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?
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.
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.
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.
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:
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
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.
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
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-Programmerhttp://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.
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:
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?
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
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:
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/pullsFuchu 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.
> 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
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/43Fuchu 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.
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.
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
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.
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
Thread beobachten
Seitenaufteilung abschalten