Author Topic: useful links on C programming on AVR.  (Read 1621 times)

0 Members and 1 Guest are viewing this topic.

Offline dunkTopic starter

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 1,086
  • Helpful? 21
useful links on C programming on AVR.
« on: February 09, 2010, 08:28:55 AM »
hey guys,
i've been digging into the workings of avr-gcc over the last few days.
in that vein i stumbled across this nice simple diagram of how all the components fit together:
http://www.avrfreaks.net/wiki/index.php/Documentation:AVR_GCC/AVR_GCC_Tool_Collection

another nice article i stumbled upon was this one on C program structure:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=48535

anyone got anything else useful on programming in their bookmarks folder?


dunk.

Offline Admin

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,660
  • Helpful? 169
    • Society of Robots
Re: useful links on C programming on AVR.
« Reply #1 on: February 10, 2010, 12:08:15 AM »
So . . .

C -> assembly -> hex . . . does the hardware programmer then convert it to binary?

Offline Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,150
  • Helpful? 110
Re: useful links on C programming on AVR.
« Reply #2 on: February 10, 2010, 12:43:31 AM »
Hold on ... I think there are some issues with the original diagram - let alone what folk understand it to mean.

The diagram shows how you can write assembly language files and these, once parsed/compiler, go to the linker as object files.

The diagram suggests that our C programs are also converted to assembly programs and that these follow the path above. In reality this is not the case. The C programs are compiled (and yes it may produce intermediate assembler files) but these files are not visible by you. They go straight into object files.

The linker then takes all of your object files (regardless as to whether they started as C or Assembly language coz they are now just object files) and adds them all together.

The resultant file has all sorts of meta-data in it like filenames, line numbers etc. Hence if you debug a program in AVRStudio it can show you the correct line from the correct C file for the current instruction.

Quote
C -> assembly -> hex . . . does the hardware programmer then convert it to binary?
What do you mean by binary?

An elf file has all sorts of meta data within it. Thats why it can be used to generate all sorts of stuff like rich listing (LSS) files.

From this elf you can produce a hex file - ie the bare program with all meta-data stripped out. Maybe thats what you mean by a "binary"?

At the end of the day: a hex file is produced (with everything else stripped out) and the raw machine code is sent to the processor.

The hardware programmer does nothing - its just a file transfer program.

The avr-gcc toolset like all good compilers will retain all meta-data until the very last minute.

But this is all advanced stuff - you need know nothing!
Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.co.uk

Offline Admin

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,660
  • Helpful? 169
    • Society of Robots
Re: useful links on C programming on AVR.
« Reply #3 on: February 10, 2010, 12:55:11 AM »
Quote
C -> assembly -> hex . . . does the hardware programmer then convert it to binary?
What do you mean by binary?

An elf file has all sorts of meta data within it. Thats why it can be used to generate all sorts of stuff like rich listing (LSS) files.

From this elf you can produce a hex file - ie the bare program with all meta-data stripped out. Maybe thats what you mean by a "binary"?

At the end of the day: a hex file is produced (with everything else stripped out) and the raw machine code is sent to the processor.

The hardware programmer does nothing - its just a file transfer program.

I'm a little confused on what goes on between the .hex file saved on my PC, and how its stored/read on the actual AVR chip. Somewhere the hex is converted into 0's and 1's for storage in memory, no? Isn't the .hex file already in 'raw machine code'?

Its not something I need to know, I just program in C and its all automagic, but I've been asked this before and I don't like to give the "I don't really know" answer.

Offline Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,150
  • Helpful? 110
Re: useful links on C programming on AVR.
« Reply #4 on: February 10, 2010, 03:12:50 AM »
The hex file format obeys the Intel hex file format http://en.wikipedia.org/wiki/Intel_HEX

Its the lowest thing in the food chain: having produced elfs etc. along the way

But it still retains a certain amount of structure ie its not just a sequence of 1s an 0s as seen in your favorite sci-fi movie.

It still has info as to what should be loaded where: and the data is still in human readable form.

So when you load it into your AVRISPII then it reads it in - and coverts it into real binary format. Yep - the last part is done by your programmer.

Is anyone interested in this - or should I just hit 'auto-sleep' now ?  :)
Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.co.uk

Offline dunkTopic starter

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 1,086
  • Helpful? 21
Re: useful links on C programming on AVR.
« Reply #5 on: February 10, 2010, 04:46:13 AM »
The hex file format obeys the Intel hex file format http://en.wikipedia.org/wiki/Intel_HEX

Its the lowest thing in the food chain: having produced elfs etc. along the way

But it still retains a certain amount of structure ie its not just a sequence of 1s an 0s as seen in your favorite sci-fi movie.

It still has info as to what should be loaded where: and the data is still in human readable form.

So when you load it into your AVRISPII then it reads it in - and coverts it into real binary format. Yep - the last part is done by your programmer.

to my understanding the .hex file is 2 columns of numbers.
first, the hardware address,
second, the instruction to be saved at that address.

