Hier ist nun mein neuer Bootloader V1.4

Die Programmierzeiten sind z.B.:

ATtiny13: 0,8s
ATmega8: 1,8s
ATmega644: 8,2s

Hinzugekommen ist ein CRC-Check und eine Verify-Funktion.

Bei den ATtinys kann man sie deaktivieren, bringt bis zu 64Byte mehr
Flash für die Applikation.


Peter

Hallo Peter,

eine Frage: Was genau bedeutet die "BufferSize", bzw. was meinst Du mit
"Attention: BufferSize must fit perfectly into BootStart!"?
Beim ATmega8 z.B. ist BufferSize = 15*PageSize = 15*32 = 480 = 0x1E0
(warum dieser Wert?).
Beim ATmega168: BufferSize = 4*PageSize = 4*64 = 256 = 0x100
Ich Frage, da ich den Bootloader mit einem ATmega88 verwende, der eine
PageSize von 32 hat. Ergo müsste ich bei BufferSize "8*PageSize" bei
Verwendung der BOOTSTART-Adresse 0x0F00 eintragen, oder? Meine
Feststellung ist nämlich, dass jeder Multiplikator zwischen 2 und 12
funktioniert (weiter hab ich´s nicht getestet). Ich wäre Dir für eine
kurze Erklärung sehr dankbar!

ciao Michael

Windows mag es nicht, wenn man immer nur ein Byte über die UART sendet.
Man sollte also möglichst große Blöcke senden, dann geht es wesentlich
schneller.
Daher richte ich im SRAM einen Puffer ein und sage der PC-Software, wie
groß dieser Puffer ist.
Diese Puffergröße muß natürlich ein Vielfaches der Pagegröße sein.

Um den Bootloader klein zu halten, programmiert er immer komplette
Puffer. Daher muß die Puffergröße exakt, d.h. ohne Rest in den
Userbereich passen.
Oder anders gesagt: n * Puffergröße = Bootstart.


Peter

Hallo Andreas,

wie Peter schon schrieb, die Programmierpins sind frei wählbar, da die
serielle Schnittstelle als Softwarelösung implementiert ist.
Die Konfiguration der beiden Pins kannst Du in dem Deinem
Mikrocontroller entsprechenden *.asm-File abändern und dann mit z.B.
AVR-Studio das Hex-File für den Controller erzeugen.
Auf dem Weg nochmal Danke Peter für Deine Antwort. Jetzt habe ich
verstanden dass Du mit Bootstart die Bootstart-Adresse meinst.

ciao Michael

Hallo Peter,

super Teil dein Bootloader.
Hab ihn gerade auf ATMega64 und RS-485 Schnittstelle angepasst und er
läuft!
Jetzt muss ich nur noch das PC-Programm auf Dev-C++ portieren, da ich
kein Borland C++ habe.

Vielen Dank
andie.

Andreas wrote:

> Kannst Du evtl. für die Noobs (wie ich  ;-)  ) ein paar Zeilen zum
> Einstieg schreiben, welche Pins jetzt benutzt werden, wie und wo man
> diese ändert, wie das Programmieren funktioniert usw. Also eine _kurze_
> Anleitung?


Die Pins können in folgenden Zeilen geändert werden

; Sendepin:
.equ    STX_PORT        = PORTB
.equ    STX_DDR         = DDRB
.equ    STX             = PB1
;Empfangspin:
.equ    SRX_PIN         = PINB
.equ    SRX_PORT        = PORTB
.equ    SRX             = PB0

Peter

Richard wrote:
> Kann mir einer verraten wie ich den sourcecode kopilieren kann?
>
> Habe es mit AVR Studio versucht ... kriege es aber leider nicht hin :-(

Du öffnest die Datei, die Du assemblieren willst, z.B. t13.asm.
Die anderen (*.inc, *.h) müssen sich im gleichen Verzeichnis befinden.


Peter

Uwe wrote:
> Sehe ich das richtig, dass AVRs mit mehr als 64k Flash (z. B. ATm128)
> nicht unterstützt werden?

Ja, der ATMega644 ist mein größter, größere habe ich nicht.

Hab ihn aber auch nur aus Interesse gekauft, weiß noch nicht, womit ich
ihn vollkriegen kann.


Peter

Uwe wrote:
> Ist es viel Aufwand, den ATM128 noch mit einzubauen?

Im Prinzip nicht.

Die meisten Änderungen sind am PC Programm.
Ich müßte mir ansehen, wie ein Segmentrecord funktioniert (bisher
ignoriere ich ihn) und alle Pointer, Adreßzähler auf long umstellen und
ein farmemset selber schreiben.

Auf dem AVR muß ich RAMPZ mitzählen und ESPM, ELPM benutzen, sollte max
10 Worte kosten.

Ich kanns aber nicht testen.


Peter

Hallo Peter,

kann man den alten Borland C-Compiler legal irgendwo runterladen?
Oder ist der immer noch kostenpflichtig?

Schöne Grüße,
Techniker

FBOOT.EXE /PC:\AVR_PR~1\LED_mega32.hex

so vielleicht?

Diese DOS-Anwendung kann leider keine langen Pfad- und Dateinamen (max
8.3).


Peter

LED_mega32.hex

der dateiname ist immer noch 10 buchstaben lang ;)

Stimmt!

BOOT.EXE /PLED_me~1.hex

PS: Dann war obige Antwort auch nicht richtig. Da ist nur der Pfadname
korrekt, der Dateiname aber immernoch zu lang.

Richard wrote:
> Asoo, Dateiname ... ich dachte Pfad^^. Danke jetzt geht es.

Beides.

Richard wrote:

> Muss ich irgendwas an den Security bits umstellen?

Die Fuses: firstboot und boot reset

sonst kann er ja den Bootloader nicht finden.

Bei nem leeren MC rauscht er durch die 0xFFFF durch bis zum Bootloader.


Peter

Gasti wrote:

> Vielleicht habe ich aber auf das ganze noch nicht richtig durchschaut.

Stimmt

Auf das SKIP folgt kein RJMP, d.h. auch bei einem Timeout wird nicht
mehr zum Schleifenanfang gesprungen.


Peter

Hat jemand von euch schon das FBoot Programm von Peter auf Dev-C++
portiert?

Habe keine inportb() und outportb() Funktionen zur Verfügung.
Würde mich über jede Hilfe freuen.

andie.

Ich hab das ganze gerade auf VC++ umgeschrieben, da ich das ganze an
einem USB-RS232 Wandler betreibe. Im Prinzip muss man nur noch einige
casts hinzufügen und die seriellen Schnittstellenroutinen ändern.

Hat jemand eine Idee wie man den Bootloader starten könnte, wenn es
keinen Reset Knopf gibt, der AVR über USB versorgt wird, und ebenso der
FT232, der COM-Port also nicht vor dem Einschalten des AVRs geöffnet
sein kann ?

Im controller eine resetfunktion implementieren?
Also, irgend ein zeichen bzw steuercode über rs232 der dann den watchdog
einschaltet und wartet?

Benedikt K. wrote:

> Hat jemand eine Idee wie man den Bootloader starten könnte, wenn es
> keinen Reset Knopf gibt, der AVR über USB versorgt wird, und ebenso der
> FT232, der COM-Port also nicht vor dem Einschalten des AVRs geöffnet
> sein kann ?

Nimmste eben eins von den Handshakesignalen (RTS, DTR) und knallst es an
den Resetpin.

Und im PC-Programm wird es dann kurz gepulst.


Peter

Stefan wrote:

> Ist denn auch eine Halb-Duplex-Kommunikation auf einem Pin
> konfigurierbar ?
> Gerade auf den 8-Pin-Prozessoren wäre das ungemein hilfreich... dafür
> würde ich gern auch noch ein wenig Speicher opfern; denn da ist man bei
> den neuen Tinys ja recht flexibel :)

Ist gerade in Arbeit, anbei schonmal der Schaltplan.
Die Dioden sind nur zum Schutz, wer Lust hat, kanns auch ohne probieren.

6 IO-Pins zu haben und trotzdem neu brennen zu können (ohne Fuses !),
hat schon was.

Es sieht auch ganz gut aus, fehlt noch der Feinschliff.

Die Prolific-Dongle haben das viele RX-Traffic nicht ausgehalten und
Bytes verschluckt und vertauscht (!), wenn einige Bytes 0x13 waren.
Ich bin fast verrückt geworden beim Debuggen.

Bis ich dann den FTDI benutzt habe, da lief alles.

Dann habe ich den neuen Profilic-Treiber installiert und dann gings
auch.
Der Treiber muß von 2005 sein (der alte war von 2003).
Allerdings sinkt die Downloadrate auf 25%, wenn die Bytes 0x13 sind.


Für das 1-wire mußte ich auch noch das Protokoll etwas umstellen.
Ich muß mal das 2-wire überprüfen, ob das noch geht.

Die PC-Software erkennt den Modus automatisch und schmeißt dann alle
Echos weg, so daß nur die echten Antworten übrig bleiben.

Damit die Paßworterkennung funktioniert, sendet der PC noch ein 0xFF
dahinter und der AVR wartet auf das Starbit und hängt das Antwortbyte
daran an.
Falls das fehlschlägt, macht es der AVR immer wieder, daher sollte das
Paßwort eine gerade Anzahl Zeichen haben.

Daß das Zeichen 'a' im Paßwort vorkommen muß, hat vielleicht schon
jemand gemerkt.
Die Baudratenerkennung akzeptiert nur bestimmte Zeichen, um eine
Fehlerkennung (doppelte Bitzeit) zu vermeiden.


Peter

Ich habe hier ein ATMega 48 und möchte gerne den Bootloader zum laufen
kriegen, habe daher die Ports und Includes angepasst (ich hoffe mal
richtig, habe noch nie mit Assembler gearbeitet):

;*************************************************************************
;*                   *
;*        ATmega8 Bootloader       *
;*                                                                       *
;*                      Author: Peter Dannegger                          *
;*                   *
;*************************************************************************
.nolist
.include "m48def.inc"


;please burn this BootStart Fuse:

.equ  BootStart  = SecondBootStart


;Attention: BufferSize must fit perfectly into BootStart !
;e.g. BufferSize * 8 = BootStart

.equ  BufferSize  = (15*PageSize)

;-------------------------------------------------------------------------
;                               Port definitions
;-------------------------------------------------------------------------
.equ    STX_PORT        = PORTD
.equ    STX_DDR         = DDRD
.equ    STX             = PD0

