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

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

Hi,

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

"Ist nicht hier die Codesammlung?"


Ja, hier ist die Codesammlung.
Deshalb ist ja auch das Codebeispiel über den angegebene Link
erreichbar.
Als Dateianhang war das ja damals nicht möglich.
Da das ja jetzt wieder geht, hier dann eben nochmal.


Änderungen kann ich allerdings nur auf dem obigen Link machen.


Peter

Hallo, alle zusammen
den Bootloader hatte ich lange zeit verdrängt, da ich nicht so recht
wollte...
Nun habe ich aktuellen Projekt die ISP-Schnittstelle "vergessen" und
mich auf den Bootloader besonnen.
Ich konnte die Codesammlung compilieren ( nicht immer
selbstverständlich) und in den Atmega16 via angelöteten Kabelsen am
SPI-Bus programmieren.
In der BOOTLOAD.H steht noch 11.59 Mhz als Clock, habe ich auf meine
4.9152 Mhz geändert-
um es vorweg zu nehmen: es geht nicht, bin vielleicht zu blöd, oder
mein Rechner schafft es nicht, wenn der bootloader läuft, sich um seine
anderen ( auch wichtigen) Sachen zu kümmern. Bei mir schleicht windows,
die applikation lässt sich auch nicht so richtig beenden.

COM 1 19200 CONNECT
FLASHTEST.HEX 0000 - 0000_ <--blink

Damit kann ich aber leben, hi. Welche BootLock und Fusebits muss ich
denn nun beim mega16 setzen, damit der bootloader auch dort ausgeführt
wird, wo er hin muss...???
Naja vielleicht erbarmt sich der eine oder andere und hilft mir aus der
patsche.

Danke
Axel R.

Die Quarzfrequenz dient nur zur Berechnung der Wartezeit, die 11MHz
kannst Du ruhig drin lassen.


Die Fuses müssen auf "THIRDBOOTSTART" (1E00) gesetzt werden.

Das PC-Programm habe ich nur unter Windows 98 getestet.


Peter

Hallo Peter

erst mal danke für die prompte Antwort.
Dachte ich mir schon, das mit der Quartzfrequenz.
Ich will ja auch nicht faul sein, und andere für mich denken lassen,
ich habe mich also belesen und das mit dem Boot Reset Vector und den
einzelnen Einsprungadressen ausprobiert. Funktioniert, wie theoretisch
erarbeitet.
Der Datei INIT.INC entnehme ich, dass der bootloader normal von org0
startet und dann erst die Vectoren umschaltet. Lasse ich also die Fuse
Boot Reset Vector unangehakt? Na, wie auch immer. Mit dem windows2000
scheint's nicht zu laufen, ich teste mal unter 98..
bis denne
Gruß an alle
AxelR.

Anbei die Fuses für den M16.


Peter

Hi, alle zusammen:

habe das Problem in den Griff bekommen, der 1.3Ghz AMD und der 3Ghz P4
sind zu schnell, ich bekomme ein Timeout und Programmer Error 2.
Ich habe noch ein altes Notebook mit einem 100Mhz 486er, damit geht's
auf Anhieb. Ich kann leider den Quelltext nicht neu compilieren, da ich
kein "C" habe. Könnte jemand den Timeout im PBOOT.C hochsetzen,
bitte?

Einen guten Rutsch ins neue Jahr wünscht euch
Axel Rühl
Potsdam

Nochmals danke für die nette Hilfe...

Hallo Peter,
ich nochmal:
ich habe nun also auch noch meinen 450'er P2 mit Win98 nochmal
aufgebaut, man schmeisst ja nichts weg. unter Win98 funktioniertz
einwandfrei!!!

Ich neheme an, die Art des Zugriffs auf die Serielle Schnittstelle wird
von XP und/oder Win2000 so nicht aktzeptiert...

Du spricht ja direkt die Register an. ansich nicht schlecht, ich wüsste
die register garnicht, die da angesprochen werden müss(t)en.

wenn man API- Funktionen nimmt, ob es dann auch unter win2000 und XP
geht?
Ich habe mit Delphi und der CPort-Komponente ein wenig herumgespielt,
da geht das dann über fileCreateFile und so. Ich habe aber nicht soo
viel Erfahrung, wie man das nun im einzelnen handeln muss.

Nochmal, RESPEKT!

Für mich ein Grund mehr, mich intensiver mit der Materie zu
beschäftigen.

Guten Rutsch an alle
Gruß aus Potsdam
Axel Rühl

Hallo Axel und Peter,

bis jetzt habe ich mich noch nicht mit den Bootloader beschäftigt. Das
werde ich aber in den nächsten Tage nachholen ...

>Ich neheme an, die Art des Zugriffs auf die Serielle Schnittstelle
>wird von XP und/oder Win2000 so nicht aktzeptiert...

Probierst du bitte mal allowio von PortTalk/Beyondlogic

Hallo Axel und Peter,

bis jetzt habe ich mich noch nicht mit den Bootloader beschäftigt. Das
werde ich aber in den nächsten Tage nachholen ...

>Ich neheme an, die Art des Zugriffs auf die Serielle Schnittstelle
>wird von XP und/oder Win2000 so nicht aktzeptiert...

Probierst du bitte mal allowio von PortTalk/Beyondlogic aus ?
http://www.beyondlogic.org/porttalk/porttalk.htm


Ich habe mal kurz in die Datei "PBOOT.C" hereingeschaut. Sieht ja gar
nicht so wild aus ... Womit hast du das ganze denn kompiliert ?

>wenn man API- Funktionen nimmt, ob es dann auch unter win2000 und XP
>geht?

Ich habe schon mal WinIO von www.internals.com eingesetzt. Damit
funktionierts auf jedem Fall.

Ich werde evtl. eine Win 2000/XP Version schreiben. Ich werde euch
informieren ...


Die Idee mit den 0,2s und der automatischen Baudratenerkennung ist sehr
gut ! Hut ab !!!


Gruß

Fiffi

