AVR-Bootloader =?ISO-8859-15?Q?f=FCr?= CF?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From German to

Threaded View
Hallo,

hat schon jemand einen Bootloader für den AVR gesehen/geschrieben, der sich
die Firmware von einer CF lädt? Serielles findet man ja in allen AppNotes -
das nützt mir nur wenig.

Danke,
Sebastian

Re: AVR-Bootloader =?ISO-8859-1?Q?f=FCr?= CF?

Quoted text here. Click to load it

Na ja, sagen wir fast. Denn ich muß - anders als bei "echtem" RAM der CF
erst sagen, welchen Sektor ich gerne hätte. Aber Routinen für die
CF-Ansteuerung habe ich, da liegt nicht das Problem.

Quoted text here. Click to load it

Klar - grundsätzlich bin ich auch soweit; mein Player kann FAT-Dateien
lesen. Nur: das ganze ist in avr-gcc geschrieben und damit zu groß für
einen Bootloader (max. 1k, wenn ich das Datenblatt richtig verstanden
habe). Dazu müßte ich also auf Assembler umsteigen. Und bevor ich das
mache, wollte ich halt fragen, ob jemand sowas schon in der Schublade hat.

Gruß,
Sebastian


Re: AVR-Bootloader =?ISO-8859-1?Q?f=FCr?= CF?

Quoted text here. Click to load it

Mein Problem ist der Assembler. Die bisherigen Sachen habe ich in C gemacht,
das ist einiges "übersichtlicher". Zumal für die FAT-Geschichten einige
Berechnungen (Start der FAT, CHS-Umrechnung, Start des Datenbereichs)
notwendig sind.

Mein Erstversuch (der allerdings auch noch nicht funktioniert...) sieht
erstmal vor, daß die Firmware von Sektor 1 an fortlaufend auf der Karte
steht. Wenn das funktioniert, wird FAT dazugebastelt.

Sebastian

Re: AVR-Bootloader =?ISO-8859-1?Q?f=FCr?= CF?

Quoted text here. Click to load it

Software schreiben? Ist nicht nötig: dd if=rom.bin of=/dev/hda bs51%2 ;o)

Sebastian

Re: AVR-Bootloader =?iso-8859-1?Q?f=FCr?= CF?
Moin,

Quoted text here. Click to load it

mach das mal mit deinem billig USB-CF-Reader/Writer unter Win ;)
Das wird nix.  

Gruß
 Holger

--
Dipl. Ing. (FH) Holger Klabunde
http://home.t-online.de/home/holger.klabunde/homepage.htm

Re: AVR-Bootloader =?iso-8859-1?Q?f=FCr?= CF?
Moin,

Quoted text here. Click to load it

welchen AVR benutzt du eigentlich ?

Quoted text here. Click to load it

wie kommst du darauf das ein in Assembler geschriebener Bootloader kleiner
wird als das was avr-gcc erzeugt ? Da mußt du dich aber schon mächtig ins Zeug
legen um da noch mal ein paar Prozent Ersparnis rauszuholen.

Nimm doch einfach einen ATMega32. Da darf dein Bootloader 2kB groß werden.
Oder einen ATMega128. Da darf er sogar 4kB groß werden.

Wo ist dein Problem ? Keine 10 Euro für einen größeren Prozessor übrig ?
Geiz ist geil oder was ;)

Gruß
 Holger

--
Dipl. Ing. (FH) Holger Klabunde
http://home.t-online.de/home/holger.klabunde/homepage.htm

Re: AVR-Bootloader =?ISO-8859-1?Q?f=FCr?= CF?

Quoted text here. Click to load it

Pardon me. Es ist ein ATmega 162L (16k Flash, 1k RAM).
Quoted text here. Click to load it

Wenn ich meine C-Routinen benutze, lande ich bei ca. 3kb. Wenn ich mir dann
aber ansehe, was da an Assembler rauskommt, kann man das schon um einiges
kürzen (z.B. Overhead bei Funktionsaufrufen, Schleifen etc.). Aber
vermutlich ist eine Mischung am schlauesten.