.equ    SRX_PIN         = PIND
.equ    SRX_PORT        = PORTD
.equ    SRX             = PD1
;-------------------------------------------------------------------------
.include "fastload.inc"
;-------------------------------------------------------------------------

Und kriege dann beim kompilieren folgende Fehler:

AVRASM: AVR macro assembler 2.1.2 (build 99 Nov  4 2005 09:35:05)
Copyright (C) 1995-2005 ATMEL Corporation

C:\avr\bootloader\bootloader.asm(9): Including file 'C:\Programme\Atmel\AVR Tools\AvrAssembler2\Appnotes\m48def.inc'
C:\avr\bootloader\bootloader.asm(14): warning: Use of undefined or forward referenced symbol 'SecondBootStart' in .equ/.set
C:\avr\bootloader\bootloader.asm(33): Including file 'C:\avr\bootloader\fastload.inc'
C:\avr\bootloader\fastload.inc(9): Including file 'C:\avr\bootloader\compat.h'
C:\avr\bootloader\fastload.inc(10): Including file 'C:\avr\bootloader\fastload.h'
C:\avr\bootloader\fastload.inc(21): error: Overlap in .cseg: addr=0x0 conflicts with 0x0:0x1
C:\avr\bootloader\bootloader.asm(33): info: 'C:\avr\bootloader\fastload.inc' included from here
C:\avr\bootloader\fastload.inc(38): Including file 'C:\avr\bootloader\abaud.inc'
C:\avr\bootloader\fastload.inc(39): Including file 'C:\avr\bootloader\password.inc'
C:\avr\bootloader\fastload.inc(83): Including file 'C:\avr\bootloader\checkcrc.inc'
C:\avr\bootloader\fastload.inc(90): Including file 'C:\avr\bootloader\verify.inc'
C:\avr\bootloader\fastload.inc(101): Including file 'C:\avr\bootloader\message.inc'
C:\avr\bootloader\fastload.inc(104): Including file 'C:\avr\bootloader\progmega.inc'
C:\avr\bootloader\fastload.inc(110): Including file 'C:\avr\bootloader\uartcrc.inc'
C:\avr\bootloader\bootloader.asm(35): warning: end of .dseg at 0x4c0 is beyond end of memory at 0x2ff

Assembly failed, 1 errors, 2 warnings

Und wenn ich sowieso schon schreibe, hat jemand den Bootloader für Linux
auf den aktuellen Stand gebracht? (war ja im vorhergehenden Thread mal
dabei).

Danke.

mfg Andreas

Der ATmega48 gehört bezüglich Bootfunktion zu den ATtinys.

Daher gibts kein Secondbootstart.

Nimm daher das T45.ASM als Vorlage.


Peter

Ok, Danke!
Der Bootloader ist drauf, nur wartet der unendlich lange?
Ich konnte mein Programm aufspielen, aber es wurde nicht gestartet.
Selbst wenn ich über eine Minute warte kann ich immer noch das Flash
bespielen. Wie muss ich mein Programm starten, bzw. wenn wird es
gestartet? (da ich den vorherigen Thread auch gelesen habe gehe ich mal
davon aus das dein Bootloader auf 0x00 eine rjmp zur Adresse in der der
Bootloader ist geschrieben hat, und dann von dort auf zurück auf 0x01
springt wo das Programm beginnt, oder so ähnlich?)


Wie schon genannt, ATMega 8, und ich kann immer noch kein Assembler;-)

mfg Andreas

Die Applikation startet, sobald das PC-Programm fertig ist bzw. etwa
0,3s nach einem Reset.

Bei den AVRs ohne Bootstartfuses muß der erste Befehl ein RJMP sein,
sonst geht es nicht.

Und die Applikation muß lauffähig sein, d.h. eine Mainloop haben.


Peter

Die Applikation hat eine Hauptschleife, es ist in C geschrieben, wie
muss ich das realisieren?
Es ist so das mein Programm definitiv nicht startet, weder nach einem
Reset noch nach dem Flashen.


mfg Andreas

Andreas B. wrote:

> Es ist so das mein Programm definitiv nicht startet, weder nach einem
> Reset noch nach dem Flashen.

Verify und CRC sind o.k. ?


Wenn Du überzeugt bist, daß Dein Programm funktioniert, dann lade es mal
direkt, ohne Bootloader.


Peter

Ohne Bootloader läuft es, und CRC habe ich nicht drauf, zumindest wird
ausgegeben das CRC nicht implementiert ist.
Auch wenn ich .crc = 17 auskommentiere erscheint dies.
Ich benutze den Internen Oszi, habe Datenübertragung mit 9600 Baud
klappt bei meinem Programm, ich habe beim Flashen auch 9600 Baud
angegeben (wobei das wahrscheinlich eh nichts bringt da du sowieso das
ganze per Software machst).

Ist es möglich das ich den Bootloader falsch geflasht habe, also das der
auf 0x00 steht und mein Programm hintendran oder so?
Ich habe einfach das .hex File mit AVR Studio aufgespielt.


mfg Andreas

Ich muss natürlich nicht CRC auskommentiern sonder VERIFY
einkommentieren.
Und dann erscheint auch "fail" warum weiss ich noch nicht...
Aber demfall wurde mein Programm nicht augespielt, oder zumindest nicht
richtig aufgespielt...

Danke für die Antworten und ich hoffe mal ich kriege das noch selbst
raus, oder du hast nochmals einen Vorschlag...

mfg Andreas

Schau mal bei den Fuses nach, der ATmega48 hat noch ne
Self-Programming-Enable Fuse, die muß man setzen.


Peter

Danke!
Das wars!


mfg Andreas

So, hier mein Linuxport des Bootloader Programmers. (Basiert auf dem
Original und dem Port von Sascha Biedermann vom vorherigen Thread)

Leider nicht ganz so schnell wie das original, und mit ein paar
unschönen Hacks drin...:

/dev/ttyS0 at 115200 Baud: /
Connected
Bootloader V1.4
Target: 1E9205 ATmega48
Buffer: 64 Byte
Size available: 3582 Byte
reading file... Done.
Program project.hex: 0000 - 0D25 successful
CRC: o.k.
Elapsed time: 28 seconds
andreas@andreas:~/avr/bootloader_linux$ ./main /Vproject.hex
/dev/ttyS0 at 115200 Baud: \
Connected
Bootloader V1.4
Target: 1E9205 ATmega48
Buffer: 64 Byte
Size available: 3582 Byte
reading file... Done.
Verify project.hex: 0000 - 0D25 successful
CRC: o.k.
Elapsed time: 41 seconds

Trotzdem möglicherweise nützlich für Linuxuser ;-)

mfg Andreas

Hier eine neue Linuxversion, nun klappt das Programmieren innert
Sekunden (bei meinem ATMega48 sinds sogar nur 0.44 Sekunden) und einige
Bugs behoben.

Und noch eine Frage, kann der Bootloader aus C gestartet werden?
Ich habes versucht mit

cli();
asm volatile ("rjmp 0");

das klappt aber nicht, da hängt sich alles auf.

ps. ich habe versucht einen Pin mit dem Resetpin zu verkabeln, da hängt
sich aber alles auf wenn ich den auf LOW setzte, irgendwie funktioniert
das nicht... bzw. ich mache was falsch.

mfg Andreas

Werner B. wrote:
> Du musst natürlich an den Anfang des Bootloader springen, nicht nach
> Null.

Das stimmt, aber ich weiss nicht wo der Bootloader beginnt, und ich habe
gelesen das der an erster Addresse ein Jump zum Bootloader drin ist.

Ich versuchs mal noch mit dem Watchdog.


mfg Andreas

Ich bin mir nicht sicher ob ich ein Problem mit dem Bootloader oder
sonst etwas habe, hier mal die Beschreibung:
Ich mache einen Reset per Watchdog:

void reset(void)
{
  uint8_t i;
  
  uart_puts("reset\r\n");
  
  for(i = 30; i > 0; i--) {
    uart_puti(i);
    uart_puts("\r\n");
    _sleep();
  }
  
  
  //Interrups deaktivieren
  cli();

  //Watchdog einschalten
  WDTCSR = (1 << WDE);  
  for(i = 0;1; i++) {
    uart_puti(i);
    uart_puts("\r\nw");
  }
  
}

Aufem Treminal kriege ich:

...
2
1
0
w1
w2
w3

Daher kann ich davon ausgehen das er einen Reset macht. Aber danach wird
mein Programm nicht mehr gestartet. Wenn ich versuche ein Programm
aufzuspielen erscheint gerade noch (ich beende natürlich das Terminal,
sonst würde es ja meine serielle Schnittstelle blockieren)

/dev/ttyS0 at 115200 Baud: -
Connected

da das Laden des Bootloaders sonst klappt gehe ich davon aus das
irgendetwas nicht richtig initialisiert wird beim Reset mit Watchdog,
oder was könnte es sonst sein? Hat noch keiner den Bootloader per C
gestartet?


mfg Andreas

Die Warnungen kannst du ignorieren, diese sind unwichtig, jedoch das
Problem mit der Grösse hatte ich auch, ich habe darum etwas einfach so
"gebastelt" das es bei mir funktioniert, warum das es bei dir nicht
funktioniert kann ich so nicht sagen, was hast du für ein Controller?
(Vor allem wie viel Speicher hast du)

Ich habe hier mal eine "Debugversion" angehängt, diese schreibt die
entscheidenden Zahlen auf die Konsole, einfach die Ausgabe kopieren, ich
hoffe ich kann damit zumindest feststellen was schief läuft.

Ich habs bis jetzt nur mit einem Mega48 probiert, und einfach alles so
angepasst das es damit funktioniert, was mir nicht klar war warum das
ich einmal falsche Zahlen empfangen habe (mir wird die Länge der Zahl
übertragen, in Byte, die war jedoch bei zwei Werten immer um eins zu
hoch).

mfg Andreas

Versuch mal diese Version. Bei ich musste ein paar Änderungen machen,
damit der Bootloader Programmer bei mir lief, ich denke aber für den
ATMega 8 scheinen diese nicht nötig zu sein (der ATMega 48 war ja auch
nicht in der Liste, darum hats wahrscheinlich auch nicht funktioniert.)

Ich warte auf dein Ergebnis und werde hoffentlich dann eine Finale
Version machen können die mit allen Controllern funktioniert...

mfg Andreas

Irgendwo ist beim portieren ein Fehler passiert, denn das ist 1:1 die
Funktion die auch in der Windowsversion eingesetzt wird. Ich werde das
ganze morgen nochmals vergleichen, und vielleicht komme ich auf einen
Fehler.

Ich kann dir auf jeden Fall mal sagen wo das es schief läuft (in der
Hoffnung ein mitdenkender Forumuser könnte mir die Lösung sagen;-)):
ATMega 48: er sagt er sendet mir 2Bytes, sendet aber nur eines (Buffer:
64Byte, 64 passt in ein Byte), dann beim Speicher sagt er er Sendet
3Bytes, sendet aber zwei, usw.
Dein Controller sagt auch er Sendet zwei Byte beim Buffer, sendet aber
zwei...
Ich weiss (noch) nicht wo der Fehler liegt.


mfg Andreas

Es wäre sinnvoll dafür einen Artikel im Wiki zu erstellen:
Anleitung: Artikel erstellen

Hi,

hab jetzt nach über einem Tag intensivem probieren meine ganzen Fehler
rausgekriegt und der Bootloader läuft ;-)

Da der ein oder andere Anfänger sicher ähnliche Probleme hat, hab ich
mal ne kleine Anleitung geschrieben.

Seh auch grad die Frage nach dem Wiki. Wenn Ihr nichts dagegen habt
schreib ich die Anleitung auch noch ins Wiki.

Am Support durch die ATMega IDE schreib ich gerade. Sollte also heute
oder morgen dann downloadbar sein.

Die Geschwindigkeit ist echt der Hammer. Ich hab für ein Programm im
168er mit dem ISP immer so 1,5 Minuten gebraucht. (inkl. Verify) Jetzt
brennt er das in nur 3 Sekunden rein (ohne Verify).

Echt toll ;-)

Ciao
Karsten

So Wiki ist drin.

http://www.mikrocontroller.net/articles/AVR_Bootlo...

Ciao
Karsten

Hallo,
ich würde das PC-Programm gerne in VB schreiben. Allerdings ist Java und
C nicht gerade meine Stärke ;-)

Gibt es irgendwo eine ausführliche Dokumentation zum Protokoll zwischen
MC und PC ?

Viele Grüße
David Herrmann

So, ich hab mich in Unkosten gestürzt und nen ATmega2561 gekauft.

Über 64kB brennen geht jetzt.

Allerdings ist noch irgendwo der Wurm drin, dauert sehr lange.

Daher hier erstmal ne Vorabversion.

Das Protokoll ist geändert, betrifft aber nur den Verbindungsaufbau
(extra Zeichen nach Paßworterkennung), wurde für den Eindrahtmodus
nötig.


David Herrmann wrote:
> Gibt es irgendwo eine ausführliche Dokumentation zum Protokoll zwischen
> MC und PC ?

Bisher noch nicht. Mal sehen, wann ich dazu komme.


Peter

Der Bootloader ist pure Assembler.

Nur das PC-Programm ist in C geschrieben, muß man aber nicht neu
übersetzen, die EXE ist ja schon dabei.

Ist nur für die, die es modifizieren (GUI) oder an Linux usw. anpassen
wollen.
Manche mögen ja keine automatischen Programme, sie wollen lieber
jedesmal umständlich umherklicken müssen.


Peter

Tom wrote:

> Ich habe dann das Flash wieder per ISP ausgelesen, dabei stellte sich
> heraus das die erste 48 Bytes komplett verschieden sind.

Hab ich jetzt auch keine Erklärung dafür.

Versuch mal ganz oben Version 1.4, die sollte eigentlich laufen.

Die Version 1.6. hab ich nur ganz kurz getestet und noch nicht weiter
verwendet.


Peter

In der Anleitung steht das man die Fuses auf 256 words setzen soll, in
meinem Fall bin ich aber auf 512 gekommen.

Am besten machst du mal ein Chip Erase, brennst den bootloader und liest
dann mal den Flash aus, wenn ich mich recht entsinne (bin gerade nicht
am richtigen Rechner) fängt der Bootloader mit der Standard Config bei
:101E0000 (Intel Hex) an.

@Johannes
der Bootloader sitzt am oberen Ende im Flash. Der brennt praktisch
erstmal ein leeres Programm und oben den Bootloader. Der Bootloader legt
danach das eigentliche Programm wieder an der richtigen Stelle (weiter
unten) ab.

Frequenz sollte nicht stören. Ich hab den M8 mit der 3,68er und den M168
mit 8,000MHz benutzt. Die Wartezeit hat bei mir bisher keine Probleme
gemacht.

Ich benutze auch die Hardware-Pins da ich da eh schon ne RS232 dran hab.

Größe ermitteln: avr-size -A m8.hex


@Kriewitz
256 Worte = 512 Bytes. und der Bootloader hat weniger als 512 Bytes
(zumindest V1.4, 1.6 hab ich noch nciht getestet weil ich im Urlaub
war).

Hab jetzt mal die Version 1.6 genauer getestet, die ist Schrott.
Mein Borland-C 3.0 weigert sich standhaft, Felder über 64kB zuzugreifen.

Also erstmal Version 1.4 verwenden.

Wenn da oft Bytes 0x13 vorkommen, geht die Geschwindigkeit über USB
drastisch in die Knie.
Wird in Version 1.7 abgestellt (muß aber erstmal nen funktionierenden
Compiler besorgen).

Wenn gar nichts geht, kann das an speziellen LPT-Treibern für direkte
IO-Zugriffe (ISP) liegen, die können sich mit der COM im DOS-Fenster
beißen. Also diesen mal deaktivieren.


> Program test.hex: 0000 - 1300 failed !

könnte das nicht aktivierte SELFPRGEN-Fusebit sein.


Peter

P.S.:
Ein kompletter ATmega2561 dauert ~33s.

Mit dem C-Builder von Borland (jetzt CodeGear) gehen auch
Konsolenanwendungen. Die haben auf der Homepage auch eine Testversion
zum Download.

An sonsten könnte ich was mit Delphi schreiben. Da kommt das je eh in
die ATMega IDE rein.

Karsten

Anbei die neueste Version.

Wie es scheint, muß ich bei meinem uralt BC3.0 die
Segment/Offset-Rechnung zu Fuß machen. Jedenfalls geht es jetzt.

Können sich die Windowsprogrammierer mal einen ablachen, was früher so
für Verrenkungen notwendig waren.


Peter

Bin aber eher froh das ich mich mit sowas nicht mehr rumplagen muss.
Wenn ich da so an Overlay Dateien usw. denk. Oder die selbstgeschriebne
XMS Unit ;-)

Karsten

Sorry, natürlich 256 words, nicht 512!

@Tom
Im Anhang ist eine funktionierende M8535.ASM, der mega8535 hat im
Gegensatz zum mega8 nur 512kByte SRAM, BufferSize muss also auch
angepasst werden.

@Peter
Du kannst die Datei gerne mit reinnehmen.
Hier nochmal die device id vom mega8535

case 0x1e9308: s = "ATmega8535"; break;

Kompletter flash (7680 Byte) hat bei mir 2,3 Sekunden gedauert :)

Getestet mit 115200 BAUD @ 14318180 Hz und FBOOT V1.7

Bin noch dabei.

Karsten

Anbei das PC-Programm mit einigen Typen hinzugefügt. Die Typenliste
sollte man wohl besser auslagern.
Werde mal noch 8051-er hinzufügen, das Flip ist mir zu langsam und zu
umständlich.

Den ATtiny44 hab ich noch getestet.

Der Eindrahtmodus funktioniert bei mir auch sehr gut bei 115200 Baud,
geht also auch ohne MAX232.
Das Abzählen der Echobytes funktioniert zuverlässig.
Die Programmierzeiten sind gleich.


Peter

Tom wrote:

> Mich würde noch interessieren was es mit der password.inc auf sich hat,
> kann man damit den Bootloader Zugriff beschränken? Falls ja, wie?

Das ist nur die Auswerteroutine für das Paßwort.

Du kannst auch ein anderes und auch längeres Paßwort als "PeDa"
definieren, es muß bloß ein für die Baudratenerkennung geeignetes
Zeichen enthalten, z.B. 'a'.

Und dann natürlich mit:

fboot17 -ineues_Passwort ...

dem PC-Programm übergeben (sehe gerade, das fehlt im Hilftext).

Ohne das Paßwort kommt keiner in den Bootloader.
Man kann also ruhig Geräte an die UART anschließen, die schon beim
Einschalten sehr gesprächig sind.


> Und wie verhält sich der booloader wenn man etwas in den booloader
> Bereich flashen will (wenn man keine LockFuses programmiert hat)?

Die Programmierroutine macht immer einen Adreßcheck und verweigert die
Selbstzerstörung.

Aber auch schon das PC-Programm bricht ab, wenn die höchste Adresse über
dem Applikationsbereich liegt.


> Bin mir gerade nicht sicher, aber kann man eigentlich auch per Booloader
> Fuses ändern, fände eine Möglichkeit die RSTDISBL Fuse zu ändern noch
> sehr praktisch.

Die Fuses kann der AVR nicht selber ändern.


Peter

Nun, das Paßwort enthält ja verschiedene Bytes, die Low-Impulse von 1..9
Bitzeiten enthalten können.

Damit nun die Baudratenerkennung nicht austillt, prüft sie das
Verhältnis zweier aufeinanderfolgender Low-Pulse, ob es 1:4 beträgt. Das
ist z.B. beim 'a' der Fall.


Man könnte sie in die Irre führen, indem man die Bytefolge 0x20,0x80
sendet, dann hat man 2 Bitzeiten gefolgt von 8 Bitzeiten, was auch 1:4
ist. Dann steht die Baudratenerkennung aber auf der halbe Baudrate.
Daher dürfen derartige Bytefolgen nicht im Paßwort vorkommen.


Peter

Zuerst einmal Respekt! :)

Habe jedoch mit dem FBOOT17 hin und wieder ein Problem. Manchmal
reagiert die DOS-Box, in der ich das Programm starte nicht mehr (Keine
Rückmeldung). Aber wie gesagt nicht immer. (so ca. bei jedem 10. Mal)
Als System hab ich ein aktuelles WinXP Home. Hast du eine Idee, woran
das liegen könnte?

Deshalb die Frage: Ist ein Windows-Tool geplant bzw. in Arbeit? :)

Falls nein: Könntest du bitte Details zum Protokoll veröffentlichen,
dann werd ich vorr. übernächste Woche (kommende Woche bin ich im Urlaub
- juhu) mal mit VB ein Windows-Tool zusammenstricken..

Falls ja: Wann (ca.) und wo kann es downloaden? Ist dann hoffentlich
Freeware?

Gruß,
Techniker

Der Techniker wrote:

