www.mikrocontroller.net

Forum: Projekte & Code UART Bootloader ATtiny13 - ATmega644


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Peter Dannegger (peda)
Datum:
Angehängte Dateien:

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

Autor: Michael St. (keil)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Andreas (Gast)
Datum:

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

Autor: Michael St. (keil)
Datum:

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

Autor: Andreas K. (andie)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: SRX_DDR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SRX_DDR

Autor: Richard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann mir einer verraten wie ich den sourcecode kopilieren kann?

Habe es mit AVR Studio versucht ... kriege es aber leider nicht hin :-(

Autor: Richard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese Fehlermeldung bekomme ich:

AVRASM: AVR macro assembler 2.1.12 (build 87 Feb 28 2007 07:31:13)
Copyright (C) 1995-2006 ATMEL Corporation

C:\Documents and Settings\Admin\My Documents\AVR 
Projects\fastload_V14\ABAUD.INC(18): error: zl: Unknown instruction or 
macro
C:\Documents and Settings\Admin\My Documents\AVR 
Projects\fastload_V14\ABAUD.INC(18): error: syntax error, unexpected ','

Assembly failed, 2 errors, 0 warnings

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehe ich das richtig, dass AVRs mit mehr als 64k Flash (z. B. ATm128) 
nicht unterstützt werden?

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist es viel Aufwand, den ATM128 noch mit einzubauen?

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Der Techniker (_techniker_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

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

Schöne Grüße,
Techniker

Autor: Richard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann mir einer sagen was ich falsch mache?


C:\AVR_programm>FBOOT.EXE /PLED_mega32.hex
COM 1 at 115200 Baud: Connected
Bootloader V1.4
Target: 1E9502 ATmega32
Buffer: 1792 Byte
Size available: 32256 Byte
File LED_mega32.hex open failed !
CRC: o.k.
Elapsed time: 0.00 seconds

C:\AVR_PR~1>FBOOT.EXE /PC:\AVR_programm\LED_mega32.hex
COM 1 at 115200 Baud: Connected
Bootloader V1.4
Target: 1E9502 ATmega32
Buffer: 1792 Byte
Size available: 32256 Byte
File C:\AVR_programm\LED_mega32.hex open failed !
CRC: o.k.
Elapsed time: 0.00 seconds

C:\AVR_PR~1>



Die Datein liegen so:

C:\AVR_PR~1>dir
 Volume in Laufwerk C: hat keine Bezeichnung.
 Volumeseriennummer: 1819-D039

 Verzeichnis von C:\AVR_PR~1

15.07.2007  19:08    <DIR>          .
15.07.2007  19:08    <DIR>          ..
07.07.2007  16:20            16.441 FBOOT.EXE
15.07.2007  19:05             1.036 LED_mega32.hex
               2 Datei(en)         17.477 Bytes
               2 Verzeichnis(se), 66.330.902.528 Bytes frei

C:\AVR_PR~1>


Danke

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FBOOT.EXE /PC:\AVR_PR~1\LED_mega32.hex

so vielleicht?

Autor: Peter Dannegger (peda)
Datum:

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


Peter

Autor: Richard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Geht aber auch nicht :-(

C:\AVR>FBOOT.EXE /PLED_mega32.hex
COM 1 at 115200 Baud: Connected
Bootloader V1.4
Target: 1E9502 ATmega32
Buffer: 1792 Byte
Size available: 32256 Byte
File LED_mega32.hex open failed !
CRC: o.k.
Elapsed time: 0.00 seconds

C:\AVR>FBOOT.EXE /PC:\AVR\LED_mega32.hex
COM 1 at 115200 Baud: Connected
Bootloader V1.4
Target: 1E9502 ATmega32
Buffer: 1792 Byte
Size available: 32256 Byte
File C:\AVR\LED_mega32.hex open failed !
CRC: o.k.
Elapsed time: 0.00 seconds

C:\AVR>

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LED_mega32.hex

der dateiname ist immer noch 10 buchstaben lang ;)

Autor: Simon K. (simon) Benutzerseite
Datum:

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

Autor: Richard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Asoo, Dateiname ... ich dachte Pfad^^. Danke jetzt geht es.

Hab aber folgendes Problem:

Habe erfolgreich folgendes Programm draufgespielt:
#include <avr/io.h>

// Sollte normalerweise schon im Makefile definiert sein.
// In dem Fall hier einfach löschen.
#define F_CPU 11059200
        
#define BAUD        2400UL
#define UBRR_BAUD   ((F_CPU/(16UL*BAUD))-1)

void ioinit(void);
void delay_ms(unsigned int ms);
void uart_init(void);



// USART initialisieren
void uart_init(void)
{
    // Baudrate einstellen (Normaler Modus)
    UBRRH = (uint8_t) (UBRR_BAUD>>8);
    UBRRL = (uint8_t) (UBRR_BAUD & 0x0ff);

    // Aktivieren von receiver und transmitter
    UCSRB = (1<<RXEN)|(1<<TXEN);

    // Einstellen des Datenformats: 8 Datenbits, 1 Stoppbit
    UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0);
}



// Hauptprogramm
int main(void) {
    unsigned char i;   

    ioinit();   

    uint8_t buffer;

    // USART initialisieren
  //  uart_init();

   
    // Endlosschleife
    while (1) {
        PORTD ^= (1 << PD7);
       
        // Eine Sekunde warten
        delay_ms(1000);
    }   

    return 0;
}

// Initialisierung
void ioinit(void)
{
    DDRD = 0xff;    // PortB als Ausgang deklarieren
    PORTD = 0x00;   // Ports auf LOW schalten
}

// Warteschleife
void delay_ms(unsigned int ms)
{
    unsigned int zaehler;
   
    while (ms) {
        zaehler = F_CPU / 5000;
       
        while (zaehler) {
            asm volatile("nop");
            zaehler--;
        }
        ms--;
    }
}



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:
;-------------------------------------------------------------------------
;                               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"
;-------------------------------------------------------------------------

Autor: Simon K. (simon) Benutzerseite
Datum:

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

Beides.

Autor: Richard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe ein bisschen rumprobiert ... habe jetzt andere pins benutzt ... 
das komische ist aber .. ich kann nur einfach eine hex draufspielen.
C:\AVR>FBOOT.EXE /PLED.hex
COM 1 at 115200 Baud: Connected
Bootloader V1.4
Target: 1E9502 ATmega32
Buffer: 1792 Byte
Size available: 32256 Byte
Program LED.hex: 0000 - 016B successful
CRC: o.k.
Elapsed time: 0.33 seconds

C:\AVR>FBOOT.EXE /PLED.hex
COM 1 at 115200 Baud: /
Aborted

C:\AVR>FBOOT.EXE /PLED.hex
COM 1 at 115200 Baud: -
Aborted

C:\AVR>FBOOT.EXE /PLED.hex
COM 1 at 115200 Baud: |

Bei allen anderen versuchen geht es nicht, wenn ich schon einmal 
gebrannt habe. ;-(

Muss ich irgendwas an den Security bits umstellen?

Autor: Richard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Startet sofort das Programm ... nicht den Bootloader. Wieso? Wie 
muss ich mein Programm ändern ... damit es immer funktioniert?

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Richard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahhh danke für die Info.
Welche Bits sind es in PonyProg sprache?

http://mikrocontroller.cco-ev.de/php/counter/count...


Heißt das ich muss bei BootLock01 ein häckchen machen und bei BOOTRST ??

Danke im voraus.

Autor: Gasti (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Andreas K. (andie)
Datum:

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

Autor: Richard Brose (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas Kasper

Ich bin dabei eine Win32 Anwendung zu machen mit GUI etc.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Stefan (Gast)
Datum:

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


---

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

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

Autor: Stefan (Gast)
Datum:

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

Autor: Andreas B. (andreasb)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der ATmega48 gehört bezüglich Bootfunktion zu den ATtinys.

Daher gibts kein Secondbootstart.

Nimm daher das T45.ASM als Vorlage.


Peter

Autor: Andreas B. (andreasb)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Andreas B. (andreasb)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Andreas B. (andreasb)
Datum:

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

Autor: Andreas B. (andreasb)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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


Peter

Autor: Andreas B. (andreasb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke!
Das wars!


mfg Andreas

Autor: Andreas B. (andreasb)
Datum:
Angehängte Dateien:

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

Autor: Andreas B. (andreasb)
Datum:
Angehängte Dateien:

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

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du musst natürlich an den Anfang des Bootloader springen, nicht nach 
Null.

Autor: Werner B. (Gast)
Datum:

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

Autor: Andreas B. (andreasb)
Datum:

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

Autor: Andreas B. (andreasb)
Datum:

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

Autor: Tobias W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
vm-debian-testing:~/tmp# make
gcc -Wall -g -c main.c -o main.o
main.c: In function 'readhex':
main.c:327: warning: pointer targets in passing argument 1 of 'sscanhex' differ in signedness
main.c:330: warning: pointer targets in passing argument 1 of 'sscanhex' differ in signedness
main.c:333: warning: pointer targets in passing argument 1 of 'sscanhex' differ in signedness
main.c:339: warning: pointer targets in passing argument 1 of 'sscanhex' differ in signedness
gcc -Wall -g -c readargs.c -o readargs.o
readargs.c: In function 'readargs':
readargs.c:46: warning: conversion lacks type at end of format
readargs.c:46: warning: too many arguments for format
gcc -Wall -g main.o readargs.o -o main
vm-debian-testing:~/tmp# ./main
/dev/ttyS0 at 115200 Baud: \
Connected
Bootloader V1.4
Target: 1E9307 ATmega8
Buffer: -2 Byte
Size available: -2 Byte
CRC: o.k.
Elapsed time: 0.03 seconds
vm-debian-testing:~/tmp#

Autor: Andreas B. (andreasb)
Datum:
Angehängte Dateien:

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

Autor: Tobias W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
danke für Die schnelle Antwort, ich hab nen Atmega8. Und hier die 
Debug-Daten.
Grüsse Tobias

vm-debian-testing:~/tmp2/debug# ./main
/dev/ttyS0 at 115200 Baud: |
Connected
->--------------
->168
->3
->1
->4
->170
Bootloader V1.4
->--------------
->168
->4
->30
->147
->7
->170
Target: 1E9307 ATmega8
->--------------
->168
->3
->3
->192
Buffer: -2 Byte
->--------------
->170
->168
->4
->30
->170
->-1
Size available: -2 Byte
CRC: o.k.
Elapsed time: 0.00 seconds
vm-debian-testing:~/tmp2/debug#

Das sagt Peters Programm:
E:\avr\fastboot1.4>fboot
COM 1 at 115200 Baud: Connected
Bootloader V1.4
Target: 1E9307 ATmega8
Buffer: 960 Byte
Size available: 7680 Byte
CRC: o.k.
Elapsed time: 0.11 seconds

E:\avr\FASTBO~1.4>

Autor: Andreas B. (andreasb)
Datum:
Angehängte Dateien:

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

Autor: Tobias W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
fast...
vm-debian-testing:~/tmp3# ./main
/dev/ttyS0 at 115200 Baud: \
Connected
Bootloader V1.4
Target: 1E9307 ATmega8
Buffer: 960 Byte
Size available: -2 Byte
CRC: o.k.
Elapsed time: 0.01 seconds
vm-debian-testing:~/tmp3#

Autor: Andreas B. (andreasb)
Datum:

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

Autor: Christian (Gast)
Datum:

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

Autor: Jochen (Gast)
Datum:

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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hast Du bidirektionale RS-485 oder unidirektionale mit Umschaltung der 
Sende- / Empfangsrichtung ?

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Halbduplex - unidirektional.

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

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

Autor: Tobias (Gast)
Datum:

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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

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

Autor: Karsten Donat (karstendonat)
Datum:
Angehängte Dateien:

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

Autor: Karsten Donat (karstendonat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: David Herrmann (davherrmann)
Datum:

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

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

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

Autor: Stefan (Gast)
Datum:

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


---

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Stefan (Gast)
Datum:

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


---

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
COM 2 at 4800 Baud: Connected
Bootloader V1.6
Target: 1E9308
Buffer: 960 Byte
Size available: 7680 Byte
Program test.hex: 00000 - 0022F successful
CRC: o.k.
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):
:10000000EC0102C02196E8DF88818823D9F7DF91CF
:10001000CF910895CF93DF93EC0101C0DDDFFE01A6
:10002000219684918823D1F7DF91CF910895FFCF56
:10003000D2E0DEBFCDBF10E0A0E6B0E0E0E3F2E04A

Die soll .hex Datei (compiliert):
:1000000014C02EC02DC02CC05BC02AC029C028C07F
:1000100027C026C025C05FC088C022C021C020C024
:100020001FC01EC01DC01CC01BC011241FBECFE5B9
:10003000D2E0DEBFCDBF10E0A0E6B0E0E0E3F2E04A
Erst ab der 4ten Zeile sind sie wieder identisch

Was ist da passiert?

PS:
case 0x1e9308: s = "ATmega8535"; break;
für die fboot.c ;)

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Mega8535 ist nun mal kein Maga8.
z.B. die Interruptvektoren ganz am Anfang sind unterschiedlich.

Da musst du die Datenblätter vergleichen.

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Johannes (Gast)
Datum:

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

Autor: F. Kriewitz (freddy436)
Datum:

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

Autor: Johannes (Gast)
Datum:

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

Autor: F. Kriewitz (freddy436)
Datum:

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

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe es nun mit dem 1.4er versucht, jetzt brennter garnichts mehr ;)
Immer failed...
COM 2 at 4800 Baud: Connected
Bootloader V1.4
Target: 1E9308
Buffer: 64 Byte
Size available: 7680 Byte
Program test.hex: 0000 - 1300 failed !
Elapsed time: 21.59 seconds

Das /D lässt fboot anscheinend auch nur festfahren.

Autor: Karsten Donat (karstendonat)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Karsten Donat (karstendonat)
Datum:

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

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

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

Autor: Karsten Donat (karstendonat)
Datum:

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

Autor: F. Kriewitz (freddy436)
Datum:
Angehängte Dateien:

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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat sich schon mal jemnad die Mühe gemacht, den PC-Teil in Delphi 
umzusetzten ?

Autor: Karsten Donat (karstendonat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin noch dabei.

Karsten

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

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

Autor: Tom (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Tom (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ah ok, danke für die Erklärung

Autor: Der Techniker (_techniker_)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Der Techniker (_techniker_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich arbeite an meinem alten Desktop -> also echte RS232..

Autor: Tom (Gast)
Datum:

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

Autor: Der Techniker (_techniker_)
Datum:

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

Autor: Dirk Schmidt (disc)
Datum:

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

Autor: F. Kriewitz (freddy436)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versuchs mal mit einer niedrigeren BAUD rate (/B9600)

Autor: Dirk Schmidt (disc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@freddy436

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

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

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

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

Autor: Bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur einer kleine dinge mehr

Die program unterstutzt auch lange dateinahme

/Bingo

Autor: Bingo (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Bingo (Gast)
Datum:

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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... und ab Com9 muss es "\\.\Com9" heißen.

Bei Com1..Com8 stört der Präfix auch "\\.\" nicht.

Autor: Bingo (Gast)
Datum:

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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gast

Du hast recht , das ist einer Native Windows dinge

/Bingo

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Bingo (Gast)
Datum:

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

Autor: Joerg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
.nolist
.include "tn85def.inc"

.equ  CRC      = 17
.equ  VERIFY      = 15
.equ  ONEWIRE      = 3

;-------------------------------------------------------------------------
;                               Port definitions
;-------------------------------------------------------------------------
.equ    STX_PORT        = PORTB
.equ    STX_DDR         = DDRB
.equ    STX             = PB2

.equ    SRX_PIN         = PINB
.equ    SRX_DDR         = DDRB
.equ    SRX_PORT        = PORTB
.equ    SRX             = PB2
;-------------------------------------------------------------------------
.include "fastload.inc"
;-------------------------------------------------------------------------

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Gruß Hagen

Autor: Joerg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
.nolist
.include "fastload.h"
.listmac
.list

.ifndef BootFuse
  .org  0x0000
  rjmp  init
.endif

  .org  BootStart
init:

oder habe ich was übersehen, wo der "rjmp init" sonst gemacht gehört?

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Joerg (Gast)
Datum:

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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Karsten

Gibt's denn schon was Neues in bezug auf Deine Delphi-Portierung ?

Autor: Der Techniker (_techniker_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..und ich warte immer noch auf die Protokoll-Doku..  ;)

Autor: Joerg (Gast)
Datum:

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

Autor: Malte __ (malte) Benutzerseite
Datum:

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

Autor: Alexander (Gast)
Datum:

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

Autor: Joerg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also meine Einstellungen für einen ATtiny85 1-wire schaut so aus:
.nolist
.include "tn85def.inc"

.equ  CRC        = 17    ; 17 = additional code size
.equ  VERIFY      = 15
.equ  ONEWIRE      = 3

;-------------------------------------------------------------------------
;                               Port definitions
;-------------------------------------------------------------------------
.equ    STX_PORT        = PORTB
.equ    STX_DDR         = DDRB
.equ    STX             = PB2

.equ    SRX_PIN         = PINB
.equ    SRX_DDR         = DDRB
.equ    SRX_PORT        = PORTB
.equ    SRX             = PB2
;-------------------------------------------------------------------------
.include "fastload.inc"
;-------------------------------------------------------------------------

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

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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.equ  ONEWIRE      = 3


Peter

Autor: Alexander (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Eindrahtmodus funktioniert jetzt :-)
Es lag an:
.equ  ONEWIRE      = 3

Danke für Eure Hilfe

Autor: Kurt (Gast)
Datum:

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

Autor: Stefan (Gast)
Datum:

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


---

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

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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und schon den ersten Fehler gefunden:

...
5.
Abfrage Useflashgrö0e:

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

Peter

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

Bewertung
0 lesenswert
nicht lesenswert
CRC vergessen.


Peter

Autor: Kurt (Gast)
Datum:

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

Autor: Karsten Donat (karstendonat)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Elektrikser (Gast)
Datum:

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

Autor: Kurt (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Kurt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Peter.......
Der Wahnsinn. Der Loader läuft jetzt mit ONEWIRE und das auch noch super 
schnell!!!!
Vielen Dank für deine Geduld.

Autor: Der Techniker (_techniker_)
Datum:

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

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

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

Autor: Der Techniker (_techniker_)
Datum:
Angehängte Dateien:

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

Autor: J.L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?
outportb(ComPort+4, 0x00);
..macht keinen Unterschied zu..
outportb(ComPort+4, 0x01);

Grüsse,
Jochen

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Dirk (Gast)
Datum:

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

Autor: Der Techniker (_techniker_)
Datum:

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

Autor: Der Techniker (_techniker_)
Datum:

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

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

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

Autor: Jogi (Gast)
Datum:

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

Autor: Andreas K. (andie)
Datum:

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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
C:\boot>fboot /C1 /Pmain.hex
COM 1 at 115200 Baud: Connected
Bootloader VFFFFFFFF.FF
Target: FFFFFFFF
Buffer: -1 Byte
Size available: -1 Byte
CRC: error !
Elapsed time: 0.55 seconds

und für V1.7
C:\boot>fboot17 /C1 /Pmain.hex
COM 1 at 115200 Baud: Connected
Bootloader VFFFFFFFF.FF
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

Autor: Der Techniker (_techniker_)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

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

Bewertung
0 lesenswert
nicht lesenswert
@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:
D:\fboot17>fboot17 /C1 /Ptest.hex
COM 1 at 115200 Baud: Connected
Bootloader VFFFFFFFF.FF
Error, wrong device informations

D:\fboot17>fboot17 /C1 /B19200 /Ptest.hex
COM 1 at 19200 Baud: Connected
Bootloader VFFFFFFFF.FF
Error, wrong device informations

D:\fboot17>fboot17 /C1 /B9600 /Ptest.hex
COM 1 at 9600 Baud: Connected
Bootloader VFFFFFFFF.FF
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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Patrick (Gast)
Datum:

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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ups meinte natürlich sony vaio....

Patrick

Autor: Tino (Gast)
Datum:

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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tino

Ich habs gleich mal probiert. Das Problem besteht jedoch weiterhin...

Grüße,
Patrick

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

Bewertung
0 lesenswert
nicht lesenswert
Hier mal ein Screenshot der Fusebits, damit hat es bei mir funktioniert.

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Patrick (Gast)
Datum:

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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, möchte mich für die dumme Frage entschuldigen. Wer lesen kann ist 
klar im Vorteil. Also vielen Dank nochmal für die Lösungsvorschläge!!

Patrick

Autor: Tino (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß gerade nicht was du meinst, was musst du manuell machen?

Autor: Vladimir Yershov (Firma: INELT) (kabron)
Datum:

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

Autor: Tobi (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Benedikt Patt (Gast)
Datum:
Angehängte Dateien:

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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt

setz mal die Baudrate runter:
fboot17 -b9600


Schwingt Dein Quarz?

setz mal die Fuses auf internen Takt 8MHz


Peter

Autor: Benedikt Patt (Gast)
Datum:
Angehängte Dateien:

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

Autor: Benedikt Patt (Gast)
Datum:

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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es schon 'was Neues von der Delphi-Umsetzung des PC-Teils ?

Autor: Walter (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: holm (Gast)
Datum:

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

Autor: Walter (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Werner B. (Gast)
Datum:

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

Autor: Walter (Gast)
Datum:

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

Autor: holm (Gast)
Datum:

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

Autor: Fabian G. (kjion) Benutzerseite
Datum:
Angehängte Dateien:

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

Autor: Friedhelm Altmann (Gast)
Datum:

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

Autor: Friedhelm Altmann (Gast)
Datum:

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

Autor: Friedhelm Altmann (Gast)
Datum:

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

Autor: Friedhelm Altmann (Gast)
Datum:
Angehängte Dateien:

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

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

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

Autor: Friedhelm Altmann (Gast)
Datum:
Angehängte Dateien:

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

Autor: Michael (Gast)
Datum:

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

Autor: Tobias (Gast)
Datum:

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

Autor: Bingo (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Daniel M. (usul27)
Datum:

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

Autor: Friedhelm Altmann (Gast)
Datum:
Angehängte Dateien:

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

Autor: Ludger (Gast)
Datum:

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

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

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

Autor: Andreas K. (andie)
Datum:

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

Autor: Ludger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter

Danke fuer die prompte Antwort. Assemblieren tuts es jetzt einwandfrei. 
Allerdings habe ich bei meinem 1281er noch nicht geschafft den 
Bootloader zur Kommunikation mit dem PC zu bringen. Beim Testen habe ich 
dann vermutlich versehentlich die Fuses verstellt und nachdem ich sie 
mit externem Takt wieder auf die Defaultwerte gesetzt habe, tut sich gar 
nichts mehr. Aber das ist eine andere Baustelle.

Bei meinem 644er funktioniert alles tadellos.

Gruss,
Ludger

Autor: Friedhelm Altmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Andreas Kasper

macro  IOPortInit
  sbi  SRX_PORT, SRX
  sbi  STX_PORT, STX
  sbi  STX_DDR, STX
  cbi  SCS_PORT, SCS
  sbi  SCS_DDR, SCS
.endmacro

Ja das habe ich.

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

Sind den die Ändrungen in der uart.inc so OK?

Bin mir nicht so sicher ob nicht eine kleine Pause zwischen dem 
Umschalten von RX -> TX erfolgen muss?

Die Übertragungsrate ist momentan noch auf 19200 Baud eingestellt und 
ist wohl unkritisch.

Vieleicht noch eine Idee?

Viel Grüße

Fred

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Friedhelm Altmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,
hallo Andi

erstmal vielen Dank für die Antwoten.

habe meinen Fehler nun gefunden die Sendefunktion war zu langsam für den 
Bootloader weil ich jedes Zeichen einzeln gesendet habe und immer 
zwischen TX und RX umgeschaltet habe.

Jetzt bekomme ich die gewünschte 0xA6 als Antwort.

Mit der PC Software das war mir klar. Mein Ziel ist es einen RS-485 Bus 
mit mehreren Mega 16 und einem Mega 162 als Bindeglied zwischen PC und 
RS-485 Bus zu realisieren.

Der Mega 162 soll dann quasi die PC Software beinhalten um die Mega 16 
mit den Updates zu versorgen.

Hoffe mal das ich den Rest dann auch noch hinbekomme.

Viele Grüße

Fred

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat das jemand bereits auf einen ATmega als >Programmer< umgesetzt ?
Mir schwebt da ein Mega mit einem SD-Kartenslot vor, in einem Gehäuse 
ähnlich einem Tastkopf; so dass man den Code später mit einem sehr 
portablen Programmer lokal injizieren kann.

Autor: Andreas K. (andie)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
für 485 müsste es doch auch gehen.....

die meisten 485-USB machen doch das automatisch und verhalten sich wie 
eine 232 schnittstelle , oder??
auf ATmegaseite brauch er ja nur auf empfang stehen

Autor: Ludger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter

nachdem ich meinen 1281'er wieder zum Leben erweckt habe funktioniert 
der Bootloader nun auch dort.
Herzlichen Dank fuer die neue FASTLOAD.H

Ludger

Autor: Karsten Donat (karstendonat)
Datum:

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

Autor: Karsten Donat (karstendonat)
Datum:

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

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo *,

ich habe den fboot18 von Peter mal nach WinAVR uebersetzt.

@Peter
Ich wollte zunaechst das ganze Projekt konvertieren, bin jedoch mangels 
WinAVR Assembler Kenntnissen an der Universalitaet deines Bootloaders 
gescheitert. Dann habe ich alles, was mein 1281'er benoetigt in eine 
Datei kopiert und das dann konvertiert. Ich hoffe Du bist nicht allzu 
veraergert :-)

Herzliche Gruesse,
Ludger

Autor: Bootloaderneuling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, für vollwertigen ISP-Ersatz müsste mir das Teil auch den EEPROM mit 
meinen Daten beschreiben können! Ist diese Funktion vielleicht geplant?

Autor: Karsten Donat (karstendonat)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

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

Bewertung
0 lesenswert
nicht lesenswert
@Peter D

Hier ist einer source im TurboC , für 9bit kommunikation.

mfg
Bingo

Autor: Peter Dannegger (peda)
Datum:

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

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo *,

ich besitze weder den Borland noch den Dev-C++. Habe aber schon lange 
ein cygwin mit GCC und MINGW. Damit habe ich Bingos fboot17a uebersetzt.
Sourcen, Executable und makefile liegen bei.

Gruss,
Ludger

Autor: Raik A. (raik)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Bootloaderneuling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Den EEPROM benutzt man ja dazu, Werte zu speichern, die noch nicht zur
Programmierzeit bekannt sind"

Nun dem muß ich mal ganz entschieden widersprechen. Mein EEPROM dient 
z.B. der Initialisierung des RAMs durch ein einfaches Copy und so wäre 
es durchaus sinnvoll den EEPROM auch vorab beschreiben zu können. Nun 
gut, ist halt nicht drin- aber eben deshalb ist es leider auch kein 
vollwertiger ISP-Ersatz.

Autor: Peter Dannegger (peda)
Datum:

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

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hat hier vielleicht schon jemand eine Portierung des FBoot nach .NET 
probiert? Ich möchte einen Bootloader in ein kleines 
Applikationsframework integrieren und da ungern ein externes Tool für 
aufrufen. Bisher hatte ich mit dem Fleury Bootloader gearbeitet, aber 
dieser hier ist schön kompakt. Gibts zu dem Protokoll evtl. etwas Prosa 
oder muß ich alles aus dem Quelltext rauslesen?

Autor: Peter Dannegger (peda)
Datum:

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

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, das habe ich in den wenigen hunderten Beiträgen übersehen... Der 
Link könnte auch in den Wiki Beitrag zu deinem Bootloader rein.

Autor: Dirk Schmidt (disc)
Datum:

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

Autor: Thomas V. (thomas_v)
Datum:

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

Autor: Dirk Schmidt (disc)
Datum:
Angehängte Dateien:

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

Autor: Jojo S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke, das sieht doch sehr brauchbar aus.

Autor: Dirk Schmidt (disc)
Datum:
Angehängte Dateien:

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

Autor: Jojo S. (jojos)
Datum:

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

Autor: Dirk Schmidt (disc)
Datum:

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

Autor: Jojo S. (jojos)
Datum:

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

Autor: Jojo S. (jojos)
Datum:

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

Autor: Jojo S. (jojos)
Datum:

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

Autor: Jojo S. (jojos)
Datum:

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

Autor: David Herrmann (davherrmann)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Jojo S. (jojos)
Datum:

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

Autor: David Herrmann (davherrmann)
Datum:

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

Grüße
David

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Jojo S. (jojos)
Datum:

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

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich hab das mal nach dem PDF versucht für einen ATMEGA8 zu komplilieren, 
bekomme aber Massen an Fehlern heraus. Ich hab die Originaldateien aus 
dem ZIP verwendet ohne etwas zu ändern, dann die include und die 
Assembler EXE dazu und heraus kommt:

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

Creating   'm8.hex'

Assembling 'm8.asm'
Including  'm8def.inc'
Including  'fastload.inc'
Including  'compat.h'
Including  'fastload.h'
Including  'abaud.inc'
abaud.inc(25) : error : Unknown instruction opcode
abaud.inc(32) : error : Unknown instruction opcode
Including  'password.inc'
Including  'checkcrc.inc'
Including  'verify.inc'
Including  'message.inc'
Including  'progmega.inc'
Including  'uartcrc.inc'
uartcrc.inc(7) : error : Unknown instruction opcode
uartcrc.inc(10) : error : Unknown instruction opcode
uartcrc.inc(21) : error : Unknown instruction opcode
uartcrc.inc(46) : error : Unknown instruction opcode
uartcrc.inc(57) : error : Unknown instruction opcode
uartcrc.inc(60) : error : Unknown instruction opcode
m8.asm(119): warning: A .db segment with an odd number of bytes is 
detected. A z
ero byte is added.
m8.asm(14) : error : Symbol is already defined by the .EQU directive
fastload.h(81) : error : Undefined variable referenced
fastload.h(88) : error : Syntax error
fastload.h(90) : error : Syntax error
fastload.h(92) : error : Syntax error
fastload.h(94) : error : Syntax error
fastload.inc(17) : error : Relative branch out of reach
fastload.inc(74) : error : Relative branch out of reach
fastload.inc(120) : error : Syntax error
fastload.inc(121) : error : Syntax error
fastload.inc(122) : error : Syntax error
fastload.inc(123) : error : Syntax error

Assembly complete with 20 errors

Deleting   'm8.hex'
Kennt jemand das Problem? Bin nicht sooo firm mit Assembler.
Danke sehr vorab, Gruss
Thomas

Autor: Peter Dannegger (peda)
Datum:

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

Autor: gamecounter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich wollte nun auch endlich mal nen bootloader verwenden, weil ich auf 
meinem neuen PC nur eine RS232 hab, und mir das umstecken zwischen isp 
und seriellem port mittlerweile etwas lästig ist.

Ich hab mich an die toll geschriebene Anleitung von Karsten gehalten. 
(nur das hex hab ich mit pony prog geflasht)

Hat auch alles geklappt, nur der mikrocontroller antwortet einfach 
nicht.
fboot.exe mit meinem hex als parameter ausgeführt, und das "kreuz" dreht 
sich. contoller aus und wieder an, doch es tut sich nix.

Das Programm is definitiv im Flash.

Ich hab keine Ahnung wo ich den Fehler suchen soll. Ich weiß, is nicht 
grad ne tolle fehlerbeschreibung, aber ... vielleicht hat ja jemand ne 
idee

vielen dank bereits im voraus

gamecounter

Autor: David Herrmann (davherrmann)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: David Herrmann (davherrmann)
Datum:

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

Autor: Markus B. (wolframator)
Datum:

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

Autor: Malte __ (malte) Benutzerseite
Datum:

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

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

Bewertung
0 lesenswert
nicht lesenswert
@Peda:

Vielen Dank für diesen Bootloader. Habe diesen auch ohne Probleme
auf einem Mega16 zum Laufen gebracht.
(kleine Änderung wegen dem nicht vorhandenen WDCE bit)

@Dirk Schmidt:

Habe mir die Mühe gemacht und noch ein paar Features hinzugefügt:

1. Auswahl des Comports
2. Texteingabe des Passwortes möglich

(kann man alles noch erweitern, für mich langte es erst mal ;-) ,
bin trotzdem für konstruktive Hinweise zu haben)

(getestet nur mit COM1 bis COM4;
hatte die FTDI-Wandler gerade nicht zur Hand)

Viel Spass

Gruß Sven

Autor: TobyTetzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sven,

habe grade deine Programmdateien in VS2005 importiert.
Obwohl ich mich noch nicht mit VS2005 auskenne, versuche es erst noch zu 
lernen,
geht alles einwandfrei, sogar auf Com5 mit einem USB->RS232 Kabel.

Gruß Toby

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

Bewertung
0 lesenswert
nicht lesenswert
Überarbeitung der Version Bootloader_CSharp_adv.zip:

Neue Version: Bootloader_CSharp_adv_v2.zip

1.  Auswahl des Comports
1.1 Comport wird jetzt automatisch vom System ermittelt
2.  Texteingabe des Passwortes möglich
3.  Baudrate einstellbar
    (Standard Baudraten vorbelegt;
     keine automatische Ermittlung)

(getestet mit Hardware COM1 bis COM2;
 Prolific 2303 USB-Seriell Adapter funktioniert;
 FTDI-Wandler gerade nicht zur Hand)

Viel Spass

Gruß Sven

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Prolific 2303 USB-Seriell Adapter funktioniert;

Ports COM 14 + COM 15 funktionieren auch ;-)

Gruß Sven

Autor: Hagen Re (hagen)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
  sbiw  yh:yl, TOLERANCE
  adiw  yh:yl, 2 * TOLERANCE
  brcc  _aba2      ; outside tolerance

kann es sein das zwischen sbiw und adiw noch ein Branchbefehl fehlt ? 
Das wäre das Einigste was aus meiner Sicht noch einen Sinn ergäbe. Wenn 
nicht dann müsste ein einfaches adiw  y,3 das gleiche Resultat ergeben.

Gruß Hagen

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um es mal in einer Hochsprache zu erläeutern:

Man kann schreiben:

  if( (i >= MIN) && i <= MAX )


Man spart sich aber einen Vergleich, wenn man es so macht:

  if( (i - MIN) <= (MAX - MIN) )



Simulier den Code einfach mal mit verchiedenen Werten.


Peter

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter,

Danke ich habs jetzt kapiert. Entscheidend ist ja die letzte Operation 
und es ist eben nicht egal op man 2*TOLERANCE addiert oder nur 
TOLERANCE. Ansonsten recht clever das Ganze und wieder mal was dazu 
gelernt.

Gruß Hagen

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

Bewertung
0 lesenswert
nicht lesenswert
Neue Version: Bootloader_CSharp_adv_v3.zip

1.  Speicherung der möglichen Einstellungen in
    "Applikationspfad\Settings.cfg";
    beim Starten der Anwendung werden die letzten
    Einstellungen aus Settings.cfg geladen !
2.  Auswahl des Comports
2.1 Comport wird jetzt automatisch vom System ermittelt
3.  Texteingabe des Passwortes möglich
    (Passwort wird mit in der Datei Settings.cfg (Klartext) abgelegt)
4.  Baudrate einstellbar
    (Standard Baudraten vorbelegt;
     keine automatische Ermittlung)

(erneut getestet mit Hardware Schnittstelle COM1 bis COM2)

So, dies war vorerst meine letzte Version.

Viel Spass

Gruß Sven

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

habe den loader auf meinem m168 ausprobiert und funktioniert super.
Leider habe ich auch das problem das ich Variablen werte ins eeprom 
auslagere die ich seperat in den mega brennen muß.
Frage an dich Peter, ist angedacht, das du das eeprom schreiben noch 
implementierst? Das würde dann dein Programm vollenden.

vielen Dank

mfg.

chris

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris wrote:
> Leider habe ich auch das problem das ich Variablen werte ins eeprom
> auslagere die ich seperat in den mega brennen muß.

Kannst Du das irgendwie erklären, warum der EEPROM separat gebrannt 
werden muß ?


Peter

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

z.b. habe ich hier ein funktranceiver den ich in verschiedenen Modes 
verwende. Also FSK, GMSK, MSK usw. Diese auch in verschiedenen speed 
modes und ISM Bändern. Habe dadurch einen Parametersatz von über 100 
Werten. Um Speicherplatz zu sparen lade ich einfach je mach mode den 
passenden Parametersatz aus dem EEPROM in ein array. Auch ein "default" 
Parametersatz ist vorhanden den ich nur lade wenn nix mehr geht. Also so 
ne Art "Werkseinstellung".
Wenn ich das alles mit #if's machen würde kostet das mehr Platz im 
flash.

Vieleicht hätte man es auch anders machen können, aber habs halt so 
gemacht :-)


BTW: kann man den onewire mode auch deaktivieren? Beißt sich irgendwie 
mit meiner Hardware wenn ich den Transceiver chip am M168 hängen habe. 
Ohne Transceiver chip flash er super im rs232 mode.

thx

mfg.
chris

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris wrote:

> Wenn ich das alles mit #if's machen würde kostet das mehr Platz im
> flash.

Nein, #if's kosten kein Byte Speicherplatz mehr, da sie bereits zur 
Compilezeit ausgewertet werden.
Sonst würde Dir ja auch der EEPROM schnell ausgehen.

> Vieleicht hätte man es auch anders machen können, aber habs halt so
> gemacht :-)

Hab leider keine Zeit, das einzubauen.
Bin aber grad dabei nen API-Call zu entwickeln, damit der Flash aus der 
Applikation heraus programmiert werden kann.
Brauche nämlich mehr Datenspeicher, als der EEPROM groß ist.


> BTW: kann man den onewire mode auch deaktivieren? Beißt sich irgendwie
> mit meiner Hardware wenn ich den Transceiver chip am M168 hängen habe.

Ein Deaktivieren ist nicht nötig, solange das Paßwort nicht reinkommt, 
ist der Bootloader muxmäuschenstill.
Er kann also die Applikation garnicht stören.
Man hat nur die 0,3s zusätzliche Resetzeit, das ist alles.

Du  mußt außerdem den Bootloader nicht mit auf die UART legen, jede 
anderen 1 oder 2 Pins gehen.


Peter

Autor: Thomas Space (space)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte mich bei Peter für den Bootloader, insbsondere für den 
Singlewiremode, bedanken. Der Loader löst mein Problem, wie ich meinen 
Eigenbau RC-Empfänger, welcher tief in der engen Rumpfröhre steckt, 
zukünftig updaten kann.

Funzt super:
C:\TEMP>FBOOT18.EXE   /Vrx.hex
COM 1 at 115200 Baud: Connected (One wire)
Bootloader V1.8
Target: 1E930A ATmega88
Buffer: 960 Byte
Size available: 7680 Byte
Verify rx.hex: 00000 - 00B93 successful
CRC: o.k.
Elapsed time: 0.99 seconds

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

eins noch dann bin ich still :-)

<Nein, #if's kosten kein Byte Speicherplatz mehr, da sie bereits zur
<Compilezeit ausgewertet werden.
<Sonst würde Dir ja auch der EEPROM schnell ausgehen.

das stimmt, aber ich will ja alle Parametersätze während der Laufzeit 
ändern und modifizieren können. Wenn die mir beim compilen entfernt 
werden bringt mir das leider nicht so viel.

<Ein Deaktivieren ist nicht nötig, solange das Paßwort nicht reinkommt,
<ist der Bootloader muxmäuschenstill.
<Er kann also die Applikation garnicht stören.
<Man hat nur die 0,3s zusätzliche Resetzeit, das ist alles.

jo, ist wohl ein Probelm mit meiner applikation. Wenn ich den Sender 
ausschalte, flasht er im normalen mode. Muß mal sehen woran das liegt.

vielen Dank für die schnelle Antwort

cu und mach weiter so

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris wrote:

> <Nein, #if's kosten kein Byte Speicherplatz mehr, da sie bereits zur
> <Compilezeit ausgewertet werden.
> <Sonst würde Dir ja auch der EEPROM schnell ausgehen.
>
> das stimmt, aber ich will ja alle Parametersätze während der Laufzeit
> ändern und modifizieren können. Wenn die mir beim compilen entfernt
> werden bringt mir das leider nicht so viel.

Du könntest in deine Applikation auch eine EEProm schreib Routine 
intengrieren, die die Daten per RS232 entgegen nimmt. Falls du dafür 
nicht mehr genügend Flash hast könntest du erst ein Program zum 
schreiben des EEProm hochladen, den EEProm damit schreiben und dann das 
eigentliche Program drüber spielen. Das ließe sich sicher auch 
automatisieren. Nur der Flash "altert" dann entsprechend schneller.

Autor: JoJo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In den ersten Versionen von Pedas Bootloadern (April/Mai 2004) war die 
Funktion noch mit drin. Damals noch für Mega8/16.
Gruß JoJo

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo  Malte,

ne das ist schon ok. Ich muß ja eh ein ISP dran hängen um den bootloader 
zu flashen. Dann kann ich ja acuh direkt das eeprom schreiben, also kein 
Problem.

Autor: frans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter und anderen,


Ein hollander hat sehr intressiert das forum gelesen!
Die deutsche sprache bleibt swierig fur mich.....

Aber ist die atmega128 auch unterschutst oder nicht?

gruss frans

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
frans wrote:
> Aber ist die atmega128 auch unterschutst oder nicht?

Ja, alle AVRs ab dem ATtiny13.

Die aktuelle Version ist hier:

http://www.avrfreaks.net/index.php?module=Freaks%2...


Peter

Autor: frans@seabed.nl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was muss ich tun fur  unterschutzung atmega128?
Ich bin der erste???

edit
ins fboot18.def         1E 97 02 : atmega128
ins bootload.asm die atmega128 include selectieren

und dann offenen in avrstudio und assemblieren.


fur meine platine muss ich nog pin PE3 hoch machen und veileicht mehr...
Ist da ein specialer platz fur?


gruss Frans

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
frans@seabed.nl wrote:

> ins fboot18.def         1E 97 02 : atmega128
> ins bootload.asm die atmega128 include selectieren
>
> und dann offenen in avrstudio und assemblieren.

Ja.
Und dann noch die beiden (oder einen) Pins für den Bootloader 
definieren.


> fur meine platine muss ich nog pin PE3 hoch machen und veileicht mehr...
> Ist da ein specialer platz fur?

Was meinst Du damit?


Peter

Autor: frans@seabed.nl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

Ich muss mehr io pins initialisieren fur power und levelconverter 
enable.

Dan die programmier io pins initialisieren in bootload.asm?
mein xtal ist 3686400 Hz muss anpassen ins fastload.h?
bootdelay = xtal/5
Will fboot sich anpassen mit die timing? (abaud?)


Gibt er ein adaptier handleidung (manual) ?

gruss, Frans

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dear Frans,

please take a look at this page, which is automatical translated by 
google.

http://translate.google.com/translate?u=http%3A%2F...

cu

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
frans@seabed.nl wrote:
> Ich muss mehr io pins initialisieren fur power und levelconverter
> enable.

Zusätzliche Initialisierungen mußt Du in der "fastload.inc" hinter das 
Label "init:" eintragen.


> Dan die programmier io pins initialisieren in bootload.asm?

ja.


> mein xtal ist 3686400 Hz muss anpassen ins fastload.h?

kann man, ist aber unkritisch.


> bootdelay = xtal/5

sollte eigentlich passen


> Will fboot sich anpassen mit die timing? (abaud?)

dazu ist ja der XTAL-Eintrag da.


> Gibt er ein adaptier handleidung (manual) ?

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


Peter

Autor: Alexei Vyssotski (Firma: Universitaet Zurich) (vyssotski)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Peter,

vielen Dank fuer deinen Bootloader! Er ist toll!

Ich habe mit den hardware COM port and Aten UC-232 USB dongle probiert. 
Beide waren gut. Ich habe ATmega88 mit 7.3728MHz getaktet. Der gute 
baudrate war 19200. Ich habe nicht alle baudrates getestet, aber es 
scheint mir, dass nich alle funktionieren. Das ist aber kein Problem. 
Das richtige Problem war das ich nicht FTDI USB-serial Wandler zum Lauf 
mit dem bootloader bringen koennte. Ich weiss nicht warum. Mit meiner 
eigenen Software und dem gleichen Processor (ATmega88) FTDI laeuft gut. 
Ich habe mit FBOOT18.exe und bootloader_CSharp_adv_v3.zip probiert. 
Beide funktionieren mit FTDI nicht!

Du hast ein mal geschrieben, dass du den FTDI adapter benutzt. Wie hast 
du das gemacht? Was war fuer Treiber und Einstellungen? Welche Version 
ist mit FTDI getestet? Was hast du mit den nicht noetigen Leitungen 
gemacht? Bei mir sind sie frei. Mein FTDI Adapter heisst TTL-232R-3V3.

Noch eine Kleinigkeit. Ich habe den Kode vom bootloader ein bisschen 
geaendert. Auf meiner Platine koennte ich nur "debug wire" nutzen. 
Deswegen koennte ich nich FUSES aendern. Ich habe am Anfang des Kodes 
ueberal
.org 0
    rjmp  0x0f00
    reti
plaziert. Das soll keine Role spielen, while mit den normalen Ports 
alles  gut funktioniert.

Wer noch hat die Erfahrung mit FTDI?

Vielen Dank fuer die Hilfe im voraus!

Alexei

P.S. Ich bitte fuer mein Deutsch entschuldigen...

Autor: Alexei Vyssotski (Firma: Universitaet Zurich) (vyssotski)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch Information zu FTDI und anderen convertors. Nicht alle FTDI sind 
gleich. Ich habe gefunden dass FBOOT18.EXE mit FT232BM gut funktioniert. 
Aber FT232R im TTL-232R-3V3 Kabel - gar nicht. Natuerlich, ich habe den 
letzten Treiber 2.2.4 benutzt. Fuer Zuverlassigkeit habe ich zwei Stueck 
Kabel getestet. Zur Zeit habe ich die folgende Tabelle, wo ich markiert 
habe was funktioniert and was nicht:

PC program:             FBOOT18.EXE     "C# Ver.3"
Matherboard COM             +               +
Aten UC-232A                +               +
Keyspan USA-19HS            -(*)            +
FTDI FT232BM                +               -(**)
FTDI FT232R                 -               -

* "Transmit vom PC" LED ist OFF
** "Transmit vom PC" LED ist ON, aber keine Antwort vom ATmega88.
Leider habe ich FT232R in einem Kabel ohne LED and kann nichts ueber 
transmit/receive sagen.

Hat jemand die gute Erfahrung mit FT232R? Oder kennt jemand eine version 
vom PC Programm, die mit ihm funktioniert?

Alexei

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Alexei,

ich kann Di oder Mi Tests mit FT232RL ATMega16 mit 7.3728Mhz 
durchführen.
OS: W2k SP4 oder XP SP2

Welches Betriebssystem benutzt Du ?
Welcher Modus genau beim Bootloader ? Einfach über TX/RX also seriell ?

Gruß Sven

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexei Vyssotski wrote:

> Du hast ein mal geschrieben, dass du den FTDI adapter benutzt. Wie hast
> du das gemacht? Was war fuer Treiber und Einstellungen? Welche Version
> ist mit FTDI getestet? Was hast du mit den nicht noetigen Leitungen
> gemacht? Bei mir sind sie frei. Mein FTDI Adapter heisst TTL-232R-3V3.

Im Gerätemanager stehte nur FTDI, mehr weiß ich nicht.
Dann hab ich noch nen Prolific.
Beim Prolific mußte ich nen neueren Treiber installieren (25.07.2005).
Der FTDI hat noch den alten (25.02.2003).

Ich benutze Windows-XP.


Peter

Autor: Alexei Vyssotski (Firma: Universitaet Zurich) (vyssotski)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Sven, Peter

vielen Dank fuer ihre Antworten.

Ich habe gefunden, dass alle Bytes zum Microkontroller gut kommen, ohne 
Muell, aber gibt es inzwischen die besstimte Loecher. Sie konnen im 
Anhang schauen wie es ist. Alle Daten sind mit FT232BM gesammlet. Die 
gute Sequenz war mit FBOOT18.EXE generiert, die schlechte - mit C# V.3. 
Theoretisch, alle Sequenzen sollen fuer einen seriellen Port gut sein, 
aber das Problem macht warschaenlich Autoboading. Sven, schickst du 
einen Byte nach dem anderen separat? Oder nutzst nur einen Befehl um 
array 'Peda',0xFF zu schicken? Das habe ich noch nicht geschaut.

Die wichtige Frage fuer mich, was ist eifacher zu aendern, das PC 
Programm oder den ATmega Teil? Ich wuerde zuerst versuchen zwei Sachen 
zu machen: a) die Loecher zwischen Bytes in der Sequenz eliminieren oder 
b) diese Loecher sehr gross zu machen. Zum Beispiel, kann man versuchen 
'Peda',0xFF jede Millisekunde zu schicken? Wie sie denken, bringt es 
etwas?

Theoretisch, man kann autobauding ausschalten, aber es ist keine schoene 
Losung. Die Taktfrequenz kann in dieser Anwendung nicht genau 7.3728Mhz 
sein. Das Hauptprogramm nutzt das 1pps Sygnal (vom anderen Teil) um 
inneren ATmega88 Generator von ca. 8MHz auf 7.3728MHz (+/-0.5%) zu 
stellen. Das ist am ersten Start gemacht, und danach immer, when 
moeglich, automatish korregiert. Aber falls das Geraet ganz neu ist, hat 
er nur ca. 8MHz mit einer hohen Fehler in der Frequenz. Deshalb braucht 
man autoboading.

Ich nutze Windows XP, aber Win 2000 hat das gleiche Problem, wie ich 
geschaut.

Gruss,

Alexei

Autor: Alexei Vyssotski (Firma: Universitaet Zurich) (vyssotski)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt versuche ich noch ein mal den Dateianhang zu schicken, der nicht 
gegangen ist. Jetzt ist er 352K gross.

Alexei

Autor: Alexei Vyssotski (Firma: Universitaet Zurich) (vyssotski)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Sven, Peter

ich habe meine Problemen geloescht! Zeurst, die Frequenz des Procressors 
am Start war 7.3728/8 MHz und nicht 7.3728MHz, wie ich frueher gedacht 
habe. Das war der Gruend warum der Processor nur bis 19200bps 
programmiert werden koennte. Wenn ich die Frequenz acht mal vergroessert 
habe, alle baudrates waren gut. Das zweite Problem war, dass 
TTL-232R-3V3 Kabel von FTDI immer (am Start) die hohe Spannung auf TX 
Leitung hat. Wenn die Platine mit diesem Adapter verbunden war, und am 
Anfang der Strom auf dem Microcontroller aufgeschaltet war, koennte er 
nicht starten!!! Die Loesung war den Microkontriller zuerst starten und 
dann mit dem Adapter verbinden. Aber fuer  solchen Start 0.33 sec 
Startzeit ungenuegend ist. Zum glueck sollte ich diesen Konstant nicht 
aendern, while meine richtige Processorfrequenz mehr als acht mal 
niedriger als default war. Am Schluss habe ich  ca. 2.7 Sekunden 
Startzeit gehabt.

Das letzte Problem ist nur fuer TTL-232R-3V3 Kabel aktuell. Der Chip 
FT232R hat den Eingang, der die Spannung auf TX/RX Linien leiten kann. 
Aber im TTL-232R-3V3 Kabel giebt es leider keinen Zugang zu diesem Pin.

Ich hoffe, dass diese Information fuer den anderen Leute nuetzlich sein 
koennte.

Mit freundlichen Gruessen,

Alexei

Autor: Hannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

kann man die Schaltung , wie in der bootloader.pdf beschrieben , direkt
an die R232 eines  PC anschliessen ?
Oder muss zwischen J8 und J9 noch ein MAX232 ?

Konnte hier im Thread und im Wiki nichts dazu finden.


Gruss und noch schöne Ostern
 Hannes

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hannes wrote:
> Hallo zusammen,
>
> kann man die Schaltung , wie in der bootloader.pdf beschrieben , direkt
> an die R232 eines  PC anschliessen ?

Ja.


Peter

Autor: frans@seabed.nl (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo peter,

Dar ist die hollander wieder.....
Die ATmega128 brennt einmal!
Das program lauft dan.

COM 1 at 9600 Baud: Connected
Bootloader V1.8
Target: 1E9702 ATmega128
Buffer: 1024 Byte
Size available: 130048 Byte
Program solo.hex: 00000 - 0F000 successful
CRC: o.k.
Elapsed time: 61.59 seconds

Die zweite mal geht es nicht mehr............

COM 1 at 9600 Baud: Connected      oder mit (OneWire)??
Bootloader VFFFFFFFF.FF
Error, wrong device informations

connected -> das pasword ist gut
und die baudrate ist auch gut fur das 4 char password
check_crc volgt dan
und dan readinfo gibt die falshe version aber kein signature???
auf das resultcode von readinfo wirt die Error, wrong usw. geprinted??


Ich hat das problem ins bootdelay gesucht....
das crystal sind 3.68 Mhz und bootdelay/5
(wie komt man von default 8Mhz und bootdelay/3 auf 0.33 sec?)
Die fuses sind correct wie das ORG ins die .lst file

Mein zu brennen program gebraucht die watchdog, kan das interferieren 
mit die watchdog von fboot18?
Muss ich noch etwas tun mit CRC, WDT, verify???
Ist der toleranz van die baudrate das problem??
Kan ich ein baudrate forcieren?
Kan ein tastedruck version mit fixed baud mein problem wegnemen?

in die anhang hat ich die anderte files mit gelievert (<- zu 
hollandisch?)

Mit freundlichen Gruessen,

Frans

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter:

Ich habe jetzt eine Schaltung aufgebaut mit einem Mega8 und
FT232RL. Schaltung wird komplett durch den USB Bus versorgt.
(Bus-Powered)

Die Schaltung arbeitet einfach mit UART über RX/TX.
Jetzt besteht das Problem:

Voraussetzung:

- der Bootloader ist aufgespielt
- ein normales Programm läuft ebenso

Update Vorgang:

- man muss den USB Bus abziehen
- schnell wieder anstecken

Problem:

- virtueller Comport ist noch nicht bereit;
  oder vielmehr das Handle existiert ja nicht mehr,
  man kann also nicht vorher schon den Comport öffnen
  und innerhalb der 0,3s updaten


Mein Vorschlag:

Der Bootloader bekommt 2 Startzeiten:

1. Standardzeit festgelegt mit den 0,3s
2. Bootloader schaut auf die erste Stelle
   des internen EEProms und stellt entsprechend
   eine längere Wartezeit ein,
   danach startet die Firmware aber normal durch.
   Standard ist ja FF, dann ist es also möglich
   die Zeit von 0-254 zu stellen, 255 als Wert
   lässt also auch die 0.3s ablaufen

Über die normale Applikation kann man also diese
Speicherzelle beschreiben und vor einem Reset
die Startzeit verlängen.


Was hälst Du von der Idee ?

Gruß Sven

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

Bewertung
0 lesenswert
nicht lesenswert
frans@seabed.nl wrote:

> Mein zu brennen program gebraucht die watchdog, kan das interferieren
> mit die watchdog von fboot18?

Ja, kann sein.

Anbei ne korrigierte Version (werd sie auch in AVRFreaks updaten).

Es scheint so, daß zumindest bei neueren AVRs beim ersten Zugriff noch 
kein neuer Teilerwert geladen werden darf, sondern erst beim 2.Zugriff.


Peter

Autor: Duri (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle fboot Nutzer (das sind in der Zwischenzeit ziemlich viele)

Ich wollte für meinen ATMega32 eine Bootdatei compilieren und habe die 
Felermeldung " WDCE unbekannter Wert" bekommen.

Beim M32 heisst dieses Registerbit WDTOE.

In der Datei X:\..\avrassembler2\Appnotes\m32def.inc ist definiert:
(AVR Studio 4 SP2)

.equ  WDDE  = WDTOE  ; For compatibility

Ich behaupte einfach mal, das ist ein Fehler von Atmel.

Richtig wäre:
.equ  WDCE  = WDTOE  ; For compatibility

Wenns jemanden hilft....

Autor: Karsten Donat (karstendonat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven wrote:
> - man muss den USB Bus abziehen
> - schnell wieder anstecken
>
> Problem:
>
> - virtueller Comport ist noch nicht bereit;
>   oder vielmehr das Handle existiert ja nicht mehr,
>   man kann also nicht vorher schon den Comport öffnen
>   und innerhalb der 0,3s updaten

Für das Problem gibts 3 einfache Lösungen:

1. Hardware Reset über Taste
--> Reset Pin auf Masse ziehen per Taster
(wenn die Schaltung schon fertig ist, nimm halt nen Draht)

2. Hardware Reset über Transistor
--> PNP an einen Pin hängen und mit 10k an den Reset. Nach em Reset ist 
der Pin Low und der PNP hat am Ausgang zum Reset High (invertierende 
Schaltung). Stzeuert man den Pin High, sperrt der Transistor und man 
zieht den Reset auf Masse.

3. Software-Reset
wdt_enable(WDTO_15MS);
while (true);

In der IDE wird ein Reset Signal gesendet. Danach wird das Programmer 
Tool von Peter gestartet. Dafür muss das Bootloader Delay auf 1s erhöht 
werden.

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 3. Software-Reset

> wdt_enable(WDTO_15MS);
> while (true);

> In der IDE wird ein Reset Signal gesendet. Danach wird das Programmer
> Tool von Peter gestartet. Dafür muss das Bootloader Delay auf 1s erhöht
> werden.

Dieser Vorschlag hat aber genau das gleiche Problem,
das innerhalb des Befehls des wdt_enable aus der eigenen
Anwendung der Comport geschlossen und dann das Tool
zum Flashen gestartet werden muss. (auch wenn
man die Zeit auf 1 Sekunde stellt)

Meine Idee mit dem EEProm fand ich universeller, da kein
Zugang zum Reset Pin notwendig ist. Ebenso braucht
es keinen Taster und die "Standard" Flasher Tools funktionieren
weiterhin.

Vielleicht ist es jetzt verständlicher.

Tja, warum habe ich diese Frage eigentlich gestellt ?
Weil ich in Assembler dafür viel Zeit brauche um
die entsprechenden Routinen in Abaud.inc einzubauen.
In C bin ich in 10 Minuten damit fertig.
Deswegen wollte ich eigentlich das Feedback von Peter,
ob er denkt das es eine gute Idee ist und
er sich in 10 Minuten Assembler Know-How dafür begeistern
kann.
Ausserdem möchte ich den schönen präzisen Code
von Peter nicht versaubäuteln. ;-)

Gruß Sven

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven wrote:
> Weil ich in Assembler dafür viel Zeit brauche um
> die entsprechenden Routinen in Abaud.inc einzubauen.
> In C bin ich in 10 Minuten damit fertig.

Na, so schlimm ist Assembler auch nicht.
Hier mal der Hack, ist aber nicht getestet.
Kannst ja mal berichten, obs funktioniert.
Für längeres Reset nen kleineren Wert als 0xFF speichern.

...
abaud:
        ldi     a0, 1                   ; additional boot delay at 0x0001
        out     EEARL, a0
        out     EEARH, zerol
        sbi     EECR, EERE
        in      a0, EEDR
        subi    a0, -(byte3(BootDelay / 6) + 1)
_aba1:
        movw    zh:zl, zeroh:zerol      ; cause first try invalid
...


Peter

Autor: Karsten Donat (karstendonat)
Datum:

Bewertung
0 lesenswert
&#