mikrocontroller.net

Forum: Projekte & Code SD/MMC Card Bootloader (passt in 2kb bootsection)


Autor: Nik Bamert (nikbamert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Gesperrt durch Moderator
Autor: Nik Bamert (nikbamert)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
..Anhang vergessen..

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Nik Bamert (nikbamert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...
vbr_start = buffer[454]; 
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

Autor: Nik Bamert (nikbamert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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





Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin!

Hab mir gerade was zusammengedacht:

Man könnte im Hauptprogramm folgendes definieren:
typedef struct
{
  char sid[8];
  uint16_t version;
  uint16_t crc;
} bootldrid_t;

#define SWVERSION 0x0105

const bootldrid_t bootldrid __attribute__ ((section (".bootldrid"))) = {{'M', 'E', 'I', 'N', 'T', 'E', 'I', 'L'}, SWVERSION, 0};

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

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Nik Bamert (nikbamert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Nik Bamert (nikbamert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Wert = *((uint32_t *)&buffer[EntryOffset+28]);
files.size =(( Wert & 0xff000000) >> 24) | ((Wert & 0x000000ff) << 24) | ((Wert & 0x00ff0000) >> 8) | ((Wert & 0x0000ff00) << 8);

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

Autor: ich&er (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Iller (iller101)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
naja, also die Einschränkung das die Datei nicht Fragmentiert sein darf 
ist schon nicht gerade toll, aber sonst interessant.

CA

Autor: Nik Bamert (nikbamert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welches dickes Buch hast denn dir da geleistet ?

Autor: Nik Bamert (nikbamert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"TCP/IP" von W. Richard Stevens :) Bin aber noch lange nicht durch.

Autor: Hansi Lein (fabian87)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Nik Bamert (nikbamert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rai (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 !

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Nik Bamert (nikbamert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.