> Habe jedoch mit dem FBOOT17 hin und wieder ein Problem. Manchmal
> reagiert die DOS-Box, in der ich das Programm starte nicht mehr (Keine
> Rückmeldung).

Hast Du USB/RS232 oder ne echte RS232 ?
Hast Du nen LPT-Treiber installiert, z.B für SPI ?

Bei USB mal den neuesten Treiber installieren.
Bei LPT mal den Treiber deaktivieren.
Drauf achten, daß keine andere Anwendung die gleiche COM belegt.

Das Protokoll werd ich demnächst aufschreiben.


Peter


P.S.:
Ich hab ja kürzlich mal den ATtiny13 programmiert, da hab ich mich über
den Bootloader geärgert :-)
Und zwar, warum ich ihn nicht früher entwickelt habe.
Es macht jetzt richtig Spaß. Besonders der 1-Drahtmodus bei den
8-Pinnern ist goil. Und man kann endlich alle 6 IOs benutzen ohne nur
einen einzigen Schuß zu haben.

Ich arbeite an meinem alten Desktop -> also echte RS232..

..hmm..

Sollte eigendlich nichts laufen, was die RS232 stören könnte..
Alle anderen Anwendungen, die RS232 benuten laufen ja problemlos..
(..davon läuft aber keins im Hintergrund..)

PS: Auch ein wechsel der Schnittstelle auf COM2 bringt keine wesentliche
Verbesserung.. :-/

Hallo Leute,
ich habe in den letzten Tagen versucht, den Bootloader (V1.7) bei mir
ans Laufen zu bekommen. Leider nur mit wenig Erfolg :-(.

Zunächst mal meine Konfiguration: ATMEGA644, TXD auf PD1, RXD auf PD0
(Standard-UART vom 644)

Ich bin dann nach der Wiki-Anleitung vorgegangen:
- fastload.h angepasst :".equ XTAL = 20000000 ; 20MHz, not critical"
- in m644.asm die Ports auf Port D angepasst
- übersetzt mit "avrasm2 -fI m644.asm"
- gebrannt mit "avrdude -p m644 -c stk200 -P lpt1 -U
flash:w:"m644.hex":i -U flash:v:"m644.hex":i -y"
- Fuses gesetzt: BOOTRST programmiert, BOOTSZ0 und BOOTSZ1 nicht
programmiert. Das heißt allerdings beim 644 "Boot size=512 Words"
(kleinster möglicher Wert). In der Wiki steht etwas von 256 Worte. Ist
das ein mögliches Problem???
- Wenn ich jetzt fboot17 aufrufe, kommt folgende Ausgabe:

D:\Daten\AVR\BOOTLO~1>fboot17 /C1 /Pflash.hex
COM 1 at 115200 Baud: Connected
Bootloader VFFFFFFFF.FF
Error, wrong device informations

D:\Daten\AVR\BOOTLO~1>

Wenn ich beim fboot ein anderes Passwort setze, z.B. "fboot17 /ifoo"
kommt es nicht zum Connect. Ich nehme daher mal an, dass zumindest die
Passwortabfrage funktioniert!?!

Die Version 1.4 hab ich auch schon mal kurz probiert, hier kommt es noch
nicht mal zum Connect.

Vielleicht fällt einem von Euch noch etwas dazu ein oder hat Tipps dazu.

Gruß

Dirk

Versuchs mal mit einer niedrigeren BAUD rate (/B9600)

@freddy436

Danke für den Tip. Hab´s gleich probiert. Funktioniert aber leider auch
nicht :-(.

Bingo wrote:
> Im Dev-Cpp bist 1000 clock() ticks pro sekunde , vie viel ist im Borland
> ??

Das ist der DOS-Timertakt:

#define CLOCKS_PER_SEC 18.2
#define CLK_TCK        18.2

Peter

Hat denn jemand von Euch wirklich so viele RS232-USB Adapter
gleichzeitig in Betrieb, daß er so hohe COMs braucht ?

Ich habe am Notebook nur 2 USB-Anschlüsse und die habe ich als COM1 und
COM2 konfiguriert.

Und am Desktop habe ich ne interne COM1 und die 2 USB an der Frontseite
sind dann COM2 und COM3.


Peter

Joerg wrote:

> Ein paar Dinge sind mir aber noch unklar.
> Der ATtiny85 hat ja keinen Bootblock... wie wir er nun aufgerufen.
> normalerweise wird der bootloader ja zuerst gestarte... und wenn die die
> definierte Bootloader-Bedinging (was auch immer) erfüllt ist, dann
> bleibt er im Bootloader und wenn nicht, dann wird das Hauptprogramm
> gestartet. Wie funktioniert das jetzt hier? Denn der Chip startet ja
> immer auf 0x0000. Aber hier liegt ja mein Hauptprogram. Oder muss ich
> die Bedingung in meinem Hauptprogramm einbauen und dann nach 0x1E00
> springen um den  Bootloader zu aktivieren?

Der Bootloader leitet den ersten Sprungbefehl (RJMP) Deiner Applikation
um.
Du brauchst also auf den Bootloader keinerlei Rücksicht zu nehmen.


> Habe einen 12MHz Quarz. und BootDelay auf XTAL / 10 gesetzt... was
> bedeutet das jetzt?

Das ist die Zeit, in der der Bootloader die Baudrate und das Paßwort
erkennt.

1/10s = 100ms, könnte etwas knapp werden.
Ich nehme lieber 1/3 = 333ms.


Peter

Der Bootloader "patcht" quasi bei Upload einer neuen Anwendung den RESET
Vektor so das er immer aufgerufen wird.

Gruß Hagen

Joerg wrote:
> hmmm... habe jetzt ewig gesucht und nicht verstanden, warum auf 0x0000
> kein Code steht...

Ein leerer Flash enthält ja 0xFFFF.
Es ist zwar nicht offiziell, aber dieser Befehl wirkt wie ein NOP, der
Code läuft also das erste mal durch bis zum Bootloader.
Kannst natürlich auch nen Sprung eintragen.


Peter

..und ich warte immer noch auf die Protokoll-Doku..  ;)

Dein letzter Bootloader war schon super, aber dieser ist noch besser.
Ich hatte damals überlegt ob es möglich wäre den alten Bootloader auch
in 512 Byte zu quetschen, hatte aber keinen Weg gefunden, der neue hat
mehr Funktionen und erfüllt den 512 Byte Wunsch :-)
EEProm schreiben war aber bei den 470 Byte nicht mehr möglich, oder?

.equ  ONEWIRE      = 3

Peter

Stefan wrote:
> Ähm, den Bootloader finde ich klasse und um so bedauerlicher ist es,
> dass die Kokumentation des Protokolls immer noch "fehlt". Das "fehlt"
> deshalb in Anführungszeichen, da wir ja nicht wirklich einen Anspruch
> darauf haben. Aber einige -mich eingeschlossen- möchten gern die
> PC-Seite in andere Sprachen umsetzen oder gleich ganz in eine
> Applikation einbinden. Wäre doch schade, wenn so eine feine Applikation
> über die ersten, wenn auch sehr erfolgreichen, Schritte nicht hinaus
> kommt...
> Haben wir da noch Chancen ?


O.k., hier isses.


Peter

Und schon den ersten Fehler gefunden:

...
5.
Abfrage Useflashgrö0e:

Senden: COMMAND, USERFLASH
Antwort: ANSWER, 0x04, Flash_high, Flash_mid, Flash_low, SUCCESS
...

Peter

CRC vergessen.


Peter

Danke für das Protokoll ;-)

Ich war leider mehrere Wochen ohne Internet (warum gibts sowas
eigentlich nich im Krankenhaus?).

Aber jetzt code ich wieder weiter an der IDE und auch nem Tool für den
Bootloader mit klicki bunti g

Ciao

Karsten

Kurt wrote:
> Ich kann die Defines in der Source nicht finden - gibt es eine neuere
> Version von Loader als tinyload3.zip

http://www.mikrocontroller.net/attachment/25943/fboot17.zip


Peter

Falls es jemanden interessiert:

Ich hab den Bootloader in nen ATtiny45 gebrannt und danach Reset
disabled.

Dann hab ich per Bootloader ein Programm reingeschrieben, welches PB5
toggled und es läuft.


Peter

Kurt wrote:

> Wenn ich Fboot17.exe mit /Pxy.hex starte (das Programm xy.hex lief mit
> ISP Programmierung), kann ich mit dem Skope an PD0 (RX) wildes Zappeln
> zwischen -0,9 und +6V sehen.

Ohne MAX232 habe ich nur den 1-Drahtmodus vorgesehen (geht ja auch nicht
anders).
Im 2-Drahtmodus mußt Du noch die Bitmacros invertieren, wenn Du keinen
MAX232 benutzt.


Peter

Hallo Peter,

Da ich leider der Assembler-Sprache nicht so mächtig bin (g) wollte
ich dich fragen, ob es ein großer Aufwand für dich wäre wenn du mir
einen kurzen Tipp gibst, was ich für 3 zusäzlich abfragbare Variablen am
Bootloader ändern muss.. (Im Prinzip so, wie die Versionsabfrage des
Bootloaders..)

Ich möchte gerne zwei 16Bit-Zahlen (für Software-, und Hardwarestand)
hinzufügen. Zusätzlich bräuchte ich noch eine 16Byte breite Variable für
die "Softwarebeschreibung". (Damit man nicht beim Gerät x die Firmware
für Gerät y aufspielen kann; zur Not reicht hier auch eine 16Bit-Zahl -
falls es einfacher zu realisieren ist..)

Das ändern der PC-seitigen Software ist kein Thema..

Problematisch ist für mich nur der Assembler-Code. :(

Danke schonmal im Vorraus! :)

Gruß,
Techniker


PS: Der Bootloader ist echt absolute spitze! ;-)

Der Techniker wrote:

> Da ich leider der Assembler-Sprache nicht so mächtig bin (g) wollte
> ich dich fragen, ob es ein großer Aufwand für dich wäre wenn du mir
> einen kurzen Tipp gibst, was ich für 3 zusäzlich abfragbare Variablen am
> Bootloader ändern muss.. (Im Prinzip so, wie die Versionsabfrage des
> Bootloaders..)

Anbei die Routine.
Abgefragt werden die 3 Parameter mit den Codes 253,254,255.
Die Definitionen sind zwischen den =============-Zeilen.


Peter

Hallo Peter!

Zuersteinmal vielen dank! :)

