??? 12/08/08 06:38 Read: times |
#160707 - Be Very Careful Responding to: ???'s previous message |
If you intend to march off to Dual C programs be very wary of how you are going to manage any shared variables between the two programs and how you will go about easily coming up with an efficient 8051 style way to let boot_loader.c have data allocations that can use the same RAM as application_prog.c. This is not a trivial exercise!! In addition, since both programs are compiled separately, there is a maintenance headache to solve as well because the ways you end up managing this type of mess. For the introductory level C programmer this management often ends up as sets of special statements in the two programs which must be kept correct in parallel to assure that the boot loader and application work properly with each other. I have seen some samples of this that end up pre-allocating separate RAM spaces for each program's data and buffers. This ends up being wasteful and limits the amount of resources available to the application program. This is especially problematic on 8051 type MCU devices where available RAM is so precious!!
Advanced and clever C programmers may be able to come up with fancy sets of macros, shared source files, and specialty header files to make this RAM data space management a little bit more reliable but I would bet that even I would be hard pressed to fully understand how it worked!!! When you follow my suggestion to put the boot loader in to ASSEMBLER language it can simply be a source file compiled into the same build process as the application program. Since it is in assembler it is quite easy to manage the data RAM space between the loader and that managed by the C compiler. Almost ALL RAM used by the boot loader is fully reclaimed and available for the application as per the C program. Keep in mind that C programs written in Keil C51 and others make heavy use of RAM for local variables, calling parameters and so forth. The standard 256 bytes of RAM in an 8051 application written in C can often see heavy usage. It would be easy to expect that many applications cannot afford giving up some 10-20 bytes for variables and 32 or 64 bytes saved away for buffers to support a C language boot loader that is seldom used. Go for an assembler boot loader. You will save yourself hours and days of self inflicted torture. If you are not proficient yet with assembler language that time will be far far more productively utilized by you in teaching yourself a new skill that will be valuable for you again and again. And lastly I'll comment again that I believe that one has no business trying to use C coding on an MCU, for any kind or programming, without first demonstrating a modicum of proficiency with the MCU assembler language. Michael Karas |
Topic | Author | Date |
Bootloader | 01/01/70 00:00 | |
you are mixing RAM and ROM and .... | 01/01/70 00:00 | |
Circuit | 01/01/70 00:00 | |
Follow up the reply | 01/01/70 00:00 | |
rework the board so that ... | 01/01/70 00:00 | |
How to rework the board? | 01/01/70 00:00 | |
I give up | 01/01/70 00:00 | |
Don't Give Up... | 01/01/70 00:00 | |
two ways | 01/01/70 00:00 | |
a sample | 01/01/70 00:00 | |
StartUp Code | 01/01/70 00:00 | |
I have heard that ... | 01/01/70 00:00 | |
this is a forum for help with problems ... | 01/01/70 00:00 | |
Thank Erik,.. | 01/01/70 00:00 | |
Dual C Programs | 01/01/70 00:00 | |
Dual C Programs | 01/01/70 00:00 | |
Be Very Careful | 01/01/70 00:00 | |
Be Very Careful | 01/01/70 00:00 | |
BEWARE | 01/01/70 00:00 | |
please do not .... | 01/01/70 00:00 | |
Upload Image... | 01/01/70 00:00 | |
That's not the way... | 01/01/70 00:00 | |
Von Neumann - Interrupt problem | 01/01/70 00:00 | |
Yes | 01/01/70 00:00 | |
Interrupt problem | 01/01/70 00:00 | |
Erik's advice? | 01/01/70 00:00 | |
How to use the code? | 01/01/70 00:00 | |
Strong Suggestion..... | 01/01/70 00:00 |