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.
- 6448 megtekintés
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)
- A hozzászóláshoz be kell jelentkezni
Ú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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
A cdc_acm csak egy tipp, a udev szabály keresi a /dev/ttyACM* eszközt, amit egy gyors keresés után annak kéne létrehoznia.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Köszönöm a tippet - még sajnos nem értem odáig.
OFF: Jó is lenne, ha bedobunk egy kérdést a fórumba, tíz perc elteltével jönne a megoldás :) Tipp, ötlet, iránymutatás.
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
A cdc_acm nem nincs mint modul!?
Nem lehet hogy beleforgatták? A csomagkeresőben nem találtam olyan csomagot ami erre végződne.
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Egy verbose lsusb-t adsz kérlek? (lsusb -v)
- A hozzászóláshoz be kell jelentkezni
Gondolom elég magára az eszközre:
http://pastebin.com/Q7U1wCG3
Sajnos itt sem igen tudom, mit is kellene látnom ;(
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
> bDeviceClass 255 Vendor Specific Class
Imho ezt hiába próbálod CDC-vel, nem fogja felismerni.
- A hozzászóláshoz be kell jelentkezni
Egyet értek! Pont most találtam meg én is.
Nincs más, meg kell nézni a micronucleust - lehet újra kell forgatni és beállítani. De vajon mire is?
Remélem a micronucleus konfigurációban ehhez kapok segítséget.
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Á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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Nem valószínű, hogy menni fog, l. lentebb.
- A hozzászóláshoz be kell jelentkezni
Ha cdc, és tényleg az a protokoll is (nem elég, ha átírod a számot), akkor a kernel hozzárakja a cdc drivert.
Egyéb esetben a driver a vendorid:productid párosra matchel. Ha nincs hozzá driver: pech.
- A hozzászóláshoz be kell jelentkezni
Klassz!
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Azt azért vágod, hogy ha nem úgy akar kommunikálni, mint egy CDC eszköz, akkor teljesen hiába írsz át bármilyen azonosítót. Ennél ez sokkal mélyebb változtatást igénylő dolog.
Magyarul: zsákutca, amit csinálsz. Majdnem biztosan.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Azt értsd meg, kérlek, hogy önmagában nem a class kódon múlik, az magában kevés. A mögötte levő szoftver a lényeges.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Úgy látszik soká tart mire megírok egy hozzászólást. :-/
Nincs mese, mivel programozni akarsz akkor meg kell tanulnod használni az általad választott eszközt. Kell hogy legyen rá valahol pár kisebb példa amit tudsz módosítani, lefordítani és azt betölteni.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Ú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 hozzászóláshoz be kell jelentkezni
Amikor az avrdude fut, a /proc/[pid]-ben valahol ott van.
- A hozzászóláshoz be kell jelentkezni
Sajnos az nagyon rövid ideig megy - megtalálni a pid-et és kiszedni /proc/[pid/cmdline] tartalmát?
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ú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.
- A hozzászóláshoz be kell jelentkezni