Try writing in assembly, or at least providing a listing of the PRU
code your compiler is generating.  The C code you've written could
turn into very ugly assembly with a lot of memory reads (which are
*VERY* expensive on the PRU) depending on the compiler.

In general, for speed you only want the PRU to write to your buffer[]
memory region, you should never read from it.  So use a local variable
to build a 32-bit word and then write that into the buffer[] memory
instead of bit-wise oring the data piece-meal into your buffer[].

If you need to maintain a rate of 10 MHz, you only have 20 assembly
instructions per bit, which isn't many when you're trying to code in C.

On 12/4/2018 3:30 AM, Fred Gomes wrote:
> I've forgotten to mention. I am sending the clocks from the PRU 1 to PRU 0
> at this time. So I know exactly how many clocks there is and the frequency.
> The objective is to plug the sensor which I want to read the data after
> having this working .
> 
> -- Fred Gomes
> 
> 
> <fred.p.gome...@gmail.com> escreveu no dia terça, 4/12/2018 à(s) 09:25:
> 
>> Hi, I need your help,
>>
>> I need to read data of an SPI Master device on the BeagleBone. Since the
>> SPI kernel driver doesn't support an SPI slave mode I have to implement it
>> in the PRU (Because the maximum frequency one BeagleBone's GPIO can be
>> toggle is only 15 KHz).
>> From what I have read, the PRU cycle time is 200 MHz, even so, I can't
>> read data up to 10 MHz. I am doing the following:
>>
>>
>>
>>                          k=0;
>> shift = 0;
>>
>> while((__R31&cs) != cs){ // CS = 0
>> while((__R31&sclk) == sclk);
>> while((__R31&sclk) == sclk){ //sclk = 1
>>
>> if((__R31&cs) == cs)
>> goto END;
>> }
>> while((__R31&sclk) != sclk); //SCLK = 0
>> buffer[cnt] = ((__R31&miso) == miso)?  buffer[cnt] | 0x01 << shift:
>> buffer[cnt]; // Here is where my cycle is being stranded!!!
>> k++;
>> shift = (shift==32)? 0 : shift + 1;
>> cnt = ((k%32)==0)? cnt+1 : cnt;
>>
>> If I comment on the reading line, I can't catch clocks at 20 MHz. However,
>> if a uncomment it I only can get all of them at 9 MHz (I need 10 MHz). My
>> question is if it is possible to get it a bit faster. I can't understand
>> why it is so slow (given that the PRU is a real-time processor  and has
>> a high speed between instructions).
>>
>> Regards,
>> -- Fred Gomes
>>
>> --
>> 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/Vtw23FneFLk/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/d8ea84f9-cb22-47bd-89ac-328214ded03e%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/d8ea84f9-cb22-47bd-89ac-328214ded03e%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> 


-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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/15bfe150-751b-17a2-da72-2a7ea91d0929%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Reply via email to