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.
before we go on, where are you? can you fit it in 68k, in 72k in 100k ....
Erik
Declaring variables as xdata makes the code bigger.
So you want variables what are large or used at few locations to be stored in xdata, while the small and popular variables uses the best possible addressing modes.
And you want to make sure that you use bit variables when possible.
Yes, u all are right.
i have done these types of optimizations in my code like --- using small memory model, declaring variables with 'xdata', and most important i didn't used even a single 'printf' statement in my code.
santosh.
"each with 10-50 characters of text."
That's where putting the constants into XDATA-mapped ROM really helps...
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)
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.
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...
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"
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 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.
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.
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!
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.
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...
martha search compiler hints, not a good/bad processor discussion, I think.
View all questions in Keil forum