You were already added to the repo, I forgot to tell you that 
I created a new ps2_usb_sniffer branch and will pull your code into that branch when the merge checks finish.
2 Likes
I can't wait to be able to use the USB sniff capability.
I’ve got an RP2040 based device (Adafruit Macropad), emulating an absolute-positioning mouse, and it works great on my PC. It also was working great on my iPad.
Then, it just started to hang early in script execution when connected to the iPAD. Debugging is … non-trivial … as the device is actually running CircuitPython.
It’s the oddest thing. The screen stays on, but it’s almost like the iPAD sent some deformed USB request that results in crashing the device.
Re-connect to the PC and it’s fine. iPAD doesn’t show the device as connected at all … so now I’m left wondering if the iPAD is doing something sketchy (or “smart” … just without explaining).
Really want to see the USB packets (in something that decodes them, of course).
3 Likes
Just got my plank today (along with some other stuff I ordered).
Didn’t have much time with it, but did update my BP to the USB sniffer branch. Hooked up a device and was able to capture some packets, but with errors. Didn’t look into it, maybe tomorrow or Friday.
I have an HID device I built a few years ago, so I can use that as my test device.
2 Likes
In my case, I’m seeing some really odd behavior where the first time I perform drag operations (using a virtual, absolute positioning mouse), the app doesn’t scroll quite as far as it does on subsequent movements.
messy details
At this point, I’m guessing that iOS is applying acceleration to absolute mouse inputs. There’s no setting available to disable this on iOS that I can find (in fact, iOS seems to have a love/hate relationship with mouse devices … only allowed via accessibility settings).
In order to test my theory about acceleration, I need to check if the timing of those movement reports is the same. I’m now guessing that CircuitPython compiles on-demand, and then caches some amount in RAM, resulting in “faster” execution on subsequent calls. At least, I hope so … because I can work around that.
3 Likes
Sigh. I have to hold my tongue to keep from going on a “who thought an interpreted language on a microcontroller is a good idea” rant.
I hope the plank helps to solve that issue 
2 Likes
I don’t have the PLANK yet, when the shipment arrives at my home and I test it, I’ll let you know.
2 Likes
I made a DIY pico-crap-board for pico-usb-sniffer-lite (Also with a trigger pin 
)
That way I can more easily tell if a bug comes from the BP port or from pico-usb-sniffer-lite project
It’s also fully compatible with my mod of Alex Taradov’s bare-metal project:
Possible bugs sources:
- I messed something up when porting from my pico-usb-sniffer-lite to the BP project
- I messed something up when porting from bare-metal to PICO SDK
- It’s a bug from the original bare-metal project by Alex
1 Like
PICO VS BARE (low speed keyboard USB → Caps Lock)
BPV6 (low speed keyboard USB → Caps Lock)
Behavior seems identical on PICO, BARE, and BPV6 (in this case), so I’ll always test that Multi-Behavior-test first
There’s something weird though (DIY USB PLANK) … ONLY in the BP firmware it seems like doesn’t start capturing USB traffic at the right moment? (or wtf?) … BUT if I repeat the test it sometimes works fine, I need to look into it…
Hopefully the PLANK arrives soon so I can run more tests…
3 Likes
What triggers start of USB capture? Is it all in PIO? Does the PIO use interrupts or any pins to signal between state machines?
PIO1 is completely full (all instructions) with the USB capture logic (which is actually useful because we get a sort of trick-wrap-thing haha)
But for PIO1 to do its job correctly, there’s a program running on PIO0 that makes sure it waits for the right moment to start capturing
When the right moment comes, a GPIO is used to signal from PIO0, and PIO1 detects that pin change and starts working
1 Like
Be sure the IO buffer is set for output and input correctly for the signalling pins.
I tested that part and the signaling works fine (I added IRQs on both PIO0 and PIO1 to be sure… and everything seemed “okay”), I’ve got a couple of theories… but I need to test them first
1 Like
I notice you don’t have anything hooked into the periodic service loop for the modes. Is it interrupt based?
When the sniff command is executed (both for PS2 and USB), it runs as a standalone application, calling the necessary BP APIs and that’s it. I’ve made it as simple as possible.
When I implement more features in future PRs—like the PS2 Host and similar things—I’ll start handling those details, but for sniffing, I think this is the best approach for now. Do you see any problem I might be overlooking?
1 Like
When I was playing with it the other day, I found no way to end a capture early. I was going to look into adding functionality to use the button to abort a capture.
2 Likes
Good idea, Feel free to make a PR to my PR if you want
2 Likes
I’m heading out on a couple week holiday; I can do it when I get back
2 Likes
I’ve got the plank now!
- USB Low Speed Keyboard works—both sniffing and typing on the PC
- PS2 Keyboard also works—both sniffing and typing on the PC
So my DIY plank and the official one made by @ian both work and are equivalent. Now it’s just a matter of fine-tuning the firmware.
I also tested the trigger and slide switch and it works correctly. As far as I’m concerned, the PLANK is well designed — PASS!
3 Likes
Glad it arrived! Still waiting on mine. Keep us updated!
3 Likes
I also tested two cables: USB-C to USB-C → PC and USB-C to USB-A → PC, and everything works fine.
@ian, The only thing I’d do before releasing it publicly is to add two pins next to each other: one for VBUS/PS2VCC and one for GND. That way, if someone wants to supply extra power with an external PSU (via dupont cables) or when we start doing HOST-type things, it would be easy. I don’t think it would cost much to add two pins, and it’s simple—what do you think?
3 Likes