Hi Gerhard,
Thank you very much for your answer.
In fact, I did not have the CS and Clock pins defined as "define", I made
the program a way faster.
Another tip that improved the program's performance a lot is to access the
storage array through a pointer, rather than a direct indexation, like the
following: *(buffer_shared + count) = var.
About your advice of not processing the data as it is being received, I
don't think that's possible. The reason is that I want to catch 98 bytes *
102 bytes = 79.184 bits (which corresponds to an image of CMOS sensor). I
don't have enough memory space to save those bits without doing the shift
processing inside the function ...
Here's the code where I got the better results:
while(__R31&cs); // CS = 1
while(__R31&sclk){ //sclk = 1
if(__R31&cs){
goto END;}
}
while(!(__R31&sclk)); //SCLK = 0
var = (__R31&miso)? var |(0x01 << shift): var;
k++;
shift--;
if(shift == -1){
*(buffer_shared + cnt) = var;
cnt++;
shift=31;
var = 0;
}
END:
*(buffer_shared+2600) = k; // Here I am storing the value of the counter,
to check if all the clocks wre catched.
I have only one small problem though, the sensor is sending data every
time, and sometimes it catches more than one frame. I don't
understand quite well why is it happening since the time between frames is
about 10 ms, and in that why it is difficult to have sure that I haven't
miss clocks in the frame. So, to have sure I am not missing clocks I add
the following line:
LABEL:
if(k==79184)
goto END;
And I noticed that sometimes I miss one clock (although here I am
introducing one extra instruction, which will make the program a bit slow).
If you have any suggestion I should implement to tackle this problem,
please let me know ...
Thank you very much for your help.
-- Fred Gomes
Gerhard Hoffmann <[email protected]> escreveu no dia quarta,
5/12/2018 à(s) 03:15:
>
> Am 04.12.18 um 10:25 schrieb [email protected]:
>
> 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
>
>
> Why not simply
>
> #define CS 15 /* whatever */
>
> while(__R31 & CS) {};
>
>
> I hope that cs is a #defined macro and not a variable;
>
> In C there is the convention that macros are written in upper case,
>
> as a warning that there may be more action inside than meets the eye.
>
> And macros should employ parentheses generously to avoid bugs like this:
>
> #define A 2 + 3
>
> if (5 * A) ..... which results in
>
> if (5 * 2 + 3) , which is probably not what was intended.
>
>
> Note that EVERY computation result can be used as a boolean.
>
> 0 is false, EVERYTHING else is true, so your compares to
>
> generate a boolean are just a non-wanted complication.
>
>
>
> while((__R31&sclk) == sclk);
> while((__R31&sclk) == sclk){ //sclk = 1
>
> if((__R31&cs) == cs)
> goto END;
>
> I don't know where END is, but gotos are known to not work well
>
> with optimizing compilers since the the compiler may have to
>
> throw assumptions overboard that are not safe any more since the
>
> goto is non-local.
>
> buffer[cnt] = ((__R31&miso) == miso)? buffer[cnt] | 0x01 << shift:
> buffer[cnt]; // Here is where my cycle is being stranded!!!
>
>
> The conditional assignment makes the program read back buffer[cnt]. That
> is bad
>
> in concept since the buffer may be in shared ram and reading that may cost
> many clocks
>
> for arbitration. Writing the shared RAM may be a little bit cheaper since
> the bus logic
>
> might buffer the write and let the PRU run on.
>
>
> Thinking about it, even the PRU local data RAM is somehow shared since the
>
> ARM CPU and the other PRU can read & write it; let's hope that the
> priorities are set
>
> in a sensible way.
>
>
> Also the address of buffer[cnt] is computed 3 times in this line.
>
> The compiler might spot that it has the values already. But you could kick
> it into the
>
> right direction:
>
>
> register int tmp; // I have no idea if the TI compiler honors that.
> It is just a hint.
>
> int *bufferp = KJHGKJHJHM;
>
>
> tmp = __R31 & MISO; // the & result is already usable as a boolean
>
> if (tmp) tmp = tmp | (1 << shift); // that feels somehow wrong since the
> original bit is kept.
>
> *bufferp++ = tmp;
>
>
> You might also leave that shifting to the ARM CPU; it probably can be done
>
> when the data is further proccessed.
>
>
> regards,
>
> Gerhard
>
> --
> 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
> [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/6f91ab43-b393-277c-43a2-7f201005e65a%40hoffmann-hochfrequenz.de
> <https://groups.google.com/d/msgid/beagleboard/6f91ab43-b393-277c-43a2-7f201005e65a%40hoffmann-hochfrequenz.de?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/CAJHs20wF-9xPUj%2BcV5ssSJfOVgfdt2BbJvZReu9weCJb11eV_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
