Hi all
I am working on STM32F030R8 chip,using Keil MDK. For every unit, it carries it own characteristics, and hence for every calibrated unit, I need to re-flash a part of the flash to put the characteristic in.
For example, the characteristics is an array of bytes, so I create a characteristic.c file to put the data at specific location: (0x0800F000)
const unsigned char array[] __attribute__(at(0x0800F000)) = {1, 2, 3, 4, 5, 6} ;
The compiler will generates object file: characteristic.o
Now the question is, how can I get this object file converted to a hex file, that I can just page flash into the target? I think there should have simple command from the MDK suite.
Thanks
Calvin
I'm well aware of the requirement to individually program each unit with specific detail. I've done it myself many, many times during the past 25+ years!
What I have never considered and would never seriously consider is using the compiler to produce that specific detail. It just sounds plain wrong!
Nevil Chapada, I am talking about complicate structure of characteristics, containing numerous floating point numbers and integers. May be there is some other easy way to generate this structure of floating points intermix with integers into the correct binaries.
I am talking about complicate structure of characteristics, containing numerous floating point numbers and integers.
Can't see anything unusual about that. I've just written simple C programs or scripts to do such things and handed it to production. I don't want (and they wouldn't want) a development environment on their PCs.
"This somehow way can be intake the csv record, and in my example, generate the c file, shell out to call the compiler/linker/fromelf to get the hex and then page flash to the target."
But why, why, why involving a C compiler to compile and convert and mish and mash around the data?
You talk about "complicated structures", but haven't given a single indication that you really have anything complicated to handle.
I would not involve a compiler run once/line to convert the individual lines of a CSV file into multiple HEX files for loading. I would write one source code that would read the CSV file and directly produce the HEX output. And I would consider integrating that program directly with the factory downloader code to do the full factory programming as a single step - merge one bootloader binary + one application binary + one configuration binary formed from the CSV input data.
You don't write one calculator software to solve fact(15) and another to solve fact(27). You write a single software that takes the numeric value as input. It is only when doing something requiring extreme processing power, that you might consider doing an "on-the-fly" compilation of a configuration script into machine instructions - so for example some graphics applications might build on-the-fly a sequence of processor instructions based on input parameters, just to be able to cut the runtime speed of doing some very heavy noice processing of many thousands of frames of a movie.
In this case, you have locked down on a bad route and want to continue on that path even as the water gets deeper and deeper and fouler and fouler. Your compiler should produce one (1) version of the program per feature set - not per delivered unit. Anything that can be parametrized should be handled by configuration and not by custom source code lines. No other part of the distribution chain should require the use of any compiler.