mikrocontroller.net

Forum: Projekte & Code Micronucleus - USB-Bootloader für ATtiny


Autor: Tim    (cpldcpu)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Cool aber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und wo is die Doku?

Autor: Davis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: A Hempel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: A Hempel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wie kann man dann auf die V-USB Funktionen zugreifen?

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: A Hempel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?)..

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: gugl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tim    schrieb:
> Es ist geplant, noch andere ATtinies zu unterstützen

ATtiny45 oder welche?

Autor: Davis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gugl schrieb:

> Tim    schrieb:
>> Es ist geplant, noch andere ATtinies zu unterstützen
>
> ATtiny45 oder welche?

ATTiny10.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gugl schrieb:
> ATtiny45 oder welche?

841/84/167. 45 ist aber auch kein Problem.

Davis schrieb:
> ATTiny10.

Du kannst Dich ja mal 'dran versuchen :)

Autor: da (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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 ...

Autor: gugl (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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:
#if (defined __AVR_ATtiny85__) && (HARDWARE_CONFIG == TINY85_HARDWARE_CONFIG_2)
# define USB_CFG_DMINUS_BIT      3
/* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected.
 * This may be any bit in the port.
 */
# define USB_CFG_DPLUS_BIT       4
/* This is the bit number in USB_CFG_IOPORT where the USB D+ line is connected.
 * This may be any bit in the port, but must be configured as a pin change interrupt.
 */
 #endif

vusb-20121206 usbconfig-prototype.h:
#define USB_CFG_DMINUS_BIT      4
/* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected.
 * This may be any bit in the port.
 */
#define USB_CFG_DPLUS_BIT       2
/* This is the bit number in USB_CFG_IOPORT where the USB D+ line is connected.
 * This may be any bit in the port. Please note that D+ must also be connected
 * to interrupt pin INT0! [You can also use other interrupts, see section
 * "Optional MCU Description" below, or you can connect D- to the interrupt, as
 * it is required if you use the USB_COUNT_SOF feature. If you use D- for the
 * interrupt, the USB interrupt will also be triggered at Start-Of-Frame
 * markers every millisecond.]
 */

Was nu?

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Tim (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: gugl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
...
GENERAL DESIGN NOTES
====================
All examples have D+ on hardware interrupt INT0 because this is the highest
priority interrupt on AVRs. You may use other hardware interrupts (and
configure the options at the end of usbconfig.h accordingly) if you make sure
that no higher priority interrupt is used.
...


Das sieht in usbconfig.h so aus
/* ----------------------- Optional MCU Description ------------------------ */

/* The following configurations have working defaults in usbdrv.h. You
 * usually don't need to set them explicitly. Only if you want to run
 * the driver on a device which is not yet supported or with a compiler
 * which is not fully supported (such as IAR C) or if you use a differnt
 * interrupt than INT0, you may have to define some of these.
 */
/* #define USB_INTR_CFG            MCUCR */
/* #define USB_INTR_CFG_SET        ((1 << ISC00) | (1 << ISC01)) */
/* #define USB_INTR_CFG_CLR        0 */
/* #define USB_INTR_ENABLE         GIMSK */
/* #define USB_INTR_ENABLE_BIT     INT0 */
/* #define USB_INTR_PENDING        GIFR */
/* #define USB_INTR_PENDING_BIT    INTF0 */
/* #define USB_INTR_VECTOR         INT0_vect */

Den Teil vom Code habt ihr gar nicht angefasst (bootloaderconfig.h:244), 
sondern weiter vorher dupliziert (Z. 194):
// setup interrupt for Pin Change for D+
#define USB_INTR_CFG            PCMSK
#define USB_INTR_CFG_SET        (1 << USB_CFG_DPLUS_BIT)
#define USB_INTR_CFG_CLR        0
#define USB_INTR_ENABLE         GIMSK
#define USB_INTR_ENABLE_BIT     PCIE
#define USB_INTR_PENDING        GIFR
#define USB_INTR_PENDING_BIT    PCIF
#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?

Autor: gugl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gugl schrieb:
> V-USB anpassen, so dass INT0 genutzt wird.

Quatsch, ich meine PCINT

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gugl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok danke, mehr ist offenbar wirklich nicht zu machen - es funktioniert.

Autor: gugl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.embedded-creations.com/projects/attiny8...
"
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...

Autor: Ingo Stahl (ingo-s)
Datum:
Angehängte Dateien:

Bewertung
-3 lesenswert
nicht lesenswert
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

Autor: gugl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...
PB3, PB4

https://www.sparkfun.com/datasheets/Widgets/AVR-St...
PB0, PB2

http://codeandlife.com/2012/02/22/v-usb-with-attin...
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/...

http://dl.bintray.com/oneclick/rubyinstaller/rubyi...

.. aber da hakt's noch:
F:\micronucleus-master\upgrade>ruby generate-data.rb micronucleus_ATtiny85_PB3-5.hex
I:/Ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- libusb (LoadError)
        from I:/Ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
        from F:/micronucleus-master/ruby/micronucleus.rb:1:in `<top (required)>'
        from generate-data.rb:1:in `require_relative'
        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

Autor: o_O (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Seit ein paar Tagen ist V1.11 draussen:

https://github.com/micronucleus/micronucleus

Changes compared to v1.10:
 • The size was reduced further to 1816 bytes, allowing 6380 bytes user space. 
   (320 bytes more than in v1.06)
 • The bootloader will always start and never quit if no user program was loaded. 
   This allows for much easier driver installation. Use the new "--erase-only" 
   function of the command line tool to create a clean device.
 • New entrymodes have been added. See firmware release notes and source code 
   comments for details.
 • All incoming data is now CRC checked to improve robustness.

: Bearbeitet durch User
Autor: Fuchu R. (fuchur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
BOOTLOADER_ADDRESS = 3A80

Dies wird dann in einem weiteren Schritt für einige DEFINES nachgeholt:
DEFINES = -DBOOTLOADER_ADDRESS=0x$(BOOTLOADER_ADDRESS) #-DDEBUG_LEVEL=2 
In den LDFLAGS wird dann aber der Wert ohne "0x" übergeben:??
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:
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
Autor: Fuchu R. (fuchur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
# hexadecimal address for bootloader section to begin. To calculate the best value:
# - make clean; make main.hex; ### output will list data: 2124 (or something like that)
# - for the size of your device (8kb = 1024 * 8 = 8192) subtract above value 2124... = 6068
# - How many pages in is that? 6068 / 64 (tiny85 page size in bytes) = 94.8125
# - 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:
 page     Usage:  B = Bootloader   u = unused   f = free for programming
address

0x1FC0    BBBBBBBBBBBBBBuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu
0x1F80    BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
0x1F40    BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
  ..                          
  ..                           
0x17C0    BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 
0x1780    BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 
0x1740    ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  ..
0x0040    ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
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:
static inline void eraseApplication(void) {

  uint16_t ptr = BOOTLOADER_ADDRESS;

  while (ptr) {
    ptr -= SPM_PAGESIZE;
    boot_page_erase(ptr);
  }
  ...

: Bearbeitet durch User
Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Fuchu R. (fuchur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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
main.hex:  main.bin
  @rm -f main.hex main.eep.hex
  @avr-objcopy -j .text -j .data -O ihex main.bin main.hex
  @avr-size main.bin
Im Master-Zweig jedoch auf das hex-file
main.hex:  main.bin
  rm -f main.hex main.eep.hex
  avr-objcopy -j .text -j .zerotable -j .data -O ihex main.bin main.hex
  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...) 
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.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...

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...)
> 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.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die ATtiny167 Version ist inzwischen erfolgreich getestet worden.

https://github.com/micronucleus/micronucleus/tree/...

: Bearbeitet durch User
Autor: Fuchu R. (fuchur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hier ist ein Artikel über die USB-Implementierung für Micronucleus V2:

http://cpldcpu.wordpress.com/2014/03/02/interrupt-...

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
Autor: Fuchu R. (fuchur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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/dig...

: Bearbeitet durch User
Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fuchu R. schrieb:
> Ist das der attiny mit micronucleus?

Ja, das Board nutzt auch Micronucleus.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

: Bearbeitet durch User
Autor: Tim    (cpldcpu)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: gogo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: gogo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/Soft...

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.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Matthias Denzel (matthias42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Denzel (matthias42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Denzel (matthias42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
 * Controller type: ATtiny 85 - 16.5 MHz
 ...
 *       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

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?!?

Autor: Martin HR (horo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin HR (horo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
...
upgrade: main.bin
  avr-objcopy -O binary main.bin main.raw
  avr-objcopy -I binary -O elf32-avr \
        --rename-section .data=.text \
        --redefine-sym _binary_main_raw_start=loader \
        --redefine-sym _binary_main_raw_end=loader_end \
    main.raw bootloader_linkable.o  
...

Ciao, Martin

: Bearbeitet durch User
Autor: Martin HR (horo)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 ;)

Autor: gugle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Martin HR (horo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_programmi...) reicht. 
Oder was mit USB für wenige € beim Chinesen bestellt.

Ciao, Martin

Autor: gugle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-vol...

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.

Autor: gugle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.ms...
>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-...

Egal. Danke jedenfalls an die Macher.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.