mikrocontroller.net

Forum: Projekte & Code MMC/SD Bootloader füt ATMega16


Autor: Stefan Seegel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

im Anhang findet sich ein Bootloader, der seine Updates von einer MMC/SD 
Karte bezieht. Der Bootloader passt knapp in 2kB, so dass der Bootloader 
vom Mega8 bis zu den Großen verwendet werden kann.

Ausstattung:
- Unterstützung für FAT16 (Partitionstyp 0x06)
- Überprüfung der "Geräte-ID", so dass automatisch die richtige Datei, 
und nur diese, von der Karte geladen wird
- Überprüfung der Versionkennung, so dass nur aktualisiert wird wenn 
eine neuere Software auf der Karte vorhanden ist
- CRC Überprüfung; das Hauptprogramm wird nur dann gestartet, wenn die 
CRC (befindet sich in den letzten beiden Bytes des Hauptprogrammes) 
korrekt ist.

Einschränkungen:
- Auf der Karte muss ein MBR vorhanden sein, und es wird nur die erste 
Partition überprüft (meine letzten 3 Karten die ich gekauft habe waren 
bereits so eingerichtet mit FAT16 Partition). Ggf. selber einen MBR auf 
die Karte schreiben

Beschreibung:
Im Bootloader wird eine Gerätekennng (DEVID) im makefile definiert. Für 
jedes Gerät sollte eine eigene Kennung vergeben werden.
Im Hauptprogramm wird diese Gerätekennung, die Softwareversionsnummer 
und 2 leere Bytes, in die später die CRC kommt, über eine Section ans 
Ende des Hauptprogramms geschrieben.
Nach dem erzeugen des Hauptprogramms muss noch mit dem ebenfalls 
beiliegenden Tool "crcgen" die CRC in die hex-Datei geschrieben werden.
Nun wird noch die hex-Datei auf eine MMC kopiert (Dateiname egal) und 
fertig. Der Bootloader erkennt dann an der Dateigröße und der DEVID dass 
es sich um ein Update für dieses Gerät handelt. Nachdem die 
Versionsnummer (im Makefile des Hauptprogramms hinterlegt) überprüft 
wurde beginnt der Updatevorgang. Anschließend wird noch die CRC im Flash 
überprüft und das Hauptprogramm gestartet.


Zu tun:
Der Bootloader passt derzeit ganz knapp in 2 kB, für ein paar 
Statusausgaben (Display, LEDs, etc) ist kein Platz mehr. Vielleicht 
könnte sich jemand den Code ansehen der mehr von "effizientem 
Programmieren" versteht als ich, und noch das ein oder andere Byte 
herauskitzeln.


So, dann viel Spaß beim Testen,

Stefan

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieht gut aus! (sehr flüchtig draufgeguckt)

Ich brauche zwar keinen solchen Bootloader, aber kann mir vielleicht was 
für meinen abgucken. ;-)

Zum Thema unter gcc kleiner kriegen siehe hier:
Beitrag "Tricks, wie ich mein Compilat kleiner kriege"

Bin noch nich ganz durch damit, werde bestimmt noch was ergänzen, aber 
besonders die "umstrittenen" -mint8 und -mtiny-stack bringen viel.

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eins fällt mir doch noch auf:
In deinem .lss File sieht man, daß du dir die Bibliotheksfunktion 
udivmodsi4 "eingefangen" hast, eine allgemeine Division. Die ist recht 
teuer.
Sie wird 2 mal benutzt:
Einmal in fat16_readfilesector für Teilen durch SectorsPerCluster. 
Versuch' da vorher einen Zweierexponenten draus zu gewinnen, dann ist 
hier ein Rechtsschieben möglich.
Das zweite Mal ein paar Zeilen tiefer, ich durchschaue aber nicht warum.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Danke für die Tips, bin nun schon auf 1976 Bytes unten, vorher waren es 
etwa 2040.
Das mit der Division muss ich mir mal genauer ansehen...

Stefan

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kleine Anmerkung, habe ich gerade rausgefunden:
<avr/boot.h> ist nicht ganz -mint8 fest. Der Check
 #elif (FLASHEND > USHRT_MAX) 
tut nicht mehr das gewünschte, weil USHRT_MAX sich halbiert. An dieser 
Stelle sollte besser UINT16_MAX stehen. Mal sehen, ob ich den Autor 
ausfindig machen kann.
Als Abhilfe kann man die internen __boot_page_XXX_normal Funktionen 
direkt verwenden. (Oder die jeweils anderen, je nach Controller)

Autor: Stefan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So,

wie nicht anders zu erwarten, hier schon mal eine neue Version. Der 
Bootloader ist nun 1952 Bytes groß, und es ist noch ein neues, äußerst 
informatives Merkmal hinzugekommen: Oben in main.c kann man einen 
Portpin definieren, an der eine Led angeschlossen ist. Die LED wird 
aktiviert, sobald der Bootloader startet und die MMC Karte durchsucht 
wird. Wird ein passendes Update gefunden, wird selbiges installiert, 
währenddessen die Led flackert. Nach diesem Vorgang wird der CRC-Test im 
Applikationsbereich durchgeführt. Verläuft der Test positiv verlischt 
die Led und das Hauptprogramm wird gestartet. Andernfalls bleibt die Led 
aktiv und der Bootloader hält an. So wird verhindert dass eine 
fehlerhafte Applikation gestartet wird, und man hat eine direkte 
Rückkopplung, wie der Aktualisierungsvorgang verlief.

Ausblick:
Evtl. könnte man Pin 3 des 10-pin ISP Steckers misbrauchen und auf 
diesen z.B. den SS Pin auflegen. Dadurch wäre es möglich, eine MMC-Karte 
direkt an den ISP Header anzuschließen, zumindest bei den Prozessoren 
deren MISO/MOSI Pins gleichzeitig für ISP und SPI verwendet werden (z.B. 
Mega16).
Mal sehen, evtl. entwickle ich bei Gelegenheit ein kleines 
Adapterplatinchen auf der der MMC-Sockel, ein 3.3 V Spannungsregler, die 
Spannungsteiler und ein 10-pin Header drauf sind. So muss man nicht 
immer das Notebook zum Gerät oder das Gerät zum Rechner tragen, sondern 
schließt einfach kurz die MMC an, Reset drücken, kurz warten, fertig.

Gruß
Stefan

Autor: Robert S. (razer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

Dein Bootloader ist wirklich nicht schlecht, Kompliment!!

Eine Frage, wäre es schwer, den Bootloader auf einen Mega128 
umzuschreiben??

mfg Robert

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tach,

nein, wäre nicht schwer... Ich hatte das ganze ursprünglich für einen 
Mega128 entwickelt, weil ich aus dem Bauch heraus vermutet hatte dass 
der Bootloader mehr als 2 kB Platz braucht. Nachdem ich sah dass es 
knapp in 2 k passt, habe ich den Bootloader mit Defines etc. versehen, 
so dass er universell verwendbar ist.
Du musst im Bootloader-Makefile zunächst BOOTLOADERSTARTADR entsprechend 
setzten, je nachdem wie groß du die Bootloadersektion mit den Fusebits 
einstellst und BOOTLDRSIZE ebenfalls entsprechend anpassen. In mmc_lib.h 
müssen die Port Pins angepasst werden an denen die MMC hängt.
Im Hauptprogramm muss dann ebenfalls noch im makefile BOOTLDRSIZE und 
BOOTLDRINFOSTART angepasst werden, damit der Bootloader die 
"Hundemarke", Versionnummer und CRC finden kann.

Viel Spaß,
Stefan

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan

Du hast nur einen Buffer fat_buf. Ein Sektor ist 512 Bytes
groß. Warum also beide als Parameter übergeben ?

void mmc_read_buffer(void)
{
 unsigned char *buf;
 unsigned short len;

 buf = fat_buf;
 len= 512;

  while (len)
  {
    spi_send_byte(0xFF);
    len--;
    *buf++ = SPDR;
  }
}

Autor: holger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan

Hab mal ein bisschen rumgespielt. Aber leider nicht ausprobiert.
Nur mal was zum nachdenken ! Ein bisschen ausklammern,
ein % entsorgt. Über die Größe der Clusternummern nachdenken.

Startpunkt war 1972 Bytes mit WinAVR 3.4.6.
Rausgekommen ist 1890 Bytes.

Gut, das mit void mmc_read_buffer(void)
könnte man sich ja noch mal überlegen ;)

Gruß
 Holger

Autor: holger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Und nun steht er bei 1820 Bytes.

Autor: holger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Und jetzt komme ich auf 1716 Bytes.
Soll ich weitermachen ?

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In zwei Jahren ist er weg ;-)

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Soll ich weitermachen ?

Na ich bitte darum ! :-)

>Und jetzt komme ich auf 1716 Bytes.

Hm, mein Compiler sagt 1724, aber was soll's, trotzdem um Welten 
kleiner. Super!

Von manchen Sachen kann man zwar deren "logische Herkunft" nicht mehr so 
gut erkennen, z.B. sowas
if ((entry_num * sizeof(direntry_t) / 512) >= RootDirRegionSize)

wird ersetzt durch
if ((entry_num / 16) >= RootDirRegionSize)

, aber was solls, den Zweck das Compilat kleiner zu kriegen erfüllt es 
ja deutlich.

Also wenn noch was rauskommt, immer her damit.
Dann kann ich mir schonmal gedanken drüber machen ob/was man noch an 
sinnvollen Funktionen einbauen kann.

Bis dann,

Stefan

Ach ja, hast du auch ausprobiert ob das ganze funktioniert ? Kann das 
derzeit nicht testen, weil ich für eine Woche im Ausland bin...

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Stefan,

>Ach ja, hast du auch ausprobiert ob das ganze funktioniert ? Kann das
>derzeit nicht testen, weil ich für eine Woche im Ausland bin...

Ist bei mir noch rein theoretisch. Probiert habe ich es noch
nicht. Mach ich am Wochenende aber auf jeden Fall.

>Von manchen Sachen kann man zwar deren "logische Herkunft" nicht mehr so
>gut erkennen, z.B. sowas
>if ((entry_num * sizeof(direntry_t) / 512) >= RootDirRegionSize)
>wird ersetzt durch
>if ((entry_num / 16) >= RootDirRegionSize)

sizeof(direntry_t) ist nun mal 32. Das wirds wohl auch immer bleiben.
Deine Klammersetzung zwingt den Compiler aber erstmal
entry_num * sizeof(direntry_t)
auszurechnen und danach durch 512 zu teilen.
Selber ausrechnen ist hier der bessere Weg.

Das meiste haben die Bitschubsereien mit SectorsPerCluster
gebracht. Echte Multiplikation bzw. Division vermeiden !

Dann die Funktionsparameter nicht selbst zum rechnen zu
benutzen. Pushs und Pops im *.lss sind rapide gesunken.

Als Abschluss: die minimal benötigten Datentypen
für einen Wert einsetzen.

Und wenn man einen Bootloader wirklich klein kriegen
will muss man heilige Kühe schlachten.
Bei MMC oder FAT16 Lib-Funktionen so weit wie möglich
auf Übergabeparameter verzichten.

Mehr habe ich nicht gemacht ;)




Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hätte ich jetzt fast vergessen !

@ Werner

>In zwei Jahren ist er weg ;-)

Geh spielen. Heute darfst du mal für ne Stunde raus.

Autor: holger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Upps, schneller Bugfix :(

Autor: holger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, alles aufgebaut und getestet. Funktioniert prima.
War noch einiges an Bastelarbeiten zu erledigen:

Bei CMD1 wurde nicht lange genug gewartet (bei 16MHz).
Hab den Timeoutzähler dort entfernt. Wenn
von der Karte nix kommt fliegt sie jetzt
schon bei CMD0 raus.

Eine meiner SD Karten möchte doch glatt zwei
mmc_init() hintereinander haben.

In fat16.c kann man sich jetzt aussuchen
ob Karten mit oder ohne MBR zum Einsatz kommen.
Ohne MBR gehts unter 1700 Bytes ;)

