HI, okay, mein Atmega16 funzt noch, nun würde ich echt gerne das Beispiel http://www.mikrocontroller.net/articles/AVR_Bootloader_in_C_-_eine_einfache_Anleitung ausprobieren. Ich möchte Studio 5 nutzen, daher kann ich leider als Anfänger die Einstellungen von Studio 4 nicht so einfach übernehmen. Ich dachte mir, ich würde dann in der Toolchain eintragen müssen: Flash Segment: .text=0x3800 Wenn ich das mache, dann bekomme ich bizarrerweise -Wl,-Map="$(OutputFileName).map" -Wl,--start-group -Wl,-lm -Wl,--end-group -Wl,-section-start=.text=0x7000 -mmcu=atmega16 unter dem AVR/GNU Linker... laut dem Link oben hat man bei Studio 4 aber bei dem 8k-Kontroller die 0x1800 zu setzen, das kapiere ich schon mal nicht! Weil genau die Adresse würde ich ja erwarten, wenn ich 1024 words von 8 k abziehe... Also, im Tutorial lese ich (MK II Programmer, habe ich nicht, nutze Burn-O-Mat): "Danach können wir uns an das setzen der Fuses machen. CKDIV8 sollte ausgeschalten werden, der interne Takt von 8 Mhz sollte genutzt werden (SUT_CKSEL) und BOOTSZ auf 1024 words gestellt werden. Zusätzlich muß die BOOTRST-Fuse gesetzt werden, damit der Bootloader an der richtigen Adresse anfängt. Für alle, die einen anderen Programmer benutzen (z.B. avrdude), hier die exakten Werte der Fuses: Low Fuse: 0xE2 High Fuse: 0xD2 Extended Fuse: 0xF8 " Beim Burn-o-Mat finde ich keine Extended Fuse... Welche Fuses setze ich nun im Burn-O-Mat? Beim Atmega16? Danke! Jens
J. W. schrieb: > Wenn ich das mache, dann bekomme ich bizarrerweise Daran ist nichts bizarr. Im Studio musst du die Word-Adresse (wie sie auch im Datenblatt steht) eintragen. Da die GNU-Tools aber Byte-Adressen erwarten, trägt das Studio in die Kommandozeilen eben jene ein.
Das hier schreit doch schon danach, dass es schief geht, oder nicht: C:\Programme\WinAVR-20100110\bin\avrdude.exe -C C:\Programme\WinAVR-20100110\bin\avrdude.conf -p m16 -P com1 -c ponyser -U flash:w:C:\Dokumente und Einstellungen\jens\Eigene Dateien\Atmel Studio\Bootloader1\Bootloader1\Debug\Bootloader1.hex:a avrdude.exe: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude.exe: Device signature = 0x1e9403 avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude.exe: erasing chip avrdude.exe: reading input file "C:\Dokumente und Einstellungen\jens\Eigene Dateien\Atmel Studio\Bootloader1\Bootloader1\Debug\Bootloader1.hex" avrdude.exe: input file C:\Dokumente und Einstellungen\jens\Eigene Dateien\Atmel Studio\Bootloader1\Bootloader1\Debug\Bootloader1.hex auto detected as Intel Hex avrdude.exe: writing flash (15164 bytes): Writing | ################################################## | 100% 24.23s avrdude.exe: 15164 bytes of flash written avrdude.exe: verifying flash memory against C:\Dokumente und Einstellungen\jens\Eigene Dateien\Atmel Studio\Bootloader1\Bootloader1\Debug\Bootloader1.hex: avrdude.exe: load data flash data from input file C:\Dokumente und Einstellungen\jens\Eigene Dateien\Atmel Studio\Bootloader1\Bootloader1\Debug\Bootloader1.hex: avrdude.exe: input file C:\Dokumente und Einstellungen\jens\Eigene Dateien\Atmel Studio\Bootloader1\Bootloader1\Debug\Bootloader1.hex auto detected as Intel Hex avrdude.exe: input file C:\Dokumente und Einstellungen\jens\Eigene Dateien\Atmel Studio\Bootloader1\Bootloader1\Debug\Bootloader1.hex contains 15164 bytes avrdude.exe: reading on-chip flash data: Reading | ################################################## | 100% 23.31s avrdude.exe: verifying ... avrdude.exe: 15164 bytes of flash verified avrdude.exe done. Thank you. Wieso schreibt der Mist denn 15164 bytes? Oh man...
Stefan Ernst schrieb: > J. W. schrieb: >> Wenn ich das mache, dann bekomme ich bizarrerweise > > Daran ist nichts bizarr. Im Studio musst du die Word-Adresse (wie sie > auch im Datenblatt steht) eintragen. Da die GNU-Tools aber Byte-Adressen > erwarten, trägt das Studio in die Kommandozeilen eben jene ein. Also ist doch .text=0x1c00 okay? Okay, kein Problem. Was muss ich nun tun, welche Fuses muss ich nun wirklich setzten? Ich habe das Pollin-Board, das dürfte aber egal sein... was muss ich nun tun, damit ich über Putty kommuniziere? Aufrufen von Putty mit Baud 9600 und COM1 geht schon mal nicht, da kommt keine Reaktion. Ich bin mir nicht sicher bei der Taktfrequenz... ich bin bei UART und den Takten der absolute Neuling... muss ich beim Kontroller was einstellen? Danke! Ciao, Jens
J. W. schrieb: > Ich bin mir nicht sicher bei der Taktfrequenz... ich bin bei UART und > den Takten der absolute Neuling... muss ich beim Kontroller was > einstellen? Dann würde ich diese Unsicherheit als allererstes mal abstellen, wenn der Bootloader über kein Autobaud-Feature verfügt. Über die tatsächliche Taktfrequenz des µC darf es keine Unsicherheiten geben, da alle Timingsache davon abhängen. Und USART (egal in welcher Form) ist zu 99% eine Timing-Sache.
Karl Heinz Buchegger schrieb: > J. W. schrieb: > >> Ich bin mir nicht sicher bei der Taktfrequenz... ich bin bei UART und >> den Takten der absolute Neuling... muss ich beim Kontroller was >> einstellen? > > Dann würde ich diese Unsicherheit als allererstes mal abstellen, wenn > der Bootloader über kein Autobaud-Feature verfügt. > > Über die tatsächliche Taktfrequenz des µC darf es keine Unsicherheiten > geben, da alle Timingsache davon abhängen. Und USART (egal in welcher > Form) ist zu 99% eine Timing-Sache. Okay Karl Heinz, und da checke ich momentan minder viel, ich muss natürlich lernen, das Datenblatt richtig zu lesen. Ich verstehe irgendwie diese CHKSEL0 bis 3 nicht... was heißt das? Und dann kann ich die "Nominal Frequency" auf 8 MHz einstellen... ich stelle mir das total naiv vor: Der mC bekommt von mir das Komanndo: Du arbeitest jetzt mit keine Ahnung 8 MHz. So. Lieber vielleicht niederfrequenter, hauptsache es funktioniert. Nun soll das Ding kommunizieren. Über UART. Irgendwie logisch: Wenn das Ding zu langsam ist, dann funktioniert UART nicht... ist das so? Hast Du nen Tipp was ich einstelle oder verstehen muss, damit ich diese Kommunikation hinbekomme? Danke im Voraus! Jens
Karl Heinz Buchegger schrieb: > J. W. schrieb: > > Dann würde ich diese Unsicherheit als allererstes mal abstellen, wenn > der Bootloader über kein Autobaud-Feature verfügt. > > Über die tatsächliche Taktfrequenz des µC darf es keine Unsicherheiten > geben, da alle Timingsache davon abhängen. Und USART (egal in welcher > Form) ist zu 99% eine Timing-Sache. Das blöde ist halt: Ich habe keine Idee, wie ich nun wissen kann, was ich einstellen muss, da ja auf dem Putty keine Reaktion kommt. Vielleicht sollte ich irgendwelche Programme nutzen, die den RS232 des Computers lesen, was vom Controller kommt?
J. W. schrieb: > Okay Karl Heinz, und da checke ich momentan minder viel, ich muss > natürlich lernen, das Datenblatt richtig zu lesen. Ich verstehe > irgendwie diese CHKSEL0 bis 3 nicht... was heißt das? Studier im Datenblatt den Abschnitt über "System Clock and Clock Options" > Und dann kann ich > die "Nominal Frequency" auf 8 MHz einstellen... So einfach ist die Sache nicht. erst mal gilt es zu klären, woher der System Clock überhaupt kommt, wer ihn generiert. Da gibt es mehrere Möglichkeiten > ich stelle mir das total naiv vor: Der mC bekommt von mir das Komanndo: > Du arbeitest jetzt mit keine Ahnung 8 MHz. So. Lieber vielleicht > niederfrequenter, hauptsache es funktioniert. Nun soll das Ding > kommunizieren. Es ist relativ egal welche Frequenz es ist (ok, ganz egal ist es nicht. Bei manchen Taktfrequenzen geht sich kein ordentlicher Teiler für die UART aus). Aber erst nal musst du wissen, wie schnell dein µC tatsächlich getaktet wird. Das ist das um und auf. Nicht nur für UART sondern auch zb für die Timer. Wie willst du denn CTC-Werte auf Vorteiler abstimmen um bestimmte ISR Frequenzen zu erreichen, wenn du dir über die Ausgangsbasis des ganzen, die Taktfrequenz des Controllers nicht 100% im klaren bist? > nicht... ist das so? Hast Du nen Tipp was ich einstelle oder verstehen > muss, damit ich diese Kommunikation hinbekomme? Du musst verstehen, dass die Taktfrequenz in den meisten Fällen von einer Quelle kommt. Das kann sein * interner Generator * Quarz * Quarzoszillator Das sind deine 3 prinzipiellen Möglichkeiten für die Quellen, die die Aufgabe der Generierung des Systemtakts übernehmen können. Und je nach Quelle gibt es noch Unterkategorien, wie zb langsamer Quarz oder schneller Quarz.
Karl Heinz Buchegger schrieb: > J. W. schrieb: > > Studier im Datenblatt den Abschnitt über > "System Clock and Clock Options" > okay, klar noch viel zu lernen >> Und dann kann ich >> die "Nominal Frequency" auf 8 MHz einstellen... > > So einfach ist die Sache nicht. > erst mal gilt es zu klären, woher der System Clock überhaupt kommt, wer > ihn generiert. Da gibt es mehrere Möglichkeiten > Ich habe dieses Pollin-Board, da ist glaube ich ziemlich nix drauf. Ich möchte interne Taktung nehmen... wenn das so geht... >> ich stelle mir das total naiv vor: Der mC bekommt von mir das Komanndo: >> Du arbeitest jetzt mit keine Ahnung 8 MHz. So. Lieber vielleicht >> niederfrequenter, hauptsache es funktioniert. Nun soll das Ding >> kommunizieren. > > Es ist relativ egal welche Frequenz es ist (ok, ganz egal ist es nicht. > Bei manchen Taktfrequenzen geht sich kein ordentlicher Teiler für die > UART aus). Aber erst nal musst du wissen, wie schnell dein µC > tatsächlich getaktet wird. Das ist das um und auf. Nicht nur für UART > sondern auch zb für die Timer. Wie willst du denn CTC-Werte auf > Vorteiler abstimmen um bestimmte ISR Frequenzen zu erreichen, wenn du > dir über die Ausgangsbasis des ganzen, die Taktfrequenz des Controllers > nicht 100% im klaren bist? > > Ich weiß noch nicht, was CTC-Werte sind oder ISR-Frequenzen... ich dachte, ich könnte das im Kontroller einstellen, die interne Frequenz... >> nicht... ist das so? Hast Du nen Tipp was ich einstelle oder verstehen >> muss, damit ich diese Kommunikation hinbekomme? > > Du musst verstehen, dass die Taktfrequenz in den meisten Fällen von > einer Quelle kommt. Das kann sein > > * interner Generator > * Quarz > * Quarzoszillator > > Das sind deine 3 prinzipiellen Möglichkeiten für die Quellen, die die > Aufgabe der Generierung des Systemtakts übernehmen können. Und je nach > Quelle gibt es noch Unterkategorien, wie zb langsamer Quarz oder > schneller Quarz. Okay, ich habe halt dieses ganz simple Board, ich glaube, das hat überhaupt keinen externen Quarz... ich wollte die interne Taktung für die Kommunikation nehmen... absolutes Neuland... ich weiß, es gibt noch viel zu lernen... Aber danke schon mal für die Geduld! :)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.