Siduction Forum
Siduction Forum => Hardware - Support => Topic started by: wodga on 2024/02/26, 20:28:19
-
Zum Betreiben eines kleinen Schulroboters möchte ich einen 2.4G-Wireless-Dongle einbinden.
Ein dmesg spricht:
[ 7904.179881] hid-generic 0003:0416:FFFF.0006: input,hidraw5: USB HID v1.10 Device [MemsArt RF UART] on usb-0000:00:14.0-2/input0
[ 9168.681233] usb 1-2: USB disconnect, device number 17
[ 9170.217485] usb 1-2: new full-speed USB device number 18 using xhci_hcd
[ 9170.345151] usb 1-2: New USB device found, idVendor=0416, idProduct=ffff, bcdDevice= 1.10
[ 9170.345183] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 9170.345198] usb 1-2: Product: RF UART
[ 9170.345209] usb 1-2: Manufacturer: MemsArt
[ 9170.353464] input: MemsArt RF UART as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:0416:FFFF.0007/input/input32
Ein Auslesen über lsusb:
Bus 001 Device 024: ID 0416:ffff Winbond Electronics Corp. RF UART
Daraufhin habe ich eine udev-Regel erstellt:
SUBSYSTEM=="usb", ATTRS{idVendor}=="0416", ATTRS{idProduct}=="ffff", MODE="0666"
und anschließend mit sudo udevadm control --reload-rules die Regeln neu eingelesen.
Was habe ich hier möglicherweise falsch gemacht?
-
Gibt es eine richtige Bezeichnung für den Dongel, Hersteller und Model Bezeichnung?
RF UaRt gibt es viele, der Beilage Zettel bzw. die Verpackung könnte Aufschluss geben.
Vielleicht fehlt irgend eine Firmware?
Was für ein Linux werkelt da?
Raspberry Pi, Debian basiert oder was ganz anderes?
-
Hallo hendrikL,
es handelt sich konkret um folgendes Produkt:
"... Als Board verwendet Makeblock "MegaPi", das auf dem Arduino UNO basiert ...als Programmierumgebung wird das auf Scratch basierende mBlock bereitgestellt ... das Programm wird in Arduino C compiliert ...
Wir verwenden das an der Schule um programmieren zu schulen. Der Clou bei der Software selbst ist, dass während man mit den einfach zu erlernenden Blöcken hantiert man parallel dazu den erzeugten C-Code sehen kann, welcher letztlich den Arduino ansteuert.
Das Programm hatte ich früher bereits einmal im Browser zum laufen gebracht, wo es eine experimentelle Erweiterung für Scratch gab.
Jetzt hat der Hersteller ein debian-Paket bereitgestellt, dass eigentlich die Verbindung zum 2.4G-Dongle herstellen soll, was offenbar scheitert (https://www.mblock.cc/en/download/mlink/).
Letztlich ist es halt keine Siduction-Baustelle, dachte nur, dass ich möglicherweise mit den udev-Rules was falsch gemacht habe. Trotzdem danke für die Rückmeldung.
-
Das ist vollkommen ok, nur möchte man eine Lösung so sollte man auch bekannt geben worum es sich handelt, so kann auch besser geholfen werden. Anamnese nennt man das.
Ich selber kann jetzt nichts zur Lösung beitragen, nur ich weiß, daß es hier noch mehr Menschen gibt die damit arbeiten und vielleicht jetzt helfen können bzw. Tipps haben wo man suchen kann.
-
Ich sehe das Problem nicht! Was tut das Gerät denn nicht? Hat das "Device" am Ende nicht "Mode 0666 (rw-rw-rw-)", oder was? Dann könnte man den "User" noch den Gruppen für "serial input', "serial output" oder beide zuweisen. Ein /dev/usb... wird doch wohl auch generiert, oder?
Die "udev"-Regel sieht richtig aus und sollte spätestens beim Reboot greifen.
-
Könnte es statt /dev/usb /dev/tty<foo> sein welches generiert wird? ls -l /dev/tty* oder dmesg | grep tty
-
@hendrikL: Richtig, ein falscher Schnellschuß von mir, ich hätte nachsehen sollen. Danke. Ich meinte natürlich so etwas wie /dev/ttyUSB<n>.
-
Wenn ich jetzt vorab mlink, dann den Dongle einstecke, bekomme ich folgende Ausgabe von dmesg:
[27513.354302] usb 1-2: new full-speed USB device number 26 using xhci_hcd
[27513.481860] usb 1-2: New USB device found, idVendor=0416, idProduct=ffff, bcdDevice= 1.10
[27513.481918] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[27513.481933] usb 1-2: Product: RF UART
[27513.481943] usb 1-2: Manufacturer: MemsArt
[27513.488649] input: MemsArt RF UART as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:0416:FFFF.000C/input/input38
[27513.488768] hid-generic 0003:0416:FFFF.000C: input,hidraw1: USB HID v1.10 Device [MemsArt RF UART] on usb-0000:00:14.0-2/input0
Scheint eigentlich, dass das Gerät selbst nun richtig eingebunden wird. Dann liegt das Problem jetzt wohl an den Einstellungen im Browser. Der Hersteller empfiehlt Google-Chrome. Hab's mit Chromium und Google-Chrome probiert, zwar erscheint das Fenster von mlink (siehe Anlage) jedoch wird kein Gerät erkannt.
-
Laut Bild (Anlage) hat doch sogar ein erfolgreiches Pairing stattgefunden!
Sind die Zugriffsrechte des Benutzers unzureichend?
Hält die Dokumentation oder Webseite des Geräts keine Hilfe dazu bereit?
-
Nein es hat kein Pairing stattgefunden, sonst wäre unterhalb von "alle anschlussfähigen Geräte anzeigen" nicht ausgegraut, sondern würde ein Gerät aufgeführt.
Laut Dokumentation des Herstellers muss "mlink" mit "sudo mbot-mlink start" ausgeführt werden", d. h. der user muss in der sudoers-Gruppe sein, was der Fall ist. Ich frage mich jedoch, ob nicht der Browser ebenfalls erweiterte Rechte benötigt, damit er die Kommunikation mit der Hardware übernehmen kann. In der Dokumentation kann ich dazu leider nichts finden.
-
Wie lautet denn die URL zum Link? "localhost:<some_port>"? Dann sollte man nachsehen, "unter" welchem "User" der Dienst für <some_port> ausgeführt wird. Eventuell auch, welche Konfigurationsdatei zu diesem Dienst gehört.
-
Hallo, ich weiß nicht genau was du meinst. Das Online-Programm läuft jedenfalls hier: https://ide.mblock.cc/
Das Mlink-Programm scheint als Java zu laufen, weil ich einmal die Nachricht "/usr/bin/mblock-mlink: Zeile 8: 37761 Getötet $noded ${appDir}/app.js" empfangen habe.
-
Vom Bild her dachte ich, daß der Browser nach dem "sudo mbot-mlink start"-Kommando mit dem dadurch gestarteten Programm Kontakt aufnimmt. Der Link https://ide.mblock.cc/ (https://ide.mblock.cc/) konstruiert doch wohl - ich verstehe das nicht allzu gut - ein Python-Programm, das dann auf dem echten "Bot" ausgeführt werden soll. Wie soll das Programm zum Bot kommen? Irgendwie muß der Browser ja auch Kontakt mit dem Bot aufnehmen. Wird dazu nicht eine andere URL aufgerufen, als die obenstehende ....cc?
Das meinte ich mit dem Link "localhost:<some_port>", von dem ich glaubte, daß ihn das "mbot-mlink"-Kommando erzeugte.
Falls es sich ganz anders verhält, verstehe ich leider das Prinzip nicht. Dann kann ich nur noch die Daumen drücken.