Btw: wie teile ich dem GCC mit, an welcher Adresse mein Programm losgehen
soll?

Quoted text here. Click to load it

Nee ;o) Der 162 ist schon in der Schaltung drin. Es war eher der Reiz, für's
Firmware-Update nicht mehr das Gehäuse öffnen und ein Kabel anschließen zu
müssen. Karte mit Firmware rein, einschalten, fertig. Mehr oder weniger
(lehrreiche) Spielerei.


Gruß
Sebastian

Re: AVR-Bootloader =?iso-8859-1?Q?f=FCr?= CF?
Hi

Quoted text here. Click to load it

Schneller zu entwickeln ! Das ist wichtig.
Das Programm wird durch C nicht schneller. Aber es wird schneller fertig.
Ein C Compiler meckert öfter bei Syntaxfehlern oder wenn der Datentyp
nicht kompatibel ist. Und ganz wichtig: Mit C Routinen kann man ohne
größeren Aufwand auch schon mal zwischen verschiedenen Prozessoren
hin und herspringen. Zum Teil entwickle ich C Routinen erst auf dem PC und
benutze sie dann fast ohne Änderungen mit AVR/ATMega, PIC oder 8051.
 
Quoted text here. Click to load it

Jeder der uC in C programmiert kommt einfach nicht darum herum sich auch
in Assembler einzuarbeiten. Man sollte schon eine Vorstellung davon haben
was der C Compiler aus dem Code macht. Wenns mal nicht klappt lohnt sich
der Blick ins Assemblerlisting. Nur so kann man feststellen ob der Compiler
da vieleicht ein paar Schleifen wegoptimiert hat. AVR-GCC oder auch SDCC
tun sowas ganz gerne mal. Besonders mit Variablen die man in Interrupts
benutzt. Deklaration als volatile hilft dann.

Der Streit um C oder Assembler ist ganz einfach Schwachsinn.
Handoptimiertes Assembler ist immer schneller als ein C Compilat.
Tatsache ist aber das mindestens 95% eines Programmes gar nicht
schnell sein müssen. Z.b. eine Tastaturabfrage per Interrupt
oder Zeichenausgabe auf einem LCD-Display. Bei langsamer Peripherie
muss sowohl der C- als auch der Assemblerprogrammierer aufpassen
das er nicht zu schnell ist.
 
Ich hab mal einen Audio-Sampler/Player (22kHz Samplerate) mit PIC18F242
gebaut. Alles in C geschrieben. Da war nicht eine Zeile Assembler drin.

Bis dann
 Holger

--
Dipl. Ing. (FH) Holger Klabunde
http://home.t-online.de/home/holger.klabunde/homepage.htm

Re: AVR-Bootloader =?ISO-8859-1?Q?f=FCr?= CF?

Quoted text here. Click to load it

Nicht ganz, denke ich:

"Note that the user software can never read any code that is located inside
the RWW section during a Boot Loader software operation. The syntax
Read-While-Write section  refers to which section that is being programmed
(erased or written), not which section that actually is being read during a
Boot Loader software update.

RWW   Read-While-Write Section If a Boot Loader software update is
programming a page inside the RWW section, it is possible to read code from
the Flash, but only code that is located in the NRWW section. During an
ongoing programming, the software must ensure that the RWW section never is
being read. If the user software is trying to read code that is located
inside the RWW section (i.e., by a call/jmp/lpm or an interrupt) during
programming, the software might end up in an unknown state."

Ersteres klingt gar danach, also könne man aus dem Bootloader gar keine
Funktionen im Application Flash ausführen (?!). Zweiters ist nicht so
tragisch - ich könnte ja erst einen Sektor ins RAM laden, das Flashen
passiert dann nur aus dem NRWW-Bereich.

Quoted text here. Click to load it

