Ich wollte gerne auf Micronucleus hinweisen. Hierbei handelt es sich um einen USB-Bootloader für den ATtiny85: https://github.com/micronucleus Die Bootloader wurde ursprünglich für den Digispark entwickelt (www.digistump.com), ist aber ein unabhängiges Open Source Projekt, welches von unterschiedlichen Leuten weiterentwickelt wird. Ich habe den Release der letzten Version getrieben. Der Hauptvorteil gegenüber ähnlichen Bootloadern, wie z.B. dem vom Adafruit trinket, ist eine deutlich geringere Speichernutzung. Die aktuelle Version belegt weniger als 1900 bytes. Es ist geplant, noch andere ATtinies zu unterstützen, die Codegröße weiter zu reduzieren und die USB-Kompatibilität zu verbessern.
:
Warum sollte man überhaupt einen USB-Bootloader nehmen? Warum nicht einen RS232-Bootloader? Dieser ist wesentlich freundlicher zu den Ressourcen. Noch etwas: auf "github" sieht das ganze Projekt ziemlich unaufgeräumt aus.
Davis schrieb: > Warum sollte man überhaupt einen USB-Bootloader nehmen? z.B. wenn man sowieso V-USB verwendet. Die zweite Anwendungsmöglichkeit ist in einem "mini-Arduino". Plattformen wie der Digispark und Trinket sind inzwischen ziemlich erfolgreich und weit verbreitet.
Davis schrieb: > Noch etwas: auf "github" sieht das ganze Projekt ziemlich unaufgeräumt > aus. Ja, das Projekt ist durch viele Hände gegangen. Allerdings bin ich mir nicht ganz sicher, ob Du das Repository oder Github selbst meinst?
Tim schrieb: > wenn man sowieso V-USB verwendet Kann ich gut gebrauchen, mit 4 IO/ADC Pins für ein Touchpanel via USB. Aber wie funktioniert das?
Ich denke, es ist wirklich eine Schnellstart-Anleitung erforderlich. Prinzipiell ist es recht einfach: 1) Installieren des Bootloaders auf dem ATTiny85 Voraussetzung: - Aktuelle GCC-AVR Toolchain - AVRdude Wechseln in das Verzeichnis /firmware. Wenn kein USBASP verwendet wird, muss das makefile angepasst werden (PROGRAMMER=) Wenn USB nicht an PB3 und PB4 angeschlossen ist, muss "bootloaderconfig.h" angepasst werden "make" - compiliert die firmware "make flash" - programmiert den ATtiny85 "make fuses" - Setzt die fuses (clock multiplier, self programming) 2) Installieren der Devicetreiber aus dem Archiv im Hauptverzeichnis 3) Uploaden eines Programms auf ein Device mit installiertem Bootloader Entsprechendes Tool aus /commandline/builds heraussuchen (windows/mac vorhanden, Linux muss selbst compiliert werden) micronucleus --help gibt eine Befehlsübersicht aus. micronucleus <programmname.hex> lädt ein hexfile hoch. Der Bootloader ist in der Standardkonfiguration so ausgelegt, dass er einen Timeout von 6 Sekunden hat. Das heisst, nach dem Reset ist für sechs Sekunden der Bootloader am USB-Port zu sehen. Danach wird das Userprogramm gestartet.
:
Bearbeitet durch User
Und wie kann man dann auf die V-USB Funktionen zugreifen?
A Hempel schrieb: > Und wie kann man dann auf die V-USB Funktionen zugreifen? Wie Du es sonst auch machen würdest. Der Bootloader verbiegt den PCINT0, verzweigt aber in Dein User-Programm wenn der Bootloader nicht aktiv ist. Mit den par Taktzyklen Verzögerung kommt V-USB noch zurecht.
:
Bearbeitet durch User
Ach so, ich dachte, du meinst, dass die V-USB-Funktionen des Bootloaders von der Anwendung auch genutzt werden können (ginge das nicht, wenn man Anwendung und Bootloader zusammen erstellt oder linkt?)..
A Hempel schrieb: > (ginge das nicht, wenn man > Anwendung und Bootloader zusammen erstellt oder linkt?).. Theoretisch ja, praktisch wird es daran scheitern, dass man sehr viel Flexibilität aufgibt. In V-USB werden alle Features durch Compilerflags definiert. Wenn V-USB Teil des Bootloaders ist, dann kann man diesen Teil nicht mehr updaten, oohne dass man den Bootloader neu hochlädt. Damit ist der Sinn der Bootloaders fraglich. Besser ist es also, getrennte Konfigurationen für Bootloader und User-Program zu verwenden und mit den zusätzlichen 1000 bytes zu leben.
:
Bearbeitet durch User
gugl schrieb: > Tim schrieb: >> Es ist geplant, noch andere ATtinies zu unterstützen > > ATtiny45 oder welche? ATTiny10.
gugl schrieb: > ATtiny45 oder welche? 841/84/167. 45 ist aber auch kein Problem. Davis schrieb: > ATTiny10. Du kannst Dich ja mal 'dran versuchen :)
Ohgott ist das ein Chaos: - Win32 Binarys im Root-Verzeichnis - Irgendeine .bin Datei im Root-Verzeichnis (nyan-cat.bin) - Dokumentationen irgendwie wild überall verstreut Zum Code: - Zeileneinrückungen völlig chaotisch - "//" Kommentare und /**/ gemischt - Vernestelte Kommentare Raeum das Teil erstmal auf, das sieht massiv nach Frickelei aus ...
Tim schrieb: > wenn man sowieso V-USB verwendet. Nach dem der Bootloader läuft habe ich "Reset disabled" und stelle nun fest, dass vusb-20121206 offenbar nicht mit deinen Standard-Pins kompatibel ist: Micronucleus bootloaderconfig.h:
1 | #if (defined __AVR_ATtiny85__) && (HARDWARE_CONFIG == TINY85_HARDWARE_CONFIG_2) |
2 | # define USB_CFG_DMINUS_BIT 3 |
3 | /* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected. |
4 | * This may be any bit in the port. |
5 | */ |
6 | # define USB_CFG_DPLUS_BIT 4 |
7 | /* This is the bit number in USB_CFG_IOPORT where the USB D+ line is connected. |
8 | * This may be any bit in the port, but must be configured as a pin change interrupt. |
9 | */ |
10 | #endif |
vusb-20121206 usbconfig-prototype.h:
1 | #define USB_CFG_DMINUS_BIT 4 |
2 | /* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected. |
3 | * This may be any bit in the port. |
4 | */ |
5 | #define USB_CFG_DPLUS_BIT 2 |
6 | /* This is the bit number in USB_CFG_IOPORT where the USB D+ line is connected. |
7 | * This may be any bit in the port. Please note that D+ must also be connected |
8 | * to interrupt pin INT0! [You can also use other interrupts, see section |
9 | * "Optional MCU Description" below, or you can connect D- to the interrupt, as |
10 | * it is required if you use the USB_COUNT_SOF feature. If you use D- for the |
11 | * interrupt, the USB interrupt will also be triggered at Start-Of-Frame |
12 | * markers every millisecond.] |
13 | */ |
Was nu?
Sowohl der Bootloader, als auch die Userapp sollten auf die gleichen USB-Pins konfiguriert sein. Am besten natürlich auf welche, an die der USB-Bus auch angeschlossen ist. Wird der Bootloader denn von Windows erkannt?
da schrieb: > Raeum das Teil erstmal auf, das sieht massiv nach Frickelei aus ... Ich muss Dir da zustimmen. Nur kann ich als ein bestehendes OS-Projekt von Anderen nicht einfach komplett umräumen, weil mir der Stil gerade nicht passt. Es hat sich aber schon einiges verbessert. Dir muss ich als Vorschlag mitgeben, zu lernen, wie man konstruktiv kritisiert.
Tim schrieb: > Wird der Bootloader denn von Windows erkannt? Ja - wie ich gerade schrieb. Tim schrieb: > Sowohl der Bootloader, als auch die Userapp sollten auf die gleichen > USB-Pins konfiguriert sein. Am besten natürlich auf welche, an die der > USB-Bus auch angeschlossen ist. Das ist schon klar. Aber du/ihr/micronucleus nutzt Pins, die von v-usb so gar nicht unmittelbar vorgesehen sind, und benutzt einen anderen Interrupt, wie ich gerade gesehen habe. https://github.com/obdev/v-usb/tree/master/circuits
1 | ... |
2 | GENERAL DESIGN NOTES |
3 | ==================== |
4 | All examples have D+ on hardware interrupt INT0 because this is the highest |
5 | priority interrupt on AVRs. You may use other hardware interrupts (and |
6 | configure the options at the end of usbconfig.h accordingly) if you make sure |
7 | that no higher priority interrupt is used. |
8 | ... |
Das sieht in usbconfig.h so aus
1 | /* ----------------------- Optional MCU Description ------------------------ */
|
2 | |
3 | /* The following configurations have working defaults in usbdrv.h. You
|
4 | * usually don't need to set them explicitly. Only if you want to run
|
5 | * the driver on a device which is not yet supported or with a compiler
|
6 | * which is not fully supported (such as IAR C) or if you use a differnt
|
7 | * interrupt than INT0, you may have to define some of these.
|
8 | */
|
9 | /* #define USB_INTR_CFG MCUCR */
|
10 | /* #define USB_INTR_CFG_SET ((1 << ISC00) | (1 << ISC01)) */
|
11 | /* #define USB_INTR_CFG_CLR 0 */
|
12 | /* #define USB_INTR_ENABLE GIMSK */
|
13 | /* #define USB_INTR_ENABLE_BIT INT0 */
|
14 | /* #define USB_INTR_PENDING GIFR */
|
15 | /* #define USB_INTR_PENDING_BIT INTF0 */
|
16 | /* #define USB_INTR_VECTOR INT0_vect */
|
Den Teil vom Code habt ihr gar nicht angefasst (bootloaderconfig.h:244), sondern weiter vorher dupliziert (Z. 194):
1 | // setup interrupt for Pin Change for D+
|
2 | #define USB_INTR_CFG PCMSK
|
3 | #define USB_INTR_CFG_SET (1 << USB_CFG_DPLUS_BIT)
|
4 | #define USB_INTR_CFG_CLR 0
|
5 | #define USB_INTR_ENABLE GIMSK
|
6 | #define USB_INTR_ENABLE_BIT PCIE
|
7 | #define USB_INTR_PENDING GIFR
|
8 | #define USB_INTR_PENDING_BIT PCIF
|
9 | #define USB_INTR_VECTOR PCINT0_vect
|
Daher halte ich dein Statement für ausgesprochen unglücklich: Tim schrieb: > z.B. wenn man sowieso V-USB verwendet. Es gibt also zwei Möglichkeiten: andere Pins nutzen, wie von obdev vorgesehen, und den entspr. geänderten Bootloader über ein "Upgrade" flashen, oder V-USB anpassen, so dass INT0 genutzt wird. Letzteres ist etwas bequemer - reicht es, die USB_INTR_* Definitionen aus eurer config zu nutzen, oder muss an anderen Stellen auch etwas angefasst werden?
Sorry für die Verwirrung. Die Standardkonfiguration von Micronucleus hat den Vorteil, dass sich das USI noch verwenden lässt. Für V-USB selbst ist es egal, ob INT0 oder PCINT0 verwendet werden. Du kannst die Interrupt-Konfiguration aus dem Bootloader problemlos in Deinen V-USB Code übernehmen.
Ok danke, mehr ist offenbar wirklich nicht zu machen - es funktioniert.
http://www.embedded-creations.com/projects/attiny85-usb-bootloader-overview " Update September 2013 - Adafruit released the Trinket and Gemma dev boards which use the ATtiny85 and the same boot loader mechanisms as I did. Their boot loader is not as space efficient as micronucleus, as their goal was to work with an unmodified AVRDUDE executable. " https://github.com/adafruit/Adafruit-Trinket-Gemma-Bootloader
Wieso entwickelt man so einen riesigen ATtiny Bootloader, wo es doch wesentlich kleinere gibt? 2006 habe ich den nur 96 Byte TinyLoader von Pedersen enddeckt, durch einen Fehler in der PC App benötigt er zwar eine Page mehr, ist aber wohl immer noch ungeschlagen in der Größe. Ich setze ihn seitdem in allen meinen Tiny Projekten ein. Es gibt von ihm auch eine Consolen App, die die eigene App mit dem Bootloader auf Hex-File Basis vereint. Die Webseite zum downloaden gibt es leider nicht mehr, habe aber noch alle Files falls Bedarf besteht. Gruß Ingo
Mhh. Der Bootloader funktioniert gut bislang, nun habe ich aber Pech gehabt, denn ich muss die USB-Pins ändern, da #RESET zu schwach ist, um ein Touchpanel zu "treiben". Das ergibt 2 Möglichkeiten: - #RESET wird für USB benutzt, aber das macht -bestimmt- definitiv (s.u.) Probleme - #RESET bekommt einen Transistor und schaltet das Panel an GND, ein anderer Pin wird als ADC genutzt Gibt es einen Pin-Belegungs-Standard? https://s3.amazonaws.com/digistump-resources/files/97a1bb28_DigisparkSchematic.pdf PB3, PB4 https://www.sparkfun.com/datasheets/Widgets/AVR-Stick-v12.pdf PB0, PB2 http://codeandlife.com/2012/02/22/v-usb-with-attiny45-attiny85-without-a-crystal/ PB1, PB2 Eher nicht, also egal. Ich will's doch mal mit USB am RESET-Pin probieren, d.h. nur zwei Leitungen tauschen. Also den Bootloader an die neuen Pins angepasst und dann das bootloader-upgrade erzeugt .. https://github.com/micronucleus/micronucleus/tree/master/upgrade http://dl.bintray.com/oneclick/rubyinstaller/rubyinstaller-1.9.3-p484.exe?direct .. aber da hakt's noch:
1 | F:\micronucleus-master\upgrade>ruby generate-data.rb micronucleus_ATtiny85_PB3-5.hex |
2 | I:/Ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- libusb (LoadError) |
3 | from I:/Ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' |
4 | from F:/micronucleus-master/ruby/micronucleus.rb:1:in `<top (required)>' |
5 | from generate-data.rb:1:in `require_relative' |
6 | from generate-data.rb:1:in `<main>' |
Macht doch keinen Sinn, zum Erzeugen der Daten wird libusb sicher nicht gebraucht. Also die erste Zeile in "micronucleus.rb" mit '#' auskommentiert und nochmal probiert .. spuckt einen Haufen Bytes aus und schreibt "bootloader_data.c". WinAVR2010.. erzeugt dann das upgrade.hex Mit bootloader flashen.. wenn jetzt was schiefgeht, bin ich draußen :-) Pins umlöten.. Anwendung anpassen.. Mit bootloader ... "Unknown Device" !! Es wäre wohl besser gewesen, das mit V-USB erstmal auszuprobieren, anstelle gleich den Bootloader zu tauschen.. Also, der AVR #RESET Pin ist mehr oder weniger unbrauchbar.. Und der t85 auch, da hilft nur: https://www.mikrocontroller.net/articles/AVR_HV-Programmer http://www.simpleavr.com/avr/hvsp-fuse-resetter
gugl schrieb: > Also, der AVR #RESET Pin ist mehr oder weniger unbrauchbar.. Du spielst aber auch mit dem Feuer :) Der Reset Pin kann ja weniger treiben, als die normalen I/O Pins. V-USB benötigt wegen der Zenerdioden einen einigermassen hohen Ausgangsstrom wenn der Pin auf Hi ist. Vielleicht klappt es ja ohne die Zener-Diode? Dann müsstest Du allerdings die Betriebsspannung des Controllers absenken, damit der USB-Port nicht geschädigt wird, was evtl. wieder Probleme mit der hohen Taktfrequenz mit sich bringt. Ingo Stahl schrieb: > 2006 habe ich den nur 96 Byte TinyLoader von Pedersen enddeckt, durch Ein netter Bootloader, aber er kann kein USB! Darum geht es hier gerade.
Seit ein paar Tagen ist V1.11 draussen: https://github.com/micronucleus/micronucleus
1 | Changes compared to v1.10: |
2 | • The size was reduced further to 1816 bytes, allowing 6380 bytes user space. |
3 | (320 bytes more than in v1.06) |
4 | • The bootloader will always start and never quit if no user program was loaded. |
5 | This allows for much easier driver installation. Use the new "--erase-only" |
6 | function of the command line tool to create a clean device. |
7 | • New entrymodes have been added. See firmware release notes and source code |
8 | comments for details. |
9 | • All incoming data is now CRC checked to improve robustness. |
:
Bearbeitet durch User
Hallo, ich habe mir die aktuelle Version aus github gezogen, da ich derzeit mit einem attiny167 spiele und entdeckt habe, dass Du den auch gerade unterstützen möchtest. Ich kann nach erster Analyse den Vorrednern nur zustimmen, dass ein Aufräumen des Codes an einigen Ecken mehr als angebracht erscheint. So halte ich es für sinnvoll, unterschiedliche Controller bzw. Konfigurationen in eigene Dateien auszugliedern, die dann jeweils inkludiert werden, anstatt per bedingter Compilierung alles in eine Datei zu packen. Nun aber zu meinen konkreten Fragen: BOOTLOADER_ADDRESS wird im Makefile als HEX-Value ohne führendes "0x" definiert:
1 | BOOTLOADER_ADDRESS = 3A80 |
Dies wird dann in einem weiteren Schritt für einige DEFINES nachgeholt:
1 | DEFINES = -DBOOTLOADER_ADDRESS=0x$(BOOTLOADER_ADDRESS) #-DDEBUG_LEVEL=2 |
In den LDFLAGS wird dann aber der Wert ohne "0x" übergeben:??
1 | LDFLAGS = -Wl,--relax,--section-start=.text=$(BOOTLOADER_ADDRESS),-Map=main.map |
Warum das? Weiterhin zur Berechnungsformel der BOOTLOADER_ADDRESS im Kommentar: Die Adresse soll auf einer Seitengrenze liegen, soweit klar. Warum wird allerdings auf eine Seite abgerundet und nicht aufgerundet? Die aktuelle Adresse passt so gar nicht zum attiny167, der ja 128 Byte Seiten hat (64 Words anstelle 32 Words des attiny85). Weiter zu den verwendeten USB-Pins: Hier werden PB0 und PB2 verwendet. Im Kommentar steht:
1 | Please note that D+ must also be connected to interrupt pin INT0! |
Diese Anforderung wird jedoch nur von PB6 erfüllt. Ich habe sowohl mit Deinen Einstellungen, als auch mit PB6 (D+) und PB3 (D-) versucht, bekomme den Loader jedoch nicht zum Laufen. PB3/PB6 halte ich für die idealeren Pins, da somit das USI Interface PB0-PB2 frei bleibt. Das kann jedoch je nach Anwendung unterschiedlich aussehen. Zunächst wäre es mal gut, den Loader überhaupt funktionstüchtig zu bekommen. Läuft der Loader bei Dir auf den attiny167 schon, oder gibt es jemanden, der den Loader auf einem attiny167 installiert hat?
:
Bearbeitet durch User
Ich antworte mir hier mal selbst zur Frage der Bootlader-Adresse. Die Berechnung stimmt wohl, da der Bootloader soweit oben im Adressraum abgelegt werden soll, als möglich. Hier der Kommentar aus dem Makefile:
1 | # hexadecimal address for bootloader section to begin. To calculate the best value: |
2 | # - make clean; make main.hex; ### output will list data: 2124 (or something like that) |
3 | # - for the size of your device (8kb = 1024 * 8 = 8192) subtract above value 2124... = 6068 |
4 | # - How many pages in is that? 6068 / 64 (tiny85 page size in bytes) = 94.8125 |
5 | # - round that down to 94 - our new bootloader address is 94 * 64 = 6016, in hex = 1780 |
Zu genau diesen Zahlen habe ich eine Beschreibung erstellt:
1 | page Usage: B = Bootloader u = unused f = free for programming |
2 | address |
3 | |
4 | 0x1FC0 BBBBBBBBBBBBBBuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu |
5 | 0x1F80 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB |
6 | 0x1F40 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB |
7 | .. |
8 | .. |
9 | 0x17C0 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB |
10 | 0x1780 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB |
11 | 0x1740 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff |
12 | .. |
13 | 0x0040 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff |
14 | 0x0000 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff |
Der Bootloader benötigt als Speicher immer Vielfache der Speicherseitengröße des jeweiligen Prozessors. Beim Attiny167 also 128 Byte. Da die Startadresse errechnet wird, wird der freie Speicher abgerundet, was erst nach einigem Nachdenken aus der Dokumentation hervorging. Es muss allerdings, meinem Kenntnisstand nach, die Summe von .text und .data aus der Compilerangabe herangezogen werden. Optimierungen des Bootloaders machen -insbesondere für den attiny167- wohl nur dann Sinn, wenn eine weitere Speicherseite für Programme verfügbar wird. Aussagen wie: > The size was reduced further to 1816 bytes, allowing 6380 bytes user space. > (320 bytes more than in v1.06) passen dann nicht, da dies keine Vielfachen von Seitenangaben sind. Oder habe ich irgendetwas übersehen? Im Code werden ja dann die Seiten für die Applikation gelöscht, was zu meiner obigen Grafik passt:
1 | static inline void eraseApplication(void) {
|
2 | |
3 | uint16_t ptr = BOOTLOADER_ADDRESS; |
4 | |
5 | while (ptr) {
|
6 | ptr -= SPM_PAGESIZE; |
7 | boot_page_erase(ptr); |
8 | } |
9 | ... |
:
Bearbeitet durch User
Hi Fuchur, vielen Dank für Deine Kommentare. Als erstes muss ich darauf hinweisen, dass Du herzlich eingeladen bist, Änderungsvorschläge direkt als Pull-Request zu submitten :) https://github.com/micronucleus/micronucleus/pulls Fuchu R. schrieb: > Nun aber zu meinen konkreten Fragen: > BOOTLOADER_ADDRESS wird im Makefile als HEX-Value ohne führendes "0x" > definiert: Guter Punkt. Das scheint bereits vom USBasploader zu kommen. Warum es so ist, weiss ich auch nicht. Am Makefile habe ich bisher nichts geändert, da soweit alles funktioniert. Fuchu R. schrieb: > ich habe mir die aktuelle Version aus github gezogen, da ich derzeit mit > einem attiny167 spiele und entdeckt habe, dass Du den auch gerade > unterstützen möchtest. Die Attiny167-Unterstützung ist bisher nur Trockenschwimmen. Ich habe keinen 167er und konnte sie bisher nicht testen. Erik von Digistump wird die Version testen, da die nächste Version des Digisparks auf dem ATtiny167 basieren soll. Bisher ist noch kein Support für einen far jmp implementiert. Daher muss der Bootloader innerhalb der ersten 8kb liegen. Ist das vielleicht das Problem? Funktioniert V-USB generell auf Deinem ATtiny167? Fuchu R. schrieb: > Im Kommentar steht:Please note that D+ must also be connected to > interrupt pin INT0! > Diese Anforderung wird jedoch nur von PB6 erfüllt. Das stammt aus der V-USB Dokumentation und gilt nur, wenn INT0 verwendet wird. Auf den neueren ATtinies mit pin change interrupt ist die Pinzuordnung egal. Die anderen Fragen hast Du Dir ja schon selbst beantwortet :) Fuchu R. schrieb: > Es muss allerdings, meinem Kenntnisstand nach, die Summe von .text und > .data aus der Compilerangabe herangezogen werden. Nach avr-objcopy gibt es nur eine .text section. Fuchu R. schrieb: > Optimierungen des Bootloaders machen -insbesondere für den attiny167- > wohl nur dann Sinn, wenn eine weitere Speicherseite für Programme > verfügbar wird. Korrekt. > Aussagen wie: >> The size was reduced further to 1816 bytes, allowing 6380 bytes user space. >> (320 bytes more than in v1.06) > passen dann nicht, da dies keine Vielfachen von Seitenangaben sind. Oder > habe ich irgendetwas übersehen? Der Userspace ist natürlich in Vielfaches der Seitengröße. Die Codegroße ist unabhängig von der Seitengroße.
:
Bearbeitet durch User
> Als erstes muss ich darauf hinweisen, dass Du herzlich eingeladen bist, > Änderungsvorschläge direkt als Pull-Request zu submitten :) Dazu muss ich mich wohl erstmal in Git einarbeiten. Das ist doch deutlich komplexer als SVN. Ich bin gerne bereit die Doku zumindest in den Dingen glattzuziehen, über die ich stolpere. Ich habe die Erfahrung gemacht, dass keine Doku mitunter weniger schlimm, als veraltete oder widersprüchliche Doku ist. > Nach avr-objcopy gibt es nur eine .text section. Hmm, dann wäre der Kommentar ja ganz daneben, der nur .data in die Berechnung einbeziehen will. Im attiny167-Zweig gibt es jedoch tatsächlich nur eine .text-Ausgabe, während es im Master-Zweig nur eine .data Ausgabe gibt. Nach diff auf das Makefile wird im tiny167-Zweig avr-size auf das bin-file ausgeführt
1 | main.hex: main.bin |
2 | @rm -f main.hex main.eep.hex |
3 | @avr-objcopy -j .text -j .data -O ihex main.bin main.hex |
4 | @avr-size main.bin |
Im Master-Zweig jedoch auf das hex-file
1 | main.hex: main.bin |
2 | rm -f main.hex main.eep.hex |
3 | avr-objcopy -j .text -j .zerotable -j .data -O ihex main.bin main.hex |
4 | avr-size main.hex |
Demnach gibt es nach avr-objcopy wohl nur noch .data, was insofern auch logisch ist. Hier würde ich in die Doku den Hinweis auf die Addition von .data und .text aufnehmen, dann spielt es z.B. keine Rolle, ob *.hex oder *.bin ausgewertet werden. > Bisher ist noch kein Support für einen far jmp implementiert. > Daher muss der Bootloader innerhalb der ersten 8kb liegen. > Ist das vielleicht das Problem? Das werde ich gleich nachher mal ausprobieren. Ich habe bisher natürlich versucht, den Loader ans obere Ende der 16k zu bekommen. Mit dem Loader in der Mitte ist der attiny167 auch relativ witzlos. Stellt sich mir nur die Frage: Warum schreit der Compiler hier nicht? Ich bekam sonst auf die Finger, wenn ich zu weit springen wollte. > Funktioniert V-USB generell auf Deinem ATtiny167? Eine kleine per ISP hochgeladene Testanwendung (wackelt alle 30 Sekunden mit dem Mauszeiger), funktioniert an einem Rechner ohne Probleme zu 100%, wird an zwei anderen jedoch nur als fehlerhaftes USB-Gerät erkannt. Ich verwende die V-USB Kleinteile aus dem Guloshop (https://guloshop.de/shop/Zubehoer-und-Kleinteile/V-USB-Kleinteileortiment::76.html) und ein USB-Kabel einer alten Maus. Ich habe hier nun vor, das USB-Kabel noch zu kürzen, weiterhin will ich den Quarz noch tauschen, da dieser aus meiner Bastelkiste stammt. Ich halte Dich auf dem Laufenden, kann sich aber verzögen, da der Brotjob in den nächsten Tagen mir wenig Luft lassen wird.
Fuchu R. schrieb: >> Als erstes muss ich darauf hinweisen, dass Du herzlich eingeladen bist, >> Änderungsvorschläge direkt als Pull-Request zu submitten :) > Dazu muss ich mich wohl erstmal in Git einarbeiten. Das ist doch > deutlich komplexer als SVN. Es gibt einen Windows-Client der ziemlich straightforward ist. Komplizierter als SVN ist es eigentlich nicht, wenn man das Fork&Merge Prinzip verstanden hat. Github bietet auch einige Projektverwaltungsfunktionen an, um Bugs zu dokumentieren. Ich habe inzwischen den far jmp Support ergänzt, mangels 16kb ATtiny aber noch nicht getestet. Die aktuelle Version liegt hier: https://github.com/micronucleus/micronucleus/tree/testing-V2-T187 Es sollte zumindest soweit funktioniert, dass der Bootloader per USB vom Computer erkannt wird. Das konnte die alte Version auch schon. Ich habe die Ausgabe von AVR-Objcopy noch einmal klargestellt. Änderungen sind übrigens hier dokumentiert: https://github.com/micronucleus/micronucleus/pull/43 Fuchu R. schrieb: >> Funktioniert V-USB generell auf Deinem ATtiny167? > Eine kleine per ISP hochgeladene Testanwendung (wackelt alle 30 Sekunden > mit dem Mauszeiger), funktioniert an einem Rechner ohne Probleme zu > 100%, wird an zwei anderen jedoch nur als fehlerhaftes USB-Gerät > erkannt. > Ich verwende die V-USB Kleinteile aus dem Guloshop > (https://guloshop.de/shop/Zubehoer-und-Kleinteile/V-USB-Kleinteileortiment::76.html) > und ein USB-Kabel einer alten Maus. Ein Aufbau auf einem Breadboard ist natürlich immer etwas kritisch. Die Kabellänge sollte keinen so großen Einfluss haben, da das Signal durch die Serienwiderstände terminiert wird.
Die ATtiny167 Version ist inzwischen erfolgreich getestet worden. https://github.com/micronucleus/micronucleus/tree/testing-V2-T187
:
Bearbeitet durch User
Hallo zusammen, ich kann bestätigen, dass die aktuelle Version nun auch bei mir läuft. Abweichende Konfiguration: D- auf PB3, D+ auf PB6, da ich das I2C auf PB0/PB2 nutzen möchte. Mein Aufbau wird nun auch an allen getesteten Rechnern erkannt, nachdem ich den Quarz getauscht habe. Kommt die weitere Code-Reduktion überwiegend aus dem Weglassen der PLL-Taktsynchronisation für den tiny85?
Fuchu R. schrieb: > Mein Aufbau wird nun auch an allen getesteten Rechnern erkannt, nachdem > ich den Quarz getauscht habe. Prima! > Kommt die weitere Code-Reduktion überwiegend aus dem Weglassen der > PLL-Taktsynchronisation für den tiny85? Ja, das OSCCAL Handling belegt ca 100 Bytes. Allerdings ist auch die 16 MHz Version von V-USB deutlich kleiner als die 16.5 MHz Version.
Hier ist ein Artikel über die USB-Implementierung für Micronucleus V2: http://cpldcpu.wordpress.com/2014/03/02/interrupt-free-v-usb/ MN V2 nutzt eine V-USB Modifikation, die ohne Interrupts auskommt. Das hat erhebliche Vorteile für den Bootloader, da dann der Interrupt-Vektor im Nutzerprogramm nicht mehr gepatched werden muss. Interessanterweise wird die USB Übertragung auch deutlich schneller.
:
Bearbeitet durch User
> Die Attiny167-Unterstützung ist bisher nur Trockenschwimmen. Ich habe > keinen 167er und konnte sie bisher nicht testen. Erik von Digistump wird > die Version testen, da die nächste Version des Digisparks auf dem > ATtiny167 basieren soll. Ist das der attiny mit micronucleus? https://www.kickstarter.com/projects/digistump/digispark-pro-tiny-arduino-ready-mobile-and-usb-de
:
Bearbeitet durch User
Hier eine Liste der mir bekannten Boards, die Micronucleus einsetzten: - Digispark: http://digistump.com/products/1 - BBtech ATtiny85 USB-Board: https://www.tindie.com/products/BBTech/attiny85-usb-development-tool-board/ - Pro Nano: http://www.jayconsystems.com/pro-nano-50v-attiny85.html - Iteaduino Tiny: http://imall.iteadstudio.com/im130615003.html - Olimexino 85s: https://www.olimex.com/Products/Duino/AVR/OLIMEXINO-85S/open-source-hardware - Olimexino 85: https://www.olimex.com/Products/Duino/AVR/OLIMEXINO-85-KIT/open-source-hardware - Fosdem 85: https://www.olimex.com/Products/Duino/AVR/FOSDEM-85/open-source-hardware - Paperduino: http://paperduino.eu/doku.php
:
Bearbeitet durch User
Angehängte Dateien:
-
nanite-pic1.jpg
200 KB -
nanite-pic2.jpg
270 KB
Dies ist mein eigenes Board. Es nutzt den gleichen Footprint wie ein DIP ATtiny85: http://cpldcpu.wordpress.com/2014/04/25/the-nanite-85/
:
Bearbeitet durch User
Hallo Tim, Ich habe vor kurzem angefangen, mit V-USB auf dem tiny85 zu spielen. Über kurz oder lang bin auch ich über micronucleus gestolpert. Bevor ich mir einen tiny85 bricke folgende prinzipielle Fragen bzw. Annahmen zur Bestätigung/Korrektur: -- micronucleus wird als USB Gerät mit eigener VID/PID erkannt? -- Welche Device Klasse implementiert micronucleus? -- Wenn nun mein Userprogramm auch ein USB Gerät implementiert, muss ich dann ---- entweder einen Pin für das Device (dis)connect (schaltbarer Pullaup auf D-) einplanen ---- oder das Starten des Bootloaders an einen Hardwarezustand knüpfen? Mir gefällt für die zweite Variante die Beschaltung des RST Pins in deinem Nanite Projekt sehr gut, da ich in meinem Projekt nur Ausgangspins mit LEDs für die Bootloaderlogik hernehmen kann. Rund um diese RST Beschaltung im Nanite ist mir noch aufgefallen: ---- Was passiert, wenn der Nanite am USB Port angeschlossen bleibt, nachdem ein Userprogramm startet - i.e. usb_poll() wird ja dann in der Regel nimmer aufgerufen? Verliert der Nanite hier über kurz oder lang die Verbindung? ---- Falls das Userprogramm auch ein USB Gerät implementiert und deinen Vorschlag mit dem WDT inkludiert: Kann ich da dann überhaupt eine Reenumeration und damit ein erneutes korrektes Erkennen des Bootloaders am USB Bus erreichen? Danke für deine Arbeit am micronucleus ...... Ich kann nur noch soviel sagen (da ich selber als Softwareentwickler arbeite): Wenn am Ende des Tages die einzigen Probleme gemischte ANSI-C und C++ Kommentare, oder unerklärliche historisch gewachsene preproc defines in prähistorischen Makefiles sind, dann gehe ich getrost in den Feierabend. LG Gogo
Hallo Gogo, vielen Dank für Dein Feedback. Der zentrale Punkt Deiner Fragen scheint sich darum zu drehen, was passiert wenn der Bootloader fertig ist und das Userprogram gestartet wird. Es ist ganz einfach: Die USB-Verbindung wird durch einen Bus Reset getrennt und der Computer sieht das Device nicht mehr. Wenn Dein Userprogramm auch V-USB Einsetzt, wird es als neues Device auftauchen. Übrigens musst Du die Reset-Fuse nicht setzen, damit MN funktioniert. Du kannst es auch risikofrei ohne ausprobieren. Grüße, Tim
Hallo Tim, Danke für die Antwort - Micronucleus verabschiedet sich tatsächlich vom USB Bus und mein Userprogramm taucht auf - Ich habe mit offenem Mund das syslog verfolgt. Ich verstehe aber noch immer nicht wie diese Magie fnktionieren kann ;) -- In leaveBootloader wird zwar usbDeviceDisconnect gerufen - Ich habe den Pullup an D- aber weder an einen PortPin gelegt, und schon gar nicht micronucleus davon erzählt (in bootloaderconfig.h) -- Ist es also das cli() direkt davor, das die USB Kommunikation brutal abwürgt? Ich hatte nämlich folgendes vor: -- ein einzelner Taster schickt (bei longpress) die UserApp in den Watchdog Tod, nachdem sie das USB-Device über ein, tatsächlich auch mit Hardware, hinterlegtes, usbDeviceDisconnect vom OS abmeldet (für den Pin hätte ich den RESET eingeplant gehabt) -- micronucleus nutzt nun entweder den WD reset, oder den Tasterzustand als StartIndikator Den RST will ich ohnehin deaktivieren (und mir damit den Pullup sparen) - Ist es für micronucleus vorteilhaft (stabilität, kompatibilität) wenn ich in meiner Schaltung USB_CFG_PULLUP_* vorsehe, und damit einen Hardware Disconnect ermögliche, oder würde das deiner Ansicht nach keinen Unterschied machen? LG Gogo
Das USB-Device wird "abgemeldet" in dem von Micronucleus ein Bus-Reset erzwungen wird. Dazu werden beide Leitungen auf Low gezogen. Besser wäre es natürlich, wenn man den Pull-Up widerstand dazu auch abklemmen würde, aber es ist auch so noch alles innerhalb der Spezifikationen. Über den Pull-Up fließen gerade mal 5/1.5=3.3mA. Das ist für den AVR kein Problem. Der Reset über den Watchdog ist beim Nanite genau so implementiert, wie Du es beschreibst. Schaue Dir einmal nanite.h an: https://github.com/cpldcpu/Nanite/blob/master/Software/Nanite.h In Micronucleus kannst Du als Bootloaderconfig entweder "ENTRY_WATCHDOG" nutzen, oder direkt den Taster abfragen, der den Watchdog-Reset auslöst. z.B. "ENTRY_JUMPER" und "JUMPER_PIN PB5". Letzeres ist etwas robuster, da es nicht auf das User-Program angewiesen ist.
Micronucleus V2.0b ist fertig: https://github.com/micronucleus/micronucleus Micronucleus is a bootloader designed for AVR ATtiny microcontrollers with a minimal usb interface, cross platform libusb-based program upload tool, and a strong emphasis on bootloader compactness. To the authors knowledge this is, by far, the smallest USB bootloader for AVR ATtiny The V2.0 release is a complete rewrite of the firmware and offers significant improvements over V1.x: • Support for the entire ATtiny family instead of only ATtiny85. • Much smaller size. All configurations are below 2kb. • Interrupt free V-USB: no patching of the user program INT-vector anymore. • Faster uploads due to new protocol. • Far jmp also allows using ATtinies with more than 8kb flash. • Many robustness improvements, such as compatibility to USB hubs and less erratic time out behavior. Due to the many changes, also the upload tool had to be updated. The V2.0 upload tool is backwards compatible to the V1.X tool, though.
Großes Kompliment an Tim und alle anderen Beteiligten. Die ganze V-USB Geschichte ist ja schon spannend und der Bootloader eine tolle Anwendung. Daumen hoch! Weiterhin kann ich die Kritik bezüglich Chaos zumindest in der aktuellen Version nicht mehr nachvollziehen. Sieht alles sehr ordentlich aus und gut dokumentiert bzw. beschrieben.
Ach ja, kurze Frage noch. Es gibt ja die Möglichkeit 16 und 16.5 Mhz (und noch weitere) zu konfigurieren. Welcher Wert verwendet werden soll durch F_CPU festgelegt, korrekt? Konkrete Frage zu F_CPU = 16500000. So wie ich es verstanden habe, wird dann der interne RC Osizilators durch die Fuses auf 16 Mhz eingestellt und dann durch die OSCR auf 16.5 Mhz "getrimmt". Ist das korrekt?
Danke für das Feedback! Matthias Denzel schrieb: > Konkrete Frage zu F_CPU = 16500000. So wie ich es verstanden habe, wird > dann der interne RC Osizilators durch die Fuses auf 16 Mhz eingestellt > und dann durch die OSCR auf 16.5 Mhz "getrimmt". Ist das korrekt? Ja, genau. Bei den Anderen muss teilweise noch stärker "Verstimmt" werden.
Super. Danke für die Info. Wirklich, wirklich pfiffiges Projekt. Habe mir den Kram mit den Interrupt umbiegen (in der aktuellen Version wohl nicht mehr nötig) durchgelesen. Sehr spannende Problemlösung. Eine Sache verwirrt mich noch etwas. Tim schrieb: > Ja, genau. Bei den Anderen muss teilweise noch stärker "Verstimmt" > werden. Ich habe es so verstanden, dass "OSCCAL_RESTORE_DEFAULT 0" dafür sorgt, dass der Wert von OSCCAL nach dem Ende des Bootloader auf diesem Kalibrierten Wert bleibt. Weiterhin sorgt "OSCCAL_SAVE_CALIB 1", dass der Kalibrierte Wert von OSCCAL in die Factory-Konfiguration des uC geschrieben wird, und damit in Zukunft automatisch geladen wird. Ist das beides korrekt? Denn in der "t85_default/bootloaderconfig.h" steht oben:
1 | * Controller type: ATtiny 85 - 16.5 MHz |
2 | ... |
3 | * OSCCAL : Stays at 16 MHz |
Müsste dort dann nicht "Stays at 16.5 Mhz" stehen? Oder habe ich da etwas noch nicht ganz verstanden? Viele Grüße
V2.01 ist fertig: https://github.com/micronucleus/micronucleus • v2.01 July 26th, 2015 - Fixes "unknown USB device" issue when devices with <16MHz CPU clock were connected to a USB3.0 port. - Fixes one bug that could lead to a deadlock if no USB was connected while the bootloader was active and noise was injected into the floating D+ input. - D- line is released before the user program is started, instead of pulling it down. This solves various issues where Micronucleus was not recognized after a reset depending on the duration of the reset button activation. Att: This may lead to a "Unknown device" pop-up in Windows, if the user program does not have USB functionality itself.
Matthias D. schrieb: > > Müsste dort dann nicht "Stays at 16.5 Mhz" stehen? Oder habe ich da > etwas noch nicht ganz verstanden? Stimmt. Das muss ich in der Zwischenzeit allerdings schon geändert haben?!?
FYI: https://github.com/micronucleus/micronucleus • v2.03 February 13th, 2016 - Added page buffer clearing if a new block transfer is initiated. This fixes a critical, but extremely rare bug that could lead to bricking of the device if micronucleus is restarted after an USB error. - #74 Fixed LED_INIT macro so it only modifies the DDR register bit of the LED. (Thanks @russdill) Ciao, Martin
Die Bootloader-Update-Funktion ist jetzt auch in Version 2.03 verfügbar. Ich habe die Ruby-Abhängigkeiten zu libusb entfernt, damit reicht eine minimale Ruby-Installation (nur getestet unter Linux - Debian Stable). https://github.com/micronucleus/micronucleus In meinem Fork https://github.com/Ho-Ro/micronucleus sind auch vorkonfigurierte Files update-*.hex in update/releases verfügbar, die ich aus den Dateien in firmware/releases gebaut habe - speziell für die "ruby-losen" Anwender. Die Version für t85_default.hex konnte ich problemlos mit dem alten Bootloader (Ver. 1.6) meiner China-Clones des Digispark ATtiny85 flashen. Theoretisch ist es auch möglich, per avr-objcopy den Bootloader so umzuwandeln, dass er mit "upgrade.o" gelinkt werden kann, ein Fragment ist seit einigen Jahren im Makefile vorhanden. Jetzt fehlt "nur noch" der Linker-Aufruf und die Anpassung in "upgrade.c". Das ist aber eine Aufgabe für lange Winterabende... Makefile
1 | ... |
2 | upgrade: main.bin |
3 | avr-objcopy -O binary main.bin main.raw |
4 | avr-objcopy -I binary -O elf32-avr \ |
5 | --rename-section .data=.text \ |
6 | --redefine-sym _binary_main_raw_start=loader \ |
7 | --redefine-sym _binary_main_raw_end=loader_end \ |
8 | main.raw bootloader_linkable.o |
9 | ... |
Ciao, Martin
:
Bearbeitet durch User
Hi, manchmal geht es schneller als man denkt... Ich habe das Linken wie oben beschrieben hinbekommen, der Code sah gut aus - Listing und disassemblerten Code angeschaut, sah immer noch gut aus - dann Luft angehalten und mutig per Bootloader übergeflasht - gewartet - tada!, das Board bootet - und sogar mit dem neuen Bootloader, zum Test hatte ich die Wartezeit von sechs auf drei Sekunden verkürzt :) (Wenn's schiefgegangen wäre, hätte ich meinen STK500 nach Jahren wieder mal aktivieren dürfen.) -> https://github.com/Ho-Ro/micronucleus Ciao, Martin P.S.: Hat Spass gemacht, war so ähnlich wie ein altes Textadventure - allerdings mit nur einem Leben ;)
Martin H. schrieb: > Die Version für t85_default.hex konnte ich > problemlos mit dem alten Bootloader (Ver. 1.6) meiner China-Clones des > Digispark ATtiny85 flashen. Ich nicht :-( So einen habe ich offenbar gerade zerflasht, deine Änderungen sind ja schon "upstream": micronucleus.exe 2.0a4 crasht, wenn bereits ein Gerät steckt (enthalten im digistump AVR board in Arduino IDE) commandline/builds/Windows/micronucleus.exe 2.0a5 braucht eine "libusb-0-1-4.dll" (in Wahrheit libusb-win32 1.2.6.0, die man sich aus windows_driver umbenennen kann), crasht dann zwar nicht, findet aber auch kein Gerät (von github). Also mal upgrade/releases/upgrade-t85_default.hex mit 2.0a4 geflasht, dann aber >USB Device not recognized >Unknown USB Device (Device Descriptor Request Failed) >Windows has stopped this device because it has reported problems. (Code 43) >A request for the USB device descriptor failed. Ohne HV-Programmer ist jetzt wohl Schluss!
Ich hab auf meinen Rechnern nur Linux zu laufen, kann daher die Windows-Probleme leider nicht checken. Einen HV-Programmer brauchst Du sicher nicht, denn es sind ja keine Fuses verstellt. Ein einfacher ISP-Adapter (z.B. http://thomaspfeifer.net/einfaches_atmel_programmierkabel.htm) reicht. Oder was mit USB für wenige € beim Chinesen bestellt. Ciao, Martin
Martin H. schrieb: > Einen HV-Programmer brauchst Du > sicher nicht, denn es sind ja keine Fuses verstellt. Wie das, wenn der Digispark doch 6 IO-Pins, d.h. 0-5 und damit auch #RESET nutzt? Jedenfalls habe ich mit einigem Aufwand den HVSP von http://www.rickety.us/2010/03/arduino-avr-high-voltage-serial-programmer/ offenbar zum Laufen gebracht und konnte mit USBASP das aktuelle t85_default.hex (V 2.3) flashen. Mit 2.0a4 gibt es damit zumindest keinen Absturz mehr, wenn bereits eingesteckt.
gugle schrieb: > Wie das, wenn der Digispark doch 6 IO-Pins, d.h. 0-5 und damit auch > #RESET nutzt? Oh je. Ich hätte mir den Aufwand wohl tatsächlich sparen können. Meine Klone hatten wohl (E:FE, H:DD, L:E1) http://www.engbedded.com/fusecalc/ PLL 1K / 14 + 64 ms BOD 2.7 V SPI enabled Self programming enabled Aber die Original-Fuses "disablen" Reset: http://digistump.com/board/index.php/topic,2257.msg10551.html#msg10551 >Low fuse: 0xe1 >High fuse: 0x5d >Extended fuse: 0xfe Dann müsste es ja viele Post zum "defekten" Pin geben... http://thetoivonen.blogspot.de/2015/12/fixing-pin-p5-or-6-on-digispark-clones.html Egal. Danke jedenfalls an die Macher.
Nachdem ich nun wieder mal einen "digispark" wiederbelebt habe (fuse reset mit HV-programmer und flashen von micronucleus) habe ich mich eine zeitlang über das "USB Gerät nicht erkannt" gewundert, bis ich endlich auf die zurückgesetzten fuses gekommen bin... Daher hier nochmal zum kopieren:
1 | >avrdude -p t85 -c usbasp -B 10 |
2 | |
3 | avrdude: set SCK frequency to 93750 Hz |
4 | avrdude: AVR device initialized and ready to accept instructions |
5 | |
6 | Reading | ################################################## | 100% 0.01s |
7 | |
8 | avrdude: Device signature = 0x1e930b (probably t85) |
9 | |
10 | avrdude: safemode: Fuses OK (E:FE, H:DF, L:62) |
11 | |
12 | avrdude done. Thank you. |
13 | |
14 | |
15 | >avrdude -p t85 -c usbasp -B 10 -U lfuse:w:0xe1:m -U hfuse:w:0xdd:m -U efuse:w:0xfe:m |
Reset und SPI sind aktiv. Wem die 6s Wartezeit des Bootloaders zu lang sind, wird hier fündig: Beitrag "Re: Digispark Attiny85 schneller booten lassen."
Anbei eine aktuelle micronucleus.exe mit MinGW gebaut (103 KB, 2018-05, Download/Nutzung auf eigene Gefahr). Mit online verfügbaren Releaseversion habe ich Probleme (228 KB, 2017-08, wartet endlos auf Gerät) und hatte bislang eine ältere aus den Arduino-Tools für Digispark genommen (82KB, 2016-04?). Läuft bei mir ohne Beifahrer-DLL, YMMV. https://github.com/micronucleus/micronucleus/tree/master/commandline Stand https://github.com/micronucleus/micronucleus/commit/2118a88880fe9bd2f6aad9135f87d2e9abb473f2 Aus https://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.6.0/libusb-win32-bin-1.2.6.0.zip/download libusb-win32-bin-1.2.6.0.zip\libusb-win32-bin-1.2.6.0\lib\gcc\libusb.a libusb-win32-bin-1.2.6.0.zip\libusb-win32-bin-1.2.6.0\include\lusb0_usb. h kopieren (headerdatei in usb.h umbenennen) und den Pfad ggf. ins Makefile eintragen (sonst "...ld.exe: cannot find -lusb"): ++ USBFLAGS = -L...\\micronucleus\\commandline\\library Infos dazu: http://www.mingw.org/wiki/specify_the_libraries_for_the_linker_to_use Treiber: http://zadig.akeo.ie/ libusb 1.2.6.0 auswählen
Beitrag #5884228 wurde von einem Moderator gelöscht.
Beitrag #5885848 wurde von einem Moderator gelöscht.
Beitrag #5890198 wurde von einem Moderator gelöscht.
Beitrag #5890214 wurde von einem Moderator gelöscht.
Beitrag #5890414 wurde von einem Moderator gelöscht.
Beitrag #5890515 wurde von einem Moderator gelöscht.
Beitrag #5890535 wurde von einem Moderator gelöscht.
Beitrag #5890562 wurde von einem Moderator gelöscht.
Beitrag #5890576 wurde von einem Moderator gelöscht.
Beitrag #5891056 wurde von einem Moderator gelöscht.
Beitrag #5891999 wurde von einem Moderator gelöscht.
Beitrag #5892059 wurde von einem Moderator gelöscht.
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.