Aufpassen: Im Anhang wird ein ATMega32 benutzt !
Hab auch die Sampleapp für ATMega32 dazugepackt.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hervorragend,

konnte es leider immer noch nicht testen, weil ich noch nicht zu Hause 
bin, werde ich aber nächste Woche tun.

Ich teste nächste Woche noch an einer kleinen Schaltung, mit der man 
eine mmc-Karte an den ISP Stecker anschließen kann. Das Problem dabei 
ist natürlich dass ein Pin (Chip Select) fehlt. Testhalber habe ich 
einfach mal CS der MMC fest auf GND gelegt. Dabei muss man nach dem 
Einschalten (Betriebsspannung) 2x, danach immer 8x Reset drücken, dass 
der Zugriff auf die MMC klappt. Mal sehen ob man das softwaretechnisch 
irgendwie gebacken kriegt. Ich denke dass das Problem in der fehlenden 
Bytesynchronisation durch CS liegt. Ich werde nächste Woche mal 
versuchen, die CS Leitung durch die Resetleitung über einen Transistor 
zu schalten. Wenn das alles klappt mach ich eine Platine, auf der ein 
MMC Sockel, die Spannungsbegrenzung /-regler, eine Resettaster, ein ISP 
10 Pin und ein ISP 6 Pin Header drauf ist. So hat man ein einfaches, 
günstiges kompaktes leicht zu handhabendes Programmiergerät. Ich muss 
z.B. immer mein Notebook mitsamt Evertool und Kabel in den Heizraum 
tragen um ein Update in meine Heizungs zu kriegen.

Noch mal zum MBR/VBR: Meinst du es ist noch möglich den Bootloader 
selber erkennen zu lassen ob ein MBR vorhanden ist oder nicht und 
entsprechend zu reagieren ?

Bis denn,
Stefan

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch was:
Ich habe ja alles bisher nur mit einem Mega 16 gtestet. hast du für 
Deinen Mega 32 auch diese CRC Erzeugungssoftware benutzt, und hat's da 
funktioniert ?

Stefan

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Noch mal zum MBR/VBR: Meinst du es ist noch möglich den Bootloader
>selber erkennen zu lassen ob ein MBR vorhanden ist oder nicht und
>entsprechend zu reagieren ?

Mit bsFileSysType könnte man das machen, bzw. habe ich das
schon mal gemacht. Da steht eigentlich immer "FAT12", "FAT16" drin.
Bei meinen Karten jedenfalls. Wenn nix
drin steht ist das natürlich Panne :(

Sektor 0 auf bsFileSysType[0]=='F' und bsFileSysType[4]=='6'
checken. Stimmen beide nicht hat man einen MBR, einen
FAT12 oder FAT32 Bootsektor vor sich. Dann einfach auf Teufel
komm raus einen MBR annehmen, und Sektor an bootsecoffset
lesen. Dort wieder bsFileSysType[0]=='F' und bsFileSysType[4]=='6'
checken. Wird wieder nix gefunden wars ne FAT12 oder FAT32
formatierte MMC/SD. Oder gar nicht formatiert.

>Ich habe ja alles bisher nur mit einem Mega 16 gtestet. hast du für
>Deinen Mega 32 auch diese CRC Erzeugungssoftware benutzt, und hat's da
>funktioniert ?

Ja, klappt prima das Proggi.

Autor: holger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe die einfache automatische MBR/VBR Erkennung für FAT16 
eingebaut.
Man hat aber immer noch die freie Wahl in fat16.c :)

// !! define only ONE of these !!
//#define USE_MBR  //if card has a master boot record, partitiontable
//#define USE_VBR  //if sector 0 is a bootsector
#define USE_MBR_VBR_AUTO //auto mode

Dann habe ich noch ein paar Übergabeparameter entsorgt
die entweder gar nicht benutzt oder als Variable
bereits global definiert wurden. Ein wenig an Schleifen rumgefummelt.

Der Lowscore mit

#define USE_MBR_VBR_AUTO //auto mode

steht jetzt bei 1678 Bytes, und es funktioniert immer noch ;)

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ihr (speziell Holger) macht ja prima Fortschritte!

Was hältst Du davon, Deine "Erfolgsrezepte" in der Wiki-Seite zu diesem 
Thread hinzuzufügen:
Beitrag "Tricks, wie ich mein Compilat kleiner kriege"
http://www.mikrocontroller.net/articles/AVR-GCC-Co...

Ich habe gesehen, das ihr -mtiny-stack verwendet, aber den Stack nicht 
wie in dem Thread gelernt auf eine glatte Page initialisiert. Damit ist 
der verbleibende Platz recht zufällig.

Die Option -mint8 wäre noch möglich, ich habe damit mittlerweile gute 
Erfahrungen gemacht, wenn man die Wirkung im Hinterkopf behält und Typen 
fester Größe auf <stdint.h> verwendet. Bringt ziemlich viel.

Unter 1 KiB wird der Code aber vermutlich nicht kommen.  :-(
Mit meinem Bootloader habe ich allerdings auch bei ca. 1600 Bytes 
angefangen, jetzt bin ich auf 1014 runter. Nach Holgers aktuellen Tricks 
muß ich nochmal Ausschau halten. Das man die Übergabeparameter besser 
nicht modifiziert (sondern Kopien davon) war mir neu.

Dank und Gruß
Jörg

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jörg

>Die Option -mint8 wäre noch möglich,

Geht nicht :( Dann kennt er RAMPZ nicht mehr !
Das brauchen wir aber halt nun mal.
An die Compiler internen Header Files trau
ich mich besser nicht ran. Wer weiss was das wieder
für Nebenwirkungen (in meinen anderen Programmen) hat.

>Das man die Übergabeparameter besser
>nicht modifiziert (sondern Kopien davon) war mir neu.

Mir auch, aber die Pushs, Pops sind erheblicher weniger
geworden ! Klappt aber irgendwie nicht immer.
Möglicherweise stimmts auch einfach nur nicht.
Vieleicht waren es doch nur die anderen Optimierungen.

@ Stefan

Können wir die CRC auch von oben nach unten berechnen ?
Bringt nochmal 6 Bytes bei Umwandlung einer for()
in eine while() Schleife ;)

Autor: holger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt gehts mit 1642 Bytes.

void flash_update(void)
erzeugte komischerweise 6 Pushs und 6 Pops.
Habs einfach in die main loop eingefügt. Pushs, Pops waren dann weg.

void fat16_readfilesector(uint16_t startcluster, uint32_t filesector)
benutzt keine absolute Sektornummer sondern eine relative
Sektornummer im File. Bei AVR/ATMega reicht da auch uint16_t ;)
void fat16_readfilesector(uint16_t startcluster, uint16_t filesector)

Statt break eine Schleife direkt mit return beendet.
Spart die Abfrage hinter der Schleife.

Ich denke das wars dann jetzt aber auch.

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Holger:

RAMPZ kenne ich als Mega8-User nicht. Keine Ahnung, warum das zum 
Problem wird. Man kann verschiedene C-Files auch mit unterschiedlichen 
Flags kompilieren, das Problem so vielleicht "auslagern".