Diese Idee klingt doch mal richtig gut! Du hast nicht zufällig eine Idee
parat, wie ich Funktionen mit absoluten Adressen versehen kann?
Oder ich schreibe die Cluster, die der Bootloader belegt, in's EEPROM und
rufe dann erst den Bootloader auf - der dann ganz ohne FAT auskommt. Bei
einem 16k-File (abzüglich Bootloader etc.) kommen nicht viele Cluster
zusammen. Wenn ich die CF-Lese-Routinen dann noch nach Deiner obigen Idee
"share"....

Sebastian


Re: AVR-Bootloader =?ISO-8859-1?Q?f=FCr?= CF?

Quoted text here. Click to load it

Ist klar. Die Frage ist nur, wie man das "can never read any code that is
locate inside the RWW section during a Boot Loader software operation"
verstehen soll. Während des page write (in diesem Bereich) geht's nicht -
aber das steht eben nicht da. Anderes habe ich nicht gefunden.

Quoted text here. Click to load it

Ich werde das wohl ausprobieren müssen.

Quoted text here. Click to load it

Höö? Vielleicht muß ich den Absatz morgen nochmal lesen...

Quoted text here. Click to load it

Mach' ich. Wir sollten uns einfach zusammen tun ;o)

<...>

Quoted text here. Click to load it

Bei 1024 Byte RAM passen max. 2 Sektoren rein - da komme ich nicht weit. Und
ständig wieder zurückspringen dürfte auch sehr unsicher sein - wehe, es hat
sich schon eine klitzekleine Funktion verschoben...

Quoted text here. Click to load it

Ich favorisiere derzeit die "Cluster-Merk-Methode": Die normale Anwendung
sucht auf der CF nach einer Datei (firmware.bin). Wird diese gefunden,
werden die belegten Cluster (oder auch Sektoren, sind bei 16KB Flash ja
max. 32 Sektoren = 32 LBA-Adressen * 4 Bytes = 128 Bytes) in's RAM kopiert
und der Bootloader angesprungen. Dieser muß dann nur die readSector(ulong
lba)-Funktion enthalten, 32 Sektoren lesen und flashen - das kriege ich
locker in C im Bootloader unter. Über das Flashen der Bootloader-Sektion
mache ich mir dann später Gedanken, wenn das überhaupt noch nötig ist: ein
einfachs readSector() wird man wohl nicht so oft updaten müssen ;O)

Das Ganze hat nur einen Nachteil: ist die Firmware beschädigt, geht das
Update nicht mehr. Dafür könnte man aber natürlich dann mal ein Kabel
anschließen.

Sebastian

Re: AVR-Bootloader =?ISO-8859-1?Q?f=FCr?= CF?

Quoted text here. Click to load it

Erstmal mußt Du wissen, wo die Datei anfängt - dazu mußt Du schonmal das
Directory lesen. Im Directory sind nur Cluster hinterlegt - also mußt Du
auch die FAT lesen - damit brauchst Du alle FAT- und Directory-Funktionen
schon, um den Dateianfang zu finden. Ob die Datei dann noch sequentiell ist
oder auf zufällige Cluster verstreut liegt, macht dann nicht mehr viel aus.

Sebastian

Re: AVR-Bootloader für CF?
Quoted text here. Click to load it

Falsch! Das ist ein weit verbreiteter Irrtum. Der ganze sog. Memory
Mapped Mode einer CF bezieht sich aleine auf die Register zur
programierung der Karte. Du musst in jedem Fall Code haben welcher
einen Sektor liest. Wahlfreier zugriff auf Sektordaten ist nicht im
Adressraum der CF zu haben. D.h. die Daten auf die zugegriffen werden
sollen müssen zuerst in's Ram - oder in anderen Worten die CF hat nur
ein 8 oder 16 bit breites Datenregister! Es gibt noch den Trick mit
der Adressleitung 10, aber dort geht es nur darum
Memoryblockverschiebeoperationen des Hostprozessors zu unterstützen
indem die CF bei gesetzter A10 Leitung alle anderen Adressleitungen
ignoriert und somit automatisch Adressse 0 addressiert (das
Datenregister)

HTH

Markus

Site Timeline