AVR-GCC

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

iam totaly new in programming with the gnu winavr compiler. i made a project with an atmega8 an an 30day eval version of iccavr, nice tool but very expensive. now i want to use the winavr for compiling. i read parts of the documentation and get to that point of error free compiling, linking, converting to hex. for isp-programming i use the sp12. i spend the last 2 nights for this problem, but i get no response from the controller. loading the file, made with iccavr works the expected way.

my questions are, has somone a working makefile for winavr and atmega8 (the example in the documentation did not work, with the changes to atmega8)?
has someone another tutorial than that one on the gcc site and that one here?
and at least, are there other documentation that help me to understand how this hole winavr thing works (i seems to me, like there is somthing missing in that included documentation)???

thanks a lot in advance for any help.

joerg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1. What is the "sp12"?
2. Have you verified that your device is truly programmed? (It matches the hex file.)
3. Have you used the avrdude program that comes with WinAVR?

Eric

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Eric

1. sp12 is an is an nice programmer from pitronics (www.xs4all.nl/~sbolt/e-index.html). it can also burn fuses.

2. what means truly programmed? (i have compared both hex files (from iccavr and winavr), they dont match)

3. i use 1.

the examples from the manual also want work. i know i do smth wrong but i didnt fund it yet. is there another tutorial for programming avr in c with winavr?

joerg

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Apendix

with the sp12 programmer there is also the posibility to upload the program again and check the checksum. this part of the programming is also ok.

joerg

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your programmer should have a way to "verify" the AVR part. Verify will read back the FLASH in the AVR and compare it to the file that you used to program it with and make sure that what is in the AVR is the same as the file that you used to program it with.

This makes sure that your programmer and your programming setup is correct.

If you "get no response from the controller" after programming it with an Intel Hex file that was correctly generated by the GCC toolset, then you need to make sure and do a verify when you program to see if the AVR was programmed correctly.

Eric

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, that is what if tried also. the verification of the programming process was ok, so i think there is smthg wrong with the hex file.

joerg

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You will have to post your compiler output then.

Eric

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thank you for your pation.

joerg

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hard to guess from an object file what might be wrong
with this. At a first glance, it looks OK. Of course,
all the various AVR compilers aren't fully source-level
compatible, every compiler has some loose ends where it
handles things differently than others.

Several functions are included, but never called, like
tastennummer_in_ascii(), auswertung_zeile(),
auswertung_spalte(). Is this intented? Actually, the
only function called by main() is the device
initialization, and then, main() falls into a loop.
It toggles PD7 once before that loop, so that pin
should be at high level. The loop itself is an
indefinte one -- my guess it's a typical case of a
missing "volatile" keyword.

If you ever stop by in Dresden, you might buy me a beer
for that analysis -- for not reading the FAQ before
posting. ;-)

http://savannah.nongnu.org/downl...

Look at the first entry. Of course, in WinAVR, all
the documentation is on your harddisk as well...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

...and I meant the "messages" that the compiler prints to stdout when you build...

Eric

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank You Joerg for that analysis.

The beer thing is easy to handle, i live near Chemnitz...

Back to the Problem, in that version its intended (sorry, that was my fault, that i did not tell you) that the program goes into an endless loop, just to toggle pd7 (an led, that should blink). the loop itself should toggle pd7, wait some time (by interrupt) and toggle again.

by Joerg

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, but you still didn't read the FAQ, did you? ;-)

Read topic #1 in the FAQ (it's #1 there because
it is simply the most frequently asked
question). Then declare the variable you are
waiting for as volatile, so the compiler
won't optimize it away.

Then test it.

After enjoying your running example, go back
to the FAQ, and read the remaining entries. :-)
Maybe you'll need to remember them some day...