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 Peter,
in dem anderen Thread schreibst Du, "die Programmierpins sind frei
wählbar"...
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?
Wäre echt prima und sicher für viele sehr hilfreich.
Vielen Dank
Andreas
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
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
Asoo, Dateiname ... ich dachte Pfad^^. Danke jetzt geht es.
Hab aber folgendes Problem:
Habe erfolgreich folgendes Programm draufgespielt:
1
#include<avr/io.h>
2
3
// Sollte normalerweise schon im Makefile definiert sein.
4
// In dem Fall hier einfach löschen.
5
#define F_CPU 11059200
6
7
#define BAUD 2400UL
8
#define UBRR_BAUD ((F_CPU/(16UL*BAUD))-1)
9
10
voidioinit(void);
11
voiddelay_ms(unsignedintms);
12
voiduart_init(void);
13
14
15
16
// USART initialisieren
17
voiduart_init(void)
18
{
19
// Baudrate einstellen (Normaler Modus)
20
UBRRH=(uint8_t)(UBRR_BAUD>>8);
21
UBRRL=(uint8_t)(UBRR_BAUD&0x0ff);
22
23
// Aktivieren von receiver und transmitter
24
UCSRB=(1<<RXEN)|(1<<TXEN);
25
26
// Einstellen des Datenformats: 8 Datenbits, 1 Stoppbit
27
UCSRC=(1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0);
28
}
29
30
31
32
// Hauptprogramm
33
intmain(void){
34
unsignedchari;
35
36
ioinit();
37
38
uint8_tbuffer;
39
40
// USART initialisieren
41
// uart_init();
42
43
44
// Endlosschleife
45
while(1){
46
PORTD^=(1<<PD7);
47
48
// Eine Sekunde warten
49
delay_ms(1000);
50
}
51
52
return0;
53
}
54
55
// Initialisierung
56
voidioinit(void)
57
{
58
DDRD=0xff;// PortB als Ausgang deklarieren
59
PORTD=0x00;// Ports auf LOW schalten
60
}
61
62
// Warteschleife
63
voiddelay_ms(unsignedintms)
64
{
65
unsignedintzaehler;
66
67
while(ms){
68
zaehler=F_CPU/5000;
69
70
while(zaehler){
71
asmvolatile("nop");
72
zaehler--;
73
}
74
ms--;
75
}
76
}
Das Programm funktioniert auch ... aber jetzt kann ich kein neues
Programm brauchspielen .. er kann sich nicht mehr connecten.
Liegt es daran weil ich komplett die Ports D:
DDRD = 0xff; // PortB als Ausgang deklarieren
PORTD = 0x00; // Ports auf LOW schalten
als ausgang geschaltet habe und meine Pins beim Bootloader sind auch die
von PortD:
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
Hallo PeDa,
ist in der Abaud Funktion noch ein Bug enthalten?
Wenn RxD immer High bleibt kommt es nie zum Timeout, da die Prüfung nach
dem SKIP_RXD_O stattfindet. Bei der TinyLoad 1v3 wurde vorher geprüft.
Vielleicht habe ich aber auf das ganze noch nicht richtig durchschaut.
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 ?
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
Wirklich grossartig...
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 :)
Vielen Dank noch einmal !
Gruß, Stefan
---
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
Das klingt ja vielversprechend !
Wenn ich das richtig interpretiert habe, läuft die Flußsteuerung dann
komplett via Software, der entsprechende Port wird also umgeschaltet ..?
Das sollte für den Hausgebrauch auch ausreichend sein; wenn es dann mal
via RS485, also mit externer Treiberumschaltung sein soll, kann man das
ja nach Belieben selbst reinfriemeln ;)
Vielen Dank für Deine Anstrengungen...
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):
C:\avr\bootloader\bootloader.asm(9): Including file 'C:\Programme\Atmel\AVR Tools\AvrAssembler2\Appnotes\m48def.inc'
5
C:\avr\bootloader\bootloader.asm(14): warning: Use of undefined or forward referenced symbol 'SecondBootStart' in .equ/.set
6
C:\avr\bootloader\bootloader.asm(33): Including file 'C:\avr\bootloader\fastload.inc'
7
C:\avr\bootloader\fastload.inc(9): Including file 'C:\avr\bootloader\compat.h'
8
C:\avr\bootloader\fastload.inc(10): Including file 'C:\avr\bootloader\fastload.h'
9
C:\avr\bootloader\fastload.inc(21): error: Overlap in .cseg: addr=0x0 conflicts with 0x0:0x1
10
C:\avr\bootloader\bootloader.asm(33): info: 'C:\avr\bootloader\fastload.inc' included from here
11
C:\avr\bootloader\fastload.inc(38): Including file 'C:\avr\bootloader\abaud.inc'
12
C:\avr\bootloader\fastload.inc(39): Including file 'C:\avr\bootloader\password.inc'
13
C:\avr\bootloader\fastload.inc(83): Including file 'C:\avr\bootloader\checkcrc.inc'
14
C:\avr\bootloader\fastload.inc(90): Including file 'C:\avr\bootloader\verify.inc'
15
C:\avr\bootloader\fastload.inc(101): Including file 'C:\avr\bootloader\message.inc'
16
C:\avr\bootloader\fastload.inc(104): Including file 'C:\avr\bootloader\progmega.inc'
17
C:\avr\bootloader\fastload.inc(110): Including file 'C:\avr\bootloader\uartcrc.inc'
18
C:\avr\bootloader\bootloader.asm(35): warning: end of .dseg at 0x4c0 is beyond end of memory at 0x2ff
19
20
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
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
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...:
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
1
cli();
2
asmvolatile("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
> ich habe versucht einen Pin mit dem Resetpin zu verkabeln, da hängt
sich aber alles auf wenn ich den auf LOW setzte
Mach das am besten über den Watchdog.
Pseudocode
cli();
WdtEnable(WDT_1MS);
while(!0) {}
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:
1
voidreset(void)
2
{
3
uint8_ti;
4
5
uart_puts("reset\r\n");
6
7
for(i=30;i>0;i--){
8
uart_puti(i);
9
uart_puts("\r\n");
10
_sleep();
11
}
12
13
14
//Interrups deaktivieren
15
cli();
16
17
//Watchdog einschalten
18
WDTCSR=(1<<WDE);
19
for(i=0;1;i++){
20
uart_puti(i);
21
uart_puts("\r\nw");
22
}
23
24
}
Aufem Treminal kriege ich:
1
...
2
2
3
1
4
0
5
w1
6
w2
7
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)
1
/dev/ttyS0 at 115200 Baud: -
2
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
Hallo,
bei mir zeigt der Linux-Client seltsame Buffergrößen an...
hängt das mit den Compilerwarnings zusammen?
Ansonsten danke an Peter für den tollen Bootloader und an Andreas für
den Linux-Client.
Grüsse Tobias
1
vm-debian-testing:~/tmp# make
2
gcc -Wall -g -c main.c -o main.o
3
main.c: In function 'readhex':
4
main.c:327: warning: pointer targets in passing argument 1 of 'sscanhex' differ in signedness
5
main.c:330: warning: pointer targets in passing argument 1 of 'sscanhex' differ in signedness
6
main.c:333: warning: pointer targets in passing argument 1 of 'sscanhex' differ in signedness
7
main.c:339: warning: pointer targets in passing argument 1 of 'sscanhex' differ in signedness
8
gcc -Wall -g -c readargs.c -o readargs.o
9
readargs.c: In function 'readargs':
10
readargs.c:46: warning: conversion lacks type at end of format
11
readargs.c:46: warning: too many arguments for format
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
Super!!!
Vielen Dank an Peter Dannegger !
Hab den File auf meinen ATmega8 geflasht und konnte mit dem beigefügten
Tool (fboot.exe) sofort meine hex-Files in den uC kopieren.
Sehr geil... und auch noch dazu superschnell!
mfg Christian
Wirklich super der Bootloader! Hab ihn bei meinen RS485 Bussen
mittlerweile auf jedes Device gebracht und bin wirklich sehr zufrieden!
Warte jetzt nur noch auf eine Weiterentwicklung des FBOOT.EXE Tools, die
auch unter Vista läuft.
Ich habe mir nochmal die Linux-Version von fboot.c vorgenommen,
nachdem ich auch den Fehler mit der negativen Buffergroesse usw.
hatte.
Der Fehler lag wohl in "com_getc()".
horst.
Hallo Peter,
hast du für deine Bootloader mal eine Dokumentation gemacht.
Leider muß man sich alles aus den 3 Threads mit so vielen Beiträgen
zusammen suchen :-(
Außerdem bi ich recht neu im Bereich der Mikrocotroller.
Mich würde eine genaue Bescreibung des AVR Programms
und eine genaue Beschreibng des PC Programms interessieren.
Gruß Tobias
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
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
Hallo...
nachdem Halb-Duplex ja mittlerweile implementiert ist, -vielen Dank
dafür- habe ich den Code mal überflogen. Wenn ich's richtig verstanden
habe, dient der C-Code hauptsächlich dem strukturierteren Aufbau; der
eigentliche Bootloader ist jedoch in Assembler geschrieben !?
Jetzt bin ich in C nicht eben die Leuchte und möchte den Loader gern mit
meinem bestehenden Assembler-Source verbinden, bzw. der Einfachkeit
halber, den Assembler-Teil nachladen. Muss ich den Assembler-Code an
eine bestimmte Adresse legen, damit's möglichst reibungslos funktioniert
?
µC wäre ein Tiny45...
Gruß, Stefan
---
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
Das macht die Angelegenheit doch schon viel transparenter ;)
Ich dachte ursprünglich, dass es jetzt ein Flag gibt, das zwischen uni-
oder bidirektionale Kommunikation selektiert und dass noch Definitionen
für den Pin für's Umschalten zwischen Senden und Empfangen, bei RS-485
Treibern dazu gekommen sind.
Aber es sieht so aus, als ob man in der jeweiligen controller.asm
einfach nur Senden und Empfangen auf den gleichen Pin legt und
eventuelle Konflikte mit den Widerständen begrenzt !?
Demzufolge müsste für aktive Treiber, deren Umschaltung noch von Hand
reingefrickelt werden !?
Wäre an sich kein Problem, wollte nur fragen, bevor ich den Source nach
den TxD/RxD-Geschichten durchsuche...
Stefan
---
Hallo,
ich habe gerade versucht den bootloader mit einem mega8535 ans laufen zu
bekommen.
Habe dazu einfach das m8.asm file kopiert, und oben den include geändert
(mega8535 hat auch 8kbyte flash).
Grundsätzlich scheint es auch zu laufen, er sagt das alles wunderbar
ist:
1
COM 2 at 4800 Baud: Connected
2
Bootloader V1.6
3
Target: 1E9308
4
Buffer: 960 Byte
5
Size available: 7680 Byte
6
Program test.hex: 00000 - 0022F successful
7
CRC: o.k.
8
Elapsed time: 1.65 seconds
Das eigentliche Programm startet dann aber nicht.
Ich habe dann das Flash wieder per ISP ausgelesen, dabei stellte sich
heraus das die erste 48 Bytes komplett verschieden sind.
Die ist .hex Datei (per ISP ausgelesen):
1
:10000000EC0102C02196E8DF88818823D9F7DF91CF
2
:10001000CF910895CF93DF93EC0101C0DDDFFE01A6
3
:10002000219684918823D1F7DF91CF910895FFCF56
4
:10003000D2E0DEBFCDBF10E0A0E6B0E0E0E3F2E04A
Die soll .hex Datei (compiliert):
1
:1000000014C02EC02DC02CC05BC02AC029C028C07F
2
:1000100027C026C025C05FC088C022C021C020C024
3
:100020001FC01EC01DC01CC01BC011241FBECFE5B9
4
:10003000D2E0DEBFCDBF10E0A0E6B0E0E0E3F2E04A
Erst ab der 4ten Zeile sind sie wieder identisch
Was ist da passiert?
PS:
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
Hallo,
ich versuche schon seit einiger Zeit den Bootloader (v1.4) zum laufen zu
bekommen - leider ohne Erfolg. Versucht hab ichs mit einem M32 und einem
M8. Als RX/TX benutze ich die Hardware Schnittstelle:
M32.asm:
;-----------------------------------------------------------------------
--
; Port definitions
;-----------------------------------------------------------------------
--
.equ STX_PORT = PORTD
.equ STX_DDR = DDRD
.equ STX = PD1
.equ SRX_PIN = PIND
.equ SRX_PORT = PORTD
.equ SRX = PD0
;-----------------------------------------------------------------------
--
.include "fastload.inc"
;-----------------------------------------------------------------------
--
Habe das Programm mit AVRASM2 compiliert und anscließend mit dem
AVR-Burn-o-mat in den COntroller geladen. Was mir sehr seltsam vorkommt,
ist dass insgesamt 32722 Bytes in den Controller geladen werden (beim
M32). Damit ist der Flash doch voll...?
Die Fuses sind auch gesetzt(nach Anleitung)...
Wenn ich jetzt fboot mit COM4 im Verzeichnis mit der Zielfirmware
starte, kommt das Programm nicht weiter als "COM4 at 115200 Baud".
Zu erwähnen ist noch, dass ich den M32 mit einem Quarz 16MHz
betreibe(ist auch in Fastload.h eingestellt.
Beim M8 gibts genau das gleiche Problem, der läuft aber mit 7,37MHz.
Die Bootzeit habe ich wegen der höheren Frequenz etwas erhöht, mehrer
Werte von 3-16 ausprobiert, funktioniert trotzdem nicht...
Was mache ich falsch?? Könnt ihr mir weiterhelfen?
Gruß
Johannes
hab das mit den 512Byte mal ausprobiert, hilft aber leider auch nix...
Wo kann ich denn nachgucken, wieviel Bytes das compilierte Programm hat?
Ist das der Wert, der nach dem Compilieren bei "Summery ... USED Memory"
steht? (bei mir 470Bytes.
Kann das vielleicht auch mit dem USB- Seriell Adapter zusammenhängen?
Aber eigentlich läuft alles Andere wie geschmiert mit dem Adapter...
danke für den Tipp!
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
1
case0x1e9308:s="ATmega8535";break;
Kompletter flash (7680 Byte) hat bei mir 2,3 Sekunden gedauert :)
Getestet mit 115200 BAUD @ 14318180 Hz und FBOOT V1.7
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
Hallo,
super bootloader!
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?
Und wie verhält sich der booloader wenn man etwas in den booloader
Bereich flashen will (wenn man keine LockFuses programmiert hat)?
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.
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
Danke!
>Du kannst auch ein anderes und auch längeres Passwort als "PeDa">definieren, es muß bloß ein für die Baudratenerkennung geeignetes>Zeichen enthalten, z.B. 'a'.
Was macht das 'a' so gut tauglich für die Baudratenerkennung?
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.
Also das "nicht reagieren" kenne ich auch nur wenn der Port bereits von
einem anderen Programm verwendet wird.
Eventuell irgend ein Programm im Hintergrund was von Zeit zu Zeit alle
Ports abklappert?
..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
Hallo
Habe probiert Peters PC program Fboot17.exe zum portieren aus DEV-Cpp ,
ich glaube ich habe success. Ich kann programmiere mit 57600 , aber
115200 geht nicht , vielleicht ob die uart routinen optimiert bist.
Aber da ist support von Com 1..5 , ind source ist inkludiert.
Installiere Dev-Cpp
http://www.bloodshed.net/dev/devcpp.html
Download
http://prdownloads.sourceforge.net/dev-cpp/devcpp-4.9.9.2_setup.exe
Und extract die Fboot source , dan "Klik" am fboot.dev file.
Zum die projekt loaden.
Selektiere im Dev-Cpp select : Execute->Rebuild All
Danke an Peter , und hoffe diser program ist brauchbar.
Ps: Die program hast sources von Peter-D , und snippets von Peter Fleury
, und die linux programmer von diser thread.
Pps: Ich habe nur die program kurtzes testet.
Das ist nur einer schnell C program mit serial I/O usv im C ... und
kein C++ braucht.
Grüsse aus Dänemark
/Bingo
Hoffe meiner "Schule Deutch" ist verstehbar
@Peter
Ich bin nicht 100% sicher , das ich habe die timeout implementiert
korrekt.
Im Dev-Cpp bist 1000 clock() ticks pro sekunde , vie viel ist im Borland
??
mfg
/Bingo
Einer kleine verbesserung
Im serial_connect (void) routine
Erszatz die linie
if (--i > 6)
mit
if (--i >= (sizeof(devtab)/sizeof(devtab[0])))
Dann passt mehre comports im diser linie automatisch
char *devtab[] = { "COM1", "COM2", "COM3", "COM4", "COM5", "COM6" };
/Bingo
@Gast
"... und ab Com9 muss es "\\.\Com9" heißen." ........
Bist du sicher ???
Ich habe nur diser syntax sehen , im die com-bridge das lady-aya
brauchst im eure, Atmel USB programmer. Und ich glaube die prefix war im
die driver.
Nicht im einer standard Windows
/Bingo
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
@Peter
Ich habe COM1 .. COM6 (2x eingebaut und 2x2 von PCI karte), und das ist
ohne die viele FTDI virtual Comadapters , ich glaube meiner höheste
comport ist 9
/Bingo
Ps: Hast jemand die Dev-Cpp program probiert ??
So, jetzt muss ich diesen genialen Bootloader auch mal probieren...
scheint ja meine Probleme lösen zu können ;-)
will ihn für den ATtiny85 verwenden, da ich den reset-pin als io
verwenden muss und daher ISP nicht mehr nutzen kann.
habe mit jetzt eine datei T85.asm mit folgendem Inhalt angelegt:
soweit so gut... kompilieren ging auch alles sehr einfach von der Hand.
-> der Bootloader wurde auf Adress 0x1E00 gelegt.
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?
Habe einen 12MHz Quarz. und BootDelay auf XTAL / 10 gesetzt... was
bedeutet das jetzt?
Danke und liebe Grüsse
Jörg
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
hmmm... habe jetzt ewig gesucht und nicht verstanden, warum auf 0x0000
kein Code steht...
kann sein, dass die Datei "fastload.inc" auf folgendes geändert gehört:
1
.nolist
2
.include "fastload.h"
3
.listmac
4
.list
5
6
.ifndef BootFuse
7
.org 0x0000
8
rjmp init
9
.endif
10
11
.org BootStart
12
init:
oder habe ich was übersehen, wo der "rjmp init" sonst gemacht gehört?
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
habe das ganze jetzt probiert und es funktioniert SUPER!!!!
ich mich niederknien und verbeugen tu
habe mir mit einem Pogo-Pin einen Adapter zum 1wire programmieren
gemacht... und unglaublicherweise hat es gleich funktioniert. pogo-pin
auf SMD-Widerstand gedrückt, und ab ging die Post hut ab
Habe gestern den Bootloader auf einem ATmega88 mit der Onewire probiert
-> GENIAL.
also der One-Wire mode ist schon ein nettes Feature. Versorgung und
Pogo-Pin und ab geht die Post
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?
Was muß man zur Benutzung des „Eindrahtmodus“ an den Port-Pins ändern?
;-----------------------------------------------------------------------
--
; Port definitions
;-----------------------------------------------------------------------
--
.equ STX_PORT = PORTB
.equ STX_DDR = DDRB
.equ STX = PB1
.equ SRX_PIN = PINB
.equ SRX_PORT = PORTB
.equ SRX = PB0
Mit einem MAX232 mit zwei Drähten läuft alles super, nur der
„Eindrahtmudus“ aus Peters 1wire.pdf will noch nicht so, wie ich es
will…
Würde gern ohne MAX232 auskommen.
Kann sich bitte jemand meinen Schematischen Schaltplan für den
„Eindraht-Betrieb“ ansehen, ob dort ein Fehler in der Schaltung ist…
Ich hoffe, ich habe Peters Schaltplan richtig aufgebaut.
Leider habe ich den Eindrahtmodus am ATmega8 noch nicht zum laufen
gebracht. Mit zwei Drähten und einen MAX232 klappt es sofort. Würde gern
den MAX232 einsparen.
Hier meine Porteinstellungen für den Eindrahtmodus
;-----------------------------------------------------------------------
--
; Port definitions
;-----------------------------------------------------------------------
--
.equ STX_PORT = PORTB
.equ STX_DDR = DDRB
.equ STX = PB1
.equ SRX_PIN = PINB
.equ SRX_PORT = PORTB
.equ SRX = PB1
;-----------------------------------------------------------------------
--
Ich verfolge jetzt schon eine Zeitlang diesen super threat.
Nun plane ich einen mega8 mit dem "ONEWIRE" zu flashen.
Dazu habe ich mir tinyload3.zip heruntergeladen, in m8.asm die Ports
angepasst und mit dem AVR-Studio ein Hexfile erzeugt - aber wo finde ich
.equ CRC = 17 ; 17 = additional code size
.equ VERIFY = 15
.equ ONEWIRE = 3
Werde mir Morgen noch das Kabel schnitzen
Vielen Dank die Info
Ä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 ?
Gruß, Stefan
---
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
Nochmal
Wo bitte finde ich die Defines
.equ CRC = 17 ; 17 = additional code size
.equ VERIFY = 15
.equ ONEWIRE = 3
Ich kann die Defines in der Source nicht finden - gibt es eine neuere
Version von Loader als tinyload3.zip
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
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
Hallo Peter,
das interessiert schon. Vielen Dank!
Ich muss im nächsten Bastelprojekt einen Tiny45 ausreizen. Da kommt es
natürlich gut, wenn man alle Pins belegen kann. Da werde ich es
ausprobieren.
Gruß Gerd G.
Hallo Peter
Vielen Dank für den Hinweis.
Ich habe den mega8-Loader zunächst mal für Bidirektional angepasst.
Die Sende und Empfangspins
.equ STX_PORT = PORTD
.equ STX_DDR = DDRD
.equ STX = PD1
.equ SRX_PIN = PIND
.equ SRX_PORT = PORTD
.equ SRX = PD0
-------------------------------
Ich verwende einen 16Mhz Quarz
.equ XTAL = 16000000 ; 8MHz, not critical
.equ BootDelay = XTAL / 3 ; 0.33s
Fusebits BOOTSZ0=0
BOOTSZ1=1
BOOTRST=0
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. An PD1 (TX) sehe ich einen 4V Pegel und
alle 8ms für 240µs 0V. Am PC sehe ich "Com 1 at 115000 Baud: |" das
letzte Zeichen dreht sich bis zun St. Nimmerleinstag. Warum kann der PC
die Baudrate nicht finden? Liegt es an meinen 16MHz?
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:
Hallo
ich hab da auch mal eine frage.
Ich möchte über die DTR leitung, einen Transistor ansteuern der mir dann
reset kurz aktiviert. Dieses möchte ich mit der Option "/R" aktivieren
können.
Leider macht die DTR-Leitung jedoch bei jedem Init für etwa 625ms einen
12V-Impuls. Warum? Kann ich diesen irgendwie unterdrücken?
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
>Leider macht die DTR-Leitung jedoch bei jedem Init für etwa 625ms einen>12V-Impuls. Warum? Kann ich diesen irgendwie unterdrücken?
Hallo, koennte das wie beim USB FTDI CHIP die Enumaration ?
@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
Einer update von meiner dev-cpp (Windows 32) port von Peters bootloader
Exe datei ist inkludiert.
Ich habe nur probiert mit einer kleiner hexdatei , und ich brauche 57600
bps nicht 115200 (gibts probleme bei mir)
grusse von Dänemark
Bingo
Hallo PeDa,
kleine OT-Nachfrage an den Praktiker:
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?
a) Erst einlöten - dann werden aber die ISP-Pins trotzdem benötigt
und kosten Platz/Stecker.
b) Spezielle Programmierfassung - sehr (Sau) teuer.
c) Beim Distributer progammieren lassen - unflexibel weil Fusebits
bekannt
sein müssen (Takt Startup Brownout...)
Gruß Jogi
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.
Hallo,
ich versuche gerade den bootloader auf meinem mega644 zum laufen zu
bringen. Klappt jedoch nicht so richtig. Ich habe genau das gleiche
Problem wie es schon Dirk Schmidt (disc) am 13.09.2007 weiter oben
geschildert hat. Nur leider gab es damals keine Antwort...
Ich bin beim flashen nach der wiki Anleitung vorgegangen.
meine Einstellungen: TX und RX auf PortD, XTAL=18432000,
bootdelay=xtal/3
->mit "avrasm2 -fI m644.asm" übersetzt und mit ponyprog (lpt1) gebrannt
->fuses gesetzt: bootrst=0,bootsz1=1,bootsz0=0
beim Start von fboot.exe erscheint nun folgender fehler für V1.4
1
C:\boot>fboot /C1 /Pmain.hex
2
COM 1 at 115200 Baud: Connected
3
Bootloader VFFFFFFFF.FF
4
Target: FFFFFFFF
5
Buffer: -1 Byte
6
Size available: -1 Byte
7
CRC: error !
8
Elapsed time: 0.55 seconds
und für V1.7
1
C:\boot>fboot17 /C1 /Pmain.hex
2
COM 1 at 115200 Baud: Connected
3
Bootloader VFFFFFFFF.FF
4
Error, wrong device informations
Ich habs auch schon mit einer geringeren Baudrate (wie oben empfohlen)
probiert, leider ohne Erfolg.
Dumme Frage: Könnte es an meinem Kabel liegen? Ich verwende in normales
Nullmodemkabel. ´Hat jemand das selbe Problem gehabt und/oder kann mir
helfen?
Patrick
@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
@Peter
Danke erstmal für die schnelle Antwort.
Ich habe alles nochmal neu heruntergeladen (V1.7) und kompiliert. Es
funktioniert aber trotzdem nicht. Hier kurz der Nachweis:
1
D:\fboot17>fboot17 /C1 /Ptest.hex
2
COM 1 at 115200 Baud: Connected
3
Bootloader VFFFFFFFF.FF
4
Error, wrong device informations
5
6
D:\fboot17>fboot17 /C1 /B19200 /Ptest.hex
7
COM 1 at 19200 Baud: Connected
8
Bootloader VFFFFFFFF.FF
9
Error, wrong device informations
10
11
D:\fboot17>fboot17 /C1 /B9600 /Ptest.hex
12
COM 1 at 9600 Baud: Connected
13
Bootloader VFFFFFFFF.FF
14
Error, wrong device informations
Ich habe jetzt mal die fastload.h, m644.asm und die m644.hex angehangen.
Vielleicht hab ich dort irgendwo was verpeilt.
Grüße,
Patrick
@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
@Peter
Ich hab hier einen "alten" sony vario notebook: intel P2, 64mb ram,
Windows2000 SP4, eine Com Schnittstelle, CPU Auslastung nach start von
fboot geht auf 30%, über MHZ konnte ich nichts rausbekommen (wird
irgendwie nicht angezeigt).
Gestern hab ich es auch schon auf einem Acer notebook (winXP, 1.5GHz,
512MB ram, intel centrino) probiert. -> gleiches Problem...
dabei muss ich aber sagen, dass bis gestern abend noch die version 1.4
auf dem µC war und der comport über einen usb2rs232 dongel emuliert
wurde...
Es wäre eigentlich wichtig, dass der loader auch über den vario läuft.
Da ich hier keinen anderen pc zur Verfügung habe.
Patrick
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.
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
@Tino + Peter
Es klappt, super! Es lag wirklich am Wotchdog. Danke für die schnelle
Hilfe.
Das einzige was noch komisch ist, ist dass ich ab dem 2ten mal den Rest
manuell machen muss. Woran könnte das liegen?
Patrick
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.
Hallo Peter,
ich war schon von deinem ersten Bootloader fasziniert.
Nutze diesen schon lange auf dem ATmega8.
Den aktuellen Bootloader würde ich gerne nutzen, da dieser noch kleiner
geworden ist.
Zum aktuellen Bootloader habe ich allerdings eine Frage.
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?
Danke für deine Hilfe,
Gruß Tobi
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
Hallo,
ich versuche im Moment vergeblich den Bootloader auf einem Mega32 zum
laufen zu bekommen. Im Anahng ist meine Konfiguration. Ich habe
eigentlich nur die Frequenz auf 16000000 umgestellt und die
Schnittstellen Pins auf die der Hardware UART gelegt. Das BOOTRST
Fuse-Bit habe ich auf 0 gesetzt und die BOOTSZ Fuses auf 11 für 256
Words. 10 für 512 Words habe ich auch schon getestet, weil ich da
verschiedene aussagen gelesen habe.
Das FBoot Tool bleibt mit diesem Output stehen 'COM 1 at 115200 Baud:'.
Dahinter dreht sich dann der Balken. Am RX-Pin vom Controller kann ich
dann die eingehenden Daten mit dem Oszi sehen. Jedoch Antwortet der
Controller nicht. Der Controller ist über einen MAX232 mit dem PC
verbunden. woran könnte das liegen? Ich habe alles anhand des Artikels
gemacht. Ich habe das Gefühl als würde der Bootloader nicht ausgeführt.
Hat da Jemand noch eine Idee?
Danke im Voraus!
Gruß
Benedikt
Hallo Peter,
vielen Dank für deine Antwort!
Leider bin ich erst gerade zum testen gekommen.
Ich habe sowohl die niedrigere Übertragungsrate als auch die 8MHz intern
Quarzfrequenz getestet. beides funktioniert leider nicht.
Der Bootloader Antwortet einfach nicht.
Hast du vielleicht noch eine Idee?
Im Anhang ist die Hex-Datei die ich aus dem Mega32 wieder ausgelesen
habe. Das sieht eigentlich gut aus, die Bootloader Adresse stimmt.
Gruß
Benedikt
Hallo Peter,
ich habe den (dummen) Fehler gefunden...
Es hatte nix mit dem Bootloader oder den Fuses zu tun.
Ich hatte einfach nur ein mini kleine Brücke von GND auf Reset gemacht.
Dann kann der AVR natürlich nicht laufen ;-) Danke trotzdem für deine
Antwort! Der Bootloader ist echt genial.
Gruß
Benedikt
habe jetzt auch mal den Bootloader ausprobiert, funktioniert bis auf ein
größeres Problem einwandfrei:
ich kann fboot.exe nur ein Mal verwenden, beim 2.Mal hängt es sich beim
Versuch zu connecten auf (Ausgabe bis zum "Propeller", dieser wird aber
nicht ein einziges Mal ausgegeben)
wenn ich Windows98 neu starte geht es wieder ein einziges Mal.
Wenn der Bootloader im AVR nicht aktiv ist und ich das Programm mit
Tastendruck abbreche kann ich es immer wieder starten und es propellert
Was tun?
@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
Ich opere hier mit einem ATMEGA324P herum und komme nicht zu Stuhle.
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
.equ BufferSize = (14*PageSize)
Die Pagesize ist 64 Bytes, so das bei 256 Bytes von 3f00 bis 3fff
da nur 4 hinen passen, also wie hängt das hier zusammen?
14*64 = 380 hex bzw. 896 dez Bytes.... ?
Gruß,
Holm
@Peter
Hallo Peter,
>Wie startest Du das Programm, DOS-Box oder im Explorer?
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? Hat zwar nix
mit deinem Programm zu tun aber vielleicht kennst du die Meldung ja.
Mit der DOS Box kann ich gut leben, würde mir aber wenn möglich die
Tipparbeit sparen wollen ...
>Hängt sich W98 richtig auf oder kannst Du die Task killen?
nein, nur die Task hängt, lässt sich problemlos stoppen
>Benutzt Du ne echte RS232 oder nen USB-RS232 Dongle?
eine echte RS232
>Welchen AVR benutzt Du?
mega8
>Probier mal nen kleineren AVR (<64k).>Hast Du keinen Rechner mit XP drauf?
nein, und beim nächsten Rechner werde ich mich Mal mit Linux
herumschlagen ...
Grüße
Walter
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
Das ON oder OFF kommt von sicher einem "ECHO" ohne Text. Muss man
"ECHO." schreiben (echo<Punkt>).
WIN9x macht eine DOS-Box die von einem BATCH geöffnet wird nicht
automatisch zu. Da muss ein "EXIT" ans Ende.
die Batchdatei enthält z.B. für Verify nur eine Zeile:
fboot /C1 /B2400 /Vdefault/hauszent.hex
ich habe festgestellt dass es ja jetzt V1.7 statt 1.4 gibt, es bleibt
aber beim gleichen Effekt. Komisch dass ich scheinbar der einzige bin
...??
Keiner mehr mit W98??
Pause bringt übrigens auch nix.
Ich habe jetzt mal fboot.c für Visual C 6.0 angepasst, das funktioniert
einwandfrei. Falls es jemand gebrauchen kann bitte melden ...
Könnte auch V1.7 anpassen, aber da müsste ich dann die Segmentierung
wieder zurückdefinieren :-(
@Werner
ECHO ist keins in der Batchdatei, nur der Aufruf von fboot.exe
Walter
Ich habe auch kein W98 mehr aber operiere auf einem W2K herum wenn ich
schon irgend eine Form Dos benutzen muß ...
Ich weiß, das etwas mit dem fboot17 nicht stimmt, wenn ich das Help
aufrufe steht da das ich die any key pressen soll, aber beenden kann ich
das nur wenn ich den Task von CMD abschieße. Konsoleeingaben sind
irgendwie blockert.
Gruß,
Holm
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-frontend-python
@Fabian
super das es jetzt auch einen Client für Linux für die 1.7 Version gibt.
Leider bekomme ich keinen connect. Der Bootloader futzt da es mit
Fboot17.exe klappt.
Ich verwende einen Mega162. Der Anschluss an den uC erfolgt über
/dev/ttyS0 auf einen Max232. Habe alle Baudraten probiert. Daran sollte
es auch nicht liegen da unter Win es mit 115k klappt.
Python ist nicht so mein Ding aber mir ist aufgefallen das der Mega162
nicht bei den Targets in deinem Programm enthalten ist. Aber bis zu
dieser Abfrage kommt er ja erst gar nicht.
Wäre nett wenn Du eine Idee hast wie ich einen connect bekomme.
@Peter Dannegger
Vielen Dank für den tollen Bootloader
Viele Grüße
Fred
So bin nun schon 2 schritte weiter.
In deinem Programm habe ich hinter den Passwortstring noch ein 0x00
gehängt dann hatte ich den gewünschten connect.
# try to connect to the bootloader
echo = False
password += chr(0xff)
password += chr(0x00)
pos = 0
Und dann noch das target ergänzt so das dann auch die Daten übertragen
wurden. Leider funktioniert das Programm im uC noch nicht :(
targets = {
0x1e9007: "ATtiny13",
0x1e910A: "ATtiny2313",
0x1e9206: "ATtiny45",
0x1e9205: "ATmega48",
0x1e9307: "ATmega8",
0x1e9403: "ATmega16",
0x1e9406: "ATmega168",
0x1e9502: "ATmega32",
0x1e9609: "ATmega644",
0x1e9802: "ATmega2561",
0x1e9404: "ATmega162",
}
Viele Grüße
Fred
So ich hab mal die beiden HEX-Files mit Ponyprog ausgelesen und
verglichen
dabei habe ich festgestellt das der letzte Datenblock nicht mit
übertragen wurde.
Leider habe ich wie gesagt von Python nicht viel Ahnung aber der Fehler
liegt
zwischen den Zeilen 280-313. Vieleicht ist dies auch der Fehler warum
das CRC nicht funktioniert.
Könnte das bitte mal jemand checken der was von Python versteht.
Vielen Dank
Fred
Hier die Programmzeilen 280-313
while True:
# get one byte
byte = hex_data[addr]
# escape and send it
if byte == self.ESCAPE or byte == 0x13:
self.send(self.ESCAPE)
byte |= self.ESC_SHIFT
self.send(byte)
bufferpos -= 1
if bufferpos == 0:
print "\b\b\b\b\b\b%05x" % (addr + 1),
sys.stdout.flush()
if not verify and self.receive(10) != self.CONTINUE:
print " failed!"
return 1
bufferpos = self.buffersize
addr += 1
if addr == len(hex_data):
print "\b\b\b\b\b\b%05x" % addr,
# send the end-record (0xA5, 0x80)
self.send_command(self.PROGEND)
if self.receive(10) == self.SUCCESS:
print " successful"
return 0
else:
print " failed!"
return 1
Hallo Fabian,
jetzt komm ich nicht mehr weiter da nicht nur am Ende sonder
zwischendurch auch 3 Fehler aufgetreten sind.
Zur veranschulichung gabe ich das Ergebniss von diff mal als Anhang
beigefügt.
Linke Spalte ist das HEX-File wenn ich mit fboot.exe übertrage und die
rechte Spalte ist die Fehlerhafte.
Ich hoffe es hilft um den Fehler zu finden.
Viele Grüße
Fred
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
Hallo Fabian,
ich hoffe Du hast nichts dagegen das ich in deinem Programm
rumgewurschtelt habe.
Jetzt läuft es bei mir endlich einwandfrei.
In Zeile 77 mußte ich ne kleine Pause einbauen sonst gibts kein connect.
Den sys.stdout.flush() beim Bufferende musste ich bei mir auch
rauswerfen da sonst Daten fehlen
Der eigentliche Fehler ist jedoch in Zeile 285ff
if (byte == self.ESCAPE) or (byte == 0x13):
Da Peter mit einer unsigned char Variablen arbeitet kommt dann
beim byte |= self.ESC_SHIFT unter Python ein ganz anderer Wert raus als
unter C.
Ich hoffe du entwickelst das Programm noch weiter da es wiklich Prima
ist.
so und nun einen guten Rutsch ins neue Jahr
vom Fred
Hallo Peter,
ich habe den Bootloader in v1.8 auf meinen Mega644 gespielt. Das hat
auch alles so weit funktioniert, nur leider startet das
Anwendungsprogramm nach dem flashen nicht.
Hast du da einen Tipp für mich?
Hallo,
ich habe ebenfalls grade den FBOOT18 auf einen ATmega8 gespielt.
Funktioniert alles einwandfrei.
Danke.
Kann mir evtl. jemand mit den Look Bits weiterhelfen?
Welche kann ich setzten, damit der Bootloader noch funktioniert?
Welche dürfen auf keinen Fall gesetzt werden?
Ich habe mir zwar das Datenblatt schon angesehen, steige aber nicht so
ganz durch.
Ich würde gerne den Bootloader und die Aplikation gegen Auslesen
schützen.
MfG Tobias
@Peter D
Peter ich habe deiner version 18 und die version 17a von AvrFreaks
compared. (Nur die teile vie lauft am Pc). Ich kan keiner differenz
sehe.
Ist das korrekt das die PC programm , ist die selber im 17a und 18 ??
Und das alle verbesserungen ist im die neye AVR target files layout ??
Dan funktioniert meiner devcpp port von 10.11.2007 auch (oder ??)
Danke fur die bootloader
mfg
Bingo aus Dänemark
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...
Hallo Assembler Cracks,
Bräuchte mal nen Tip wie ich es machen könnte das der Bootloader mit
einem Max 485 zusammenarbeitet.
Im Anhang ist mein Versuch die uart.inc anzupassen aber es klappt
einfach nicht :(
SCS_PORT und SCS sind in m16.asm definiert und sollen Senden und
Empfangen entsprechend umschalten.
Aber der SCS Pin bekommt einfach keine 5 Volt
Ich habe in C ein Testprogramm geschrieben das die Daten vom RS485
abholt und auf einen Disolay ausgibt. Und es werden Peda+0xFF empfangen
sodas der Bootloader ja eigentlich antworten sollte.
Kann da bitte mal jemand mit Assembler Erfahrung schauen woran es liegen
könnte.
;-----------------------------------------------------------------------
--
; Port definitions
;-----------------------------------------------------------------------
--
.equ STX_PORT = PORTD ;TX
.equ STX_DDR = DDRD
.equ STX = PD1
.equ SRX_PIN = PIND ;RX
.equ SRX_PORT = PORTD
.equ SRX = PD0
.equ SCS_PORT = PORTD ;RS485 Steuerpin
.equ SCS_DDR = DDRD
.equ SCS = PD2
;-----------------------------------------------------------------------
--
.include "fastload.inc"
;-----------------------------------------------------------------------
--
Vielen Dank
Fred
Hallo *,
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 ?
--AUSGABE beim Assemblieren:
AVRASM: AVR macro assembler 2.1.2 (build 99 Nov 4 2005 09:35:05)
Copyright (C) 1995-2005 ATMEL Corporation
bootload.asm(38): Including file 'C:\Programme\Atmel\AVR
Tools\AvrAssembler2\Appnotes\m1281mdef.inc'
bootload.asm(62): Including file 'fastload.inc'
fastload.inc(9): Including file 'fastload.h'
fastload.h(2): Including file 'compat.h'
fastload.h(3): Including file 'protocol.h'
FATAL ERROR: Too deeply nested macro calls(16)
Assembly failed, 0 errors, 0 warnings
--Ende der Ausgabe:
Gruss,
Ludger
Thread beobachten
Seitenaufteilung abschalten