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
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.
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.
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
Kleine Anmerkung, habe ich gerade rausgefunden:
<avr/boot.h> ist nicht ganz -mint8 fest. Der Check
1
#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)
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
Hallo Stefan,
Dein Bootloader ist wirklich nicht schlecht, Kompliment!!
Eine Frage, wäre es schwer, den Bootloader auf einen Mega128
umzuschreiben??
mfg Robert
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
@ 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;
}
}
@ 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
>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
, 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...
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 ;)
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.
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
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
>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.
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 ;)
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-Codeoptimierung
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
@ 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 ;)
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.
@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:
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
1
adr<<=1;
2
3
cmd[0]=0x40+MMC_READ_SINGLE_BLOCK;
4
cmd[1]=(adr&0x00FF0000)>>0x10;
5
cmd[2]=(adr&0x0000FF00)>>0x08;
6
cmd[3]=(adr&0x000000FF);
7
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.
@ 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.
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 ?
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
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
@ 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.
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.
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.
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.
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
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
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
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
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
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
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
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.
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
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
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
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
1
BOOTLDRSIZE=0x800
2
#FLASHSIZE - BOOTLDRSIZE - 8
3
BOOTLDRINFOSTART=0x37F8
z.B. ersetzten durch
1
FLASHSIZE=0x4000
2
BOOTLDRINFOSTART=<0x4000-0x800-0x8>//Das müsste berechnet werden
?
Dann bräuchte man im makefile nicht mehr die Adresse der "Hundemarke"
selber ausrechnen...
Stefan
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
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
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
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.
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
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
>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
>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.
>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?
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.
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?
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?
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
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.
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!!
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
....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
@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... :-)
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ß
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.
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.
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!
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.
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
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
>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.
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
@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).
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 ;)
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
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
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
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
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
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
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. :-)
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
>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.
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.
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
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.
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
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.
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
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.
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
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.
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
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
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
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.
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
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!
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!
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!
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!
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!
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!!
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.
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?
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.
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.
@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
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.
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
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
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)
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
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
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
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
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
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!
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
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.
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.
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.
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
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:
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
Karim Rezapasand schrieb:> Hello everybody> if i want to change fusebit for my atmega32a (in spurce file) how to do> it ?
You can't, use a isp programmer or a jtag programmer.
Read your datasheet bevor!
Karim Rezapasand schrieb:> TU karl.M. but where is fusebits in bootloder ? Am i neede to chang it> for other MC like atmega32 or 64 ?
HI
I use the bootloader to update my App in a runnig system.
You can use for example a SKT500 to program the fusebits first and maybe
you dont need to chanche it later.
Thread beobachten
Seitenaufteilung abschalten