That USB issue? Works fine with the gadget's USB hub connected to a PC running Linux, but not when I plug in the SOM, also running Linux, that it's supposed to work with?
Well!
One of those things we just don't think about, most of the time, is how many devices we can plug into the bus. Mainly because it's nominally 127-including-hub-chips, and who among us gets anywhere close to that?
And, typically, the USB on something small, like a RasPi, will be used for a keyboard and mouse and maybe a WiFi dongle and a thumb drive.
Turns out there are limitations. Sometimes.
Like, some of Intel's USB 3.0 controllers have hard limits on the total number of endpoints in a system, which is just not something you expect.
And, as it turns out, a fair number of ARM-based SOCs are using the Mentor USB on-the-go core, which supports the control endpoint plus 15 each of in and out endpoints. Which is enough for your keyboard, mouse, WiFi dongle, and thumb drive, but if you're planning on controlling a multitude of peripherals? Maybe not.
The documentation seems to say that the host controller's endpoints can be shared among multiple devices on the bus, which is what you'd expect, isn't it? But then I look in the Linux musb driver, and I see this:
* * Control and bulk use dedicated endpoints, and there's as
* yet no mechanism to either (a) reclaim the hardware when
* peripherals are NAKing, which gets complicated with bulk
* endpoints, or (b) use more than a single bulk endpoint in
* each direction.
*
* RESULT: one device may be perceived as blocking another one.
*
* * Interrupt and isochronous will dynamically allocate endpoint
* hardware, but (a) there's no record keeping for bandwidth;
* (b) in the common case that few endpoints are available, there
* is no mechanism to reuse endpoints to talk to multiple devices.
Hm. Clearly there's some reuse of endpoints, because I can send data to the entire Imperial-bargeload of peripherals. But I can't receive data from more than the first 8-or-so that I open, so I'm guessing that getting the incoming data from an FTDI UART involves assigning a dedicated endpoint in the host controller, and that the assignment is made at open time.
It's awfully late in the project to be discovering that the SOM, which seemed to work just fine on a subset of the target hardware during the engineering-lashup phase, has the non-obvious inadequacy. And that it seems to be shared by rather a lot of the alternatives.
It doesn't help that Linux isn't reporting any sort of error when I open /dev/ttyUSBn, for some higher value of n, and the resource needed to receive data isn't available.
Well, I'll be getting my hands on a couple of different SOM/SBC things in the next day or so. Maybe one of them will work. Then there are the details of mounting, mechanical integrity, environmental specs, and all that fiddly stuff.
I really don't want to go diving into the Somebody Else's Code of the Linux USB stack to try to upgrade the host controller driver.
Update: Looks like the Allwinner A20 may be, well, a winner. I retrieved the A20 SOM and eval board from the client, hooked up the serial console and Ethernet, applied power, waited for Linux to boot, plugged in the dingus, sent the magic commands to the ACM0 device, waited for the Imperial bargeload of ttyUSB* devices to enumerate, copied over the test program, compiled and ran the test program, and... well, initial testing went well, and it appears, so far, that all the ports are actually working.
Curiously, the behavior of the modem-control lines when the port is opened appears to be different with this CPU / Linux distro. Well, that just means I need to make sure my middleware code initializes them to the expected state before enabling power.
My RasPi 3 also arrived, but I think that goes on the shelf for now. It may be cheap, but it's not even close to industrial spec, so it was never really an option for this application. Maybe for future stuff, though.
Recent Comments