Leider ist mir gerade vorhin aufgefallen, dass es ja ein taktischer
Blödsinn ist, wenn der Softwarestand im Bootloader hinterlegt ist..
dummguck

Naja.. Hardwarestand und Software-ID werd ich aber auf jedenfall dort
hinterlegen..


Zum Assembler-Code:

Mittlerweile hab ich auch schon ein bischen rumexperimentiert.. ;-)
(..habs aber noch nicht getestet..)

Du schreibst:

;=====================================================================
.equ  user_no_253  = 0x1234
.equ  user_no_254  = 0x5678
.equ  user_no_255  = 0x9ABC
;=====================================================================
  subi  a0, -3      ; add 3 messages (253,254,255)
  cpi  a0, 7
  brcs  sendmessage    ; 0 ... 6
  subi  a0, 3
;=====================================================================

Könnte ich auch das so formulieren: (?)
In FASTLOAD.H hinzufügen:

.equ  hwVER    = 0xabcd
.equ  swID    = 0x1234

FASTLOAD.INC siehe Anhang

Gruß,
Techniker

Der Techniker wrote:

> Mittlerweile hab ich auch schon ein bischen rumexperimentiert.. ;-)
> (..habs aber noch nicht getestet..)

Dadurch verschieben sich aber auch alle bisher definierten Funktionen.


Peter

@Peter:

Ja - das habe ich aber auch berücksichtigt.
Mittlerweile läuft er wunderbar.. ;) - Danke!

Die Idee mit der DTR-Leitung von "J.L." gefällt mir, jedoch habe ich das
selbe "Problem".. :-/

Gibt es dafür eine Lösung?


@Dirk:
Wer oder was ist eine "Enumaration"?
Kann man das essen?  :o)


Gruß,
Techniker

@Dirk:

Jetzt hab ich verstanden, was du meinst! ;)

Auf gut deutsch: Mir funkt XP dazwischen.. :(

Hab das ganze auf einem Win98-Rechner ausprobiert -> funktioniert
einwandfrei! :)

Auf einer XP-Kiste kommen immer noch ein paar Impulse zusätzlich.. :(

Gibts da einen Workaraound?

Gibts sowas wie MS Visual C++ als kostenlose Open-Source, damit man das
DOS-Proggi XP-tauglich bekommt? Kennt da zufällig jemand etwas in der
Richtung?

Gruß,
Techniker

Hallo zusammen,

ich würde gerne den Bootloader von Peter für mein Gerät mit RS485
Schnittstelle verwenden. Ich schalte nun in der putchar-Routine zu
Beginn den RS485-Treiber auf Senden und vor dem Verlassen der Routine
wieder auf Empfangen.
Diese Änderung funktioniert nun nur leider nicht sehr zuverlässig. Ich
bekomme sehr oft einen CRC-Error. Ich habe es schon mit diversen Pausen
vor und nach der Umschaltung versucht, doch ich bekomme das Timing nicht
100% in den Griff.
Hat vielleicht von euch schon einer in dieser Richtung Erfahrungen
gemacht?
Wäre über jeden Tipp dankbar.

Schöne Grüße
andie.

@Jogi:

Würde mich auch mal interessieren.. ;)

Den einzigen Vorteil von einem Bootloader (den ich sehe) ist, dass der
Kunde ohne große Kenntnisse eine neue Firmware selber aufspielen kann..

Ich mache das schon seit einiger Zeit so, dass ich mir ein spezielles
Footprint angelegt habe welches 3 Bohrungen und die ISP-Pins als kl.
Kontaktflächen besitzt. Dann habe ich mir einen Handadapter aus Pertinax
gebaut, der die 3 Bohrungen als Fixierung verwendet und die Kontakte
mittels feinen Prüfnadeln herstellt.

Das programmieren geht so recht einfach und fix - ohne große
Plazverschwendung und Bauteilkosten. Sollte dann die Baugruppe in Serie
gehen , werden die Kontakte dann mittels einer Prüflingsaufnahme
kontaktiert..

Mit einem Bootloader wird das programmieren nur noch ein einziges mal
gemacht und der Rest läuft über die RS232 oder einer
"Programmierbuchse"..

:)

Gruß,
Techniker

Patrick wrote:

> Ich habs auch schon mit einer geringeren Baudrate (wie oben empfohlen)
> probiert, leider ohne Erfolg.

In Deinen Screenshots sinds aber immer nur 115200Baud, versuche mal
/b19200.

Die Versionen 1.4 und 1.7 sind zueinander inkompatibel, kann also nicht
gehen.

Die Version 1.7 ist besser, benutze diese (Assemblerprogramm und
fboot17.exe).


Peter

Jogi wrote:
> Wie bekommst Du den Bootloader das erste mal in den AVR?
> Nicht beim Labormuster sondern bei der Produktion?
>
> Bei DIL/DIP kein Thema, aber was ist bei den SMD-Typen?

Ich habe keine Platzprobleme, benutze bisher nur DIP (gesockelt).

Und die Serienproduktion lassen wir extern machen.


Peter

@Patrick,

muß irgendwie an Deinem PC liegen, das Connect wird noch empfangen und
ab da nichts mehr.
Hast Du irgendwelche Treiber für COM/LPT installiert?
Erzähl mal was über Deinen PC (CPU, RAM, MHz, OS, COM, CPU-Auslastung
usw.).

Ich könnte mal ne Version mit nem längeren Timeout machen.


Peter

Tino wrote:
> Ich hatte das Problem auch mal, ich glaube ich musste den Watchdog per
> fuse abschalten damit es richtig klappte. Müsste aber nochmal nachsehen
> ob es das war.

Mein Bootloader unterstützt keinen Watchdog. Der Watchdog muß
abgeschaltet sein!

Man sollte den Watchdog nicht überschätzen.
Er ist ein völlig ungeeignetes Mittel, um seine eigenen
Programmierfehler zu verschleiern.


Wer den Watchdog benutzt, sollte ihn ja leicht in den Bootloader
einfügen können.


Peter

Hi Peter. Wonderfull product!
I'd tested it on Tiny45 with great success.
Now I designed DS2450 ADC emulator based on Tiny45 and 1wire bootloading
is especially interesting for me. But in your 1wire variant you excluded
TTL-RS232 level converter, so the data is inverted for 1wire case. It is
not quite suitable. What I need to correct in the bootloader code to
make it work with, say max232?

Thanks in advance,
Vladimir.

Tobi wrote:

> Wie kann es sein, das der neue Bootloader erst nach einem Reset
> funktioniert, wo doch der alte Bootloader nach einem Reset und einem
> Power on funktioniert?

Jedes Reset startet den Bootloader für ~0,3s

Ist der Resetpin aber als IO definiert, geht nur noch das Poweronreset.


Peter

@Benedikt

setz mal die Baudrate runter:
fboot17 -b9600


Schwingt Dein Quarz?

setz mal die Fuses auf internen Takt 8MHz


Peter

@Walter

Wie startest Du das Programm, DOS-Box oder im Explorer?

Bei der DOS-box mal mit den erweiterten Einstellungen spielen.

Hängt sich W98 richtig auf oder kannst Du die Task killen?

Benutzt Du ne echte RS232 oder nen USB-RS232 Dongle?

Welchen AVR benutzt Du?
Probier mal nen kleineren AVR (<64k).

Hast Du keinen Rechner mit XP drauf?


Peter

holm wrote:
> Ich opere hier mit einem ATMEGA324P herum und komme nicht zu Stuhle.

Nimm das File für den M32 und ändere Die Portpins und das Include.


> Mal eine Frage, was hat es mit mit folgenden Statement in m32.asm auf
> sich?
>
> ;Attention: BufferSize must fit perfectly into BootStart !
> ;e.g. BufferSize * 18 = BootStart

Um die Schreibroutine einfach zu halten schreibt sie immer komplette
Buffergrößen, auch wenn der letzte Buffer nur ein Word beinhaltet.
Es ist ja auch egal, was noch hinter dem Programm steht, wird ja nie
ausgeführt.

Deshalb muß die Buffergröße ohne Rest in den Flash vor dem Bootloader
passen. Wenn man das nicht beachtet, gibts ne Fehlermeldung, wenn man
den Userflash komplett voll schreiben will.

Die Buffergröße muß natürlich ein Vielfaches der Pagegröße sein und
kleiner als der SRAM (in Words).


Peter

Walter wrote:

> ich hab eine Batchdatei mit dem Aufruf geschrieben die ich per
> Doppelklick starte. Jetzt habe ich es mal in der DOS Box probiert, da
> funktioniert es immer wenn ich den Aufruf per Hand eintippe, will ich
> aber die Batchdatei starten, kommt eine MSDOS Meldung:
> ON oder OFF muss angegeben werden, was soll uns das sagen?

Zeig mal die Bat.

Häng mal den Befehl Pause ans Ende, kann sein, daß dem Programm die UART
weggezogen wird, befor es fertig ist.


Peter

Ich habe mal den C Code des PC-Teils mal nach Python portiert (siehe
Anhang), da ich ihn aus einer Python GUI verwenden will.

Getestet bisher nur unter Ubuntu mit einem ATMega168, sollte aber auch
unter Windows lauffähig sein.

Leider gibt es noch ein Problem mit dem CRC Check, scheinbar wird da
irgendwas nicht korrekt berechnet, der AVR meldet jedenfalls immer einen
Fehler obwohl die Daten korrekt geschrieben werden. CRC ist daher im
Moment deaktiviert.

Grüße
Fabian

PS: Aktuellere Versionen gibt's dann unter folgender Adresse:
http://www.kreatives-chaos.com/artikel/fastboot17-...

So, hier nochmal ein paar kleine Verbesserungen:

Es gibt jetzt nur noch ein Assemblerfile für alle AVRs.

Einfach vor dem gewünschten Include das ; entfernen, die UART-Pins
auswählen, fertig.

Buffersize, Bootstart, Onewire werden nun automatisch ermittelt.


Als neue Funktion ist die Watchdogunterstützung hinzugekommen.
Der Watchdog wird auf 2s verlängert, wenn er enabled ist.
Das PC-Programm muß also mindestens alle 2s ein Byte senden.
Das sollte für das PC-Programm ausreichen.

Die Liste mit den Signaturen ist jetzt als extra File ausgelagert.
Man kann also dort noch neue AVRs eintragen.
Das DEF-File muß im gleichen Verzeichnis wie die EXE stehen.


Am Protokoll hat sich nichts geändert.


Peter

Bingo wrote:

> Ist das korrekt das die PC programm , ist die selber im 17a und 18 ??

Ja, die Versionen sind gleich.


