Hi, thank you, but I don't want to steal credit for PicoModem, which is a different project that passes modem AT commands over Wi-Fi https://github.com/mecparts/PicoWiFiModem
I was not familiar with the Oric, but while it does look like the LOCI does support cdc_ncm, I am not sure that the pico-usb-wifi is the right firmware for it. The pico-usb-wifi is more aimed at any computer with a USB port, so anything from ~1995-onwards with a USB and IP networking stack - if it runs Linux and has cdc_ncm and cdc_acm - there's a good chance it'll work. Earlier systems might be feasible with PCI/ISA USB cards.
cdc_ncm is really helpful for early 2000s systems and locked-down embedded systems. For example, I've been hacking the Spotify Car Thing, which only has USB device mode. After switching it into host mode, there's no 'way in', so any change required re-flashing the firmware over-and-over. Once I had cdc_ncm set up and attached the pico-usb-wifi, I could telnet in and develop, of course a USB UART likely could have established the same thing.
I’m glad it got reposted because I just tried it out.
What a smooth experience!
I managed to get an old desktop - with no wifi and far from n ethernet port - connected by this gadget!
Great job in getting this to work, creating a nice user interface and releasing it!
Author here: I have wanted to make a wireless USB mouse and keyboard switch out of RPI Pico Ws for a long time. I would go a layer deeper than USB/IP, because I want to cache the USB handshake to keep the connection enumerated on multiple systems without dropping.
Author here: good point - I do hope the retro computing community enjoys this tool. It does remind me of the Espressif line if ESP8266 and ESP32 devices which have Wi-Fi devices which are available on UART and respond to AT modem commands. Pico-usb-wifi is a nice tool which some clever YouTubers will hopefully be able to use to get old internet appliances, or systems that didn't have Wi-Fi, online.
Personally, I rescued a dozen PogoPlugs from the trash a decade ago and used one to practice self hosting a word press instance. Having a dongle like this would have allowed me to stick it in a corner and run something like librespot or snapcast. Instead, I eventually sent them to the recycler when I moved.
Author here: thank you for this deep dive. I saw peaks of 5.9 Mbps, it might be possible to increase throughput by allocating more memory. The link between the rp2040 and Infineon Wi-Fi device is 31.5 Mb/s. It might be possible to push that out over PIO to an external USB 2.0 PHY. Apparently the Wi-Fi device is capable of higher speeds. Who knows what will be the limiting factor. I'll leave it to someone else to experiment, my focus was the stock hardware without any modifications.
> It might be possible to push that out over PIO to an external USB 2.0 PHY.
I doubt you will be able to achieve USB HS via a ULPI PHY without an FPGA tunneling the USB SIE for you and handling the tight turnaround requirement (in which case, you might as well give it the entire MAC workload or just use an MCU with an integrated HS PHY.)
The ULPI clock is a 60MHz free-running PHY-sourced signal (typically - some PHYs allow MAC-sourced clocks and this would likely be a little easier), the PHY is entirely in control of when the MAC can transmit (DIR pin), and the protocol is unforgiving from a timing standpoint.
Author here: Thank you, this is one of the nicest things anyone has ever said about my work.
I achieved two goals today: a front page post on hackernews and for being recognized for my work; or more accurately, for being very good at using AI ;)
Author here: I will consider writing a blog about ir, but it will require a lot of work on my part, because as I mentioned, this was a digression/side quest from the main task of hacking my Spotify Car Thing. It might work better as a YouTube video.
Author here: Thank you! It's a nice thought that something I made will become a trusted tool for IT professionals.
Now I need to make a nice 3D-printed case.
I admit, I almost couldn't believe it when I turned off my regular blazing fast 802.11ax NIC in the KDE network manager and switched to the pico-usb-wifi and I watched the YouTube "stats for nerds" buffer fully fill up and playback was totally smooth.
Author here: this is actually a "side quest" which I alluded to in the README.adoc and another comment. I've had a few Spotify Car Things (SuperBird) sitting on my desk that I have not touched in a year because I was waiting for the community to come out with a non-tethered approach to reclaiming them. All of the existing continue to either require a host PC, phone, or RPI Zero. I want to deploy these throughout my home and have them usable without my PC or phone nearby - likely with just a Home Assistant dashboard. I spent the first few hours cloning repositories of existing firmware, and examining other approaches, such as Bluetooth low energy with ESPHome Bluetooth proxies, but they ended up being dead ends. I took a compromise that a small wireless dongle would be acceptable. I then began examining the Linux source tree to see if it was possible to flip the USB from client to host and spent a considerable amount of time recompiling BishopDynamics' SuperBird NixOS distribution and building a test dashboard to show the IP networking information, because I knew that once I flipped the device's USB mode, I would lose access to the device. SuperBird took almost four hours to compile on my low end CPU - I let it compile while I hit my five hour Claude Code quota.
I also did not look forward to trying to build in wireless functionality in to NixOS, because it also took 30 minutes to flash the device - I had to lower the transfer block size and add more retries in the flash utility because it kept crashing.
ultimately both the SuperBird work and the RPI pico firmware was about 300 prompts of investigation, research, creating potential approaches, architecting, designing, debugging, testing/validating, and documenting.
Regarding your last two questions... I started out 25 years ago by studying for a CCNA in high school and joined the industry just as first generation 802.11ac devices began hitting the market. From my position, I've worked on every layer from the SoC, PCB, to software. I want to be very careful and say software estimation is very difficult. The main bug (issue #1) I encountered would have been very difficult to diagnose and resolve ten years ago using traditional development workflows.
I'm only starting out in embedded software domain, and the way you describe your 2 day side quest feels like Dumbledore showing some magic trick to Harry.
I was not familiar with the Oric, but while it does look like the LOCI does support cdc_ncm, I am not sure that the pico-usb-wifi is the right firmware for it. The pico-usb-wifi is more aimed at any computer with a USB port, so anything from ~1995-onwards with a USB and IP networking stack - if it runs Linux and has cdc_ncm and cdc_acm - there's a good chance it'll work. Earlier systems might be feasible with PCI/ISA USB cards.
cdc_ncm is really helpful for early 2000s systems and locked-down embedded systems. For example, I've been hacking the Spotify Car Thing, which only has USB device mode. After switching it into host mode, there's no 'way in', so any change required re-flashing the firmware over-and-over. Once I had cdc_ncm set up and attached the pico-usb-wifi, I could telnet in and develop, of course a USB UART likely could have established the same thing.