Compiling 8 bit code using gcc compiler
 

Hi All,

I want to compile 8 bit microcontroller to run it on arm(32 bit) based controller. What is the procedure to do that?

Regards,
Ravi

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.
--- rod.

hi theNbomr,

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???

Kindly provide your inputs.

Regards,
Ravi

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.

--- rod.

i know that the cross compiler is to build the code, and it will generate a target specific binary :-).I will try to do the target specific changes and let you know.

Hi theNbomr,

Its basically a firmware upgrade related work using SPI bus on EEprom(AT25128 chip).
That means i have to read the EEprom first and update a firmware on to that EEprom.

Suppose, i am generating the "test_eeprom" binary and using that i have to update the firmware
there on EEprom(assume it as 1.hex), then i should be able to do that using below mentioned command:

./test 1.hex, after passing this i should be able to write firmware on the EEprom chip.

Please help me and let me know if you have any suggestions.

Regards,
Ravi

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.
--- rod.