Hallo,

ich versuche gerade den Bootloader auf einem ATmega128 zum laufen zu
bringen ... (2 UARTS, etc ...)

Hat das schon mal jemand gemacht ?


@Peter
Hast du die Dateien "m*def.inc" selbst editiert ?
In meinen (AVR-Studio) fehlt nämlich "RAMSTART", "NOINTaddr" ...

Wie funktioniert die automatische optimale Baudrateneinstellung ?
Funktioniert diese auch noch bei einem Quarz von 16 MHz ?

Könntest du mir das pboot Programm bzw. die Kommunikation AVR<->PC
bitte mal ein wenig erläutern ?


@Axel
>Könnte jemand den Timeout im PBOOT.C hochsetzen, bitte?
Ich habe das Timeout auf 16 hochgesetzt. Oder wie hoch soll ich dir das
Timeout setzten ? Die Datei befindet sich im Anhang. Ich habe es mit
Borland Turbo C++ 3.0 für DOS kompiliert. Leider kann ich das Programm
nicht testen ... (P4, Win2k, nur ATmega128)

Ich habe die PortTalk Beispiele mit Dev-C++ 5 (GCC/MinGW) erfolgreich
kompiliert. Der Win2k/XP Version steht also nichts im Weg ...

Welche Probleme hast du genau unter W2k/XP ? Nur Timingprobleme oder
auch Zugriffsfehler ?

>Für mich ein Grund mehr, mich intensiver mit der Materie zu
beschäftigen.

Ich glaube da komm ich auch nicht herum ...


Gruß

Fiffi

@Fiffi,

die Kommandos sind Texte mit 0x0D abgeschlossen:

"\370\360\340\200\374": Start des Bootloaders, muß ständig
gesendet werden, bis der Bootloader mit 'a' antwortet.

"Reset": Beenden und Start der Anwendung

"DM8": Auswahl des Flash

"DEM8": Auswahl des EEPROM

"FPR1234": Start der Programmierung ab Adresse 0x1234

Danach werden die Daten binär übertragen.
0xA5, 0x00 beendet das Programmieren
0xA5, 0xA5 bedeutet das Byte 0xA5

Nach jeder Adresse 0x***F muß auf ein 'c' vom Bootloader gewartet
werden.

"READ4321": Lesen ab Adresse 0x4321

Es wird das gelesene Byte binär gesendet. Nach Erhalt von 'c' wird
das nächste Byte gesendet, andere Bytes als 'c' beenden das Lesen.

Mein PC-Programm kann aber nur programmieren.

Mit Windows-Anwendungen habe ich mich noch nicht beschäftigt. Ich
benutze noch W89SE und da habe ich keine Einschränkungen für
DOS-Programme.

Mir war es wichtig, daß das Programm schnell und ohne großes Getöse
startet und einfach im Make mit aufgerufen werden kann und auch keine
umständliche Bedienung mit der Maus benötigt.

Der Programmer im Studio für das STK500 ist ja dagegen eine Zumutung.
Den habe ich daher nur zum Setzen der Fuses benutzt.
Zum Glück ist ja auch eine Kommandozeilenversion (AVRPROG.EXE) mit
dabei, die habe ich dann zum Brennen des Bootloaders benutzen können.
Da erspart man sich zumindest die nervigen Mausklicks.


Bei 16MHz kann man aber nur bis 38400 Baud einstellen, da sonst der
Fehler zu groß wird. Für 115200 Baud sollte man Standardquarze
vorziehen (z.B. 14,7456MHz)


Die erweiterten *def.inc sind in dem *.zip mit dabei.



Peter

Hallo Peter,

danke für die Erklärung !

>Mir war es wichtig, daß das Programm schnell und ohne großes Getöse
>startet und einfach im Make mit aufgerufen werden kann und auch keine
>umständliche Bedienung mit der Maus benötigt.

Ich möchte auch nur eine W2k/XP fähige Konsolenanwendung schreiben.
Mir ist wichtig einen freeware Compiler zu nutzen ...


Gruß

Fiffi

@Fifi
Ich finde es besser wenn man für die serielle Kommunikation
Windows-API-Funktionen verwendet. Der direkte Zugriff auf die
UART-Register funktioniert zwar unter Win9x, findet dann aber
ausserhalb der Kontrolle des Betriebssystems statt. Unter Win2000/XP
ist ein direkter Hardware-Zugriff nur mit PortTalk und ähnlichen
Treibern möglich.

Als Anhang ein Beispiel Programm wo mittels Win32-API via COM-Port mit
einem Modem kommuniziert wird. Kann mit GCC/MinGW kompiliert werden.

Hallo,

ich habe den Quellcode ein wenig geändert, um den Mega128 zu
unterstützen. Leider funktioniert dies nicht: er stürzt in der Routine
"abaud" ab, und macht einen Reset.

Kann bitte mal jemand diesen Stand auf einem anderen AVR probieren ?

@ Peter Fleury
>Ich finde es besser wenn man für die serielle Kommunikation
>Windows-API-Funktionen verwendet.

Ich auch ...

>Als Anhang ein Beispiel Programm wo mittels Win32-API via COM-Port
>mit einem Modem kommuniziert wird. Kann mit GCC/MinGW kompiliert
>werden.

Danke !


So wie es aussieht, muß ich einen neuen Bootloader schreiben, da ich
Peter's nicht auf meinem Mega128 zum laufen bekomme.

Ich habe z.Zt. leider auch keinen Mega16 o.ä. um zumindest mal den
original Code zu probieren. (Ich habe nur einen Mega128 und einen
Rechner, wo "PBOOT.EXE" anscheinend nicht drauf läuft ...)


Gruß

Fiffi

@Fiffi,


bist Du sicher, daß der Code auch richtig im Flash gelandet ist ?

Es gibt nämlich Programmer, die können nur die ersten 64kB des Mega128
beschreiben, der Bootloader muß aber ganz ans Ende.

Die Fuses müßten ja ähnlich wie oben für den Mega16 sein.


