How to declare and assign variables in ROM to an specific address
Is the demand real? Is it really difficult to implement? Yep. The demand for this is obviously real. And, Yep, it's also going to be difficult to implement. It is on the list of feature that we will add, however, there are lots of features on this list and many of them have no work-arounds. Needless to say, we fix or implement those first. Since there are numerous ways to use fixed addresses for checksums, CRCs, configuration data, MCU reset configurations, and so on WITHOUT locating an initialized variable, it is not considered a critical situation. Let me elaborate... Checksum/CRC Does the C program REALLY need to assign the value of the CRC or checksum as shown in the following code?
unsigned int code my_programs_crc = 0x1234 _at_ 0xFFFF;
unsigned int code my_programs_crc _at_ 0xFFFF;
struct config_st { unsigned int hi; unsigned int lo; unsigned int span; unsigned int hi_limit; unsigned int lo_limit; unsigned char warm_start_flag; }; xdata struct config_st my_config_data = { 20, 4, 16, 18, 7 } _at_ 0x1000;
struct config_st { unsigned int hi; unsigned int lo; unsigned int span; unsigned int hi_limit; unsigned int lo_limit; unsigned int warm_start_flag; }; xdata struct config_st my_config_data _at_ 0x1000; code struct config_st reset_config_data = { 20, 4, 16, 18, 7, ~0xDEAD }; . . . if (my_config_data.warm_start_flag != ~0xDEAD) { // Config Data is Trash -- Cold Start my_config_data = reset_config_data; } else { // Config Data is OK }
Jon, You should be considering how best the problem can be solved instead of trying to catalog all the possible situations in which it occurs. My issue is that my system stores code in flash memory, and I reserve a sector for configuration storage there, too. I'd like to burn the default configuration into flash before pc assembly. That saves an operation in manufacturing. My solution is not elegant, but it DOES work. My project includes an assembly language STARTUP file instead of letting the compiler generate start up. Within that file, I am free to locate and initialize a section of code memory. The name can be declared PUBLIC. For example, CSEG AT 0xc000 PUBLIC config config: DB 0, 5, 0x55,... Over on the C side, I just declare extern code data_type config; No need to redeclare the address. The linker already knows its location. There are two obvious problems with this solution. * First, you MUST include an assembly language file in the build. Most of us would like to avoid that because it is non-portable. * Second, it's a maintenance nightmare. If the data struct is very complicated, it is SO easy to get off by one byte. Then it could take forever to get back on track. No doubt, it would be sweeter to write the whole thing in C, but depending on your desperation factor, you might stoop to my level. Jeff.
Jeff, my comments are not necessarily directed to you specifically. You just drew them out of me. Reordering quotations... "No doubt, it would be sweeter to write the whole thing in C, but depending on your desperation factor, you might stoop to my level." Well Jeff, I would contend that your level is just fine. "There are two obvious problems with this solution. * First, you MUST include an assembly language file in the build. Most of us would like to avoid that because it is non-portable." Maybe most of you would like to avoid assembly language because you don't know/like/whatever assembly language, but what is the "portable" way to do it? Certainly using an enhancement to a non-portable C language extension does not suddenly make it portable. If anything, the way you are doing it would be more familiar to those who have solved the same problem on other platforms, since it is the "conventional" way of going about it. "* Second, it's a maintenance nightmare. If the data struct is very complicated, it is SO easy to get off by one byte. Then it could take forever to get back on track." [rant] If a configuration data structure is complex enough to be even remotely considered a maintenance nightmare, you should be using other tools to generate it anyway. Folks should take their blinders off and expand their software tools use beyond just the assembler, compiler, linker. Software tools that were created by software developers for software developers, have been around a long time. In these cases of complex configuration data structures (especially if they change from time to time), consider expressing the configuration in form easy and familiar to the configurer, and use Perl, awk, etc. to programmatically generate an assembly source file from the configuration file as one step in your build process. [/rant] Sigh. I'm going to go off and reread Jon Bentley's "Programming Pearls" and "More Programming Pearls" for my mental health ;-)
Sorry, I just have to share this because it is so relevant. Just to illustrate the "maintenance nightmare" issue using an example, and this is literally an issue I was asked to help with today coincidentally... A client of mine who will remain nameless, is a "device" manufacturer. Their high-end parts are big and complex, having embedded CPU(s) and BGA packages with pin (ball) counts as high as 1704. The databook for this device is around 2000 pages. The databook contains pinout tables for 256, 456, 672, 676, 896, 1148, 1152, 1517, 1696, and 1704 pins (some pins missing in an otherwise regular "row" by "column" pin array). Some poor documentation fellow has to take the "source" package/pinout text documents output early in the IC design and packaging engineering process and verify BY HAND/EYEBALL that the PDF databook pinout tables match. For the big packages, these tables are upwards of 48 pages! Well guess what? A pin got dropped somewhere along the way in the databook creation process and a customer caught it. Oops. There you go. Now that's and error-prone maintenance nightmare! The documentation fellow has a remarkable attention to detail and ability to focus, but he's only human after all. He also gets to recheck all the other tables to verify that nothing has changed if there's an edit performed to another table. So what we do is use those marvelous text processing software tools my forefathers created for me, write a surprisingly simple script (program) to parse out the pins from the the engineering source document and the PDF (or from old PDF and new PDF), process one against the other looking for inconsistencies, and BAM! that poor fellow's hair starts growing back in. The moral of the story is that there is usually a way to make a complex problem simpler using the right tools. Since you are not likely to be the first one to encounter your complex problem or something very similar to it, there's a good chance that a tool exists to help you.