ich will mit einem ATmega8 einen minimal Arduino bauen, der ohne Quarz auskommt. Dafür suche ich einen Arduino IDE "kompatiblen" Bootloader für den ATmega8, der mit 8Mhz intern getaktet wird und aus der Arduino IDE heraus beschrieben/geflasht/programmiert werden kann.
Vollständig Arduino-funktionskompatibel muss das nicht sein. Der ATmega8 wird wie ein AVR programmiert.
Welcher BL kommt dafür infrage?
Eignet sich Fastboot von Peter Dannegger dafür, bzw. ließe sich dafür anpassen? Wo findet man die neuste Version von Fastboot?
ich will mit einem ATmega8 einen minimal Arduino bauen, der ohne Quarz
auskommt. Dafür suche ich einen Arduino IDE "kompatiblen" Bootloader für
den ATmega8, der mit 8Mhz intern getaktet wird und aus der Arduino IDE
heraus beschrieben/geflasht/programmiert werden kann.
Der interne RC-Oszillator ist nicht ausreichend frequenzstabil dafür.
Warum nicht? Der BL berücksichtigt doch normalerweise eine Checksumme
und kann Kommunikationsfehler feststellen.
Und inwiefern hilft das? Ein gescheiterter Upload ist ein gescheiterter Upload. Daß man ihn anhand der fehlerhaften Prüfsumme bemerkt, ist nur ein schwacher Trost.
Ich würde dem ATMega8 einen Resonator oder Quarz spendieren. Alternativ den Upload über ISP machen. Den braucht man doch sowieso, um den Bootloader aufzuspielen.
Wenn Du mit der Arduino IDE arbeiten willst, benötigst Du sowieso ein "Hardware Paket", das den ATmega8 unterstützt. Da bietet sich dann der MiniCore (https://github.com/MCUdude/MiniCore) an, der alle ATmegaX8 unterstützt und zudem einen Bootloader mit adaptiver Baudrate mitbringt. Den muss man, wie schon bemerkt, natürlich mit einem ISP-Programmierer erstmal brennen.
Der interne RC-Oszillator ist nicht ausreichend frequenzstabil dafür.
Das stimmt natürlich. Aaaber: Man kann den Takt trimmen. Der Bootloader kann sich also auf den Takt des Senders abstimmen. Muss man halt bloß eine entsprechende Trimm-Routine in den BL einbauen.
Läuft dann so ab: erster Upload-Versuch schlägt mit einiger Wahrscheinlichkeit fehl, liefert aber genug Info für die Trimm-Routine im Bootloader. Zweiter Uploadversuch funktioniert dann.
Natürlich muß der Bootloader sich den gefundenen Korrekturwert irgendwo merken, wo er auch einen Reset übersteht. Interessanterweise überstehen RAM-Inhalte einen Reset. Nur unbedarfte C-Benutzer haben eventuell einen anderen Eindruck von der objektiven Realität...
Kommt allerdings dann die erfolgreich gebootete Anwendung zum Zuge, ist mit einiger Wahrscheinlichkeit der RAM-Inhalt des Bootloaders weg. Das muss der BL erkennen können und dann folgt halt wieder die Sequenz aus einem Fehlversuch und einem gelungenen Versuch.
Besser wäre also: Der Bootloader merkt sich den Korrekturwert im eigenen Flash-Bereich. Dann ist der persistent und zutreffend, so lange sich Betriebsspannung und Umgebungstemperatur nicht nennenswert ändern.
Man könnte den RC-Ozillsator mit OSCCAL kalibrieren. Wäre das persistent? Der RCO ist temperatur- und spannungsabhängig. Meiner Erfahrung nach ist er sehr genau und reproduzierbar, wenn er auf einen konstanten Betriebspunkt kalibriert ist.
Viele AVRs haben die Möglichkeit einer internen Temperaturmessung mit der man auf die momentane Temperatur kalibrieren könnte.
Ich würde ebenfalls den ATmega328pb empfehlen. Er ist ein verbesserter Ersatz für den ATmega8 und Massenware weil er auf den Arduinos verbaut ist.
Was spricht eigentlich gegen den Arduino-Bootloader? Oder habe ich da etwas überlesen?
Vielleicht etwas am Ziel vorbei, aber passend zum Thema. Hier ist noch ein interessanter Krypto-Bootloader der sich selbst den Takt sucht:
https://jtxp.org/tech/onewayloader.htm
Der interne RC-Oszillator ist IMHO deutlich besser als sein Ruf. Serielle Protokolle können die Schwankungen üblicherweise locker verpacken.
Man muss allerdings die UART-Register passend zur realen Frequenz vorbesetzen und darf nicht stumpf mit 8MHz rechnen (siehe Bild). Es sei denn man verwendet eine Vcc von genau 3,75V..
Bei sehr hohen Takten werden die Werte in den Registern leider sehr klein und das klappt nicht mehr sauber weil die Frequenzsprünge zu gross werden.
Das ganze funktioniert natürlich auch nur bei Temperaturen bei denen man selbst am Leben bleibt. Für ein Minimalsystem sollte das aber eine akzeptable Einschränkung sein.
Man muss allerdings die UART-Register passend zur realen Frequenz
vorbesetzen
Kann man denn den Upload in der Arduino IDE auf andere Frequenzen als die vorgegebenen 115200/57600 Baud umstellen? 250000 Baud wäre z.B. Vorteilhaft. Ein klassischer serieller Port vom PC kann das zwar nicht, aber die sind eh Geschichte, denke ich.
Kann man denn den Upload in der Arduino IDE auf andere Frequenzen als
die vorgegebenen 115200/57600 Baud umstellen? 250000 Baud wäre z.B.
Vorteilhaft.
Das hilft nicht bei der Instabilität und Drift des RC-Oszillators. Sowas hilft nur, die statische Fehlerrate des (miesen) Baudratengenerators der AVRs ohne "Baudratenquarz" zu reduzieren.
Aus dem Bauch heraus würde ich sagen dass man die 57600 Baud noch gerade so über die AVR-UART-Register hingeschoben bekommt. Bei höheren Takten nicht mehr. (Ausser bei 3,75V, was vmtl niemand verwendet)
Wie erwähnt halte ich die Drift über Temperatur für diesen Einsatz für weniger relevant.
Ich würde ebenfalls den ATmega328pb empfehlen. Er ist ein verbesserter
Ersatz für den ATmega8 und Massenware weil er auf den Arduinos verbaut
ist.
Hier möchte pro aktiv eingreifen, bevor es Missverständnisse gibt. Es gibt keinen originalen Arduino in Massenware mit ATmega328PB. Auf den orignalen UNO R3 und Nano sitzt der ATmega328P. P <> PB sind zwar nahezu identisch aber nicht gleich. Von Elektor gab einmal einen Versuch den ATmega328PB auf einen Elektor Uno R4 in den Massenmarkt zubringen, wurde eingestellt. Den ATmega328PB gibt es laut meines Wissens nur auf China Boards. Das ist okay, ich habe nichts dagegen. Wollte nur klarstellen wegen Arduino vs. Massenmarkt vs. 'PB'. Empfehlenswertes Board Package ist https://github.com/MCUdude/MiniCore
Das hilft nicht bei der Instabilität und Drift des RC-Oszillators.
Der interne Oszillator ist doch nicht instabil in dem Sinne, daß der massiven Jitter hat. Der hat eine sich fast statische langsam ändernde Abweichung vom Sollwert.
Kann man denn den Upload in der Arduino IDE auf andere Frequenzen als
die vorgegebenen 115200/57600 Baud umstellen? 250000 Baud wäre z.B.
Vorteilhaft. Ein klassischer serieller Port vom PC kann das zwar nicht,
aber die sind eh Geschichte, denke ich.
Hallo,
kann man in der boards.txt bzw. boards.local.txt ändern.
Warum? 20 Jahre alt, überteuert, es gibt mittlerweile viel bessere AVRs, die auch einen für UART ausreichend genauen und stabilen internen Oszillator mitbringen.
Siehe z.B. AVR32DD28-I/SP. Ob der "Arduino-kompatibel" ist, entzieht sich allerdings meiner Kenntnis. Falls nicht, wäre es ein Anlaß dafür, mal über den Arduino-Tellerrand hinauszugehen.
Der TO schrieb, daß er es rund um den ATMega8 (nicht -88, nicht -328xx) aufbauen will. Der einzige plausible Grund, der mir einfällt, ist daß er noch auf einer erklecklichen Anzahl dieses IC sitzt.
Was spricht eigentlich gegen den Arduino-Bootloader? Oder habe ich da
etwas überlesen?
Optiboot ist der (neue) Arduino-Bootloader für AVR. Für den ATMega8 definitiv die bessere Wahl gegenüber dem alten Arduino-Bootloader. Denn er braucht nur 512 Bytes Flash, der alte 2KB.
Man könnte den RC-Ozillsator mit OSCCAL kalibrieren. Wäre das
persistent?
Nein. Nahezu alle SFIO-Register (insbesondere jedenfalls OSCCAL) werden bei einem Reset mit Default-Werten geladen.
Bei OSCCAL gibt es noch die Besonderheit, dass der Default-Wert nicht für alle Devices gleich ist, sondern durch die werksseitige Kalibrierung festgelegt wird. Und diese Kalibrierung passt halt nur für die im DB angegebenen Randbedingungen. Dazu kommt noch, dass automatisch immer der Kalibrierungswert für 1MHz geladen wird, obwohl auch die für 2, 4 und 8Mhz verfügbar sind.
Die Kalibrierungswerte liegen in der signature row und müssen bei von 1MHz abweichender Taktkonfiguration durch das Programm selber von dort gelesen und dann an OSCCAL verfüttert werden.
Mit der Bemerkung des ATmega328pb auf den Arduinos habe ich wohl einen empfindlichen Nerv getroffen. Hier muss man ja auf jedes Wort achten :)
Trotzdem habe ich einige simpel-ATmega-Boards mit einem 328pb. Das Wort "Arduino" hätte ich wohl besser in Klammern gesetzt..
Ich finde es befremdlich, dass hier Fragen nach Software-Lösungen so häufig mit "nimm andere Hardware" beantwortet werden.
In den meisten Fällen ist die Hardware fest vorgegeben, oder sie wird vom Fragenden aus für ihn guten Gründen bevorzugt. Zum Beispiel, weil er sie schon hat, oder damit vertraut ist. Dann ist es scheiß-egal, ob ein neuerer Mikrocontroller stärker oder billiger ist. Die Softwarefrage ist mit solchen Antworten kein bisschen beantwortet. Thema verfehlt, setzen, 6.
Optiboot ist der (neue) Arduino-Bootloader für AVR. Für den ATMega8
definitiv die bessere Wahl gegenüber dem alten Arduino-Bootloader. Denn
er braucht nur 512 Bytes Flash, der alte 2KB.
Das waren sinnvolle Antworten zur Frage. Alle anderen empfinde ich als Klugscheißerei. Ja ich weiß, ich neige auch dazu und schäme mich dafür.
Warum nicht? Der BL berücksichtigt doch normalerweise eine Checksumme
und kann Kommunikationsfehler feststellen.
Meine Erfahrung ist, dass der interne R/C Oszillator bei 3,3V und Zimmertemperatur für 57600 Baud knapp gut genug ist. Ich habe damit beim Basteln nur selten Aussetzer gehabt.
Leider setzt Arduino inzwischen auf 115200 Baud, und das sehe nicht nur ich sondern auch Atmel wesentlich kritischer. Selbst mit Quarz ist das keine empfohlene Baudrate für 8 MHz (auch nicht für 16 MHz). Nur die fett hervorgehobenen Zeilen sind (mit Quarz!) empfohlen.
Wie gesagt wäre 250000 eine vorteilhafte Baudrate.
ich will mit einem ATmega8 einen minimal Arduino bauen, der ohne Quarz
auskommt.
Es war gestern Freitag.
Natürlich handle ich mir jetzt wieder viele Unkenrufer ein, aber ich will das Ansinnen mal übersetzen:
"Ich will einen total veralteten Mikrocontroller mit den neuzeitigen Sachen benutzen, habe aber gar keine richtige Ahnung von der Materie und weiß auch eigentlich gar nicht warum ich das will, da es ja einen viel besseren Nachfolger gibt.
Und weil ich keine Ahnung habe (und die KI mir möglicherweise auch keine Antwort geben wollte) sollen jetzt andere meine völlig bescheuerte Idee für mich umsetzen."
Man braucht keinen Bootloder, nicht mal für Arduino. Da erzeugt man die Binär Datei und läd die (z.B. mit dem Atmel Studio) direkt auf den Controller.
Der Threadstarter könnte ganz vielen Problemen entgehen, wenn er einfach auf einen Bootloder verzichten würde. AVRs kann man ganz wunderbar per ISP programmieren, die dazu nötige Hardware kostet nicht viel, Softwareunterstützung gibts dafür auch ...
Oh, und wenn er einen Bootloader in seinen AVR 'reinbekommen will, braucht er die ISP-Hardware sowieso.
Dann kann er die aber auch gleich für die eigentliche Arbeit verwenden. Und dann isses völlig wurscht, wie genau und bei welcher Frequenz der Taktgenerator arbeitet.
Harald, du ignorierst, dass der Stefan mit der Arduino IDE arbeiten möchte.
In dieser ist es nun mal vorgesehen, eine serielle Schnittstelle sowohl fürs' Debugging (für Textausgaben) als auch zum Hochladen zu benutzen. Das ist dort die bequemste Methode, weil das eben dem Grundkonzept von Arduino entspricht.
Eine zweite Schnittstelle zum PC bedeutet mehr Kabel, mehr Pins belegt und mehr Klicks zum Bedienen. Nicht jeder möchte das so tun.
Eine zweite Schnittstelle zum PC bedeutet mehr Kabel, mehr Pins belegt
und mehr Klicks zum Bedienen.
Das ist natürlich ein schreckliches Schicksal. Wieso eigentlich mehr Klicks? Stellt man nicht einfach ein, welcher Programmer genutzt werden soll, und fertig?
wurde 2005 von Massimo Banzi und David Cuartielles der erste Arduino,
der auf dem günstigeren ATmega8 basierte, entwickelt."
Klar und ich glaube ich gabe noch so einen Arduino.
Aber ist doch trotzdem überholt.
Wenn ich jetzt unbedingt so ein altes Teil nutzen wollte, weil ich vielleicht noch 1000 Stück davon habe, dann weiß ich aber wie es geht und frage da nicht die uC_KI.
wurde 2005 von Massimo Banzi und David Cuartielles der erste Arduino,
der auf dem günstigeren ATmega8 basierte, entwickelt."
Klar und ich glaube ich gabe noch so einen Arduino.
Aber ist doch trotzdem überholt.
Wenn ich jetzt unbedingt so ein altes Teil nutzen wollte, weil ich vielleicht noch 1000 Stück davon habe, dann weiß ich aber wie es geht und frage da nicht die uC_KI.
Oh, und wenn er einen Bootloader in seinen AVR 'reinbekommen will,
braucht er die ISP-Hardware sowieso.
Dann kann er die aber auch gleich für die eigentliche Arbeit verwenden.
Und dann isses völlig wurscht, wie genau und bei welcher Frequenz der
Taktgenerator arbeitet.
Das war das was ich mit "keiner Ahnung von der Materie meinte."
Gerade wollte ich doch mal wieder was mit Programmierung machen und lud
einen älteren Sketch.
Da kam eine Fehlermeldung. Nun bin ich schon wieder länger raus und
dachte mir, da frag ich mal die KI.
Es gibt schon einige Arduino Cousinen mit dem 328PB als uC. Da fällt mir momentan ein:
Watterott hat(te) einen Pro-Mini im Programm *)
Pollulo oder Star (da müsste ich nachschauen ob der Name stimmt) *)
Mindestens noch irgendein Chinesischer Nano *)
Noch ein Nano - erinnere mich nicht an den Namen *)
Eine eigene spezielle Pro-Mini Entwicklung von mir
*) Alle im eigenen Bestand
Der 1284er wäre m.M.n. eine bessere Wahl für Arduino an sich gewesen. Da hat man einfach mehr Ellenbogenraum. Leider war jener vergleichsweise für den vorgesehenen Hobbyist Markt zu teuer.
Die Bords aus China versehe ich alle mit Optiboot, weil diese Bords meist fast immer mit einem fossilen Bootloader ausgeliefert werden, der nicht Watchdog geeignet ist.
Viele China Klonen haben ohnehin einen (versteckten) 328bp (falsch bedruckt) drauf. Ein Aufdruck mit 328P bedeutet nucht unbedingt, dass es tatsächlich noch einer ist. Meist sind es nun 328bp uC. Das müsste man im Bedarfsfall prüfen.
Die neueren AVR wären in der 8-Bit Welt aber nun doch eine bessere Wahl für anspruchsvollere Anwendungen. Z.B. der AVR128DB48/64 ist da schon ein anderes Kaliber.
Ich versuchte es, klappt nicht. Es fehlen offenbar noch Dateien, die aus der Linux-Variante stammend früher klaglos, jetzt unter Win 11 überhaupt nicht mehr zur Mitarbeit zu bewegen sind. Auch ein Nachinstallieren neuerer zum Download angebotener *.dlls derselben bringt keinen Erfolg.
Auch ISP nach klassischer Art (6-polig) ohne Bootloader geht bei mir nicht über STK500 und Atmel Studio bei den erwähnten Targets. ATMega32U2 geht noch (include "m32u2def.inc"), andere "höhere" nicht mehr.
Aber: Nehme zum Beispiel einen Nano und mache ihn zum Programmer, indem ich den Arduino-Programmer-Sketch lade. Näheres auf der Webseite. Damit habe ich zum Beispiel den vorhandenen "old bootloader" durch den aktuelleren ersetzen können.
Viele China Klonen haben ohnehin einen (versteckten) 328bp (falsch
bedruckt) drauf. Ein Aufdruck mit 328P bedeutet nucht unbedingt, dass es
tatsächlich noch einer ist. Meist sind es nun 328bp uC. Das müsste man
im Bedarfsfall prüfen.
Das erklärt gerade einiges.
Danke für deinen Beitrag!
Optiboot ist der Hit des Tages.
In der Info*.txt ist der Mega 8 namentlich erwähnt.
Evtl. löst der auch das erwähnte Atmel Studio Problem.
Muss 'mal ausprobieren.
Auch ISP nach klassischer Art (6-polig) ohne Bootloader geht bei mir
nicht über STK500 und Atmel Studio bei den erwähnten Targets. ATMega32U2
geht noch (include "m32u2def.inc"), andere "höhere" nicht mehr.
Hast du schon die Treiberinstallation über Zadig probiert?
Versuche das mal und auch mit Zadig muss die Vorgabe nicht zum Erfolg führen. Da musst du auch sonst die anderen Treiber (drei Möglichkeiten) installieren, wenn es mit der Vorgabe nicht klappt.
Ich habe sehr wohl verstanden dass ein Bootloader gesucht wird. Und sehe aber auch dass der mit neuen Problemen daher kommt.
Könnte man die Arduino-IDE nicht auch mit einem ISP-Programmer kombinieren? Die IDE baut ganz normal das Hex-File und danach nimmt man eine kleine Batch-Datei um es per AVRdude zu programmieren. Vielleicht lässt sich das Batch sogar noch irgendwie in die IDE "einbauen"?
Ich habe sehr wohl verstanden dass ein Bootloader gesucht wird.
Das stimmt Christian und Du warst auch nicht gemeint. Der Tipp zu OWL war echt super, nochmals danke. Dem OWL Entwickler sollte man echt was spenden. OWL sehe ich mir auf jeden Fall genauer an. Habe mir alles dazu schon runtergeladen.
Einen Arduino Uno/Nano etc in einen ISP flasher umzufunktionieren und den BL auf den ATmega8 zu flashen ist auch kein Problem. Und dass es mit einem ATmega8 mit 8MHz intern ev. zu wie auch immer gearteten Arduino-Funktionsinkompatibilitäten kommen kann, habe ich ja auch gleich zu Anfang vermutet.
Ich nutze die Arduino IDE einfach nur zum entwickeln von AVR C Code, Compilieren und "übertragen" der SW auf den Uno bzw. ATmega8 minimal. Daher kann es gut sein, dass ich die möglichen Einschränkungen gar nicht mitbekomme.
Und falls doch, nehme ich den von Dir skizzierten Weg oder gehe zurück auf reines manuelles ISP.
also wenn man das so liest vom TO und Christian wird einem Angst und Bange. Viel zu viele Vermutungen mit zu wenig Wissen dahinter.
Und dass es mit einem ATmega8 mit 8MHz intern ev. zu wie auch immer
gearteten Arduino-Funktionsinkompatibilitäten kommen kann,
habe ich ja auch gleich zu Anfang vermutet.
Wie kommt man zu so einer Vermutung? Leute, informiert euch doch erstmal oder fragt nach. Aber haut nicht ohne Ende solche Dinger raus.
https://github.com/MCUdude/MiniCore
Interne 8MHz auswählen, fertig.
Du meine Güte, Leute was habt ihr denn nur? Seid ihr nur zum Stänkern hier? Könnt ihr keine normalen Sätze mehr formulieren, ohne Aggression und ohne herablassend zu werden?
"Könnte" ist eine Höflichkeitsformulierung. Man bringt seinen Gesprächsgegenüber durch Hinweise in die Lage eine Lösung selbst zu finden ohne selbst als Besserwisser dazustehen.
Ich denke der TE hat genug Anregungen bekommen.
Die Herren Oberschlau können sich gerne weiter über Banalitäten angiften. Ich verabschiede mich.
Das gilt nur für "Ich möchte einen Bootloader installieren"...
Da hast du mich aber gewaltig beschäftigt.
Vor langer Zeit hatte ich das mal gemacht, aber ehrlich gesagt weiß ich nicht, ob es da auch nicht geklappt hat.
Selbst mit einem 328P kommt noch die Meldung nach der Signatur.
Diverse Hinweisen bin ich schon nachgegangen, ohne Erfolg.
Also bis jetzt klappt es nicht. Gut, für jeden der sowieso ein Programmer hat, ist es eh witzlos das über die IDE zu machen, aber funktionieren sollte es schon. Da ich sowohl den AVR MKII und den AVR-ICE habe, sollte es doch eigentlich klappen. Tut es tatsächlich leider nicht.
Aber ich bleibe dran.
Nachtrag:
Es klappt! Nachdem ich die IDE neu installiert hatte und nun den Rechner neu gestartet habe, konnte ich einen 328P mit dem AVR-ICE programmieren.
Funktioniert im Moment nur mit dem 328P.
Entsprechend unterstützt die IDE den auch nicht direkt.
Das ist wohl so, aber es gibt da doch Möglichkeiten. Hatte das gestern Nacht noch gelesen. Werde ich aber nicht weiter verfolgen, denn ich würde sowieso nicht über einen Programmer in der Arduino IDE programmieren.
Interessant war aber, dass ich letztendlich sowohl den ICE am PC angeschlossen haben konnte als auch USB (muss zur Stromversorgung, weil der Programmer nicht den Controller speißt). Und ich konnte, beides angeschlossen, sogar abwechselnd über USB oder den ICE programmieren.
wie empfohlen, habe ich MiniCore iinstalliert um den passenden BL (8 MHz intern) auf den ATmega8-16PU zu flashen. Installation und Menüauswahl ohne Probleme. Die Toolkette ist: Arduino IDE 2.3.8, MiniCore 3.1.2 und Arduino Uno R3 als ISP.
Das Flashen klappte aber leider nicht, da AvrDude die Seriennummer des ATmega8-16PU nicht erkennt. Im log steht die Seriennummer sei 00 00 00, erwartet würde 1E 93 07. Was läuft da falsch?
Der log-output:
Error: invalid device signature
Error: expected signature for ATmega8 is 1E 93 07
double check connections and try again, or use -F to carry on regardless
Failed chip erase: uploading error: exit status 1
"C:\Users\PC\AppData\Local\Arduino15\packages\MiniCore\tools\avrdude\8.0-arduino.1/bin/avrdude" "-CC:\Users\PC\AppData\Local\Arduino15\packages\MiniCore\tools\avrdude\8.0-arduino.1/etc/avrdude.conf" -v -patmega8 -cstk500v1 -PCOM3 -b19200 -e -Ulock:w:0xff:m -Uefuse:w:{bootloader.extended_fuses}:m -Uhfuse:w:0b11000111:m -Ulfuse:w:0b10111111:m
Avrdude version 8.0-arduino.1
Copyright see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is C:\Users\PC\AppData\Local\Arduino15\packages\MiniCore\tools\avrdude\8.0-arduino.1\etc\avrdude.conf
Using port : COM3
Using programmer : stk500v1
Setting baud rate : 19200
AVR part : ATmega8
Programming modes : SPM, ISP, HVPP
Programmer type : STK500
Description : Atmel STK500 v1
HW Version : 2
FW Version : 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.0 us
XTAL frequency : 7.372800 MHz
AVR device initialized and ready to accept instructions
Device signature = 00 00 00 (retrying)
Device signature = 00 00 00 (retrying)
Device signature = 00 00 00
Error: invalid device signature
Error: expected signature for ATmega8 is 1E 93 07
double check connections and try again, or use -F to carry on regardless
Für den Anfang könntest du prüfen, ob die Reset Leitung beim Flashen auf Low geht. Wenn ja, kontrolliere ob die SCK Leitung ein Taktsignal liefert. Wenn ja, kontrolliere ob der Pegel auf der MOSI Leitung mehrfach wechselt. Und erst danach macht es Sinn, die Antwort vom Target zu prüfen, also die MISO Leitung.
Wenn nur der letzte Schritt scheitert, überlege dir, ob alle Voraussetzung geschaffen sind, dass dein Target funktionieren kann. Prüfe die Stromversorgung: Sind beide VCC/GND Päärchen versorgt? Abblock-Kondensator vergessen?
Wenn der mal für einen Quarz konfiguriert wurde musst du auch einen anschließen. Oder speise ein Taktsignal an XTAL1 ein (1-4 MHz).
Danke Hans, ich verwende die Definitionen wie in Deinem Screenshot. Die Verkabelung scheint mir OK. Ich prüfe sie aber noch Mal. Bin gerade nicht am Rechner und liefere Fotos nach. Melde mich wieder.
Könnte es sein, dass ich den Atmega8 verfused habe? Selbst Hand angelegt oder was geändert habe ich nicht. Lediglich das im Minicore vorhandene in der Arduino IDE ausgewählt (es sei denn, ich habe mich da bei den vielen Versuchen mal vertan...).
Für den Anfang könntest du prüfen, ob die Reset Leitung beim Flashen auf
Low geht.
Der berühmte 10µF Elko.
Quelle KI:
"...Wenn Sie einen Arduino (wie den Uno) als ISP-Programmer (In-System Programmer) nutzen möchten, dient der 10µF Elko (Kondensator) dazu, den automatischen Reset des Programmierer-Boards zu unterdrücken. Dadurch wird verhindert, dass der PC beim Start des Programmiervorgangs in den Bootloader springt..."
/KI
Wenn Sie einen Arduino (wie den Uno) als ISP-Programmer (In-System
Programmer) nutzen möchten, dient der 10µF Elko (Kondensator) dazu, den
automatischen Reset des Programmierer-Boards zu unterdrücken.
Die sollten endlich mal ihre Bilder aktualisieren, denn der Kondensator ist nur beim Arduino Mega eingezeichnet. Das ist so ein alter Hut! Man könnte meinen, der Autor habe Spaß daran, daß Anfänger immer wieder daran scheitern.
Unter anderem deswegen hatte ich nach Fotos vom Aufbau gefragt. Aber wer nicht will, der hat schon.
Hab noch was gefunden:
In der Programmer.ino, die ich erfolgreich anwendete, steht oben im Kommemntar:
Zitat:
ArduinoISP
// Copyright (c) 2008-2011 Randall Bohn
// names rather than the modern CIPO/COPI names.
// For further details, see https://docs.arduino.cc/learn/communication/spi
//
// This sketch turns the Arduino into a AVRISP using the following Arduino pins:
//
// Pin 10 is used to reset the target microcontroller.
//
// By default, the hardware SPI pins MISO, MOSI and SCK are used to communicate
// with the target. On all Arduinos, these pins can be found
// on the ICSP/SPI header:
Zitat Ende
Der Resetanschluss am Target ist auch zu beachten.
Nicht einfach die 6-poligen Stecker 1:1 direkt verbinden.
ciao
gustav
P.S.: Vielleicht mache ich gleich nochmal 'nen aktuellen Test und mache aussagekräftige Bilder. Aber ich hab nur "Nanos" V3-er.
Aber wenn der Bootloader einen Quarz haben
will, dann musst du jetzt einen anschließen.
Hans , das ist es, hier liegt der Hund begraben! Ich hatte zuvor einen ATmega8 mit 8 Mhz intern ohne Quartz geflasht. Das klappt auf Anhieb. Anschliessend wollte ich einen weiteren Atmega8 mit 16 Mhz Bootloader flashen und habe ihn einfach in den Aufbau ohne Quartz gesteckt....
Wie gesagt, bin grad woanders. Bilder kann ich gerade nicht liefern
Vermutlich ist der Kondensator jedich gerade nicht der Knackpunkt denn die Kommunikation zwischen PC und ISP Firmware scheint ja grundsätzlich zu laufen.
Die Fehlermeldungen deuten auf ein Problem weiter hinten in der Kette hin: Das Target antwortet nicht.
Man könnte den RC-Ozillsator mit OSCCAL kalibrieren. Wäre das
persistent?
Nein. Nahezu alle SFIO-Register (insbesondere jedenfalls OSCCAL) werden
bei einem Reset mit Default-Werten geladen.
Ich habe mal ein kleines Projekt gemacht um den OSCCAL Wert an die serielle Gegenseite anzupassen, so dass die Bitraten-Abweichung möglichst klein ist. Den ermittelten Wert habe ich dann direkt im Code vom Optiboot gespeichert. Natürlich könnte man Wert den auch im EEPROM speichern und im Haupt-Programm immer wieder nachkalibrieren. Wenn sich die Umgebungstemperatur ändert ist das ggf. notwendig.
Damit war ein Upload mit "115200" Baud (oder das was die Gegenstelle tatsächlich darunter versteht) mit dem internen Oszillator möglich.
Allerdings lief die CPU nicht mehr mit 8 MHz sondern mit ca. 8,3 MHz.
Heute würde ich wohl eher Baudraten verwenden, die sich besser mit den Teilern realisieren lassen wie z.B. 100000 bps.
Allerdings lief die CPU nicht mehr mit 8 MHz sondern mit ca. 8,3 MHz.
Ja, logisch. Genau so sollte das sein. Und wen stört's, wenn die CPU mit 8.2944MHz läuft? Man braucht das dann doch bloß auch noch dem Compiler sagen und alles ist gut.
Eine hochgenaue Uhr wird ja wohl sowieso niemand mit dem internen Takgenerator als Zeitbasis bauen wollen.
Und übrigens: für die gebootete Anwendung kann der Bootloader OSCCAL ja auch vor deren Start wieder auf den Kalibrierwert zurücksetzen, wenn die unbedingt 8MHz benötigt.
Damit war ein Upload mit "115200" Baud (oder das was die Gegenstelle
tatsächlich darunter versteht) mit dem internen Oszillator möglich.
Allerdings lief die CPU nicht mehr mit 8 MHz sondern mit ca. 8,3 MHz.
Das würde bedeuten das dein Quelltakt mit 8,3MHz läuft.
