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

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.

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

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

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

Moin,

welchen AVR benutzt du eigentlich ?

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

Pardon me. Es ist ein ATmega 162L (16k Flash, 1k RAM).

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?

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

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.

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

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

Sebastian

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.

Ich werde das wohl ausprobieren müssen.

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

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

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

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

Moin,

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

Gruß Holger

Hi

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.

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

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