Hallo zusammen, ich möchte einen Atmega32u4 auf meinem eigenen Board verwenden und dort den Arduino Bootloader flashen. Da meine Systemspannung 3.3V beträgt habe ich einen 8MHz Quarz vorgesehen. Nun bin ich nicht ganz sicher wie ich mit dem HWB Pin umgehen muss und ob mein Vorhaben überhaupt mit einem 8MHz Quarz funktioniert. In dem Beitrag hier heißt es, dass der Atmega32u4 default mit 16MHz läuft: Beitrag "Re: ATMEGA32U4 scheint nicht anzuschwingen, was tun?" Daraus werde ich trotzdem nicht ganz schlau. Also: Kann ich bei einem Atmega32u4 bestückt mit einem 8MHz Quarz per ISP den Arduino Bootloader flashen? Falls ja, wie muss hierbei der HWB Pin beschaltet sein? Wie muss der HWB Pin beschaltet sein, damit ich nach (angenommen) erfolgreichem Flashen des Arduino Bootloaders per USB aus der Arduino IDE Sketches auf den Atmega32u4 programmieren kann? Vielen Dank im Voraus für eure Hilfe! Gruß elektricar
D. M. schrieb: > In dem Beitrag hier heißt es, dass der Atmega32u4 default mit 16MHz > läuft: Der Atmega32u4 läuft "default" ab Werk mit dem internen OSC und Div/8 - also mit 1Mhz. Zum Rest: warum zum Geier willst du den Mega32u4 mit dem Arduino BL kastrieren?!
Hi Rene K. schrieb: > warum zum Geier willst du den Mega32u4 mit dem Arduino BL kastrieren?! Denke, daß Er So per 'Arduino' programmieren kann und das Steinchen dann trotzdem macht, was Er will. Spontan aus der Luft gegriffen - also ohne Glaskugel, könnte aber was dran sein. MfG
Leider falsch geraten :P Ich liebe es einfach in meiner Freizeit Mikrocontroller zu kastrieren... Es wäre trotz meiner sadistischen Mikrocontroller Züge super wenn jemand meine beiden Fragen beantworten könnte!
Tja weil er nicht in der Lage ist sich einen eignen Bootloader zu bauen ;) Das geht aber leichter als gedacht mit dem LUFA Projekt. http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/_page__alternative_stacks.html Die 48MHZ für den USB werden intern durch ein PLL erzeugt. Die Quelle kann man konfigurieren. Wichtig ist eben nur die richtige Konfiguration für 8MHZ. Per copy and paste geht das in die Hose -> der Arduino Bootloader müsste wahrscheinlich ohnehin verändert werden.
Wenn du deine Freizeit nutzen würdest um die Antworten auf deine Fragen zu lesen anstatt MCs zu kastrieren, würdest du feststellen das eine Frage bereits beantwortet ist. Zur zweiten Frage: Der Mega32u4 Arduino Bootloader arbeitet mit einer Sequenz (Per Terminal mit 200 Baud verbinden und 2 sec halten, dann geht er in den Bootloader Mode, macht einen anderen COM auf zum flashen) und nutzt, soweit mir bekannt ist, nicht den HWB Pin. Ansonsten einfach mal bei den Einschlägigen Pro Micro Clonen und Leonardo Boards nachschauen wie es dort gelöst ist. Ansonsten, lese das DB des Mega32u4 zur HWB Beschaltung. Dort stehen auch die Factory-Def drinnen mit denen er ausgeliefert wird. Und weiterhin: dämliche Idee, wenn du die Arduino Umgebung nicht nutzt - wie du sagtest - da gerade den Arduino BL drauf zu ziehen. Da gibt es so schöne DFU Loader für. Gerade der Arduino BL für den Mega32u4 ist sowas für den Ar*#€. (Gerade wegen den Umstand der doppelten COM und den Max. 2sec Zeit um das Flashen zu starten) gehört dieser auf den Hinterhof der Arduino Geschichte.
Er wird auch Schiffbruch erleiden. Ich hatte bei meinen Projekt den Originalen Bootloader noch oben. Bis ich Festellen musste das einige Dinge wie Timer oder Vektoradressen verändert wurden. Offenbar um sie an die Arduino IDE anzupassen. Ewt. ist er deswegen für den "Ar*#€" ...
Das gibt es doch nicht! Wie asozial ist das denn? Anstatt dem TO die Frage folgendermaßen richtig zu beantworten: /HWB auf Gnd und den Bootloader von LilypadUSB (der ist für 8MHz) über die ArduinoIDE per ISP mit (z.B. USBasp) flashen und fertig! Aber nein, stattdessen holen sich einige einen runter und bewerten mich zeitgleich negativ!
Ich habe heute mal meine Spendierhosen an. Bitte schön, mit dem ISP drauf brennen und dann den Code per Flip 3.4.x irgendwas hochladen. Der Bootloader wird aufgerufen wenn man am Arduino Micro die Reset taste drückt dann blinkt die LED auf dem Board und dann wird der USB Core gestartet, der Code kann dann mit Flip hochgeladen werden. Der Bootloader ist 4K groß und schreibt den Code oberhalb rein. Dein Code ab Adresse 0x0000 wie gewohnt linken aus ob der Bootloader nicht da wäre. Ohne drücken der Reset Taste springt dieser sofort ins Programm. Das Atmel Studio Projekt auf Anfrage... Eben nicht! Er wird mit den Arduino Bootloader nicht glücklich. Wenn er ISRs benutzen will macht er eine Bauchlandung. Schau in den Code des Bootloaders dann hat man keinen Bock mehr diesen zu benutzen da die Programme inkompatible zu allem anderen werden. Es dürfte auch mit 8MHZ laufen da USB_OPT_AUTO_PLL gesetzt ist, sollte der Clock wurst sein. Es könnte nur langsamer Blinken :)
:
Bearbeitet durch User
Marc H. schrieb: > folgendermaßen richtig zu beantworten: > > /HWB auf Gnd und den Bootloader von LilypadUSB (der ist für 8MHz) über > die ArduinoIDE per ISP mit (z.B. USBasp) flashen und fertig! Kann man in Arduino eine Hex direkt über ISP flashen?! ? Wäre mir neu.
leider nicht.. naja bis auf den Bootloader denn kann man mit einen ISP neu flashen über die IDE. Der Bootloader ist aber kein Geheimnis und baut auf den Code vom Hersteller auf. Der Rohrkopierer dabei ist das man ein Script braucht der die Serial mit 1200baud öffnet und schließt damit der Bootloader startet. Die unterschiedlichen Serial Ports bei den Boards haben die Ursache vor allem darin das man A: einmal mit den CDC der Arduino IDE kommuniziert. B: mit dem Bootloader. Die CDC löst dann einen Reset aus der den Bootloader aufruft. Deswegen ist ja der Code sehr groß auch wenn man nur das Blink Blink übersetzt. Da ist ein Haufen Ballast mit drin.
Hallo zusammen, vielen Dank für die Antworten. Vielen Dank auch an Marco H. für den Bootloader, ich möchte jedoch eigentlich keinen "eigenen" Bootloader sondern einen, der mit den Arduino Libraries von Grund auf kompatibel ist. Deshalb würde ich gerne den originalen nutzen. Falls die von Marc Horby beschriebene Vorgehensweise nun wirklich möglich ist, würde ich das so machen. Ist eben nur so, dass ich gerade eine Board designe und nachher es blöd wäre, wenn es gar nicht laufen kann. Ich werde eine Brücke am HWB Pin vorsehen, aber eigentlich könnte dieser in meinem Fall dauerhaft auf GND gezogen werden?
Beachte aber die Hinweise das dort einige Sachen umgebogen wurden. Schon bei einer ISR Routine wird es Probleme geben.
Beitrag #5139312 wurde von einem Moderator gelöscht.
Marco H. schrieb: > Beachte aber die Hinweise das dort einige Sachen umgebogen wurden. Schon > bei einer ISR Routine wird es Probleme geben. Das könnte in dem Fall wirklich zum Problem werden, da ich schon vorhabe ISRs zu benutzen... Gibt es denn eine Alternative mit Arduino Bootloader, 3.3V Versorgung und der Möglichkeit über USB zu flashen ohne dabei einen weiteren uC verbauen zu müssen?
Verwendet der Bootloader nicht seine eigene Interrupt Sprungleiste? So wie die meisten anderen Arduino Bootloader auch... Wenn ich mir den generierten Assemblercode meiner Testapplikation anschaue, dann sehe ich keinen einzigen Sprung welcher in den Bootloader zeigt. Ich halte es also für gelogen, dass der Bootloader Interruptvektoren der Applikation belegt.
D. M. schrieb: > Falls die von Marc Horby beschriebene Vorgehensweise nun wirklich > möglich ist, würde ich das so machen. Ist eben nur so, dass ich gerade > eine Board designe und nachher es blöd wäre, wenn es gar nicht laufen > kann. Mch doch den /HWB-Pin mit zwei 0402er-Widerstandspads einmal gegen GND und einmal gegen VCC. So kannst du jumpern.
Alex W. schrieb: > D. M. schrieb: >> Falls die von Marc Horby beschriebene Vorgehensweise nun wirklich >> möglich ist, würde ich das so machen. Ist eben nur so, dass ich gerade >> eine Board designe und nachher es blöd wäre, wenn es gar nicht laufen >> kann. > > Mch doch den /HWB-Pin mit zwei 0402er-Widerstandspads einmal gegen GND > und einmal gegen VCC. So kannst du jumpern. Das ist schon geplant. Die einzige Frage die nun noch offen ist, ist ob die ISRs Probleme machen werden oder nicht. Und falls ja, ob es eine geeignete Alternative gibt. >Gibt es denn eine Alternative mit Arduino Bootloader, 3.3V Versorgung >und der Möglichkeit über USB zu flashen ohne dabei einen weiteren uC >verbauen zu müssen?
D. M. schrieb: > Die einzige Frage die nun noch offen ist, ist ob die ISRs Probleme > machen werden oder nicht. Welche Probleme hättest du denn gerne?
Marco H. schrieb: > Eben nicht! Er wird mit den Arduino Bootloader nicht glücklich. Wenn er > ISRs benutzen will macht er eine Bauchlandung. Schau in den Code des > Bootloaders dann hat man keinen Bock mehr diesen zu benutzen da die > Programme inkompatible zu allem anderen werden. >Beachte aber die Hinweise das dort einige Sachen umgebogen wurden. Schon >bei einer ISR Routine wird es Probleme geben. Diese hier :)
D. M. schrieb: > Diese hier :) Habe ich eben schon als Unwahrheit entlarvt. Bei einem leeren Arduino Programm, mit setup()und loop() werden 3 Vektoren belegt. 2 USB Vektoren und 1 Timer Vektor. Keiner davon zeigt in den Bootloader (siehe Anhang in einem der vorherigen Posting von mir) Bei einem leeren Arduino Programm, mit main() wird kein Vektor belegt. > da die Programme inkompatible zu allem anderen werden. Das ist natürlich ein ebensolcher Schwachsinn!
Arduino F. schrieb: > D. M. schrieb: >> Diese hier :) > Habe ich eben schon als Unwahrheit entlarvt. > > Bei einem leeren Arduino Programm, mit setup()und loop() werden 3 > Vektoren belegt. 2 USB Vektoren und 1 Timer Vektor. > Keiner davon zeigt in den Bootloader > (siehe Anhang in einem der vorherigen Posting von mir) > > Bei einem leeren Arduino Programm, mit main() wird kein Vektor belegt. > >> da die Programme inkompatible zu allem anderen werden. > Das ist natürlich ein ebensolcher Schwachsinn! Super, danke für die Klarstellung! Nun kann ich also mit dem PCB Design anfangen! :)
Ich habe damals den Arduino Bootloader noch oben gehabt und es wurden keine ISR Funktionen aufgerufen. Auf Nachfrage wurde mir gesagt das dort vermutlich die Vektor Adressen verändert wurden. So dann habe meinen eigenen Bootloader gebaut und die ISR Funktionen liefen sofort. Geprüft habe ich das nicht. Da es mit meinen eigenen Bootloader aber funktionierte und mit dem Arduino nicht ging ich davon aus das diese Information korrekt sein muss. Ich lass mich auch gerne vom Gegenteil überzeugen.
Marco H. schrieb: > Ich lass mich auch gerne vom Gegenteil überzeugen. Das kann ich dir liefern! Schaue ins Datenblatt: http://www.atmel.com/Images/Atmel-7766-8-bit-AVR-ATmega16U4-32U4_Datasheet.pdf Du findest im MCUCR das IVCE und das IVSEL Bit. Diese ermöglichen 2 Interrupt Sprungtabellen in einem System. Eine für die Anwendung, und eine für den Bootloader. Das wird in der Arduino Welt auch auch so genutzt. Damit sind Bootloader und Anwendung vollkommen getrennt voneinander. Sie sind Nachbarn im Speicher, mehr auch nicht. Sie haben keine Chance sich ins Gehege zu kommen. Überzeugt?
Ja schon aber warum wurde die ISR Funktion nicht aufgerufen mit Arduino Bootloader? Ohne und mit meinen schon. Also am Code kann es nicht gelegen haben. Der Code lief bis auf das die ISR nicht Aufgerufen wurde. Ich glaube wir sollten das noch mal Testen. Den Arduino Bootloader zu verwenden macht aus meiner Sicht auch wenig Sinn.
Marco H. schrieb: > Ja schon aber warum wurde die ISR Funktion nicht aufgerufen mit Arduino > Bootloader? Das kann ich dir nicht sagen! Und ich sehe auch nicht, wie ein Bootloader ISRs verhindern kann. Klarer: Nach einem Reset darf erst der Bootloader. Wenn der Bootloader durch ist, ist die Anwendung dran. Dann ist der Bootloder ein totes Stück Code am oberen Speicherende. Da beide ihre eigene Interruptsprungleiste haben und die Anwendung volle Macht über alle Register, welche IRQs betreffen, hat, gibt es kein einziges Argument, welches das Versagen der Anwendung, bestätigen könnte. -------- > Ich glaube wir sollten das noch mal Testen. Ich habe den Beweis hier vor mir liegen! Meine ISR auf dem Leonardo funktionieren. In vielen Variationen. Ohne jede Ausnahme. Ein ATMega32U4 mit Arduino Bootloader. ------- Ich glaube dir, dass du den Effekt so gesehen hast. Aber ich sehe auch, dass du den Fehler an der falschen Stelle gesucht/gefunden hast. > Also am Code kann es nicht gelegen haben. Ja, nee, ist klar! Natürlich ist es einfacher andere (den Bootloader) für irgendwas verantwortlich zu machen, als das eigene Geschreibsel. Und wenn man das dann nicht mehr in Frage stellt, hat man die Ursache gefunden. Und wenn man die Ursache gefunden hat, dann kann man das im Forum als Fakt präsentieren. Heutzutage nennt man das dann alternative Fakten, glaube ich... Übrigens, zum testen: Du könntest mal den Fehler verursachenden Code zeigen. Dann habe ich eine Chance, das zu testen.
Der Code war simple. Timer mit OFV ISR. Da beim eigentlichen Projekt schon die ISRs nicht funktionierten habe ich es mit einen simplen Code versucht. Das Projekt (RDM Device) läuft nun mit meinen eigenen Bootloader problemlos.
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.