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
..Anhang vergessen..
Gast
#439372
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 | |
2 | |
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...
Gast
#439494
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
Gast
#439883
Moin! Hab mir gerade was zusammengedacht: Man könnte im Hauptprogramm folgendes definieren:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
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
Gast
#440095
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
Gast
#441157
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.
1 | |
2 | |
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
Gast
#441740
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.htm http://home.teleport.com/~brainy/fat32.htm http://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
naja, also die Einschränkung das die Datei nicht Fragmentiert sein darf ist schon nicht gerade toll, aber sonst interessant. CA
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 ...
Welches dickes Buch hast denn dir da geleistet ?
"TCP/IP" von W. Richard Stevens :) Bin aber noch lange nicht durch.
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
Gast
#467108
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 !
Gast
#539691
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