Hallo, um mich auch etwas mit Mikrocontrollern zu beschäftigen und meine Kenntnisse hierzu vertiefen hatte ich mir bei E-Bay dieses Board gekauft. http://www.ebay.de/itm/New-Minimum-Development-Board-Core-System-Shield-Board-for-Atmega32-Mega32-AVR-/261121351546?pt=LH_DefaultDomain_0&hash=item3ccc0b9f7a Mir erschien es ausreichend um erste Gehversuche zu machen. Aber wenn man etwas kauft von dem man keine kauft von dem man keine Ahnung hat... Und da es so billig war war natürlich auch nichts an Dokumentation dabei. Ich hatte mir halt gedacht das ich mit dem Board erste einfache Projekte ausprobieren kann. Ich kann das Board zwar an meinen PC anschließen aber ich bekomme irgendwie keine Verbindung zustande. Die Power-LED leuchtet zwar und mein Window erkennt auch ein USB-Gerät. Aber keiner der Treiber aus der Arduino Software Paket lies sich installieren. Kann mir jemand einen Tipp geben was ich da falsch mache Schon mal im voraus vielen Dank#
Angehängte Dateien:
-
Mini_Board.JPG
260 KB
Hi, das ist kein Arduino Board! USB dient primär zur +5V Gewinnung - Du benötigst einen ISP/ JTag Programmer.
Hi Michael, könnte sein, dass da als Firmware etwas benutzt wird, was auf dem V-USB Stack von www.obdev.at basiert. Es gibt da wohl einige USB-Bootloader, z.B. BootloadHID oder usbasploader. Von letzterem wird behauptet, er wäre (teilweise) zu Arduino kompatible, was auch immer teilweise bedeuten soll. Ich würde mal in diese Richtung forschen... die USB-Datenleitungen sind ja am AVR angeschlossen. Viel Erfolg Hermann-Josef
Hermann-Josef schrieb: > könnte sein, dass da als Firmware etwas benutzt wird Die Beschreibung auf der ibee-Seite sagt was anderes: (without bootloader Source Code) Da ist wohl ein leerer Controller drauf. Wie schon gesagt: Uwe S. schrieb: > das ist kein Arduino Board! > USB dient primär zur +5V Gewinnung - Du benötigst einen ISP/ JTag > Programmer. mfg.
Michael Dauber schrieb: > Ich kann das Board zwar an meinen PC anschließen aber ich bekomme > irgendwie keine Verbindung zustande. Die Power-LED leuchtet zwar und > mein Window erkennt auch ein USB-Gerät. Tja, wenn das so ist, dann wäre es sehr nützlich, wenn du auch noch geposted hättest, welches USB-Gerät genau Windows denn nun erkennt.
Thomas Eckmann schrieb: >> könnte sein, dass da als Firmware etwas benutzt wird > Die Beschreibung auf der ibee-Seite sagt was anderes: > (without bootloader Source Code) Dann könnte Windows aber kein USB-Gerät erkennen. Oder genauer: es würde zwar die Präsenz eines USB-Gerätes erkennen, aber auch umgehend vermelden, daß dieses nicht funktioniert. Davon schrieb der OP aber nix. Er schrieb nur was davon, daß ein Gerät erkannt werden würde. Aber na klar: Fehlerbeschreibungen Unwissender lassen in aller Regel den entscheidenden Knackpunkt aus. Also gut möglich, daß der Atmel wirklich völlig nackt ist. Dann ist das Board allerdings voll für'n Arsch. Ein Platte Lochraster und ein Atmel im DIL-Gehäuse von den üblichen Verdächtigen wäre billiger gewesen und hätte genausoviel gekonnt...
Möchte ja nicht Haare spalten, c-hater schrieb: >>> könnte sein, dass da als Firmware etwas benutzt wird >> Die Beschreibung auf der ibee-Seite sagt was anderes: >> (without bootloader Source Code) aber Source Code != bootloader, also könnte ein Bootloader drauf sein. Ich gebe c-hater recht, der OP hätte dazu noch etwas mehr Infos liefern können. Falls etwas 'Vernünftiges' erkannt wird, wäre USB-Device und Vednor-ID hilfreich. So es denn einen Bootloader gibt. Gruß Hermann-Josef
Ich bin auch an so ein Board geraten: Beim Drücken der Taste RST auch die Taste S4 drücken und RST loslassen. oder anders ausgedrückt: Wenn RST freigegeben wird, und S4 noch gedrückt ist, geht das Board in den bootload-Betrieb. Gezeigt wird diese Bereitschaft durch Blinken einer LED im Sekundentakt. Die Software HIDBootFlash muss auf dem PC installiert sein, damit kann man dann Vendor-ID lesen und ein .hex file aufspielen. Vorsicht bei Verwendung der ISP-Schnittstelle: Damit hat man schnell den bootloader gelöscht. Dann aber kann man (theoretisch) den bootloader seines Vertrauens draufspielen. M.E. Eigentlich ein recht ordentlich ausgestattetes board, nur eben keine Spur von Unterstützung vonseiten des Herstellers. Unter JY-MCU lässt sich Einiges ergoogeln.
Kauft euch lieber Boards, die man auch auf einem Steckbrett betreiben kann (einreihige Buchsenleisten). Da hat man mehr Einsatzmöglichkeiten und kann Peripherie einfacher anschließen. Z.B. so etwas: http://www.aliexpress.com/item/Funduino-Nano-3-0-Atmel-ATmega328-Mini-USB-Board-with-USB-Cable-Free-Shipping-Dropshipping/611171466.html
Peter R. schrieb: > Ich bin auch an so ein Board geraten: > > Beim Drücken der Taste RST auch die Taste S4 drücken und RST loslassen. > oder anders ausgedrückt: Wenn RST freigegeben wird, und S4 noch gedrückt > ist, geht das Board in den bootload-Betrieb. Gezeigt wird diese > Bereitschaft durch Blinken einer LED im Sekundentakt. > > Die Software HIDBootFlash muss auf dem PC installiert sein, damit kann > man dann Vendor-ID lesen und ein .hex file aufspielen. Hallo Peter, danke für deine Tipps. habe mit HIDbootflash die Vendor ID ausgelesen: obdev.at Soweit schon mal so gut. Wie schon gesagt bin ich leider noch Anfänger auf dem Gebiet der Mikrokontroller und deshalb kenne ich mich halt nicht so gut aus. Gibt es zu dem Board auch eine eine brauchbare Entwicklungsumgebung? Danke nochmal für deine Hilfe Michael
c-hater schrieb: > Michael Dauber schrieb: > >> Ich kann das Board zwar an meinen PC anschließen aber ich bekomme >> irgendwie keine Verbindung zustande. Die Power-LED leuchtet zwar und >> mein Window erkennt auch ein USB-Gerät. > > Tja, wenn das so ist, dann wäre es sehr nützlich, wenn du auch noch > geposted hättest, welches USB-Gerät genau Windows denn nun erkennt. Entschuldigung ich wusste leider nicht ganz genau was gebraucht wird um mir zu helfen. Aber die Info liefere ich gerne nach Im Geraätemanager ? Andere Geräte -? USB Gerät Unter Eigenschaften Reiter Details Geräteinstanzkennung : USB/VID_413C&PID_8140/6&CAA4AAE&0&4 Hardwarekennungen USB/Vid_413c&Pid_8140&rev_4315 USB/Vid_413c/Pid_8140 Kompatible Kennungen UBS/Class_e0&SubClass_01&Prot_01 USB/Class_e0SubClass_01 USB/Class_e0 Passende Gerätekennung Dienst Enummrator USB Devnode Flqags DN_HAS_PROBLEM DN_DISABLE DN_REMOVEABLE DN_NT_ENUMERATOR DN_NT_DRIVER ConfigFlags CONFIGFLAG_FAILEDINSTALL dann sind die restlichen Einträge leer Ich hoffe mal dass diese Infos nun ausreichend sind. Danke für eure Geduld michael
Michael Dauber schrieb: > Gibt es zu dem Board auch eine eine brauchbare Entwicklungsumgebung? Du kannst jede nehmen, die ein HEX-File erzeugt. Also praktisch alle. Anstatt dem in der Entwicklungsumgebung eingebauten Flasher musst du dann halt eben diesen HIDBootFlash nehmen, um das fertige HEX-File zum Board zu übertragen.
Michael Dauber schrieb: > Gibt es zu dem Board auch eine eine brauchbare Entwicklungsumgebung? Ich arbeite seit Jahren mit Studio4. Wenn das Programm kompiliert wird, entsteht dann ein .hex-file (schwach erinnere ich mich, dass der Compiler darauf eingestellt werden muss). Von diesem Punkt an verzichtet man auf die in Studio angebotenen Programmiermöglichkeiten. Man öffnet das Hilfsprogramm HID...., stellt die Verbindung her (Feld1), gibt das zu übergebende .hex-file an (Feld2) und startet das flashen (Feld3). Einziger Nachteil: Man kann zwar .hex files per HID... übergeben, kann aber die auf dem Kontroller des boards eingestellten fuses nicht verstellen. Das ist aber vielleicht auch ein Vorteil. Was sich nicht ändern lässt, kann auch nicht auf falsche Werte gestellt werden. Nicht umsonst arbeiten z.B. Arduino und auch viele andere Anfängersysteme mit einem bootloader .
Very good Board for beginners posted by tboysen on 14:44:08 GMT 12/04/2012 certificated customer Involvement Level: Expert (understands the inner workings) Pros: The board comes with an Atmega32 running on 16MHz, complete with screws and spacers. The Controller is preloaded with a USB bootloader, that implements a HID USB device (VendorID 16C0, ProductID 05DF), so no drivers are needed with windows. It seems to be BootloadHID, AVRUSBBoot or equivalent. It resides in the 2KB boot code section and is activated by holding S4 while reset. A blinking LED indicates that the bootloader is awaiting data. If S4 isn't pressed while reset the software loaded to the flash is started. Just compile your program with for example AVR Studio and send the hex file via USB using a tool like "HIDBootFlash". That's all. Therefore this is a very nice product for beginners to start because no extra Programmer is needed. For me it's a useful board to quickly implement and test something without the need to etch a board. Cons: The ISP connector is unusual, but this is not a real minus. There was no documentation, so i had to figure out the USB flash process by myself. Other: Like i said, good for beginners, handy for quick tests for pros. c-hater: lesen!
Volker Block schrieb: > Youtube-Video "atmega32 minimum Bascom blinky 9 Euro" > > > mal angucken. Für Anfänger. Beim Eröffnen des thread ging es doch um die Frage, wie man per USB und bootloader das board programmieren kann. Wie/ob es mit einem weiteren Teil, dem ISP-Programmiergerät geht, war doch garnicht die Frage. Nicht Jeder fängt mit Basic an. Die Übergabe eines .hex-file per HIDBootflash ist doch der wesentliche Weg. Ein Hex file bekommt man doch auch aus Assembler, aus C usw. heraus. Volker Block schrieb: > Very good Board for beginners Da wäre doch ein Angabe des link, aus dem so viel zitiert wird, ganz schön.
Link: http://dx.com/p/jy-mcu-minimum-avr-system-board-atmega32-104310 korrigierter Link für Youtube-Video "atmega32 minimum Bascom blinky 9 Euro" http://youtu.be/gQD3SdgPueQ
Atmega32 Minimum : die Anschlüsse der Tasten scheinen auf dem Schaltplan verkehrt bezeichnet zu sein. S1 bis S4 ist bei mir angeschlossen an PD3 bis PD6.
Hi, hab mir auch das Board gekauft. Ich wollte es jetzt mit dem AVR ISP mk2 programmieren, aber leider blinkt der Programmer nur mit orangem Licht... An anderen Controllern funktioniert der Programmer problemlos! Tastenkombi mit RST und S4 geht nicht mehr. Bootloader anscheinend schon gelöscht wie oben beschrieben. Gruß
Hi >aber leider blinkt der Programmer nur mit orangem >Licht... Troubleshooting Guide sagt: ISP cable is not mounted correctly MfG Spess
Hallo alle. Hermann-Josef schrieb: > oder usbasploader. Von letzterem wird behauptet, er > wäre (teilweise) zu Arduino kompatible, was auch immer teilweise > bedeuten soll. https://github.com/baerwolf/USBaspLoader schreibt: [...] This boot loader is similar to Thomas Fischl's avrusbboot and our own bootloadHID, but it requires no separate command line tool to upload the data. USBaspLoader emulates Thomas Fischl's USBasp programmer instead. You can thus use AVRDUDE to upload flash memory data (and if the option is enabled) EEPROM data. Since USBaspLoader cooperates with AVRDUDE, it can be used in conjunction with the Arduino software to upload flash memory data. [...] Heist, das es definitiv in Arduino funktioniert, man aber in der Arduino IDE eine "board description" fuer das zu verwendende Board installieren und auszuwaehlen hat. Beispiel: http://matrixstorm.com/avr/tinyusbboard/#arduino MfG
hab den ISP mal einzeln über die Pin-Outs verbunden. Gleiches negatives Ergebnis. Hat das vielleicht was mit der RESET Beschaltung zu tun?
Ich benutze das Board v1.3 . Zum programmieren nehme ich den avra unter Linux. Um das hex-file aufzuspielen nehme ich den avrdude (auch linux). usbasp-programmer gibt's für ca. 3 Euro aus China. avrdude -c usbasp -p m32 -U flash:w:dateiname.hex Alles funtioniert wunderbar. Gibt es die Schwierigkeiten mit der 1.4 Version ?
Hi. hans schrieb: > Gibt es die Schwierigkeiten mit der 1.4 Version ? Ich habe Version 1.4 mit USBaspLoader (https://github.com/baerwolf/USBaspLoader) am Laufen. Nach Anpassung der PIN-Konfiguration funktioniert es super. MfG Stephan
Hallo, hat jemand Erfahrung mit dem Upload einer hexdatei unter Linux über die USB-Schnittstelle des Boards ? Gruss hans
hans str schrieb: > hat jemand Erfahrung mit dem Upload einer hexdatei unter Linux über die > USB-Schnittstelle des Boards ? Ja. Ich benutze AVRDUDE und es funktioniert super. Du kannst dir aber auch einmal den "testing"-branch vom USBaspLoader ansehen: https://github.com/baerwolf/USBaspLoader/tree/testing Mit den neuen Funktionen kannst du sogar einen PIN (fuer die bootloaderCondition) einsparen und das Verhalten vom Arduinobootloader einstellen. Fragen dazu beantworte ich gern. MfG Stephan Anhang neue Funktionen: * CONFIG_HAVE__BOOTLOADER_ABORTTIMEOUTONACT (d7ac76b34c7ead103af) * CONFIG_HAVE__BOOTLOADER_ALWAYSENTERPROGRAMMODE (2bdd5099cb391ff) * BOOTLOADER_LOOPCYCLES_TIMEOUT (a3d7386c66be4c2479a15ebfa60) * CONFIG_NO__BOOTLOADER_HIDDENEXITCOMMAND (46cd9d4a9468b30ee8e456) * CONFIG_NO__BOOTLOADERENTRY_FROMSOFTWARE (fdd80449610db4cccc152e17)
Angehängte Dateien:
-
Fledermaus.jpg
510 KB
danke, da hab ich 'ne Weile dran zu knacken. Da tauchen sicher noch Fragen auf. Als Anhang ein Foto von meinem derzeitigen Projekt. Das Teil piept immer höher, wenn sich ein Gegenstand nähert. Gruss Hans
gerne. Es ist das Board wie im ersten Beitrag beschrieben, nur v1.3 16 MHZ Quarz. Das hat noch keinen USB-Bootloader, nur isp. Gruss hans
So hallo nochmal. Anbei ein vorkompilierter USBaspLoader (testing, https://github.com/baerwolf/USBaspLoader/commit/3e8387dcfe45fa59d9ceab898a163d5630e247b9). MCU --> ATmega32 Takrate --> 16MHz USBD+ (green) --> PD2 USBD- (white) --> PD7 PROGBUTTON --> PD6 Als Fuses empfehle ich folgendes: lfuse = 0x3f, hfuse = 0xc0 Die Lockbits sollten nach einem Chiperase unveraendert (0x3f) bleiben. Wenn ueber ISP geflasht wird, dann die main.hex verwenden. Fuer ein Update uber die USB-Schnittstelle die updater.hex. MfG Stephan
Hallo, erstmal Danke! dann drei Fragen: 1.)Ich möchte die main.hex mit avrdude über isp flashen, wie rufe ich den avrdude auf ? ( avrdude -c usbasp -p m32 -U .....) ? 2.) Nach dem Flashen: Wie rufe ich den avrdude auf für einen normalen Upload einer Hexdatei ? 3.) Bleibt die isp-Schnittstelle nach dem flashen erhalten, oder geht dann nur noch usb ? Angst ;-) Gruss hans
Hallo. hans str schrieb: > 1.)Ich möchte die main.hex mit avrdude über isp flashen, wie rufe ich > den avrdude auf ? ( avrdude -c usbasp -p m32 -U .....) ? Wenn dein IS-Programmer usbasp ist, dann:
1 | avrdude -c usbasp -p atmega32 -U flash:w:main.hex -U lfuse:w:0x3f:m -U hfuse:w:0xc0:m |
(Hat den Vorteil, das die fuses erst nach erfolgreichem verify geschrieben werden) > 2.) Nach dem Flashen: Wie rufe ich den avrdude auf für einen normalen > Upload einer Hexdatei ? Bei RESET oder Power-UP des Boards und gleichzeitigem druecken von PROG (Switch 4) wechselt das Board in den Programmiermodus. (Diese spezielle Version die ich hier anbiete wechselt sogar immer in den Programmiermodus und startet nach 4Sek Inaktivitaet oder druecken von PROG die Firmware des Benutzers). Im Programmiermodus gibt sich das Board dann auch als USBasp aus und kann genauso wie oben programmiert werden. Dies geht aber insgesamt schneller, der Flash wird geschont (es werden nur noch die zu beschreibenden Seiten geloescht) und die Fuse-/Lockbits sind ab daan schreibgeschuetzt und koennen nicht versehentlich geaendert werden. > 3.) Bleibt die isp-Schnittstelle nach dem flashen erhalten, oder geht > dann nur noch usb ? Angst ;-) Wenn die FUSES so gesetzt werden, wie ich es vorschlage bleibt ISP weiter aktiv. (Bei diesem USBaspLoader muss aber theoretisch nie mehr darauf zurueckgegriffen werden, da er sich auch ueber USB austauschen laesst. - Siehe update.hex) Die genauere Erklaerung des Fuses (Datenblatt Seite 258f): hfuse: 0xc0 = 0b 1100 0000 1 (MSB) --> OCD (OnChipDebug) deaktiviert (PINs freimachen) 1 --> JTAG deaktiviert (PINs freimachen) 0 --> ISP Scnitstelle aktiviert 0 --> ClockOption (auf "0" - noetig fuer externen Quarz) 0 --> EEPROM Inhalt nach einem ChipErase erhalten 0 --> BOOTSZ1 0 --> BOOTSZ0 (zusammen mit BOOTSZ1 die Position des Bootloaders im Flash) 0 (LSB) --> RESET Interruptvektor beim Bootup an Bootloader deligieren lfuse: 0x3f = 0b 0011 1111 0 (MSB) --> BrownOut Level 4.5V (Braucht der ATmega32, wenn er auf 16MHz laeuft) 0 --> BrownOut Ueberwachung aktiviert 1 --> StartUP Time Bit 1 1 --> StartUP Time Bit 0 (zusammen mit Bit1 ergibt diese laengste Einschwingzeit von 65 Zyklen) 1 --> 1 --> 1 --> 1 (LSB) --> das low-nibble ist der "Clockselect" der hiermit auf "external crystal" konfiguriert wird
Hallo, da ist noch 'ne Unsicherheit. Du schreibst weiter oben: USBD+ (green) --> PD2 USBD- (white) --> PD7 Laut Datenblatt des Boards hängt USBD- an PD0 Gruss Hans
hans str schrieb: > Laut Datenblatt des Boards hängt USBD- an PD0 Ich weiss. Das war nen Fehler in einem zu altem Datenblatt. Es muesste PD7 sein. Wenn es nicht funktioniert: ISP bleibt ja an und ich schicke dir dann einfach ne neue HEX. MfG Nachtrag: Du kannst ja auch gerne mal mit deinem Multimeter im Diodentest das ganze vorher pruefen.
Hallo Stephan, nach dem Flashen von main.hex avrdude -c usbasp -p m32 -U flash:w:sound.hex Fehlermeldung: avrdude: error: could not find USB device "USBasp" with vid=0x16c0 pid=0x5dc Gruss hans
Hallo Hans. Hattest du innerhalb von 3 Sekunden nach powerup die sound.hex geflasht? (Sonst hatte das Board ggf. den PROG-Modus bereits wieder verlassen) Ich bereite mal eine Version mit PD0 vor g. Wenn du Linux hast, kannst du mit mal dein syslog kurz nach einstecken des USB schicken? MfG
Hallo Stephan, hier die syslog: Sep 13 13:12:51 localhost kernel: [3184736.312255] usb 3-2: USB disconnect, device number 69 Sep 13 13:12:56 localhost kernel: [3184741.496178] usb 3-2: new low-speed USB device number 70 using uhci_hcd Sep 13 13:12:56 localhost kernel: [3184741.620126] usb 3-2: device descriptor read/64, error -71 Sep 13 13:12:57 localhost kernel: [3184741.844142] usb 3-2: device descriptor read/64, error -71 Sep 13 13:12:57 localhost kernel: [3184742.116149] usb 3-2: new low-speed USB device number 71 using uhci_hcd Sep 13 13:12:57 localhost kernel: [3184742.240153] usb 3-2: device descriptor read/64, error -71 Sep 13 13:12:57 localhost kernel: [3184742.464143] usb 3-2: device descriptor read/64, error -71 Sep 13 13:12:57 localhost kernel: [3184742.680132] usb 3-2: new low-speed USB device number 72 using uhci_hcd Sep 13 13:12:58 localhost kernel: [3184743.092137] usb 3-2: device not accepting address 72, error -71 Sep 13 13:12:58 localhost kernel: [3184743.204145] usb 3-2: new low-speed USB device number 73 using uhci_hcd Sep 13 13:12:58 localhost kernel: [3184743.616139] usb 3-2: device not accepting address 73, error -71 Sep 13 13:12:58 localhost kernel: [3184743.616179] hub 3-0:1.0: unable to enumerate USB device on port 2 Gruss hans
Hier die Version mit PD0 auf USBD-. Fuer Leute die update.hex verwenden: !! Bitte nur PIN-korrekte Updates flashen !! Anbei ein vorkompilierter USBaspLoader (testing, https://github.com/baerwolf/USBaspLoader/commit/3e8387dcfe45fa59d9ceab898a163d5630e247b9). MCU --> ATmega32 Taktrate --> 16MHz USBD+ (green) --> PD2 USBD- (white) --> PD0 PROGBUTTON --> PD6 Als Fuses empfehle ich folgendes: lfuse = 0x3f, hfuse = 0xc0 Die Lockbits sollten nach einem Chiperase unveraendert (0x3f) bleiben. Wenn ueber ISP geflasht wird, dann die main.hex verwenden. Fuer ein Update ueber die USB-Schnittstelle die updater.hex. MfG Stephan
Hallo Stephan, der error 71 bleibt bestehen. Kann das am Board liegen ? Es ist schon älter. Hab ein Neues bestellt. Werde einen atmega32-chip auf ein Breadboard setzen und weiterprobieren.
Hallo. Das es jetzt nicht geht ist seltsam. Der ATmega32L ist zwar mit seinen 16MHz etwas uebertaktet - das macht aber i.d.R. nichts. Vielleicht ist USBD- doch noch etwas ganz anderes als PD0. Kannst du das ggf. mal durchmessen? Ich selbst habe hier eine Version 1.4 (bei der ich den ATmega32L durch einen ATmega644p ausgetauscht habe) - das funktioniert anstandslos (mit USBD- als PD7). MfG Stephan
hallo Stephan, habe ein USB-Kabel aufgeschnitten und nachgemessen. das Board hat: PD0 an white 100 Ohm PD7 an green 100 Ohm Sind die Kabel alle gleich, oder kann weiss und grün vertauscht sein ? Gruss hans.
Hallo hans. hans str schrieb: > das Board hat: > PD0 an white 100 Ohm > PD7 an green 100 Ohm Okay... Schreibfehler? > PD7 an green 100 Ohm Also wenn die Kabel einigermasen korrekt verdrahtet sind, dann ist weiss USBD- und gruen USBD+. In diesem Fall bedeutet das, das PD7 (anstatt PD2) USBD+ ist? Ist das korrekt? Falls so, dann muss ich intensiv nachdenken, weil das ja bedeuten wuerde, das das Boardlayout fuer USB falsch ist. (Mindestens ein USBD muss an einen Interrupt-PIN) Vermutlich kann man es fixen, mal nachdenken... Welche PINs sind dann die 5 Switches? MfG Stephan
Hallo Stephan, ich fürchte Du hast recht. S1 löst bei dem Board den INT_1 aus. Das heist es ist PD3. Dann sind die Schalter an PD3-PD6. Wahrscheinlich ist das Board nicht für v-usb geeignet. Bei dem neuen Board v1.4 steht was von USB_Upgrade. Ich nehme an da ist dann die Belegung des USB_Port geändert. Gruss Hans P.S. Mein neues Board kommt erst in ein paar Wochen (China) Darf ich Dich weiter löchern, oder nervt es ;-)
hans str schrieb: > Darf ich Dich weiter löchern Klar, ich bitte darum. hans str schrieb: > Dann sind die Schalter an PD3-PD6 Die Frage ist dann, wo ist PD2 (INT0)? Wenn die Frage geklaert ist, wo die PINs von PORTD ueberall hin verbunden sind, kann ein Patchplan entwickelt werden g. Version 1.4 funktioniert, da: PD2-->USBD+ und PD7-->USBD- Ich bin mir aber sicher, das man zur Not ein kleines Wrappingwire zwischen 2 PINs des ICs loeten kann - dann noch Firmware anpassen - laeuft ;-) MfG Stephan
hallo, wenn ich einen Jumper von PD0 nach PD2 setze, dann habe ich: PD7 = green PD2 = white also nahe dran, nur green und white vertauscht. solange PD0 nicht als Ausgang gesetzt wird könnte nichts durchbrennen. Gruss hans
Hallo, sorry fuer meine verzoegerte Antwort. Ich habe mal recherchiert: Auszug aus dem USB-Treiber:
1 | Please note that D+ must also be connected to interrupt pin INT0! |
dabei kann man auch auf INT1 ausweichen, USBD+ muss aber die Interruptquelle sein. Gruen/Weiss zu tauschen reicht also nicht. Kann man irgendwie PD7 (gruen) mit PD2 oder PD3 bruecken? hans str schrieb: > PD2 = white Ich dachte das war PD0? MfG Stephan
Hallo, ich habe PD7 und PD2 gejumpert sodass green an beiden pins anliegt. white ist an PD0 Dann habe ich Deine main.hex geflasht mit: MCU --> ATmega32 Taktrate --> 16MHz USBD+ (green) --> PD2 USBD- (white) --> PD0 PROGBUTTON --> PD6 jetzt siht die syslog so aus: Sep 15 09:55:37 localhost kernel: [3345701.008166] usb 3-2: new low-speed USB device number 101 using uhci_hcd Sep 15 09:55:37 localhost mtp-probe: checking bus 3, device 101: "/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-2" Sep 15 09:55:37 localhost mtp-probe: bus: 3, device: 101 was not an MTP device Sep 15 09:55:39 localhost kernel: [3345702.944255] usb 3-2: USB disconnect, device number 101 diese Sequenz wiederholt sich solange der USB-Port eingesteckt ist. ABER ich kann ein Programm über USB uploaden. Nur funktioniert das Programm nicht wie vorher. Ich experimentiere weiter Gruss hans
Nachtrag: Wenn ich mein Testprogramm mit avrisp-programmer flashe geht es wieder, aber das v-usb ist weg. Also benutzen beide den gleichen Speicherbereich ?? hans
Hi hans. hans str schrieb: > diese Sequenz wiederholt sich solange der USB-Port eingesteckt ist. Normalerweise betritt der USBaspLoader den Programmiermodus nur, wenn der PROGBUTTON waehrend eines Bootups gedrueckt ist. (siehe https://github.com/baerwolf/USBaspLoader/blob/master/Schematics.txt Zeile 42ff) Aus den Erfahrungen mit meinem tinyUSBboard (http://matrixstorm.com/avr/tinyusbboard/) kommen viele damit nicht richtig klar. Deswegen habe ich seit einer Woche ein Feature im testing-branch implementiert, dass der Loader immer in den Programmiermodus geht - dann aber nach 3sek austimed, wenn nix programmiert wird. (Das austimen findet nicht statt, wenn du ueber den PROGBUTTON in den Modus wechselst). Hast du den WATCHDOG aktiv? Die derzeitige Loaderversion ignoriert den watchdog (deaktiviert ihn also NICHT explizit). hans str schrieb: > Wenn ich mein Testprogramm mit avrisp-programmer flashe geht es wieder, Nach dem Chiperase ist der Bootloader aber wieder weg. Wenn die Fuses aber unveraendert bleiben, dann stimmt die __start-Adresse im Chip NICHT mehr. (Die zeigt auf den Bootloader!) Wenn du nach dem flashen deiner firmware ueber USB (natuerlich muss dann erstmal wieder der Bootloader draufgefalsht werden) die PROG-taste drueckst - startet sie dann? Passiert das staendige disconnect/connect auch nachdem du mit avrdude verbunden warst? (Normalerweise wird nach einem detektierten avrdude connect das timeout abgebrochen und der Loader verbleibt im Programmiermodus: Solange bis entweder PROG gedrueckt wird oder das ISP-Raw-Kommando 0xff 0x00 0x00 0x00 empfangen wurde) MfG Stephan
hans str schrieb: > ABER ich kann ein Programm über USB uploaden. > Nur funktioniert das Programm nicht wie vorher. Wie aeussert sich das? Läuft es zu schnell/zu langsame? MfG Stephan
Hallo Stephan, alles im grünen Bereich ;-) die syslog bleibt auch ruhig. Ich fasse zusammen: ------------------- 1.) PORTD7 mit PORD2 jumpern 2.) Deine main.asm über isp flashen 3.) Meine test.hex über usb flashen 4.) Die Prog-Taste drücken puhh, das war 'ne schwere Geburt. Danke für Deine Geduld. Gruss hans.
hans str schrieb: > Danke für Deine Geduld. Kein Problem. Jetzt wo das Basicsystem geht, kannst du mir dein bevorzugtes Verhalten sagen und ich bau dir eine update.hex. Z.B. wenn do moechtest das per Default immer die programmierte Firmware startet (und nicht der Bootloader), oder wenn du kein Timeout/hoeheres Timeout willst. Einfach sagen g MfG Stephan p.s.: Statt PROGTaste am Ende der Programmierung, kannst du auch mit AVRdude ein Rohkommando "0xff 0x00 0x00 0x00" senden. Nach dem disconnect vom AVRDude startet der Bootloader die Firmware (als waere PROG gedrueckt worden). Auf diese Weixse kannst du alles am PC machen, ohne am Board "fummeln" zu muessen.
Achso, fuer Fortgeschrittene: Der bootloader hat auch eine API mit der man aus einer eigenen Firmware wieder in den Programmiermodus wechseln kann. Ein ansteuerungsbeispiel ist im entsprechendem Commit beschrieben: https://github.com/baerwolf/USBaspLoader/commit/fdd80449610db4cccc152e17b04cdb51de578a61 Die Bootloader(byte)adresse ist beim ATmega32: BOOTLOADER_ADDRESS=0x7000 MfG Stephan
Hallo Stephan, alles super wie es jetzt ist. Ich programmiere nur in Assembler und da weiss man immer gerne wo was ist im Speicher. Hast Du vielleicht 'ne memory-map ? Gibt es vielleicht sogar Subroutinen, die man benutzen kann ? Gruss hans
hans str schrieb: > Hast Du vielleicht 'ne memory-map ? Hi hans. Ich hatte, die habe ich geloescht. Ich kann es aber nocheinmal neu compilieren , dir die hexfiles posten und die zugehoerige Map (+ASM dump). MfG Stephan
hans str schrieb: > Ich programmiere nur in Assembler Da ist die SPM API des Loader ggf. was fuer dich. Damit kannst du innerhalb deiner Firmware schreibend auf den Flash zugreifen. Ich hatte mal dazu etwas im Beitrag "Re: [ATMega] Programm aus externem EEprom laden" geschriben. MfG Stephan
Hallo, Stephan B. schrieb: > Ich hatte mal dazu etwas im > Beitrag "Re: [ATMega] Programm aus externem EEprom laden" geschriben. interessanter Thread Frage: Wo im Flash ist Dein Bootloader und wie kommt er dahin ? Ich habe ihn doch über SPI geladen, wie ein normales Programm. Gruss hans
Der Bootloader ist aber ein speziell gelinktes Programm. Seine Position ist vom AVR (und den fusebits) abhaengig. In diesem Fall ist es 0x7000 (Byteadresse) - also die letzten 4KiB des Flashspeichers. Normale Applikationen befinden sich also immer oberhalb des Bootloaders. Der Bootloader schuetzt sich selbst davor, durch zu lange Firmwares nicht ueberschrieben zu werden. (Dadurch muessen keine Lockbits benutzt werden und er bleibt "updatefaehig") Der Applikationsbereich wird im Datenblatt RWW-Sektion (Read-While-Write) genannt und hat geringere Ausfuehrungsprivilegien. Z.B. darf ein Aufruf von SPM innerhalb 0x0000-0x6FFF nicht auf den Flash schreiben und schlaegt stillschweigend fehl. Deswegen implementiert USBaspLoader (als einzigster? Bootloader) ein Interface (spminterface.h) was wie ein Unterprogramm aufgerufen werden kann. https://github.com/baerwolf/USBaspLoader/blob/testing/firmware/spminterface.h hans str schrieb: > [...] und wie kommt er dahin ? Im Detail verschiebe ich das Textsegment nach 0x7000 mittels
1 | -Wl,--section-start=.text=$(BOOTLOADER_ADDRESS) |
Man kann das fuer kleinere Adressen als 0x7000 auch fuer normale Firmwares machen. Und in der Tat nutze ich das um hintere Bereiche aehnlich oft zu beschreiben, wie vordere Flashseiten. In der Interrupttabelle an 0x0000 schreibt man einmalig feste Spruenge zum "neuen" Start der Firmware und beflasht ab daan nur noch den "hintereren" Bereich. Da der Bootloader kein Chiperase braucht und nur sich veraenderende Seiten implizit löscht, bleiben die "Spruenge" an 0x0000 mit jedem neuen Programmierzyklus erhalten. (Solange bis sie ueberschrieben werden) Das eroeglicht es die Lebensdauer des Flashspeichers zu erhöhen. Denn ist ersteinmal die Seite 0 kaputt - kann man nix mehr im Nachhinein fixen. Fuer tinyUSBboard biete ich spezielle "empty"-firmwares an, die schon entpsprechende Einsprungsverschiebungen behinhalten: http://matrixstorm.com/avr/tinyusbboard/#firmwares Meine Beispiel-Makefiles enthalten dann eine Varibale ("FLASHADDRESS"), wo man die Firmware hingelinkt haben moechte: https://github.com/baerwolf/avrskel/blob/master/Makefile MfG Stephan
Hallo, da habe ich jetzt für einige Zeit was zum Nachdenken und Ausprobieren ;) Bis bald mal wieder. Gruss hans
Hallo Stefan, kann ich genau den Quellcode bekommen, den Du für mich Compilert hast. Liegt der irgendwo im Internet ? Gruss hans
Anbei hier nocheinmal alles der Vollstaendigkeit halber. (Version mit PD0 als USBD-) Fuer Leute die update.hex verwenden: !! Bitte nur PIN-korrekte Updates flashen !! Wenn bereits ein funktionierender Bootloader mit spminterface auf dem AVR installiert ist, kann update.hex bequem ueber den Bootloader geflasht werden, um den Bootloader auszutauschen. (Keine Notwendigkeit main.hex per ISP zu flashen.) main.hex kann nicht per Bootloader instaliert werden, da im Normalbetrieb der Bootloader sich vor Ueberschreiben schuetzt. ( Details hier: http://matrixstorm.com/avr/tinyusbboard/#updates ) Anbei die Dateinen fuer einen vorkompilierten USBaspLoader. Sie basieren alle auf den aktuellen HEAD des USBaspLoader testing branch (https://github.com/baerwolf/USBaspLoader/commit/3e8387dcfe45fa59d9ceab898a163d5630e247b9) plus die Veraenderungen aus "0001-spice-up-for-customized-edition.patch" . MCU --> ATmega32 Taktrate --> 16MHz USBD+ (green) --> PD2 USBD- (white) --> PD0 PROGBUTTON --> PD6 Als Fuses empfehle ich folgendes: lfuse = 0x3f, hfuse = 0xc0 Die Lockbits sollten nach einem Chiperase unveraendert (0x3f) bleiben. Wenn ueber ISP geflasht wird, dann die main.hex verwenden. Fuer ein Update ueber die USB-Schnittstelle die updater.hex. MfG Stephan
hallo Stephan, habe die Dateien heruntergeladen und angesehen. Bin leider etwas überfordert. Ich suche eine Assemblerroutine mit der ich ein Byte über die USB-Schnittstelle an den Picocom auf den PC schicken kann. Wenn man die Resettaste drückt meldet das Board ja die USB-Schnittstelle an. Die Routinen sind ja demnach vorhanden. Gruss hans
Hallo hans. So wird das nichts (bzw. zu aufwaendig). Der bootloader Code ist, wenn ich das hier sagen darf, pervers optimiert. Alles bis auf die API die er absichtlich exportiert, sollte nichts reused werden. Unter anderem werden gloable Variablen in Register gezwungen - long story short: Der Bootloadercode ist nicht positionsunabhaengig. Wenn du in deinem Code auch USB implementieren willst, dann linke den USB-Stack selbst nocheinmal zu deiner Firmware. Ich habe fuer tinyUSBboard vor einiger Zeit einmal eine kleine Demo "VUSB skeleton/example" vorbereitet (inclusive Host Applikation). Hier der Link: http://matrixstorm.com/avr/tinyusbboard/#examples Seh dir aber ggf. auch einmal meinen Beitrag "Re: LED Stripes über USB ansteuern(dimmbar)" MfG Stephan
Hallo, alles zu kompliziert für mich. Ich dachte an 'ne Subroutine die man ungefähr so aufrufen kann. ldi R1, 65 call SendeZeichen SendeZeichen: ; ein Zeichen aus R1 zum USB-device senden ... ... ret Aber das gibt's wohl nicht. Trotzdem danke für Deine Antwort Gruss hans
Hallo hans. hans str schrieb: > SendeZeichen: > ; ein Zeichen aus R1 zum USB-device senden So funktioniert USB leider nicht. USB Geraete muessen sich beim Host identifizieren und Kontrollnachrichten austauschen. Dann gibt es noch Konfigurationen und Endpunkte ...etc... Selbst die einfachste Methode Daten "Huckepack" ueber den Kontrollendpunkt 0 zu uebertragen ist komplexer als ein einfacher TX-Aufruf. Falls du dir es doch anders mit USB ueberlegt - du kannst mich gern jederzeit fragen. MfG Stephan
Habe das selbe Board zu Testzwecken gekauft. Kann nur sagen, dass es super Funktioniert. Spannungsversorgung aund aufspielen der Programme über USB funktionieren einwandfrei !
Microfreak schrieb: > Spannungsversorgung aund aufspielen der Programme über USB funktionieren > einwandfrei ! Hallo Microfreak. Dann erstmal Glueckwusch dazu. Rein aus Neugier: Welchen Bootloader verwenden Sie? Welche Boardversion? MfG Stephan
Hallo zusammen, ich habe mir nun auch solch eine Platine zugelegt und diesen Thread verfolgt. Allerdings habe ich das erste mal mit einem Bootloader zu tun... Wie bekommt Ihr die Programme auf den Chip? Ich habe das Programm "HIDBootFlash" zum flashen des Bootloaders benutzt. Gibt es eine Möglichkeit die Platine via USB in Kombination mit dem AVR-Studio zu programmieren?! Das wäre spitze!
Hallo Julian B. Julian B. schrieb: > Wie bekommt Ihr die Programme auf den Chip? Den Bootloader musst du mittels externen Programmieradapter (ISP oder HVPP) installieren. Falls du kein Programmiergeraet hast, so gibt es einige Bastellloesungen: http://matrixstorm.com/avr/tinyusbboard/#chickenoregg Neben der Installation des Bootloaderprogrammcodes muessen damit auch die Fuse-Bits entpsrechend programmiert werden. Solltest du den USBaspLoader von hier flashen, so brauchst du das Programmiergeraet spaeter nicht mehr, da dies USBaspLoader Version Updates unterstuetzt und somit der Bootloader durch sich selbst austauschbar ist. Theoretisch sogar gegen andere Bootloader (siehe tinyUSBboard Beispiel: http://matrixstorm.com/avr/tinyusbboard/#firmwaresotherbootloader) Julian B. schrieb: > Ich habe das Programm "HIDBootFlash" zum flashen des Bootloaders > benutzt. Das funktioniert natuerlich nicht - zunaechst muss ein Bootloader installiert sein. Das Tool "HIDBootFlash" ist ausserdem nur fuer den Bootloader "HIDBoot". Mit dem in diesem Thread verfuegbaren USBaspLoader arbeitet es (zunaechst) NICHT zusammen. Hast du USBaspLoader installiert, kannst du alle Tools verwenden die das USBasp Protokoll unerstuetzen. Z.B.: AVRDUDE (Beitrag "AVRDUDE 6.0 freigegeben") oder KhazamaAVRProgrammer (http://khazama.com/project/programmer/). Es gibt aber zahlreiche mehr. USBasp wird zudem von der Arduino IDE unterstuetzt. Julian B. schrieb: > Gibt es eine Möglichkeit die Platine via USB in Kombination mit dem > AVR-Studio zu programmieren?! Ja. Siehe: Beitrag "USBasp unter AVRStudio 5 oder 6 verwenden - Anleitung!"
Hmm... ...wie wird man eigentlich Moderator in diesem Forum? @Moderatoren: Koennt Ihr bitte die vorherigen 2 Beitraege loeschen - es handelt sich wohl offensichtlich um Spam. Danke und mfG Stephan
Hallo, habe ein kleines Assemblerprogramm geschrieben: Code : 43 words (86 bytes) Wenn das auf dem Board läuft kann man mit der Bash (linux) das Board steuen. Wenn jemand Interesse hat schreibe ich mehr. Gruss Hans
hans str schrieb: > Wenn jemand Interesse hat schreibe ich mehr. Erzaehl mal! Was ist genau damit gemeint: "Das Board steuern"? Ueber was wird gesteuert (USB oder UART)? Code? Auf jeden Fall Interesse! MfG Stephan
Hallo Stephan, das geht über UART (an USB war ich gescheitert) z.B. echo -en '\x1\x18\x41' >/dev/ttyUSB0 gibt auf dem Board eine hex 41 an portb (wo die leds sind) aus Wenn man noch einen Terminalemulator laufen hat: z.B. picocom /dev/ttyUSB0 erscheint dort ein A also die 1 ist das Befehlstoken zum Schreiben ins Ram die hex 18 ist die Adresse (portb) als drittes Byte folgt der Wert, der geschrieben wird. So kann man alle Ports des Atmega ansprechen. Gruss hans
Hallo Hans. Das klingt auf jeden Fall spannend und ich bin neugierig auf Code g Vielleicht moechtest du dir auch einmal avrBridge ( http://ka010.wordpress.com/avrbridge/ ) ansehen. MfG Stephan
Hallo Stephan, hier ist der code quick and dirty (hauptsache läuft erstmal.) später sollen noch weitere Befehle folgen. hans
Nachtrag: Zitat: Vielleicht moechtest du dir auch einmal avrBridge ( http://ka010.wordpress.com/avrbridge/ ) ansehen. die sind ja schon viel weiter als ich ;) aber ich möchte es so einfach wie möglich machen. hans
noch ein Nachtrag: Die Adresse von portb ist natürlich hex 38 nicht 18. also echo -en '\x1\x38\x41' >/dev/ttyUSB0 die drittletzte Zeile im code kann dann auch weg. hans
erstmal der letzte Nachtrag:
ich habe fertig.
Hier ein paar Beispiele:
mit: echo -en '\x1\x37\xFF' >/dev/ttyUSB0
wird PORTB als Ausgang geschaltet.
mit: echo -en '\x1\x38\x41' >/dev/ttyUSB0
wird ein A an PORTB und an den UART gesendet
mit: cat </dev/ttyUSB0 >x
wartet der cat-Befehl auf ein Zeichen vom UART
und schreibt das dann in die Datei x
mit: echo -en '\x2\x37' >/dev/ttyUSB0
wird der Inhalt von DDRB gelesen und ausgegeben
mit: hexdump x kann man dann den Wert von DDRB sehen.
Gruss hans
Hi Stephan, ich habe mir den Thread einige Male durchgelesen, getestet und leider den Boot-Loader noch nicht am laufen. Kannst Du mir ggf. weiterhelfen? Ich habe das Board in der Revision 1.4. Danke! Lg Martin
Hallo Martin Rev. 1.4 war die erste dieses Boardtypes, deren Layout zwar anders - aber fuer VUSB auch am besten geeignet ist. Es entspricht dem Standard (tinyUSBboard) Rev.3 layout. MCU --> ATmega32(L) Takrate --> 16MHz USBD+ (green) --> PD2 USBD- (white) --> PD7 PROGBUTTON --> PD6 (Alle LEDs an PortB -- magic value: 0xfe6b9502) Als Fuses empfehle ich folgendes: lfuse = 0x3f, hfuse = 0xc0 Die Lockbits sollten nach einem Chiperase unveraendert (0x3f) bleiben. Wenn ueber ISP geflasht wird, dann die main.hex verwenden. Fuer ein Update ueber die USB-Schnittstelle die updater.hex. Da die Erfahrung gezeigt hat, dass es fuer Einsteiger immer Schwierigkeiten bereitet den PROG-Button richtig zu bedienen: Die angehangene Version betritt immer den Bootloadermodus (auch wenn PROG nicht gedrueckt wird) und timed aber nach ein paar Sekunden Inaktivitaet aus und startet die zuvor programmierte Firmware. Dies ist ein Feature des verwendeten, aktuellen testing-branch (https://github.com/baerwolf/USBaspLoader/commit/45fd44c6dd933b7b79274e6d03da013066b2682f) Soll ohne bootloader condition (PROG Button gedrueckt) die Firmware sofort gestartet werden, so kannst du Bescheid geben oder die betreffenden Features selbst deaktivieren, neu compilieren und per update auf deinem Board installieren. MfG Stephan
:
Bearbeitet durch User
Hi Stephan, grundlegend hat es funktioniert. :) Vielen Dank dafür! Also usbasp und flashen klappt jetzt. Wunderbar! Dennoch habe ich noch ein paar Fragen: - Im Windows-Gerätemanager wird nach Einschalten des Boards ständig nach neuen Geräten gescannt. Also ähnl. wie es damals bei Hans in den Linux-Logs war. Hast Du eine Idee woran das liegen könnte? - Welche Zeile muss ich ändern um den Timeout am Anfang zu deaktivieren? Am besten wäre es, wenn das Board direkt mit dem Programm startet und den Bootloader nur dann lädt, wenn beim Booten die Taste 4 gedrückt/gehalten wird. Was auch praktisch wäre, wenn die Firmware (hattest Du ja mal oben geschrieben) über einen Dummy-avrdude-Befehl ausgeführt wird. :) Bist Du eigentl. der Maintainer von dem usbasp? :) Danke! LG Martin
Angehängte Dateien:
-
versuch1.PNG
12 KB
Hallo nochmal, ich kann den Source leider nicht kompilieren. Hast Du eine Idee? Ich habe mir den testing-branch heruntergeladen, dann den Patch von Deinem Thread eingespielt (patch -p1 < patch.pa) und versucht mit make den Source zu kompilieren. Im Anhang ein Screenshot von den Ausgaben. Danke! LG Martin
Hallo Martin. Ich werde dir heute abend ausfuehrlicher antworten - momentan bin ich gearde noch schwer mit etwas anderen beschaeftigt... Nur kurz vorab: Bitte verwende eine "moderene" toolchain (version 3.4.X). Diese erhaelst du entweder direkt von Atmel oder von der tinyUSBboard Seite. Fuer Windows: http://matrixstorm.com/avr/tinyusbboard/#asmorc_windows Und jap, ich bin der maintainer vom USBaspLoader. MfG und bis nachher
:
Bearbeitet durch User
Hi Martin Fandel schrieb: > Dennoch habe ich noch ein paar Fragen: > - Im Windows-Gerätemanager wird nach Einschalten des Boards ständig nach > neuen Geräten gescannt. Also ähnl. wie es damals bei Hans in den > Linux-Logs war. Hast Du eine Idee woran das liegen könnte? USBD- liegt auf High. Wenn das USB Interface nicht verwendet wird (d.h. keine Interruptrutine zum scannen nach Daten installiert ist): Die VUSB-Funktion (eigentlich Makro) usbDisconnect() oder alternativ das Setzen von PD7 auf Output Low schaltet das ab. Martin Fandel schrieb: > - Welche Zeile muss ich ändern um den Timeout am Anfang zu deaktivieren? In der Makefile.inc ganz am Anfang das Feature "CONFIG_HAVE__BOOTLOADER_ALWAYSENTERPROGRAMMODE" auskommentieren. Da du die Timeout-Funktion dann auch nicht mehr brauchst (und falls du Sie auch nicht haben willst): "CONFIG_BOOTLOADER_LOOPCYCLES_TIMEOUT=16" und "CONFIG_HAVE__BOOTLOADER_ABORTTIMEOUTONACT" deaktivieren. MfG Stephan
Hi Stephan, die main.hex funktioniert jetzt perfekt! Kein Timeout. Wirklich prima! :) Mit der updater.hex komme ich jedoch noch nicht klar. Ich schließe das Board per USB an, drücke RST und Taster4 gleichzeitig, lasse RST los, danach erst Taster4. Dann habe ich den folgenden Befehl zum flashen der updater.hex eingegeben: avrdude -c usb -p atmega32 -U flash:w:updater\updater.hex -U lfuse:w:0x3f:m -U hfuse:w:0xc0:m Danke! Lg Martin
:
Bearbeitet durch User
Martin Fandel schrieb: > avrdude -c usbasp -p atmega32 -U flash:w:updater\updater.hex -U > lfuse:w:0x3f:m -U hfuse:w:0xc0:m Die fuses muessen beim Update nicht erneut gesetzt werden, da sie updater.hex ausschlieslich zur Verwendung ueber das USB Interface gedacht ist. Der Gedanke hinter updater.hex ist kein direktes bootloader-image. Vielmehr ist es eine Firmware die ausgefuehrt werden muss. Diese Firmware enthaelt das neue bootloader-image und installiert es bei ihrer ersten Ausfuehrung. MfG
Ok, vielen Dank! Ich denke ich komme erstmal ohne den Updater klar. So wie es jetzt ist, werde ich den Bootloader wohl nicht mehr ändern. :) OT: Ich habe vorhin versucht die Arduino SD-Library mit dem Board ans Laufen zu bekommen, leider ohne Erfolg. Mit den Ulrich Radig Libs funktioniert es aber. Hat jemand das schon ans laufen bekommen? Danke! Lg Martin
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.