mikrocontroller.net

Forum: Compiler & IDEs Bootloader startet überhaupt nicht


Autor: Andreas Paulin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, zusammen,

ich habe hier ein Problem, das mich langsam in den Wahnsinn treibt, 
vielleicht
kann mir von Euch jemand zeigen, wie ich aus diesem Film herauskomme. 
Bin versierter Entwickler, aber das hier ist mir zuviel Neuland:

Hardware:     Ein Crumb 128-Board von Chip45, aufgesetzt auf ein eigenes 
Eva-Board,
Programmer: Ein STK200 kompatibler ISP-Dongle, selbstgeschnitzt, 
funktioniert soweit ganz gut
Entwicklungsumgebung ist die WINAVR-Suite mit AVRDude als Pgm.-Software

Diverse Progrämmchen zum Betrieb von RS232, eines LC-Grafikdisplays etc. 
funktionieren soweit gut. Das Testsystem läuft also grundsätzlich

Jetzt das Problem: Für spätere Anwendungen brauchts einen Bootloader.
Um einen Einstieg ins Thema zu kriegen habe ich einen Bootloader von 
CHIP45.COM (ATMEGABOOT) heruntergeladen
und kompiliert.
Und geflasht.
Und geht nicht.
Warum?

Makefiles sind mir noch etwas fremd, aber alle zur Kompilierung nötigen 
Info, Parameter und Flags sollten sich dort
finden.
OK, die Fuses des AVR:
LFUSE = 0xFF (im wesentlichen Taktparam., geht auch gut so),
HFUSE = 0x98, d. h. BOOTSZ1=BOOTSZ0=0, BOOTRST=0 -> Der Bootvektor 
sollte also auf 0x1E00 zeigen.

Setze ich das BOOTRST-Bit probehalber auf 1 (-> HFUSE=0x98) starten 
Programme auch ganz normal bei 0x00000.

Das Makefile enthält die Zeilen:
ifeq ($(PRODUCT),CRUMB128)                    // OK, ist oben definiert
MCU_TARGET = atmega128                       // falsch, aber vorläufig 
OKgibts noch Probleme mit dem CAN128
#MCU_TARGET     = at90can128                 // noch nicht in devlist
LDSECTION  = --section-start=.text=0x1E000    // GENAU! Hierhin muss es
ISPFUSES    = avrdude -c $(ISPTOOL) -p m128 -P $(ISPPORT) $(ISPSPEED) -u 
-U efuse:w:0xff:m -U hfuse:w:0xc8:m -U lfuse:w:0xdf:m
ISPFLASH    = avrdude -c $(ISPTOOL) -p m128 -P $(ISPPORT) $(ISPSPEED) -V 
-U flash:w:$(PROGRAM)_$(PRODUCT)_$(BUILD).hex

Ein Blick aufs Hexfile mit Galep zeigt auch einen ab 0x0000 leeren 
Puffer, aber Code an der richtigen Stelle:
1E000: 0C 94 46 F0 0C 94 63 F0...............................
Schätze, das ist der Startup-Code.

OK, um die Funktion des Bootloader-Codes mal grundsätzlich zu 
überprüfen,  habe ich den Loader abgekürzt, und schlicht
folgende Zeilen eingefügt:


