On Mon, Dec 19, 2022 at 07:25:03PM +0100, Greg KH wrote: [...] > > That is only if you want to manually bind the generic driver to this > device. The kernel takes this and says "are you sure you want to do > this, if so, email this address and talk to these developers" :) One does need a dedicated /dev/ttyUSB. It is similar, but not identical, to /dev/ttyACM. Cf. e.g. https://rfc1149.net/blog/2013/03/05/what-is-the-difference-between-devttyusbx-and-devttyacmx/ And the board makes an effort to establish a dedicated /dev/ttyUSB. Indeed, after I plugged the board in 21:35 and did "ls -l /dev/tty*" I saw crw--w---- 1 root tty 4, 0 Dec 19 21:28 /dev/tty0 crw------- 1 dima tty 4, 1 Dec 19 21:35 /dev/tty1 crw--w---- 1 root tty 4, 10 Dec 19 21:28 /dev/tty10 crw--w---- 1 root tty 4, 11 Dec 19 21:28 /dev/tty11 ... - it's the Linux host that doesn't recognise this fact. (it's not even seen in dmesg that something happened on /dev/tty1 - probably a premature termination of something in the kernel) Needless to say, there is also /dev/ttyACM0 popping up - so this part of the communication is OK. I think it's prudent that the kernel understands that it's a a proper ttyUSB device, apparing as /dev/ttyUSB, and advertises it as such. Without it, it's hard to detect it, and indeed, the only way I see this, without an active usbserial driver, is by the time shown next to /dev/tty* > > > Unfortunately I can't easily tell you how it behaved without it, > > > as it seems to be impossible to remove things there :-( > > > https://unix.stackexchange.com/questions/463291/how-to-remove-device-id-from-manually-entered-usb-serial-driver > > > Can it be wiped by reinstalling the kernel? I can do this... > > > > OK, I removed the "new_id" by kernel reinstall, and > > now all I get is the following: > > > > [ 176.427839] usb 1-3: new full-speed USB device number 5 using xhci_hcd > > [ 176.558808] usb 1-3: New USB device found, idVendor=0d28, idProduct=0204, bcdDevice=10.00 > > [ 176.558825] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > > [ 176.558833] usb 1-3: Product: BBC micro:bit CMSIS-DAP > > [ 176.558839] usb 1-3: Manufacturer: Arm > > [ 176.558845] usb 1-3: SerialNumber: 9905360200052833525e24a702a68552000000006e052820 > > [ 176.566864] hid-generic 0003:0D28:0204.0001: hiddev96,hidraw0: USB HID v1.00 Device [Arm BBC micro:bit CMSIS-DAP] on usb-0000:00:14.0-3/input3 > > [ 177.727061] usb-storage 1-3:1.0: USB Mass Storage device detected > > [ 177.733180] scsi host0: usb-storage 1-3:1.0 > > [ 177.733333] usbcore: registered new interface driver usb-storage > > [ 177.733607] cdc_acm 1-3:1.1: ttyACM0: USB ACM device > > [ 177.733646] usbcore: registered new interface driver cdc_acm > > [ 177.733648] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters > > [ 177.739250] usbcore: registered new interface driver uas > > [ 178.752970] scsi 0:0:0:0: Direct-Access MBED VFS 0.1 PQ: 0 ANSI: 2 > > [ 178.759252] sd 0:0:0:0: [sda] 131200 512-byte logical blocks: (67.2 MB/64.1 MiB) > > [ 178.759440] sd 0:0:0:0: [sda] Write Protect is off > > [ 178.759443] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 > > [ 178.759611] sd 0:0:0:0: [sda] No Caching mode page found > > [ 178.759613] sd 0:0:0:0: [sda] Assuming drive cache: write through > > [ 178.769674] sda: > > [ 178.769773] sd 0:0:0:0: [sda] Attached SCSI removable disk > > > > As you see, no USB serial driver is loaded. > > However, https://tech.microbit.org/software/daplink-interface/ > > tells you that there is a 2nd CPU on the board, aka "interface chip", > > capable of UART. > > And that would be the ttyACM0 device node, right? Why not use just use that? Actually, the "interface chip" is reponsible not only for ttyACM, but for USB mass storage, and USB serial, all crammed in into the same physical USB port. ttyACM is a slightly different from serial USB device, understanding slightly different set of commands. (as I wrote above) An application might want to talk to the board on several virtual ports in the same time, why not? If it's a real-time communication, say? > > If I manually load the driver: > > # insmod /lib/modules/6.0.8-gentoo-x86_64/kernel/drivers/usb/serial/usbserial.ko vendor=0x0d28 product=0x0204 > > and re-insert the USB connector, I see dmesg log as in my previous > > message, and indeed, /dev/ttyUSB0 appears. > > Yes, but does using that device node actually work? > > > Well, perhaps, it's all supposed to work without a kernel module, hard > > to say. It's however confusing that a /dev/tty1 (or some other number) > > appears, but it's totally non-transparent that it is a USB connection > > (no reflection of it in dmesg). > > Again, try ttyACM0 and see if that works. Yes, it does basic things, I can use web interface for https://python.microbit.org/ to upload and run Python (https://python.microbit.org/) programs on the board. I only know Chromium talks to the board via webUSB (https://wicg.github.io/webusb/) I don't know yet whether one can try several USB interfaces from it. I'll be teaching practicals to our 1st year CS students using these boards, they will tear me apart in case I don't know the stuff. :-) And not only practical bits, but theory as well. Cheers, Dima
Attachment:
signature.asc
Description: PGP signature