> Und das alle verbesserungen ist im die neye AVR target files layout ??

Auch da ist alles gleich, nur die Watchdogunterstützung ist
hinzugekommen.
Und einige Vereinfachungen, um andere AVRs einzubinden.


Peter

Ich hätte noch eine PC-Software in Java. Diese unterstützt KEIN OneWire
und ist nur mit Version 1.7 getestet.
Aber vielleicht ist das ja für den einen oder anderen interessant.

Der Code findet sich in der PC-Software meines Motorcontrollers:
http://www.matuschek.net/motorsteuerung-software/

Viele Sachen sind dort sehr einfach gehalten, da gibt es sicher noch
Potential für Verbesserungen. Aber es funktioniert prinzipiell...

Ludger wrote:
> weiss jemand, warum beim Versuch den Bootloader fuer den ATMega1281 zu
> assemblieren folgender Fehler ausgegeben wird, obwohl nach einem ersten
> Dateivergleich von m1281def.inc und m2561def.inc kein Fehler
> offensichtlich ist ?

Probiers mal mit der Datei im Anhang.


Peter

Friedhelm Altmann wrote:
>
> Aber der SCS Pin bekommt einfach keine 5 Volt
>

Hast du den Pin als Ausgang gesetzt?
z.B.: im File FASTLOAD.H im macro IOPortInit die Zeile

sbi SCS_DDR, SCS

einfügen.

Gruß andie.

Friedhelm Altmann wrote:

> Jedoch nicht bei ONEWIRE weil habe ja 2 bzw. 3 Leitungen und mir auch
> nicht ganz klar ist wie ONEWIRE funktioniert

Das ist ein Wired-OR (verdrahtetes Oder).
Der High-Pegel ist dominant, d.h. high wird immer gelesene, wenn der PC
high sendet "ODER" der AVR.

Dabei sendet der PC über einen Widerstand, damit der AVR das
überschreiben kann. Der AVR simuliert einen open-drain Ausgang, d.h.
kann nur high senden.
Damit nun die Quittung gelesen kann, muß der AVR sich auf die
Startflanke des 0xFF vom PC synchronisieren und dort sein Byte einfügen.
Solche Timings sind natürlich bei RS-485 nicht möglich.


Bei RS-485 brauchst Du eine spezielle Treiber-DLL, die das Signal für
die Richtungsumschaltung exakt synchron zum Senden erzeugt.

Das Byte 0xFF nach dem Paßwort darf nicht gesendet werden, sondern es
muß dann für 2 Bytezeiten auf Empfang umgeschaltet werden, ehe der
nächste Versuch gestartet wird.

Du mußt also in jedem Fall die PC-Software umschreiben, die kann
definitiv nicht mit RS-485 zusammmenarbeiten!


Peter

Peter Dannegger wrote:
>
> Du mußt also in jedem Fall die PC-Software umschreiben, die kann
> definitiv nicht mit RS-485 zusammmenarbeiten!
>

Hallo Peter,

könntest du nicht eine Version der PC-Software für RS-485 kompilieren?
Es wären dir sicher einige dafür dankbar ;-)
Auf der µP-Seite sollte es dann kein Problem mehr sein, da der Treiber
immer auf Empfang ist und nur zum Senden kurz umgeschaltet werden muss.

Gruß andie.

Andreas Kasper wrote:

> könntest du nicht eine Version der PC-Software für RS-485 kompilieren?

Ich habe ja keine RS-485 Karte an meinem PC und auch nicht die
notwendige Treiber-DLL.

Ich habe nur die ganz normale RS-232 (COM), wie jeder PC.

Ich weiß also nicht, wie man es machen müßte und kann es auch nicht
testen.


Peter

@Ludger

Ich versuch mich auch gerade an nem 128er. Kannst du bitte mal deine
m128.asm posten? Irgendwie will der noch nicht so wie ich.

Danke.

Karsten

Hat sich erledigt. Hatte beim löten nen Draht in der TX Leitung gelötet
weil ich dachte da is was nicht richtig angeschlossen. Hatte aber nur am
flaschen Pin des FT232RL geklingelt. Draht weg und es geht g

Aber man lernt ja aus seinen Fehlern.

Karsten

Also bis zur Version 17 hat die Hilfe noch die Möglichkeit für EEProm
angezeigt. Probiers mal, wenn du hinter den Flash mit Komma getrennt den
EEProm schreibst.

Sonst wäre es ja noch möglich, erst ein Dummy Programm rüber zuladen das
den EEprom schreibt. Notfalls wäre es auch möglich diese Kombination in
der IDE einzubaun.

Der Bottloader Support ist grad in der Testfase in der IDE (noch mit
Version 17). Wenn mein aktuelles Projekt fertig hab gibts in den
nächsten Tagen dann ne Version die nach dem compilieren automatisch die
Software über den Bootloader brennt. (und auch den entsprechenden
Bootöoader erzeugen kann)

Karsten

@ Peter Dannegger (peda)

>> könntest du nicht eine Version der PC-Software für RS-485 kompilieren?

>Ich habe ja keine RS-485 Karte an meinem PC und auch nicht die
>notwendige Treiber-DLL.

>Ich habe nur die ganz normale RS-232 (COM), wie jeder PC.

>Ich weiß also nicht, wie man es machen müßte und kann es auch nicht
>testen.

Doch, nimm einen FTDI232RL. Gibt billig bei Angelika und der hat das
gesuchte TXEN Signal standardmässig dabei, muss nix speziell
programmiert werden, einfach nur über virtuellen COM-Port Daten senden.

MfG
Falk

Falk Brunner wrote:

> Doch, nimm einen FTDI232RL.

Hab ich nicht.

Würde ja nichts nützen, hab auch kein AVR-Board mit RS-485.


> Gibt billig bei Angelika

Schön.

Codesammlung heißt doch nur: "ich hab mal was programmiert und stelle es
rein, so wie es ist."

Wer RS-485 benutzt, kann gerne Bootloader und PC-Programm abändern und
hier reinstellen.



Peter

Hi,

erst einmal auch von mir vielen Dank für das schöne Projekt.

Auch ich habe Probleme in der Programmversion 1.8 bei der Übertrageung
von eep- Dateien in den EEProm.
In der Version 1.7 konnten diese Dateien beispielsweise mit
fboot17 /C1 /PFtest.hex,Etest.eep
übertragen werden.
Leider habe ich in der Version 1.8 trotz veränderter Syntax keinen
Erfolg damit:
fboot18 /C1 /Ptest.hex,test.eep

Wurde die Übertragung der eep- Dateien aus dem Code entfernt?

Grüße
Raik

Raik A. wrote:

> Wurde die Übertragung der eep- Dateien aus dem Code entfernt?

Sie war nie drin, ist nur ein Fehler im Hilfetext gewesen.

Ich habs noch nie gebraucht.

Den EEPROM benutzt man ja dazu, Werte zu speichern, die noch nicht zur
Programmierzeit bekannt sind.

Wenn ich den EEPROM benutze, dann mache ich einen Gültigkeitstest über
die Daten und schreibe bei nem Fehler default Werte rein.

Oder es ist eine Kalibration nötig, dann ergibt es keinen Sinn,
irgendwas reinzuschreiben.


Peter

Bootloaderneuling wrote:
> Nun dem muß ich mal ganz entschieden widersprechen. Mein EEPROM dient
> z.B. der Initialisierung des RAMs durch ein einfaches Copy

Den RAM initialisiert man üblicher Weise aus dem Flash, macht zumindest
jeder C-Compiler so.

Und das Copy Flash->RAM geht auch viel einfacher und schneller, 2
Pointerregister mit Autoincrement ("LPM r16,Z+", "ST Y+,r16").


> aber eben deshalb ist es leider auch kein
> vollwertiger ISP-Ersatz.

Du vergleichst Äpfel mit Birnen.

Es ist ein Bootloader, d.h. er kann auch keine Fuses ändern.
Dafür kann er aber noch bei abgeschaltetem Resetpin flashen, was ISP
nicht kann.


Peter

JojoS wrote:
> dieser hier ist schön kompakt. Gibts zu dem Protokoll evtl. etwas Prosa
> oder muß ich alles aus dem Quelltext rauslesen?

http://www.mikrocontroller.net/attachment/27570/Bo...


Peter

Hallo JoJoS,
ich hab den fboot nach C# konvertiert. Bein Interesse kurze PM an mich,
ich könnte Dir den Code dann zusenden. Ist allerdings direkt aus der
Anwendung "herausgerissen" und mäßig kommentiert. Ich denke aber, man
sollte damit zurechkommen können.

Gruß

Dirk

@Dirk:

Könntest Du den Code bzw. das Projekt evtl. hier posten - ich wäre
nämlich auch an einer Umsetzung in c# interessiert.

Gruß, Thomas

Hallo Leute,
ich habe grade mal eben den Bootloader Code aus meiner Anwendung
herauskopiert und eine eigene kleine Anwendung daraus gemacht.

Der Aufruf des Bootloaders müsste aus dem Code vom OK-Button ersichtlich
sein.

Der Bootloader ist von mir nur mit einem MEGA644 im Zweidrahtmodus
getestet. Kleinere Probleme gab es mit der ersten CRC-Prüfung beim
Anmeldevorgang.

Über Resonanz dazu, Erfolgs-, Fehlermeldungen, Testergebnisse oder
Fragen würde ich mich freuen.

Gruß

Dirk

danke, das sieht doch sehr brauchbar aus.

Hallo Leute,
ein kleiner Nachtrag zum C#/.NET Bootloader.

Es gab noch ein kleines Problem mit eingebauten Warteschleifen. Das
konnte unter Umständen zum Blockieren der Anwendung führen. Auf meinem
Entwicklungsrechner (mit Zweikernprozessor) trat dieses Problem nicht
auf.

Das Projekt benötigt .NET Framework 2.0 und Visual C# 2008. Für die 2005
Version einfach ein neues Projekt anlegen und die Source-Dateien manuell
hinzufügen.

Gruß

Dirk

das Performanceproblem konnte ich nachvollziehen, es hat mir mein
Notebook zum Glühen gebracht :-) Mit dem Sleep ist es aber ok und der
Upload liegt im Sekunden Bereich.
Das Senden geht nochmal doppelt so schnell wenn man die Zeichen
Blockweise sammelt und sendet. Ich verstehe nur noch nicht das
Echo-Lesen in der Send-Methode, ist das für die one-wire Lösung? Das
macht dann Probleme beim blockweisen Senden.
Gegenüber dem Original von Dirk habe ich noch den Buffer aus der Send
Methode genommen damit der nur einmal alloziert wird.

       private byte[] acBuffer = new byte[1];

       private void Send(System.Byte vcByte)
       {
            if(this.Echocount != 0)
            {
                if(this.Echocount > 1)
                    this.Receive(0);    // remove echo
                this.Echocount++;
            }
            acBuffer[0] = vcByte;
            this.MySerialPort.Write(acBuffer, 0, 1);
            this.UpdateCrc(vcByte);      // calculate transmit CRC
       }

Hallo Johannes,
das mit dem Herausziehen der Puffer-Allokierung wird glaube ich nicht
wirklich messbar etwas bringen. Das serielle Senden wird wohl
verhältnismäßig viel mehr Zeit brauchen.

Die meisten Funktionen der Laderoutinen hab ich mehr oder weniger direkt
vom fboot übernommen. Wenn da Unklarheiten sind, kannst Du auch zum
Vergleich einen Blick in den Original-Sourcecode werfen. Das ist die
Datei fboot18.c in der Bootloader Distribution.

Gruß

Dirk

ok, das Bufferallozieren im Send brachte wirklich nichts messbares. Aber
das blockweise Senden bringt hier schon bei knapp 6kB 3,3s gegenüber
8,9s (@115200 BPS, incl. Verify, wo die Daten ja nochmal
rübergeschaufelt werden). Die Änderungen sind minimal, pappe ich mal
hierdran. Nur die Sache mit Echo ist noch nicht ganz klar. Wenn es nur
für one-wire gebraucht wird könnte mit man 'if (onewire)' zwischen den
Send Versionen umschalten. Oder kann man trotzdem erst alles am Stück
senden und danach mit einem Receive über Blocksize die Echos wegwerfen?

Änderung in ProcessFile():

        byte[] tmpbuffer = new byte[Buffersize*2];      // tem.
Sendbuffer, size = max for data+ESC
        int n=0;
         for(i = this.Buffersize, addr = 0; ; addr++)
         {
            switch(d1 = this.Data[addr])
            {
               case ESCAPE:
                  goto case 0x13;
               case 0x13:
                  //this.Send(AVRBootLoader.ESCAPE);
                  tmpbuffer[n++] = AVRBootLoader.ESCAPE;
                  UpdateCrc(AVRBootLoader.ESCAPE);      // calculate
transmit CRC
                  d1 += ESC_SHIFT;
                  goto default;
               default:
                  //this.Send(d1);
                  tmpbuffer[n++] = d1;
                  UpdateCrc(d1);      // calculate transmit CRC
                  break;
            }

            if(--i == 0)
            {
                if (n > 0)
                {
                    MySerialPort.Write(tmpbuffer, 0, n);
                    n = 0;
                }

                if (!bVerify && this.Receive(TIMEOUTP) !=
AVRBootLoader.CONTINUE)
               {
                  this._ErrorMessage = String.Format("Programmieren bei
Adresse {0} fehlgeschlagen", addr);
                  return 1;
               }
               i = this.Buffersize;
            }

            if(addr == lastaddr)
            {
                if (n > 0)
                {
                    MySerialPort.Write(tmpbuffer, 0, n);
                    n = 0;
                }


Die Zeitmessung habe ich in das frmBootloader integriert:

      private DateTime ProgrammingStartTime;

      private void ProgrammingThread()
         {
         .....
         // Programmieren
            ProgrammingStartTime = DateTime.Now;

         // Progress-Event anmelden

....
      private void ProgrammingThreadFinished()
         {
         if(this.InvokeRequired)
            {
            this.Invoke(new
ProgrammingThreadFinishedHandler(this.ProgrammingThreadFinished));
            }
         else
            {
                TimeSpan elapsedTime = DateTime.Now -
ProgrammingStartTime;

            this.txtDateiname.Enabled = true;
            this.cmdDatei.Enabled = true;
            this.cmdOK.Visible = true;
            this.cmdCancel.Visible = false;
            this.cmdSchliessen.Enabled = true;
            this.Cursor = Cursors.Default;

            if(this.MyAVRBootloader.Success)
               Util.MyUtils.MessageInfo(String.Format("{0} Bytes
erfolgreich geschrieben in {1:F1} s!",
                   this.MyAVRBootloader.BytesWritten,
                   elapsedTime.TotalMilliseconds/1000));
            }
         }

an PeDa:
der Assembler hatte gemeckert beim includieren der m32def.inc für den
ATMega32. Die Option Watchdog benutzt das Register WDCE das der m32
nicht kennt. Habe ich die Option erstmal deaktiviert damit, läuft es
durch.

ich habe in die compat.h folgendes eingetragen:

.ifndef WDCE
.equ  WDCE  = WDTOE
.endif

damit klappt der Watchdog für den Mega32 (und andere hoffentlich auch).

muss nochmal nerven und zurückrudern: die Watchdog Option klappt noch
nicht: es lässt sich jetzt übersetzen aber funktioniert nicht (verwende
das fboot18.zip).

erstmal in Watchdog.inc:

;------------------------------  check, if watchdog active ----------------
  wdr
  xin  a0, WDTCR
  ori  a0, 1<<WDCE^1<<WDP2^1<<WDP1^1<<WDP0  ; change enable
  xout  WDTCR, a0
  andi  a1, ~(1<<WDE^1<<WDP2^1<<WDP1^1<<WDP0)  ; 2s
  xout  WDTCR, a0
;-------------------------------------------------------------------------

wird erst Register a0 eingelesen und ausgegeben, dann mit andi a1
bearbeitet aber wieder a0 ausgegeben -> effektiv wird als nur zweimal
der gleiche Wert in WDTCR geschrieben.
Aber zum WD einschalten müsste doch zuerst WDE gesetzt werden? Und wenn
der WD aktiv ist müsste der Bootloader endlos warten statt die Zeit
'BootDelay' abzuwarten? Fragen über Fragen...

Hallo,
ich hab noch ein paar Fragen zum Protokoll.
Ich hab die Kommunikation zwischen einem Atmega8 mit dem Bootloader
Version 18 und dem PC-Programm fboot18 mehrmals mitgeloggt.
Ja, wenn das PC-Programm peda + FF zum Verbinden sendet, und ich dann
den MC anschalte, sendet dieser ein FF 03 08 FF 03 0B FE..
Warum ? Muss ich das im PC-Programm beachten ?

Danach sendet das PC-Programm weiter die Kennung, bis der MC mit A6
antwortet. Allerdings sendet er das A6 über 100 mal, dann sendet er AA
(also SUCCESS) und erst dann sendet das PC-Programm wieder Befehle. Muss
ich jetzt auf das AA warten oder kann ich schon nach dem ersten A6
Befehle senden ?

Ok, dann kommen die Befehle CHECK_CRC, REVISION, SIGNATURE, BUFFSIZE,
USERFLASH, CHECK_CRC und PROGRAM. Nach dem Programmieren nochmal ein
CHECK_CRC.

Jetzt sendet das PC-Programm nochmal ein A5 80 A5 A5 A5..den Befehl gibt
es ja eigentlich nicht. Der MC antwortet auch mit A7 FF 01 F9 00, also
BADCOMMAND. Ich muss diesen Befehl aber nicht senden, oder ?

Vielen Dank :-)

Grüße
David

Johannes Stratmann wrote:

>   andi  a1, ~(1<<WDE^1<<WDP2^1<<WDP1^1<<WDP0)  ; 2s

Ja, das muß natürlich a0 heißen.
Beim 2. Schreiben muß ja das WDCE gelöscht sein.


Peter

David Herrmann wrote:
> Hallo,
> ich hab noch ein paar Fragen zum Protokoll.
> Ich hab die Kommunikation zwischen einem Atmega8 mit dem Bootloader
> Version 18 und dem PC-Programm fboot18 mehrmals mitgeloggt.
> Ja, wenn das PC-Programm peda + FF zum Verbinden sendet, und ich dann
> den MC anschalte, sendet dieser ein FF 03 08 FF 03 0B FE..
> Warum ? Muss ich das im PC-Programm beachten ?

Ich hab das Programm ohne Logger entwickelt, daher sind mir die
zusätzlichen Zeichen nicht aufgefallen.
Ich hab jetzt keine Idee, wo die herkommen.
Wichtig ist ja nur, daß irgendwann das A6 kommt.
Welchen AVR benutzt Du?


> Allerdings sendet er das A6 über 100 mal

Ja, das liegt an Windows, das puffert die UART-Ausgabe (4096 Byte).

D.h. das Bytesenden kommt zurück, aber in Wirklichkeit wird das Byte
erst viel später gesendet.
Der Windowspuffer wird quasi mit Paßwörtern geflutet und dann muß er
erst leer gesendet werden.
Für echte Windowsprogrammierung sollte es aber eine Flush Funktion
geben, die erst zurückkommt, wenn das letzte Byte wirklich gesendet
wurde.


>, dann sendet er AA
> (also SUCCESS) und erst dann sendet das PC-Programm wieder Befehle. Muss
> ich jetzt auf das AA warten

Ja.


> Jetzt sendet das PC-Programm nochmal ein A5 80 A5 A5 A5.

Das dient nur dazu, falls sich die Kommunikation verhakt und der AVR
noch in der Flashschreiberoutine stecken sollte, diese abzubrechen
(A5,80).


Peter

ist immer noch unklar: der WD ist doch nur aktiv wen WDE gesetzt ist?
Vielleicht habe ich den Sinn der WD Option nicht verstanden. Ich denke
es soll nach der WD Zeit ein Reset ausgeführt werden, aber der kommt so
ja vorher durch das Timeout von 0,3s ?

Hallo,
ich verwende einen Atmega8, hab ich im Post eigentlich schon geschrieben
;-)
Danke, Deine Antworten helfen mir aber schon weiter.

Grüße
David

Johannes Stratmann wrote:
> ist immer noch unklar: der WD ist doch nur aktiv wen WDE gesetzt ist?
> Vielleicht habe ich den Sinn der WD Option nicht verstanden. Ich denke
> es soll nach der WD Zeit ein Reset ausgeführt werden, aber der kommt so
> ja vorher durch das Timeout von 0,3s ?

Der Bootloader braucht den Watchdog nicht, er soll nur den Watchdog
unterstützen,

D.h. wenn die Applikation ihn verwendet, trotzdem noch ein Flashen
ermöglichen.

Oder die Applikation startet den Bootloader von sich aus per
Watchdogreset.


Peter

Peter Dannegger wrote:
> Der Bootloader braucht den Watchdog nicht, er soll nur den Watchdog
> unterstützen,

danke, dann ist das klar.

> Oder die Applikation startet den Bootloader von sich aus per
> Watchdogreset.

so mache ich das jetzt auch, ich hatte zuerst den Proz. Takt nicht
angepasst, bei default 8Mhz und vorhandenen 12Mhz war die Wartezeit nach
dem Reset zu kurz. Jetzt läuft alles wie im Kino, auch mit der .Net
Version von D. Schmidt.

Thomas wrote:
> C:\temp>avrasm32 -fI m8.asm
> AVRASM: AVR macro assembler version 1.74  (Dec 16 2003 11:49:32)

2003 is schon ne Weile her,

AVRASM2 nehmen.


Peter

Hallo,
mit meinem VB-Programm bin ich jetzt schon so weit, dass die Verbindung
mit dem Atmega8 aufgebaut wird, die Checksumme initialisiert wird,
Signatur, Buffsize und Userflash ausgelesen werden und dann eine
CRC-Prüfung gemacht wird.
Jetzt gehts ans Programmieren, da hab ich noch eine Frage:
Ich hab jetzt die BufferSize ausgelesen, bei mir kam da der Wert 960
raus. Sind das Byte ? Oder Bit ? Oder was sonst ?
Soll ich dann nach 960 Byte/Bit auf ein CONTINUE (A9) warten ?

Grüße
David

David Herrmann wrote:

> Ich hab jetzt die BufferSize ausgelesen, bei mir kam da der Wert 960
> raus. Sind das Byte ? Oder Bit ? Oder was sonst ?

Was für nen Sinn sollte denn eine Bitangabe haben?

Die UART (8,N,1) arbeitet immer byteweise.


> Soll ich dann nach 960 Byte/Bit auf ein CONTINUE (A9) warten ?

Ja.


Peter

Peter Dannegger wrote:

> Was für nen Sinn sollte denn eine Bitangabe haben?
>
> Die UART (8,N,1) arbeitet immer byteweise.

Ehrlich gesagt, keinen :-)
Sorry, aber ich wusste es einfach nicht, ob es jetzt 960 Byte oder 120
Byte (960 Bit sind).
>
>
>> Soll ich dann nach 960 Byte/Bit auf ein CONTINUE (A9) warten ?
>
> Ja.

Ok, vielen Dank.

Grüße
David

Mal eine ganz dumme Frage... Nachdem ich 2x direkt nacheinander meine
AtMega644 mit PonyProg gekillt hatte und nur 1 gerettet werden konnte
will ich nun einen Bootloader nutzen.

Wenn ich den Thread hier richtig verstanden habe, dann muss ich nur die
Hex-Datei aus dem Projekt compilieren und auf den µC laden und dann mit
der fboot17a.exe meine eigenen Projekte übertragen, richtig?

Beziehe mich auf dieses Zip-Archiv:
>Autor: Ludger (Gast)
>Datum: 28.01.2008 15:05
>Dateianhang: fboot17a_20080128_1458.zip (18 KB, 35 Downloads)

Markus B. wrote:
> Wenn ich den Thread hier richtig verstanden habe, dann muss ich nur die
> Hex-Datei aus dem Projekt compilieren und auf den µC laden und dann mit
> der fboot17a.exe meine eigenen Projekte übertragen, richtig?
Du musst zusätzlich noch die Fuses so einstellen dass von der richtigen
Adresse gestartet wird, sonst passiert nichts.

Hi Peter,

ich versuche deine ABaud Routine zu kapieren.

abaud:
  ldi  a0, byte3(BootDelay / 6)
_aba1:
  movw  zh:zl, zeroh:zerol  ; cause first try invalid
_aba2:
  movw  yh:yl, zh:zl
  movw  zh:zl, zeroh:zerol  ; z = 0x0000
_aba3:
  sbiw  twh:twl, 1    ;2
  sbci  a0, 0      ;1
  SKIP_RXD_0      ;1  wait until RXD = 0
  brne  _aba3      ;2 = 6
  breq  timeout
_aba4:
  sbiw  yh:yl, 1    ;2
  adiw  zh:zl, 4    ;2  count bit time
  brcs  timeout      ;1  time to long
  SKIP_RXD_1      ;1   wait until RXD = 1
  rjmp  _aba4      ;2 = 8
;------------------------------ correction for USB dongle !!! ------------
  mov  r0, zh
_aba5:
  asr  yl      ; shift signed !
  lsr  r0
  brne  _aba5
;-------------------------------------------------------------------------
  sbiw  yh:yl, TOLERANCE
  adiw  yh:yl, 2 * TOLERANCE
  brcc  _aba2      ; outside tolerance
  cpi  zl, MINTIME
  cpc  zh, zerol
  brcs  _aba2      ; time to short
  sbiw  zh:zl, 2*UartLoop-1  ; rounding, -loop time
  lsr  zh      ; /2
  ror  zl
  movw  baudh:baudl, zh:zl

1.) das Label _aba1: wird nicht benutzt und kann doch sicherlich
entfernt werden

