Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I am using SDCC compiler to run my C code on CC2430 (which contains 8051 controller). Problem is that SDCC generates .hex file! But I need a .elf file as output, because I want to use an elf_Loader to dynamically relocate the code! I have read a lot about SDCC compiler and there is no way that I can generate .elf from it!
So is there any way to convert .hex to .elf???
If not, then how can I interpret and read the .hex file after it has been loaded on the target board?
Thanks in advance,
I am planning to work with a cc1110 in the near future and wondering what you plan on using for a loader that needs .elf files
Currently, according to the manual, SDCC can only output ELF for HC08. But it might prove not too hard to implement it for mcs51 too. If you decide to look into it yourself and need help, just ask. If you get it to work, please send in a patch.
SDCC does not come with a converter but maybe srecord ( http://srecord.sourceforge.net/ ) can do this.
Sorry for my late reply, I did not have access to internet for last week :)
Thanks Maarten for your suggestion! And I have decided to convert .hex to .elf using .mem and .map files! Can you please guide me and give me a starting point!
In my opinion you're going about this the wrong way. I was under the impression you only wanted to put the info from the .hex file into a .elf file.
But you seem to want to combine information from the .hex and .map files in a .elf file. But the linker already has all this information when it creates these files. I suggest to adapt the linker so it can output .elf directly just as it can for hc08. You'll find these linkers are very much the same.
You still have not answered what loader you want to use. And why do you prefer .elf over an aomf file?
Well, I don't have any loader as yet, but this will be the final idea! I have looked at Contiki operating system! Adam Dunkle has written an elf_loader for his operating system! I want to do a similar thing for another operating system!
So, you are right, that instead of using .hex and .mem files to generate .elf, I should look at linker as it already has the information!
I start with this, and will ping if I have questions :)
So here I am with immediate first question! As I don't have much inside knowledge of how linker code works, so where should I start?
I compared 'main.c' of hc08 and mcs51. But may be, directly comparing these source files will not help me updating linker for mcs51!
Do you have an ELF specification? Is it tailored to the 8051? I searched but could not find one.
Which information do you want inside the ELF file? Are the contents of the HEX file not enough?
If you compared both 'main.c' files and could not figure out what to do I doubt you'll get very far with this project. The help text at the bottom explains which option to use for ELF output. Main.c parses the command line options and you'll see this one option missing in the mcs51 variant. When it is found it sets a certain flag. Search for this flag to find where it is used.
What tool did you use to compare? I used WinMerge on the two linker subdirectories.
But I get a strong feeling you would be better off if you used the hex-file for downloading.
well, as I said earlier, i need to ultimately use an elf_loader which will be able to reload some code in flash at runtime! So it can not be done with .hex file.
After comparing the linker files "lkmain.c" of MCS51 and HC08, I have a question that in "main" of lkmain.c, it is parsing some command line and checks if it is "-t", then in lkmain of HC08 it does some stuff for .elf format, but in MCS51 it is doing something related to "banks"! So from this command line argument to "main" of lkmain.c is passed?
Also do I need to change the assembly files of MCS51 in \sdcc\device\lib\mcs51 ?
Thanks in advance!
Runtime or not is not relevant, both will require a loader inside the target. But what I read between the lines is that you want to *relocate* it at runtime. Remember that the 8051 is highly unsuitable for that. I suggest to stick to putting the app at a fixed address.
I don't see the mcs51 lkmain.c do anything related to banks when "-t" is given. The only thing related to "banks" is the part about the register banks.
"So from this command line argument to "main" of lkmain.c is passed?"
I don't understand this question.
If you don't try to relocate the app you will not need to adapt the libraries. If you do, you probably even have to change the code generator.
Only if you limit your app to less than 2kB you might get relocation working, but you still need to handle function pointers in a special way (both in the code generator and in the library).
Right now, my goal is to generate .elf somehow from sdcc. Then I will use this .elf in an elf_loader(as in Contiki operating system)which is part of the operating system.
Well, we have a sensor networks project going on, and our sensor nodes are not within our physical reach after deploying them, but they are communicating via radio transciever to our base station. So we have to used some dynamic loading of the code at runtime if we want to update the configurations of our sensor nodes at any time in future!
So currently the task is to get somehow .elf after compiling from sdcc!!!
Ahhhh! There was a word missing in the sentence: "So from this command line argument to "main" of lkmain.c is passed?"
Here is the question again: "which command line is parsed by "parse()" of lkmain.c? and where I can see that ohhhh here it is passing -t?"
Any help please????
Thanks, I have figured it out myself :)