/* main program starts here */
int main(void)
{
// 'vorhandener Code..unwichtig:
    uint8_t ch,ch2;
    uint16_t w;
    asm volatile("nop\n\t");
    /* set pin direction for bootloader pin and enable pullup */
    /* for ATmega128, two pins need to be initialized */
#ifdef _AVR_ATmega128_
    BL_DDR &= ~_BV(BL0);
    BL_DDR &= ~_BV(BL1);
    BL_PORT |= _BV(BL0);
    BL_PORT |= _BV(BL1);
#else
    BL_DDR &= ~_BV(BL);
    BL_PORT |= _BV(BL);
#endif
//////////////////////////////////////////////////////////////////////// 
/////////////////////////
Hier nun mein Code, der nicht funktioniert:
 #define LEDRD_PORT   PORTG
 #define LEDRD        PG0
 #define LEDRD_DDR    DDRG

 #define LEDRDON    LEDRD_PORT |= _BV(LEDRD)
 #define LEDRDOFF   LEDRD_PORT &=~_BV(LEDRD)

 LEDRD_DDR |= LEDRD;
 while (1)
  {
  LEDRDON;
  LEDRDOFF;
  }

Und jetzt frage ich mich, warum ich am Port G0 nichts messen kann.
Der Code läuft, wenn ichs mit normalem Resetvektor 0x0000 flashe.

Eine merkwürdige Sache: Der AVRDude bringt NACH der Programmierung die 
Meldung
"avrdude.exe: 123578 bytes of flash written"


1. Warum soviele. Bootloader hat doch nur ein paar kB und sollte ab 
1E000 geflasht werden?
2. Ist das normal, dass der STK200/AVRDude für 123578 Bytes 90sec(!). 
brauchen?
3. Wieso ausgerechnet ca 8kB weniger als ins FlashROM passt (128kB)?
4. Warum aber sinds nicht exakt 8kB (8192Byte) sondern nur 7940 Byte 
weniger?

Liegt da der Hund begraben? Aber warum? Ich komm nicht drauf. Hab schon 
alle Foren etc. abgegrast....

Wer kann hier helfen? Ich danke im voraus vielmals für Tips.

Grüßle

Andreas Paulin

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

Bewertung
0 lesenswert
nicht lesenswert
Ups, OK, hier nochmal der komplette Sourcecode&makefile

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

Bewertung
0 lesenswert
nicht lesenswert
Und nochmal: Der Sourcecode

Autor: Andreas Paulin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wow - Keiner irgendne Idee?

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
ideen jede menge, aber imo recht konfus, was so geschrieben steht. aber 
der reihe nach.

>Setze ich das BOOTRST-Bit probehalber auf 1 (-> HFUSE=0x98) starten
>Programme auch ganz normal bei 0x00000.

das ist falsch ( und hoffentlich ein tippfehler).
hfuse sollte dafür 0xC9 werden.

>Eine merkwürdige Sache: Der AVRDude bringt NACH der Programmierung die
>Meldung
>"avrdude.exe: 123578 bytes of flash written"
>1. Warum soviele. Bootloader hat doch nur ein paar kB und sollte ab
>1E000 geflasht werden?

ist bei avrdude so, da wird von 0x0000 bis zum ende geflash-ed. leider.

2. Ist das normal, dass der STK200/AVRDude für 123578 Bytes 90sec(!).
brauchen?

das ist normal.

> 3. Wieso ausgerechnet ca 8kB weniger als ins FlashROM passt (128kB)?

keine ahnung, bin grad zu faul, nachzurechnen :)

4. Warum aber sinds nicht exakt 8kB (8192Byte) sondern nur 7940 Byte
weniger?

möglicherweise ist der bootloader nicht größer.

wie testest du den port g?

bye kosmo

Autor: Andreas Paulin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, Joe,

danke fürs Feedback. Die Punkte:

"das ist falsch ( und hoffentlich ein tippfehler)."
hfuse sollte dafür 0xC9 werden."
Stimmt. Tippfehler. Bit 0 Muss 1(!) sein, dann ist Reset bei 0x00000.
War Tippfehler, Unterschied 0x99<->0xC9 ist unwesentlich, ist nur das 
JTAGEN-Bit, das hat imho nichts mit dem reset zu tun..werds aber auch 
mal checken.

"ist bei avrdude so, da wird von 0x0000 bis zum ende geflash-ed. 
leider."
OK, das erklärt das.
Da kommt so oder so ein Zeitproblem bei der Entwicklung auf mich: zu 
lange Turnaround-Zeiten.
Gibts eine andere Pgm-SW, die mit STK200 arbeitet und nur die zu 
flashenden Bereiche brennt? Sonst wird das Herumprobieren am Bootloader 
zur Mühsal bis unmöglich
Oder würdest Du eine komplett andere Prommer/Software-Kombination 
empfehlen?

