This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM4376: QSPI implementation on PRU

Part Number: AM4376
Other Parts Discussed in Thread: TIDA-01555

Hi team,

Are we able to implement a master 4/8 bit QSPI on the PRU-ICSS? What would be the QSPI clock speed?

I managed to find the following TI Design showing our PRU-ICSS as a SPI master: http://www.ti.com/tool/TIDEP0033 Do we have something for QSPI?

Regards,

Akash Patel

  • The PRU experts have been notified. They will respond here.
  • Hello Akash, 

    I am not aware of any documentation related to implementing QSPI on the PRU-ICSS. It might be possible - however, the implementation and clock speed would be highly dependent on the use case. The PRU training on Designing a PRU Application may be helpful in outlining the process to determine feasibility. 

    Regards, 

    Nick

  • Here is another SPI design which may be closer to a QSPI use case: TIDA-01555 (6 SPIs in parallel with shared chip select and shared clock)

    design
    www.ti.com/.../TIDA-01555

    PRU code
    git.ti.com/.../PRU_ADS8688_Interface.asm .

    The Design Guide has good information in it
  • Hi Nick,

    Can you help me understand how to calculate the Maximum Clock Speeds for the different number of ADCs? For example, why is the maximum clock speed 14.29 MHz for 4 ADCs?

    This is from Table 2 (p. 9) in the TI Design Guide you just referenced: www.ti.com/.../tidudn4.pdf

    Regards,
    Akash Patel
  • Hello Akash,

    To all readers, please note that this walkthrough is purely an example. The customer is in charge of designing their own implementations. TI will neither design custom use cases nor write custom code.  

    The PRU clock is 200MHz, so a 10MHz SPI clock requires 20 PRU clocks per SPI clock, an 11.11MHz SPI clock requires 18 PRU clocks per SPI clock, etc. The code was written for a 10MHz SPI clock. If fewer SPIs were used, each config_cycle/read_cycle would call config_bit fewer times, which would enable fewer PRU clock cycles and faster SPI clocks.

    The SPI implementation designers decided to dedicate one PRU to controlling the interface. They decided that they wanted to "pack" and "unpack" the SPI values in that PRU rather than doing the processing elsewhere - the packing/unpacking is done in config_cycle/read_cycle. Other considerations: the high/low pulsewidths of the SPI clocks needed to be symmetric, they wanted the number of cycles used to read to match the number of cycles used to write.

    I've added comments to snippets of the system designers' PRU code below to explain the timing.

            config_cycle 15  ; send 16 config bits serially on each SPI (eacg config_cycle sends one bit)
     	config_cycle 14  ; one bit per SPI clk cycle
     	config_cycle 13  ; so 1 config_cycle = 20 PRU clks
     	config_cycle 12 
     	config_cycle 11 
     	config_cycle 10 
     	config_cycle 9 
     	config_cycle 8 
     	config_cycle 7 
     	config_cycle 6 
     	config_cycle 5 
     	config_cycle 4 
     	config_cycle 3 
     	config_cycle 2 
     	config_cycle 1 
     	config_cycle 0 
     	nop ; each nop takes 1 PRU clk
     	nop 
     	nop 
     	nop 
     	nop 
     	nop 
     	nop 
     	nop 
     	nop 
     	clock_high ; this takes 1 PRU clk
     	nop 
     	nop 
     	nop 
     	nop 
     	nop 
     	nop 
     	nop 
     	nop ; we'll call this PRU clk 18 of a 20 clk cycle
     	; Read the data from the ADCs and place it into the result registers one cycle at a time 
     	read_cycle 15 ; read 16 bits from each SPI
     	read_cycle 14 ; 1 read_cycle = 20 PRU clks
     	read_cycle 13 
     	read_cycle 12 
     	read_cycle 11 
     	read_cycle 10 
     	read_cycle 9 
     	read_cycle 8 
     	read_cycle 7 
     	read_cycle 6 
     	read_cycle 5 
     	read_cycle 4 
     	read_cycle 3 
     	read_cycle 2 
     	read_cycle 1 
     	read_cycle 0 
    
    config_cycle	.macro bit  
     	mov	r8, r9 ; 1 PRU clk
     	config_bit adc1_config_reg, bit, mosi1_pin ; 2 PRU clks 
     	config_bit adc2_config_reg, bit, mosi2_pin 
     	config_bit adc3_config_reg, bit, mosi3_pin 
     	config_bit adc4_config_reg, bit, mosi4_pin 
     	clock_high ; this is the 10th PRU clk
     	config_bit adc5_config_reg, bit, mosi5_pin 
     	config_bit adc6_config_reg, bit, mosi6_pin 
     	mov	r30, r8 ; 1 PRU clk
     	nop ; these top two NOPs could be removed to get 18 PRU clks = 11.11 MHz SPI clk
     	nop ; see above
     	nop
     	nop ; SPI requires at least 1 NOP before toggle clk low to satisfy setup
     	clock_low ; this is the 20th PRU clk in the config_cycle
     		.endm 
    
    read_cycle	.macro bit  
     	mov r11, r31 ; 1 PRU clk (clk 19 of 20)
     	clock_low ; 1 PRU clk (CLK 20 of 20)
     	read_bit adc1_result_reg, bit, miso1_pin ; 2 PRU clks (clk 1 of 20)
     	read_bit adc2_result_reg, bit, miso2_pin 
     	read_bit adc3_result_reg, bit, miso3_pin 
     	read_bit adc4_result_reg, bit, miso4_pin 
     	nop 
     	clock_high ;(PRU clk 10 of 20)
     	read_bit adc5_result_reg, bit, miso5_pin 
     	read_bit adc6_result_reg, bit, miso6_pin 
     	nop ; these two NOPs could be removed to get 18 PRU clks/cycle = 11.11 MHz
     	nop ; see above
     	nop 
     	nop ;(PRU clk 18 of 20)
     		.endm 

    Different code implementations may yield different max clock rates.

    Regards,

    Nick