mikrocontroller.net

Forum: Projekte & Code AVR Bootloader


Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich habe jetzt meinen Bootlader unter AVRFreaks ins Web gestellt:

http://www.avrfreaks.org/Freaks/freakshow.php?acti...



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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Passwort: hinterm
Username: mond
Ist das so richtig, oder ist hier die Codesammlung ?

Autor: Joline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ist ja nett, wenn Code zur Verfügung gestellt wird. Aber wie Michael
schon bemerkte: Ist nicht hier die Codesammlung?

Autor: Peter Dannegger (peda)
Datum:
Angehängte Dateien:

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

Autor: Axel Rühl (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Axel Rühl (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anbei die Fuses für den M16.


Peter

Autor: Axel Rühl (Gast)
Datum:

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

Autor: Axel Rühl (Gast)
Datum:

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

Autor: Fiffi (Gast)
Datum:

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

Autor: Fiffi (Gast)
Datum:

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

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

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Fiffi (Gast)
Datum:

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

Autor: Peter Fleury (Gast)
Datum:
Angehängte Dateien:

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

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

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

Autor: Peter Dannegger (peda)
Datum:

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

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

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

Autor: Fiffi (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:
Angehängte Dateien:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Axel Rühl (Gast)
Datum:

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

Autor: Fiffi (Gast)
Datum:

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


@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

Autor: AndreasH (Gast)
Datum:

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

Autor: Fiffi (Gast)
Datum:

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

Autor: AndreasH (Gast)
Datum:

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

Autor: Fiffi (Gast)
Datum:

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

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

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Fiffi (Gast)
Datum:

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

Autor: Fiffi (Gast)
Datum:

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

Autor: AndreasH (Gast)
Datum:

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

Autor: AndreasH (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

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

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

Autor: Fiffi (Gast)
Datum:

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

Autor: AndreasH (Gast)
Datum:

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

Autor: AndreasH (Gast)
Datum:

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

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

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

Autor: Sascha Biedermann (Gast)
Datum:
Angehängte Dateien:

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

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

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

Autor: Sascha Biedermann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

wunderbar... der werde ich mich wohl am Wochenende mal drüber machen.

MfG
Sascha

Autor: Uwe Seidel (Gast)
Datum:
Angehängte Dateien:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/ind...
ist evtl. einen Blick wert.

Matthias

Autor: mthomas (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Werner Mehl (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Werner Mehl (Gast)
Datum:

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

Autor: mthomas (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:
Angehängte Dateien:

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

Autor: mthomas (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Matthias (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: AbsoluteBeginner (Gast)
Datum:

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

Autor: Björn (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Dirk (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe jetzt fest 9600 Baud eingetragen und es funktioniert
einwandfrei.

Mfg
Dirk

Autor: Tobias Floery (Gast)
Datum:

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

Autor: mthomas (Gast)
Datum:

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

Autor: theFloe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe probleme den Bootloader unter Linux zu compilieren. Kann mir
jemand ein Makefile mailen oder hier posten?

Autor: Harald Uliczka (Gast)
Datum:

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

Autor: Malte (Gast)
Datum:

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

Autor: Fritz Ganter (Gast)
Datum:

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

Autor: Andreas Turban (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey könntest du den geänderten Code für den Mega32 mal bitte
reinstellen


MFG Andi

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

unterstützt dieser Bootloader hier eigentlich auch den ATmega169?

Gruß
Thorsten

Autor: Frank Simon (Gast)
Datum:

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

Autor: florian (Gast)
Datum:

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

Autor: florian (Gast)
Datum:

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

Autor: AxelR. (Gast)
Datum:

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

Autor: Suschman (Gast)
Datum:

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

Autor: AndreasH (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für den 2313 findest Du hier was:
http://web.media.mit.edu/~ladyada/techproj/Atmex/d...

Autor: Thomas (Gast)
Datum:

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

Autor: Sebastian Bäumler (Gast)
Datum:

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

Autor: Gerd Laschinski (Gast)
Datum:

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

Autor: Gerd Laschinski (Gast)
Datum:

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

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Du schreibst wirklich schöne Programme.

Oh wie süß.

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Gerd Laschinski (Gast)
Datum:

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

Autor: Peter Dannegger (Gast)
Datum:

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

Autor: Gerd Laschinski (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Gerd Laschinski (Gast)
Datum:

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

Autor: Dirk (Gast)
Datum:

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

Autor: Gerd Laschinski (Gast)
Datum:
Angehängte Dateien:

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

Autor: plitzi (Gast)
Datum:

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

Autor: Frank Simon (Gast)
Datum:

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

Autor: Dirk (Gast)
Datum:

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

Autor: Peter Dannegger (Gast)
Datum:

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

Autor: Frank Simon (Gast)
Datum:
Angehängte Dateien:

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

Autor: Frank Simon (Gast)
Datum:

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

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Frank,

sorry, hatte bisher keine Zeit dem Fehler nachzugehen.


Peter

Autor: Wolfgang (Gast)
Datum:

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

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin moin,
läuft der BootLoader auch auf einem ATMega162?

Jens

Autor: Thomas (Gast)
Datum:

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

Autor: Sebastian Bäumler (Gast)
Datum:
Angehängte Dateien:

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

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sebastian Bäumler

Danke :-) ich werde am Wochenende mal testen.

Thomas

Autor: Malte __ (malte) Benutzerseite
Datum:

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

Autor: Jens Schoon (Gast)
Datum:

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

Autor: Gerd Laschinski (Gast)
Datum:

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

Autor: Jens Schoon (Gast)
Datum:

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

Autor: Sebastian Bäumler (Gast)
Datum:

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

Autor: Frank (Gast)
Datum:

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

Autor: xeus (Gast)
Datum:

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

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pboot.exe -?


z.B.:

pboot.exe -c2 -b19200 -pName.hex

(COM2, 19200 Baud)


Peter

Autor: Quacks (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

leider kann ich Deinen Bootloadercode nicht finden,
ist der Link ist nicht mehr aktiv!

Grüße

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Quacks,

ja, es ist etwas mühsam, die letzte Version zu finden:

http://www.mikrocontroller.net/forum/read-4-53146.html#82861


Peter

Autor: Sebastian Bäumler (Gast)
Datum:

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

Autor: Christoph Seiwert (Gast)
Datum:

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

Autor: Peter Dannegger (Gast)
Datum:

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

Autor: Christoph Seiwert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Peter,

danke für die prompte Antwort. HAt funktioniert, dann kann ich ja jetzt
weiter experimentieren!

lg

Christoph

Autor: Christoph Seiwert (Gast)
Datum:

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

Autor: Joline (Gast)
Datum:

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

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, sorry diesen alten thread auszugraben! gibts irgendwo fertige
hexen (wortspiel) die ich einfach mit ponyprog oder bascom in den avr
laden kann??

Autor: Christoph Seiwert (Gast)
Datum:

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

Autor: horst (Gast)
Datum:

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

Autor: FeeJai (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das könnte was mit Seriennummer zu tun haben... Kein Ahnung!

Autor: Felix Jankowski (feejai)
Datum:
Angehängte Dateien:

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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es eine Linux Version die auch mit dem aktuellen Bootloader
fünktioniert?

Autor: Thomas K. (_tom_)
Datum:
Angehängte Dateien:

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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ist jemand so nett und schickt mir ein fertiges hex-file vom
Bootloader?

Atmega128 8Mhz Com0

Besten Dank im Voraus
Gruß Michael

Autor: Thomas K. (_tom_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einfach mal nach oben scrollen -->
http://www.mikrocontroller.net/forum/read-4-53146....

Vielleicht funktionierts.

Viel Erfolg,
Tom

Autor: Dominic Thomé (Gast)
Datum:

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

Autor: Dominic Thomé (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zur Ergänzun, ich spreche hier von Dev-CPP.... weils nix koscht ;)

Autor: Jürgen Bremer (jbr)
Datum:
Angehängte Dateien:

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

Autor: Jörg Friedrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte Ja bitte.

Was ist mit "PSDK" gemeint?

Danke DAU Jörg

Autor: Kai Werner (kai__werner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde mich auch über den Source freuen!

Danke Jan

Autor: Jürgen Bremer (jbr)
Datum:
Angehängte Dateien:

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

Gruss
Jürgen

Autor: Kai Werner (kai__werner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke!!!

echt super von Dir!

Autor: Lorenz Koe (lkoe)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Lorenz Koe (lkoe)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Jörg Friedrich (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Adrigan Peter (Gast)
Datum:

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

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist denn 2048 Word richtig? Der Bootloader ist (zumindest beim ATMEGA8)
deutlich kleiner.

Autor: Adrigan Peter (Gast)
Datum:

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

Autor: Adrigan Peter (Gast)
Datum:

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

Autor: Karl heinz Buchegger (kbucheg)
Datum:

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

Autor: Peter Adrigan (Gast)
Datum:

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

Autor: Peter Adrigan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo mal wieder!

Ich hab das Problem leider immer noch nicht gelöst!
Hat vielleicht jemand von Euch einen Tipp ?

LG
 Peter

Autor: Hauke Radtki (Gast)
Datum:

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

Autor: Hauke Radtki (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Hauke Radtki (Gast)
Datum:

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

Autor: Malte __ (malte) Benutzerseite
Datum:

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

Autor: Tobias Tetzlaff (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Tobias Tetzlaff (Gast)
Datum:

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

Autor: Tobias Tetzlaff (Gast)
Datum:
Angehängte Dateien:

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

Autor: Tobias Tetzlaff (Gast)
Datum:

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

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

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

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:
Angehängte Dateien:

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

Autor: Tobias Tetzlaff (Gast)
Datum:

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

Autor: Hauke Radtki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen installer für die Comm hab ich noch nicht gefunden.

Ich programmiere Java in Eclipse, ist freeware.

Autor: Knuddel Pudel (knopf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gibts den bootloader nicht mehr. der Link scheint tod zu sein.

Autor: Tobias Tetzlaff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ralf,

sind doch alle Bootloader Versionen hier im Anhang.
Ich nutze PBootXP.zip.

Gruß Toby

Autor: Tobias Tetzlaff (Gast)
Datum:

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

Autor: Malte __ (malte) Benutzerseite
Datum:

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

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
;Checks if WDRF in MCUCSR is set
  in  r1, MCUCSR
  sbrc  r1, WDRF
        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.

Autor: Frank Esselbach (Gast)
Datum:

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

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

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


Autor: Frank Esselbach (Gast)
Datum:

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

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1.) Beitrag "Re: AVR Bootloader"
2.) dezimal ... so funkionierts bei mir zumindest ;)

Autor: heiko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo.
was muß gemacht werden um den bootloader auf 8MHz bei ATmega8 
anzupassen?

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

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

Autor: Lösungsuchender (Gast)
Datum:

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

Autor: Oliver (Gast)
Datum:

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

Autor: Lösungssuchender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei Ponyprog bleibt das Programm sozusagen stehen ohne Reset, ohne dass 
das Programm von vorne beginnt ...

Oder auf was willst du raus?

Autor: Lösungssuchender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Push it ...

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Lösungssuchender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, die Antwort reicht mir ja schon,
wo hab ich was schlechtes über deinen Bootloader gesagt?
Wollte ja nur meinen Fehler wissen ...

Autor: Timo Wischer (twischer)
Datum:
Angehängte Dateien:

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

Autor: Timo Wischer (twischer)
Datum:

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

Autor: Tishima (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

>Ich habe eienen ATMEGA16 und tackte ihn mit 8Mhz intern.
                                             ------------
Das wird eher dein Problem sein.......


gruß,
Bjoern

Autor: Thomas Horner (the0ne)
Datum:
Angehängte Dateien:

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

Autor: Thomas Horner (the0ne)
Datum:
Angehängte Dateien:

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

Autor: Thomas Horner (the0ne)
Datum:
Angehängte Dateien:

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

Autor: Eisbaeeer (Gast)
Datum:

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

Autor: Eisbaeeer (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Thomas Horner (the0ne)
Datum:
Angehängte Dateien:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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