OK, zur Sache:
Den Port schaue ich mir mit dem Oszi an. Da muss sich (bei 
Bootloader-modus, HFUSE = 0xC8) im us-Bereich was tun.
Tut sich aber nichts.........




Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe auch Probleme, die Fragestellung zu verstehen ;-)

Das glaube ich verstanden zu haben:

Target ist AT90CAN128, der aber als ATMEGA128 programmiert wird.
Usercode nach 0x0000 geladen, funktioniert.
Abgespeckter Bootloadercode nach 0x1E00 geladen, funktioniert nicht.
Abgespeckter Bootloadercode nach 0x0000 geladen, funktioniert 
(BOOTRST-Bit probehalber auf 1)
Funktionieren heisst LED an PORTG lässt sich toggeln.

> 3. Wieso ausgerechnet ca 8kB weniger als ins FlashROM passt (128kB)?

Hast du schon probiert die Boot-Fuses erst NACH dem Flashen zu setzen? 
Nicht dass durch die gesetzte Boot-Fuses der genau 8 KB grosse 
Bootloaderbereich schreibgeschützt ist...

Ansonsten mach nach dem Flashen einen Memdump und schau nach, was im 
Bootloaderbereich drin steht.

Autor: Andreas Paulin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan: Danke Dir.
Ja, das IST so durcheinander. Schlag mich nicht, wenns nachher was ganz 
simples war.....

Joes Posting scheint mir den Grund für "8kb weniger" zu erklären: Der 
AvrDude flasht echt ALLES mit Nullen voll bis 0x1e000, dann den 
'Loader'.
Da der aber nur ein paar hundert Byte hat, siehts FAST so aus wie wenns 
128kB - 8kB wären.

Die Bootsize-Fuses haben damit nichts zu tun, für programmierbarkeit 
oder nicht sind die Lock-Fuses zuständig, und die sind alle '1' (=freier 
R/W-Zugriff).

Oki, einen Memdump könnte ich mal machen.....NEIN, der Avrdude HAT doch 
schon erfolgreich verifiziert!


Autor: Andreas Paulin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Joe: Die HFUSE sollte WIRKLICH 0xD8/0xD9 sein, nicht 0xC8, 0xC9.

Der Unterschied liegt im Watchdog: Wenn diese Fuse (Bit4) als '0' 
programmiert wird, ist der Watchdog eingeschaltet.

Autor: Andreas Paulin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wichtige Erkentnisse:

- Watchdog MUSS ausgeschaltet bleiben (HFUSE =0xD8/9)
- Der Avrdude im Terminalmode MUSS mit 'quit' verlassen werden, ERST 
dann startet der AVR neu.

Bleibt noch ein anderes Problem:

Warum führt der Avrdude IMMER einen Chip erase durch?
Per AvrdudeGUI lasse ich nun erst den 'Bootloader' MIT Chip-Erase (Param 
-e) nach 0x1e000 brennen und  dann OHNE Chip-Erase die 4K 
Standardfirmware @0x00000.

Der AvrdudeGUI schiebt zu letzterem folgende Kommandozeile raus:
"E:\Programme\WinAVR\bin\avrdude.exe" -p m128 -c stk200 -C 
"E:\Programme\WinAVR\bin\avrdude.conf" -P lpt3 -U flash:w:"E:\CSS 
Projekte\RolliX\Firmware\HelloCSS\HelloCSS.hex":i -v -V -E reset,novcc

Stimmt, der Parameter '-e' ist nicht da.   :)
Der Bootloader wird aber trotzdem gelöscht :(  wie ein Memdump ab 
0x1E000 zeigt (Danke, Stefan :)

Warum???


Autor: kosmonaut pirx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
warum nicht? das ist ein chip erase, da wird nun einmal alles platt 
gemacht (naja, fast alles). auszuschalten via -D option

warum lädst du die firmware nicht über den bootloader? da solltest du 
das problem nicht haben. und dafür ist der auch gedacht, ist kein 
selbstzweck, das ding.

bye kosmo

Autor: kosmonaut pirx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ach ja: von welcher mcu reden wir denn überhaupt? doch wohl dem mega128, 
oder?

>Die HFUSE sollte WIRKLICH 0xD8/0xD9 sein, nicht 0xC8, 0xC9.
>Der Unterschied liegt im Watchdog: Wenn diese Fuse (Bit4) als '0'
>programmiert wird, ist der Watchdog eingeschaltet.

man, das hättst ja mal konkret herausstellen könnnen.
bin_grad_tierisch_bedient

>Hardware:     Ein Crumb 128-Board von Chip45, aufgesetzt auf ein eigenes

was du meinst, ist ein
"Crumb128-CAN"

da sich diese in der hfuse unterscheiden, hat mich das erst stutzig 
gemacht. ja klar, watchdog aus, was'n sonst.

junge junge :)

