PRU I/O max speed

[Paul Beam]

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?  

[Paul Beam]

With a sample size of one, r31 appears to be 4 instructions behind the state of the pin.

[Andrew P. Lentvorski]

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.

[rpau...@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.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/f88c700e-69c2-4ac4-bc64-d44a1715460dn%40googlegroups.com.

[Gerhard Hoffmann]

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 rpau...@gmail.com:

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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/02f301d7377e%24d9e9e3b0%248dbdab10%24%40gmail.com.

[Jason Kridner]

https://pub.pages.cba.mit.edu/ring/

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/78b77aa0-0115-7281-8319-78e14b26a6ce%40hoffmann-hochfrequenz.de.

--

https://beagleboard.org/about/jkridner - a 501c3 non-profit educating around open hardware computing

[Gerhard Hoffmann]

It was really a ping-pong buffer, not a ring.

I did check the timing with an Agilent 54846B scope.

this is snipped from a backup copy, I have re-purposed the BBB

I did comment about this here already a year ago or so.

My memory about that gets fuzzy...

volatile register unsigned int __R30;        // CPU register R30 connects directly to some output pins
volatile register unsigned int __R31;        // CPU register R31 connects directly to some input pins

#define SELECT     8   /* 2 BITS addressing of the 4 bytes in CPLD  Bit8 = P8.27 und Bit9=p8.29 */
#define PROG_CLK  10   /* P8.28  prog_dat green wire to SDI of ADC*/
#define PROG_DAT  11   /* that works unexpectedly. probably the BBB handbook is wrong/incomplete. */
                       /* should be possible according to CPU data sheet. */
#define DAT_AVAIL 16   /* Pin P9.26, the only PRU1 pin on P9  input  busy oŕ drl, depending on output used */

// GPIO, Clearing or setting takes about 40 nsec
#define PROG_ENA   (1<<2)
#define USE_CHAN_B (1<<4)


// variables in main end up on the stack. We only have 0x100 bytes by default.
// global variables are on the heap. Stack and heap are on the bottom of the PRU data RAM.

volatile int      heapmarker = 0x22222222;  // Easy to find in a memory dump
volatile char     *bla = "HEAP @ @ @ ";
int             i;
volatile int     *pipo_pointer;
int             pipo_offset;



// data avail is either not busy or not drl. It is high active.
// When the ADC is busy, it is low for 600 nsec.
// The CPLD then takes a little more than 32 Clocks
// to get the 32 bits. Then we can read them out, bytewise.
// It is probably harmless if that extends slightly into the next
// conversion since the read activity is decoupled from the ADC core.
// inline saves 20 nsec.

inline void wait_data_avail(void){

    while  (  __R31 & (1 << DAT_AVAIL)) {};    // wait for the high time of p9.26 = data_avail
    while  (!(__R31 & (1 << DAT_AVAIL))){};    // wait for the low time

    //  now the ADC transaction window opens.
    // next 320 ns we will read the data into the CPLD or program the ADC
}

// read 4 bytes from the CPLD, mask them, shift them & convert to one int.
// I must read at least 3 times that the results are right ( for address setup time)
// removing a single read makes it 60 nsec faster, 15 nsec per read. Should be 5 nsec???
// reading 3 times takes 40 nsec per bit. That should be enough.
// reading 4 times takes 60 nsec per bit. Reading __R31 takes abt. 20 ns. :-(
// Von der steigenden Flanke von data_available am P9 bis zum return dauert 725 nsec.
    // kill 320 nsec, the time the CPLD needs to fill the shift register
    // das sind 340 nsec für 5 Schleifendurchläufe. LAHM??
    // 1 = 42 ns  2 = genauso??  11 = 104 ns  31 = 208 ns 51 = 304 ns
    // 61 = 355 nsec   60 = 350 ns

    // Once through the empty loop costs 5 nsec.
    // for( retval=60; retval;  retval--){};       

// D.h. es bleiben 250 nsec zum ABspeichern im pingpong-Buffer. Das CPLD könnte sagen,
// wann die Daten für den BBB fertig sind. Dann hätte man 350 nsec mehr Zeit für sonst was.
// Das ist jetzt gemacht. Data_rdy_bb geht jetzt 330 nsec low, solange das CPLD den ADC auslutscht.
// Wenn data_rdy_bbb hochgeht, können wir gleich anfangen, das CPLD leerzunuckeln.
// Genug Zeit für noch 2 Kanäle.


inline int read_adc(void){

    int retval;

    // Without volatile it runs 3 times as fast, even though __R31 is volatile
    volatile unsigned int byte0, byte1, byte2, byte3;

    wait_data_avail();


//    __R30   &= ~(3 << SELECT);    // address 0  Trigger
//    __R30   |=  (3 << SELECT);    // address 3

    // from here to parking address wires  at return it takes 350 nsec.

    __R30   &= ~(3 << SELECT);    // address 0
    byte0    = __R31;            // address setup time for byte 0
    byte0    = __R31;        // 5 nsec each line
//    byte0    = __R31;
    byte0    = __R31;

    __R30   |= (1 << SELECT);    // address 1
    byte1    = __R31;
    byte1    = __R31;
//    byte1    = __R31;
    byte1    = __R31;

    __R30   &= ~(3 << SELECT);    // address 2,   remove old bit field
    __R30   |=  (2 << SELECT);    // insert new bit field
    byte2   = __R31;
    byte2   = __R31;
//    byte2   = __R31;
    byte2   = __R31;

    __R30   |= (1<< SELECT);    // increment to address 3
    byte3   = __R31;            //
    byte3   = __R31;
//    byte3   = __R31;
    byte3   = __R31;            // get the last byte



    retval  = ((byte0 & 0xff)      )
            | ((byte1 & 0xff) << 8 )
            | ((byte2 & 0xff) << 16)
            | ((byte3 & 0xff) << 24);

    __R30   &= ~(3 << SELECT);    // park address at 0, may be removed.

    return  retval;
}

-----------------------

Am 24.04.21 um 08:16 schrieb Jason Kridner: