Announcement: there is an English version of this forum on So, ich habe jetzt meinen Bootlader unter AVRFreaks ins Web gestellt: http://www.avrfreaks.org/Freaks/freakshow.php?action=2&projectid=191 Hier nochmal die kurze Beschreibung: Nach jedem Reset wartet er 0,2s, ob da ein bestimmtes Wort über die serielle reinkommt. Wenn nicht, dann startet er die Anwendung ab 0x0000. Die Baudratenerkennung erfolgt automatisch (1200...115200Baud). Zum Schnellprogrammieren habe ich mir ein Kommandozeilentool geschrieben, damit man es bequem im Make-File oder in der Compile-Batch mit aufrufen kann. Nach dem Aufruf sendet das Tool ständig das Paßwort an den ATMega, bis der antwortet. Also erst das Tool starten und dann den Resettaster drücken, sonst sind die 0,2s ja vorbei. Bei 115200Baud ergeben sich folgende Programmierzeiten: 15kB (ATMega16): 2,8s 7kB (ATMega8): 1,5s Peter
Passwort: hinterm Username: mond Ist das so richtig, oder ist hier die Codesammlung ?
Hi, ist ja nett, wenn Code zur Verfügung gestellt wird. Aber wie Michael schon bemerkte: Ist nicht hier die Codesammlung?
"Ist nicht hier die Codesammlung?" Ja, hier ist die Codesammlung. Deshalb ist ja auch das Codebeispiel über den angegebene Link erreichbar. Als Dateianhang war das ja damals nicht möglich. Da das ja jetzt wieder geht, hier dann eben nochmal. Änderungen kann ich allerdings nur auf dem obigen Link machen. Peter
Hallo, alle zusammen den Bootloader hatte ich lange zeit verdrängt, da ich nicht so recht wollte... Nun habe ich aktuellen Projekt die ISP-Schnittstelle "vergessen" und mich auf den Bootloader besonnen. Ich konnte die Codesammlung compilieren ( nicht immer selbstverständlich) und in den Atmega16 via angelöteten Kabelsen am SPI-Bus programmieren. In der BOOTLOAD.H steht noch 11.59 Mhz als Clock, habe ich auf meine 4.9152 Mhz geändert- um es vorweg zu nehmen: es geht nicht, bin vielleicht zu blöd, oder mein Rechner schafft es nicht, wenn der bootloader läuft, sich um seine anderen ( auch wichtigen) Sachen zu kümmern. Bei mir schleicht windows, die applikation lässt sich auch nicht so richtig beenden. COM 1 19200 CONNECT FLASHTEST.HEX 0000 - 0000_ <--blink Damit kann ich aber leben, hi. Welche BootLock und Fusebits muss ich denn nun beim mega16 setzen, damit der bootloader auch dort ausgeführt wird, wo er hin muss...??? Naja vielleicht erbarmt sich der eine oder andere und hilft mir aus der patsche. Danke Axel R.
Die Quarzfrequenz dient nur zur Berechnung der Wartezeit, die 11MHz kannst Du ruhig drin lassen. Die Fuses müssen auf "THIRDBOOTSTART" (1E00) gesetzt werden. Das PC-Programm habe ich nur unter Windows 98 getestet. Peter
Hallo Peter erst mal danke für die prompte Antwort. Dachte ich mir schon, das mit der Quartzfrequenz. Ich will ja auch nicht faul sein, und andere für mich denken lassen, ich habe mich also belesen und das mit dem Boot Reset Vector und den einzelnen Einsprungadressen ausprobiert. Funktioniert, wie theoretisch erarbeitet. Der Datei INIT.INC entnehme ich, dass der bootloader normal von org0 startet und dann erst die Vectoren umschaltet. Lasse ich also die Fuse Boot Reset Vector unangehakt? Na, wie auch immer. Mit dem windows2000 scheint's nicht zu laufen, ich teste mal unter 98.. bis denne Gruß an alle AxelR.
Hi, alle zusammen: habe das Problem in den Griff bekommen, der 1.3Ghz AMD und der 3Ghz P4 sind zu schnell, ich bekomme ein Timeout und Programmer Error 2. Ich habe noch ein altes Notebook mit einem 100Mhz 486er, damit geht's auf Anhieb. Ich kann leider den Quelltext nicht neu compilieren, da ich kein "C" habe. Könnte jemand den Timeout im PBOOT.C hochsetzen, bitte? Einen guten Rutsch ins neue Jahr wünscht euch Axel Rühl Potsdam Nochmals danke für die nette Hilfe...
Hallo Peter, ich nochmal: ich habe nun also auch noch meinen 450'er P2 mit Win98 nochmal aufgebaut, man schmeisst ja nichts weg. unter Win98 funktioniertz einwandfrei!!! Ich neheme an, die Art des Zugriffs auf die Serielle Schnittstelle wird von XP und/oder Win2000 so nicht aktzeptiert... Du spricht ja direkt die Register an. ansich nicht schlecht, ich wüsste die register garnicht, die da angesprochen werden müss(t)en. wenn man API- Funktionen nimmt, ob es dann auch unter win2000 und XP geht? Ich habe mit Delphi und der CPort-Komponente ein wenig herumgespielt, da geht das dann über fileCreateFile und so. Ich habe aber nicht soo viel Erfahrung, wie man das nun im einzelnen handeln muss. Nochmal, RESPEKT! Für mich ein Grund mehr, mich intensiver mit der Materie zu beschäftigen. Guten Rutsch an alle Gruß aus Potsdam Axel Rühl
Hallo Axel und Peter, bis jetzt habe ich mich noch nicht mit den Bootloader beschäftigt. Das werde ich aber in den nächsten Tage nachholen ... >Ich neheme an, die Art des Zugriffs auf die Serielle Schnittstelle >wird von XP und/oder Win2000 so nicht aktzeptiert... Probierst du bitte mal allowio von PortTalk/Beyondlogic
Hallo Axel und Peter, bis jetzt habe ich mich noch nicht mit den Bootloader beschäftigt. Das werde ich aber in den nächsten Tage nachholen ... >Ich neheme an, die Art des Zugriffs auf die Serielle Schnittstelle >wird von XP und/oder Win2000 so nicht aktzeptiert... Probierst du bitte mal allowio von PortTalk/Beyondlogic aus ? http://www.beyondlogic.org/porttalk/porttalk.htm Ich habe mal kurz in die Datei "PBOOT.C" hereingeschaut. Sieht ja gar nicht so wild aus ... Womit hast du das ganze denn kompiliert ? >wenn man API- Funktionen nimmt, ob es dann auch unter win2000 und XP >geht? Ich habe schon mal WinIO von www.internals.com eingesetzt. Damit funktionierts auf jedem Fall. Ich werde evtl. eine Win 2000/XP Version schreiben. Ich werde euch informieren ... Die Idee mit den 0,2s und der automatischen Baudratenerkennung ist sehr gut ! Hut ab !!! Gruß Fiffi
Hallo, ich versuche gerade den Bootloader auf einem ATmega128 zum laufen zu bringen ... (2 UARTS, etc ...) Hat das schon mal jemand gemacht ? @Peter Hast du die Dateien "m*def.inc" selbst editiert ? In meinen (AVR-Studio) fehlt nämlich "RAMSTART", "NOINTaddr" ... Wie funktioniert die automatische optimale Baudrateneinstellung ? Funktioniert diese auch noch bei einem Quarz von 16 MHz ? Könntest du mir das pboot Programm bzw. die Kommunikation AVR<->PC bitte mal ein wenig erläutern ? @Axel >Könnte jemand den Timeout im PBOOT.C hochsetzen, bitte? Ich habe das Timeout auf 16 hochgesetzt. Oder wie hoch soll ich dir das Timeout setzten ? Die Datei befindet sich im Anhang. Ich habe es mit Borland Turbo C++ 3.0 für DOS kompiliert. Leider kann ich das Programm nicht testen ... (P4, Win2k, nur ATmega128) Ich habe die PortTalk Beispiele mit Dev-C++ 5 (GCC/MinGW) erfolgreich kompiliert. Der Win2k/XP Version steht also nichts im Weg ... Welche Probleme hast du genau unter W2k/XP ? Nur Timingprobleme oder auch Zugriffsfehler ? >Für mich ein Grund mehr, mich intensiver mit der Materie zu beschäftigen. Ich glaube da komm ich auch nicht herum ... Gruß Fiffi
@Fiffi, die Kommandos sind Texte mit 0x0D abgeschlossen: "\370\360\340\200\374": Start des Bootloaders, muß ständig gesendet werden, bis der Bootloader mit 'a' antwortet. "Reset": Beenden und Start der Anwendung "DM8": Auswahl des Flash "DEM8": Auswahl des EEPROM "FPR1234": Start der Programmierung ab Adresse 0x1234 Danach werden die Daten binär übertragen. 0xA5, 0x00 beendet das Programmieren 0xA5, 0xA5 bedeutet das Byte 0xA5 Nach jeder Adresse 0x***F muß auf ein 'c' vom Bootloader gewartet werden. "READ4321": Lesen ab Adresse 0x4321 Es wird das gelesene Byte binär gesendet. Nach Erhalt von 'c' wird das nächste Byte gesendet, andere Bytes als 'c' beenden das Lesen. Mein PC-Programm kann aber nur programmieren. Mit Windows-Anwendungen habe ich mich noch nicht beschäftigt. Ich benutze noch W89SE und da habe ich keine Einschränkungen für DOS-Programme. Mir war es wichtig, daß das Programm schnell und ohne großes Getöse startet und einfach im Make mit aufgerufen werden kann und auch keine umständliche Bedienung mit der Maus benötigt. Der Programmer im Studio für das STK500 ist ja dagegen eine Zumutung. Den habe ich daher nur zum Setzen der Fuses benutzt. Zum Glück ist ja auch eine Kommandozeilenversion (AVRPROG.EXE) mit dabei, die habe ich dann zum Brennen des Bootloaders benutzen können. Da erspart man sich zumindest die nervigen Mausklicks. Bei 16MHz kann man aber nur bis 38400 Baud einstellen, da sonst der Fehler zu groß wird. Für 115200 Baud sollte man Standardquarze vorziehen (z.B. 14,7456MHz) Die erweiterten *def.inc sind in dem *.zip mit dabei. Peter
Hallo Peter, danke für die Erklärung ! >Mir war es wichtig, daß das Programm schnell und ohne großes Getöse >startet und einfach im Make mit aufgerufen werden kann und auch keine >umständliche Bedienung mit der Maus benötigt. Ich möchte auch nur eine W2k/XP fähige Konsolenanwendung schreiben. Mir ist wichtig einen freeware Compiler zu nutzen ... Gruß Fiffi
@Fifi Ich finde es besser wenn man für die serielle Kommunikation Windows-API-Funktionen verwendet. Der direkte Zugriff auf die UART-Register funktioniert zwar unter Win9x, findet dann aber ausserhalb der Kontrolle des Betriebssystems statt. Unter Win2000/XP ist ein direkter Hardware-Zugriff nur mit PortTalk und ähnlichen Treibern möglich. Als Anhang ein Beispiel Programm wo mittels Win32-API via COM-Port mit einem Modem kommuniziert wird. Kann mit GCC/MinGW kompiliert werden.
Hallo, ich habe den Quellcode ein wenig geändert, um den Mega128 zu unterstützen. Leider funktioniert dies nicht: er stürzt in der Routine "abaud" ab, und macht einen Reset. Kann bitte mal jemand diesen Stand auf einem anderen AVR probieren ? @ Peter Fleury >Ich finde es besser wenn man für die serielle Kommunikation >Windows-API-Funktionen verwendet. Ich auch ... >Als Anhang ein Beispiel Programm wo mittels Win32-API via COM-Port >mit einem Modem kommuniziert wird. Kann mit GCC/MinGW kompiliert >werden. Danke ! So wie es aussieht, muß ich einen neuen Bootloader schreiben, da ich Peter's nicht auf meinem Mega128 zum laufen bekomme. Ich habe z.Zt. leider auch keinen Mega16 o.ä. um zumindest mal den original Code zu probieren. (Ich habe nur einen Mega128 und einen Rechner, wo "PBOOT.EXE" anscheinend nicht drauf läuft ...) Gruß Fiffi
@Fiffi, bist Du sicher, daß der Code auch richtig im Flash gelandet ist ? Es gibt nämlich Programmer, die können nur die ersten 64kB des Mega128 beschreiben, der Bootloader muß aber ganz ans Ende. Die Fuses müßten ja ähnlich wie oben für den Mega16 sein. Achso, Du must natürlich auch die ELPM, EJMP Instruktionen für die Commandotabelle verwenden ! Peter
Angehängte Dateien:
-
fuses.jpg
67 KB
Hallo Peter, >bist Du sicher, daß der Code auch richtig im Flash gelandet ist ? Ja, der Code landet richtig im Flash ab Adresse 0xFC00. >Es gibt nämlich Programmer, die können nur die ersten 64kB des >Mega128 beschreiben, der Bootloader muß aber ganz ans Ende. Ich verwende den JTAGICE. >Die Fuses müßten ja ähnlich wie oben für den Mega16 sein. Im Anhang befindet sich ein Sreenshot ... >Achso, Du must natürlich auch die ELPM, EJMP Instruktionen für die >Commandotabelle verwenden ! Ich verstehe nicht was du meinst. Der Mega128 hat keinen ELPM Befehl. EJMP gibt es nicht, sondern nur EIJMP. Was soll ich den mit den Befehlen tun ? Kannst du evtl. mal über den Code schauen aus meinem letzten Beitrag ? Vielen Dank für deine Hilfe ! Gruß Fiffi
Hallo Peter, ich habe einen Fehler in meinem Code gefunden: ich hatte das define ".equ base = ..." falsch. Beim Mega128 muss es "SMALLBOOTSTART" heißen ... Aber das ändert nicht an meinem Problem, daß "er" mir irgenwo "abhaut" in Richtung Application Code, der überall 0xFF ist. Er verschwindet nicht über die Routine "userprog". Gruß Fiffi
@Fiffi, das mit dem Mega128 ist etwas tricky, in den oberen 64kB zu bleiben. Anbei die neue Include-Datei, damit müßte es klappen. Zumindest die unteren 64kB sollten sich damit brennen lassen und ehe Du die voll hast, dürften schon ein paar Monate vergehen. Dann dürftest Du mit dem Mega128 auch schon so vertraut sein, daß die Erweiterung für die oberen 64kB nur ein Klacks ist. Man könnte z.B. die Adreßangabe für den Programmierbefehl auf 5 oder 6 Hex-Digits erweitern. Da ja immer bis zum 0x0D-Zeichen umgewandelt wird, ist das voll abwärtskompatibel. In der PC-Software muß man dann noch den Segmentrecord mit auswerten, der wird bisher ignoriert. Und auch einen 128kB Puffer alloziieren. Peter
@Peter Fleury, Dein Code hat mich inspiriert, vielleicht doch mal nach Windows zu kompilieren. Leider hat Borland C++ 3.1 diese Modemfunktionen nicht, deshalb habe ich es ja zu Fuß machen müssen. Ich hab noch irgendwo ein Borland C++ 4.0 rumliegen, mal installieren ob das sowas kann. Peter
Hallo zusammen, gut reingerutscht? ich denke ja, fein. Ich habe einen weiteren Grung ausgfindig gemacht, warum's nicht lief: Mein COM3 liegt aud 0xD000 bis D0007 und mein COM4 auf 0xD4000 bis D4007. Ich hatte mir eine Erweiterungskarte einbauen müssen, weil mein neuer Rechner die Seriellen , bis auf COM1 "ausgeschwitzt" hatte, jaja ohne Schweiß keinen Preis, selbst schulz. Teilen sich beide Interrupt 19. Timeout hochgesetzt, danke. Bringt auch nichts. Trotzdem,. versuch macht kluch... Da stehe ich mit meinen Delphi und Pascal-Dialekt wohl ziemlich allein auf weiter Flur, wie es scheint. Nicht das ich mit C nichts am Hut habe, schon von Arbeit wegen, jetzt aber umlernen?? ich portiere das mal die PBOOT.C als ganz normales Windows-Programm unter Delphi6 für alle Mausklicker. die seriellen Schnittstellen sind, wie es scheint, im gegensatz zur Parallelen nicht vom Zugriff durch XP gesperrt (API-Funktionen vorausgesetzt). Dann ist auch die Adresse egal. Wenn ich die Timer-und ModemEvents in die Konsolenanwendung untergebracht habe,(das ist das ,was ich nicht hinbekomme) mach ich uns noch 'ne XP-Kommandozeilen Variante mit Delphi-Pascal. Erst mal habe ich meinen W98-Rechner wieder angemacht, funktioniert ja einwandfrei, gibt also eigentlich keinen Grund zur Hektik... Grüsse an alle und viel Spass noch Axel
Hallo, @Peter Vielen Dank für deine Hilfe! Ich sehe ein, daß ich mich erst mal mit der Bootloader Geschichte an sich vertraut machen muss, bevor ich deinen Code zum laufen bekomme. Ich werde versuchen ein Assembler Programm mit fester Baudrate zu schreiben, und dabei die Grundlagen lernen ... >Ich hab noch irgendwo ein Borland C++ 4.0 rumliegen, mal installieren >ob das sowas kann. Kennst du Dev-C++ von Bloodshed ? Schau mal unter http://www.bloodshed.net/devcpp.html Es enthält eine IDE und den GCC/MinGW. Ich würde mich über eine Version für einen Freeware Kompiler freuen ... Die Kommandozeilenversion von Borland C++ 5.5 ist Freeware. Schau mal unter: http://www2.pmf.fh-goettingen.de/~isimon/Informatik/CompilerHowto/BorlandundCrimson.htm @Axel >Da stehe ich mit meinen Delphi und Pascal-Dialekt wohl ziemlich >allein auf weiter Flur, wie es scheint. Ich kann leider nur C/C++ ... Ich wollte aber auch schon immer mal in Delphi reinschauen ... Gruß Fiffi
Ich habe mir vor einiger Zeit mal eine Klasse in C++ sowohl für den C++-Builder von Borland als auch den dev-c++ geschrieben, mit der ich Daten über die serielle senden und empfangen kann. Damit habei ich das C-Programm (PBOOT.C) von Peter ziemlich einfach umschreiben können, so daß der Zugriff auf die serielle jetzt nur noch über API-Funktionen läuft. Da ich zur Zeit keinen Mikrocontroller zur Verfügung habe, geschweige denn einen ATMega, kann ich das nicht komplett testen. Das Programm läßt sich kompilieren, sendet den Initialisierungsstring über die serielle des PC raus und wartet darauf das was zurückommt. D.h. der Balken dreht sich ständig. Mehr war mir nicht möglich zu überprüfen. Falls jemand Interesse hat und das ganze weiter testen will, bitte melden. Ich würde das Programm dann mit Quellcode mailen. Wenn es einmal läuft, läßt es sich auch ziemlich einfach auf Windows-Click erweitern.
Hallo Andreas, >Falls jemand Interesse hat und das ganze weiter testen will, bitte >melden. >Ich würde das Programm dann mit Quellcode mailen. Natürlich haben wir Interesse ! Kannst du bitte hier ins Forum stellen oder mir mailen ? Gruß Fiffi
Hallo Fiffi, was machst Du denn um 02.40 Uhr noch hier? Hatte das Programm gerade fertig gestellt und dann noch eben gepostet. Aber nicht erwartet, daß kurz danach noch jemand antwortet. Zur Zeit habe ich das nur für den gcc (also dev-c++) lauffähig. Für den C++-Builder war mir dann doch gestern abend zu spät. Wenn Dir das reicht, setze ich es heute nachmittag rein. Ansonsten würde ich das erst noch für den Builder hinbasteln und beide Versionen bringen.
Hallo Andreas, >was machst Du denn um 02.40 Uhr noch hier? Ich habe Urlaub ... >Wenn Dir das reicht, setze ich es heute nachmittag rein. Natürlich ... (Ich komme erst heute abend dazu, mich damit zu beschäftigen ...) >Ansonsten würde ich das erst noch für den Builder hinbasteln und >beide Versionen bringen. Kann man die Version dann mit der 5.5 Freeware Version kompilieren ? Gruß Fiffi
Habe es doch schon für den Builder hingebastelt. Ging einfacher als ich befürchtet hatte. Ich denke nicht, daß es ohne weiteres für den Borland-Freeware funktioniert. Den habe ich zwar, aber bisher nicht installiert. Habe ich derzeit auch nicht vor weil man für den gcc einfach mehr Quellcode findet wo man sich dran orientieren kann. Ich habe nur Probleme mit dem Debugger, daher benutze ich nachwievor den C++-Builder. Geh doch einfach auf: http://www.bloodshed.net/ und download den dev-c++ mit dem mingw-Compiler. Ich habe das mit dem dev-c++ 4.9.8.4 compiliert. Beim Borland war es der C++-Builder 5. Damit man erkennen kann, was Peter an den verschiedenen Stellen vorhatte (und wo ich Fehler reinprogrammiert habe) sind alle Zeilen die ich rausgenommen habe auskommentiert. Ebenso hinter meinen neuen Zeilen befindet sich das Datum. Wenn das Programm mal einwandfrei läuft muß dies alles noch bereinigt werden. Vorher möchte ich das auch nicht mit Windows-Fenstern versehen. Weil erstmal die eingentliche Funktion einwandfrei sein sollte. Falls Fragen sind melde Dich einfach nochmal. Ich werde Dir auch eine email schicken. Dann hast Du meine email-adresse. Wegen laufend unerwünschter email habe ich mir abgewöhnt überall meine adresse mit anzugeben.
@Fiffi und gehts nun mit dem neuen Include ? Es kann ja nur an dem Commandointerpreter gelegen haben, denn das ist die einzige Funktion, die IJMP verwendet. Und für das ELPM mußte noch das RAMPZ geladen werden. Peter
Hallo, @Andreas Ich kann das Programm kompilieren, bekomme aber eine Warnung, da alloc.h in pboot.cpp includiert wurde: \Dev-Cpp\include\c++\backward\backward_warning.h:32 #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <sstream> instead of the deprecated header <strstream.h>. To disable this warning use -Wno-deprecated. Bringt er die Warnung, da wir malloc() nutzen ? Sollten wir es auf new/delete umstellen ? Ich kenne Dev-Cpp leider noch nicht lange ... @Peter >und gehts nun mit dem neuen Include ? Ich habe heute einen Mega16 bekommen, mit dem ich zuerst mal die W2k/XP Version des PBOOT.EXE Programms zum laufen bringen möchte. Danach werde ich das AVR-Programm für den Mega128 anpassen ... Ich halte euch auf dem laufenden ... Gruß Fiffi
Hallo, ich habe den Mega16 @ 8MHz mit Peters original Code und original PBOOT.EXE geflasht. (Win2k, P4 1,6GHz). >>COM 3 at 38400 Baud: Connected >>Program m16test.hex: 0000 - 0001 >>Programming successful Leider funktioniert das Programm von Andreas noch nicht. Ohne AVR-Reset dreht sich der Pfeil/Zeiger nach dem Anfruf schnell, wird dann langsamer und bleibt dann stehen. ein RESET des AVR's hat keine Wirkung. Andreas, hast du eine Idee was das sein kann ? Gruß Fiffi
Diese Warnung hatte ich nicht. Verstehe ich auch nicht. Was sein könnte, daß bei einem neuen dev-c++ auch ein neuerer mingw dabei war. Ich erinner mich daran, daß bei einer älteren Version vom dev-c++ wieder auf den alten mingw 2.9.??? zurückgegangen wurde, weil der neue Fehler hatte. Die ganzen malloc-sachen usw. konnte ich nicht testen, da kein AVR dran. nimm einfach statt alloc mal malloc rein. Es hätte mich auch gewundert, wenn es auf Anhieb geklappt hätte. Mir war z.B. folgendes in Peter´s Programm nicht klar: if( !ComPort ) return COMMAND_DONE; Daraus habe ich das: if(Mikrocontroller1->GetHandle() == NULL) return COMMAND_DONE; gemacht, weil ich das so verstanden habe, wenn die Schnittstelle nicht geöffnet ist, bzw. kein Port angegeben, dann wieder raus aus Emfpang(). Aber was ich nicht verstanden habe ist dann das: sendstring( "\370\360\340\200\374" ); if( empfang( 0 ) == COMMAND_DONE ){ printf("\bConnected\n"); In der Funktion connect() wird das ausgeführt. Mir war nicht klar wieso bei COMMAND_DONE wieder rausgegangen wird. Es sei denn, der Mikrocontroller schickt ein 'a' zurück wenn er sich beim PC meldet. Was gleich wie COMMAND_DONE wäre. Dann könnte ich das wieder verstehen. Das weisst Du aber besser, da Du den Controller mit Quellcode hast. Kannst Du mal Hilfsanzeigen rein machen oder den Debugger benutzen? Ich habe den Debugger vom dev-c++ nie richtig benutzt weil der unter NT eine Macke hat. Ich benutze immer den vom Borland-Builder. Habe mir allerdings mal sagen lassen, dass der vom freeware auch mit dem gcc bzw. mingw-dateien funktionieren soll. Die Frage ist jetzt, was macht das Programm während dem drehenden Balken bzw. wenn es (und welches) das erste Zeichen empfangen hat. Die Klasse für die serielle habe ich schon mehrfach eingesetzt. An der kann es eigentlich nicht liegen. Aber man weiss ja nie.
Hab noch was vergessen zu der Warnung. Ich habe mir Deine Fehlermeldung mal genauer angesehen. Es könnte aber das sein: #include <string.h> das es jetzt so: #include <string> sein muss. Mit new/delete geht es auch. Ist natürlich mehr Arbeit. Halte ich auch nicht für notwendig da es ja vorher funktioniert hat. Immer getreu dem Motto "Never touch a running system". Der Compiler motzt ja auch nur an, das ein veralteter Header reingenommen wurde. Beim AVR-gcc hat der aber genauer gesagt, welcher Header alt ist. Kannst Du das mal versuchen näher rauszufinden.
@AndreasH
das mit dem:
if( !ComPort )
return COMMAND_DONE;
ist nur zum Debuggen drin. Damit habe ich getestet, ohne wirklich immer
mit dem AVR verbunden sein zu müssen.
Sobald eine COM ausgewählt ist, enthält ComPort die Adresse und ist
ungleich 0.
Peter
Hallo Andreas, >nimm einfach statt alloc mal malloc rein. wenn ich malloc.h anstatt alloc.h inkludiere, bekomme ich keine Warnungen mehr. Ich hatte mir Dev-c++ 4.9.8.0 heruntergeladen, und habe ihn gestern auf 4.9.8.5 upgedated. (Online-Update) >Aber was ich nicht verstanden habe ist dann das: > sendstring( "\370\360\340\200\374" ); > if( empfang( 0 ) == COMMAND_DONE ){ > printf("\bConnected\n"); Ich verstehe es auch nicht ! Peters Version und meine selbstkompilierte Verion (mit Borland Turbo c++ 3.0) senden nach ihrem Aufruf unterschiedliche Daten ! (Sie funktionieren aber beide ???!!!) Siehe die beiden Dateien im Anhang. ("peter_out.txt" und "tc30_out.txt") Kannst du mir das erklären Peter ? Um die Dateien zu erstellen, habe ich "Termial v1.9b - 20030716 - by Br@y++" mit folgenden Einstellungen verwendet: Com3, Baudrate 38400, 8 Datenbits, kein Paritybit, 1 Stopbit, kein Hanshaking. Als Verbindung habe ich folgendes: RxD und TxD gekreuzt, GND verbunden, alle anderen Pins offen. COM1 und COM2 sind auf dem Mainboard, und haben die Standardadressen: 0x3f8 unf 0x2f8 ... COM3 und COM4 ist eine PCI-Karte mit Netmos Chip. COM3 hat folgende Resourcen: E/A: D400-D407 IRQ: 9 Ich vermute die DOS-Box emuliert dann die Adresse 0x3e8 ... ? Meine selbstkompilierte Version sendet mit der sendstring Zeile folgendes (hex): 0xF8 0xF0 0xE0 0x80 0xFC 0x0D >Ich habe den Debugger vom dev-c++ nie richtig benutzt Er ist eine reine Katastrophe ... Ich habe den Fehler nochmals untersucht: Ich führe dein Programm immer mit den Argumenten "-c3 -b38400 -pm16test.hex" aus. Ich habe nun zu Testzwecken folgendes: An COM2 hängt ein JTAGICE, mit dem ich den AVR debuggen kann. COM1 ist mit COM3 verbunden. (An COM1 läuft ein Terminal Programm) Wenn der AVR und das JTAGICE aus ist, dreht sich der Blaken ständig. Ich empfange an COM1 aber nichts ! Wenn der AVR und das JTAGICE (COM2 !) an ist, tritt das Phänomen mit dem langsamer werdenden Balken auf. Ich empfange an COM1 aber nichts ! Hast du eine Idee irgendeine Idee ? Wie hast du das Programm probiert ? Kannst du mir mal deine binär Datei per Email schicken ? (Im Anhang befindet sich meine aktuelle pboot.cpp) Gruß Fiffi
Hallo, die habe einen Fehler gemacht !: Peters Programm und meine selbstkompilierte Version geben dasselbe aus. Beim erstellen der Dateien (oben im zip-file) habe ich Peters Programm falsch aufgerfen "pboot -c3 b38400 -pm16test.hex". es läuft dann mit 57600 Baud. Bei korrektem Aufruf mit "pboot -c3 -b38400 -pm16test.hex" empfange ich daselbe wie in der Datei "tc30_out.txt". Aber unsere Dev-C++ Version sendet nichts ... Ich bin auch mal durch die Klasse durchgesteppt, dort wo auf Fehler überprüft wird, ist angeblich alles OK. Gruß Fiffi
@Fiffi:
>>Wie hast du das Programm probiert ?
Wen meinst Du damit? Mich oder Peter?
Falls Du mich meinst ich habe das Programm heute nochmal getestet. Aber
nur soweit, daß ich sehe ob was gesendet wird. Ich habe einen
Schnittstellentester angeschlossen und bin dann mit dem Debugger vom
C++-Builder drangegangen. Mehr konnte ich nicht testen, da ich nichts
dahinter habe.
Ich habe aber festgestellt, daß hierbei: sendstring(
"\370\360\340\200\374" ); was rausgeschickt wird.
Habe gerade nochmal den Debugger vom Builder angeschmissen. Es sind
exakt die selben Zeichen wie in Deiner TXT-Datei.
Irgendwie verstehe ich Deine Aufzeichnung noch nicht. Laut dem Code in
PBoot.c wird immer der String "\370\360\340\200\374"
rausgeschickt.
Das sind 5 Byte. Einschliesslich des CR am Ende sind es dann 6 Bytes.
Da bis zum Erkennen der Antwort des Controllers dies in einer Schleife
läuft, würde sich das mit jedem 7.Byte wiederholen.
Dies stimmt auch mit Deiner Aufzeichnung des von Dir compilierten
Programms überein (F8 F0 E0 80 FC 0D).
Wenn ich mir jetzt die Aufzeichnung ansehe, die Du mit Peters Programm
gemacht hast, dann ist immer nach 4 Byte eine Wiederholung. (3C 07 7E
E4).
Wobei der Anfang ganz anders ist (3C 38 E6 22). Also irgendwie bin ich
zu blöd das zu verstehen. Ein CR sehe ich überhaupt nicht.
Während es in Deiner Aufzeichnung vorhanden ist.
Der Compiler wandelt das "\370\360\340\200\374" in einzelne
Bytes um. Wie die Umrechnung funktioniert weiss ich im Moment nicht.
Habe ich mal irgendwo gelesen.
Im Moment gibt aus meiner Sicht zwei Probleme:
Zum einen muß klar sein, was aus diesem String werden soll bzw. was
will der Controller genau haben. (Sollte aus dem Quellcode des
Contorllers hervorgehen. Habe im Moment nur keine Zeit mir das genau
anzusehen, da ich noch eine Software schreiben und ein Angebot für eine
größere Sachen machen muß). Dies ist aber erstmal das kleinere Problem,
da die Anzahl der Bytes mit dem Quellcode übereinstimmt.
Zum anderen muß der Unterschied zwischen dem von Dir compilierten und
Peter´s geklärt werden. Hier stimmt die Anzahl der Bytes nicht. Dies
sollte erstmal geklärt werden.
Ich kann Dir meine Binär-Datei schicken. Das Ergebnis wird dasselbe wie
bei Dir sein.
Grüße
Andreas
@Fiffi: Mist hatte bei mir etwas länger gedauert mit dem Schreiben weil ich parallel zum Schreiben nochmals mit dem Debugger durchgegangen bin. Ich habe das mit dem Borland C++Builder und dem Debugger getestet. Bei mir kommt was raus. Habe ich auch auf dem Schnittstellentester gesehen. Wie bist Du denn da durch gesteppt. Mit dem Debugger vom dev-c++? Wenn Du willst maile ich Dir mal diese Version. Damit ich den Schnittstellentester nicht umstellen muß, aber auf 9600 Baud eingestellt. Mußt also die richtigen Parameter übergeben. @Peter: Dachte schon, daß hätte einen anderen Sinn, den ich nicht verstehe.
Hallo Andreas,
die beiden Programme geben das selbe aus. Mein Fehler, wie oben
beschrieben ...
>Wie bist Du denn da durch gesteppt. Mit dem Debugger vom dev-c++?
Ja, ich habe im Menü Projekt -> Projekt Optionen ->
Tab-Seite: Compiler -> Zeile: Linker -> "Generiert
Fehlersuchinformationen" auf "Yes" gestellt.
Er erzeugt nach erneutem kompilieren eine exe-datei mit 1,86 MByte !
Dann habe ich den besch******* Debugger im Dev-C++ verwendet. Mit
"Fehlersuche" "Ausführen bis Cursor" ...
In dem Debugger / Frontend sind viele Bugs ... (Manchmal macht er keine
Haltepunkte, oder bleibt dort nicht stehen, ganz zu schweigen von der
tollen "Watch" Funktion ...
Kann ich die erzeugt exe noch mit irgendetwas anderem außer Dev-C++
debuggen ?
Welche Windows Version benutzt du ?
Kannst du das Programm bei dir mal mit einem gekreuzten Kabel über eine
zweite serielle Schnittstelle testen ?
Kannst du es evtl. mal mit der hex-datei aus dem Anhang probieren ?
(ist ein fast leeres main() ...)
Gruß
Fiffi
Hallo Leute! Ich habe jetzt keine Lust mir alle Beiträge erst durchzulesen... Ich habe den Programmer nach Linux portiert, siehe Anhang. Funktioniert ganz gut, evtl. kann ihn jemand gebrauchen. @peter Wenn du möchtest, kannst du ihn mit in dein ZIP file tuen. MfG Sascha
Hallo Sascha, >Ich habe den Programmer nach Linux portiert, siehe Anhang. Danke! Ich bin vor ein paar Wochen auch umgestiegen auf Linux. Peter hat den Bootloader erweiert. (siehe Anhang) Hier seine Mail an mich: > Anbei eine neue Version des Bootloaders. > Jetzt ist Verify und CRC-Check mit drin: > 0 = CRC o.k. > -2 = CRC Fehler > -1 = CRC nicht unterstützt (alter Bootloader) > > Read ist auch im AVR drin, nur im PC-Programm fehlts noch. > Mit "RSIZE" kann der PC abfragen, wieviel Flash / EEPROM er > überhaupt lesen muß. > Mit "RSIG" kann er die Signatur abfragen, d.h. was für ein AVR > es ist. > > Für den Mega128 ist auch schon das Einlesen der Adresse auf > 20 Bit (= 5 Hex-Digits) erweitert. Leider habe Ich zur Zeit keine Zeit zum testen, da ich am renovieren bin... Kanst du den neuen Bootloader evtl. mal testen, und dein Linux Programm erweitern ? Gruß Fiffi
Hi! wunderbar... der werde ich mich wohl am Wochenende mal drüber machen. MfG Sascha
Hi, damit das Thema nicht "abkühlt". Also ich hab das jetzt aufmerksam verfolgt, wollte aber den Code nicht verwenden sondern selber lernen. Allerdings gibts da schon so einige Probleme bei mir. Prinzipiell kann ich den bootloader schon mal nicht compilieren wegen der .if anweisung in macro out_ext usw. aber das könnte ich ja auslassen weil es ja eh nur für meinen uC ist. Ansonsten knack ich das nicht mit dem Sprung nach $0000, hab was kleines geschrieben um die Geschichte zu testen. Aber nach dem Sprung , wenn er denn passiert, geht nix mehr. Ist im Anhang. Wollte das eigentlich nicht übertreiben mit dem Bootloader aber das frisst mir ja die Zeit weg. Wollte eigentlich in Delphi nen Progger für USB schreiben aber jetzt häng ich schon ewig an der ASM-geschichte rum. Jetzt frag ich mal euch. Hab das zwar schon in "allgemein" gepostet , aber dort antwortet mir schon auf einige Fragen keiner mehr. Kann nur heißen , dass die Frage unsinn oder uninteressant ist ?!?!?!.
So ich bin jetzt auch XP-Benutzer (Aldi-PC). Werde mich also mal daran machen, daß das PC-Programm XP-fähig wird. Kann doch nicht so schwer sein. @Uwe, also in meinem Code ist doch gar kein .if drin. Nach dem Sprung nach 0x0000 kann doch nur dann was passieren, wenn Du auch was runtergeladen hast. Nach dem der Bootloader z.B. mit dem STK500 reingebrannt wurde, ist darunter doch alles gelöscht. Peter
Ich will mal meine neuesten XP-Erfahrungen berichten: Also man kann auch unter XP ohne irgendwelche Treiber im DOS-Fenster (mein uralt Norton Commander geht auch noch) direkt mit inportb() und outportb() auf die UART zugreifen. Der Unterschied, es geht nur sehr langsam. Ich habe einfach die Timeouts in dem Bootloader drastisch erhöht und dann konnte ich auch den Mega8 unter XP proggen. Allerdings dauern die 7kB jetzt nicht mehr 1,5s sondern 49s, egal ob ich 115200 oder 9600 Baud nehme. Ich werd mal weiter forschen, ob ich rauskriege, wo die Zeit verloren geht. Peter
So, ich habe jetzt rausgekriegt, daß es elend lange dauert, bis ein Byte zum ATMega gesendet wurde und dann dessen Antwort wieder im PC angekommen ist. Könnte es vielleicht sein, daß die UART garnicht echt ist, sondern über den USB simuliert wird ? Denn nur durch die langen Latenzzeiten des USB sind solche Verzögerungen erklärlich. Da muß ich wohl nochmal drastisch am Bootloader feilen und z.B. in 1kB Paketen senden. Peter
Hi warum sollte die RS232 über den USB gehen? In den üblichen SuperIO-Bausteinen ist allerdings auch ein FIFO drin. Da dein "direkter" Portzugriff wahrscheinlich von OS abgefangen wird kann es durchaus sein das die Daten die vom µC zurückkommen erstmal eine Weile im FIFO des SuperIO-Bausteins bleiben bis sich das OS bequemt da mal wieder vorbeizuschauen. Schau dir doch einfach mal das Zeitverhalten mit dem Skop an. Allerding ist der Zugriff per outp() und inp() unter einem modernen OS wie XP natürlich eine Krücke. Da macht man das über API-Funktionen des OS. http://www.siwawi.arubi.uni-kl.de/avr_projects/index.html#avrdudew32 ist evtl. einen Blick wert. Matthias
>...ist evtl. einen Blick wert.
und falls "draufgeblickt" und der W32-Native-Port nicht funktioniert,
bitte einen Fehlerbericht zumailen (Adresse unten auf der genannten
Seite). Danke, Martin
Ist ja gut gemeint, aber mir raucht schon der Kopf vor AVRDude, Cygwin, Visual C++. Ich wollte ja auch eigentlich in der Kommandozeile bleiben und nicht immer mit "lots of bells and whistles" extra Windows-Fenseter aufmachen. Ich hab mal IO.DLL von Fred Bulback probiert, aber außer "Schutzverletzung blablabla" ist da nichts weiter bei rausgekommen. Im Prinizp geht das Senden und Empfangen ja, bloß da ist eben eine riesenlange Latenzzeit dazwischen. Bevor ich das Paßwortsenden ohne Delay gemacht habe, hatte XP schon etwa 104 mal das Paßwort im Puffer, ehe die Antwort vom AVR zurück kam. Ich mußte also noch 104 mal das 'a' zurücklesen, ehe der Empfangspuffer wieder leer war. XP hat da also außer den 16 Byte FIFO noch einen riesen Softwarepuffer dazwischen. Deshalb eben auch mein Verdacht mit dem USB. Da ich also mit IO.DLL gründlich auf die Nase gefallen bin und Cygwin und Konsorten nur bömische Dörfer für mich sind, werde ich mal noch an dem Protokoll feilen, d.h. größere Pakete austauschen, um wenigstens wieder unter 10s für die 7kB zu kommen. Peter
Hallo alle Hat von euch schon mal einer einen Bootloader für die RS 485 Schnittstelle geschrieben? Ich bin in C bzw. in ASM praktisch nicht zu gebrauchen und wäre für ein Stück ASM Code zum Initialisieren der Schnittstelle (Mega 8/128), senden mit umschaltung und empfangen richtig dankbar. Wäre super wenn da schon mal jemand ... Werner
RS-232 und RS-485 unterscheiden sich doch nur durch den Typ des Leitungstreibers. Allerdings geht RS-485 immer nur mit einem zusätzlichen Protokoll, da es ja den Anschluß mehrerer Devices erlaubt. Das Protokoll muß dann entweder die Adressierung verschiedener Slaves oder den Umlauf des einzigen Sendertokens sicherstellen. Den RS-485-Bootloader kann es also nicht geben, da es auch nicht das RS-485-Protokoll gibt, sondern viele verschiedene. Wenn Du also schon RS-485 benutzt, mußt Du dafür ja irgendeine Protokollbibliothek haben. Und dann brauchst Du nur noch diese Protokollbibliothek an irgendeinen RS-232 Bootloader ranpappen. Peter
Wenn Du allerdings nur eine 2-Punkt Verbindung brauchst, geht RS-485 (4-Draht) auch Full-Duplex ganz ohne Protokoll wie eine RS-232. Peter
Danke für die Prompte Antwort Die RS 485 hat nur eine 2 Punkt-verbindung bei der Programmierung. Verhält sich also im Prinzip wie eine RS 232 Schnittstelle. Das Protokoll ist wie bei der RS 232. Mir geht es Hauptsächlich um die Sende-und Empfangsumschaltung des Treibers. Werner
eine Moeglichkeit fuer die Umschaltung ist eine ISR fuer "UART TX complete" einzusetzen und darin den RS485 Baustein von senden auf empfang umzuschalten. Loest zwar nicht alle Probleme, aber erspart zumindest ein Delay.
So nun läuft er bei mir auch unter Windows98 und unter Windows-XP. Das Protokoll mußte dafür geändert werden. Es werden jetzt immer 512 Bytes gesendet und dann am Stück programmiert. Nur ein Byte ändern ist natürlich weiterhin möglich. Um das Programm einfach zu halten, wurde nicht auf Geschwindigkeit optimiert. D.h. erst nachdem alle 512 Byte empfangen wurden, wird programmiert. Die Programmierzeiten haben sich etwas verlängert: ATMega8: 2,4s ATMega16: 3,4s Wird der EEPROM geschrieben, dauert das etwa 5s je 512 Byte, da ja je Byte 8,5ms Schreibzeit nötig sind. Peter
Nur aus Interesse: Warum werden in der Programmiersoftware (Windows-Seite) outportb() und inportb() zum Zugriff benutzt und nicht die Windows-API-Funktionen fuer die serielle Schnittstelle? Ist das ein Kniff, um die Geschwindigkeit zu steigern? Funktioniert das Windows-Programm ohne speziellen Port-Treiber und auch fuer Nutzer ohne Administrator-Rechte unter XP? Martin
"nicht die Windows-API-Funktionen" Dazu müßte es ja eine Windows-Exe sein. Ich benutze Borland C++ 3.0, das soll ja theoretisch sowas können. Ich habs auch versucht und nach vielen Stunden entnervt aufgegeben. Dabei bin ich auch nicht ansatzweise in die Nähe einer rudimentären Funktionalität gekommen. Dafür wurde ich mit Schutzverletzungen und tonnenweise anderer Fenster bombardiert obwohl ich ja die Ausgaben in der gleichen DOS-Box haben will. Das inport() und outport() läuft bei mir sehr zuverlässig auf dem Aldi-PC. Das Windows scheint die Ein-/Ausgaben nur sehr lange zu puffern und dadurch funktioniert die "ein Byte hin/her" Methode nur sehr langsam. Mit der "512 Byte hin" Methode gehts aber, da fallen die Pufferzeiten dann nicht mehr ins Gewicht. Peter
P.S.: Das inport() / outport() ging von Anfang an, ich habe dazu keinerlei Treiber geladen, der PC ist noch in der Original-Konfiguration. Da ich der einzige Benutzer bin, nehme ich mal an, ich bin der Administrator. Es grassiert ja wieder eine PC-Grippewelle, aber ich hatte rechtzeitig das Update gemacht. Meinen Kumpel hats erwischt, ich mußte ihm erst eine CD brennen, da der Virus ja immer beim Download runterfährt. Peter
Hi @Peter Hast du WINAVR installiert? Das lädt AFAIK automatisch irgend einen Treiber der inp() und outp() ermöglicht. Ohne diesen Treiber sollte ein WinNT diese Aufrufe mit einer Fehlermeldung quitieren. Matthias
Solche Gemeinheiten traue ich WINAVR nicht zu, daß es ungefragt im System rumpfuscht. Ich habs außerdem nicht neu installiert, sondern nur vom alten W98-PC kopiert. Peter
Vielleicht könnte mal ein anderer XP-Benutzer meine PBOOT.EXE ausprobieren. Ich hab jetzt noch eins draufgesetzt und mir ein USB-RS232 Kabel gekauft, das meldet sich als COM4 an. Was soll ich sagen, einfach "PBOOT.EXE -C4 -PTEST.HEX" aufgerufen und läuft super. Die Programmierzeit ist dann 9s für 7kB (ATMega8), geht ja noch. Man muß allerdings das USB-Kabel reinstecken, bevor man das DOS-Fenster öffnet und erst rausziehen, nachdem das Fenster wieder geschlossen ist. Die DOS-Entwickler haben wohl nicht damit gerechnet, daß eine COM während des Betriebs erscheinen und wieder verschwinden kann. Ich hab jetzt nichts mehr gegen W-XP, hätte also das W98 schon früher entsorgen können. Peter
Peter ich kann dich verstehen ... Viele Leute sind mit dem zufrieden was sie kennen/läuft, aber haben wenig mut was neues auszuprobieren. Im nachhinein sagen alle: HÄTTE ICH SCHON FRÜHER .... FAZIT: ÖFTERS MAL WAS NEUES PROBIEREN wie wärs als nächstes damit: http://www.gnu.org/directory/All_GNU_Packages/commoncpp.html damit auch Linuxer, macOS'ler und DOSer in den Genuß deiner Programme kommen. hier noch ein schönen OPEN-SOURCE Compiler: http://www.bloodshed.net/download.html die Zukuft liegt in LINUX. dort ist jeden Tag "patch-day" :---------) den Luxus sollte man/frau sich gönnen. schönes Wochenende Gruß MARC
Hallo, ich hoffe das ist jetzt keine allzu dumme Frage aber was muss ich genau über das uart senden zum Programmieren? also soweit ich das verstanden habe muss ich ein Zeichen senden, bis der AVR antwortet und dann? das hexfile so senden??? oder wie muss ich das verstehen?
Nein, da ist ein eigenes einfaches Protokoll drauf. Die Kommandos werden als Text gesendet und die Daten binär. Würde man die Daten als Intel-Hex senden, würde sich die Programmierzeit etwa auf das dreifache verlängern. Peter
Hi, hab jetzt endlich den Bootloader hinbekommen. Leider hatte ich ein paar Probleme. Ich benutze den Mega8 mit internen RC Oszillator (4Mhz) unkalibiert. pboot.exe habe ich mit folgenden Commands gestartet: /B9600 /C1 /Pmain.hex Unter diesen Voraussetzungen hat er keinen Com Teilnehmer gefunden. Ich hab zum testen den mal ein 7,3728Mhz XTAL angeschlossen und wolla es funktionierte freu Ich wollte jetzt die Autobauddetecion rausnehmen und die Baudrate 9600 festeintragen. Vielleicht hat jemand noch ein anderen Tipp . Mfg Dirk
Beim unkalibrierten RC-Oszillator kannst Du keine feste Baudrate eintragen, da Du ja die Frequenz nicht kennst. Versuchs mal mit 4800Baud, obs dann klappt. Kann sein, daß die Frequenz so ungünstig liegt, daß 9600 noch zu fehlerhaft ist. Beim Quarz 7,3728MHz kannst Du bis 115200 Baud gehen. Peter
Hi, ich habe jetzt fest 9600 Baud eingetragen und es funktioniert einwandfrei. Mfg Dirk
Hat schon mal jemand das ganze für einen ATMega32 mit dem Terminalprogramm für Linux getestet? Wie compiliere, assembliere ich das ganze unter Linux?
Falls richtig verstanden, ist die "Ansteuersoftware" fuer Peters Bootloader ein "DOS-Programm". Unter Linux gibt es die Moeglichkeit, einen AVR109 kompatiblen Bootloader mit avrdude anzusprechen. Jedoch hat der Bootloader nach AVR109 kein "autobauding" und auch keine automatische "Bootloader-Start-Erkennung" wie Peters Entwicklung.
Ich habe probleme den Bootloader unter Linux zu compilieren. Kann mir jemand ein Makefile mailen oder hier posten?
Hallo, ich habe gerade mal den Bootloader für meinen mega8 ausprobiert, es läuft einwandfrei, aber nur das flashen. Die Application macht jetzt allerdings Schwierigkeiten. Nach einem Reset funktioniert es noch einwandfrei, aber wenn ich die Power unterbreche, erhalte ich seltsame Ergebnisse. Der INT0 verhält sich leider etwas anderst als erwartet. Kurz zur Schaltung: ich benutze einen PCF8583 als realtime und auf INT0 wird ein Signal ausgegeben, wenn die Alarmzeit erreicht wird. Also, wenn ich einen reset mache gehts. nach dem aber Power kurz trennt wird scheint ein Interupt ausgelöst zu werden. hat irgendjemand eine Idee ? Nochmal ohne Bootloader funktioniert die Hardware und das Programm einwandfrei. Das Programm ist ca 6 K groß. Mfg Harald
Hallo, vielen Dank an Peter Dannegger für den Bootloader und Sascha Biedermann für die Linux-Portierung. Funktioniert erstklassig (getestet mit ATMEGA8), in Zukunft werde ich wohl öfter den Bootloader einsetzen. :-) Auch wird es Zeit den On-board IR-Port mal mit nem MAX232 als zweiten RS232 Port zur Verfügung zu stellen. Hier nochmal eine Step-by-Step Anleitung (unter Linux) weil ich mir bei manchen Punkten doch etwas unsicher war. Villeicht hilft dies ja dem einen oder anderem Leser: 1. AvrStudio3 herunterladen. astudio3.exe Datei mit WINE öffnen und in ein Verzeichnis entpacken Im entpacktem Verzeichnis die SETUP.exe wieder mit WINE öffnen und den Installationsanweisungen folgen. 2. Aus diesem Thread bootload.zip und linux.tar.gz downloaden und beide in jeweils einen eigenen Ordner entpacken. Der Einfachheit halber temporär die Dateien fürs compilieren (aus bootload.zip) in das Verzeichnis vom installiertem AVRStudio kopieren - ins gleiche Verzeichnis, in der sich auch die avrasm32.exe befindet. 3. Eine Konsole öffnen und in das Verzeichnis in dem sich avrasm32.exe befindet wechseln. In der Datei BOOTLOAD.H die Konstante xtal an die eigene Quarzfrequenz anpassen. -> wine avrasm32.exe -fI M8BOOT.ASM <- ausführen (für MEGA8). Für einen ATMEGA16 entsprechend M8BOOT.ASM durch A16BOOT.ASM ersetzen. Läuft alles nach Plan, so wird eine Datei M8BOOT.hex erzeugt. 4. Die M8BOOT.hex wie bei bisher in den AVR uploaden. sp12 beispielsweise kopiert die Datei automatisch an die entsprechende hintere Stelle im Flach, auch wenn die hex Datei so klein erscheint. (Ich hoffe das ist bei allen Programmern der Fall). 5. Die Fusebits werden so geändert, dass BOOTSZ1 = 0, BOOTSZ0 = 1 und BOOTRST = 0 steht. (Manche Programmer sollen angeblich die FuseBits genau falschherum anzeigen!) 6. In der Konsole in das Verzeichnis der entpackten linux.tar.gz wechseln. Dort -> ./main -d/dev/ttyS0 -b9600 -p -f/filename.hex <- ausführen. filename steht für das zu überspielende Programm. ttyS0 für den entsprechenden RS232 Port des PCs. "/dev/ttyS0 at 9600 Baud: -" müsste erscheinen. Dann den AVR einmal kurz vom Strom abklemmen oder durch eine Reset Taste neustarten. Das Programm wird dann überspielt. Falls dies nicht der Fall ist, mal kontrollieren ob nicht noch ein anderes Programm (z.B. Terminal die RS232 Schnittstelle nicht schon verwendet - das Programm zum Upload schient dies nicht zu erkennen). 7. Viel Spaß
An peter dannegger, Malte und Sascha Biedermann: Danke für den Bootloader, hab zwar erst für den Mega32 anpassen müssen und viel unter Wine gelitten, aber es tut. Falls ihr mal in Hamburg seit, ihr habt Eintrittskarten für das Miniatur-Wunderland bei mir gut. Einfach dann mir mailen.
Hey könntest du den geänderten Code für den Mega32 mal bitte reinstellen MFG Andi
Hallo, unterstützt dieser Bootloader hier eigentlich auch den ATmega169? Gruß Thorsten
Hallo, vielen Dank für diesen schönen Bootloader. Seit neuestem kann ich also auf meinem COM-losen Laptop per USB flashen. Für die Leute, die lange Threads von hinten lesen: Nehmt einfach das Posting vom 2.Mai 2004, arbeitet unter XP sehr schön. Noch ein Tip: Eure Hex-Dateien müssen jetzt die alte DOS-Namenskonvention (8.3) erfüllen. (Für diese Erkenntnis brauchte ich leider 2 Stunden.)
moin, kann mir bitte jemand erklären wie das mit dem CRC funktioniert? steige da überhaupt nicht durch, wäre sehr dankbar. hoffe jemand ist so nett? mfg flo
hallo, kann keiner mir was dazu sagen? habe natürlich den theoretischen ablauf gelesen und verstanden. generatorpolynom usw. so gesehen war das recht simpel, aber wie man das in code umsetzt, verstehe ich niocht, deshalb bitte ich euch um hilfe, oder ist das zu schwer für ein anfänger? mfg flo
passt hier nu aber vielleicht nich rein, mach am besten einen neuen Thread mit dieser Frage auf, da erreichst Du mehr Leute... AxelR. Ich weiss nicht, wie es geht.
Nabend Der Bootloader ist toll, muss ich sagen. Hat jemand eventuell eine Version für den Tiny2313 fertig ? Sonst muss ich mich da mal selber hinsetzen. Mfg
Der Tiny2313 hat meines Wissens nach keinen Bootloader-Support, die Interrupt-Vektoren (einschließlich des Reset-Vektors) befinden sich immer am Anfang des Programmspeichers. Gruß Thomas
Hallo, vor einiger Zeit musst ich vom ATmega16 auf den 32er umsteigen. Zuvor habe ich den Bootloader vom Peter verwendet, der auch super funktioniert hat. Aber Peter hat leider bei seinem Archiv keinen Bootloader für den Mega32. Daher die Frage ob jemand einen passenden Bootloader für mich hat, bzw. wie ich den Bootloader vom Mega16/Mega323 ändern muss um ihn selber zu übersetzen. Gruss Sebastian
Hallo Peter, vielen Dank für Deinen schönen Bootloader. Bisher habe ich immer via ISP programmiert, aber wenn erstmal der Controller in einem Gehäuse verschwunden ist, sieht man sehr schnell die Vorteile eines Bootloaders. Mir gefällt besonders gut die Baudratenerkennung, und daß der AVR dabei nicht sendet. Du schreibst wirklich schöne Programme. Ich habe mir mal den MegaLoad von MicroSyl angeschaut, der ist nicht wirklich praktikabel. Die Baudratenerkennung funktioniert so, daß der AVR nach jedem Start fleißig über die serielle Schnittstelle sendet. Bei mir hängt ein Drucker an der Schnittstelle dran, das ist nicht lustig. Und jeder Start des AVR dauert. Den MegaLoad kann ich nicht einsetzen. Bisher unterstützt Dein Bootloader nicht den Mega128. Soweit ich diesen Thread verfolgt habe, gab es Bestrebungen von Fiffi, das zu ändern. Was ist denn daraus geworden? Meine C-Zeiten sind leider schon etwas länger her, momentan arbeite ich mit Delphi. Aber die Änderungen an PBOOT.C können doch nicht so kompliziert sein? Es müßte mehr Speicher alloziert werden, und die Signatur vom Mega128 hinzugefügt werden. Ich bin in diesem Thread ein wenig durcheinander gekommen, aber welchen C-Compiler benutzt Du? Die Änderungen am eigentlichen Bootloader sind vielleicht etwas komplizierter. Kann Fiffi mal antworten, ob er das Problem gelöst hat? Gruß Gerd
Hallo Peter, vielen Dank für Deinen schönen Bootloader. Bisher habe ich immer via ISP programmiert, aber wenn erstmal der Controller in einem Gehäuse verschwunden ist, sieht man sehr schnell die Vorteile eines Bootloaders. Mir gefällt besonders gut die Baudratenerkennung, und daß der AVR dabei nicht sendet. Du schreibst wirklich schöne Programme. Ich habe mir mal den MegaLoad von MicroSyl angeschaut, der ist nicht wirklich praktikabel. Die Baudratenerkennung funktioniert so, daß der AVR nach jedem Start fleißig über die serielle Schnittstelle sendet. Bei mir hängt ein Drucker an der Schnittstelle dran, das ist nicht lustig. Und jeder Start des AVR dauert. Den MegaLoad kann ich nicht einsetzen. Bisher unterstützt Dein Bootloader nicht den Mega128. Soweit ich diesen Thread verfolgt habe, gab es Bestrebungen von Fiffi, das zu ändern. Was ist denn daraus geworden? Meine C-Zeiten sind leider schon etwas länger her, momentan arbeite ich mit Delphi. Aber die Änderungen an PBOOT.C können doch nicht so kompliziert sein? Es müßte mehr Speicher alloziert werden, und die Signatur vom Mega128 hinzugefügt werden. Ich bin in diesem Thread ein wenig durcheinander gekommen, aber welchen C-Compiler benutzt Du? Die Änderungen am eigentlichen Bootloader sind vielleicht etwas komplizierter. Kann Fiffi mal antworten, ob er das Problem gelöst hat? Gruß Gerd PS: Mein Eintrag steht nochmal am 05.02.2004 obwohl ich ihn heute (17.06.2005) gepostet habe. Die Uhr auf dem Server lief wohl falsch.
@Gerd, tja, den Mega128 muß wohl ein anderer einbauen, da ich bisher auch nicht annähernd solche Unmengen an Flash benötigt habe und wohl nicht brauchen werde. Außerdem nehme ich lieber DIP-Gehäuse, die sind schnell auf einer Uniplatine zusammengebaut. Der Mega64 ist pinkompatibel, nimm doch den. Das entsprechende Include-File genommen und fertig. Änderungen Mega128: C-Programm: Auswertung des Segmentrecords, 256kB Puffer und senden der Programmieradresse mit 5 Hex-Digits. Bootloader: Die Kommandotabelle muß über die erweiterten Befehle (ELPM) angesprochen werden und die Programmierroutine muß die erweiterte Adressierung unterstützen. Das Einlesen des 5. Adreßdigits ist bereits drin (Register ADDRXH). Peter
Danke Peter. Ich habe mir inzwischen Dein Programm in Hinblick auf einen Mega128 angesehen, und mir ist etwas ziemlich Gemeines aufgefallen: Die Bits IVCE und IVSEL sind ins MCUCR "gewandert", das könnte die Probleme von Fiffi erklären. Gruß Gerd
@Gerd, stimmt, über dem Mega32 und bei den neuen Mega48/88/168 ist alles wieder völlig durcheinander gewürfelt, auch die UART sitzt da nicht mehr im IO-Bereich. Was dieser Unsinn bloß soll ? Bei den 8051-ern klappt das doch wunderbar, die alten Bits und Bytes und Interrupts an der gleichen Stelle zu belassen. Vermutlich kommen da neue Entwickler, die unbedingt ihre Spuren hinterlassen müssen. Wie die Politiker, die ständig Straßen umbenennen müssen, statt mal was sinvolles zu tun. Peter
Hallo Peter, ich verstehe das auch nicht. Bisher war ich ein Fan der AVRs, ich fand die klar strukturiert. Aber jetzt wird an verschiedenen Enden "erweitert" und "geflickt", wenn ich das mal so nennen darf. Vermutlich ist es selbst bei Firmen wie Atmel nicht möglich, über ein paar Jahre in die Zukunft zu denken. Ist mir gerade beim Assembler2 wieder aufgefallen. Da gibt es eine Fehlermeldung, wenn ich Deinen Bootloader mit Deiner "m16def.inc" übersetze. Angemeckert wird das OR: ; UCSRA .equ OR =3 .equ DOR =3 ;New name for OR Vermutlich wurde es in DOR umbenannt, damit es mit dem Assembler2 läuft. Im Assembler2 ist die "m16def.inc" auch geändert. Hast Du die Zeile .equ NOINTaddr=0x2A ;no more interrupt vectors hinzugefügt? Die fehlt in der neuen "m16def.inc". Gruß Gerd
@Gerd, ja, den Eintrag habe ich angefügt als erste Adresse, an der das Main stehen kann. Ist deswegen nötig, damit man nicht versehentlich Vektoren überschreibt, da die Reihenfolge der Vektoren ja je nach Typ unterschiedlich ist. Peter
Hallo Peter, ich habe Deinen Bootloader auf den Mega128 erweitert. Zumindest ist es jetzt möglich, 64k in das Flash zu übertragen. Die Änderungen für 128k sind schon ein bisschen umfangreicher, daher habe ich es bei den 64k belassen. Ich muss das Programm noch ein wenig testen, und werde es dann in den nächsten Tagen posten. Ich habe ein Bitte: Da ich keinen C-Compiler habe, könntest Du bei Gelegenheit die Zeile case 0x1E9702: dev = "ATMega128"; break; in PBOOT.C einfügen und compilieren. Gruß Gerd
Hi, ich hab versucht die ASM Files fuer den M16 neu zucompilieren. ASM.bat M16boot Leider bekomme ich beim compileren folgende Fehler: program.inc(11) : warning: Immediate byte operand out of range program.inc(67) : warning: Immediate byte operand out of range In der Datei Bootload.h hab ich die XTAL Freq. angepasst. Ich hatte gelesen das es nur fuer Wartezeiten ist, aber mir ist es lieber alles richtig anzupassen. Soll ich diese beiden Fehler ignorieren ? Lieber waere es mir , wenn mir jemand kurz erklaeren koennte wo mein Problem ist. Mfg Dirk
Hier ist der Bootloader für den Mega128. Alle Dateien, die ich anpassen mußte, haben ein "128" in ihrem Dateinamen. Und ich habe in den Dateien kenntlich gemacht, wo ich was verändert habe. Der Bootloader sollte prinzipiell auch 128k einlesen können, ich konnte es nur noch nicht testen. Die unteren 64k funktionieren. Getestet habe ich auch noch nicht das EEprom, aber da habe ich eigentlich nichts verändert. Als Assembler habe ich den "AVR Assembler 2" des AVR Studio 4.11 verwendet. Gruß Gerd
Die neueren Version vom AVR-Assembler geben diese Warnung aus, wenn man z.B. über einen ldi-Befehl einen negativen Wert in ein Register läd. ldi r16,-reloadtime Hintergrund ist, dass der Schreiber der Übersicht wegen für die Berechnung des Nachladewertes eines Timers die Anzahl der Zählimpulse einsetzt und nur noch ein Minus dovro schreibt, da die Timer ja nur aufwärts zählen. Der Assembler meckert hier, weil für ihn die Konstante intern mit bis zu 32bit dargestellt wird, was mit dem Minus davor immer zu 32bit führt, Du diesen Wert aber in ein Register (8bit) laden möchtest. Das Ergebnis ist aber in jedem Falle richtig. Jörg
Hallo, ich brauch mal Hilfe. Bisher tuts der Bootloader immer klaglos. Bei meinem neuen Projekt sagt er mir beim Programmieren immer: ...0000 - 1323 Error at adress: 0 WinAVR sagt mir: AVR Memory Usage: ----------------- Device: atmega8 Program: 4900 bytes (59.8% Full) (.text + .data + .bootloader) Data: 738 bytes (72.1% Full) (.data + .bss + .noinit) Die .hex-Datei ist 14kB groß. Was mache ich falsch?
Hi, wie willst du den 14k in ein 8k µC quetschen? Der Mega8 hat nachdem Bootloader nur 7,5k flash Speicher noch frei. Mfg Dirk
@Frank, kannst Du mal das Hex anhängen oder als E-Mail. @Dirk, das ist schon o.k. 14kB Hex sind etwa 14kB / 2,8 = 5kB Code. Peter
Hallo, danke erstmal für die schnelle Betreuung. Die .hex-Datei ist im Anhang. Was ich schon überprüft hab: - mit Ponyprog gehts (natürlich) - anderer Chip, gleiche Reaktion Bis bald Frank
An Peter: Konntest Du was rausfinden? Ich mach munter weiter mit Ponyprog, aber unter XP dauert das alles so lange, dass ich einfach zu oft Kaffee trinken gehe...
Hallo Der Bootloader läuft nach einem kleinen Problem bei mir, aber ich habe zum Windows und Linux Client noch ein paar Anmerkungen. Windows: Die XP taugliche Version (02.05.2004 23:43 pboot_xp.zip 40.4kB) wollte bei mir einfach nicht funktionieren bis ich durch Zufall noch eine offene HyperTerminal während eines tests laufen hatte. Ich staunte nicht schlecht plötzlich ging's, danach funktionierte auch die erste Version (19.11.2003 21:56 bootload.zip 41.4kB) bei mir unter XP. Schon etwas komisch ?!?!!? Linux: Der Linux Client (13.02.2004 17:00 linux.tar.gz 35.3kB) funktionierte schneller. Allerdings ist mir aufgefallen das nach dem Flashen des AVRs über den Bootloader bei dieser noch ein manueller Reset ausgeführt werden muss bevor das neue Programm lief. Beim durchstöbern der Windows Source ist mir aufgefallen das dort zum Schluss noch ein Reset-Kommando an den AVR geschickt wird sendstring( "\nReset" ); // disconnect ATMega Wenn ich in der Shell jetzt manuell ein Reset absetze klappts. echo -n -e "\nReset" > /dev/ttyS0 Ansonsten ist der Bootloader eine supper sache. Dank an die Programmierer!! Wolfgang
@ Fritz Ganter Ich möchte nochmal nachhaken, du hast den Bootloader für den M32 angepasst. Bitte stelle ihn doch hier nochmal zur Verfügung. Thomas
Hallo, ich habe es auch mal versucht den Bootloader für einen Mega32 zu übersetzten. Es ist mir auch gelungen, wobei ich jetzt nicht sagen kann ob er auch wirklich 100% funktioniert. Also die Programme die ich bis jetzt geladenhabe liefen problem los, bin aber auch noch nicht an die Speichergrenzen des Mega32 vorgedrungen. Anbei ist der Code und ein compiliertes Hex File! Vielleicht kann jemand der sich besser mit dem Bootloader auskennt den geänderten Code von mir überprüfen? MFG
Wäre jemand so freundlich und würde die für den ATmega128 benötigten Modifikationen der PC Software auch in die Linux Version integrieren oder habe ich die nur übersehen? Schon mal danke :-)
Moin moin,
ich habe hier ein Projekt mit dem Mega32 (16MHz). Programmiere ich
"direkt" mit avrdude dann läuft alles, auch die A/D-Wandlung gibt den
Richtigen Wert aus. Programmiere ich jetzt den Bootloader (m32boot.hex,
siehe hier weiter oben) OHNE die Fuses etc. zu verstellen und danach
das Programm wieder mit pboot (nicht neu compiliert), dann geht die
Spannungsmessung nicht mehr!
Programmiere ich jetzt wieder mit avrdude geht wieder alles, wie es
soll.
Wo liegt jetzt der Fehler? Im m32boot.hex, in meinem Programm,...???
Unten angehängt mal meine Spannungsmesssroutine.
Mfg Jens
unsigned int Spannung(void)
{
// Spannung an PA7
unsigned int Spannung;
unsigned char H,L;
ADCSRA = (1<<ADEN) | (1<<ADPS0) | (1<<ADPS1) | (1<<ADPS2);
ADMUX = (0<<REFS1) | (0<<REFS0);
ADMUX = (1<<MUX0) | (1<<MUX1) | (1<<MUX2) | (0<<MUX3);
ADCSRA |= (1<<ADSC);
while (ADCSRA & (1<<ADSC)) {}
L=ADCL;
H=ADCH;
Spannung=H*256;
Spannung=Spannung+L;
return (Spannung);
}
Hallo Jens, Du mußt doch die Fuses ändern, wenn Du den Bootloader nutzt. Oder habe ich Deine Formulierung falsch verstanden? Als ich den Bootloader auf den Mega128 portiert habe, ist mir auch was merkwürdiges passiert: Die serielle Schnittstelle übertrug nur noch Müll. Ohne Bootloader lief es, mit Bootloader kam nur Datensalat rüber. Das Problem lag darin, daß der Bascom-Compiler das Register UBRRH bei der Einstellung der Baudrate nicht setzt und als 0 annimmt. Ist es aber nach dem Bootloader nicht. Daher habe ich in Userprog128.inc noch ein paar Zeilen eingefügt, die dieses Problem beheben. Vielleicht hast Du ein ähnliche Problem. Gruß Gerd
Hallo Gerd, natürlich habe ich die Fuses so geändert, dass er den Bootloader nutzt. Diese dann aber nicht mehr verändert. Findet er keinen Bootloader startet ja das Programm ganz normal. Es läuft ja auch sonst alles (soweit ich das bisher sehe; ist einiges an LCD-Ausgaben, dann noch 2 Cips per I2C angesprochen etc. insgesamt derzeit 23kB Code) egal ob mit oder ohne Bootloader. Das mit nicht/falsch initialisierten Variablen kann gut möglich sein. Werde mir das nochmal ansehen und ggf. berichten. Mfg Jens
@Jens Die 23kb Code, ist das reiner Sourcecode oder ist das der real benötigte Speicher? Peter Dannegger hat weiteroben mal eine Faustformel zur berechnung des Programmcodes gepostest (HexFile Größe / 2,8 = Programmcode Größe). Ich selber hatte nämlich das Problem mit dem Mega8 in Verbindung mit dem Bootloader, das mein Programm größer war als der mir zu Verfügung stehende Programmspeicher. Kann man leicht sehen, wenn man das Hex File im PanyProg öffnet und nachschaut an welcher Adresse der Programmcode zuende ist, und an welcher Adresse der Bootloader anfängt. Gibt es hier Überschneidungen, dann kann es auch zu solchen problemen führen. Wenn ich das richtig aus dem Datenblatt entnehme, dann fängt der Bootloader bei Adresse $3C00 an. Vielleicht hilft es. Es kann aber auch sein das ich bei der Anpassung des Bootloaders einen Fehler gemacht habe, was ich nicht ausschließen würde. Ich war froh das der Bootloader überhaupt funktioniert hat. MFG & Good Luck
Moin Moin! Ich hab einfach mal aus Neugierde den Bootloader in einen M16 geschubst und bin davon wirklich begeistert. Nicht mehr das serielle Kabel von der Programmierschnittstelle auf die Serielle umstecken und dann die affenartige Geschwindigkeit im Vergleich zu Pony Prog! Ich benutze FastAVR und PBoot lässt sich daraus problemlos aufrufen. Der Rechner läuft unter W2k. Fazit: ein wirklich schönes Stück Software! bye Frank
kann mir bitte mal jemand kurz erläutern, wie ich eine datei in den mc hochladen kann. was mus ich in die console eingeben. gruß xeus
Hallo Peter, leider kann ich Deinen Bootloadercode nicht finden, ist der Link ist nicht mehr aktiv! Grüße
@Quacks, ja, es ist etwas mühsam, die letzte Version zu finden: http://www.mikrocontroller.net/forum/read-4-53146.html#82861 Peter
Hallo, ich meinte in diesem Thread gelesen zu haben das der Bootloader von Peter nach dem Programmieren automatisch das Programm gestartet wird. Ist das nicht der Fall, oder sollte es so sein? Weil bei mir muss ich immer nach dem Programmieren einen manuellen Reset ausführen! MAch ich da etwas falsch? MFG Sebastian
Hi,... versuche mich auch gerade am Bootloader. Leider bekomme ich beim Compilieren der Dateien immer drei Fehlermeldungen folgender Art: D:\downloads\bootload\program.inc(62): error: Operand(s) out of range in 'cpi r28,0x240' Kann jemand damit was anfangen? Was mach ich falsch? LG + danke Christoph
@Christoph, der neue Assembler schneidet wohl nicht mehr automatich die oberen Bits ab. Muß man mit low() machen: cpi yl, low(page_buff_end) ;check page overflow Peter
Hi Peter, danke für die prompte Antwort. HAt funktioniert, dann kann ich ja jetzt weiter experimentieren! lg Christoph
Hi,... hab jetzt mit BASCOM nen Bootloader geschrieben. Funktioniert auch einwandfrei mit nem Mega8. Auf dem Mega64 läuft der Bootloader auch, aber das Programm, das ich per MCS Bootloader hochlade ist nach dem Upload verschwunden!? Zumindest startet es nicht. Wo liegen die Unterschiede zwischen Mega8 und Mega64? Gibts da etwas, das ich übersehen habe? LG Christoph
Hallo, der originale Bootloader von Peter funktioniert ja über RS232 und einem entsprechenden Kabel. Könnte man das Kabel nicht auch einfach durch eine "Funkstrecke" mit je einem IR-Sender/-Empfänger ersetzen? Joline
Hallo, sorry diesen alten thread auszugraben! gibts irgendwo fertige hexen (wortspiel) die ich einfach mit ponyprog oder bascom in den avr laden kann??
Hi! In der neuen Bascom-Version sind Beispielquellcodes für Bootloader drin! Kannst Du Dir selbst schreiben und daraus selbst Hexereien machen :-) Viel Spaß Christoph
( stelle diesen Beitrag noch mal ans Ende des zug. Artikels )
Hallo,
ich habe mich einmal mit dem Bootloader von Peter Dannegger aus der
Codesammlung befasst.
Fuer den Atmega8 ( M8BOOT.hex / Pboot.exe ) geht das alles wunderbar.
Dann der Versuch alles fuer den Atmega8535 anzupassen:
1) M8535BOOT.asm:.equ signature = 0x1E9308 ;Mega8535
2)
m8535def.inc:.equ RAMSTART = 0x60 ; ?? von mir hp/1/2006
m8535def.inc:.equ PAGESIZEB =64 ; ?? von mir
m8535def.inc:.equ NOINTaddr=0x15 ; Mega8 18 Vectoren 0x13, hier 20
Vectoren ???????
3) BOOTLOAD.H:
;***********************************************************************
**
; Constant definitions
;-----------------------------------------------------------------------
--
.equ xtal = 4000000 ;11.0592MHzA
....
...
...
;-----------------------------------------------------------------------
--
; Port definitions
;-----------------------------------------------------------------------
--
.equ led_out = PORTB ;LEDs
.equ led_ddr = DDRB
.equ led0 = PB0
.equ led1 = PB1
.equ led2 = PB2
.equ led5 = PB5
.equ UART_IN = PIND
.equ RXD = PD0
;-----------------------------------------------------------------------
--
4) Assemblierung und flashen klappt.
5) Fuses fuers Bootloaden geaendert:
S8535C WDTON SPIEN CHOPT EESAVE BOOTSZ1 BOOTSZ0 BOOTRST
1 1 0 1 1 0 1 0
6) Pboot.exe /B9600 /PIsony.hes
Com1 at 9600 Baud: Connected
Signature: 1E9408 Device: ( Pboot nicht neu kompiliert)
Program Isony.hex: 0000 - 13DB
error at address: 0 ( nach einigen Sekunden )
*******************
Wenn ich das zu ladenende Programm einmal mit dem Bootloader und einmal
mit Ponyprog in den Flash lade, unterscheidet es sich nur
in den ersten 2 bytes:
Bootloader: $00000: 97 c0 51 c0 .....
Ponyprog: $00000: 38 c0 51 c0 .....
da komme ich jetzt nicht weiter und bitte um Hilfe.
vielen Dank im voraus
horst.
So, ich hab jetzt ein angepasstes Makefile erstellt, mit dem man direkt mittels "make program" den bootloader nutzen kann. Desweiteren kann man mit "make test" die Verbindung prüfen. Hier die Ausgabe: E:\AVRPRO~1\BOOTLO~1\pboot_xp\pboot -c1 -b19200 -pE:main.hex COM 1 at 19200 Baud: Connected Signature: 1E9307 Device: ATMega8 Program E:main.hex: 0000 - 14E9 Program successful CRC pass make.exe: *** [program] Error 1 > Process Exit Code: 2 > Time Taken: 00:09 Funktioniert wunderbar, trotz Error 1, ist vielleicht der Rückgabewert nicht 0?
In der Zwischenzeit hat sich offensichtlich das Übertragugnsprotokoll etwas geändert, zumindest funktionierte das weiter oben angebotene Linux-Programm nicht mit dem Bootloader für den ATMega32. Im Anhang schicke ich meinen Patch, mit dem es mir gelungen ist, meinen ATMega32 problemlos zu programmieren. Hier --> http://www.mikrocontroller.net/forum/read-4-53146.html#66454 befindet sich das Linux-Programm. 1) Herunterladen, entpacken und in das Verz. wechseln 2) patch < proto_neu.patch (bei Bedarf den Pfad zum Patch anpassen) 3) make PS: Ich arbeite hier mit MacOS und nicht mit Linux, die Funktionalität sollte dennoch identisch sein. Gruß, Tom
Hallo, ist jemand so nett und schickt mir ein fertiges hex-file vom Bootloader? Atmega128 8Mhz Com0 Besten Dank im Voraus Gruß Michael
Einfach mal nach oben scrollen --> http://www.mikrocontroller.net/forum/read-4-53146.html#198047 Vielleicht funktionierts. Viel Erfolg, Tom
Hallo zusammen,
getreu dem Motto, probier es doch erstmal selbst, habe ich mich die
letzten beiden Abende, die als juner Familienvater wirklich selten
sind, an durch die WindowsApi-Geschichte gebissen, da ich mir, um
meinen mega32 zu programmieren, mich bei :
A: Peter beim Bootloader
B: Osamu Tamura für die USB->SPI
bedient habe (Das Rad nicht nochmal neu erfinden lautet hier das
Device)
pboot läuft mir dem normalen Serialadapter ganz gut, aber mit AVRusb
überhauptnicht, deswegen meine Anstrengung in Richtung Win32-Api.
Was ich baer feststellen mußte :
NON_OVERLAPED scheint nicht zu gehen.
Weil :
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
int main(void){
DCB dcb;
HANDLE handle;
// Open serial port as a file, Windows style
handle = CreateFile("COM2:", GENERIC_READ | GENERIC_WRITE, 0, 0,
OPEN_EXISTING, 0, 0);
if (handle == INVALID_HANDLE_VALUE) {
printf("Couldn't open serial device!");
while (getchar() != '\n');
exit(-1);
}
char *data="Hallo";
DWORD written=0;
WriteFile(handle, data, 5, &written, NULL);
printf("Gesendet, %i\n",written);
const int cBufferSize=0x1000;
char szBuff[cBufferSize];
DWORD dwRead;
ReadFile(handle,szBuff,cBufferSize,&dwRead,NULL);
printf("Empfangen %s, %i",szBuff,dwRead);
while (getchar() != '\n');
// Close serial port
CloseHandle(handle);
return 0;
}
Sendet zwar munter, aber liefert nun mal wirklich überhaupt garnichts
zurück.
Hat das schon jemand zum laufen ebracht ?
Gruß
dD
Hallo, hab mal meine Variante mit Win32API hier angehangen. Habe dazu Pelle C benutzt (kleine schnelle kostenlose C IDE und Compiler) findet man hier www.smorgasbordet.com/pellesc/index.htm Benutzt habe ich die Version 4.5 Beim der Checksumme gibts noch einen Bug, daher zur Zeit ausgelassen. Hab das ganze jetzt auch noch mal auf VisualC++ 2005 Express übertragen. Gibts ja auch umsonst für ein bisschen Downloadzeit :) ca. 400 MB + ca 300 MB fürs PSDK. Letzteres muss dann entprechen von Hand in VSC++ 2005 Express konfiguriert werden. Sollte an der VSC++ Variante Interesse bestehen kann ich die gerne auch noch hier anhängen. Gruss Jürgen
Hi, ok hier die Variante für VSC++ 2005 Express. Hänge wieder das ganze Projekt dran, dann gehts sicher am einfachsten. Bitte unbedingt Hinweis bezüglich UniCode beachten. Ist im Projekt aber schon entsprechend eingestellt. PSDK == Platform Source Developement Kit Wird benötigt für Win32API (z.B CreateFile etc.) Ist bei VSC++ 2005 Express nicht default dabei. Kann aber kostenlos heruntergeladen werden und nach folgender Anleitung installiert werden. http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/default.aspx Gruss Jürgen
Hallo Zusammen! Ich habe mich lange gedrückt einen Bootloader zu verwenden und einfach überall ein isp-anschluss integriert. Beim aktuellen Projekt ist dies jedoch definitiv nicht mehr der richtige Weg. Nun brauche ich also einen Bootloader für folgendes System: AVR ATmega8, PC: Linux, alles soll mit C geschrieben werden und mit AVR-GCC kompiliert werden. Ich habe zuest einmal das Datenblatt vom Atmel studiert aber komme da ehrlichgesagt im Untschied zu anderen Kapitlen nicht wirklich draus. Und jetzt wo ich jede Menge Forenbeiträge gelesen habe sehe ich den Wald vor lauter Bäume nicht mehr. Also ich stell mir das ganze so vor: Ich setze per ISP zuerst die richtige Fuse-Bits und übertrage dann ein Bootloader. Dieser wird beim reset ausgeführt, konfiguriert die UART und wartet dann kurz ob er ein bestimmtes Byte empfängt, ansonsten startet er die wirkliche Applikation. Auf dem PC habe ich ein mit C geschriebenes Programm, welches unter Linux läuft. Dieses wandelt das Hex-File in den Byte-Code um. Beim Starten sendet es die ganze Zeit das bestimmte Zeichen, bis es vom AVR eine antwort hört. Dann übertragen die beiden nach einen einfache Protokoll die ganze Appilaktion. Ist sowas mit dem hier diskutierten Code mögich? Wenn ja wie genau? Zb. wie müssen die Fuse-Bits gesetzt werden, wie lad ich den Bootloader auf den AVR (ich benutze dafür bis jetzt uisp) etc.? Vielen Dank für Hilfe!!
@Lorenz, warscheinlich hast Du Dir den Thread nicht durchgelesen, denn genau das macht er doch. Nur einen Unterschied gibt es, es wird kein einzelnes Zeichen sondern ein Paßwort gesendet, welches stimmen muß. Ein Zeichen könnte ja auch bei Benutzung der UART durch den Anwender auftreten und da wäre es blöd, wenn er plötzlich im Bootloader feststeckt. Die Fuses müssen so gesetzt werden, daß Deine gewünschte Taktquelle ausgewählt ist und die Resetadresse auf den Bootloader zeigt. Peter
Vielen Dank für deine prompte Antwort, Peter. Was ich nocht nicht gefunden habe ist, der Bootloader (für den AVR) als C. Wurde dieser "nur" in Assambler geschrieben? Nun so ganz den Druchblick habe ich nocht nicht. Ich glaube das Beste ist, wenn ich mir selber einen Bootloader progge, dann raff ich wenigstens wie er funktioniert. Dazu aber im Voraus noch eine Fragen: Auf dem AVR werden die Daten Binär übertragen (macht ja keinen Sinn diese auf dem AVR umzurechnen). Jetzt der AVR-GCC liefert ein Hex-File, richtig? Jetzt wo finde ich informationen, wie dieses genau zu parsen sind? Am Anfang steht ja noch ein ':' und danach irgend eine Nummer. Lorenz
@Lorenz, ja der Bootloader ist in Assembler. Das erschien mir sicherer, wegen dem ganzen Timed-Access, Interruptsperren usw. Es muß ja nichts gerechnet werden. Auch wollte ich möglichst viel Flash für die Anwendung übrig behalten. Die Einleseroutine für HEX ist doch in meinem C-Programm drin. Außer 0xA5 werden alle Bytes binär übertragen. 0xA5 dient als Steuercode. Peter
@All Ist Euch schon aufgefallen das der Mega8 überhaupt keinen absoluten JMP Befehl kennt, sondern nur den indirekten IJMP via Z Register und den relativen RJMP ?!? Nichts desto trotz funktioniert der Bootloader wunderbar.
@Jörg, "Ist Euch schon aufgefallen das der Mega8 überhaupt keinen absoluten JMP Befehl kennt..." als ich den Bootloader geschrieben habe, war er noch im Datenblatt drinn, sonst hätte ich ihn ja nicht verwendet. Auch gabs keinen Bugreport, daß er fehlerhaft wäre. Warum er aus dem Datenblatt wieder rausgenommen wurde, weiß ich nicht. Es ist jedoch äußerst unwarscheinlich, daß er auch aus dem Silizium rausgenommen wurde. Eine neue Revision ist zu teuer, als daß man Sachen ändert, die funktionieren. Peter
Hi JMP wird wohl nie im Mega8 dringewesen sein. Ich vermute eher das der Assembler so clever war JMP auf RJMP abzubilden da damit ja schließlich der ganze Adressraum erreicht werden kann. Matthias
@Matthias, "Ich vermute eher das der Assembler so clever war JMP auf RJMP abzubilden" Der Hauptunterschied Compiler/Assembler ist, ein Assembler muß immer genau das in Code umsetzen, was man hingeschrieben hat ! Er darf sich keinerlei Freiheiten rausnehmen, irgendwas zu optimieren. Man kann sich natürlich Macros schreiben, die targetabhängig Befehle ersetzen. Aber diese Macros dürfen keinesfalls wie reguläre Befehle heißen, denn diese sind reserviert. Z.B. gibt es Macros, die IO-Zugriffe bei neueren ATMegas in LDS umsetzen, wenn die über 0x3F liegen. Peter P.S.: Das alte PDF des Mega8 mit dem JMP kann ich hier leider nicht reinstellen, da größer 1MB.
Hallo Leute! Ich bin hier im Forum über den Bootloader Leider hab ich Probleme mit pboot_xp.zip vom 02.05 einen Mega 128 mit dem Bootloader zu vesehen. Die von mir verwendete Software ist AVR-Studio 4.12, SP3, PC ist WinXP. Meine Vorgehensweise war bisher: Den Bootloader boot128.hex in den Mega programmieren, danach die Fuses Flas Bootsize 2048 Words setzen und Bootresetvector enable. Mit pboot -c1 -b19200 -ptest.hex hab ich dann versucht ein ganz simples Programm einzuspielen (Das nur geraden Ausgänge von Port b auf low zieht, damit am STK500 jede 2 Led leuchtet). Pboot startet zwar, danach "dreht" sich die Fortschrittsanzeige, und es geschiet nichts weiter. Bisher hab ich festgestellt, dass wenn ich im Bootloader ein 'a' an den PC sende, nachdem mit autobaud und setbaud die Baudrate eingestellt wurde, pboot.exe am Monitor connectet schreibt. Aber die Daten von test.hex werden nicht geschickt. Ob der Bootloader im Atmel oder die EXE am PC "hängen" bleibt hab ich leider noch nicht herausgefunden! Habt Ihr einen Tipp für mich, wie ich das Werk zum laufen bekomme? Danke schon mal für Eure Hilfe! LG Peter
Ist denn 2048 Word richtig? Der Bootloader ist (zumindest beim ATMEGA8) deutlich kleiner.
Hallo nochmal! Hab leider gleich eine falsche Angabe gemacht! Ich verwende natürlich die Datei boot128.zip vom 22.06.2005 15:10 ! Trotzdem besteht das oben genannte Problem! LG Peter
Hi! Das war aber eine flotte Antwort! Hab ich zuerst gar nicht bemerkt! Die Größeneinstellung hat leider keine Auswirkung - es geht leider immer noch nicht! Trotzdem Danke! LG Peter
> Pboot startet zwar, danach "dreht" sich die Fortschrittsanzeige, > und es geschiet nichts weiter. Blöde Frage: Nachdem Pboot gestartet wurde, resettest du den Mega128? Der Bootloader wartet nur eine bestimmte zeitlang nach dem Reset. Tut sich in der Zeit nichts an der Seriellen startet er was auch immer als Pgm im Flash vorliegt.
Hi - Danke für den Tipp, aber dass ist es nicht Hier ist meine genaue Vorgehensweise: Den Bootloader mit normaler ISP Programmierung über das STK 500 in den Atmel. Danach mit dem Programmiertool vom AVR Studio die Fuses setzen,(Bootgröße und Bootresetvector) Bei der größe hab ich verschiedene Einstellungen probiert. Danach beende ich das AVR Studio, schließe die Serielle Schnittstelle von Com1 am STK 500 Spare an und verbinde Sie mit PE0 und PE1 Wenn das passiert ist, schalte ich das STK500 wieder ein und halte den Reset Taster gedrückt Dann Starte ich Pboot mit den Parametern -c1, -b19200 und ptest.hex Sobald Pboot gestartet ist lasse ich den Resetknopf aus. Ich hab ein paar Überwachungspunkte in den Bootlaoder eingebaut. Die Funktion abaut und Set_baudwerden noch durchgeführt. Danach springt er in die Main Routine. Weiter komm ich allerdings nicht! Gibt es irgendwas beim laden des bootloaders in den Flash zu Beachten, oder hab ich irgend welche Fuse bits vergessen? Dass der Bootloader startet spricht ja eigentlich nicht dafür oder? Serielle Kommunikation selber funktioniert überigens mit anderen Programmen also sollte die Schnittstelle in Ordnung sein. Was um alles in der Welt mach ich nur falsch?? Schönen Abend noch! Peter
Hallo mal wieder! Ich hab das Problem leider immer noch nicht gelöst! Hat vielleicht jemand von Euch einen Tipp ? LG Peter
Kann es sein dass die Programmiersoftware für den PC einen fehler enthält? Wenn ich einfach pboot.exe /Pmega8.hex aufrufe geht alles. Nur jetzt hab ich n Projekt wo ich keinen Baudratenquarz hab und deswegen das ganze nicht mit der voreingestellten Baudrate geht. Jetzt rufe ich einfach: pboot.exe /Pmega8.hex /B9600 auf. Soweit geht auch allse und das Programm wird korrekt auf den controller geschrieben. Jetzt kommt mein Problem. Wenn ich jetzt erneut versuche zu Programmieren, egal ob mit /B9600 oder ohne, kommt die Fehlermeldung, dass pboot.exe den Comport (COM1) nicht öffnen konnte (Ignorieren, Abbrechen) Erst nach einem Neustart kann ich den Comport wieder öffnen. Der comport ist irgendwie gesperrt, kein anderes Programm kann ihn öffnen. Wenn ich nur pboot.exe /Pmega8.hex aufrufe kann ich das so oft wiederholen wie ich will, es tritt kein fehler auf.
Kann das mal bitte wer bei sich ausprobieren? Würde gerne wissen ob es nur bei meinem rechner so ist oder auch bei anderen (d.h. "größerer" bug) Ich hab hier immoment leider nur einen Rechner zur verfügung.
@Hauke, also ich habe nichts dergleichen bemerkt. Besonders, daß es von der Baudtrate abhängig sein soll, ist äußerst merkwürdig. Wird in einer DOS-Box die COM geöffnet, behält diese DOS-Box die COM, solange sie offen ist. Da ich in der gleichen DOS-box auch DOS-Terminalprogramme starte zum Debuggen stört mich das nicht weiter. Wenn es stört, kann man die Programmier-Batch als Symbol ablegen und zum Programmieren anklicken. Dann ist mit Beenden die COM wieder frei. Peter
Wäre nett, wenn du das machen könntest. Es hilft aber auch nicht, die DOS-Box zu schließen. Ich hab außerdem gemerkt, dass das Problem anscheinend NUR bei 9600 Baud auftritt. Ich hatte mich vertippt und 6900 geschrieben und ich hatte keine probleme den befehl erneut auszuführen. Auch bei 14400 Baud wurde der Comport wieder freigegeben. Mehr hab ich vorerst nicht getestet.
Ich habe bei mir (Linux, ATMEGA8 mit 11,0592 MHZ) auch das Problem, dass bei 9600 Baud die Übertragung nach wenigen Byte stets abbricht - bei der doppelten Geschwindigkeit funktioniert es aber fast immer.
Hallo, ich habe mich nun auch mal mit diesem Tread beschäftigt. Ich habe die Datei bootload.zip entpackt, ein AVR Studio Projekt erstellt, die M8BOOT.ASM als initial File genommen. Nun bekomme ich folgenden Fehler : AVRASM: AVR macro assembler 2.1.9 (build 90 Jul 5 2006 11:06:16) Copyright (C) 1995-2006 ATMEL Corporation C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(7): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\m8def.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\m8def.inc(345): error: Attempt to redefine keyword 'or' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(7): info: 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\m8def.inc' included from here C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(8): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(25): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\init.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(46): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\uart.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(47): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\commexec.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(48): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\asc2hex.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(49): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\commands.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(50): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\read.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(51): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\program.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(52): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\userprog.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(53): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\abaud.inc' Assembly failed, 1 errors, 0 warnings Wenn ich die m8def.inc von meinem aktuellen AVRStudio nehme bekomme ich folgende Fehler 3 : AVRASM: AVR macro assembler 2.1.9 (build 90 Jul 5 2006 11:06:16) Copyright (C) 1995-2006 ATMEL Corporation C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(7): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\m8def.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\m8def.inc(321): error: Attempt to redefine keyword 'or' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(7): info: 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\m8def.inc' included from here C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(8): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h(44): error: Use of undefined or forward referenced symbol 'RAMSTART' in .org C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(8): info: 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h' included from here C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h(44): warning: .org 0x0 in .dseg is below start of RAM at 0x60 C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(8): info: 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h' included from here C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h(46): warning: .org 0x0 in .dseg is below start of RAM at 0x60 C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(8): info: 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h' included from here C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h(58): warning: Use of undefined or forward referenced symbol 'PORTB0' in .equ/.set C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(8): info: 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h' included from here C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h(59): warning: Use of undefined or forward referenced symbol 'PORTB1' in .equ/.set C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(8): info: 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h' included from here C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h(60): warning: Use of undefined or forward referenced symbol 'PORTB2' in .equ/.set C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(8): info: 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h' included from here C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h(61): warning: Use of undefined or forward referenced symbol 'PORTB5' in .equ/.set C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(8): info: 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h' included from here C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h(64): warning: Use of undefined or forward referenced symbol 'PORTD0' in .equ/.set C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(8): info: 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\bootload.h' included from here C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(23): error: Use of undefined or forward referenced symbol 'NOINTaddr' in .org C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(25): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\init.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(46): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\uart.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(47): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\commexec.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(48): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\asc2hex.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(49): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\commands.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(50): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\read.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(51): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\program.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(52): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\userprog.inc' C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\M8BOOT.ASM(53): Including file 'C:\Dokumente und Einstellungen\Tobias Tetzlaff\Eigene Dateien\Atmel\Peter_Bootloader\bootload\abaud.inc' Assembly failed, 3 errors, 7 warnings Könnte mir evtl. jemand weiter helfen? Gruß Toby
> Dateien\Atmel\Peter_Bootloader\bootload\m8def.inc(345): error: Attempt > to redefine keyword 'or' Nun das heißt bestimmt das, was das steht. OR ist irgendwo definiert und warscheinlich in neueren Assemblern ein reserviertes Schlüsselwort. Also auf Zeile 345 gehen und umbenennen. Peter
Hallo Peter, Danke für die schnelle Antwort! Ich habe im AVR Studio, unter Projekt, Assembler Optionen, von AVR Assembler 2 auf AVR Assembler 1 umgestellt. Danach war der Fehler weg. Eine Frage noch, womit erstellt man so ein Komandozeilen Programm? Kenne bislang nur Visual Basic. Gruß Toby
Hallo nochmal. ich habe nun doch den Bootloader auf einem ATmega8 16Mhz extern zum laufen gebracht. Eigentlich lief er ja immer, nur konnte "ich" nicht flashen. Ehrlich gesagt, hatte ich immer das "p" vergessen. Ich habe das original PBootXP verwendet. Eine Frage nur: Ich habe es mit anliegendem Hex File versucht, dabei bekomme ich immer den Fehler: open failed! Der File ist mit dem neusten WinAVR erstellt. Die Files, die ich per Bootloader laden kann, sind allerdings mit CodeVision erstellt. Gibt es da Unterschiede im Format? Peter, kannst du mir sagen, woran es liegt? Lade ich den Hex File per ISP, läuft das Programm ja. Halt nur ohne Bootloader. Danke im voraus... Gruß Toby
Hmmmm, kann man auch Beiträge löschen??? Ist mir ja ein wenig peinlich, aber der Hex File geht doch. ich hatte ihn umbenannt in Test.hex, als ich ihn flashen wollte war der Name elf Buchstagen lang. Das ist bekanntlich ein Problem, in Dos, bzw. bei langen Dateinamen. Sorry. Gruß Toby
So ich hab das PC programm mal in Java umgesetzt, und ich denke, die Programmierzeiten können sich sehen lassen: 0,9s für 7,6kb Ich muss das ganze erst noch komplett testen bevor ichs hier hochlade, bin jetzt zu müde dazu.
So, sollte jetzt gehen. Im konsolenmodus sollte es genauso funktionieren, wie das originalprogramm, das GUI sollte selbsterklärend sein. Damit das ganze funktioniert muss die Comm API installiert werden, die ist enthalten. (Installationshinweise in der PlatformSpecific.html Viel spass damit ;)
Hallo Hauke, ich habe soeben dein Programm ausprobiert. Meinen Hex File läd es einwandfrei.( sogar mit langen Dateinamen ;-) ) Das Gui sieht sehr gut aus, gefällt mir! Was mich etwas stört, ist, das man diese Comm Sachen von Hand einfügen muß. Gibt es bei Java nicht so etwas, wie eine Install Datei, die man mit in das Programm steckt? Das man das JRE installieren muß, damit muß man wohl leben. Womit hast Du in Java programmiert? Ich versuche mich grade daran, Java kennen zu lernen, weiß aber noch nicht genau, mit welchem Programm. Ich habe das JDK von Sun, und den JBuilder 2005 Fundation. Vielleicht kannst du mir etwas auf die Sprünge helfen. Gruß Toby
Einen installer für die Comm hab ich noch nicht gefunden. Ich programmiere Java in Eclipse, ist freeware.
Hallo Ralf, sind doch alle Bootloader Versionen hier im Anhang. Ich nutze PBootXP.zip. Gruß Toby
Hallo, ich wünsche frohe Weihnachten gehabt zu haben! Ich habe mal eine Frage: ich würde die Datenübertragung des Bootloaders gerne per IR machen. Beim Mega8 eine Sendediode SFH415 an TX und PB3/OC2 Pin, ein Empfangs IC SFH5110 an RX. Nun frage ich mich, wie und wo ich folgenden Code einfügen muß, damit ich ein ständiges 36 kHz Signal am PB3/OC2 Pin bekomme. ;PB3/OC2 als Ausgang setzen ldi r16,0x08 out DDRB,r16 ;Timer 2 / OC2 Pin mit 36 kHz toggeln in r18,(1<<WGM21)+(1<<COM20)+(1<<CS20) ldi r18,0x00 out TCCR2,r18 out PORTB,r18 ldi r18,0x6E out OCR2,r18 ldi r18,(1<<OCIE2) out TIMSK,r18 sei Vielleicht kann mir ja jemand helfen. Eine weitere Frage wäre, was man ändern muß, um den Bootloader für einen ATmega168 zu nutzen. Dann wäre es allerdings der Timer0, der das 36 kHz Signal erzeugen soll. Guten Rutsch ins neue Jahr... Gruß Toby
Hallo Peter, wie weit überschreibt/löscht der Bootloader eigentlich den RAM wenn er nur feststellt dass es nichts zu flashen gibt und zum Hauptprogramm springt? Der Hintergrund ist, das ich gerade wohl zum zweiten mal auf Beitrag "Re: Variable in .noinit scheint Initialisiert zu werden" hereingefallen bin...
Ich habe mir den Bootloader nun selbst mal angeschaut. :-) Nach dem Start schreibt er den kompletten RAM mit Null voll. Da dies bei mir Probleme gab wenn sich ein Programm durch den Watchdog verabschiedete und nach einem Reset zur Ursachenerforschung einige Variablen mit .noinit deklariert worden waren, habe ich folgene Zeile in den Booloader eingefügt: An den Anfang der Datei INIT.INC:
1 | ;Checks if WDRF in MCUCSR is set |
2 | in r1, MCUCSR |
3 | sbrc r1, WDRF |
4 | rjmp userprog ;if WDRF is set, go to the user prog |
Damit wird im Fall eines Watchdog Resets direkt wieder zum normalen Programm gesprungen. Allerdings kann das normale Programm so nicht mehr per Watchdog ein neues Flashen anstoßen.
Hallo, ich habe auf der Suche nach dem Stichwort "Bootlader" diesen Thread hier gefunden. Ich möchte eine Update-Funktion in eine Mess-Software einbauen, die auf eine externe Logger-Box mit einem ATMEGA8-16PU zugreift (per RS232). Die AVR-Applikation selber stellt mir ein anderer Programmierer bereit, ich muss die Übertragung des Firmware-Updates in meine Anwendung einbauen. Als absoluter AVR-Nicht-Kenner habe ich ein par Fragen an das "erlauchte" Auditorium: - ich arbeite mit RealBasic. Damit kann ich aus dem selben Sourcecode quasi per Knopfdruck kompakte native Compilate für Windows, Mac und Linux mit GUI erstellen. In RB verfüge ich auch über vollen (API-) Zugriff auf serielle Schnittstellen. Das habe ich schon in vielen Anwendungen (Messwerte einlesen, Bondrucker direkt steuern) problemlos gemacht. Im oberen Teil dieses Threads laß ich aber von Problemen, über die API auf die COM-Schnittstellen zuzugreifen - muss ich mir Sorgen machen? Die Kommunikation mit einer herkömmlich per ISP programmierten Logger-Box funktioniert problemlos. - welche der hier genannten Bootlader-Versionen ist für meinen AVR die richtige? Wo kann ich die runterladen? Kann "mein" AVR-Programmierer die problemlos "einpflanzen"? - wo finde ich eine detailierte Beschreibung des Übertragungsprotokolls? Ich muss die gesamte Kommunikation mit in meine Anwendung einbauen. Genügen die Leitungen RX/TX oder werden auch Statusleitungen benötigt? - in welchem Format muss mir mein AVR-Programmierer die jeweils neue Firmware bereitstellen? Danke für die Hilfe und ein Gesundes Neues Jahr! Frank
Also wenn du die hier vorhandenen Programme nutzen willst brauchst du das Intel Hex format, wenn du dir was selbst schreibst, dann kanns auch binärformat sein. Das Format ist ist weiter oben beschrieben ... Aber soweit ich das jetzt noch zusammen bekomme musst du solange >F8,F0,E0,C0,FC senden, bis der controller mit 'a' antwortet. Danach kannst du die Signatur des controllers auslesen indem du >"RSI" sendest. Aufpassen musst du nur, dass nach jedem String ein zeilenumbruch gesendet werden muss (ASCII nr 13) Danach wählst du mit >"DM8" - den Flash oder mit >"DEM8" - das EEPROM aus. Jetzt wartest du bis der controller wieder mit 'a' antwortet. Dann startest du mit >"PRO1234" die Programmierung an der stelle 1234 (diese zahl halt durch die erste Adresse ersetzen.) Bei der Programmierung musst du noch folgendes beachten: Wenn das Byte das du sendest 0xA5 ist, musst du noch einmal 0x00 senden um das Byte zu bestätigen. Zum beenden des Programmiervorgangs musst du 0xA5 senden und direkt danach 0xFF dann wartest du wieder auf ein 'a' Alle 512 Bytes musst du auf nen 'c' vom controller warten. Wenn du >"RES" sendest kannst du den controller nach dem Programmiervorgang resetten.
Hallo, danke für die ausführliche Antwort. Zwei Fragen bleiben noch: - welches ist konkret die aktuellste und fehlerfreieste Version des Bootladers für "meinen" AVR - die Adressangabe für "PRO1234" - ist das dezimal oder Hex? Frank
hi @peter dannegger der Bootloader ist super. Danke Jetzt mal zu meinen problem. ich versuche mein AVR über eine Bluetooth-brücke zu programmieren. eigendlich ist es eine software rs232-usb eine usb-bluetooth und dann eine bluetooth-RS232 brücke :) mir ist aufgefallen das er jedes byte einzeln sendet, mit einer 7-10ms pause dazwischen. ich benutze auf der PC seite den avbootvc von Jürgen Bremer (jbr). ich habe es noch für den atmega128 angepasst, also die eine zeile von Gerd Laschinski für das erkennen vom Atmega128. wenn ich jedes byte einzeln sende klappt es. ich wollte es jetzt so machen in dem ich jedes byte jetzt erstmal einzeln in einen zwischenbuffer schreibe. und wenn dann der xpage wert erreicht ist, alles an einen stück in den schreibbuffer vom software-RS232 schieben. damit müsste der software-RS232 auch alles in einen stück rüberschicken ohne diese pause von ca 9ms zwischen jeden byte. doch so scheine ich nicht das 'c' vom µC zu bekommen. hat irgendjemand eine idee? oder habe ich einen fehler im code ohne es zu merken? sowas kann ja vorkommen :) Gruß Andreas
Hallo, ich benutze auch den Bootloader, hab bei mir ein kleines Problem festgestellt. Laden und ausführen klappt alles. Nur wenn mein Programm, welches nicht endlos läuft im Hauptprogramm auf des Ende -> return 0; trifft, resetet sich der Controller und beginnt von vorne. Schreib ich das Programm direkt mit Ponyprog ohne Bootloader funktionierst. Hat wer ne Ahnung, an was das liegen kann? Danke Lösungssuchender
>Schreib ich das Programm direkt mit Ponyprog ohne Bootloader >funktionierst. ??? Was "funktioniert" denn da? Was genau macht ein Prozessor, wenn das Programm "zu Ende" ist? Oliver
Bei Ponyprog bleibt das Programm sozusagen stehen ohne Reset, ohne dass das Programm von vorne beginnt ... Oder auf was willst du raus?
Lösungsuchender wrote: > Nur wenn mein Programm, welches nicht endlos läuft im Hauptprogramm > auf des Ende -> return 0; trifft, resetet sich der Controller und > beginnt von vorne. Was erwartest Du ? Du schreibst ein Programm entgegen den Regeln und wunderst Dich über das Ergebnis. Bei einem MC darf das Main nicht enden, bzw. es läuft dann einfach in den Wald. Der Bootloader kann nichts für Deine Programmierfehler. Peter
Danke, die Antwort reicht mir ja schon, wo hab ich was schlechtes über deinen Bootloader gesagt? Wollte ja nur meinen Fehler wissen ...
Angehängte Dateien:
-
rs232int.gif
7,8 KB
Hey Mein Problem: Ich möchte die Umwandelung von den RS232-Pegel mit zwei Transistoren auf TTL-Pegel (siehe Bild) umwandeln. Das klappt auch mit eigenen Programme für den UART. Wenn ich das jetzt aber mit dem Bootloader mit der Verdrahtung genauso mache bleibt der schon bei der Erkennung der Geschwindigkeit hängen. Ich habe auch wie bei meinen vorherigen Programmen das Pull-Up-Bit für den RXD gesetzt. Warum geht es mit den 2 Transistoren nicht? Oder hat einer eine andere simpele und kompackte Idee wie man die Umsetzung von der RS232 zu einen TTL-Pegel macht? Ich habe eienen ATMEGA16 und tackte ihn mit 8Mhz intern.
So ahbe mein Problem gelöst. Mein USB-to-RS232-Adapter macht nur einen Baundrate von 9600 und das Kabel das ich verwedet habe war nicht abgeschirmt genug und ich habe den alten bootloader genommen der anscheinent nciht ganz funktioniert. Also jetzt kann ich auch aus eigender erfahrung sagen das der Bootloader echt hammer ist echt einb großes lob sit echt praktisch.
Hallo!
>Ich habe eienen ATMEGA16 und tackte ihn mit 8Mhz intern.
------------
Das wird eher dein Problem sein.......
gruß,
Bjoern
hi *all! ich habe ein einfaches interface zum flashen von avrs unter windows geschrieben das auch mit höheren port umgehen können sollte und in einem späteren stadium als ersatz für pboot gedacht ist. leider ist es momentan noch ein wenig langsamer als das im ursprünglichen zip-file mitgelieferte pboot, dafür werden aber mehr als nur die ersten vier ports unterstützt. mscomm32.ocx lässt grüßen :) voraussichtlich werde ich in nächster zeit auch eine kommandozeilenversion bauen, ich könnte diese auch online stellen falls bedarf besteht. das standard-kennwort F8 F0 E0 C0 FC ist im ini-file von flashavr bereits eingestellt, ein neues kennwort kann mittels eingabe als leerzeichengetrennter hex-code eingegeben werden, also z.b. A0 82 0B 34 br, thomas
hi *all! das update beinhaltet eine aktualisierte version des bootloaders und des flash-programms. das flash-programm flashavr connected nun für den login immer mit 9600 baud und schaltet anschließend mittels des neuen SPExxxx bootloader kommandos auf die vom benutzer wählbare geschwindigkeit. flashavr beherrscht nun kommandozeilenparameter für alle optionen die auch interaktiv eingestellt werden können, inklusive der möglichkeit die angegebenen parameter in das ini-file zu sichern. tritt ein fehler z.b. beim flashen auf, so wird für die bessere verwendung in batchdateien der exit errorcode auf 1 gesetzt. die anzeige der optionen erfolgt mittels parameter /? oder --help. flashavr verwendet nun den direkten zugriff auf die com-ports via windows api, die geschwindigkeit entspricht aber noch immer nicht der von pboot. möglicherweise liegt das problem des geschwindigkeitsverlusts direkt in den api aufrufen. vorteil des api-zugriffs ist aber die volle kompatibilität z.b. mit usb <-> serial wandlern. br, thomas
hi *all der fehler mit dem crc sollte in dieser behoben sein, es war letztendlich ein kleiner fehler bei der konvertierung von hex zu long values. das ziel für die nächste version wird die kaskadierbarkeit sein, mal sehn' ob ich das hinbekomme und wie die geschwindigkeit sein wird. vor allem befürchte ich, dass diese funktionalität einige änderungen im bootloadercode und flashprotokoll erfordern wird. br, thomas
Hi, ich habe versucht, dein Bootloader zu compilieren. Die GUI gefällt mir ganz gut, nur bekomme ich beim compilieren deiner Original Quelle schon einen Fehler. Ich möchte den Bootloader für einen m32-16 benutzen. Grüße Eisbaeeer
Hier noch die Meldungen: AVRASM: AVR macro assembler version 1.77.3 (Dec 20 2006 14:29:41) Copyright (C) 1995-2005 ATMEL Corporation Creating 'M32BOOT.hex' Assembling 'M32BOOT.ASM' Including 'm32def.inc' Including 'bootload.h' bootload.h(75) : warning : Undefined variable referenced bootload.h(76) : warning : Undefined variable referenced bootload.h(77) : warning : Undefined variable referenced bootload.h(78) : warning : Undefined variable referenced bootload.h(81) : warning : Undefined variable referenced Including 'init.inc' Including 'uart.inc' Including 'commexec.inc' Including 'asc2hex.inc' Including 'commands.inc' Including 'hexout.inc' Including 'readcrc.inc' Including 'readsig.inc' Including 'userprog.inc' Including 'abaud.inc' Including 'program.inc' bootload.h(61) : error : Undefined variable referenced bootload.h(75) : error : Undefined variable referenced bootload.h(76) : error : Undefined variable referenced bootload.h(77) : error : Undefined variable referenced bootload.h(78) : error : Undefined variable referenced bootload.h(81) : error : Undefined variable referenced M32BOOT.ASM(25) : error : Undefined variable referenced userprog.inc(20) : error : Relative branch out of reach program.inc(11) : warning: Immediate byte operand out of range program.inc(67) : warning: Immediate byte operand out of range program.inc(105) : error : Undefined variable referenced program.inc(108) : error : Undefined variable referenced program.inc(109) : error : Undefined variable referenced Assembly complete with 11 errors Deleting 'M32BOOT.hex'
Eisbaeeer wrote:
> bootload.h(75) : warning : Undefined variable referenced
Dann schau einfach mal nach, was in Zeile 75 steht.
Das Programm wurde mit dem alten Atmel Assembler geschrieben, kann sein,
daß später einige IO-Definitionen umbenannt wurden.
Ein GUI hat mein Bootloader nicht, wäre mir auch viel zu umständlich,
jedesmal mit der Maus rumklicken zu müssen.
Ich füge den Aufruf einfach in die Compile-Batch ein und gut is.
Peter
Eisbaeeer wrote: > Hi, > ich habe versucht, dein Bootloader zu compilieren. Die GUI gefällt mir > ganz gut, nur bekomme ich beim compilieren deiner Original Quelle schon > einen Fehler. Ich möchte den Bootloader für einen m32-16 benutzen. > > Grüße Eisbaeeer hi eisbaeeer! ich persönlich habe bisher immer nur m8boot verwendet. um die sache zu vereinfachen hab ich die bootloader für m16 und m32 ebenfalls durchgebaut und das gesamtpaket hier neu angehängt. folgend der output vom assembler. lg, thomas <------------------- snip ------------------> AVRASM: AVR macro assembler version 1.77.3 (Sep 21 2005 08:43:03) Copyright (C) 1995-2005 ATMEL Corporation Creating 'm32boot.eep' Creating 'm32boot.hex' Creating 'm32boot.lst' Assembling 'm32boot.asm' Including 'm323def.inc' Including 'bootload.h' Including 'init.inc' Including 'uart.inc' Including 'commexec.inc' Including 'asc2hex.inc' Including 'commands.inc' m32boot.asm(30): warning: A .db segment with an odd number of bytes is detected. A zero byte is added. Including 'hexout.inc' Including 'readcrc.inc' Including 'readsig.inc' Including 'userprog.inc' Including 'abaud.inc' Including 'program.inc' program.inc(11) : warning: Immediate byte operand out of range program.inc(67) : warning: Immediate byte operand out of range Program memory usage: Code : 355 words Constants (dw/db): 22 words Unused : 15911 words Total : 16288 words Assembly complete with no errors. Deleting 'm32boot.eep' AVRASM: AVR macro assembler version 1.77.3 (Sep 21 2005 08:43:03) Copyright (C) 1995-2005 ATMEL Corporation Creating 'm16boot.eep' Creating 'm16boot.hex' Creating 'm16boot.lst' Assembling 'm16boot.asm' Including 'm16def.inc' Including 'bootload.h' Including 'init.inc' Including 'uart.inc' Including 'commexec.inc' Including 'asc2hex.inc' Including 'commands.inc' m16boot.asm(30): warning: A .db segment with an odd number of bytes is detected. A zero byte is added. Including 'hexout.inc' Including 'readcrc.inc' Including 'readsig.inc' Including 'userprog.inc' Including 'abaud.inc' Including 'program.inc' program.inc(11) : warning: Immediate byte operand out of range program.inc(67) : warning: Immediate byte operand out of range Program memory usage: Code : 355 words Constants (dw/db): 22 words Unused : 7719 words Total : 8096 words Assembly complete with no errors. Deleting 'm16boot.eep' AVRASM: AVR macro assembler version 1.77.3 (Sep 21 2005 08:43:03) Copyright (C) 1995-2005 ATMEL Corporation Creating 'm8boot.eep' Creating 'm8boot.hex' Creating 'm8boot.lst' Assembling 'm8boot.asm' Including 'm8def.inc' Including 'bootload.h' Including 'init.inc' Including 'uart.inc' Including 'commexec.inc' Including 'asc2hex.inc' Including 'commands.inc' m8boot.asm(30): warning: A .db segment with an odd number of bytes is detected. A zero byte is added. Including 'hexout.inc' Including 'readcrc.inc' Including 'readsig.inc' Including 'userprog.inc' Including 'abaud.inc' Including 'program.inc' userprog.inc(20) : warning : 'JMP' not supported on this device program.inc(11) : warning: Immediate byte operand out of range program.inc(67) : warning: Immediate byte operand out of range Program memory usage: Code : 355 words Constants (dw/db): 22 words Unused : 3600 words Total : 3977 words Assembly complete with no errors. Deleting 'm8boot.eep'
So, ich möchte jetzt diesen Bootloader abschließen. RIP. Hier geht es weiter: Beitrag "ATtiny45 Bootloader" Der ist noch kleiner (~200 Words), noch schneller, noch universeller. Aufm ATmega8 sind nun 7,5kB für die Applikation verfügbar nach 1,8s Brennzeit. Die Sourcen sind alle mit dem aktuellen AVRASM2.EXE geschrieben. Peter
Da der alte Thread grad hochgeholt wurde, hier gehts weiter: Beitrag "UART Bootloader ATtiny13 - ATmega644" Es werden alle AVRs ATtiny13 ... ATmega2561 unterstützt. Aktuell ist Version 18. Peter
Beitrag #5859308 wurde von einem Moderator gelöscht.
Beitrag #5859309 wurde von einem Moderator gelöscht.
Beitrag #6337756 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.