Autor: Andreas Paulin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ kosmo:
Der Sinn eines Bootloaders ist mir schon klar, kosmo.
Ich lade die Firmware nicht über den Bootloader, weil das schlicht nicht 
funktioniert.
Der Bootloader ist der bei www.chip45.com herunterladbare 'ATMegaBoot'.

Hierzu gibts auch Makefiles für alle Varianten der dort angebotenen 
Prozessormodule.
Fast alle.
Ich habe ein Crumb128-CAN.
Für Crumb128-CAN gibts da noch GARNICHTS.
Also behelfe ich mir mit Code für den ähnlichsten Controller. Den 
'Crumb128'.
Es passt aber keins der Makefiles so richtig, weil nirgends die 
Konstante F_CPU auf 16000000 steht: Es sind Makefiles für den CRUMB128 
mit 14.75 MHz und 20.0MHz vorhanden, aber keines für einen CRUMB128-CAN 
mit 16MHz.
Davon hängt aber wiederum die Baudrate der ser. Schnittstelle ab.
Und darüber soll ja die Software geladen werden.

Also: Falsche Taktangabe bei Compilierrung macht download unmöglich. 
ergo: Rein ins Getümmel und die Sache ändern. Und wenns dann nicht läuft 
speckt man normalerweise den Code auf rudimentäre Reste ab und geht 
zurück zur Badstraße.........

Im zugehörigen Makefile werden übrigens auch auch die Fuses (hier: 
HFUSE)definiert. Siehe oben.

Genauso, wie Du oben vorgeschlagen hast: 0xC8
Soweit sind Dr. Lins und Du also einer Meinung im Bit#4
Was den ATMEGA128 betrifft, voll OK.

Was leider für meinen Fall anders ist: Das Bit #4 der HFUSE ist beim 
ATMega128 die 'CKOPT', bei meinem AT90CAN128 aber das 'WDTEN'-Bit.
Da läuft bei mir also der Watchdog.........
Ergo: ATMega128 und AVR90CAN128 haben unterschiedliche HFUSEs.
In EINEM Bit unterschiedlich. Eben im Datasheet gesehen.
Und ich renne voll ins Messer.

Thanks a lot. Ich tret dem blöden Lins die Eier blau. Ich hab das 
Crumb128CAN gekauft um nen leichten Einstieg zu kriegen, und nicht in 
Makefiles zu stochern!

OK, jedenfalls 1 Schritt weiter.........


Aber zum Avrdude. Du schreibst:
"warum nicht? das ist ein chip erase, da wird nun einmal alles platt
gemacht (naja, fast alles). auszuschalten via -D option"

Weil ich die Option "-e: perform a chip erase" ausgeschaltet hatte.
Deshalb sollte er keinen chip erase durchführen.
Das war meine Frage.
Aber Du sagst da was Gutes: '-D' gibts auch noch.
Ich war hier auf die Option '-e' fixiert.

Wieder ein Schritt....... wichtig für später.......
Jetzt nehme ich mal alle erkentnisse zusammen, und schau, obs nicht 
langsam klappt. Bleiben Sie dran ;-)

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nimm doch den hier, sonst wirst du ja nie fertig :)

http://www.siwawi.arubi.uni-kl.de/avr_projects/#avrprog_boot

der geht. muss man auch ein bichen frickeln, aber nur ganz kurz. oder 
ich schicke dir gleich nen bl für CAN.

