New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Differentiating ttyACM devices #955
Comments
ok cool, then seems to me like vid/pid is a possibly simple way to identify crow without handshake+fallback logic. druid does this: that said, i would not mind structuring the device detection stuff more intelligently anyway. (i have a crow but, funnily enough, i rarely am in a position to use it since i don't have any eurorack stuff. but i can test this simple connection stuff when i am back at home - travelling now.) |
Model and vendor are what's normally used for determining if a device is what you think it is, so unless there are any blockers that would prevent us from using or setting)them it should be the correct way to achieve this. |
@trentgill does crow use a custom vid/pid or is it just the STM32 default? |
The vendor and product ID are generic (STMicroelectronics, Virtual COM Port), not sure how it works to get your own. |
Simon is correct- generic vid/pid. It’s very expensive to get your own. The name ‘crow: telephone line’ is defined in one of the header files in the usbd/ folder. I thought it was a cute play on TTY devices & crows sitting on wires :) It also changes to ‘crow: bootloader’ when entering that mode fyi. |
Could someone also post the output from |
lol, I thought it was either the SoC or Linux being clever because it's registered as a modem 😆 But anyway, those two fields should be enough to identify a device I think. |
|
Did a pass at comparing the product name and manufacturer on tty devices. Don't know if this is more intelligent as such (probably still too simple), but here's a branch with a start: Works with monome grid and my DIY teensy-grid. Both show up properly on norns. For crow I'm not sure if |
so i think the summary of that change is:
it still seems quite brittle as a solution, but if it works for everyone then it's fine with me. if we're gonna bypass the regexp then let's just remove it and make the whole code module clearer. |
More or less correct. Minor corrections:
Any suggestions to make this "less brittle"? I don't know what other use cases need to be accounted for.
OK - just now got a report that the SlowGrowth Arc Clone does not work with this because it's reporting I don't have an Arc to look at but that might also be a bad match... Maybe just using ID_VENDOR is OK? |
If you can find a solution that works for all the clones and whatever devices of interest, I am happy to clean up the code module to accommodate that solution, and test it with all the devices I have (Norns factory, shield, monome grid, hid, midi, aleph, crow and other tty devices with custom protocols.) I can test with your teensy firmware too, though not with a fully built grid on top of it. By brittle I mean two things:
At this point I would probably accommodate the inherent ambiguity of broad device support, with a tiny configuration layer. So I'll do that in such a way that you or technobear or whoever can easily configure for alt hardware (gpio) or alt device profiles. How does that sound? |
I'll make an edit to my branch above to just look at ID_VENDOR and that should be a working solution for the DIY devices I know about. Previously (like w/ Arduinome for example) the only solution was to be sure to have the vendor, product and serial number modified to look like a monome device. Thus the computer or host device just thought it was a monome device. I've just followed that path for recent devices - the only difference being the new ones use ttyACM* instead of ttyUSB* I don't know that we need to change that for new devices with some other customized product name for example - mostly because other serialosc/libmonome hosts are still going to want the monome product/vendor/serial. But yes - a config layer sounds good if that's not too much hassle. While we're looking at this, it would be nice to revisit the "USB only" aspect of device_monitor.c (re: thetechnobear's issue/pr raised some time ago) - mostly to be able to support Bluetooth input devices for norns shield and fates. See #822. I did some initial work on this but I ended up in a crashing situation and wasn't sure how to debug.
|
i think we can call this resolved for now? |
I started down this roard with issue #525 and it's come back around with crow, so I'm starting a new issue to find a good way forward for future ttyACM devices.
Problem:
DIY devices using Teensy or some other microcontrollers use
/dev/ttyACM*
but [device_monitor.c] (https://github.com/monome/norns/blob/master/matron/src/device/device_monitor.c) is currently hard coded to treat any ttyACM device as a crow. There is a handshake for crow, but it just ignores anything not a crow (and it really seems like we need to differentiate between devices before it gets to the handshake stage).
I've done some hacking on this, but I could really use some guidance.
Possible Solution:
Simplify the watchers by subsystem - to only "tty", "sound", "input". For tty, check the node and then add additional checks for ttyACM devices.
In handle_device() we could look at device information from udev and get product ID, model, vendor, etc. (which is similar to what libmonome does I think). Would those details be adequate for differentiating devices*?
udevadm info --query=all --name=/dev/ttyACM0
is very handy to check those names/valuesAt this point, i think the device could be added in device_list.c as it stands (or cases added for new device types).
Thoughts? Suggestions? Help?
I don't have a crow, so i can't test against that.
* EDIT: (some) DIY devices can modify the udev Manufacturer/Product/Serial details for a particular device. With Teensy this is a super easy code change. I'm testing with a SAMD board as well (Adafruit ItsyBitsy M0). Older Arduino required reflashing the FTDI chip, but this has gotten much better with time.
The text was updated successfully, but these errors were encountered: