I got it working, and I hope to never revisit it. It was kind of a surprise. I selected a 1MS/s 16-bit SPI ADC and assumed a 16 Mhz SPI clock to get the data out. I totally missed that the ADC can’t sample, convert, and send at the same time, so I basically have 300nS to get my 16 bit out. Everything else I had done with the PRU monitored and responded to an external clock, so this is the first time I was generating the clock and sampling the incoming data. I had noticed a previous oddity where I had some debugging statements (set an output pin) and when I removed them things stopped working. There is definitely a speed limit.
From: [email protected] <[email protected]> On Behalf Of Andrew P. Lentvorski Sent: Thursday, April 22, 2021 5:01 AM To: BeagleBoard <[email protected]> Subject: [beagleboard] Re: PRU I/O max speed I would be stunned if the GPIOs don't have synchronizer flip-flops as they are sampling a signal asynchronous to the 200MHz clock. That would account for 2 clocks. You probably need one extra to clock data into R31. And then one clock to read R31. 50MHz is a pretty smoking speed for SPI--you normally need to start thinking about series termination and some basic signal integrity. You normally need the clock to capture to flop directly if you want things to work. I suspect you probably need to use the 16-bit Parallel Capture Mode while feeding your clock out back as clock in. You'll still probably be 4 clocks behind when the data hits R31, but the data will get *captured* by the PRU<n>_CLOCKIN edge properly so the delay will now be deterministic if you are generating the 50MHz clock yourself. On Thursday, February 25, 2021 at 12:15:18 PM UTC-8 [email protected] <mailto:[email protected]> wrote: With a sample size of one, r31 appears to be 4 instructions behind the state of the pin. On Thursday, February 25, 2021 at 12:26:16 PM UTC-5 Paul Beam wrote: I am, unfortunately, bit-banging SPI with the PRU, and I seem to be running into a speed limit < 50 MHz I desire. I can certainly create a clock that fast, but reading data seems to be delayed. I can see on the logic analyzer a "0" clearly being read as a '1" so there is either a delay in my clock output or a delay in my input or both. I would like to think that r30 and r31 are tied directly to the outside world, but now I am thinking there is something in between that is either clocked or just has significant output delays. Anyone else encountered this? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/9GdOGgGv-eY/unsubscribe. To unsubscribe from this group and all its topics, send an email to [email protected] <mailto:[email protected]> . To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/f88c700e-69c2-4ac4-bc64-d44a1715460dn%40googlegroups.com <https://groups.google.com/d/msgid/beagleboard/f88c700e-69c2-4ac4-bc64-d44a1715460dn%40googlegroups.com?utm_medium=email&utm_source=footer> . -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/02f301d7377e%24d9e9e3b0%248dbdab10%24%40gmail.com.
