[MEGOLDVA] Jessie udev 49-micronucleus.rule nem megy - nem is kell neki!

Fórumok

Van pár nagyon cuki arduino board klónom:
Digispark Kickstarter ATTINY85
Ha bedugom az USB -be akkor szépen megjelenik a syslog -ban, hogy


usb 4-1: New USB device found. idVendor=16d0, idProduct=0753
usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
mtp-probe: checking bus4, device 2: "/sys/devices/pci0000:00/0000:00:1d.2/usb4/4-1"
mtp-probe: bus: 4, device: 2 was not an MTP device

Az lsusb kimenete:
Bus 004 Device 002: ID 16d0:0753 MCS Digistump Digispark
Keresgélés után találtam ezt:
https://github.com/micronucleus/micronucleus/blob/master/commandline/49…

Betettem - végül mindkét helyre /etc/udev/rules.d és /lib/udev/rules.d alá is, de mintha ott sem lenne semmi változás.
Mi lehet ilyenkor?
Ütközik valamivel?
Hogy lehet egy ilyen "hibát" megtalálni? - egyébként a szerkezet jól működik.

Hozzászólások

Újratöltetted vele a szabályokat a bemásolás után? (udevadm control --reload-rules)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Újratöltöttem, újraindítottam - olyan mintha ott sem lenne :(
Még egy érdekesség (lehet semmi köze a rendszerhez), hogy két féle kivitelem is van:
http://digistump.com/products/1
http://chinacoolgadgets.com/2015/04/19/arduino-micro-usb-interface-digi…
A kettő másként viselkedik, az első kivitel a végén teljesen lebont, míg a másik (egyébként újabb beszerzés) az lsusb szerinti is digistump.
Zavaros, de valószínű más-más firmware verzió - micronucleus tiny85

* Én egy indián vagyok. Minden indián hazudik.

Igazából fogalmam sincs, mi az a micronucleus, csak egy tipp volt.

Másik tipp: A cdc_acm modul be van töltve a kernelben? (a szabály a kernel által létrehozott eszközre matchelne)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

"cdc_acm"? - no ezzel még sosem kellett foglalkoznom - megnézem.

A micronucleus egy olyan kis bootloader ami az ATtiny85 soros portjából közvetlenül az USB -re csatlakozik - azaz bedugod az USB -be, feláll mint valamiféle soros port és tudsz neki programot le/feltölteni - úgy használhatod mint bármely Arduino boardot. Mondjuk nem szeretnék Arduino IDE -ben programozni (nagyon fapados) de egyenlőre egyáltalán nem tudom összehozni sem Jessie (64) sem winXP (32) rendzserrel.

OFF: Mondjuk nem tűnik egyszerűnek a beüzemelés - nem túl felhasználó barát. Valami kimarad a tudományból, ha eljut odáig hogy felismeri akkor miért nem épül be?

* Én egy indián vagyok. Minden indián hazudik.

Elvileg a linux-image csomag része (https://packages.debian.org/search?searchon=contents&keywords=cdc-acm.k….: , úgyhogy egy lsmmod-ban látnod kéne, hogy van-e egy modprobe meg be kellene, hogy töltse]

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

modprobe cdc_acm betölti, ott van.
A rule -t betettem ide is oda is.
Változás - semmi :(
Az is furcsa miért kell ezt kézzel betölteni.
Továbbra is azzal jön, hogy ez "not an MTP device" - tudjuk.
Lehet az id -k hibásak? - vagy adatbázis.
Miért nem tud továbblépni az MTP device -n?

* Én egy indián vagyok. Minden indián hazudik.

Debian Jessie kernel 3.16.0-4-amd64
A cdc_acm "USB Abstract Control Model driver for USB modems and ISDN asdapters" betöltve.
Az udev számára két helyen is beillesztettem a megfelelő szabályt:


SUBSYSTEMS=="usb", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0753", MODE:="0666"
KERNEL=="ttyACM*", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0753", MODE:="0666", ENV{ID_MM_DEVICE_IGNORE}="1"

A /dev/ttyACM nem áll fel, a kernel logban "was not an MTP device".
lsusb: 16d0:0753 MCS Digistump DigiSpark
Most ez egy kernel "hiba" vagy egy konfigurációs hiba?
Hogy tudnám ezt lenyomozni, kideríteni?
Sajnos még mindig nem tudok eleget az USB rendszerről, olvasgatom ezt
http://www.linux-usb.org/USB-guide/book1.html
de nem érzem magam sokkal okosabbnak - ez a dokumentum arról szól ha minden működik, nem arról hogy mi van ha nem!?
SZERK: Vajon mennyire aktuális ez a dokumentum?
http://www.linux-usb.org/USB-guide/c607.html
"If the /proc/bus/usb directory is empty ..."
Nincs is ilyen mappám ;(
SZERK: Van ilyen mappám, de a /sys -ben!?
Ez most egy újítás a dokumentumhoz képest vagy egy Debian koncepció?

* Én egy indián vagyok. Minden indián hazudik.

Egy verbose lsusb-t adsz kérlek? (lsusb -v)

Azt hiszem találtam valamit.
Az lsusb kinmenetén:
bDeviceClass 255 Vendor Specific Class
A sudo cat /sys/kernel/debug/usb/devices -ben:
D: Ver= 1.10 Cls=ff(vend.)
...
I:* .... Driver=(none)
Ha jól értem, akkor a "class" az szállító/gyártó specifikus így a driver is és persze ilyen driver nincs a rendszereben - lehet a firmwre van rosszul "besütve"?

* Én egy indián vagyok. Minden indián hazudik.

Állj! Ezt elkiabáltam? Ki vagy mi mondja meg, hogy egy USB eszköz milyen class? Az eszköz kommunikálja le, vagy egy adatbázisból(?) kimazsolázza, a idVendor és az idProduct alapján hogy mis is ez és milyen drivert kér?
Mert ha az utóbbi, akkor forgathatok micronucleust rogyásig.
Egyenlőre nem találom a választ, ki dönti el milyen Device class az eszköz?

* Én egy indián vagyok. Minden indián hazudik.

Talán mégis forgatni kell:
https://en.wikipedia.org/wiki/USB#Device_classes

The functionality of USB devices is defined by class codes, communicated to the USB host

Ebből még mindig nem tudom mit kellene kommunikálnia a kütyümnek:
http://www.usb.org/developers/defined_class
Nem lehet valahogy a rendszert "becsapni" - lehet egyszerűbb mint forgatni majd újraprogramozni a kütyüt?

* Én egy indián vagyok. Minden indián hazudik.

Pompás ;) A micronucleus forrásában mindent szépen be lehet állítani: device class, device subclass, interface class stb.
A kérdés csak az, hogy ezeket mire is kellene beállítanom?
Ráadásul a reset láb a fuse -ban ki van véve - kell mint I/O (az egész IC 8 láb).
Így ahhoz hogy újra programozzam, valami "nagyfeszültségű" programozó eszköz kellene.
Miért nem lehet az USB alrendszerre egy drivert "ráerőszakolni"?

* Én egy indián vagyok. Minden indián hazudik.

Tettem egy gyenge, de annál időigényesebb próbát - feldobtam egy SID -et 4.5.x kernellel.
Azért más az eredmény - nem küzd az MTP device -al.
Ki kell derítenem milyen class és egyéb azonosítók kellenek ahhoz, hogy a ttyACM* felálljon.
Meg kell találnom, hogy tudom visszaállítani az ATtiny85 fuse -át hogy tudjam programozni.
Kell forgatni egy micronucleust a megfelelő beállításokkal és beégetni.

* Én egy indián vagyok. Minden indián hazudik.

Jogos. Alapvetően a micronucleus egy USB kompatibilis bootloader:
https://github.com/micronucleus/micronucleus
lásd "readme"
Arra alkalmas, hogy a felhasználó által írt programot betöltse. Bekapcsolás után egy ideig vár, majd ha nem kap inputot át vált a felhasználói program futtatására.
Jelenlegi állapotában a Linux nem ugyan felismeri az eszközt, de nem tudja beilleszteni mint ttyACM* - azt feltételezem, hogy a class, subclass stb. kódok miatt.
Az eszköz, miután bedugod, ck. 5 másodperc múlva (alap micronucleus késleltetés) elkezdi "villogtatni" a LED -jét ck. 1 sec periódussal (ami megfelel az Arduino "blink" példaprogramjának).
Vagyis, ha leforgatom a micronucleust, a megfelelő "class" kódokkal akkor képes lehet ttyACM* eszközként működni és bootloaderként funkcionálni.
A másik lehetőség, ha jól értem, hogy a micronucleus felhasználásával más, pl. HID eszközként is felcsatolhatjuk és a felhasználói program egy "keyboard" -ot szimulál.

* Én egy indián vagyok. Minden indián hazudik.

Azért mondtam, hogy jogos.
Viszont működnie kell:
https://github.com/micronucleus/micronucleus/blob/master/Devices_with_M…
ha ennyien használják.

Az jutott még az eszembe, hogy vajon, ha egyszer rendszer felismerte, tudja hol és hogyan érhető el, nem lehet mégis valahogy kapcsolatot teremteni vele - akár root -ként?
Talán a libusb?

* Én egy indián vagyok. Minden indián hazudik.

Wachag kollégának igaza van.
Mielőtt folytatnád a szkanderezést az USB-vel, érdemes lenne egy kicsit belenézned a micronucleus kódjába. A bootloader firmware az alap USB funkciókon kívül csak egy egészen minimális egyedi protokollt valósít meg ami éppen elég ahhoz hogy az user firmware-t (a saját programodat) be tudja tölteni a processzorba. Semmi többet nem tud, tehát nem fog neked pl. soros portot szimulálni az USB-n keresztül. (Az ehhez szükséges funkciók további program memória területeket foglalnának el az alkalmazói programok elől. A szoftveres USB stack miatt egyébként is több hely kell mint amennyire akkor lenne szükség ha a processzorban lenne normális, hardware alapú USB vezérlő.) A micronucleus/commandline alkönyvtárban van annak a segédprogramnak a forrása amit le kéne fordítanod ahhoz hogy legyen egy parancssoros programod ami kommunikálni tud a bootloaderrel. Ahogy elnéztem lehet vele egy kis gondod mert a réges-régen elavult libusb-0.1 API-t használja, bár a libusb-1.0 elvileg még tartalmaz hozzá egy illesztő felületet.

Belenéztem - nagyon felületesen.
A micronucleus/commandline könyvtárban megint ott van az a fránya
49-micronucleus.rules - mit már mindenhova beraktam de semmi változást nem hozott - nem áll fel a ttyACM* device :(
Nemigen piszkáltam USB -t, így a kódot mélységében nem igazán értem - pl. hogy is találja meg és kommunikál az "eszközzel" ha nincs device és driver.
Ráadásul azt láttam csak, hogy windows release van így azt hittem elsőre ez csak a windows -hoz jó :(
A Jessie (Debian 8) még tartalmazza a "libusb-0.1-4:amd64" csomagot - vagyis elvileg dolgozhat a program vele.
Lehet az egész probléma onnan ered, hogy a ttyACM az Arduino IDE -nek szükséges? (Amit egyébként nem szeretek - nagyon fakezű)

OFF: Ráadásul rengeteget bénázok a systemd miatt - utálom! Most is azzal jelentkezett be a rendszer, hogy alig bírta feldobni a loginokat, nem tudom mire vár. Ráadásul azt látom a syslog -ban hogy ha az egyik tty -ról áttérek a másikra akkor azt startolja? Néhány másodpercenként, ahogy váltok a terminálok között, "Starting Getty" és "Started Getty". Mi a sz'r ez?

* Én egy indián vagyok. Minden indián hazudik.

Bárhogy is nézem nem találok a firmware forrásában soros portra utaló funkciókat, tehát a 49-micronucleus.rules fájlt felejtsd el. Nem tudom hogy mit akart a szerző mivel a Readme fájl is utal a használatára. Talán régebben volt soros port emuláció a boot-loaderben, de most nincs. Minden esetre szívatásnak remekül megfelel hogy utal rá. Ha az eszközöd megjelenik az lsusb parancs által írt listában akkor rendben van és ne várj többet. A 49-micronucleus.rules fájlnak semmi hasznát sem veszed. Juss el odáig hogy fusson a micronucleus parancs. Az majd a libusb által felkínált listából kiválasztja a keresett eszközt a két azonosító - MICRONUCLEUS_VENDOR_ID és MICRONUCLEUS_PRODUCT_ID - alapján és megfelelő jogosultság (sudo) esetén elkezd kommunikálni vele. Tehát a micronucleus parancsod nem fog keresni semmilyen ttyACM* eszközt. Egyszerűen tojik rá hogy az létezik-e vagy sem. A libusb sem fogja keresni, hanem (amennyire emlékszem) a /dev/bus/usb/ esetleg a /proc/bus/usb/ könyvtárat használja az eszközökkel való kommunikációra. Az USB-s eszközök között beálló változásokat pedig az udev API felületen át érzékeli, ha egyáltalán használja az udev-et. (Ez fordítási opció a libusb esetében.)

A cli micronucleus, miután telepitettem a libusb-dev csomagot - ami furcsamód a 0.1.12-25 verziót telepítette - csont nélkül lefordult :)
Most viszont az a bajom, hogy ez csak letölteni tud - nincs semmilyen más teszt lehetőség, mint feltölteni egy programot.
Mit tudnék erre "gyorsan" felrakni amiből látom hogy a művelet sikeres volt?
Szerintem eleve a "blink" van rajta.

* Én egy indián vagyok. Minden indián hazudik.

Igazad van - csak örültem volna, valami egyszerű módszernek amivel el tudom dönteni működik e ez bigyó vagy sem.
"Raktáron van" több fajta bigyó, Arduino Mega, Uno, Duo, Mini, Nano stb.
(Jópofa ez a latinos elnevezés garnitúra)
A felsoroltakat könnyű "ellenőrizni" bedugod - soros port vagy emuláció (ttyUSB) - és a példaprogramokból rátöltesz valamit. Működött mind :)
A DigiStump nem, meg sem tudtam szólítani - windossal is próbálkoztam de ott sem sikerült - talán driver probléma.
(Közben találtam pl. az avrdude -hoz egy gui -t ami a "mono" librarin keresztül működik - de kicsit barátságosabb mint parancssorba összerakni valamit)
Most akkor jöhet a másik felderítendő dolog - szeretnék úgy "arduino" -t programozni, hogy nem használom az arduino ide -t.
Ha le tudom forgatni a blinket, úgy hogy mondjuk felezem a periódusát az elég látványos lehet a micronucleushoz.

* Én egy indián vagyok. Minden indián hazudik.

Úgy tűnik megtaláltam a nekem való cikket:
https://balau82.wordpress.com/2011/03/29/programming-arduino-uno-in-pur…
Első lépésben elővettem egy Arduino Pro mini -t amit "megpatkoltak" egy CH340 UART-USB chippel - ha ezzel működik jöhet a digistump.
Viszont valami nem stimmel az avrdude paraméterezésénél :(
Próba képpen elindítottam (egy másik gépen) az Arduino IDE -t elővettem a blinket - módosítottam - majd csont nélkül letöltöttem - működik.
Hogy lehetne megtudni milyen paraméterekkel használja az arduino ide az avrdude -t?

* Én egy indián vagyok. Minden indián hazudik.

A PATH-ban valahova elé (pl. /bin) ideiglenesen tegyél be egy shell scriptet, pl. ezt:


#!/bin/bash
EXEC=/usr/bin/azigazi/path
echo $@
$EXEC $@

echo helyett mentheted pl. fájlba.

Ha az IDE teljes útvonalat használ, akkor persze nem működik.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Kösz! (Magamtól rájöhettem volna.)
Bevált, elég érdekes:


avrdude -q -q -patmega328p -carduino -P/dev/ttyUSB0 -b 57600 -D -Uflash:w:/tmp/build5459842105262104269.tmp/Blink_other.cpp.hex:i

A legfeltűnőbb különbség hogy a nyakára vannak írva a dolgok.
Mindenesetre, ezzel működik :D

OFF? Bezavart, hogy anno beleütköztem abba, hogy a kínai kis jtag -em a 6.1 verzióval nem működött - csak a bináris fájlt lecseréltem és működött 5.11.1 de ezt csak a saját ~/bin mappámba raktam - az Arduino IDE úgy tűnik direkt hivatkozott rá!? Jól összezavart a dolog :)

* Én egy indián vagyok. Minden indián hazudik.

Csak a rend és az olvashatóság kedvéért.


$ avrdude -v -p atmega328p -c arduino -P /dev/ttyUSB0 -b 57600 -D -Uflash:w:blink.hex:i

Megjegyzendő: csak az 57600 baudrate a jó (sem a 115200 sem a 38400)
Nálam, az első pobálkozáskor lemaradt a végéről az "i"
Mindenesetre, szimplán a midnight commander szövegszerkesztőjével és a parancssori avr-gcc, objcopy (nem avr-objcopy?) és az avrdude gond nélkül leforgattam a programot és betöltöttem az Arduino Nano kínai klónjába ami CH340 -es UART/USB csipet használ.
Most jöhet a "micronucleus"?

* Én egy indián vagyok. Minden indián hazudik.

Úgy tűnik, a probléma megoldva :)

1. A digistump bootload -ere NEM /dev/tty{valami} csak egy bigyó.

2. A micronucleus parancssori programmal lehet feltölteni a programot
(előbb el kell indítani a programot, aztán kell bedugni a bigyót
- nincs reset láb, csak így működhet a bootloader a timeout keretben)

Már csak azt nem értem ennek a kiderítéséhez miért kellett ennyi időt elb'sznom? Miért nem lehetett ezt világosan leírni, dokumentálni?
Köszönöm a segítségeteket!

OFF: Az egészbe (nekem) bezavart, hogy létezik olyan projekt is ami egy minimalizált USB stacket képes működtetni AVR csipekkel - pl. HID. A kapcsolás is pont ilyen.

* Én egy indián vagyok. Minden indián hazudik.