https://pub.pages.cba.mit.edu/ring/
On Thu, Apr 22, 2021 at 11:02 AM Gerhard Hoffmann < g...@hoffmann-hochfrequenz.de> wrote: > I think I can read in about 3 pcs. LT2500-32 via the PRU in Software. > > The LT2500 ADC delivers 32 bit results via SPI, and with the capture and > > conversion time slots it needs 100 MHz SPI to process each 1MHz sample. > > The ADC feeds its data to a shift register in a Xilinx 2c64 Coolrunner. > > The PRU then reads it bytewise and writes the collected 32 bit words > > into a ring buffer in the shared RAM. > > Up to now I have tested 1 ADC, but bandwidth should be enough for 3, > > just so. > > regards, Gerhard > > > > Am 22.04.21 um 15:53 schrieb rpaulb...@gmail.com: > > 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:* beagleboard@googlegroups.com <beagleboard@googlegroups.com> > <beagleboard@googlegroups.com> *On Behalf Of *Andrew P. Lentvorski > *Sent:* Thursday, April 22, 2021 5:01 AM > *To:* BeagleBoard <beagleboard@googlegroups.com> > <beagleboard@googlegroups.com> > *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 rpau...@gmail.com > 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 > beagleboard+unsubscr...@googlegroups.com. > 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 beagleboard+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/02f301d7377e%24d9e9e3b0%248dbdab10%24%40gmail.com > <https://groups.google.com/d/msgid/beagleboard/02f301d7377e%24d9e9e3b0%248dbdab10%24%40gmail.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 beagleboard+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/78b77aa0-0115-7281-8319-78e14b26a6ce%40hoffmann-hochfrequenz.de > <https://groups.google.com/d/msgid/beagleboard/78b77aa0-0115-7281-8319-78e14b26a6ce%40hoffmann-hochfrequenz.de?utm_medium=email&utm_source=footer> > . > -- https://beagleboard.org/about/jkridner - a 501c3 non-profit educating around open hardware computing -- 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPnJ6t95RKme%2Bn99fz7MqyavW4EaLFrzYZuA9EjzYyYO8Q%40mail.gmail.com.
