Linux - Embedded & Single-board computerThis forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Microcontroller code generally contains a lot of hardware-specific modules and possibly compiler-specific code to handle things like memory restrictions and access to built-in peripherals. The rest of the code should compile quite well. You will need a cross toolchain. I build cross toolchains with Crosstool-NG.
Thanks for your reply. Let me elaborate my problem,
I am having a C code which is for AVR controller(8 Bit) and we can develop a .exe file
using microvision IDE, and i am able to generate a .exe using that IDE.
But i want to run the same C code on ARM controller. From your link, i came to know to know i need to build a new toolchain to run that code.But i am already having a toolchain build, when is able to cross compile the code for Arm based system.
Let me elaborate more, suppose i am having a program i.e a.c, and i am able to cross compile like:
arm-linux-gcc a.c -o a.out, and that a.out is able to run properly on arm system.
When i run another code : b.c written for 8 bit controller, can't i use, the command like this:
arm-linux-gcc -m32 b.c -o b.out.
As far a know, only the headers are different between the two code, one is using linux headers(a.c) and other is using controller headers(b.c).
Do i really need to be build crosstool gcc toolchain for 8 bit code???
Well, if you compile a source module with one set of compiler options and it works, why would you use a different set of options to compile the other source module? If you already have a cross toolchain that works, then clearly, you don't need to build one. You don't need the toolchain to run the code; you need it to build the code. The code you have may not compile for a different target architecture if it uses 8-bit target-specific compiler directives, or uses headers that don't exist for Linux (assuming bare-metal builds for 8-bit micro). In that case, you will need to identify the differences in the targets and modify the code accordingly.
Is your question about how to generate the code that gets loaded into the EEPROM, or is it about how to do the loading? It sounds like your question may be about how to convert the a.out file format into a suitable Intel-format hex file for a PROM burner or for a download monitor on your target. If so, I can only give you some general pointers and background information.
First, the Intel-hex format (or any other industry standard hex formats, like Motorola S-records, and a few others), are generally intended for carrying fully static image files. The file format encodes the binary data as well as specific address data for 16-bit addresses; the address fields in the file are only a 16 bits wide. There is no equivalent description of external linkages, such as shared object libraries. Basically, it is a way of mapping each byte in the image to a specific 16-bit address, and nothing more (other than some checksum-style error checking).
Given the above, whatever code you create with gcc will need to be fully statically linked, and probably generated as Position-Independent-Code (see the gcc option 'PIC'). I'm not well acquainted with the a.out file format, but I think that the alternative ELF format may be a better option. You will have to research whatever file format you choose, and either find a ready-made converter, or write your own.
If your question is about how to write an existing hex file to an EEPROM on the target, then you should start by reading the Wikipedia page on Intel HEX format data. It is not difficult to decode the data file, and I'm sure you can find an abundance of free code to do so. I used to have a collection of tools that I wrote for this 20+ years ago, but I don't know if I can still find it. I assume your target host has some firmware or other means for writing to the EEPROM, or you are using a commercial burner to do so, and plugging the chip into a socket (in which case, the burner should have code to load the EEPROM from hex files). Occasionally, microcontroller-based boards have a means to enable a ROM monitor on reset using jumpers or switches, and sometimes this provides a means to upload hex formatted images via a serial interface. Without knowing any details of your target host, one can only speculate about the means for loading new firmaware. Another possibility is via a J-tag dongle. If so, your dongle should have software and documentation describing the process.
It wouldn't hurt to give a more complete description of your target board. If it is a commercial product, there may be someone with direct experience to help you.