taking a look at an actual AVR .hex file just now i can see it's not actually that simple:
Code: [Select]
:1000000029C043C042C064C69CC535C6DAC506C611
:100010006BC517C53AC039C038C037C036C035C007
:1000200034C070C932C00000010008004000000167
:1000300000040000010008002000400080000001D2
:1000400000043031323334353637383.........
etc....
(according to wikepedia http://en.wikipedia.org/wiki/Intel_HEX) what we are actually seeing there are 8 data bytes and a 1 byte checksum per address.

with hardware programmers i have always presumed the format an AVR actually takes the program in is address:data pairs.
i know that is how it is the AVR saves it if you are using a bootloader.


Is anyone interested in this - or should I just hit 'auto-sleep' now ?  :)
dude, it's got to be really late for you when you made that post so i recommend sleep...

so in an ideal world this stuff is never needed.
it is very useful to know when stuff is broken or you are dealing with someone else's code though.

it's good information for anything that uses GCC, not just AVRs.
anyone who's tried to get obscure hardware platforms running using pre-compiled drivers will have hit this wall before.
(i also find it interesting but i'm weird like that.)


dunk.

Offline Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,150
  • Helpful? 110
Re: useful links on C programming on AVR.
« Reply #6 on: February 10, 2010, 05:29:02 AM »
Quote
taking a look at an actual AVR .hex file just now i can see it's not actually that simple:
But it IS simple.
Here's your example:-
Code: [Select]
:1000000029C043C042C064C69CC535C6DAC506C611
:100010006BC517C53AC039C038C037C036C035C007
:1000200034C070C932C00000010008004000000167
:1000300000040000010008002000400080000001D2
:1000400000043031323334353637383.........
etc....
First:
if each line has a checksum and then say 16 bytes of data then thats 17 bytes per line. Each byte is a 2 hex digit value ie 00->FF.
So count back 17 x 2 digits and a space - you now get:-
Code: [Select]
:10000000 29C043C042C064C69CC535C6DAC506C611
:10001000 6BC517C53AC039C038C037C036C035C007
:10002000 34C070C932C00000010008004000000167
:10003000 00040000010008002000400080000001D2
:10004000 00043031323334353637383.........
etc....

Next step. If each line has 16 data bytes (+ a checksum)  then 16 in hex is 10. So we would expect the number at the lhs to be going up in steps of 10. And it does! Just add some more spaces:-
Code: [Select]
:100000 00 29C043C042C064C69CC535C6DAC506C611
:100010 00 6BC517C53AC039C038C037C036C035C007
:100020 00 34C070C932C00000010008004000000167
:100030 00 00040000010008002000400080000001D2
:100040 00 00043031323334353637383.........
etc....

ok: so lets refer to wikipedia rules:-
   1. Start code, one character, an ASCII colon ':'.
   2. Byte count, two hex digits, a number of bytes (hex digit pairs) in the data field. 16 (0x10) or 32 (0x20) bytes of data are the usual compromise values between line length and address overhead.
   3. Address, four hex digits, a 16-bit address of the beginning of the memory position for the data. Limited to 64 kilobytes, the limit is worked around by specifying higher bits via additional record types. This address is big endian.
   4. Record type, two hex digits, 00 to 05, defining the type of the data field.
   5. Data, a sequence of n bytes of the data themselves. 2n hex digits.
   6. Checksum, two hex digits - the least significant byte of the two's complement sum of the values of all fields except fields 1 and 6 (Start code ":" byte and two hex digits of the Checksum). It is calculated by adding together the hex-encoded bytes (hex digit pairs), then leaving only the LSB of the result, and making a 2's complement (either by subtracting the byte from 0x100, or inverting it by XOR-ing with 0xFF and adding 0x01). If you are not working with 8-bit variables, you must suppress the overflow by AND-ing the result with 0xFF. The overflow may occur since both 0x100-0 and (0x00 XOR 0xFF)+1 equal 0x100. If the checksum is correctly calculated, adding all the bytes (the Byte count, both bytes in Address, the Record type, each Data byte and the Checksum) together will always result in a value wherein the least significant byte is zero (0x00).

So looking at the first line with some extra spaces:
:10 0000 00 29C043C042C064C69CC535C6DAC506C6 11
Rule 1 = it starts with a colon - yep
Rule 2 = number of chars that follow=10hex ie 16 digits
Rule 3 = address as 4 hex digits = 0000
Rule 4 = record type 00 = data record
Rule 5 = data  digits. So 16 x 2 hex digits
Rule 6 = Checksum. in this case '11'

So it totally conforms to the spec.

So the programmer will write out 16 bytes of data starting at address 0000 where the 16 data bytes are  29 C0 43 C0 42 C0 64 C6 9C C5 35 C6 DA C5 06 C6

Simple!
Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.co.uk

Offline Conscripted

  • Robot Overlord
  • ****
  • Posts: 291
  • Helpful? 10
Re: useful links on C programming on AVR.
« Reply #7 on: February 12, 2010, 11:01:20 PM »
Excellent explanation Webbot. Thank you very much.

Offline billhowl

  • Supreme Robot
  • *****
  • Posts: 375
  • Helpful? 32
  • Your success is in your hands.
Re: useful links on C programming on AVR.
« Reply #8 on: March 01, 2010, 06:45:57 AM »
a little place for some LEGAL ONLINE C tools and or references.

Find/Post your Online C Books & Tools here.....

http://www.ipass.net/hammill/newavr.htm
« Last Edit: March 02, 2010, 10:57:16 AM by billhowl »

 


Get Your Ad Here

data_list