[OT?] AVR Bootloader-Problem

und mal wieder saß das Problem davor.

Am geposteten Quelltext muss folgendes geändert werden :

#if defined(__ATmega168__) #include "iom168.h" #define SPMREG (SPMCSR+0x20) ;

Wenn es dich interessiert, könnte ich dir eine gute Alternative zum selbstgebrauten Bootloader geben. Und zwar gibt es sehr nettes Paket, das "MegaLoad" heißt - es unterstützt alle ATMEGAs. Selbstgetestet hab ich allerdings erst den ATMEGA16 + 32, es sollte aber die anderen auch können. Der Bootloader kann sowohl Flash, als auch EEPROM. Will man auf die EEPROM-Funktionalität nicht verzichten, benötigt man 1kB Flash, sonst nur

512Byte.

Hier der Link dazu:

Mfg Thomas Pototschnig

Erik Groß schrieb:

...oder einen Compiler.

--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
				Kristian Köhntopp, de.comp.os.unix.misc

Man kann die AVR-Controller auch sehr schön in C programmieren. Hierbei wird i.d.R. ein Code erzeugt, der zwar mit einem handoptimiertem Assemblercode nicht mithalten kann, aber für die überaus meisten Zwecke mehr als ausreichend ist.

Zwar sind auch bei der Programmierung in C gewisse Unterschiede zwischen den Controllertypen zu beachten (so habe ich neulich zwei Stunden gesucht, bis ich herausfand, daß beim ATmega8 beim Beschreben des Registesr UCSRC ein Bit zwingend gesetzt werden muß, welches in den Registern UCSRnC des ATmega128 reserviert ist. Im Datenblatt des ATmega128 steht dafür der irreführende Hinweis, daß man dieses Bit aus Gründen der Kompatibilität auf Null halten soll.

ATMEL hat meinen Einwand, daß dies verwirrend ist, und ein gesonderter Hinweis auf die Notwendigkeit, dieses Bit in manchen Controllervarianten setzen zu müssen, allerdings vom Tisch gewischt. Offizielle Stellungsnahme ist, daß der ATmega128 neuer sei, und sich der Hinweis auf Kompatibilität nur auf nach dem ATmega128 erscheinende Typen beziehen würde.

Aber dennoch ist unter dem Strich die Programmierung in C deutlich einfacher und portabler.

--
"Erst war es ein Kernel alle halbe Jahre, zum Schluss konnte ich mit 
dem Compilieren nicht mehr aufhören." (Torsten Kleinz im IRC)

Solche kommentare kann man sich sparen. Und wer schonmal einen C-Compiler für z.B. die AVRs benutzt hat, der wird wissen, dass man da umso mehr Assemblerkenntnisse braucht um die erzeugten Fehler durch Optimierung zu finden ;-)

Mfg Thomas Pototschnig

^^^^^ Meinst du das jetzt halbwegs ernst? Also ich habe bisher nur den GCC benutzt (wuerde mich aber bei der kommerziellen Konkurrenz nicht mit weniger zufrieden geben als es umsonst gibt) und da sind mir bei diversen Projekten seit V3.3 keine Fehler mehr aufgefallen - jedenfalls nicht im Compiler selbst. Es gab ein oder zwei minderschwere Bugs in der libc, das waren aber pre-V1.0 snapshots (da muss man das akzeptieren).

Der vom GCC erzeugte Code war allemal fehlerfreier als ich ihn mit der Hand hinbekommen haette, allerdings ziemlich langsam und gross. An diversen wichtigen Stellen die ich in Assembler neu geschrieben habe war auf Anhieb Faktor 2 bei der Geschwindigkeit (gegen "-O3

-finline-limit=2000") und Faktor 1.5 bis 2 bei der Codesize (gegen "-O3") zu holen ... mein Code war am Anfang aber alles andere als fehlerfrei.

Anmerkung: Ein richtig guter C Programmierer (der ich IMHO nicht bin) kann sich da vielleicht anders ausdruecken, so dass der Optimizer besser versteht was er sich dabei gedacht hat ...

Micha

--
Mails containing HTML or binary windows code are rejected.

Jo - das Problem war, dass hier und da mal ein volatile zu wenig und schwupps hat wieder was nicht funktioniert. Im Assemblercode hat man das Problem ziemlich schnell gefunden - aber ohne Assemblerkenntnisse wäre ich vermutlich verzweifelt :-)

Ich wollte auf keinen Fall sagen, dass AVRGCC schlecht wäre oder Fehler produziert. Aber Gemeinheiten gibt's bei C eigentlich mehr als bei Assembler :-)

Mfg Thomas Pototschnig

"Thomas Pototschnig" schrieb:

Das sollte einem aber nach dem ersten Fehlversuch nicht mehr passieren, dann weiß man, was `volatile' ist und wann man es genau braucht. Ich würde sagen, dass ich in den letzten 5 Jahren keins mehr ,,einfach nur so'' vergessen habe davon.

Klar sollte man den generierten Assemblercode *lesen* können, aber das heißt noch lange nicht, dass man ihn auch selbst vernünftig

*programmieren* können muss. Das beides ist ein himmelweiter Unterschied. Ich kann auch einigermaßen den generierten Assemblercode für eine UltraSPARC lesen (und nach einem Tag Einarbeitung auch wieder verstehen), aber bis ich das selbst programmieren könnte, wäre eine Ewigkeit an Lernkurve nötig.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Hmm, das ist aber irgendwie nicht dem Compiler anzulasten, oder?

Bernd

Bin mir da nicht so sicher - passiert hin und wieder bei Sachen, bei denen ich mir immer ziemlich sicher bin, dass man kein volatile benötigt hätte. Hab leider jetzt kein Beispiel, weil sowas selten vorkommt.

Ich wollte ja eigentlich nur darauf hinaus, dass man auf Assembler-Kenntnisse nicht verzichten kann, auch wenn man einen Hochsprachen-Compiler benutzt. So quasi:"Ich hab jetzt C - jetzt brauch ich mir nie Assembler beibringen", oder so ungefähr.

Mfg Thomas Pototschnig

"Thomas Pototschnig" schrieb:

[volatile]

Dann ist es meist ein anderer Bug, der sich in deinem Code versteckt, und um den du durch die Nicht-Optimierung mittels volatile drumrum werkelst.

Agreed. Man muss eben nur nicht fließend in Assembler programmieren können.

--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
				Kristian Köhntopp, de.comp.os.unix.misc