Achso, Du must natürlich auch die ELPM, EJMP Instruktionen für die
Commandotabelle verwenden !


Peter

Hallo Peter,

>bist Du sicher, daß der Code auch richtig im Flash gelandet ist ?

Ja, der Code landet richtig im Flash ab Adresse 0xFC00.

>Es gibt nämlich Programmer, die können nur die ersten 64kB des
>Mega128 beschreiben, der Bootloader muß aber ganz ans Ende.

Ich verwende den JTAGICE.

>Die Fuses müßten ja ähnlich wie oben für den Mega16 sein.

Im Anhang befindet sich ein Sreenshot ...


>Achso, Du must natürlich auch die ELPM, EJMP Instruktionen für die
>Commandotabelle verwenden !

Ich verstehe nicht was du meinst. Der Mega128 hat keinen ELPM Befehl.
EJMP gibt es nicht, sondern nur EIJMP. Was soll ich den mit den
Befehlen tun ?

Kannst du evtl. mal über den Code schauen aus meinem letzten Beitrag ?


Vielen Dank für deine Hilfe !


Gruß

Fiffi

Hallo Peter,

ich habe einen Fehler in meinem Code gefunden:

ich hatte das define ".equ base = ..." falsch. Beim Mega128 muss es
"SMALLBOOTSTART" heißen ...

Aber das ändert nicht an meinem Problem, daß "er" mir irgenwo
"abhaut" in Richtung Application Code, der überall 0xFF ist.

Er verschwindet nicht über die Routine "userprog".


Gruß

Fiffi

@Fiffi,

das mit dem Mega128 ist etwas tricky, in den oberen 64kB zu bleiben.

Anbei die neue Include-Datei, damit müßte es klappen.

Zumindest die unteren 64kB sollten sich damit brennen lassen und ehe Du
die voll hast, dürften schon ein paar Monate vergehen.

Dann dürftest Du mit dem Mega128 auch schon so vertraut sein, daß die
Erweiterung für die oberen 64kB nur ein Klacks ist.

Man könnte z.B. die Adreßangabe für den Programmierbefehl auf 5 oder 6
Hex-Digits erweitern. Da ja immer bis zum 0x0D-Zeichen umgewandelt
wird, ist das voll abwärtskompatibel.

In der PC-Software muß man dann noch den Segmentrecord mit auswerten,
der wird bisher ignoriert.
Und auch einen 128kB Puffer alloziieren.


Peter

@Peter Fleury,

Dein Code hat mich inspiriert, vielleicht doch mal nach Windows zu
kompilieren.

Leider hat Borland C++ 3.1 diese Modemfunktionen nicht, deshalb habe
ich es ja zu Fuß machen müssen.

Ich hab noch irgendwo ein Borland C++ 4.0 rumliegen, mal installieren
ob das sowas kann.


Peter

Hallo zusammen,

gut reingerutscht?
ich denke ja, fein.

Ich habe einen weiteren Grung ausgfindig gemacht, warum's nicht lief:
Mein COM3 liegt aud 0xD000 bis D0007 und mein COM4 auf 0xD4000 bis
D4007.
Ich hatte mir eine Erweiterungskarte einbauen müssen, weil mein neuer
Rechner die Seriellen , bis auf COM1 "ausgeschwitzt" hatte, jaja ohne
Schweiß keinen Preis, selbst schulz. Teilen sich beide Interrupt 19.

Timeout hochgesetzt, danke. Bringt auch nichts. Trotzdem,. versuch
macht kluch...

Da stehe ich mit meinen Delphi und Pascal-Dialekt wohl ziemlich allein
auf weiter Flur, wie es scheint.
Nicht das ich mit C nichts am Hut habe, schon von Arbeit wegen, jetzt
aber umlernen?? ich portiere das mal die PBOOT.C als ganz normales
Windows-Programm unter Delphi6 für alle Mausklicker. die seriellen
Schnittstellen sind, wie es scheint, im gegensatz zur Parallelen nicht
vom Zugriff durch XP gesperrt (API-Funktionen vorausgesetzt). Dann ist
auch die Adresse egal.

Wenn ich die Timer-und ModemEvents in die Konsolenanwendung
untergebracht habe,(das ist das ,was ich nicht hinbekomme) mach ich uns
noch 'ne XP-Kommandozeilen Variante mit Delphi-Pascal.

Erst mal habe ich meinen W98-Rechner wieder angemacht, funktioniert ja
einwandfrei, gibt also eigentlich keinen Grund zur Hektik...

Grüsse an alle und viel Spass noch

Axel

Hallo,

@Peter

Vielen Dank für deine Hilfe! Ich sehe ein, daß ich mich erst mal mit
der Bootloader Geschichte an sich vertraut machen muss, bevor ich
deinen Code zum laufen bekomme.

Ich werde versuchen ein Assembler Programm mit fester Baudrate zu
schreiben, und dabei die Grundlagen lernen ...

>Ich hab noch irgendwo ein Borland C++ 4.0 rumliegen, mal installieren
>ob das sowas kann.

Kennst du Dev-C++ von Bloodshed ? Schau mal unter
http://www.bloodshed.net/devcpp.html

Es enthält eine IDE und den GCC/MinGW. Ich würde mich über eine Version
für einen Freeware Kompiler freuen ...

Die Kommandozeilenversion von Borland C++ 5.5 ist Freeware. Schau mal
unter:
http://www2.pmf.fh-goettingen.de/~isimon/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

Ich habe mir vor einiger Zeit mal eine Klasse in C++ sowohl für den
C++-Builder von Borland als auch den dev-c++ geschrieben, mit der ich
Daten über die serielle senden und empfangen kann.

Damit habei ich das C-Programm (PBOOT.C) von Peter ziemlich einfach
umschreiben können, so daß der Zugriff auf die serielle jetzt nur noch
über API-Funktionen läuft.
Da ich zur Zeit keinen Mikrocontroller zur Verfügung habe, geschweige
denn einen ATMega, kann ich das nicht komplett testen.
Das Programm läßt sich kompilieren, sendet den Initialisierungsstring
über die serielle des PC raus und wartet darauf das was zurückommt.
D.h. der Balken dreht sich ständig. Mehr war mir nicht möglich zu
überprüfen.

Falls jemand Interesse hat und das ganze weiter testen will, bitte
melden.
Ich würde das Programm dann mit Quellcode mailen.

Wenn es einmal läuft, läßt es sich auch ziemlich einfach auf
Windows-Click erweitern.

Hallo Andreas,

>Falls jemand Interesse hat und das ganze weiter testen will, bitte
>melden.
>Ich würde das Programm dann mit Quellcode mailen.

Natürlich haben wir Interesse !

Kannst du bitte hier ins Forum stellen oder mir mailen ?


Gruß

Fiffi

Hallo Fiffi,

was machst Du denn um 02.40 Uhr noch hier?
Hatte das Programm gerade fertig gestellt und dann noch eben gepostet.
Aber nicht erwartet, daß kurz danach noch jemand antwortet.

Zur Zeit habe ich das nur für den gcc (also dev-c++) lauffähig.
Für den C++-Builder war mir dann doch gestern abend zu spät.
Wenn Dir das reicht, setze ich es heute nachmittag rein.
Ansonsten würde ich das erst noch für den Builder hinbasteln und beide
Versionen bringen.

Hallo Andreas,

>was machst Du denn um 02.40 Uhr noch hier?

Ich habe Urlaub ...


>Wenn Dir das reicht, setze ich es heute nachmittag rein.

Natürlich ... (Ich komme erst heute abend dazu, mich damit zu
beschäftigen ...)

>Ansonsten würde ich das erst noch für den Builder hinbasteln und
>beide Versionen bringen.

Kann man die Version dann mit der 5.5 Freeware Version kompilieren ?



Gruß

Fiffi

Habe es doch schon für den Builder hingebastelt.
Ging einfacher als ich befürchtet hatte.
Ich denke nicht, daß es ohne weiteres für den Borland-Freeware
funktioniert.
Den habe ich zwar, aber bisher nicht installiert. Habe ich derzeit auch
nicht vor weil man für den gcc einfach mehr Quellcode findet wo man
sich dran orientieren kann.
Ich habe nur Probleme mit dem Debugger, daher benutze ich nachwievor
den C++-Builder.

Geh doch einfach auf: http://www.bloodshed.net/ und download den
dev-c++ mit dem mingw-Compiler. Ich habe das mit dem dev-c++ 4.9.8.4
compiliert. Beim Borland war es der C++-Builder 5.

Damit man erkennen kann, was Peter an den verschiedenen Stellen
vorhatte (und wo ich Fehler reinprogrammiert habe) sind alle Zeilen die
ich rausgenommen habe auskommentiert.
Ebenso hinter meinen neuen Zeilen befindet sich das Datum.

Wenn das Programm mal einwandfrei läuft muß dies alles noch bereinigt
werden.
Vorher möchte ich das auch nicht mit Windows-Fenstern versehen. Weil
erstmal die eingentliche Funktion einwandfrei sein sollte.

Falls Fragen sind melde Dich einfach nochmal.
Ich werde Dir auch eine email schicken. Dann hast Du meine
email-adresse.
Wegen laufend unerwünschter email habe ich mir abgewöhnt überall meine
adresse mit anzugeben.

@Fiffi

und gehts nun mit dem neuen Include ?

Es kann ja nur an dem Commandointerpreter gelegen haben, denn das ist
die einzige Funktion, die IJMP verwendet.

Und für das ELPM mußte noch das RAMPZ geladen werden.


Peter

Hallo,

@Andreas

Ich kann das Programm kompilieren, bekomme aber eine Warnung, da
alloc.h in pboot.cpp includiert wurde:

\Dev-Cpp\include\c++\backward\backward_warning.h:32
#warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section
17.4.1.2 of the C++ standard. Examples include substituting the <X>
header for the <X.h> header for C++ includes, or <sstream> instead of
the deprecated header <strstream.h>. To disable this warning use
-Wno-deprecated.

Bringt er die Warnung, da wir malloc() nutzen ? Sollten wir es auf
new/delete umstellen ?

Ich kenne Dev-Cpp leider noch nicht lange ...


@Peter
>und gehts nun mit dem neuen Include ?

Ich habe heute einen Mega16 bekommen, mit dem ich zuerst mal die W2k/XP
Version des PBOOT.EXE Programms zum laufen bringen möchte.

Danach werde ich das AVR-Programm für den Mega128 anpassen ...


Ich halte euch auf dem laufenden ...


Gruß

Fiffi

Hallo,

ich habe den Mega16 @ 8MHz mit Peters original Code und original
PBOOT.EXE geflasht. (Win2k, P4 1,6GHz).

>>COM 3 at 38400 Baud: Connected
>>Program m16test.hex: 0000 - 0001
>>Programming successful

Leider funktioniert das Programm von Andreas noch nicht. Ohne AVR-Reset
dreht sich der Pfeil/Zeiger nach dem Anfruf schnell, wird dann
langsamer und bleibt dann stehen. ein RESET des AVR's hat keine
Wirkung.

Andreas, hast du eine Idee was das sein kann ?


Gruß

Fiffi

Diese Warnung hatte ich nicht.
Verstehe ich auch nicht.
Was sein könnte, daß bei einem neuen dev-c++ auch ein neuerer mingw
dabei war. Ich erinner mich daran, daß bei einer älteren Version vom
dev-c++ wieder auf den alten mingw 2.9.??? zurückgegangen wurde, weil
der neue Fehler hatte.
Die ganzen malloc-sachen usw. konnte ich nicht testen, da kein AVR
dran. nimm einfach statt alloc mal malloc rein.

Es hätte mich auch gewundert, wenn es auf Anhieb geklappt hätte.
Mir war z.B. folgendes in Peter´s Programm nicht klar:
  if( !ComPort )
    return COMMAND_DONE;

