Hi,
habe hier einen kleinen Bootloader geschrieben, der sich das Firmware
Update von einer SD oder MMC Karte holt. Er basiert auf den mmc Routinen
von Stefan Seegal(auch hier in der Codesammlung). Läuft also eine Karte
mit seinem Code, so sollte auch mein Bootloader funktionieren.
Features
• Unterstützung von SD / MMC Karten
• FAT32 als Filesystem
• passt in eine 1024 Word (2048Byte) Bootsection,
• liest binary Files (keine intelhex!!)
Todo
• Eine Art Datumscheck, damit bei eingelegter Karte
und bereits aktualisierter Firmware nicht bei jedem
Controllerreset das Flash wieder neu beschrieben wird.
Alle weiteren Datails im Doku-pdf in meinem Anhang.
Nik
Hi Nik!
Freut mich dass du meinen Code für Dein Bootloaderprojekt verwendet
hast, auch wenn ich "Seegel", nicht "Seegal" heiße ;-).
Ähnliches hatte ich mir auch mal geschrieben, allerdings nicht so
kompakt, weil noch eine LCD Routine etc. mit eingebaut war. Vielleicht
hier noch ein paar Tips:
Ich würde anstatt FAT32 lieber FAT16 nehmen, weil die meisten Karten die
man kauft im Auslieferungszustand so formatiert sind. Formatiert man
eine Karte mit FAT32, gibt's oft/manchmal Probleme mit Digitalkameras
und anderen Geräten, die dieses Format nicht lesen/schreiben können.
Du gehst davon aus dass in Sektor 0 der Karte ein VBR (Volume Boot
Record) liegt. Allerdings kann an der Stelle auch ein MBR (Master Boot
Record) stehen, obgleich standardmäßig SD Karten einen VBR am Anfang
enthalten. Ich selbst hab mir einige Karten "umpartioniert", also einen
MBR in Sektor erstellt und dann mehrere Partionen auf die SD gemacht.
Das ganze diente dazu dass ich einen Teil der Karte mit FAT16 am PC
lesen und schreiben kann, und einen anderen Teil der Karte als
"propietären" Speicher am µC verwenden kann.
Wegen der Versionserkennung:
Eine Möglichkeit wäre es, einfach die Versionnummer in den Dateinamen zu
hängen, z.B. "kasten-sw1.5.bin". Zum Thema lange Dateinamen hab ich auch
mal was in der Codesammlung hinterlassen (vfat), aber damit wird's
warscheinlich nicht mehr in den Bootloader passen.
Noch eine andere Möglichkeit (für selbige hatte ich mich entschieden):
Man schreibt die Versionsnummer, z.B. 2 Bytes, an eine feste Stelle im
Flash, idealerweise an die beiden letzten Bytes bevor der Bootloader
anfängt. Diese Versionnummer ist dann natürlich auch in der .bin Datei
an einer festen Stelle enthalten, so dass der Bootloader die
Versionnummer abgleichen kann. Wenn 0xFF 0xFF im Flash steht handelt es
sich um einen frischen µC (oder Bootloader neu geflasht), sodass ebenso
ein Update durchgeführt wird. Ich hatte mir zusätzlich noch ein PC Tool
geschrieben, dass hinten an die bin Datei für jede Page eine Prüfsumme
(CRC) anhängt, so dass der Bootloader überprüfen kann, ob die Daten in
Ordnung sind. Dieses PC-Tool wird gleich vom makefile aus aufgerufen, so
dass man gleich nach dem make Aufruf die fertige Datei zum Updaten hat.
Weiterhin habe ich dann die CRC über die ganze Datei berechnet und im
Eeprom abgelegt. Der Bootloader überprüft dann kurz vor dem Start des
Hauptprogramms das Flash und vergleicht die CRC mit der im Eeprom
hinterlegten und startet nur dann wenn die beiden übereinstimmen.
Noch eine kleine (kleinliche) Anmerkung zum PDF: Die Dateien heißen
nicht mmc_init.h und mmc_init.c, sondern mmb_lib.h und mmc_lib.c.
Lizenzbedienungen hab ich in der Tat keine reingeschrieben, sollte ich
vielleicht noch nachholen, wird aber Deiner Lizenz gleichen.
Grüße und viel Spaß
Stefan
Hi Stefan,
da kommt mal wieder raus was passiert wenn man mitten in der Nacht
arbeitet&postet, erstens habe ich deinen Namen falsch geschrieben und
dann auch noch die beiden Dateien..eieiei..Merkwürdigerweise ist der
Link um einen Beitrag zu bearbeiten irgendwie verschwunden (?)
>Ich würde anstatt FAT32 lieber FAT16 nehmen
Eigentlich wollte ich das auch, denn eben gerade meine Digitalkamera hat
auch gleich immer auf FAT16 formatiert...allerdings konnte ich leider
nur diese im Web kursierende "fatgen103.doc" Fat32 Specs finden,
allerdings nichts entsprechendes für fat16 :(. Werde ich aber gerne
einbauen, wenn ich mal an ein gutes Dokument über fat16 rankomme.. :P
>Du gehst davon aus dass in Sektor 0 der Karte ein VBR>(Volume BootRecord) liegt.
Ich lese den MBR zwar schon aus, aber nicht ganz so, wie man es
eigentlich sollte...
1
vbr_start=buffer[454];
2
FAT_ReadSector(vbr_start);
Ich hole bloss das LSB der LBA adresse der ersten Partition, liegt der
VolumeBootRecord also in einem Sektor >255, dann klappts nicht.
Wegen der Versionserkennung wollte ich das eben ursprünglich so machen,
dass man sich als User möglichst wenig Gedanken darum machen muss, wie
man die Datei nun nennen muss, damit das Update durchgeführt wird.
Ich dachte deshalb daran, dass einfach die 2 Bytes des modified-Datums
ins eeprom gespeichert werden und dann jeweils darauf überprüft wird, ob
auf der Karte ein File mit einem anderen Datum drauf ist. Dies ans Ende
des Bootloaders ins Flash zu speichern wäre natürlich noch besser, aber
wie stelle ich das an, dass sich der Bootloader quasi selbst beschreiben
kann?
Und bezüglich der CRC Überprüfung: Wie oft kommt es vor, dass Deine
Überprüfungsroutine im Bootloader tatsächlich einen Fehler findet?
Ich möchte eben noch einiges einbauen, nur muss ich mir überlegen was
davon am wichtigsten ist, da definitv nicht mehr alles Platz findet.
+100%-ig korrekte Auswertung des MBR
+Fat16 statt fat32
+Datumsüberprüfung (oder andere Möglichkeit um neue Firmware zu
erkennen)
+ evtl. CRC Check o.ä.
nun, das wäre meine persönliche Wishlist, allerdings sind schon
1926/2048 Bytes voll... :-(
>Lizenzbedienungen hab ich in der Tat keine reingeschrieben,>sollte ich vielleicht noch nachholen, wird aber Deiner Lizenz>gleichen.
Einfach mir auch noch zusenden oder hier posten, dann aktualisiere ich
die mmc_init.c und das PDF natürlich auch noch ;)
Grüsse
Nik
gibts ja nicht, sollte natürlich heissen :
"dann aktualisiere ich die mmc_lib.c und das PDF natürlich auch noch ;)"
Keine Ahnung weshalb ich immer mmc_init schreibe...
Hi Nik!
>Ich lese den MBR zwar schon aus, aber nicht ganz so, wie man es>eigentlich sollte...
Vorsicht, eine "normale" Karte aus dem Laden raus hat überhaupt keinen
MBR, sondern nur einen VBR in Sektor 0!
Hier ist mal ein Link in dem der Aufbau des MBR und VBR beschrieben ist:
http://www.cc5x.de/MMC/FAT.html
Noch was:
http://www.master-boot-record.de/
Zu FAT16 sollte soch mit Google mehr als genug finden lassen,
funktioniert genauso wie FAT32, nur dass eben die Einträge in der FAT
nicht 32 sondern 16bit groß sind. Notfalls kannst du mal aus der
Codesammlung meine vfat Implementierung rausziehen, da ist FAT12, FAT16
und FAT32 ausimplementiert.
>Wegen der Versionserkennung wollte ich das eben ursprünglich so machen,>dass man sich als User möglichst wenig Gedanken darum machen muss, wie>man die Datei nun nennen muss, damit das Update durchgeführt wird.
Ganz genau. Und aus diesem Grund würde ich das Dateiformat der
Updatedateien noch etwas erweitern, sonst würde der Bootloader blind
jede Datei (vielleicht von anderen Geräten etc.) in das Flash schreiben.
Das kann man z.B. machen in dem man an die bin Datei hinten dran eine
Art "Hundemarke" schreibt, und für jeden Gerätetyp eine solche vergibt.
Diese könnte dann im Bootloader stehen und beim Update zunächst mir der
Datei verglichen werden.
>Und bezüglich der CRC Überprüfung: Wie oft kommt es vor, dass Deine>Überprüfungsroutine im Bootloader tatsächlich einen Fehler findet?
Bisher hat sie noch keinen Fehler gefunden, aber ich lege in der
Hinsicht schon ein bischen Wert auf Funktionssicherheit. Wenn irgendein
Byte umkippt kann der Controller die tollsten Sachen fabrizieren.
>Ich dachte deshalb daran, dass einfach die 2 Bytes des modified-Datums>ins eeprom gespeichert werden und dann jeweils darauf überprüft wird, ob>auf der Karte ein File mit einem anderen Datum drauf ist. Dies ans Ende>des Bootloaders ins Flash zu speichern wäre natürlich noch besser, aber>wie stelle ich das an, dass sich der Bootloader quasi selbst beschreiben>kann?
Das Dateidatum das im Directory auf der MMC gespeichert ist würde ich
lieber nicht heranziehen, das ist etwas unsicher (wenn man z.B. die
Datei irgend rumkopiert kann es sein dass das Datum aktualisiert wird).
Der Bootloader muss sich nicht selbst überschreiben, die Versionkennung
macht man idealerweise kurz vor den Bootloader (mit einer Section im
Hauptprogramm). Dann ist dem Bootloader bekannt wo die Versionkennung im
Flash und in der Datei liegt und kann diese vergleichen. Im Übrigen
könnte man die oben genannte Hundemarke (z.B. 8 Bytes) gleich in die
selbe Section legen und mit vergleichen: Hundemarke muss übereinstimmen
und Versionnummer in der Datei muss größer sein als im Flash. Der
Bootloader müsste dann nur alle Dateien auf der Karte durchgehen,
nachsehen ob die Dateigröße, die Hundemarke und die Versionsnummer passt
und dann flashen.
Gruß
Stefan
Im makefile dann noch
LDFLAGS += -Wl,--section-start=.bootldrid=0x1DFF4
eintragen.
Nach dem Erzeugen des Hauptprogramms muss man eben noch mit einem
Hexeditor ganz am Ende die richtige CRC eintragen, oder ein kleines Tool
schreiben das das ganze beim Aufruf von make automatisch erledigt.
Der Bootloader geht dann alle Dateien im Directory durch und untersucht
von allen die exakt so groß sind wie der Flash (-Bootloadergröße) die
Hundemarke (sid), welche ebenfalls im Bootloader hinterlegt ist, auf
Übereinstimmung. Dann noch eben merken welche Datei die größte
Versionnummer hat und größer als die momentane ist und das Flash
beschreiben. Bevor dann das Hauptprogramm gestartet wird, wird noch die
CRC geprüft.
So kann man das ganze recht universell für verschiedene Projekte
verwenden und muss sich keine Sorgen machen dass man das richtige Update
in das richtige Gerät einspielt.
Gruß
Stefan
Ich wuerde auch empfehlen FAT12 zu unterstuetzen. Das kann man bei
Karten finden die bis zu 16MB gross sind, gerade die sind ja nur
noch zum basteln zu gebrauchen.
Ausserdem wuerde ich nicht empfehlen feste Annahmen ueber
Clustergroessen, Positionen usw. zu machen. Das muss man sich alles aus
den Angaben im MBR berechnen. Sonst faellt man auf die Nase, je nachdem
womit formatiert wurde.
Und es ist auch keinesfalls so das alle Karten Superfloppy sind. Man
kann auch problemlos auf Karten stossen die einen MBR haben. Das neueste
was
mir jetzt untergekommen ist war uebrigens eine neue 128MB MMC Karte mit
MBR und FAT16 Win95LBA Partition.
Wenn man uebrigens nicht genau weiss was man da hat heisst die Antwort,
wie so oft, Linux. Das fdisk von Linux zeigt einem alles an und erlaubt
einem auch alles. Zum Beispiel auch eine SD-Karte mit gesetztem Bootflag
im MBR. WinXP verbietet letzteres leider aus reiner Bossheit.
Olaf
Hi,
langsam glaube ich, ich begreife wie du das genau meinst mit der
Hundemarke... ;)
Dein Beispiel wäre mit --section-start=.bootldrid=0x1DFF4
also auf einen Atmega mit 128kb Flash und 8kb Bootsection angepasst, so
dass die Struct gerade vor dem Bootloader zu liegen kommt?
Demnach wäre das Hauptprogramm auch immer gleich gross, der Zwischenraum
vom eigentlichen Programmende bis zur Struct genullt(nops) nehme ich
an(?)
Eigentlich sehe ich hinter deiner Lösung nur einen Nachteil und zwar
eben die Sache mit der Abhängigkeit von einem externen Programm, das die
CRC ausrechnet, das muss für verschiedene Betriebssysteme ja immer
wieder angepasst werden. Und wenn man mal vergisst die Versionsnummer im
Hauptprogramm zu updaten dann wird ja nicht geupdatet, ausser man hat
vielleicht ein Display und der Bootloader schreibt dort dann drauf, dass
kein neues File gefunden wurde etc...
Irgendwie gefällt mir diese komfortable Variante sehr gut, nur leider
wird sie ziemlich gross und passt wohl wenn überhaupt nur in die 4kb
Section und ursprünglich wollte ich eigentlich, dass alles in der 2kb
Section patz hat, so dass man auch auf zB einem kleinen Atmega8 mp3
datenloggerchen mit Sd karte mal schnell ein Firmwareupdated durchführen
kann o.ä.
evt. Wandle ich meinen jetztigen FAT32 bootloader zuerst einmal in einen
mit FAT16 Unterstüng um, wohl aber leider ohne Checksummenüberprüfung,
dafür aber so, dass er in die 2kb Section passt.
Dann getrennt davon später die "luxus" Variante, wenn alles glatt läuft
sollte die eigentlich in der 4kb Section platz haben.
Aber damit das alles möglich ist muss ich zuerst FAT16 zum laufen
kriegen(muss erst mal wieder einen max232 ausgraben damit ich ordentlich
debuggen kann... ;) )
>Ausserdem wuerde ich nicht empfehlen feste Annahmen>ueber Clustergroessen, Positionen usw. zu machen. Das muss man sich>alles aus den Angaben im MBR berechnen. Sonst faellt man auf die Nase,>je nachdem womit formatiert wurde.
Keine Angst, das mache ich auch nicht so. Der VBR wird sowiso korrekt
ausgewertet (-> Clustergrössen etc.) Das einzige was ich dem MBR
entnehme ist der Partitionstyp & Startsektor der Partition. Nun wird in
der geuploadeten Version aber nur das LSB der Startsektoradresse
gelesen, was bedeutet, dass der VBR in einem Sektor mit Adresse <256
liegen muss.
Aber ansonsten mache ich keine "Annahmen" bezüglich irgendwelcher Werte.
Dass Karten überhaupt irgendwie formatiert sind wenn man sie kauft,
wusste ich bisher gar nicht. Alle meine gekauften Karten wurden im
Computer nicht direkt erkannt, also ab in die Digicam, formatieren und
schwupps, FAT16 mit MBR drauf... :)
Von FAT12 wollte ich mich eigentlich ursprünglich fernhalten, da die
FATTableable dort einiges schwiriger auszuwerten ist. Da mich das
Windoof Standardformatierungstool aber nicht mal eine Fat12 Partition
auf eine 16mb karte schrieben lassen will, dürfte das Ganze meinerseits
ein wenig schwer werden zu testen :(
Gruss
Nik
Hi!
>Demnach wäre das Hauptprogramm auch immer gleich gross, der Zwischenraum>vom eigentlichen Programmende bis zur Struct genullt(nops) nehme ich>an(?)
Genau!
>Eigentlich sehe ich hinter deiner Lösung nur einen Nachteil und zwar>eben die Sache mit der Abhängigkeit von einem externen Programm, das die>CRC ausrechnet, das muss für verschiedene Betriebssysteme ja immer>wieder angepasst werden.
Ja gut, da sollte man mal die Konsolenfreunde fragen, da gibt's bestimmt
was fertiges was dann die CRC einfügt. Man könnte auch einfach einen
define Schalter in den Bootloader machen ob die CRC überprüft wird oder
nicht.
>Und wenn man mal vergisst die Versionsnummer im>Hauptprogramm zu updaten dann wird ja nicht geupdatet, ausser man hat>vielleicht ein Display und der Bootloader schreibt dort dann drauf, dass>kein neues File gefunden wurde etc...
Richtig, so gehört das auch. Wenn ich vergesse die Versionnummer
hochzudrehen wird natülich nicht geupdated. Aber auch dafür lässt sich
bestimmt irgendwie ein Kniff austüfteln (irgendwelche grep und cat
Dinger, kenne mich da leider nicht so gut aus), die die Versionnummer
automatisch hochdrehen bei einem make -all.
>nur leider>wird sie ziemlich gross und passt wohl wenn überhaupt nur in die 4kb
Hmm, was ist denn an der Lösung soviel aufwendiger dass es nicht mehr in
die 2k passt ? Der Hundemarken- und Versionnummernvergleich ist relativ
trivial, und der Code für die CRC-Erzeugung sind 2 Zeilen C Code in
denen ein bischen bit-geschoben und ver-xodert wird, und wie gesagt kann
man die CRC Geschichte ja vielleicht per define deaktivieren.
>Von FAT12 wollte ich mich eigentlich ursprünglich fernhalten, da die>FATTableable dort einiges schwiriger auszuwerten ist.
Ja, würde ich auch weglassen, weil das wirklich wesentlich mehr Flash
brauchen würde. Deshalb würde ich auch vorschlagen nur FAT16 zu nehmen.
Und mal ehrlich, selbst 128MB Karten kriegt man mitlerweile für ein
Duplo hinterhergeschmissen...
Noch was anderes: Wie kann man eigentlich per Code einen MBR von einem
VBR unterscheiden ?
Gruß
Stefan
Hi!
>Hmm, was ist denn an der Lösung soviel aufwendiger dass es nicht mehr in>die 2k passt ?
Nun ja, ich dachte ehrlichgesagt der CRC Check wäre aufwendiger.. :)
Dennoch, "eine Zeile" ist ja nicht gleich "eine Zeile"
Beispielsweise habe ich vorhin kurz einige Zeilen geschrieben um die
Dateigrösse auszulesen. Ohne die beiden Zeilen ist der Code 1810 Bytes
gross.
Dieses kleine bisschen dazu und schon wurden aus den 1810 bytes Code
1918 bytes. Irgendwie finde ich 118 bytes nur um 4 bytes aus dem
speicher an eine andere stelle zu kopieren und zu 'drehen' eigentlich
ziemlich viel.(habe beim
compilieren aber die -s option drin!). Ich hoffe ja noch, dass das Ganze
schlussendlich doch noch in die 2kb section passt, aber naja, es wird
jedenfalls seeehr knapp. Ausser die Fat16 statt fat32 würde noch eine
gewisse codeersparniss mit sich bringen. Aber richtig Zeit um wieder
richtig zu Coden habe ich voraussichtlich leider erst am Wochenende
wieder :(
>Ja gut, da sollte man mal die Konsolenfreunde fragen, da gibt's bestimmt>was fertiges was dann die CRC einfügt. Man könnte auch einfach einen>define Schalter in den Bootloader machen ob die CRC überprüft wird oder>nicht.
Oder gleich selbst schreiben. Wenns ja so ein einfacher Zweizeiler ist
wie du sagst dann sollte ich das auch noch gebacken kriegen, obwohl ich
die fopen fread fwrite Funktionen noch nicht so richtig im Griff
habe.
>Richtig, so gehört das auch. Wenn ich vergesse die Versionnummer>hochzudrehen wird natülich nicht geupdated. Aber auch dafür lässt sich>bestimmt irgendwie ein Kniff austüfteln (irgendwelche grep und cat>Dinger, kenne mich da leider nicht so gut aus), die die Versionnummer>automatisch hochdrehen bei einem make -all.
Im Nachhinein muss ich sagen, dass die Sache so ja gar nicht schlecht
ist, man braucht ja nicht zwingend ein LCD, um anzuzeigen ob ein Update
gefunden wurde oder nicht. Ein Led die ein paar mal blinkt wenn etwas
gefunden wurde würde ja reichen, dann müsste man die "grep und cat
Dinger" auch nicht einbauen, davon verstehe ich nämlich auch nicht so
viel. Ausser man könnte damit vielleicht auch gerade die CRC errechnen
und anhängen.. ;)
>Noch was anderes: Wie kann man eigentlich per Code einen MBR von einem>VBR unterscheiden ?
Dazu fällt mir eigentlich nur gerade ein, dass man die Bezeichnung bei
0x36 Auslesen könnte. Bei meiner Karte steht dort im Moment "FAT 16".
Aber ob dort überhaupt immer eine Bezeichnung reingeschrieben wird,
weiss ich leider nicht.
>Und mal ehrlich, selbst 128MB Karten kriegt man mitlerweile für ein>Duplo hinterhergeschmissen...
Beim unserem Computerhändler hier gibts die gar nicht mehr zu kaufen,
das kleinste was der anbietet sind 256mb Karten für ungefähr 10€ :-D
Gruss Nik
hallo
ich habe gerade selbst eine FAT16/FAT32-Leseroutine für einen powerpc
(gelesen wird usb-massenspeicher) in C geschrieben, als grundlagen fand
ich folgende quellen sehr nützlich:
http://home.teleport.com/~brainy/fat16.htmhttp://home.teleport.com/~brainy/fat32.htmhttp://www.easeus.com/data-recovery-ebook.htm
bei letztem link kann man kostenlos ein ebook downloaden, oder sich die
sachen einfach online ansehen, die beispiele dort sind eigentlich ganz
nett illustriert...
vielleicht sucht ja mal wieder jemand solche infos,
beste grüße
hiho Nik,
wat hälst du denn davon wenn wir des ethernetboard auch mal mit mmc
ausstatten und den kleinen FAT-code in den webserver einbauen, das wäre
ja schon mal klasse :-).
CA Dirk
Hast du bei Holgi´s Brainstorming Seite schon mal geschaut?
http://www.holger-klabunde.de/avr/avrboard.htm#Fatmini
Ist für FAT12/FAT16 read only braucht allerdings 3kb
Wenn man davon CF, LCD und seriell wegläßt könnte es dann mit dem 2kb
Bootloader schaffen
Dirk Broßwick wrote:
> hiho Nik,>> wat hälst du denn davon wenn wir des ethernetboard auch mal mit mmc> ausstatten und den kleinen FAT-code in den webserver einbauen, das wäre> ja schon mal klasse :-).>> CA Dirk
Coole Idee!
Eigentlich wollte ich auch ein wenig TCP Code schreiben aber das mache
ich dann bei meinem eigenen Code noch als Erweiterung(hab mir nun so ein
richtig dickes Buch gekauft worin all die Protokolle ganz ausführlich
erklärt sind, so sollte auch ich TCP noch verwirklichen können.. )
Back to Topic, Fat16:
Bin leider noch nicht so weit das ich schon einen Code uploaden könnte,
aber ich denke mal, dass er ohne leseroutinen(also
hardwareunterstützung für mmc/sd karten) so auf 1- 1.5kb kommen dürfte.
Dabei aber bloss mit Leseunterstützung, lesen vom Rootdirectory und
standard Shortfilenames (also 8 zeichen + 3 zeichen dateiendung).
Ist aber nur mal so eine Annahme, vielleicht geht in 1.5kb ja auch noch
mehr rein :)
Selbstverständlich aber auch mit unterstützung für fragmentierte
Dateien, das geht bei meiner FAT32 lib in 3 Zeilen ...
Hey Nik, habe schon damals von deinem Atmega8 mp3 player mal erfahren :)
Wollte mich auch mit TCP/ IP beschägiten (magjack + enc) und nen mp3
stream client aufbauen. Ist das Buch, dass du dir gekauft hast gut? Oder
eher gerede um den heißen brei und sehr schwer verständlich?
Naja also ich habe es vorallem gekauft, da es auch eine deutsche Fassung
davon gibt. Die englische Fassung wurde schon beinahe als "tcp/ip
bibel" angepriesen, worauf ich mir dann gleich die ins Deutsche
übersetze Ausgabe geschnappt habe. Eigentlich bin ich sehr zufrieden
damit, allerdings habe ich auch nichts womit ich es nun vergleichen
könnte, ausser vielleicht mit den RFC's. Es ist ähnlich geschrieben,
allerdings noch mit Besipielen, Grafiken und eben in Deutsch. Dennoch,
ich würde dir nun nicht einfach empfehlen das Buch "blind" zu kaufen,
zumal es ja von Person zu Person unterschiedlich ist, ob man ein Buch
nun für leicht oder schwer verständlich hält.
Etwas (finde ich) ist aber immernoch unverzichtbar, auch wenn man so ein
Buch hat: Irgendwas in der Art wie Ethereal / Packetyzer um sich genau
ansehen zu können, was der uC so an den Computer weitersendet.
Gruss
Nik
Uuuuuaaaa, die habe ich wohl die Spezialisten für mein SD-Karten-Problem
gefunden...
Das betrifft Euch wohl nur am Rande, aber hier kurz die Vorgeschichte:
Zusammenfassung aus meiner Frage bei Pocketnavigation.de:
- >Navi PDA MD 7200 mit 2 GB-Karte "Platinum"
Im Notebook wird die Karte mit 2GB erkannt, im PDA nur mit 944 MB... Bei
Daten >1GB zeigt MD7200 zwar noch die Ordner auf der Karte an, aber
keinen Inhalt.
Jetzt kann ich von den 2GB nur 940 MB nutzen, den Rest etwa nur für
Datentransport, sagen wir von Rechner zu Rechner ?
letzte Aktionen:
im Notebook-Kartenslot auf FAT (=16) formatiert, Effekt siehe oben
im Notebook-Kartenslot auf FAT 32 formatiert, Effekt siehe oben
mit USB-Adapter auf FAT (=16) formatiert, Effekt siehe oben
mit USB-Adapter auf FAT 32 formatiert, Effekt siehe oben
Im USB-Adapter wird die SD-Karte sogar im Gerätemanager bei XP als
Wechsel-Datenträger mit Format/Größe und (einer) Partition angezeigt,
läßt sich aber nicht in zwei Partitionen trennen.
Demo-Version von PartitionMagic 8.0 runtergeladen - gleiche Situation im
USB-Adapter wie beim Gerätemanager XP, allerdings wird bei
PartitionMagic ausdrücklich darauf hingewiesen, dass zwar
USB-Festplattenlaufwerke bearbeitet werden, aber keine Karten per USB.
Demoprogramm SDFormatter.exe kann zwar formattieren, aber nicht
partitionieren.
Momentan suche ich ein Programm, mit dem wohl USB-Sticks partitioniert
werden können, nach ersten Infos zum Trennen in einen normalen und einen
zweiten, per Passwort zu schützenden Bereich/Partition (ob das auch für
ne SD-Karte geht ?).
Zitat aus einem anderen Thread:
----------------------------------------------------------
Genau, was ich aber bei meinem PNA gesehen habe ...
in der Systemsteuerung (Storage manager) kann man die SD-card
partitionieren,
d.h. 2x 1GB Partition.
Wird auch als \Storage card und \Storage Card2 angezeigt.
-----------------------------------------------------------
Frage: laut seinem Profil einen PNA470 (laut Medion-Homepage basierend
auf Windows CE 4.2), ist dann die oben genannte Funktion in der
Systemsteuerung/storage Manager eine Partitionier-Funktion eines PNA ?
Dann müsste ich doch eigentlich nur jemanden suchen, der einen solchen
PNA hat und SD-Karten formatieren kann ? (kenne in meinem Umfeld aktuell
leider noch keinen)
Kann jemand helfen ? Ich suche weiter...
.........
-> Jetzt die kurze (!) Frage an die Spezies (siehe ganz oben): geht das
überhauot ? Zwei Partitionen auf einer SD-Karte ?
Rai
Wir werden beherrscht von Sachen, die wir nicht mehr beherrschen !
Hey Nik,
was macht Dein Bootloader ? Nachdem ich letzte Woche mal akut für einen
Projekt einen genau solchen gebraucht habe, hab ich mir einen
geschrieben mit den Ideen die ich oben schonmal angesprochen hatte
(Versionsabgleich, CRC-Check, Hundemarke...)
Hier
ist das Resultat:
Beitrag "MMC/SD Bootloader füt ATMega16"
Gruß
Stefan
Hi Stefan,
irgendwie habe ich den SD Bootloader nicht so oft gebraucht, daher ist
dieses Projekt bei mir ein bisschen in Vergessenheit geraten. Bin im
Moment immer noch dabei die Grundlagen aus dem oben genannten Buch zu
verwirklichen, bin mit dem TCP Stack nun schon ziemlich weit. Eine
Minimalversion mit einem Webserverchen und einer kleinen Homepage hätte
in einem mega8 platz.
4kb Flash würden reichen, die 512bytes sram vom atmega48 aber nicht :-(
GEBT UNS MEHR SRAM ATMEL!! :-))))))
Zum Bootloader: Ich habe einmal noch FAT16 implementiert und die Fat
Funktionen ein bisschen praktischer gemacht (so dass man ganz einfach
den Hardware Treiber ändern kann, also z.B. von einer HDD statt von der
SD Karte zu lesen). Aber viel am Komfort des eigentlichen Bootloaders
ändert das nicht, daher werde ich bei Gelegenheit gerne mal deinen
ausprobieren, der passt ja ebenfalls noch in die 1kWord Bootsection :-P
Gruss
Nik
Thread beobachten
Seitenaufteilung abschalten