Das mit den Übergabeparametern habe ich jetzt in meinem Bootloader 
probiert, leider kein Effekt.  :-(

CRC rückwärts geht zwar, liefert aber ein anderes Ergebnis. Müßte die 
PC-Software drauf Rücksicht nehmen. Ich vewende übrigens einen anderen 
CRC, nicht aus den WinAVR-Headern. Der erzeugt kleineren Code:
// incremental CRC
static uint16_t crc16(const uint8_t byte, uint16_t crc)
{
    uint8_t i;

    crc ^= byte;
    for (i=8; i>0; i--)        
    {                        
        if (crc & 0x0001)        
            crc = (crc >> 1) ^ 0x8408; // reverse 0x1021 poly 
        else                      
            crc >>= 1;            
    }                        
    return crc;
}

  

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
main.c: Mache die Funktion check_file() static inline. Wird nur ein mal 
aufgerufen. Spart den call und den return. Evtl. kann auch die 
Registerbelegung vom Compiler besser Optimiert werden.

dto. für wait_start_byte() in mmc_lib.c

mmc_lib.c: in mmc_start_read_block. Spart shift-loop
  adr <<= 1;
  
  cmd[0] = 0x40 + MMC_READ_SINGLE_BLOCK;
  cmd[1] = (adr & 0x00FF0000) >> 0x10;
  cmd[2] = (adr & 0x0000FF00) >> 0x08;
  cmd[3] = (adr & 0x000000FF);
  cmd[4] = 0;

Man kann sicher noch mehr "einmalig" aufgerufene Fuktionen als "static 
inline" definieren und somit den call/return sparen wenn man (Igitt) die 
anderen C Files included statt linkt.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Werner

Klasse Tipps. Code ist jetzt nur noch 1602 Bytes.
Besonders das einsparen von shifts bringts.

>dto. für wait_start_byte() in mmc_lib.c

Bringt leider nichts. Codesize unverändert. Vieleicht
besser Funktion im Code einsetzten wo sie benutzt
wird.

@ Jörg

Ich probiere auch deine CRC Routine auf jeden Fall noch aus.

Autor: holger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Zusammenfassung:

@ Jörg
Deine CRC Routine brachte zwei Bytes Ersparnis.
Dafür das PC Programm umschreiben ? Hmm naja, vieleicht
später mal.

@ Werner

#include "fat16.c"
#include "mmc_lib.c"

in main.c bringt gar nichts :(

wait_start_byte() als Code einsetzen brachte nichts.
Code wurde größer.

Da filesector sich als uint16 erwiesen hat
konnten in fat16_readfilesector() nochmal
8 Bytes rausgeholt werden.

Stand der Dinge ist nun 1596 Bytes.

Noch jemand ne Idee ?

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
N'abend!

Hab gerade mal Deine letzte Version ausprobiert. Leider funktioniert der 
Bootloader hier garnicht mehr :-( Wenn ich den Mega 16 zurücklese 
stimmen die ersten 1024 Bytes mit der Updatedatei überein, aber danach 
steht "Müll" anstatt 0en drin. Werde mal suchen woran das liegt...

Gruß
Stefan

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
man kann noch ca. 60 bytes sparen wenn man auf ISR's verzichtet, den GCC 
Startup Code, den GCC bad_interrupt_vector entfernt und function main() 
direkt am Reset Einsprung des Bootloaders platziert. Alle globalen 
Variablen die initialisiert werden müssen (auf 0) muß man dann von Hand 
initialisieren.

So mache ich dies bei meinem ATMega8 Bootloader (ähnlich AVR910) der 
ohne Assembler (also pures C) zu benutzen in 256 Words reinpasst.

Gruß Hagen

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan

Also der Bootloader funktioniert bei mir noch.
Das per Bootloader geladene Programm auch, aber
du hast recht. Der Bereich bis Flashend ist nicht 0. Da wiederholt
sich immer wieder irgend ein Müll.

Autor: holger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, jetzt klappt es bei mir wieder
und die Daten hinter dem Testprogramm
sind wieder alle 0.

Es lag am einfügen von flash_update()
in die main loop. Sorry :(

1618 Bytes ist ja auch nicht schlecht.

Autor: holger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mein letzter Stand ist jetzt 1580 Bytes.

Inhalt vom ATmega nachdem der Bootloader geflasht hat
natürlich ausgelesen und angesehen. Das Testprogramm läuft.

Bis hier hin klappts.



Autor: Stefan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Fein!

Nachdem ihr nun soviel Platz geschaffen habt, habe ich selbigen genutzt:
Der Bootloader unterstützt nun FAT16 und FAT12, so dass auch ältere, 
kleine Karten, die eigentlich für fast nichts anderes mehr genutzt 
werden können, verwendet werden können. Selbst wenn man per Hand auf 
einer 16 MB Karte eine FAT16 Partition erstellt, baut Windows diese beim 
Formatieren in eine FAT12 Partition um, so dass kleine Karten bisher 
nicht verwendet werden konnten.

Weiterhin ist es nun möglich, des CS Pin der Karte fest auf GND zu 
legen, so dass man eine Karte bei bestehenden Schaltungen einfach an den 
ISP Stecker anschließen kann (bei 5 V Systemen natürlich mit weiterhin 
mit Pegelanpassung dazwischen). Ich werde demnächst wie schon angedroht 
eine kleine Platine fertig machen, auf der ein Kartensockel, ISP 6 Pin, 
ISP 10 Pin, Resetknopf und Pegelwandler vorhanden ist.

Viel Spaß

Stefan

P.S. Den Bootloader im Anhang habe ich mit einer 512 MB Karte FAT16 mit 
MBR, mit einer 16 MB Karte FAT12 mit MBR und einer 16 MB Karte FAT12 
ohne MBR erfolgreich getestet.

Autor: Jürgen C (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,
das Projekt ist genau was ich suche
(Beitrag "Bootloader für Mega 128 mit SD Karte")
Wärst Du bereit mir eine Version für den MEGA 128 mit einer kurzen
Installationsanleitung zu erstellen?
Bei Interesse könnten wir uns über weiter Details unterhalten.
Meine Anwendung ist ein Hobbyprojekt, deshalb brauchst Du Dir über 
Gewährleistung und Dergleichen keine Gedanken machen. Funktionieren 
sollte
es aber schon.

Viele Grüße

Jürgen

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab' mal eben aus dem Projekt einen kleinen Artikel gemacht:

http://www.mikrocontroller.net/articles/MMC/SD_Boo...

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jürgen,

Deiner Anfrage unter dem angegebenen Link entnehme ich, dass du Bascom 
benutzt. Ich weiß leider nicht ob und wie man damit Memory-Sections 
erstellen kann, denn das ist für das Hauptprogramm zwingend 
erforderlich.
Den Bootloader für den Mega128 könnte ich Dir schon kompilieren, kann 
ihn aber nicht testen, weil ich für mein STK500 nicht diesen 
Adaptersockel für den Mega128 habe.

Gruß
Stefan

Autor: Jürgen C (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

vielen Dank für Deine Hilfsbereitschaft.
Leider finde ich in Bascom keine Möglichkeit an
einer bestimten Adresse eine Memory-Sections zu erstellen.
Ich könnte aber die erforderlichen Daten von Hand an der
entsprechenden Stelle eintragen.
Zum Testen wäre es einfacher, wenn der Bootloader auch Versionsnummer
gleich der bereits installierten Version akzeptieren würde.
Wenn es dir nicht zu viel Mühe bereitet, könnten wir ja mal einen
Versuch machen.
Als Funktionsanzeige wäre bei mir der PORTB.4 geeignet.

Viele Grüße

Jürgen

Autor: Jürgen C (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

Mmc_chip_select liegt auf Portb.0 (SS)
Mmc_data_input liegt auf Portb.3 (MISO)
Mmc_data_output liegt auf Portb.2 (MOSI)
Mmc_clock liegt auf Portb.1 (SCK)

Gruß

Jürgen

Autor: Stefan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Im Anhang ist das Projekt nochmal, es gibt jeweils einen Unterordner 
"atmega128". Kann jetzt aber nicht verspechen dass es klappt, weil ich 
das mangels Mega128 nicht testen kann. Bitte sag' aber in jeddem Fall 
bescheid.

Gruß
Stefan

Autor: Jürgen C (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

leider beschreibt der Bootloader nur die ersten 64kb, d.h. er schreibt
64kb und die weiteren 64kb schreibt er nochmals über die ersten.
(So sieht es zumindest aus.)

Das Ergebnis sieht dann wie folgt aus:

00000 - 0F7F7 = 00

0F7F8 = 78
0F7F9 = 56
0F7FA = 34
0F7FB = 12
0F7FC = 00
0F7FD = 01

0F7FE - 0FFFF = 00

10000 = 10
10001 = 00
10002 = F8
10003 = 00

10004 - 1F7FF = FF (nicht beschrieben)

1F800 = 0C (Beginn des Bootloaders)

Ich vermute das RAMPZ Register muss noch entsprechend verwendet werden,
damit die richtige Page beschrieben wird.
(ATmega128 Datenblatt Seite 12
 RAMPZ0 = 0: lower 64 k
 RAMPZ0 = 1: higher 64 k wird von ELPM/SPM verwendet.)

Im Main Programm verwendest Du den Portb.4 für die Flash-LED. Leider 
kann
ich hier keine Reaktion erkennen. Im Programmspeicher findet jedoch die
oben beschriebene Änderung statt.

Bei meiner Hardware sind folgende Ausgänge mit einer LED verbunden und
können für Kontrollanzeigen verwendet werden.
Pinf.3
Pinf.7
Pine.4
Pind.7
Pind.6
Pind.4
Ping.4
Pinb.4

Bei Portx.x = 0 leuchtet die LED

Viele Grüße


Jürgen


Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jürgen,

habe den Fehler gefunden: memcpy_P funktioniert nur bis zur 64 k Grenze, 
und einige Variablen müssen von 16 Bit auf 32 Bit erweitert werden. Ich 
habe mir heute mal ein Design mit einem Mega128 aus der Bastelkiste 
gekramt mit dem ich das testen kann. Im Moment liegt der Bootloader für 
den Mega128 leider über 2048 Bytes, nämlich bei etwa 2150. Ist zwar 
weiter kein Problem, weil der Mega128 Bootsections bis 8 k kann, aber 
wäre schade die Bootloadersectiongröße wegen ein paar Bytes vergrößern 
zu müssen. Wenn's soweit stell ich selbigen hier rein. Eventuell mach 
ich ein Flag rein, mit dem man den FAT12 teil per Define abschalten kann 
(also nur FAT16), so würde es wieder in die 2 k passen. Oder vielleicht 
schauen die anderen Kolegen aus dem Thread nochmal drüber und kriegen 
das Ding noch kleiner ;-)

Gruß
Stefan

Autor: Jürgen C (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

mich stören die 2150 Byte nicht, da ich zur Zeit erst etwa 30% des 
verfüg-
baren Speichers nutze. Es würden also auch die 64kb reichen.

Gruß

Jürgen.

Autor: Stefan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, hier nochmal der Bootloader für den Mega128. Er ist nun für eine 
Bootsectiongröße von 4096 Bytes (2048 Words) ausgelegt (auch im 
Hauptprogramm beachten!) und ist 2106 Bytes groß. Vielleicht kriegt das 
ja noch jemand um 58 Bytes kleiner...

Gruß
Stefan

Autor: Robert S. (razer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke fürs portieren des Bootloaders auf den Mega128. Ihr seit spitze :)
Hab leider noch keine Zeit gehabt, ihn anzupassen, da ich keine Hardware 
noch habe. 58 Bytes kleiner wären halt schon schön ;)

mfg Robert

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan

Merkwürdig, einmal make clean, danach make all
und die Codesize ist nur noch 2046 ;)

Autor: S. Seegel (energizer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
holger:

hmmm, andere (ältere/neuere) Compilerversion ?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
avr-gcc (GCC) 3.4.6

Ich hab dein makefile nicht verändert und auch (noch)
nicht am Quellcode rumgefummelt.

Autor: S. Seegel (energizer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, war heute wohl zu lange an der Kiste gesessen, hab auch 3.4.6., und 
nun auf einmal auch 2046 ?!
Naja, aber die LED Ansteuerung ist noch auskommentiert, mit LED 
Ansteuerung sind's 2062. Naja, vielleicht gehen ja die 14 Bytes noch weg 
wenn du was am Source machst ;-)

Gruß
Stefan

Autor: holger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
10 Bytes in mmc_lib gespart.

Gute Nacht ;)

Autor: S. Seegel (energizer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
/*
  for (i=0; i<6; i++)
  {//Send 6 Bytes
    spi_send_byte(cmd[i]);
  }
*/

        i=6;
  while(i)
  {//Send 6 Bytes
    spi_send_byte(cmd[i]);
    i--;
  }

Ähm, werden so die Kommandosequenzen nicht falsch rum gesendet ?

Stefan

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tschuldigung, war schon etwas spät :(

Sollte so aussehen:

        unsigned char *buf = cmd;

        i=6;
  while(i)
  {//Send 6 Bytes
    spi_send_byte(*buf++);
    i--;
  }

Autor: S. Seegel (energizer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach Klasse, hab auch noch eine Kleinigkeit gefunden, nun sind's genau 
2048 Bytes ;-)...

Noch was anderes: Wer ist "richtig fit" mit make ?
Die Frage ist ob make eine Differenz aus zwei Hex-Werten berechnen kann, 
so könnte man
BOOTLDRSIZE = 0x800
#FLASHSIZE - BOOTLDRSIZE - 8
BOOTLDRINFOSTART = 0x37F8

z.B. ersetzten durch
FLASHSIZE = 0x4000
BOOTLDRINFOSTART = <0x4000 - 0x800 - 0x8> //Das müsste berechnet werden

?

Dann bräuchte man im makefile nicht mehr die Adresse der "Hundemarke" 
selber ausrechnen...

Stefan

Autor: Werner B. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nachdem ich nix besseres zu tun hatte (Steuer ist gemacht ;-) ), hab' 
ich das ganze nochmals etwas "geschrumpft". Die Version aus "new.zip" 
nun mit 1836 Bytes.

Allerdings nichts getestet, aber die Änderungen stammen im wesentlichen 
aus meiner Portierung des MegaLOAD bootloaders auf den AVR-GCC.

Falls es Probleme gibt, bitte zuerst im Makefile:
Das "neue" gcrt1.S aus dem Makefile entfernen und die Zusätze von
"-nostartfiles -nodefaultlibs" bei den ALL_???FLAGS entfernen und 
nochmals probieren und hier das Ergebnis posten.

P.S. Die Quelldateien sind "nicht aufgeräumt". Damit ist gemeint, daß 
die Orginalzeilen nur auskommentiert sind.

Viel Spass

Werner

Autor: Maximilian Lang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich bin in der uC Materie ganz ganz neu. Aber dieses Projekt finde ich 
sehr interessant und möchte es von anfang an nutzen.

Habe ich das richtig verstanden, dass man den Chip für Softwareupdates 
nicht mehr rausnehmen muss, sondern nur alte Karte raus neue Karte rein 
fertig? Wenn ja wie geht das denn jetzt? Ist der Bootloader auf dem 
Controller und der liesst sein Programm (zum Beispiel LED an) von der 
MMC Karte???

LG Max

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. Ja, aber entweder Neustart oder Reset des µC ist nötig
2. Siehe im Datenblatt oder im Forum unter Bootloader
3. Ja, aber was meinst du mit "Programm zum Beispiel LED an" ?

Stefan

Autor: Maximilian Lang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zu 3.) Wo liegt der Ausführcode? Wird der Code auf den uC gespielt oder 
holt er sich den von der MMC Karte. Also muss man die MMC Karte drin 
lassen oder kann man sie rausnehmen. Denn wenn nicht kann man ja größere 
Programme schreiben! :)

Ich frage deswegen, weil ich dann die Möglichkeiten habe meinen Kollegen 
einfach eine neue Hex zu schicken, die sie dann auf die MMC spielen 
können.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVRs können NUR Code aus dem Flash ausführen.
Aber egal wie, die Möglichkeit jemanden ein Update zu schicken welches 
dieser dann auf eine MMC kopiert um ein neues Programm in den µC zu 
bekommen hast du.

Stefan

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich schaue mir das hier gerade so an und muss sagen, dass wäre genau das 
richtige als Erweiterung für das MMC2IEC-Projekt bei dem ein Mega32 mit 
SD-Karte als C64-Diskettenlaufwerk benutzt wird.

Ich habe noch nie Bootloader mit den AVR's benutzt.
Daher habe ich da mal ein paar Fragen.

Erstmal, wie sieht das aus, die Rede war hier nur von den alten
WinAVR Versionen, wie gut klappt das mit der 20070525?

>Nun kann das Hauptprogramm compiliert werden.
>Die entstehende .hex Datei (binary Format!)

Ja was denn nun, .hex oder binär?
Kann ich AVR-Studio überhaupt dazu bringen, ein .bin zu erzeugen oder 
muss ich das nach dem compilieren noch konvertieren?

>wird anschließend noch mit dem Kommandozeilentool crcgen.exe behandelt
>(z.B. crcgen myflashfile.hex).

Wo finde ich das und gibt es das auch mit GUI für XP?
Und was macht das überhaupt genau? Einen Header mit der CRC32 davor 
hängen?
Die .hex dabei in einen .bin konvertieren?

>Der Aufruf dieses Programmes kann auch vom makefile aus geschehen.

Da ich das AVR-Studio benutze, wie würde man das in die Projekt-Optionen 
einfügen?

Sowieso, hat zufällig schon jemand eine Projekt-Datei für AVR-Studio 
erstellt mit welcher man den Bootloader compilieren kann?

>Das Update benennt man am besten etwa in der Form MeinApparat-v1.0-bin,
>darf aber beliebig (lang) sein .

Was macht der Bootloader genau? Sucht nach der ersten .bin im 
Hauptverzeichnis auf der Karte und schaut nach, ob die geeignet ist?
Daher ist der Name auch egal, weil sowieso nur nach der Erweiterung 
gesucht wird?
Also muss man die alten Dateien auch immer löschen weil eine später 
aufgespielte "xxx1.1.bin" nicht gefunden wird?

Gibt es eigentlich irgendeine Art von Lizenz für den Code?
Freeware? GPL? PuplicDomain?

Gruss, Rudolph

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, crcgen gefunden, es hilft, wenn man nicht nur das letzte Archiv 
runterlädt und aufmacht... :-)

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Erstmal, wie sieht das aus, die Rede war hier nur von den alten
>WinAVR Versionen, wie gut klappt das mit der 20070525?

Habe festgestellt dass der Bootloader mit dem neuen WinAVR ein paar 
Bytes größer wird, passt aber noch rein...

>Ja was denn nun, .hex oder binär?
>Kann ich AVR-Studio überhaupt dazu bringen, ein .bin zu erzeugen oder muss
>ich das nach dem compilieren noch konvertieren?

Binär, die Dateinamenerweiterung bleibt aber .hex, war zu faul das im 
makefile umzubauen. Wenn mann mit AVR Studio das GCC Plugin benutzt, 
kann man das Format Ausgabeformat im makefile einstellen, ansonsten k.A.

>Wo finde ich das und gibt es das auch mit GUI für XP?

Ist in (manchen) Archiven hier im Thread dabei.

>Und was macht das überhaupt genau? Einen Header mit der CRC32 davor
>hängen?

Nein, eine CRC16 in die letzten beiden Bytes der Datei schreiben.

>Die .hex dabei in einen .bin konvertieren?

Nein

>Was macht der Bootloader genau?

Er sucht nach einer Datei (Dateiname völlig egal), deren Größe stimmt 
und deren Versionsnummer größer als die im Flash ist.

>Also muss man die alten Dateien auch immer löschen weil eine später
>aufgespielte "xxx1.1.bin" nicht gefunden wird?

Nein, der Bootloader sucht selber die Datei mit der größten 
Versionnummer

Stefan

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Binär, die Dateinamenerweiterung bleibt aber .hex, war zu faul das im
>makefile umzubauen. Wenn mann mit AVR Studio das GCC Plugin benutzt,
>kann man das Format Ausgabeformat im makefile einstellen, ansonsten k.A.

Hmm, okay, da ich die Controlle über das makefile dem AVR-Studio 
überlassen möchte geht das so also nicht.
Da ich mich mit dem crcgen aber sowieso auf die Kommodo-Zeile herunter 
begeben muss kann ich vorher auch noch hex2bin aufrufen.

>Er sucht nach einer Datei (Dateiname völlig egal), deren Größe stimmt

Deren Größe stimmt?
Ah, die binaries werden immer maximal gross gemacht.
Also für den Mega32 werden immer 30k Dateien generiert mit 8 Byte
Info am Ende - egal wie lang die Applikation ist?
Mit make für die Beispiel-Applikation sehe ich auch, dass diese 2446 
Bytes gross wird - bin ja mal gespannt, was AVR-Studio dann anzeigt.

Und die Grösse wird in den Bootloader garnicht einkompiliert?


Oh, die Anzeige der StartAdressen für die Bootblöcke im AVR-Studio ist 
ein wenig seltsam, um nicht zu sagen, das haut überhaupt nicht hin.
Mega16, 1k -> 0x1c00
Mega32, 2k -> 0x3800
Mega128, 4k -> 0xf000

Das muss man ja immer mit 2 Multiplizieren um auf die richtige Adresse 
zu kommen.

Autor: Marco S. (masterof)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Datenblatt gibt die größe in Word an und der gcc-avr gibt sie in 
Byte an.

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das Datenblatt gibt die größe in Word an und der gcc-avr gibt
>sie in Byte an.

Ob Byte oder Word ändert  nichts an der Start-Adresse.


So, ich habe den Bootloader mal für den Mega32 konfiguriert:

---
# MCU name
MCU = atmega32

F_CPU =  8000000

# Output format. (can be srec, ihex, binary)
FORMAT = ihex

# "IEC!"
DEVID = 0x49454321

TARGET = bootloader

#Bootloader for Mega32 with 2k bootsection
BOOTLOADERSTARTADR = 0x7000
BOOTLDRSIZE = 0x0800
---

Lässt sich nur leider nicht kompilieren:

----
Linking: atmega32/bootloader-0x49454321.elf
avr-gcc -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=8000000UL 
-DDEVID=0x49454321 -DBOOT
LDRSIZE=0x0800 -Os -funsigned-char -funsigned-bitfields -fpack-struct 
-fshort-en
ums -Wall -Wstrict-prototypes -Wa,-adhlns=obj/main.o  -std=gnu99 
-mtiny-stack -W
undef -MMD -MP -MF .dep/bootloader-0x49454321.elf.d -nostartfiles 
-nodefaultlibs
 obj/main.o obj/mmc_lib.o obj/fat1216.o obj/gcrt1.o --output 
atmega32/bootloader
-0x49454321.elf -Wl,-Map=atmega32/bootloader-0x49454321.map,--cref 
-lm -Wl,-
-section-start=.text=0x7000
obj/main.o: In function `main':
D:\Projekte\Bootloader\Bootloader/main.c:82: undefined reference to 
`memcpy_P'
make: *** [atmega32/bootloader-0x49454321.elf] Error 1
----

Das verstehe ich jetzt nicht wirklich.
Mit dem "#include <avr/pgmspace.h>" in main.c sollte das doch zu finden 
sein?

---
avr-gcc (GCC) 4.1.2 (WinAVR 20070525)
---

Darin sollte eigenlich die neueste avrlibc enthalten sein.
Mit dem avr-libc-user-manual-1.4.6.pdf komme ich da auch nicht weiter.

Was mache ich falsch?

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, die Start-Adresse war schonmal verkehrt.

---
#Bootloader for Mega32 with 2k bootsection
BOOTLOADERSTARTADR = 0x7800
BOOTLDRSIZE = 0x0800
---

Ändert natürlich nichts an dem Problem, dass der Linker memcmp_P() nicht 
findet.

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, die Dateien aus "HolgerBootloader10.zip" kann ich out-of-the-box 
durch Aufruf von make compilieren.

Was ist an dem "new2.zip"-Archiv jetzt so sehr anders?

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehr seltsam das.
Ich kann im makefile vom "New2.zip" alles einstellen bis auf eine Sache.

Sobald ich "MCU = atmega128" auf "MCU = atmega32" ändere wird memcpy_P() 
nicht mehr vom Linker gefunden?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das muss an deinem 4.1.2 Compiler liegen. Habs gerade
mit dem 4.1.1 erfolgreich übersetzt. Vorher mit dem
3.4.6.

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer lesen kann ist klar im Vorteil...

>Autor:  Werner B. (Gast)
>Datum: 06.05.2007 12:19
>Falls es Probleme gibt, bitte zuerst im Makefile:
>Das "neue" gcrt1.S aus dem Makefile entfernen und die Zusätze von
>"-nostartfiles -nodefaultlibs" bei den ALL_???FLAGS entfernen und
>nochmals probieren und hier das Ergebnis posten.

Genauso funktioniert das auch...

---
Size after:
atmega32/bootloader-0x49454321.elf  :
section            size      addr
.text              1802     30720
.bss                550   8388704
.stab               888         0
.stabstr            113         0
.debug_aranges       96         0
.debug_pubnames     272         0
.debug_info        3129         0
.debug_abbrev      1097         0
.debug_line        1948         0
.debug_frame        176         0
.debug_str         1293         0
.debug_loc         1011         0
Total             12375
---

Sind die "1802" die Code-Größe?

Gruss, Rudolph

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich werd weich.
Während das bei einem Test-Projekt im AVR-Studio klappt bekomme ich die 
.bootldrinfo Sektion einfach nicht an das eigentliche Projekt angehängt.

mmc2iec.map:
.bootloaderinfo
                0x000077f8        0x0
test.map:
.bootldrinfo    0x000077f8        0x8
 .bootldrinfo   0x000077f8        0x8 test.o
                0x000077f8                bootlodrinfo

Warum bleibt die Sektion leer?
Der einzige Unterschied den ich jetzt sehe ist, dass sowohl die "Sample 
App" als auch meine "Test" jeweils nur aus einem Modul bestehen.
Meine Ziel-Anwendung hat 13 Module und ich weise den Inhalt im
Haupt-Modul zu.

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry wenn ich nerve.

Warum die Sektion leer bleibt weiss ich immer noch nicht, habe ich auch 
nicht mehr verfolgt sondern lieber erstmal versucht, den Bootloader an 
sich in Betrieb zu nehmen.

Der Bootloader aus dem HolgerBootloader10.zip Archiv funktioniert hier 
einwandfrei mit meinen Einstellung auf dem Mega32.
Beim flashen des Bootloaders mache ich den Mega32 leer, kurz nachdem das 
AVR-Studio fertig ist blinkt die Status-LED hektisch und wenig später 
ist meine Test-Applikation installiert.

Der Bootloader aus dem New2.zip Archiv macht hier mit den exakt gleichen 
Einstellungen und der gleichen 128MB SD-Karte überhaupt nichts.
Wie tot.

Aber FAT12-Support ist ohnehin nicht so wichtig. :-)

Wenn das mit der Sektion garnicht klappt kann ich mir wohl immer noch 
das CRC-Gen so umstricken, dass die Datei auf 30k aufgepumpt und die 
Daten angehängt werden.

Also erstmal vielen Dank!!

Autor: neuer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
welchen namen muss die neue flash-datei denn haben, damit die erkannt 
wird , oder wo muss ich im programm was ändern, damit ein bestimmte 
programm geladen wird? name?, grösse? usw?

mfg

Autor: karl-heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
....Der Bootloader aus dem HolgerBootloader10.zip Archiv funktioniert 
hier
einwandfrei mit meinen Einstellung auf dem Mega32.......


welche einstellungen hast du hier verändert für die mmc2iec?

mfg

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@neuer

>welchen namen muss die neue flash-datei denn haben,
>damit die erkannt wird

Der Name ist völlig egal.

>oder wo muss ich im programm was ändern,
>damit ein bestimmte programm geladen wird? name?, grösse? usw?

- die Programm-Datei muss in Binär-Form vorliegen.
- die Grösse ist immer FLASH-Bootloader, beim Mega32 mit 2K Bootloader 
also 30 KB
- Am Ende vom Programm werden eine Kennung, die Version, die Revision 
und eine CRC-Prüfsumme angehängt

@karl-heinz

>welche einstellungen hast du hier verändert für die mmc2iec?

Na, steht doch alles schon weiter oben.

Für den Bootloader:

---
MCU = atmega32
F_CPU =  8000000
# "IEC!"
DEVID = 0x49454321
BOOTLOADERSTARTADR = 0x7800
BOOTLDRSIZE = 0x0800
---

Also im wesentlichen nur eine neue Kennung gesetzt.
Ah ja, im main.c habe ich noch PC0 als Ausgang für die LED konfiguriert.

Die Änderungen in der MMC2IEC Software habe ich zwar gemacht ich bekomme 
es bisher aber nicht hin, dass die Sektion nicht gekillt wird.
Für einen Test habe ich die Daten einfach mit einem Hex-Editor angehängt 
und dann CRC-Gen drüberlaufen lassen.

Jetzt ne' Woche Urlaub... :-)

Autor: Kuen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tag zusammen,

ich wollte auch mal versuchen den Bootloader auf nem ATMega88 zum laufen 
zu kriegen.

Doch hab ich dazu einige Fragen.

Bootloader Start Adresse:

Ihr berechnet die Startadresse mit 16384 Bytes Flash - 2048 Bytes 
Bootloader = 14336 => 0x3800.

Für den ATMega88 also dann 8192 Bytes Flash - 2048 Bytes Bootloader = 
6144 => 0x1800.

Im Datenblatt des 88 ist die Startadresse aber mit 0xC00 angegeben, 
genau wie im Datenblatt des 16.

Warum wird im Programm die 0x3800 verwendet?


Sample App.:

Wozu ist das Programm gut?


Vielen Dank und Gruß

Autor: Rudolph R. (rudolph)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hat eigentlich irgend jemand mal den Bootloader aus dem new2.zip zum 
Laufen gebracht?

Ich habe das mal mit den kleinen Modifikation die ich an dem 
HolgerBootloader10.zip Archiv gemacht habe zusammengebracht und es 
kompiliert auch brav, läuft nur nicht auf meinem Mega32, stellt sich 
tot.

Naja gut, vielleicht gehe ich auch zu unbedarft an die Sache ran.
Ich habe es mal angehängt.

Im wesentlichen habe ich gerade ein paar Dateien ersetzt:

fat16.c -> fat1216.c
fat16.h -> fat1216.h
mmc_lib.c -> mmc_lib.c
mmc_lib.h -> mmc_lib.h

Wobei ja nur in der mmc_lib.h ein paar Portpins definiert werden.

Dann habe ich in der main.c noch ein paar Funktions-Aufrufe von 
fat16..() auf fat1216..() verändert.

Das Ergebnis ist ein Binary mit 1856 Bytes.

Ich wollte ja "nur" den FAT12 Code in dem bereits prächtig 
funktionierendem Bootloader aus dem HolgerBootloader10.zip Archiv 
nachrüsten.

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, so wie es aussieht ist New.zip kaputt und der Code in New2.zip hat 
den Fehler geerbt.
Die Karten werden nicht richtig initialisiert, fat1216_init() liefert 
jedenfalls nicht 0 zurück.

Mit den Dateien aus Bootloader_Mega128.zip habe ich das jetzt zum Laufen 
bekommen.

Autor: Kuen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für den Bootloader! Funktioniert Super.

Im Anhang die angepasste Version für den ATMega88.


Gruß
Kuen

Autor: newbiee (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kleine Frage: Hat jemand von euch das Ganze für das AVR Studio 4 als 
Projekt? Ich habe Das Problem, dass ich den Loader auf einem Mega8 
portieren möchte und auch die Belegung anders von LED und SD-Karte 
ändern möchte. Leider wird bei Importieren immer das MAKEFILE 
überschrieben. Das Kompilat ist dann auch Müll.
Kann mir jemand weiterhelfen / sagen was ich evtl. im AVR Studio falsch 
mache?
Danke!

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mach es Dir nicht so schwer und benutze Make von der 
Eingabe-Aufforderung aus, nachdem Du die Parameter eingestellt hast.

Ich würde auch lieber AVR-Studio benutzen, so wurde das Projekt aber nun 
einmal nicht angelegt.

Autor: Marco S. (masterof)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man kann es in den Projekt-settings einstellen.

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
habe den Bootloader gerade auf dem ATmega8 zum Laufen bekommen, echt 
super das Programm!
Ein Problem habe ich allerdings noch:
der Bootloader läd sich nur beim allerersten Mal das Programm von der SD 
Karte, danach nicht mehr. Woran liegt das? Ich habe in der Make schon 
Minor und Major Versionsnummer geändert, es tut sich aber nicht :(
Kann mir jemand sagen woran das liegt?

Vielen Dank für den Code

Kai

Autor: Holgus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Wie würdet Ihr das einschätzen...
Ist es möglich einen solchen Bootloader auch mit einem dsPIC 33 F XXX zu 
nutzen?
Nach möglichkeit möchte ich vorhandene Hard und Software nutzen, den C30 
Compiler mit MPLAB IDE und dem ICD2.
Momentan würde ich das so einschätzen, dass ich die Funktionen zum 
Schreiben im Flash passend zum Pic entwerfen müsste. Ist das Richtig ?
Also:
#include <avr/boot.h>
bzw.:
boot_page_erase(adr);
boot_page_write(adr);
boot_rww_busy();
boot_rww_enable();


Welche Steine liegen da noch im Weg?

Vielen Dank !!!

Holgus

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Welche Steine liegen da noch im Weg?

Ein dsPIC ist kein AVR vieleicht ?

>Momentan würde ich das so einschätzen, dass ich die Funktionen zum
>Schreiben im Flash passend zum Pic entwerfen müsste. Ist das Richtig ?

Du müsstest die SPI Routinen für deinen dsPIC anpassen.
Das FAT Programm so umbauen das es auf deinem dsPIC läuft....
Wenn der C30 genauso buggy ist wie der C18 dann gute Nacht.

Bootloader für AVR und dsPIC kann man nicht mal eben so
untereinander ANPASSEN.

Autor: Holgus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Holger !

Danke für deine schnelle Antwort!

Die SPI Routinen sowie der Zugriff auf die SD Karte mit FAT 16 macht bis 
jetzt keine Schwierigkeiten.
Für mich stellt sich die Frage nur bei dem Bootloader selber.
Welche Probleme beim Anpassen dort auftauchen.
Damit ich besser einschätzen kann ob ich das Problem löse oder besser 
bei seite lege..:-)

Vielen Dank
Holgus

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@holger

Moin moin,

sry erst einmal, falls ich etwas in diesem Thread falsch verstanden 
haben sollte. Ich bin noch recht neu auf diesem Gebiet. Im Rahmen eines 
FH-Projektescheins würde ich gern einen DATALogger bauen, der Daten 
(analog+ RS232) von Laborgeräten auf SD-Card speichert zur späteren 
Auswertung am PC. Bis auf die SD-Card Anbindung bin ich auch so weit 
fertig.

Zum Punkt! Ich würde das fertige Gerät gern einfach flashbar halten für 
Versionsupdates. Wenn ich das hier alles richtig verstanden habe, geht 
es doch darum, eine SD-Card an den ISP-Connector anzuschliessen und auf 
diese Weise z.B. einen ATMega32 zu flashen.

Wär es vielleicht möglich, dass ich ein Schaltbild des haben könnte vom 
SD-Card Conncetor auf die ISP-10pol-Wanne? Das würde mir wirklich sehr 
weiterhelfen. Ich habe dies leider beim Lesen des Threads nirgends 
gefunden (auch in den ZIP-files nicht).

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MMC  AVR
---- ----
DO   MISO
DI   MOSI
CLK  SCLK
CS   SS


Der AVR muss mit 3,3 V arbeiten, oder ein Pegelwandler dazwischen.

Gruß
Stefan

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Besten Dank!!! Ich dachte es wäre komplizierter. Das mit den 
Pegalanpassern hatte ich bereits gesehen. Leider habe ich die bei 
Reichelt nur in SMD-Version gefunden. Egal - irgendwann ist immer das 
erste mal ;)

Autor: Malte (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich verwende den Bootloader_Mega128.zip hier aus dem Thread. Habe ihn 
zur Ausgabe auf einem KS0108 Grafikdisplay ein ganz klein wenig 
erweitert und dabei Teile aus Holgers KS0108 Lib verwendet. Der Code ist 
hier angehängt. (die Zeichenketten in main.c gehören eigentlich ins 
Flash)

Das ganze funktioniert auch, aber nur genau ein mal. D.h. ich flashe den 
Bootloader, dann wird von der SD-Karte das eigentliche Programm 
eingespielt, das Program startet auch und verhält sich normal. Nach 
Reset oder Power Cycle scheint weder der Bootloader zu starten (was man 
aufgrund der Grafikausgabe ja sehen sollte) noch mein eigenliches 
Hauptprogramm.
Erneutes Flashen des Bootloaders startet die beschriebene Prozedur von 
vorne. Fuses etc. werden dabei nicht neu geschrieben.

Nach meinem Verständniss ist ja der Flash Bereich des Bootloaders gegen 
überschreiben geschützt. Ich habe mir den Speicherbereich trotzdem 
angesehen und er ist unverändert.

Bin gerade ziemlich ratlos. Hat jemand einen Tip?

Gruß
Malte

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du die Fuses so gesetzt dass auch der Bootloader startet ?
Klingt so als ob das nicht so wäre; wenn es nicht gesetzt ist und du den 
Bootloader flasht, ist der Rest (also Anfang bis Bootloader) zunächst 
leer, und der Bootloader startet. Wenn dann aber Dein Bootloader eine 
Applikation flasht wird nach einem Reset diese dann direkt ausgeführt...

Gruß
Stefan

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das war auch genau das Problem, was ich oben hatte.
Vielen Dank, jetzt funktioniert der Bootloader auch auf meinem mega8 :)
Gibt es eigentlich eine Möglichkeit ein bestimmtes Programm zu laden?
Also zB ein Programm flashen und dabei dann zB abfragen ob ein Taster 
gedrückt wird. Wenn ja, die Versionsnummer auf der SD Karte ändern und 
einen Reset erzwingen. Geht sowas vom Prinzip her? Ist es vielleicht 
auch irgendwie möglich ohne in das Hauptprogramm die ganze SD und fat16 
Bibliotheken importieren zu müssen.
Hintergrund meiner Frage ist eine Propellerclock mit einem mega32, der 
genau ein Bild speichern kann, auf Knopfdruck aber ein neues von der SD 
Karte liest.
Gruß
Kai

Autor: Malte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich denke die Fuses sind richtig gesetzt, aber ich überprüfe das noch 
einmal. Der Bootloader wird ausserdem aus einem Hex file geschrieben. 
Das Code landet danach an Adresse 0x1f000. Nach meinm Verständniss 
sollte der ATMega den Bootloader nicht starten wenn die Fuses nicht 
stimmen, da er ja bei 0x00000 das Programm erwartet. (Ich kann da aber 
ein Verständnissproblem haben)

Gruß
Malte

Autor: Malte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach so:

nachdem der Bootloader die App einmal geschrieben hat wird nach einem 
Neustart weder der Bootloader noch die App ausgeführt. War das bei dir 
genauso Kai?

Gruß
Malte

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir wurde der Bootloader nur direkt nach dem Flashen gelesen und 
dann wurde immer nur das Programm ausgeführt.
Ich hatte zwar die Fuses für den Bootloader auf die richtige Größe 
gestellt, hatte aber die "Boot Reset vector Enabled" Fuse (BOOTRST) 
nicht gesetzt. Jetzt wo ich das geändert habe, funktioniert alles super.
Mich würde trotzdem noch interessieren ob das irgendwie funktionieren 
könnte, dass man sich das Programm aussucht, das man laden möchte
Gruß
Kai

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man müsste den Bootloader doch nur ein wenig umstricken damit beim Reset 
"das nächste" Programm geladen wird.
In der Bootloader-Sektion gibt es doch bereits app_version.

Machst Du halt die Abfrage in check_file() entsprechend schlauer das die 
Datei mit der nächst-höheren app_version als bereits im FLASH gebrannt 
wird.
Am Besten noch mit einer Obergrenze über der wieder app_version = 1 
gebrannt wird.

Wenn das auf Tastendruck passiert bekommt man das FLASH wahrscheinlich 
nicht so schnell zerstört.
Aber automatisch alle paar Minuten einen Reset auszulösen, könnte ein 
wenig auf die Lebensdauer gehen. :-)

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hatte mir schon gedacht, dass das einfacher gehen könnte :)
Das ganze soll dazu gut sein um bei meiner Propellerclock die Bilder 
umzuschalten, geht dann eben "nur" 10000 Mal :P

Autor: Ja mann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das ganze soll dazu gut sein um bei meiner Propellerclock die Bilder
>umzuschalten

Hmm, das Programm ist doch aber dann das gleiche, nur die Daten sind 
anders ? Sowas sollte man mit externem Speicher, MMC, Flash, etc., 
machen.

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das externe Programm ist meistens das gleiche, es sei denn ich 
möchte ein Update machen. Die Sache ist, dass ein Bild bei mir genau 
28kB groß ist, also gerade so in den Flash eines mega32 passt. Würde ich 
jetzt ein komplettes Bild aus der SD Karte laden, bräuchte ich 28kB Ram 
und die sind teuer und groß. Eine SPI Anbindung ist für meine zwecke zu 
langsam, also müsste es parallel sein, da würde dann der mega32 nicht 
mehr reichen usw...
Ich hab mir das alles schon genau durchgedacht und sehe absolut kein 
Problem darin das mit einem Bootloader zu machen.

Autor: Malte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

habe eben nochmal das Datenblatt gelesen und glaube den Fehler gefunden 
zu haben. Ich habe BootszX auf 0,0 gesetzt. Das enstspricht 4096 
WORDS!!!. Müssen aber 4096 Bytes sein. Habe es jetzt noch nicht 
versucht, klingt aber nach einem Fehler der diese Symptome verursachen 
könnte. Zwischen der Einsprungadresse und dem Eigenlichen Start des 
Bootloaders liegen viele 0xff und natürlich die DeviceID, Versionnummer 
und die CRC Checksumme. Das wird, als Maschinencode interpretiert halt 
Murks sein.

Wenn ich mich nicht mehr melde war das der Treffer :-)