bye kosmo

Autor: Andreas Paulin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, Kosmo, danke für den Tip, hab die 0.81 mal runtergelden, und werde 
gleich die Fuses mal checken.....

Aaaaaaaaaaaaber:
Grundsätzlich möchte ich schon aus eigener Kraft ein Winzprogramm 
hinkriegen, das es schafft
- mittels Bootvektor auf 0x1E000
- nach einem Reset
- den dort vorhandenen Code auszuführen.
Und der geht mittlererweile so:

DDRD |= 0x40;
while (1)
        {
  PORTD |=0x40;
  PORTD &=~0x40;
  }
SOWEIT möchte ich als Entwickler die Maschine schon in den Griff 
kriegen.

Wenn DAS dann mal grundsätzlich läuft ists ok, dann werde ich klar den 
vorhandenen Bootloader verwenden. Den Teufel werde ich die ganzen 
Flash-Algorithmen neu erfinden, das braucht ja ewig ;-)

Aber erstmal müssen die wesentlichen Grundlagen stimmen.

Autor: Andreas Paulin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also... soll heißen: Da muss irgendwann mal am Port D6 was zucken, ne?!

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das sollte es wohl.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast bereits sichergestellt, dass dein main() Code grundsätzlich 
lauffähig ist (Test als Programm ab 0x0000 - LED blinkt).

Du hast bereits sichergestellt, dass dein Programm von AVRDUDE in den 
Bootloaderbereich geflasht wird (Memdump).

Du musst jetzt kontrollieren, ob das Bootloader-Programm auch in dem 
Bootloaderbereih lauffähig ist.

D.h. ob dein bewusst geschriebener Code (main()) und der dazugebundene 
Code (C Startupcode) von der Toolchain korrekt für die Adresse 0x1E00 
übersetzt sind.

Dafür würde ich Option der Toolchain benutzen, die mir ein ASM-Listing 
(*.LSS) erzeugt. Dieses Listing würde ich dann mit dem Datenblatt "8-bit 
Microcontroller with 32K/64K/128K Bytes of ISP Flash and CAN Controller 
- AT90CAN32 AT90CAN64 AT90CAN128"  und dem Bereich über den Bootloader 
(S. 61ff und 320ff) vergleichen.

Autor: Andreas Paulin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, Stefan,

danke für den Tip. Die Listings enden aber mit *.LST ;-)
Egal, ich habs gefunden: Ich hab das Listing mal komplett angehängt. Bin 
kein Assemblerkenner, aber ich sehe da ein Programm, das bei 0x1E000 
anfängt, eine Vektortabelle, irgendwelches Startupzeugs, einen Sprung 
mach main...
und dann:
0001e278 <main>:
   1e278:  cf ef         ldi  r28, 0xFF  ; 255
   1e27a:  d0 e1         ldi  r29, 0x10  ; 16
   1e27c:  de bf         out  0x3e, r29  ; 62
   1e27e:  cd bf         out  0x3d, r28  ; 61
   1e280:  00 00         nop

Das hier ist wohl mein Code:
   1e282:  8e 9a         sbi  0x11, 6  ; 17
   1e284:  96 9a         sbi  0x12, 6  ; 18
   1e286:  96 98         cbi  0x12, 6  ; 18
   1e288:  96 9a         sbi  0x12, 6  ; 18
   1e28a:  96 98         cbi  0x12, 6  ; 18
   1e28c:  fb cf         rjmp  .-10       ; 0x1e284 <main+0xc>

OK, da werden Bits in den IO-Adressen 0x11 und 0x12 gesetzt und 
gelöscht.

???????? HÄ???
Laut Datasheet AT90CAN128, IOMemory:
0x11: PORTF
0x12: PING
Mein Source MEINTE aber PORTD, bzw. DDRD. Sollte da etwa....

Blick ins ATMEGA128-Datasheet, IO-Memory::
0x11: DDRD
0x12: PORTD

