Datum:
Angehängte Dateien: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
Datum:
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.
Datum:
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.
Datum:
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
Datum:
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)
Datum:
Angehängte Dateien: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)
Datum:
Hallo Stefan, Dein Bootloader ist wirklich nicht schlecht, Kompliment!! Eine Frage, wäre es schwer, den Bootloader auf einen Mega128 umzuschreiben?? mfg Robert
Datum:
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
Datum:
@ 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;
}
}
Datum:
Angehängte Dateien:@ 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
Datum:
Angehängte Dateien:Und jetzt komme ich auf 1716 Bytes. Soll ich weitermachen ?
Datum:
>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...
Datum:
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 ;)
Datum:
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.
Datum:
Angehängte Dateien: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.
Datum:
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
Datum:
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
Datum:
>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.
Datum:
Angehängte Dateien: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 ;)
Datum:
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
Datum:
@ 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 ;)
Datum:
Angehängte Dateien: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.
Datum:
@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; } |
Datum:
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.
Datum:
@ 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.
Datum:
Angehängte Dateien: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 ?
Datum:
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
Datum:
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
Datum:
@ 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.
Datum:
Angehängte Dateien: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.
Datum:
Angehängte Dateien: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.
Datum:
Angehängte Dateien: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.
Datum:
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
Datum:
Hab' mal eben aus dem Projekt einen kleinen Artikel gemacht: http://www.mikrocontroller.net/articles/MMC/SD_Boo...
Datum:
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
Datum:
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
Datum:
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
Datum:
Angehängte Dateien: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
Datum:
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
Datum:
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
Datum:
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.
Datum:
Angehängte Dateien: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)
Datum:
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
Datum:
@ Stefan Merkwürdig, einmal make clean, danach make all und die Codesize ist nur noch 2046 ;)
Datum:
avr-gcc (GCC) 3.4.6 Ich hab dein makefile nicht verändert und auch (noch) nicht am Quellcode rumgefummelt.
Datum:
Angehängte Dateien:10 Bytes in mmc_lib gespart. Gute Nacht ;)
Datum:
/* 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
Datum:
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--;
}
Datum:
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
Datum:
Angehängte Dateien: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
Datum:
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
Datum:
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
Datum:
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.
Datum:
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
Datum:
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
Datum:
Okay, crcgen gefunden, es hilft, wenn man nicht nur das letzte Archiv runterlädt und aufmacht... :-)
Datum:
>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
Datum:
>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.
Datum:
Das Datenblatt gibt die größe in Word an und der gcc-avr gibt sie in Byte an.
Datum:
>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?
Datum:
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.
Datum:
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?
Datum:
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?
Datum:
Das muss an deinem 4.1.2 Compiler liegen. Habs gerade mit dem 4.1.1 erfolgreich übersetzt. Vorher mit dem 3.4.6.
Datum:
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
Datum:
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.
Datum:
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!!
Datum:
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
Datum:
....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
Datum:
@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... :-)
Datum:
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ß
Datum:
Angehängte Dateien: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.
Datum:
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.
Datum:
Angehängte Dateien:Vielen Dank für den Bootloader! Funktioniert Super. Im Anhang die angepasste Version für den ATMega88. Gruß Kuen
Datum:
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!
Datum:
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:
Kai Franke
(kai-)
Datum:
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
Datum:
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
Datum:
>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.
Datum:
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
Datum:
@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).
Datum:
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 ;)
Datum:
Angehängte Dateien: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
Datum:
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-)
Datum:
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
Datum:
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
Datum:
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-)
Datum:
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
Datum:
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-)
Datum:
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
Datum:
>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-)
Datum:
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.
Datum:
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
Datum:
Angehängte Dateien: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-)
Datum:
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-)
Datum:
die Grenze scheint bei genau 5kB zu liegen. Unterhalb dieser Codegröße funktioniert das Programm einwandfrei, danach spinnt es rum
Datum:
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-)
Datum:
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-)
Datum:
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-)
Datum:
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
Datum:
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-)
Datum:
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.
Datum:
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-)
Datum:
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-)
Datum:
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
Datum:
>Hat jemand anders eventuell noch eine Idee wie man den Vorgang >beschleunigen könnte? Wie schnell sollte es denn sein ?
Autor:
Kai Franke
(kai-)
Datum:
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
Datum:
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.
Datum:
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
Datum:
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!
Datum:
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!
Datum:
tippfehler bei der angabe der startadresse des bootloaders... sorry :)
Datum:
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!
Datum:
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!
Datum:
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!
Datum:
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!!
Datum:
Funktioniert dieser Bootloader auch für einen ATMega1281? Habe hier nirgends einen Hinweis gefunden?
Datum:
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.
Datum:
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?
Datum:
Hi Leute ! Ich weiß dieser Beitrag ist alt ,aber trotzdem: Könnt ihr mir ein angepasstes Programm für den Atmega 168 reinstellen?
Datum:
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.
Datum:
Kann mir keiner die Wichtigsten unterschiede(programmierteschnisch) posten? dann kann ich nämlich anfangen. Ich Danke schonmal im Vorraus Christian K.
Datum:
@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
Datum:
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.
Datum:
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
Datum:
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
Datum:
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)
Datum:
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
Datum:
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] __________________________________
Datum:
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
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten