AVR-Bootloader für CF?

[Holger Klabunde]

Moin,

Ich weiß nicht, ob es einfacher ist dem AVR gleich das FAT-ten
beizubringen, oder ersteinmal eine Software für den PC zu schreiben, die
die CF sektorweise beschreibt....

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

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

 

[Holger Klabunde]

Hi

Wenn man gröbere Abläufe oder auch so komplexe Sachen wie FAT-Zugriff
und aufwendige Menüstrukturen für das Human-Interface schreiben muss,
dann ist das in C allemal schneller. Das gebe ich gerne zu.

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.

Ich denke eine optimale Lösung kommt immer dann heraus, wenn
Hochsprachenverfechter und HardcoreAssembler sich zusammensetzten und
ein Projekt in vernünftige Häppchen für jeden teilen. Da ich momentan
noch keine Kollegen dieser Art habe, lerne ich nun C für uCs.

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

 

[Ulrich Prinz]

Sebastian Voitzsch wrote:

Ulrich Prinz wrote:


Ich weiß nicht, ob es einfacher ist dem AVR gleich das FAT-ten
beizubringen, oder ersteinmal eine Software für den PC zu schreiben, die
die CF sektorweise beschreibt....


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

Sebastian
OKi, wusste nicht, dass du Linux einsetzt Dann ist es absolut kein

Problem

Gruß

--
Ulrich Prinz
----------------------------------------------------
"But befor you connect, be advised:
you are plugging into the supply from hell."
Datasheet LTC1625, Automotive Considerations, Linear Tech.

 

[Ulrich Prinz]

Colin wrote:

Habt ihr schonmal an die LILO methode gedacht? LILO hat keine Ahnung
von FAT, ext2 o. ä. sondern merkt sich einfach den Sektor wo der
Kernel liegt und ließt den einfach raus, GRUB hingegen 'kennt' die
Pappenheimer.

Korrigiert mich wenn ich da was falsch verstanden hab .

Du könntest ja in die ersten 2 Byte der Datei die Länge hinterlegen
(ich weiß, Pfusch), dann kannst du dir deine FAT Behandlung sparen.
Wenn du mit Windows die Datei allerdings änderst (besser:
verschiebst/löschst) wird sie sehr wahrscheinlich fragmentiert oder
verschoben.

Mfg,

Colin

Hallo Colin!

Deine Verfahren basieren auf der Tatsache, dass der Bootloadr mit 512
Bytes, also 1 Sektor auskommt. In diesen Sektor kann der FAT-Loader
geschrieben werden.
Dieses Verfahren setzte ich bei Controllern ein, die RAM haben und Code
aus diesem RAM auführen können. Also ersten Sektor ins RAM laden und
starten, der lädt dann das 'FLASH-DOS' und das wiederum die Datei
FIRMWARE.BIN. Und das FLASH-DOS flasht dann.

Dieses Bootstrapping geht beim AVR aber nicht. Ich muss entweder meine
Firmware so auf der CF unterbringen, dass ich die Sektoren sequenziell
lesen kann. Die Idee, das in der Firmware vorhandene FAT-System
auszunutzen um sich die Sektortabelle zu laden, und dann im Bootloader
nur noch das Read-Sektor, Flash-Sektor anhand er Tabelle durchzuführen,
finde ich die genialste Lösung. Damit kann ich auch das FAT-System
selber erneuern, da es ja nicht mehr genutzt wird. Ein Read-Sektor kann
in den 1k Bootloader sicher noch hineingepresst werden. Das Write-Sector
ist ja schon drinn.

Gruß

--
Ulrich Prinz
----------------------------------------------------
"But befor you connect, be advised:
you are plugging into the supply from hell."
Datasheet LTC1625, Automotive Considerations, Linear Tech.

 

[Holger Petersen]

Ulrich Prinz <uprinz2@netscape.net> writes:

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

OKi, wusste nicht, dass du Linux einsetzt Dann ist es absolut kein
Problem

Das Programm "dd" gab es schon, bevor Linus in die Schule ging
Und es gibt auch etliche Versionen davon für DOS und Windows.
Allerdings ist die obige Output-Device-Angabe "/dev/hda" durchaus
ein Zeichen für _einige_ unixoide Systeme - oder Laufzeitumgebungen,
die sowas simulieren. in (free-) BDS ist das IIRC schon anders, oder?

Gruss, Holger

--
Absichtlich angefügt:
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer

 

[Sebastian Voitzsch]

Colin wrote:

Habt ihr schonmal an die LILO methode gedacht? LILO hat keine Ahnung
von FAT, ext2 o. ä. sondern merkt sich einfach den Sektor wo der
Kernel liegt und ließt den einfach raus, GRUB hingegen 'kennt' die
Pappenheimer.

Korrigiert mich wenn ich da was falsch verstanden hab .

Du könntest ja in die ersten 2 Byte der Datei die Länge hinterlegen
(ich weiß, Pfusch), dann kannst du dir deine FAT Behandlung sparen.
Wenn du mit Windows die Datei allerdings änderst (besser:
verschiebst/löschst) wird sie sehr wahrscheinlich fragmentiert oder
verschoben.

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

 

[Ulrich Prinz]

Holger Petersen wrote:

Ulrich Prinz <uprinz2@netscape.net> writes:


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


OKi, wusste nicht, dass du Linux einsetzt Dann ist es absolut kein
Problem


Das Programm "dd" gab es schon, bevor Linus in die Schule ging
Und es gibt auch etliche Versionen davon für DOS und Windows.
Allerdings ist die obige Output-Device-Angabe "/dev/hda" durchaus
ein Zeichen für _einige_ unixoide Systeme - oder Laufzeitumgebungen,
die sowas simulieren. in (free-) BDS ist das IIRC schon anders, oder?

Gruss, Holger

Keine Ahnung, ich setzte nur DOS/WIN/Linux ein. Aber Du hast recht DD

ist schon auf alten Mainframes und anderen raumfüllenden Rechnern und
deren Betriebssystemen ein gängiger Begriff.

Gruß

Ps. Habe meine PDP11/730 und PDP11/710 sammt Platten schon vor (zu)
langer Zeit einem Computermuseum gespendet.

--
Ulrich Prinz
----------------------------------------------------
"But befor you connect, be advised:
you are plugging into the supply from hell."
Datasheet LTC1625, Automotive Considerations, Linear Tech.