So. Danke. Das wars. Mein Standardprogram@0x00000 hat schon die 
AT90CAN128-Header eingebunden, den Bootloader von Chip45 habe ich mit 
'ATMEAG128-Option kompiliert, weils für das Crumb128-CAN von Chip45.com 
gar keinen expliziten Bootloader gibt. Und für mich als AVR-Newbie der 
ATMEGA128 sehr ähnlich dem AT90CAN128 schien.
Und als AVR-Newbie portier ich halt nicht mal kurz den ganzen Bootloader 
auf einen anderen Controller, ne?!

Fazit: Den ganzen Code für das Crumb128-Modul kann sich der Herr Dr. 
Lins in seinen Doktorarsch schieben, weil das ganze Zeug nicht für sein 
CRUMB128-CAN-Modul taugt!!

Die zwei Controller unterscheiden sich GRAVIEREND!
Muss man wissen, ich komme aus dem PIC-Lager, da sind alle SFR-Adressen 
ungefähr gleich...............

Danke, Stefan, danke, Kosmo, schätze jetzt komme ich weiter.
Und jetzt mache ich mit dem Bootloader von Martin Thomas weiter, der 
Lins hat verschissen!

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tut mir leid, aber mit deinem ton hast du dich grade rausgekickt :(

wenn du im makefile nicht siehst, dass das für den mega128 gemacht ist: 
selber schuld.
MCU_TARGET = atmega128

override CFLAGS        = -g -Wall $(OPTIMIZE) -mmcu=$(MCU_TARGET) -D$(PRODUCT) -D$(AVR_FREQ) $(DEFS)

$(PROGRAM).elf: $(OBJ)
        $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS)


sicher steht auf der website, dass der bootloader auch für den 
at90can128 gemacht ist. dann aber bitte gehirn einschalten, das ändern 
und bei chip45.com bescheid geben, damit andere nicht auch da rein 
stolpern.

bye kosmo

Autor: Andreas Paulin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ kosmo: Dochdoch, Kosmo, der Ton ist berechtigt. Aber voll.
Du hast keine Ahnung, wie lange ich an dem Thema schon rumnage.........
Schließlich haben wir die zwei Crumbs ja bestellt, um uns den Einstig 
ins Thema einfacher zu machen. Um Softwareunterstützung zu erhalten, um 
schneller mit diesem neuen Controller starten zu können ;-)

Das Resultat war ne kleinere Doktorarbeit. Als Anfänger...........

Das MCU_TARGET im Makefile habe ich schon gesehen. Es gab aber keine 
Alternative, also habe ich das genommen, was meinem Crumb am ähnlichsten 
schien:
Crumb128 statt Crumb128CAN. Die Ähnlichkeit ist frappierend, ne?!
Und wenns keine andere Firmwarevariante vom Hersteller für mein Produkt 
gibt, gehe ich mal davon aus, dass das schon passen wird.

Wie gesagt: JETZT weiß ich, dass auch ähnlich erscheinende AVR 
gravierende Unterschiede, auch in der SFR-Belegung, haben.

Aber dem Lins mal Bescheid sagen, das werde ich ;-)

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das eine ist ein mega, das andere nicht.

probier doch mal aus, das makefile um den at90 zu erweitern. ist ja 
nicht so schwer.

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kriegst noch futter:

AVR096: Migrating from ATmega128 to AT90CAN128
http://www.atmel.com/dyn/resources/prod_documents/...

Autor: Andreas Paulin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@kosmo: Danke. Guter Background

Naja, das Material von Chip45 ist auch nicht sooo schlecht. Ohne diese 
Zusammenstellung von Software hätts noch länger gedauert. Das meiste IST 
ja auch für alle Produktvarianten brauchbar.
Ich hab mir nur prompt den Bootloader rausgesucht, der nicht für den 
AT90CAN128 angepasst hat und bin halt in die Falle gelaufen.......... 
mit ner neuen uC-Familie im Gepäck, IDE-verwöhnt in der 
Kommandozeilen-Welt unterwegs, Makefiles und CFLAGS... gg

Autor: Andreas Paulin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thanks to all - Bootloader läuft!

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gratulation .. weißt ja, wo du bescheid geben könntest :)

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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