Daraus habe ich das:
 if(Mikrocontroller1->GetHandle() == NULL)
   return COMMAND_DONE;
gemacht, weil ich das so verstanden habe, wenn die Schnittstelle nicht
geöffnet ist, bzw. kein Port angegeben, dann wieder raus aus
Emfpang().
Aber was ich nicht verstanden habe ist dann das:
    sendstring( "\370\360\340\200\374" );
    if( empfang( 0 ) == COMMAND_DONE ){
      printf("\bConnected\n");

In der Funktion connect() wird das ausgeführt. Mir war nicht klar wieso
bei COMMAND_DONE wieder rausgegangen wird.
Es sei denn, der Mikrocontroller schickt ein 'a' zurück wenn er sich
beim PC meldet. Was gleich wie COMMAND_DONE wäre. Dann könnte ich das
wieder verstehen. Das weisst Du aber besser, da Du den Controller mit
Quellcode hast.

Kannst Du mal Hilfsanzeigen rein machen oder den Debugger benutzen?
Ich habe den Debugger vom dev-c++ nie richtig benutzt weil der unter NT
eine Macke hat. Ich benutze immer den vom Borland-Builder. Habe mir
allerdings mal sagen lassen, dass der vom freeware auch mit dem gcc
bzw. mingw-dateien funktionieren soll.

Die Frage ist jetzt, was macht das Programm während dem drehenden
Balken bzw. wenn es (und welches) das erste Zeichen empfangen hat.

Die Klasse für die serielle habe ich schon mehrfach eingesetzt. An der
kann es eigentlich nicht liegen. Aber man weiss ja nie.

Hab noch was vergessen zu der Warnung.

Ich habe mir Deine Fehlermeldung mal genauer angesehen.
Es könnte aber das sein:
#include <string.h>

das es jetzt so:
#include <string>

sein muss.

Mit new/delete geht es auch. Ist natürlich mehr Arbeit. Halte ich auch
nicht für notwendig da es ja vorher funktioniert hat. Immer getreu dem
Motto "Never touch a running system".

Der Compiler motzt ja auch nur an, das ein veralteter Header
reingenommen wurde.
Beim AVR-gcc hat der aber genauer gesagt, welcher Header alt ist.
Kannst Du das mal versuchen näher rauszufinden.

@AndreasH

das mit dem:

  if( !ComPort )
    return COMMAND_DONE;

ist nur zum Debuggen drin. Damit habe ich getestet, ohne wirklich immer
mit dem AVR verbunden sein zu müssen.

Sobald eine COM ausgewählt ist, enthält ComPort die Adresse und ist
ungleich 0.


Peter

Hallo Andreas,

>nimm einfach statt alloc mal malloc rein.

wenn ich malloc.h anstatt alloc.h inkludiere, bekomme ich keine
Warnungen mehr.

Ich hatte mir Dev-c++ 4.9.8.0 heruntergeladen, und habe ihn gestern auf
4.9.8.5
upgedated. (Online-Update)


>Aber was ich nicht verstanden habe ist dann das:
>    sendstring( "\370\360\340\200\374" );
>    if( empfang( 0 ) == COMMAND_DONE ){
>      printf("\bConnected\n");

Ich verstehe es auch nicht !

Peters Version und meine selbstkompilierte Verion (mit Borland Turbo
c++ 3.0) senden nach ihrem
Aufruf unterschiedliche Daten ! (Sie funktionieren aber beide ???!!!)

Siehe die beiden Dateien im Anhang. ("peter_out.txt" und
"tc30_out.txt")

Kannst du mir das erklären Peter ?

Um die Dateien zu erstellen, habe ich "Termial v1.9b - 20030716 - by
Br@y++" mit folgenden
Einstellungen verwendet: Com3, Baudrate 38400, 8 Datenbits, kein
Paritybit, 1 Stopbit, kein Hanshaking.

Als Verbindung habe ich folgendes:
RxD und TxD gekreuzt, GND verbunden, alle anderen Pins offen.

COM1 und COM2 sind auf dem Mainboard, und haben die Standardadressen:
0x3f8 unf 0x2f8 ...
COM3 und COM4 ist eine PCI-Karte mit Netmos Chip. COM3 hat folgende
Resourcen:
E/A: D400-D407
IRQ: 9

Ich vermute die DOS-Box emuliert dann die Adresse 0x3e8 ... ?

Meine selbstkompilierte Version sendet mit der sendstring Zeile
folgendes (hex):
0xF8
0xF0
0xE0
0x80
0xFC
0x0D


>Ich habe den Debugger vom dev-c++ nie richtig benutzt

Er ist eine reine Katastrophe ...


Ich habe den Fehler nochmals untersucht:

Ich führe dein Programm immer mit den Argumenten "-c3 -b38400
-pm16test.hex" aus.
Ich habe nun zu Testzwecken folgendes:

An COM2 hängt ein JTAGICE, mit dem ich den AVR debuggen kann.
COM1 ist mit COM3 verbunden. (An COM1 läuft ein Terminal Programm)

Wenn der AVR und das JTAGICE aus ist, dreht sich der Blaken ständig.
Ich empfange an COM1 aber nichts !

Wenn der AVR und das JTAGICE (COM2 !) an ist, tritt das Phänomen mit
dem langsamer werdenden
Balken auf. Ich empfange an COM1 aber nichts !


Hast du eine Idee irgendeine Idee ?

Wie hast du das Programm probiert ?

Kannst du mir mal deine binär Datei per Email schicken ?


(Im Anhang befindet sich meine aktuelle pboot.cpp)


Gruß

Fiffi

Hallo,

die habe einen Fehler gemacht !:

Peters Programm und meine selbstkompilierte Version geben dasselbe aus.
Beim erstellen der Dateien (oben im zip-file) habe ich Peters Programm
falsch aufgerfen "pboot -c3 b38400 -pm16test.hex".

es läuft dann mit 57600 Baud.

Bei korrektem Aufruf mit "pboot -c3 -b38400 -pm16test.hex" empfange
ich daselbe wie in der Datei "tc30_out.txt".


Aber unsere Dev-C++ Version sendet nichts ...
Ich bin auch mal durch die Klasse durchgesteppt, dort wo auf Fehler
überprüft wird, ist angeblich alles OK.


Gruß

Fiffi

@Fiffi:
>>Wie hast du das Programm probiert ?
Wen meinst Du damit? Mich oder Peter?

Falls Du mich meinst ich habe das Programm heute nochmal getestet. Aber
nur soweit, daß ich sehe ob was gesendet wird. Ich habe einen
Schnittstellentester angeschlossen und bin dann mit dem Debugger vom
C++-Builder drangegangen. Mehr konnte ich nicht testen, da ich nichts
dahinter habe.

Ich habe aber festgestellt, daß hierbei: sendstring(
"\370\360\340\200\374" ); was rausgeschickt wird.
Habe gerade nochmal den Debugger vom Builder angeschmissen. Es sind
exakt die selben Zeichen wie in Deiner TXT-Datei.

Irgendwie verstehe ich Deine Aufzeichnung noch nicht. Laut dem Code in
PBoot.c wird immer der String "\370\360\340\200\374"
rausgeschickt.
Das sind 5 Byte. Einschliesslich des CR am Ende sind es dann 6 Bytes.
Da bis zum Erkennen der Antwort des Controllers dies in einer Schleife
läuft, würde sich das mit jedem 7.Byte wiederholen.
Dies stimmt auch mit Deiner Aufzeichnung des von Dir compilierten
Programms überein (F8 F0 E0 80 FC 0D).
Wenn ich mir jetzt die Aufzeichnung ansehe, die Du mit Peters Programm
gemacht hast, dann ist immer nach 4 Byte eine Wiederholung. (3C 07 7E
E4).
Wobei der Anfang ganz anders ist (3C 38 E6 22). Also irgendwie bin ich
zu blöd das zu verstehen. Ein CR sehe ich überhaupt nicht.
Während es in Deiner Aufzeichnung vorhanden ist.


Der Compiler wandelt das "\370\360\340\200\374"  in einzelne
Bytes um. Wie die Umrechnung funktioniert weiss ich im Moment nicht.
Habe ich mal irgendwo gelesen.

Im Moment gibt aus meiner Sicht zwei Probleme:
Zum einen muß klar sein, was aus diesem String werden soll bzw. was
will der Controller genau haben. (Sollte aus dem Quellcode des
Contorllers hervorgehen. Habe im Moment nur keine Zeit mir das genau
anzusehen, da ich noch eine Software schreiben und ein Angebot für eine
größere Sachen machen muß). Dies ist aber erstmal das kleinere Problem,
da die Anzahl der Bytes mit dem Quellcode übereinstimmt.

Zum anderen muß der Unterschied zwischen dem von Dir compilierten und
Peter´s geklärt werden. Hier stimmt die Anzahl der Bytes nicht. Dies
sollte erstmal geklärt werden.

Ich kann Dir meine Binär-Datei schicken. Das Ergebnis wird dasselbe wie
bei Dir sein.

Grüße
Andreas

@Fiffi: Mist hatte bei mir etwas länger gedauert mit dem Schreiben weil
ich parallel zum Schreiben nochmals mit dem Debugger durchgegangen
bin.

Ich habe das mit dem Borland C++Builder und dem Debugger getestet. Bei
mir kommt was raus. Habe ich auch auf dem Schnittstellentester
gesehen.

Wie bist Du denn da durch gesteppt. Mit dem Debugger vom dev-c++?

Wenn Du willst maile ich Dir mal diese Version. Damit ich den
Schnittstellentester nicht umstellen muß, aber auf 9600 Baud
eingestellt. Mußt also die richtigen Parameter übergeben.

@Peter: Dachte schon, daß hätte einen anderen Sinn, den ich nicht
verstehe.

Hallo Andreas,

die beiden Programme geben das selbe aus. Mein Fehler, wie oben
beschrieben ...

>Wie bist Du denn da durch gesteppt. Mit dem Debugger vom dev-c++?

Ja, ich habe im Menü Projekt -> Projekt Optionen ->
Tab-Seite: Compiler -> Zeile: Linker -> "Generiert
Fehlersuchinformationen" auf "Yes" gestellt.

Er erzeugt nach erneutem kompilieren eine exe-datei mit 1,86 MByte !

Dann habe ich den besch******* Debugger im Dev-C++ verwendet. Mit
"Fehlersuche" "Ausführen bis Cursor" ...
In dem Debugger / Frontend sind viele Bugs ... (Manchmal macht er keine
Haltepunkte, oder bleibt dort nicht stehen, ganz zu schweigen von der
tollen "Watch" Funktion ...

Kann ich die erzeugt exe noch mit irgendetwas anderem außer Dev-C++
debuggen ?


Welche Windows Version benutzt du ?
Kannst du das Programm bei dir mal mit einem gekreuzten Kabel über eine
zweite serielle Schnittstelle testen ?

Kannst du es evtl. mal mit der hex-datei aus dem Anhang probieren ?
(ist ein fast leeres main() ...)


Gruß

Fiffi

Hallo Leute!

Ich habe jetzt keine Lust mir alle Beiträge erst durchzulesen...

Ich habe den Programmer nach Linux portiert, siehe Anhang. Funktioniert
ganz gut, evtl. kann ihn jemand gebrauchen.

@peter
Wenn du möchtest, kannst du ihn mit in dein ZIP file tuen.

MfG
Sascha

Hallo Sascha,

>Ich habe den Programmer nach Linux portiert, siehe Anhang.

Danke! Ich bin vor ein paar Wochen auch umgestiegen auf Linux.


Peter hat den Bootloader erweiert. (siehe Anhang)


Hier seine Mail an mich:
> Anbei eine neue Version des Bootloaders.
> Jetzt ist Verify und CRC-Check mit drin:
>   0 = CRC o.k.
> -2 = CRC Fehler
> -1 = CRC nicht unterstützt (alter Bootloader)
>
> Read ist auch im AVR drin, nur im PC-Programm fehlts noch.
> Mit "RSIZE" kann der PC abfragen, wieviel Flash / EEPROM er
> überhaupt lesen muß.
> Mit "RSIG" kann er die Signatur abfragen, d.h. was für ein AVR
> es ist.
>
> Für den Mega128 ist auch schon das Einlesen der Adresse auf
> 20 Bit (= 5 Hex-Digits) erweitert.

Leider habe Ich zur Zeit keine Zeit zum testen, da ich am renovieren
bin...

Kanst du den neuen Bootloader evtl. mal testen, und dein Linux Programm
erweitern ?


Gruß

Fiffi

Hi!

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

MfG
Sascha

Hi,
damit das Thema nicht "abkühlt".
Also ich hab das jetzt aufmerksam verfolgt, wollte aber den Code nicht
verwenden sondern selber lernen. Allerdings gibts da schon so einige
Probleme bei mir.
Prinzipiell kann ich den bootloader schon mal nicht compilieren wegen
der .if anweisung in macro out_ext usw. aber das könnte ich ja
auslassen weil es ja eh nur für meinen uC ist. Ansonsten knack ich das
nicht mit dem Sprung nach $0000, hab was kleines geschrieben um die
Geschichte zu testen. Aber nach dem Sprung , wenn er denn passiert,
geht nix mehr. Ist im Anhang.
Wollte das eigentlich nicht übertreiben mit dem Bootloader aber das
frisst mir ja die Zeit weg. Wollte eigentlich in Delphi nen Progger für
USB schreiben aber jetzt häng ich schon ewig an der ASM-geschichte rum.
Jetzt frag ich mal euch.
Hab das zwar schon in "allgemein" gepostet , aber dort antwortet mir
schon auf einige Fragen keiner mehr. Kann nur heißen , dass die Frage
unsinn oder uninteressant ist ?!?!?!.

So ich bin jetzt auch XP-Benutzer (Aldi-PC).

Werde mich also mal daran machen, daß das PC-Programm XP-fähig wird.
Kann doch nicht so schwer sein.


@Uwe,

also in meinem Code ist doch gar kein .if drin.

Nach dem Sprung nach 0x0000 kann doch nur dann was passieren, wenn Du
auch was runtergeladen hast.
Nach dem der Bootloader z.B. mit dem STK500 reingebrannt wurde, ist
darunter doch alles gelöscht.


Peter

Ich will mal meine neuesten XP-Erfahrungen berichten:

Also man kann auch unter XP ohne irgendwelche Treiber im DOS-Fenster
(mein uralt Norton Commander geht auch noch) direkt mit inportb() und
outportb() auf die UART zugreifen.

Der Unterschied, es geht nur sehr langsam.
Ich habe einfach die Timeouts in dem Bootloader drastisch erhöht und
dann konnte ich auch den Mega8 unter XP proggen.

Allerdings dauern die 7kB jetzt nicht mehr 1,5s sondern 49s, egal ob
ich 115200 oder 9600 Baud nehme.

Ich werd mal weiter forschen, ob ich rauskriege, wo die Zeit verloren
geht.


Peter

So, ich habe jetzt rausgekriegt, daß es elend lange dauert, bis ein Byte
zum ATMega gesendet wurde und dann dessen Antwort wieder im PC
angekommen ist.

Könnte es vielleicht sein, daß die UART garnicht echt ist, sondern über
den USB simuliert wird ?

Denn nur durch die langen Latenzzeiten des USB sind solche
Verzögerungen erklärlich.

Da muß ich wohl nochmal drastisch am Bootloader feilen und z.B. in 1kB
Paketen senden.


Peter

Hi

warum sollte die RS232 über den USB gehen? In den üblichen
SuperIO-Bausteinen ist allerdings auch ein FIFO drin. Da dein
"direkter" Portzugriff wahrscheinlich von OS abgefangen wird kann es
durchaus sein das die Daten die vom µC zurückkommen erstmal eine Weile
im FIFO des SuperIO-Bausteins bleiben bis sich das OS bequemt da mal
wieder vorbeizuschauen. Schau dir doch einfach mal das Zeitverhalten
mit dem Skop an.

Allerding ist der Zugriff per outp() und inp() unter einem modernen OS
wie XP natürlich eine Krücke. Da macht man das über API-Funktionen des
OS.
http://www.siwawi.arubi.uni-kl.de/avr_projects/ind...
ist evtl. einen Blick wert.

Matthias

>...ist evtl. einen Blick wert.
und falls "draufgeblickt" und der W32-Native-Port nicht funktioniert,
bitte einen Fehlerbericht zumailen (Adresse unten auf der genannten
Seite). Danke, Martin

Ist ja gut gemeint, aber mir raucht schon der Kopf vor AVRDude, Cygwin,
Visual C++.

Ich wollte ja auch eigentlich in der Kommandozeile bleiben und nicht
immer mit "lots of bells and whistles" extra Windows-Fenseter
aufmachen.

Ich hab mal IO.DLL von Fred Bulback probiert, aber außer
"Schutzverletzung blablabla" ist da nichts weiter bei rausgekommen.


Im Prinizp geht das Senden und Empfangen ja, bloß da ist eben eine
riesenlange Latenzzeit dazwischen.
Bevor ich das Paßwortsenden ohne Delay gemacht habe, hatte XP schon
etwa 104 mal das Paßwort im Puffer, ehe die Antwort vom AVR zurück kam.
Ich mußte also noch 104 mal das 'a' zurücklesen, ehe der
Empfangspuffer wieder leer war.
XP hat da also außer den 16 Byte FIFO noch einen riesen Softwarepuffer
dazwischen. Deshalb eben auch mein Verdacht mit dem USB.


Da ich also mit IO.DLL gründlich auf die Nase gefallen bin und Cygwin
und Konsorten nur bömische Dörfer für mich sind, werde ich mal noch an
dem Protokoll feilen, d.h. größere Pakete austauschen, um wenigstens
wieder unter 10s für die 7kB zu kommen.


Peter

Hallo alle

Hat von euch schon mal einer einen Bootloader für die RS 485
Schnittstelle geschrieben? Ich bin in C bzw. in ASM praktisch nicht zu
gebrauchen und wäre für ein Stück ASM Code zum Initialisieren der
Schnittstelle (Mega 8/128), senden mit umschaltung und empfangen
richtig dankbar.
Wäre super wenn da schon mal jemand ...

Werner

RS-232 und RS-485 unterscheiden sich doch nur durch den Typ des
Leitungstreibers.

Allerdings geht RS-485 immer nur mit einem zusätzlichen Protokoll, da
es ja den Anschluß mehrerer Devices erlaubt.
Das Protokoll muß dann entweder die Adressierung verschiedener Slaves
oder den Umlauf des einzigen Sendertokens sicherstellen.

Den RS-485-Bootloader kann es also nicht geben, da es auch nicht das
RS-485-Protokoll gibt, sondern viele verschiedene.

Wenn Du also schon RS-485 benutzt, mußt Du dafür ja irgendeine
Protokollbibliothek haben. Und dann brauchst Du nur noch diese
Protokollbibliothek an irgendeinen RS-232 Bootloader ranpappen.


Peter

Wenn Du allerdings nur eine 2-Punkt Verbindung brauchst, geht RS-485
(4-Draht) auch Full-Duplex ganz ohne Protokoll wie eine RS-232.


Peter

Danke für die Prompte Antwort

Die RS 485 hat nur eine 2 Punkt-verbindung bei der Programmierung.
Verhält sich also im Prinzip wie eine RS 232 Schnittstelle. Das
Protokoll ist wie bei der RS 232. Mir geht es Hauptsächlich um die
Sende-und Empfangsumschaltung des Treibers.

Werner

eine Moeglichkeit fuer die Umschaltung ist eine ISR fuer "UART TX
complete" einzusetzen und darin den RS485 Baustein von senden auf
empfang umzuschalten. Loest zwar nicht alle Probleme, aber erspart
zumindest ein Delay.

So nun läuft er bei mir auch unter Windows98 und unter Windows-XP.

Das Protokoll mußte dafür geändert werden.
Es werden jetzt immer 512 Bytes gesendet und dann am Stück
programmiert. Nur ein Byte ändern ist natürlich weiterhin möglich.

Um das Programm einfach zu halten, wurde nicht auf Geschwindigkeit
optimiert. D.h. erst nachdem alle 512 Byte empfangen wurden, wird
programmiert.

Die Programmierzeiten haben sich etwas verlängert:

ATMega8: 2,4s
ATMega16: 3,4s

Wird der EEPROM geschrieben, dauert das etwa 5s je 512 Byte, da ja je
Byte 8,5ms Schreibzeit nötig sind.


Peter

Nur aus Interesse: Warum werden in der Programmiersoftware
(Windows-Seite) outportb() und inportb() zum Zugriff benutzt und nicht
die Windows-API-Funktionen fuer die serielle Schnittstelle? Ist das ein
Kniff, um die Geschwindigkeit zu steigern? Funktioniert das
Windows-Programm ohne speziellen Port-Treiber und auch fuer Nutzer ohne
Administrator-Rechte unter XP?
Martin

"nicht die Windows-API-Funktionen"

Dazu müßte es ja eine Windows-Exe sein.
Ich benutze Borland C++ 3.0, das soll ja theoretisch sowas können.

Ich habs auch versucht und nach vielen Stunden entnervt aufgegeben.
Dabei bin ich auch nicht ansatzweise in die Nähe einer rudimentären
Funktionalität gekommen. Dafür wurde ich mit Schutzverletzungen und
tonnenweise anderer Fenster bombardiert obwohl ich ja die Ausgaben in
der gleichen DOS-Box haben will.


Das inport() und outport() läuft bei mir sehr zuverlässig auf dem
Aldi-PC. Das Windows scheint die Ein-/Ausgaben nur sehr lange zu
puffern und dadurch funktioniert die "ein Byte hin/her" Methode nur
sehr langsam.
Mit der "512 Byte hin" Methode gehts aber, da fallen die Pufferzeiten
dann nicht mehr ins Gewicht.


Peter

P.S.:

Das inport() / outport() ging von Anfang an, ich habe dazu keinerlei
Treiber geladen, der PC ist noch in der Original-Konfiguration.

Da ich der einzige Benutzer bin, nehme ich mal an, ich bin der
Administrator.


Es grassiert ja wieder eine PC-Grippewelle, aber ich hatte rechtzeitig
das Update gemacht. Meinen Kumpel hats erwischt, ich mußte ihm erst
eine CD brennen, da der Virus ja immer beim Download runterfährt.


Peter

Hi

@Peter
Hast du WINAVR installiert? Das lädt AFAIK automatisch irgend einen
Treiber der inp() und outp() ermöglicht. Ohne diesen Treiber sollte ein
WinNT diese Aufrufe mit einer Fehlermeldung quitieren.

Matthias

Solche Gemeinheiten traue ich WINAVR nicht zu, daß es ungefragt im
System rumpfuscht.
Ich habs außerdem nicht neu installiert, sondern nur vom alten W98-PC
kopiert.


Peter

Vielleicht könnte mal ein anderer XP-Benutzer meine PBOOT.EXE
ausprobieren.


Ich hab jetzt noch eins draufgesetzt und mir ein USB-RS232 Kabel
gekauft, das meldet sich als COM4 an.

Was soll ich sagen, einfach "PBOOT.EXE -C4 -PTEST.HEX" aufgerufen und
läuft super.
Die Programmierzeit ist dann 9s für 7kB (ATMega8), geht ja noch.

Man muß allerdings das USB-Kabel reinstecken, bevor man das DOS-Fenster
öffnet un