Gruß
Malte

Autor: Rudolph R. (rudolph)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe zwar im Rahmen meines Projektes den Source stets mit 
veröffentlicht, aber eben noch nicht hier.

Der Bootloader ist konfiguriert für das sd2iec.
Das ist ein Diskettenlaufwerks-Ersatz für den C64/C64DTV.
Als Controller kommt ein Mega644P zum Einsatz und wir benutzen 
inzwischen allerdings eine 4 KB Sektion um den Bootloader künftig noch 
erweitern zu können, etwa um SDHC und FAT32.

Der Source-Code ist teilweise aus den Archiven hier zusammengestückelt.

In der main.c haben wir ein paar Änderungen gemacht:

Eine Version.Revision 0.0 wird immer geflasht, das erleichtert das 
Verteilen von Test-Versionen.

Eine zweite LED wird mit benutzt und bleibt so lange an, wie der 
Bootloader aktiv ist.

Die Checksumme der Datei wird vor dem FLASHEN überprüft.


Momentan ist die Grösse 2164 Bytes.
Allerdings habe ich mir auch noch keine Mühe gegeben, dass zu ändern.
Der CRC-Check am Ende ist eigentlich redundant.
Und auch überflüssig, da wir die Applikation in jedem Fall starten.


Was ich noch als sehr sinnvoll erachte ist die Verwendung von Holger 
Klabunde's Hex2Bin.
Im Gegensatz zu anderen Tools dieser Art füllt Holger's Version nämlich 
die leeren Bereiche nicht einfach mit 0x00, sondern mit 0xFF.

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
prinzipiell funktioniert der Bootloader bei mir, allerdings habe ich 
Probleme sobald das Programm etwas größer wird.
Ich benutze einen mega32 und auch das entsprechende Programm.
Mit einem 2kB Bootloader sollten 30000 Byte (so groß ist das kompilierte 
Programm laut GCC) ja kein Problem sein, allerdings scheint es mir so, 
als würde sich der Controller einfach aufhängen...
wenn ich das Programm viel kleiner mache funktioniert es einwandfrei.
Hat jemand eine Ahnung wo das Problem liegen könnte?

Gruß
Kai

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die Grenze scheint bei genau 5kB zu liegen. Unterhalb dieser Codegröße 
funktioniert das Programm einwandfrei, danach spinnt es rum

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das muss irgendwie an Deinem Projekt oder an Deinen Einstellungen dafür 
liegen.

Als ich anfing den Bootloader für das MMC2IEC/SD2IEC zu benutzen lag die 
Codegrösse bei etwa 18 KB auf dem Mega32.
Als wir dann bei 27 KB angekommen sind haben wir den Umstieg auf den 
Mega644 gemacht.
Jetzt sind etwa 150 Boards da draussen mit Mega32 und 120 Boards mit 
Mega644P.

Die aktuelle Version für den Mega32 hat Code im Binary bis 0x770d,
das sind 30477 Bytes genutzt, 29,76 KB.
Also nur noch 235 Bytes Luft bis zur Kennung für den Bootloader.

Edit: im Binary für den M644 sind 32039 Bytes genutzt.

Da glaube ich irgendwie nicht, dass das ein Problem im Bootloader selbst 
ist.

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ich auch erst dachte, dass es ein Fehler von meinem Programm ist, bin 
ich folgendermaßen vorgegangen:
ich habe ein Programm mit weniger als 5kB erzeugt und getestet -> läuft 
genau wie es soll
dann habe ich ein zweidimensionales Array of chars [100][100] zu dem 
Programm hinzugefügt, es aber nicht benutzt. Logischerweise wurde das 
Programm jetzt mit weit über 5kB kompiliert.
Also habe ich die SD Karte eingelegt, das Programm wurde auch 
übertragen, allerdings funktionierte das Programm daraufhin nicht.
Mir kommt es daher so vor als ob der Bootloader nur 5kB überträgt und 
danach einfach aufhört. Gibt es dafür irgendeine logische Begründung?
5kB wären exakt 10 Blöcke der SD Karte.
Vielleicht hört er danach einfach auf zu schreiben...
Um auszuschließen, dass er an der falschen Stelle anfängt zu schreiben, 
habe ich mir über AVR Studio die Datei auslesen lassen, aber auch hier 
scheint alles zu passen.
Ich bin ratlos :(

Grüße
Kai

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dass die SD Karte irgendwann mit dem Übertragen aufhört ist übrigens 
auch Quatsch. Wenn ich nämlich eine Datei größer als 5kB flashe und über 
AVRStudio auslese, ist auch entsprechend viel Speicher belegt.

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal,
hab mich gestern mal mit einem Informatiker (Mitbewohner) an mein 
Problem gesetzt und siehe da: schon um halb 4 Uhr nachts war ein 
work-around erschaffen :P
Die magische Codegrenze waren nicht 5kB, sondern 2kB für die Variablen.
In meinem Programm habe ich ein riesiges Array, was ich als const 
deklariert habe. Der Compiler hingegen stopft mir das ins SRAM. Sobald 
das Array jetzt größer als 2kB wird, passt es nicht mehr ins SRAM und es 
gibt irgendwelche Probleme mit OBJCOPY (das hab ich nicht genau kapiert, 
mein Informatiker aber :P)
Auch nach stundenlangem Probieren das Array in andere Segmente zu 
schreiben, kamen wir nicht zu dem gewünschten Ergebnis.
Work-around:
Da das ganze mit CodevisionAVR funktioniert, erstellt man das gewünschte 
Programm einfach dort und kompiliert es.
Jetzt sucht man sich die erstellte hex Datei und schiebt sie durch einen 
hex2bin converter (wenn da jemand einen guten kennt, wär das nett wenn 
ihr mir schreiben könntet, eventuell sogar einen, den man über die 
Kommandozeile bedient (Windows))
Die erstellte Bin Datei wird jetzt mit einem .bat Programm gefüllt, die 
Hundemarke wird gesetzt und auch das CRC Byte.
Jetzt das ganze auf die SD Karte und es sollte mit dem Bootloader 
funktionieren.
Wenn jemand die gleichen Probleme hat, kann er mich ja anschreiben, ich 
schicke ihm dann die bat Datei

Gruß
Kai

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok,

d.h. es hat mit dem Bootloader nichts zu tun. Wie man ein const array 
ins RAM bringt steht in der avrlibc Doku und hier im Forum.

Gruß
Stefan

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem ist ja nicht, dass ich ein const array ins Ram bringen 
möchte, sondern, dass ich ein const array NICHT im SRAM haben will. Ein 
als const definiertes array sollte ja vom Prinzip in den Flash 
geschrieben werden, ist das Array unter 2kB groß wird es allerdings ins 
SRAM geschrieben, ab einer Größe von 2kB funktiniert das Programm nicht 
mehr richtig.

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
stichwort PROGMEM

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aua, Tippfehler, ich meinte natürlich nicht ins RAM sondern ins FLASH. 
Das steht in der Doku und (sehr oft) im Forum.

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
da merkt man mal wieder, dass ich mich noch nicht lange mit dem GCC 
beschäftigt habe.
Es liegt nicht am Bootloader, sondern am Compiler bzw an mir ;)
Der Bootloader funktioniert spitze, vielen Dank

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
hab da nochmal eine Frage:
wäre möglich den Bootloader schneller hinzubekommen?
Ich mein jetzt nicht die Datenübertragung, die wird wohl schon gut 
optimiert sein, sondern die Suche nach der richtigen Datei.
Du hast im Bootloader eine Schleife bis 512 stehen, die für jeden 
Eintrag die Datei überprüft. Wie kommst du auf diese Zahl? Ist das die 
Anzahl der Dateien, die maximal auf der Karte sein dürfen?
Wie sieht es aus wenn ich nur sagen wir maximal 20 Dateien speichern 
würde, würde es reichen dann immmer nur bis 20 zu suchen?
Hat jemand anders eventuell noch eine Idee wie man den Vorgang 
beschleunigen könnte?

