USB Device / Serial Device
SaucySoliton
Posts: 524
in Propeller 2
Am I correct that there is currently no USB device code for the P2? (CDC, keyboard, mouse, sound?)
Comments
Not sure if this contains latest: https://forums.parallax.com/discussion/170149/p2-hosted-usb-keyboard-mouse
Macca did quite some updates
Here is a program that should enumerate as CDC ACM serial port. That is all it does. It's nowhere close to USB compliance.
Serial Device Board 64006F goes on pins 16-23. Use the left / low numbered port marked by the red LED. Tested only on flexspin right now.
This is interesting. So you connect to a computer and it shows up as a serial port?
Does that mean you might not need FT chip to program?
I should be able to get there. The USB cog could do a "fake reset" on the rest of the chip, basically stop all other cogs and reset all pins (except USB) back to defaults.
Using native USB may not save much cost, since one cog is ~$2, about the same as an FT231X. The native USB would let us use a P2 to emulate a keyboard, mouse, gamepad, sound card, or webcam.
Looking forward to trying this.
Rayman, this could fit in really well with your secure cog idea. The USB cog could potentially also contain encryption code and a private key. You would still use existing development tools as usual, but 1 cog would be off limits
You could use a Max3421, but they are $10 ea.
I tried this on a couple of windows machines, it enumerates just fine
It's unlikely to be as fast as a USB-UART , and the chip-alone prices are low
lcsc has 'recent' ones like CH9102F 100+ US$0.8973 CH343G (SO16N) 100+ US$0.6173
but there are PCB area and BOM benefits, that likely exceed those chip prices.
You would need a scheme to first load the flash, and recover any bricked system, but this would have good user appeal.
I see lcsc have low cost USB-UART modules now too, as 'prop plug' alternatives.
https://www.lcsc.com/product-detail/Development-Boards-Kits_WCH-Jiangsu-Qin-Heng-CH343G6T-EVT_C2997139.html 1+US$2.94
not at lcsc yet, as a module, the CH347 - faster DUAL UART
https://www.aliexpress.com/item/1005005191167792.html HS-USB US $7.50
Here is the transmit only code. Yes, that is opposite of what we need to program the chip. Also includes a USB sniffer of low quality.
The most popular platform, Arduino, is not bothered by needing a bootloader programmed. I'm pretty sure that a malicious sketch could brick an Arduino by erasing the bootloader, but in practice nobody cares. Who has only ONE Arduino? The arduino-isp program lets you flash the bootloader onto a blank chip using an existing Arduino.
The flash has some write protect features that should reduce the chance of accidentally bricking the P2 board.
Here is a USB serial object that should work like many commonly available serial objects.
Given the line count, there are almost certainly bugs. It doesn't even check the address of USB packets. That might cause problems if attached to a hub with other devices. It's flexspin only right now.
Currently, I keep most of the FIFO configuration in hub ram. I use 4 longs per FIFO. With 16 endpoints needing 2 FIFOs each, that is potentially 128 longs needed. A big chunk out of cog RAM. There is also the issue that the application code also needs access to the FIFO pointers to transfer data. With the serial port working, I want to try USB audio class next. Tell us what USB class you want to experiment with in the comments.
Thanks for testing! I made so many changes since that version, you'll need to test again.
Looking forward to trying this
I'd vote for the webcam/uvc class, but I suspect audio is a good stepping stone along that path
Hmm, wondering if you could make it be a storage class device, basically turning the P2 into an SD reader. Would be useful to update files on the card during development. Would be much quicker than transferring over serial or whatever.
What size and speed does the Serial port manage ?
The small MCU's I've seen that have compact bootloaders, seem to use USB-HID - which suggests that codes the smallest/least resource ?
The larger ARM parts NXP do, I think have mass-storage boot loaders in ROM/
I'm trying to test. My Prop Tool 2.5.3 gives error about label being more than 30 characters.
FlexProp gives these errors:
Version 5.9.26 Compiled on: Jan 18 2023
usb_demo.spin2
|-jm_serial.spin2
|-|-jm_nstrings.spin2
E:/Parallax/Prop2/USB_Device/usb_acm_beta2/jm_serial.spin2:274: error: syntax error, unexpected FIELD
E:/Parallax/Prop2/USB_Device/usb_acm_beta2/jm_serial.spin2:304: error: syntax error, unexpected empty assignment marker _, expecting identifier or RESULT or '#'
child process exited abnormally
Finished at Wed May 3 11:47:47
Guess I'll update Prop Tool and try again
New prop tool is also giving errors on jm_serial...
Fixed that, but still complaining about labels being too long.
FlexProp now giving this error:
E:/Parallax/Prop2/USB_Device/usb_acm_beta2/usbdevice5.spin2:436: error: syntax error, unexpected FIELD
E:/Parallax/Prop2/USB_Device/usb_acm_beta2/usbdevice5.spin2:468: error: syntax error, unexpected empty assignment marker _, expecting identifier or RESULT or '#'
child process exited abnormally
Ok, replaced "field" with "fieldx" in that file too and now compiles with FlexProp, changed baud to 230400 so can see output.
Windows 10 detects something but says "USB device not recognized".
Tried that first version too. It shows a bunch of hex numbers in the serial window and then gives same not recognized message.
For those that need them I've attached the latest copies of libraries mentioned in this thread (It will be nice to ObEx again). I don't tend to use jm_serial.spin2 because it's unbuffered. I have replaced jm_nstrings.spin2 with jm_nstr.spin2. Sorry for the inconvenience of Chip's new debug features stomping on method and variable names in my libraries. I tend to be verbose, even with locals (trying to use simpler local variable names in the future).
I'm using Propeller Tool 2.9.2. All files compile without errors.
@Tubular What kind of Windows machine did you test this on?
I tried all three versions posted here now on my main Win10 box and they all say malfunctioned...
Even tried the binary in the alpha with same result, so not a compiler issue....
It works!
Just tried same usb accessory on my home PC and it works.
After changing baud to 230400 and using FlexProp can get serial comms going between FlexProp Terminal window and PST.
Strange doesn't function at work. I bet there's some domain security thing that stops it...
Weird. I wondered if it had anything to do with using an "obsolete" or "invalid" vendor id. (Openmoko) But that wouldn't make much sense, because devices produced by these companies should still work. Whitelisting USB ids doesn't seem like a useful security feature because there is nothing stopping a malicious device from impersonating something benign.
I had thought that using an older flexspin version would help compatibility, so I wouldn't inadvertently use features that require the latest git version. I guess I was using a version that was way too old.
Thanks, Jon. I'll use the new versions from now on. The usb object interface should be identical to jm_fullduplexserial, except for start(). Although since the USB interface is faster it might be worth optimizing string handling.
Builds with Propeller Tool now, and works! (tested with 2.7.0 beta)
It works too! This is great.
BTW: I think I'm seeing my issue might be that it doesn't work when going to USB port on my monitor.
Maybe it only works when directly connected to computer?
Actually, one of my other test computers had it working on a hub connected via another hub, so that's not the problem.
Maybe something strange with the USB3 hub in my Dell monitor...
Maybe it is responding to packets for other addresses. I haven't found solid evidence either way, but some hubs may broadcast downstream data to all devices. I think devices should only respond to their own address. I kept hitting FIT limits with the USB code, so ignoring addresses seemed like a good thing to defer. It's not so bad now since I cleaned out all the unused host code. Time to handle addresses properly.
Like Ray said, it works*! What a giant leap forward, thanks Saucy
Ray it might be worth trying a longer cable at work...
Deleted
I did some benchmarks in the P2 to PC direction.
Untuned implementation: 823kB/sec. I was seeing random packet sizes.
32 byte packets: 990kB/sec.
64 byte packets: 1151kB/sec. 1007kB/sec on a different machine.
For reference, 2_000_000 baud serial is theoretically 200kB/sec. I tested it at 191kB/sec.
Oh wow thats a lot more impressive than I would have expected. Nice to have margins in reserve vs the 2/3 Mbps standard ic options
Yes, impressive speeds, given all the work done in SW.
What is the P2 SysClk for that measurement, and what range of P2 SysCLK does it work over ?
Not sure what the benchmarks were done at, but the beta3 code I tested was set to 240 MHz
Wow, so faster than FTDI chip? By a lot? I didn't expect that...
Just ran this usb_acm_beta3 demo and got it working on my Mac M2 machine with MacOS Ventura without issues and can see data passing between two console windows. Nice work Saucy. This should become quite useful
I was just looking through some of the USB codebase this morning - actually not so much this code but the HID stuff macca and Wuerfel_21 are doing. Now that we are seeing independent development of USB functionality for P2 it would be good to have some way over time to support various different USB classes without excessive bloating of the code as one massive monolithic file with everything combined together or lots of different branches/variants of the USB code. For that I think we'd need some generalised framework where support for different USB classes of interest (HID, CDC serial, MassStorage etc) could be incrementally added to the code. Ideally some conditionally compiled or included file "plug in" sort of thing when you don't want support for every type of device always present in the code generated bloating it.
For that approach you'd probably want to keep the tight core USB functions in the COG+LUT RAM code and branch off to different custom handlers for different classes etc in HUB RAM. At this stage I'm not sure what USB stuff can run in HUB vs COG, and what parts are real-time and what parts are less so. I can certainly imagine it could be a fair bit of work to map that all out, and the whole PropTool vs flexspin different build capabilities could get in the way too if you want to support both toolchains.
Some generic USB polling scheduler that is also influenced by the needs of the attached USB devices would be required in host mode and that's surely a lot of work too. Also device vs host operation might (initially) need to be in different codebases and could even remain so, at least until some common framework to handle both types of roles is developed, if at all.
We'll have to see how things progress over time here, it's still early days. But great to see more progress on the USB side and especially the support for USB CDC and USB hubs now. The hub thing opens up a lot more for the P2 now than burning one COG per USB attached device that we needed before, and the CDC serial could be a cost saver in some applications where you might have a free COG but no board space or budget for FTDI etc.
Edit: I think I might have mentioned it before, but there is this LUFA project for AVRs (Lightweight USB Framework for AVRs) that is a project that can support USB in host/device mode for lots of different USB classes like HID, CDC, Audio, Mass Storage, Printers, Ethernet etc:
http://www.fourwalledcubicle.com/LUFA.php
Maybe something can be learned by that too to see how work can be separated between core HW USB transfer functionality with data pipes/endpoints etc and the USB class driver functionality.