Hello. my name is santosh. i need some help in selecting a compiler. i am developing an embedded application which is crossing 64KB code size and i am using AT89C51RE2 microcontroller which is having (will support) 128 Kbytes of on-chip ROM (code memory). My problem is, when i am compiling the code, target is not created i.e. hex file is not generating, becoz my compiler supports maximum 64 KBytes. So, plz suggest me a right compiler which should support uoto 128 Kbytes and also tell me how i obtain from keil.
Thanks and regards, santosh.
PK51 Professional Developer's Kit
I'm sure an AT89C51RE2 does not, and can not, have 128 Kbytes of on-chip ROM !!
You do understand that the 64K limit is an inherent linitation of the 8051 architecture, don't you?
SO using >64K means that you will have to mess about with Banking (aka "paging").
Do you really want to do that? Would it not be better to find a more suitable architecture for this size of application?
www.atmel.com/.../doc7663.pdf :
128K bytes On-chip Flash Program/Data Memory – 128 bytes Page Write with auto-erase
I do not know about the Arghmel chips, but the SILabs 128k flash derivatives have a free paging support available for Keil software. Obviously the standard Keil Paging does not work for >64k internal flash.
Anyhow I agree that with the chips available today it is almost ridiculous to use a '51 if 64k is not enough.
Now, before the flames begin, please note 'alomst' in the above sentence.
Erik
"128K bytes On-chip Flash Program/Data Memory"
Note the "program/data" in that.
One thing that the PK51 kit gives you is the ability to move constant data out of CODE space and into ROM mapped as XDATA. That means that you can make full use of the 64K CODE space limit without having to mess about with code banking.
I was using that about ten years ago when there were very few ARM-based microcontrollers about (certainly no Cortex-M), and they were a significant leap from an 8051.
Nowadays, I really wonder if it's worth it...
martha search compiler hints, not a good/bad processor discussion, I think.
It's not a question of whether the processor is "good" or "bad" as such.
The question is whether an 8051-based processor is an appropriate choice for this project.
As already noted, the OP is fighting the specific limitations of the architecture; so it is certainly worth considering whether using a different architecture - which does not have those limitations - would be a better idea...
See: www.8052.com/.../158656
Especially as the OP, apparently, doesn't have the necessary tools anyhow...
hello all. thanks for your valuable suggestions. and i am sorry, that i could not respond u all immediately b'coz i was out of town in past 3 days. ok, coming to subject, from your words, i understood that i have to replace existing architecture with new microcontroller which can support >64Kytes. but it is not possible to change hardware b'coz i am working under an organization and developing the application officially. ofcourse i will consider your suggestions and i am planning implement it for next version of our application (project). but for the current version, it is not possible to change hardware design, b'coz we have seperate hardware design team and it is already brought up into PCB board and some other sections of application are working on this hardware PCB. so, finally i feel compiler/IDE is the only tool which resolve this issue for current version of my application. so, plz if possible suggest me a good compiler which can support >64Kbytes of code.
thanks and regards, santosh.
No, I didn't say that!
I said that it's something to which you should give serious consideration, but I very carefully didn't say that it was an absolute necessecity!
"it is not possible to change hardware b'coz i am working under an organization and developing the application officially"
The fact that it's a commercial development is not a reason not to do it! In fact, precisely because it's a commercial development, someone in the organisation needs to carefully consider how muach it is going to cost the organisation - in terms of development time, added complexity, etc, etc...
"it is not possible to change hardware design, b'coz we have seperate hardware design team"
Again, that does not follow! If you have a separate hardware team then, surely, it is their job to develop appropriate hardware?!
Again, someone in the organisation needs to take an overview on this - it would be stupid to "save" (sic) one man-week of hardware time at the cost of two man-weeks of software time!! (those are just random example figures - I'm not saying they actually relate to this issue).
" i feel compiler/IDE is the only tool which resolve this issue for current version"
You may be right - but you (or someone in your organisation) really need to do a proper analysis to be sure!
"suggest me a good compiler which can support >64Kbytes of code"
If you ask on the Keil forum, there's obviously only going to be one answer here, isn't there?!!
You have already been given that answer!
It's great if the hw team thinks they have the hardware up and running.
But one important fact is that smaller microcontrollers have very low hardware binding - they need power and potentially an external oscillator. Then most of the rest is basically GPIO signals, or pins that may be used as UART, SPI, I2C, ...
As long as the external signals have the same voltages, it's quite easy to keep most of the external electronics but to slap in a different processor. People don't tape their PCB anymore, so they don't need to start from scratch with the hw design. Just make sure that the dedicated pins gets correctly allocated to whatever special hardware there are on the board.
The big issue - who did the prestudy that resulted in the selection of the current processor? Anyone did a serious attempt at guestimating memory needs? And having two teams means that the sw developer(s) can start to program long before there is hardware. That should quickly show if the software grows in a dangerous way in regards to variable or code space. The only factor that may be hard to figure out beforehand is the CPU speed needed. But the Keil simulator can help out greatly there.
i am developing an embedded application which is crossing 64KB code size have you considered 'slimming' the code? e.g. getting rid of printf() etc will gain a considerable amount of space. Also changing "standard C" to "architure aware C" can do much. Of course, if you are using the large model, the solution may be right there.
Not in terms of a >64K application, it won't!
"changing 'standard C' to 'architure aware C' can do much"
Indeed.
See: http://www.keil.com/support/man/docs/c51/c51_xc.htm for starters...
I have, most often seen 'application', when talking small embedded, applied to ALL the code.
Getting rid of printf() etc WILL save codespace (in 99% of cases) going 'small' WILL save codespace compared to 'large'. There are more ways than these, but the main point is: "the '51 ain't no PC"
Of course it will. But, out of a 64K application, it will not save a significant amount of code (less than 2K).
Changing from Large to Small memory model could make a significant difference - as it is liekly to affect a very large number of variable access...
It's probably not the size of printf() that is important - but if the code contains hundreds of printouts - each with 10-50 characters of text.
If I need printouts, I often use tokenized prints, and use a postprocessor that scans the data and expands it into readable messages again. This both saves code space and required bandwidth.
if (s)he is at, say 68k there are many (easy) means, if he is at 120k drastic measures will be needed (and probably not be sufficient, although I have done >50% code reductions)