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.