2.) das

  sbiw  yh:yl, TOLERANCE
  adiw  yh:yl, 2 * TOLERANCE

verstehe ich nicht. Könnte man nicht auf das sbiw verzichten und statt
dessen "adiw yh:yl, TOLERANCE" benutzen ? Das würde 1 Opcode sparen.


3.) der Vergleich mit anschließender Rundung könnte vereinfacht werden,
aus

  cpi  zl, MINTIME
  cpc  zh, zerol
  brcs  _aba2      ; time to short
  sbiw  zh:zl, 2*UartLoop-1  ; rounding, -loop time

wird eventuell so:

  sbiw    zh:zl, MINTIME
  brcs  _aba2      ; time to short
  adiw  zh:zl, MINTIME - 2*UartLoop-1  ; rounding, -loop time

4.) wenn man die Baudrate Register baudh:baudl in den oberen
Registerbereich verschieben würde so könnte man statt zh:zl direkt auf
diese Register in ABaud zugreifen. Das würde wiederum das letzte MOVW
eliminieren.

Insgesamt spart man so min. 6 Bytes an Code. Ich weiß das ist nicht viel
aber wenn man schon eine so perfekte und kompakte ABaud Routine hat...
;)

5.) mir ist aufgefallen das twh:twl nicht auf 0 initialisert wird. Ok,
das dürfte bei einem echten Reset nicht das Problem sein, wenn aber aus
der App in den Bootloader gesprungen wird dann könnten twh:twl schon
Werte <> 0 enthalten. Dadurch dürfte sich das Timing leicht verändern.
Ich weiß das dies im Grunde unwesentlich ist.

6.) könnte man das Kommandoprotokoll nicht vereinfachen ? Deine 4
Messages werden zu einem kompletten Block zusammengefasst. Gleich mit
der Bestätigung des CONNECT werden dann diese Infobytes mit übertragen,
an einem Stück. Als reale Kommandos verbleiben dann nur noch das
Programmieren, CheckCRC, Verify und Run App übrig. Man würde damit
einige Bytes an Code für den Kommandointerpreter und bei den Messages
einsparen.
Alternativ könnte man auch nur ein einzigstes Infokommando bauen.

7.) in putchar: folgt der Einsprungspunkt SyncPutChar für 1-Wire. Wenn
man diesen dort entfernt wird ein "rjmp _tx2" elimiert. Dafür wird der
Code von SyncPutchar vorgezogen und in FastLoad.inc -> connected:
eingebaut. Denn nur dort wird ja SyncPutChar aufgerufen. So spart man
nochmals 2 Bytes an Code.

Alles in allem düfte man so bei 1-Wire eine Flash-Page mindestens
einsparen können.

Gruß Hagen

Hagen Re wrote:

> 1.) das Label _aba1: wird nicht benutzt und kann doch sicherlich
> entfernt werden

Ja

> 2.) das
>

>   sbiw  yh:yl, TOLERANCE
>   adiw  yh:yl, 2 * TOLERANCE
> 

>
> verstehe ich nicht. Könnte man nicht auf das sbiw verzichten und statt
> dessen "adiw yh:yl, TOLERANCE" benutzen ? Das würde 1 Opcode sparen.

Nein, der Fehler kann ja positiv oder negativ sein.

> 3.) der Vergleich mit anschließender Rundung könnte vereinfacht werden,

>

>   sbiw    zh:zl, MINTIME
>   brcs  _aba2      ; time to short
>   adiw  zh:zl, MINTIME - 2*UartLoop-1  ; rounding, -loop time
> 
> 

Gibt nen Error, Du kannst nur kleine Werte 16bittig addieren.


> 4.) wenn man die Baudrate Register baudh:baudl in den oberen
> Registerbereich verschieben würde so könnte man statt zh:zl direkt auf
> diese Register in ABaud zugreifen. Das würde wiederum das letzte MOVW
> eliminieren.

Da ist aber nichts mehr frei.

> 5.) mir ist aufgefallen das twh:twl nicht auf 0 initialisert wird.

Ist ja insgesamt ein 3-Byte Zähler, da reicht es, nur das höchstwertige
Byte zu laden, ein Timeout muß ja nicht supergenau sein.

> 6.) könnte man das Kommandoprotokoll nicht vereinfachen ? Deine 4
> Messages werden zu einem kompletten Block zusammengefasst.

Es sollte ne universelle Zahlenausgaberoutine sein, falls man später mal
noch andere Werte übertragen will (Fusebits).

> Alles in allem düfte man so bei 1-Wire eine Flash-Page mindestens
> einsparen können.

Mein Ziel war, beim ATtiny13 noch die Hälfte vefügbar zu haben.


Peter

>>   sbiw  yh:yl, TOLERANCE
>>   adiw  yh:yl, 2 * TOLERANCE

>> verstehe ich nicht. Könnte man nicht auf das sbiw verzichten und statt
>> dessen "adiw yh:yl, TOLERANCE" benutzen ? Das würde 1 Opcode sparen.

>Nein, der Fehler kann ja positiv oder negativ sein.

Also Tolerance ist definiert als 3.

Wir Subtrahieren  also  y -= 3 und danach addieren wir y += 6, da das
Carry erst nach der Addition ausgewertet wird kann man y = y (-3 + 6) ->
y += 3 rechnen. Ein Carry in SBIW wird im ADIW nicht berücksichtigt.

Irgendwas verstehe ich da nicht. Kannst du mir erklären worin der
Unterschied bestünde zwischen

y -= 3;
y += 6;
if y < 0 then ..

zu

y+=3;
if y < 0 then ..


Gruß Hagen