You might get better feedback on a CircuitPython forum.
Generally, folks will need precise information in order to diagnose a problem. Initialization of USB devices (enumeration) is entirely controlled by the host OS, and sometimes certain scenarios have not been fully tested, as I suspect is the case with your project. Because each Pico is a composite USB device, when you say that one Pico is not working, it would be more useful to troubleshoot step-by-step:
(a) First is host-side dmseg log messages, each Pico should have its keyboard (subdevice) and serial (subdevice) reported to be attached == Pico are powered and talking to the host, devices set up (supposedly).
(b) Second is to look for the entries in the /dev directory. If any is missing, that's the smoke and somehow we need to find the fire. You say that one is not found, so we may get stuck here. Initialization can be a fragile thing, and host-side USB quirks is way out of my league. But the problem can be something as simple as a config issue -- then you're in luck. (But I have no experience with the Linux USB stack.)
(c) Third, if all 4 devices are seen in /dev even when your app says that one is not found, only then can we check each keyboard or serial device one-by-one. Any of the device on /dev should be initialized and running if the OS puts it there. But is it working properly? One may not be responsive, etc.
And so on. So, unless you report something more than "not found", then on the remote side we can only make guesses and suggestions, unless someone else has seen something similar. It's an exercise in troubleshooting -- sometimes it's good to run into problems and you manage to solve it -- then reflect on how it could have been done better -- because it hones your troubleshooting skills. Embedded stuff using SDKs is great... until we run into a pothole, heh.
Generally, folks will need precise information in order to diagnose a problem. Initialization of USB devices (enumeration) is entirely controlled by the host OS, and sometimes certain scenarios have not been fully tested, as I suspect is the case with your project. Because each Pico is a composite USB device, when you say that one Pico is not working, it would be more useful to troubleshoot step-by-step:
(a) First is host-side dmseg log messages, each Pico should have its keyboard (subdevice) and serial (subdevice) reported to be attached == Pico are powered and talking to the host, devices set up (supposedly).
(b) Second is to look for the entries in the /dev directory. If any is missing, that's the smoke and somehow we need to find the fire. You say that one is not found, so we may get stuck here. Initialization can be a fragile thing, and host-side USB quirks is way out of my league. But the problem can be something as simple as a config issue -- then you're in luck. (But I have no experience with the Linux USB stack.)
(c) Third, if all 4 devices are seen in /dev even when your app says that one is not found, only then can we check each keyboard or serial device one-by-one. Any of the device on /dev should be initialized and running if the OS puts it there. But is it working properly? One may not be responsive, etc.
And so on. So, unless you report something more than "not found", then on the remote side we can only make guesses and suggestions, unless someone else has seen something similar. It's an exercise in troubleshooting -- sometimes it's good to run into problems and you manage to solve it -- then reflect on how it could have been done better -- because it hones your troubleshooting skills. Embedded stuff using SDKs is great... until we run into a pothole, heh.
Statistics: Posted by katak255 — Tue May 14, 2024 2:24 am
