Improving sample rate for a specific protocol.

[hanetzer]

So, I want to monitor LPC (33.3Mhz, 6 signals [lframe, lclock, and lad0-3]) on a machine. My understanding is the PRUs can sample at 200Mhz, but that depends on the overhead of the code itself. Is it possible to improve the rate by cutting down on what it can do, in effect becoming overspecialized to one task?

[hanetzer]

Or, barring that, can you sync a pru clock with an external clock input? That way I don't have to oversample
in theory.

[abhishek-kakkar]

Yes, the PRU does support synchronising to external clock, so it is possible in theory but I haven't written firmware to try this even though there have been requests to do so.

The architecture of the PRU firmware is such that one PRU samples (PRU1) and the other PRU (PRU0) writes to memory, so you can alter PRU1 firmware and customise it for your scenario. It will stream bytes to PRU0 which ultimately the kernel driver will pick up.

Feel free to play with PRU1 firmware and customise it if you can and ask for help here. It will be a bit of time before I can get to the task personally but I will be happy to help.

[hanetzer]

Thanks for the info. Atm I'm tinkering with the pi pico's pio (yeah I know its usb can't spit fast enough for a byte every 33.3mhz clock so I'm thinking to implement some lpc parsing in the fw and only spit stuff out that actually 'happens')
to get actual lpc action but if I could get the prus to do it I'd be able to capture more cleanly.