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#
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.
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.
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ß
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
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
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)
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
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:
(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
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.hhans 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
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
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
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
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
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
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
