FS = USB 2.0 Full Speed, 12Mbit/s, compatible with USB 1.1
HS = USB 2.0 High Speed, 480 Mbit/s
I have a Raspberry Pi Pico W set to USB Host mode (meaning it acts how a desktop computer acts) and connected to the V5 Brain. My plan is to then send the serial streams over WiFi, resulting in a code uploading and serial printing experience much faster than VexNet through the controller.
Now the brain seems to negotiate a FS connection just fine, however, on the serial interface IN (into the host, out of the brain) the maximum packet size for a bulk transfer it sends is 512 bytes. This is incorrect, the maximum allowed bulk transfer packet size in FS is 64 bytes. Now as far as I can tell, the chip in the RP2040 can be extended to store packets up to 127 bytes, but no more than that (which is fine because it only does FS).
Is the USB stack on the brain a standard, off-the-shelf product, or is it a custom coded thing that you could possibly fix?
Is this even worth tracking down: My first solution was to look for boards that did support USB 2.0 High Speed (w/ 512 byte packets) - until I realized that Raspberry Pi Zeros Ws and other boards are literally selling for 4 or more times their retail price. And there’s no (WiFi, cheap (this whole project was supposed to cost $11), small) microcontroller board supporting HS USB in stock anywhere.
P.S. I’m pretty sure this is a problem with the brain, but the code and chips involved are incredibly complex, so please excuse me if I configured the usb connection wrong or something.
somewhere in between.
USB code on embedded processors is usually pretty complicated and very much tied to the specific hardware implementation the soc is using. In the case of the V5, most of the USB driver code comes from Xilinx. The usual process is to start with some sort of generic example and then modify to fit the project needs. With V5 we did this very early during the development cycle, so this code is several years old. To be honest we never considered supporting a host without USB 2.0 capability, I’m not sure I even have anything here that only implements (as a host) USB 1.1. It’s very unlikely we are ever going to do further development work on the V5 USB implementation, if I do find I have hardware around that only implements a FS link as a host, I will at least try it with a USB analyzer inline to see what happens.
Ok thanks, I’ll just find a board supporting USB 2.0 for now.
ok, I’m still not sure how to even test host in 1.1. I have some embedded systems that are 1.1 only, but they tend to get used as USB devices and it would take a bunch of work to configure them as a host. Not any help to you, but it looks like IQ2/EXP probably would support it, not exactly by design, just a happy accident, but again I can’t test it.
what was your plan, using PROS cli or something ?
slightly off topic, we will be releasing the VEX VSCode extension pretty soon. The extension uses a helper program for most communication with the VEX brains, program upload etc. called vexcom. We have this helper built for both 32 and 64 bit Raspberry Pi linux and have tested on RasPi 3. Using that along with tools like rsync and ssh pretty much gives you what you want.
Microcontrollers like the RP2040, ESP32 S2, nRF52840, etc. are the most common systems that still use FS USB.
Yes, PROS works with any Linux serial device, so my plan was serial (on mcu) → TCP → virtual serial (linux, using socat)
Yes, although for me this project is more an opportunity to learn USB, networking on a microcontroller and to make something cool than just a means to an end (remote coding).
Also, I’m a sucker for efficiency and my laptop + RP2040 is far more minimal than my laptop + a full Raspberry Pi (part of the make-something-more-cool-but-less-practical aspect).
Anyway, right now I’m trying to use this fully software defined USB stack (PIO is awesome), and I am hoping I can modify it to work with the brain. I will properly launch it with a forum post if it ends up working, else I’ll just get a Raspberry Pi to get the job done.
It may still work, even though max packet size is reported as 512, host doesn’t have to use that size.
I did find an old USB 1.1 hub and put that between the V5 and Mac, it worked without issue and the USB analyzer showed all packets were 64 bytes or less.
Only PC I had with USB 1.1 was a 20+ year old Dell with Windows 2000, it would detect the V5 as a USB device but (surprise) our drivers do not support Win2k so no further progress with that.
and yes, I have some ESP32-S3 boards, but don’t have time to mess around making them USB host devices at the moment.
Interesting… the only time I experienced it was on the user port when I printf’ed many characters without a newline (so filling up the buffer and flushing hundreds of characters at once). That led me to believe the system port would show similar behavior and could cause random bugs.
I will double check the packet size negotiation in tinyusb, thanks for the tip.
No problem. Thanks for your help. I don’t want to waste any more of your time, I’ll figure it out one way (size negotiation) or another (pio usb).
Update: the PIO stack is working flawlessly with packets of any size (at first glance at the user port’s IN endpoint)
or maybe it’s just negotiating packet sizes better? idk but it works
Update: after 15+ hours of fiddling I got USB and WiFi both working together, but now it randomly freezes at times, and requires a restart. The worst bugs are the bugs that aren’t consistent, or are dependent on a complex series of events. So I give up with using a pico for this.
I ordered an Orange Pi Zero, that runs Linux and should hopefully do this much better with just
socat (or I could theoretically run PROS/future vexcom directly on there, but with 256mb of ram probably not).
It also has USB 2.0, so it should be faaaar easier to deal with and the subject of this thread is not applicable anymore.