Gruß
Kai

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hat jemand anders eventuell noch eine Idee wie man den Vorgang
>beschleunigen könnte?

Wie schnell sollte es denn sein ?

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mein Updatevorgang dauert momentan insgesamt knapp 5 Sekunden.
2 Sekunden gehen dabei für die Dateisuche drauf und fast 3 Sekunden für 
das eigentliche Überspielen (LED flackert)
Ich denke, dass man an den 3 Sekunden nicht viel drehen kann, vielleicht 
aber an den 2, die für die Dateisuche gebraucht werden. Generell gilt: 
"je schneller, desto gut" :P
Das ist bei meiner Propellerclock eben die Zeit, die kein Bild angezeigt 
werden kann. Wär schön wenn die so kurz wie möglich wäre

Autor: Marco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen
Ich bin auf der Suche nach genau so einem Programm. Ich muss allerdings 
zugeben, dass ich noch neu bin in dem Bereich. Ich würde dieses Programm 
gerne auf einem AT91Sam7 einsetzen. Geht das überhaupt? Kann hier jemand 
das Ändern? Danke schon mal für eure Bemühungen.

Autor: Michael H* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Erst mal Danke für das Projekt! Super Sache!

> So konnte die ursprüngliche Fassung, in der nur FAT16 implementiert war,
> um FAT12 erweitert werden.
Wie wäre es, wenn man das per defines einbaut, sodass entweder für FAT12 
oder FAT16 compiliert wird? Könnte so ein Code dann vielleicht auch in 
einen kleineren Bootbereich als 2k passen?

Danke, Grüße,
holli

Autor: HeGr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Ich will gerade die Fuses auf meinem Atmega32 setzen und habe für bootsz 
nur 4 optionen. 1024 words sollten einer Startadresse von 0x7800 
entsprechen oder?
Danke!

Autor: HeGr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Was sagt mir dieser Fehler beim kompilieren des Hauptprogramms?

c:/winavr-20080411/bin/../lib/gcc/avr/4.3.0/../../../../avr/bin/ld.exe: 
missing argument(s) to option "--section-start"


Vielen Dank!

Autor: HeGr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tippfehler bei der angabe der startadresse des bootloaders...
sorry :)

Autor: HeGr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry aber was macht der Bootloader wenn er keine Karte findet bzw. 
keine geeignete Datei? Sollte doch eigentlich von 0x0000 starten, oder? 
Weil er bei mir hängen bleibt (LED geht an und bleibts auch).
Gibts da nen Workaround?
Grüße!

Autor: HeGr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt noch das Problem das meine Hauptanwendung die 
Manipulation des Makefiles nicht so prima findet.
Kann mir jemand ein paar Tipps für mein neues Anliegen geben?
Mein Plan: ins Menu meines Projekts baue ich einfach einen Punkt update 
ein und lasse den Mega in den Bootbereich springen. Bei einem Reset wird 
der Bootloader nicht mehr gestartet. Das ist eh Zeitsparender.
Ich möchte auch gern auf das ganze Versioning verzichten und würde den 
Bootloader deshalb gerne so verändern das die ganzen (coolen aber für 
mich gar nicht nötigen) Features wegfallen. Einfach nur nach einem 
bestimmten Dateinamen suchen (update.bin) und das aufspielen, danach 
resetten.
Leider kommt in der Anwendung etliches zum Einsatz was mir absolut gar 
nichts sagt und darum könnte ich den einen oder anderen Tipp gebrauchen. 
Oder geistert vielleicht sogar irgendwo noch eine Entwicklungsversion 
eines simple_bootloaders herum?
Danke & Grüße!

Autor: HeGr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin schon ein ganzes Stück weiter. Inzwischen lädt der Bootloader 
mir mein file dann, wenn außer dem Bootloader nichts auf dem Mega ist. 
Nachdem er dann einmal die Anwendung geschrieben hat, wird immer das 
Programm gestartet und nicht geupdatet. Soweit wie schon oben 
beschrieben.
Allerdings startet bei mir der Bootloader (LED geht an) und verhält sich 
dann so, als ob auf der Karte kein Update wäre.
Ist es aber. Ich habe im Makefile Major und Minor Version geändert aber 
beides hilft nicht.
Wie lange sucht er eigentlich nach dem File? Kann es sein das er nicht 
schnell genug fündig wird oder so? Irgendein anderer Fehler? Ich benutze 
Holgerbootloader10.zip.
Grüße!

Autor: HeGr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich entschuldige mich für den ganzen Trouble. Es war ein 
Hardware-Fehler. Ich hatte einen SMD-SD-Slot durch normales Lochraster 
gesteckt. Eine Lötstelle war unschön und hatte mal Kontakt-mal nicht. 
Sowas zu finden ist eher schwer. Und ich hab mich Software-Seitig echt 
dumm gesucht!
Läuft super. Tolle Sache. Vielen Dank!!

Autor: Tonio Seiler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Funktioniert dieser Bootloader auch für einen ATMega1281? Habe hier 
nirgends einen Hinweis gefunden?

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir fällt gerade kein Grund ein, warum das nicht funktionieren sollte.
Der M1281 hat eine Bootloader-Sektion und hier im Thread war schon mal 
eine Anpassung für den M128 zu finden.
Das "Problem" dabei war nur der Adress-Raum jenseits von 64K.

Im Zweifel einfach mal an das Target anpassen und ausprobieren.

Autor: Eitum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo erstmal,

Es wurde hier schonmal gefragt, aber da keine Antwort kam und mich das 
selbe Problem piesackt...

Ist dieser Bootloader verwendbar für AT91SAM7SE512?

Müßte er angepasst werden?

Autor: Ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Entschuldigung, aber was für eine Frage ist denn das?

ATMega16 = AVR 8 Bit
AT91SAM = ARM 32 Bit

Mit "mal eben anpassen" ist es da vermutlich nicht getan.

Autor: Matthias R. (mons)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute !
Ich weiß dieser Beitrag ist alt ,aber trotzdem: Könnt ihr mir ein 
angepasstes Programm für den Atmega 168 reinstellen?

Autor: Christian K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wäre bereit den Bootloader für einen AT91SAM7S64/128/256/512 
umzuschreiben. dafür müssten mir aber diejenigen unter euch, die ARM und 
AVR von der rogrammierung her kennen ein wenig helfen, und die 
Wichtigsten Unterschiede aufschreiben.
Ich kann zwar recht gut in C und C++ programmieren aber µC programiere 
ich noch nicht so lange und nur ARM´s deshalb brauche ich ein wenig 
Hilfe aber die werde ich sicherlich von einigen hier bekommen.


Christian K.

Autor: Christian K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann mir keiner die Wichtigsten unterschiede(programmierteschnisch) 
posten? dann kann ich nämlich anfangen.

Ich Danke schonmal im Vorraus

Christian K.

Autor: Christian K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann hier keiner beide arten programmieren?

Autor: Ben .. (lightning)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian K.

Ich würde mich zuerst in beide µC ein wenig einlesen und dann
sieht man die Unterschiede.
Vergleiche doch mal zwei Datenblätter und sieh dir an wie z.B.
der Boorloader funktioniert usw.

Ich bin selbst gerade dran mich in ARM einzulesen.

Gruß Lightning

Autor: Christian K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mit ARM´s kenne ich mich halbwegs aus, nur mit avr´s habe ich noch nie 
gearbeitet. ich habe vorhin eine andere Frage gestellt 
Beitrag "AT91SAM7S Linux auf SD/MMC/Flash"
wenn das geht, dann werde ich nämlich diesen Seriellen Bootloader 
ersteinmal nicht portieren, sondern versuchen Linux auf net AT91SAM7S 
zum laufen zu bringen.

Autor: Heiko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

habe ich das richtig verstandenn, dass die binären Quellcodefiles immer 
der größe des Flashend - Bootloaders + 1 sein soll?

Ich arbeite mit dem AVRStudio4 und habe im Makefile die entsprechende 
Zeile auf binary abgeändert. Leider entsprechen die Ergebnisse nach make 
clean und make all nie der maximalen größe.

Den Bootloader habe ich soweit auf einen Atmega64 drauf, da ich bis in 
folgende Abfrage komme,
.
.
.
void check_file(void)
{
  //Check filesize

  if (filesize != FLASHEND - BOOTLDRSIZE + 1)
    return;
.
.
.
vermute ich das die SD-Card Funktionen soweit OK sind.


Ich habe zum test eine if Abfrage auf Flashend - Bootloader + 1 == 
0xF000 welches True ergibt. Somit gehe ich davon aus das zumindest 
dieser Teil passt. Leider entspricht filesize dem was ich auch im 
Dateimanager sehe.

Hat jemand eine hilfestellung für mich
Vielen Dank

Gruß Heiko

Autor: Heiko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fehler gefunden!

Hatte unter Memory Settings den falschen Wert angegeben, beim Atmega64 
muss da 0x77FC rein. Hatte vergessen die 8byte für Device SWmajor 
SWminor und CRC mit einzurechnen.

Nun stehe ich vor dem Problem das ich nicht den CRC bestehe und somit 
nicht zum app_start(); komme.

Kann mir dazu jemand tips geben?

Danke
Heiko

Autor: Azhdar Kelass (azhdar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Holger,
Ich habe momentan ein richtiges Problem und zwar:
1)gibt es auch eine Version von HolgerBootloader5 mit SoftwareSPI?

2) Kann man die

DEVID = 0x12345678
BOOTLOADERSTARTADR = 0x7800
BOOTLDRSIZE = 0x800

auch als #define im Programm selber definieren? (damit ich den Makefile 
automatisch von WinAVR generieren lasse)

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
WinAVR generiert kein makefile, es braucht eins ;-) Du meinst vermutlich 
AVR Studio, und in selbigem kannst Du soweit ich weiß in den 
Projektoptionen Compileroptionen hinzufügen, und damit auch die 
entsprechenden defines.
Wegen Software SPI: Wirst Du Dir selber umschreiben müssen, aber dadurch 
wird der ganze Bootloader mit Sicherheit größer und langsamer...

Stefan

Autor: azhdar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat irgendjemand das Projekt mit AVR Studio ausprobiert??
Ich habe folgendes Problem:

_Teil des Codes______________________________
typedef struct
{
  unsigned long dev_id;
  unsigned short app_version;
  unsigned short crc;
} bootldrinfo_t;
#define DEVID  0x12345678
#define SWVERSIONMAJOR  1
#define SWVERSIONMINOR  0
#define BOOTLDRSIZE  1024
const bootldrinfo_t bootlodrinfo _attribute_ ((section 
(".bootldrinfo"))) = {DEVID, SWVERSIONMAJOR << 8 | SWVERSIONMINOR, 
0x0000};
________________________________

Fehlermeldung:
c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe: 
section .bootldrinfo [00007bf6 -> 00007bfd] overlaps section .data 
[00007bf6 -> 0000815d]
 __________________________________

Autor: Louis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat irgendjemand eine Idee wie man ein Programm aus dem E-lab 
Avrco-Pascal-Compiler anpassen kann damit man es in dem Bootloader 
übergeben kann?
Ich nix C sprechen...

Danke,

Louis

Autor: Paul S (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

Da der letzte Post in diesem Beitrag schon etwas her ist, hoffe ich 
trotzdem vielleicht das jemand mir bei meinem Problem helfen kann.

Ich bin dabei den Bootloader auf einem AtMega 1284p zum Laufen zu 
bringen. Leider wird nichts in den Flash geschrieben bzw er springt 
nicht an die physikalische Adresse 0x0000.
Ich wäre sehr dankbar, wenn jemand das Programm bei sich mit 
vergleichbarer Hardware testen könnte. Ich bin kurz vor dem verzweifeln.

Folgende Sachen habe ich von der letzen Version vom Holger 
(HolgerBootloader10.zip) angepasst/ abgeändert:

Auf meinem Board ist der CS Eingang der MicroSd Karte nicht mit dem 
standard SPI  SS(CS) Ausgang verbunden, sondern wird über den Pin PD6 
angesteuert. Nötige Änderungen habe ich im Code durchgeführt. Leider 
konnte ich beim Debuggen mit AVR Studio keine  Daten im SPDR

Da ich mit AVR Studio arbeite, habe ich soweit ich mich mit Makefiles 
auskenne, es angepasst.
Ich hoffe das ich nichts wichtiges ausgelassen habe, zumindest lässt 
sich es compilieren.

Da ich beim Debuggen in der Funktion check() in der main.c festgestellt 
habe , dass er bei der IF

if (filesize != ((FLASHEND - OFFSET) - BOOTLDRSIZE ) )
  return;

immer aus der Funktion rausspringt, habe ich zu dem Flashend einen 
Offset abgezogen, da er beim AtMega1284p 0x1FFFF ist und nicht wie beim 
ersprünglichen benutzen µC 0xFFFF.  Ich hoffe das ich den Sinn von 
filesize richtig verstanden habe.

Obwohl ich die Testapplikation mit dem CRC-Gen bearbeitet habe hab ich 
in der CRC Prüfung in der Main trotzdem keinen Rückgabewert von Null. 
Aus diesem Grund habe ich die If- Abfrage ertsmal auskommentiert um an 
die Funktion appstart() zu starten.

Ich benutze eine  2GB microSD von Fujifilm und habe diese mit Windows 
auf  FAT16 formatiert.

Würde mich über jeden Ratschlag freuen.

Gruß,
Paul

Autor: Azhdar Kelass (azhdar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Paul,
Ich habe ebenfalls mit Mega1284p meine Probleme. Hasst du schon der 
Fehler gefunden? Ich brauche nämlich für mein privaten Projekt eine 
funktionsfähige Version.
Grüße,
azhdar

Autor: ***SurtuR*** (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

interessiere mich für genau einen solchen Bootloader.
Habe bisher aber noch nicht so viel Erfahrung wie ihr...
hat jemand den Bootloader rein zufällig mal auf einen mega644p 
umgebastelt.

falls nicht, noch eine andere Frage: wie kann ich Ihn nach den für meine 
Zwecke spezifischen Änderungen per AVR-Studio in die BootloaderSection 
flashen oder ist dies nicht mit AVR-Studio möglich?

MfG

Autor: Matthias Eckoldt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
HILFE!!!
Habe dieses Projekt hier (brauche einen BootLoader für atmega2561) in 
Version10 runtergeladen - ich komme mit meiner hex-Datei nie unter 
4kByte. Arbeite mit ProgrammersNotepad und avr-gcc (WinAVR 20100110) 
4.3.3. Verwende auch die Make-Datei des Projekts - immer aber ist die 
Datei zu groß. Habe ohne FAT12 exakt 4588Byte als hexDatei. Was mach ich 
falsch? Wo muss ich noch was einstellen? Ich poste mal meine lss-Datei - 
vielleicht sieht einer was ich nicht sehe!

Autor: Christian1983 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo an alle!

Hätte ein kleines, großes Anliegen. Könnte mir jemand den Bootloader von 
Holger so modifizieren das folgender Ablauf funktioniert:

1.Karte Fat12 und Fat16 mit und ohne MBR
2.Während dem Laden des Updates sollte eine LED schnell blinken (Ausgang 
egal)
3.Nach Update sollte der Atmega automatisch reseten

Und falls möglich sollte ein Update auch üder die Serielle Schnittstelle 
möglich sein! (Ist aber nicht wichtig).

Und nun das Hauptproblem, Ich bräuchte das ganze für den Atmega1280 und 
den Atmega2560!!!

Bin leider was Bootloader betrifft leider ein Anfänger, hab mich damit 
noch nie beschäftigt, hab bis jetzt immer mit dem Arduino Meine Projekte 
erstellt und bin nun gerade dabei eine komplette Platine selbst zu 
entwickeln und bräuchte dafür natürlich vorher alle Daten, Tools und 
Programme.

Wäre euch sehr sehr sehr zu Dank verpflichtet falls das jemand hin 
bekommt!

Danke schon mal
LG Christian

Autor: ***SurtuR*** (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich komme mit meinen selbst kompilierten Programmen nie auf die Größe 
des freien Flashspeichers?! Wie stelle ich das an, das es passt?
Habe das Makefile der Sample-App genommen, und entsprechend meine .c 
Dateien eingetragen. Statt 14K wie beim kompilieren der Sample-App, 
kommt bei mir nun eine 9,5K Datei raus. Wie stell ich das an, das die 
Größe stimmt?

Ralf

P.S. mit AVR Studio kommt die selbe Größe raus. Nur das da ja das 
Standard Makefile (vom Studio generiert) genutzt wird.

Autor: ***SurtuR*** (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok hat sich erledigt. ich hab doch glatt bei den sourcen die übersicht 
verloren und das struct vergessen :)

Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist mal ein Update des genialen Bootloaders.

Im Wesentlichen habe ich die Arbeit von Werner B. 
(Beitrag "Re: MMC/SD Bootloader füt ATMega16", keine Vektor-Tabelle 
durch eigenes Startfile, new2.zip) und Rudolph R. (rudolph) 
(Beitrag "Re: MMC/SD Bootloader füt ATMega16", CRC-Check vor dem 
Flashen, 0.0-Version immer laden, sd2iec_Bootloader_2008-02-23.zip) 
kombiniert, und noch ein paar kleine Optimierungen gefunden.

Da ich nur SD- und SDHC-Karten >= 1GB habe, habe ich den frei gewordenen 
Platz für folgende Änderungen genutzt:
- in fat1216.c 2 Variablen von 16 auf 32 Bit erweitert, damit auch der
  hintere Teil von größeren Karten erreicht werden kann.
- Wenn eine Partitionstabelle auf der Karte ist, werden alle 4 Einträge
  nach FAT12 oder FAT16 Partitionen durchsucht. Die erste gefundene wird
  genommen.
- Alternativer mmc-Treiber, der auch mit SDHC-Karten funktioniert.
  (Routinen von CHaN, stark abgespeckt aber trotzdem ca. 170 Byte größer
  als die alten Funktionen.)

Die Hardwarekonfiguration (SPI-Pins, LED) wird in 'config.h' 
eingestellt.

Die ursprüngliche mmc-Lib habe ich drin gelassen, da ich sie mit allen 
meinen SD-Karten (ohne SDHC) doch noch zum Laufen bekommen habe. Um sie 
zu verwenden, muß man im Makefile 'mmc.c' gegen 'mmc_lib.c' tauschen, in 
den Sourcen (fat1216.h) 'mmc_lib.h' statt 'mmc.h' includen, und 
'config.h' rausnehmen.

Im Makefile der Demo-APP gibt es ein neues Target bin. Dieses 
erzeugt ein Image im Binärformat, komplett mit Bootlader-Info und CRC, 
und die Lücken im Flash werden mit 0xFF gefüllt. Im Default-Target habe 
ich 'hex' gegen 'bin' ausgetauscht. 'make/make all' erzeugt ein 
bin-File, während man mit 'make hex' wieder ein hex-File zum Flashen 
über Programmer erzeugen kann.


S. Seegel schrieb:
> Die Frage ist ob make eine Differenz aus zwei Hex-Werten berechnen kann,
> so könnte man
> BOOTLDRSIZE = 0x800
> #FLASHSIZE - BOOTLDRSIZE - 8
> BOOTLDRINFOSTART = 0x37F8
>
> z.B. ersetzten durch
> FLASHSIZE = 0x4000
> BOOTLDRINFOSTART = <0x4000 - 0x800 - 0x8> //Das müsste berechnet werden
>
> Dann bräuchte man im makefile nicht mehr die Adresse der "Hundemarke"
> selber ausrechnen...

Make kann keine arithmetischen Ausdrücke, aber es gibt ja den 
Werkzeugkasten. Damit läßt sich auch die Flash-Größe des Zielprozessors 
ermitteln, und es muß nur noch die Größe der Bootlader-Sektion angegeben 
werden. Ich hoffe, die gefundene Lösung ist ausreichend portabel. 
Getestet habe ich unter Linux und mit WinAVR 20100110.

Die Code-Größe mit avr-gcc 4.7.2 liegt zwischen 1564 Byte (ohne LED, nur 
FAT16 und alte mmc-Lib) und 1956 Byte (mit LED, FAT12/FAT16 und neue 
mmc-Lib). Bei ernsthaftem Bedarf könnte man über FAT32 nachdenken.

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Geht dieser auch fūr den atmega328?

Gruss

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antwort, auch wenn der Beitrag schon etwas älter ist.
Jetzt muss ich ganz ganz blöd fragen.

Gibt es ein Schaltbild und eine Anleitung wie ich den File auf den uC 
bekomme.
Habe bis jetzt noch nie mit Bootloadern gearbeitet.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mike,
was ist denn Deine Ausgagssituation, und was möchtest Du gerne 
erreichen?

Den hier beschriebenen Bootloader nimmt man üblicherweise dann, wenn man 
bereits einen SD-Kartenleser an seinem Gerät hat.
Etwas Beschreibung dazu gibt es (außer in diesem Thread natürlich) hier:
http://www.mikrocontroller.net/articles/MMC/SD_Boo...

Für Projekte ohne Kartenleser ist ein anderer Bootloader vielleicht 
besser geeignet. Z.B. Fastboot von Peter Dannegger:
http://www.mikrocontroller.net/articles/AVR_Bootlo...

Hier noch der allgemeine Artikel zum Thema:
http://www.mikrocontroller.net/articles/Bootloader

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Anforderung ist folgende.

Ich programmiere derzeit mit einem Arduino Uno meinen Atmega328.

Nun hätte ich gerne die Möglichkeit, dass wenn meine Schaltung später 
bei mir fest verbaut ist ich nur per SD Karte eine neue Software 
aufspielen kann.

Ich brauche eigentlich keine Versionsüberprüfung oder so, also es kann 
auch gerne mal eine ältere SW wieder auf den uC geschrieben werden. 
Sobald die SD Karte eingelegt ist. Soll er halt die neue kopieren.

Ich würde gerne weiter mit der Arduino IDE meine *.hex Files erzeugen 
und die dann auf die SD karte schieben.

Ich würde aber durchaus einen Umweg in kauf nehmen um den Bootloader 
aufzuspielen wenn das nicht mit der Arduino IDE geht.

Gruss

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mike schrieb:
> Ich programmiere derzeit mit einem Arduino Uno meinen Atmega328.
> Nun hätte ich gerne die Möglichkeit, dass wenn meine Schaltung später
> bei mir fest verbaut ist ich nur per SD Karte eine neue Software
> aufspielen kann.

Die Signale dazu findest Du auf dem Uno auf dem Stecker ICSP (außer CS, 
geht aber evtl. auch ohne). Mit Kartenslot verbinden nach diesem Schema:
Beitrag "Re: MMC/SD Bootloader füt ATMega16"
(Suche im Tread nach 'ISP' findet noch etwas mehr zum Thema.)

Falls die Signale in Deiner Schaltung noch für etwas anderes benutzt 
werden, müssen sie passend entkoppelt werden.

> Ich brauche eigentlich keine Versionsüberprüfung oder so, also es kann
> auch gerne mal eine ältere SW wieder auf den uC geschrieben werden.
> Sobald die SD Karte eingelegt ist. Soll er halt die neue kopieren.

Du kannst die Versionskennung einfach auf 0.0 stehen lassen.
(Aber irgendwann wirst Du wahrscheinlich ältere von neueren Versionen 
unterscheiden können wollen...)

> Ich würde gerne weiter mit der Arduino IDE meine *.hex Files erzeugen
> und die dann auf die SD karte schieben.

Das Hexfile muß in ein Binärfile konvertiert, und um eine CRC ergänzt 
werden. Im Bootloader Makefile gibt dazu das Target 'bin' (siehe unten).

> Ich würde aber durchaus einen Umweg in kauf nehmen um den Bootloader
> aufzuspielen wenn das nicht mit der Arduino IDE geht.

Der Bootloader kann als Hexfile erzeugt und mit einem ISP-Programmer 
aufgespielt werden (Evtl. auch über die Arduino-IDE).


ps:
'make bin' sieht (expandiert) so aus:
$ avr-objcopy -I ihex -O binary --gap-fill 0xff  meinprog.hex meinprog-0.0.bin
$ crcgen meinprog-0.0.bin

'crcgen' ist im Bootloader-Paket.
'avr-objcopy' ist in den GNU-Binutils und damit auch in der 
AVR-GCC-Toolschain.

: Bearbeitet durch User
Autor: Chris W. (verleihnix85)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hallo Zusammen

ich habe einen neuen Bootloader für Xmega geschrieben. Den Code habe ich 
mir aus vielen SD Bootloadern zusammenkopiert und teilweise stark 
modifiziert.
FAT ist von chan, Teile von https://code.google.com/p/avr-xboot/ , 
https://spaces.atmel.com/gf/project/sdbootloader/ und hier.
Hat rund 2 Wochen gebraucht das zum laufen zu bringen. Der neue Logic 
analyzer von zeroplus hat sich gelohnt. So konnte ich die Probleme mit 
dem SD Code auf Hardwareebene beheben. Jtag zum debuggen war auch echt 
hilfreich.

Daten:
bis 64k Flash getestet, für mehr muss man wahrscheinlich noch was 
anpassen.
braucht 4kB Bootbereich
Fat16 und Fat32
frisst fast alle SD Karten (mit 18 Verschiedenen erfolgreich getestet 
von 1GB bis 16GB)
Device ID und Versionskontrolle (0 geht immer)
CRC von file und flash


nächstes Ziel: für Atmega328p und nur 2kb Bootbereich. Mal sehen ob das 
hinzubekomen ist. Leider hat der keinen gescheiten debug Modus.

Gruß Chris

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.