Hi Charles, thank you very much for your answer, I followed your advice but something overly odd is happening.
First of all, let me contextualize you: the image sensor is always sending data through the CS, SCLK, and MOSI pins. The delay between each frame is about 10 ms. That said, I wrote the code in attachment "prog_pru_v1". In the first stage, I test it using the another PRU from beagle bone. So, I send some clocks from PRU 1 and count them on the PRU1; here I checked that the PRU can get all the pulses up to a frequency clock of 20 MHz (I only need 10 MHz). The problem comes when I shortened the delay time between frames, it stops catching all the clocks (in fact, it catches very few clocks) and I don't understand the reason since it should be in a loop (between the variation edges from the CS pin. The other problem I did (prog_pru_v2.c) seems to work a bit better. It sometimes catches all the clocks from the sensor and fails another times. Surprisingly, the assembly code seems to be much uncluttered on this code. I can't understand why is this happening, it doesn't seem to have much sense. I validate the code successfully, but the problem comes when I start sending much data spaced about 10 ms! Find attached the code programs mentioned above, both the .c code and assembly. Let me know if you have any other suggestion I should test, Bets regards, -- Fred Gomes Charles Steinkuehler <[email protected]> escreveu no dia sexta, 7/12/2018 à(s) 13:47: > On 12/7/2018 3:52 AM, Fred Gomes wrote: > > > > 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 ... > > Again, please either write in assembly or post the assembly listing > the compiler is generating. You have 12 lines of C code above, and > that doesn't even look like the entire loop (just the inner loop for > one 32-bit word). As mentioned previously, you have time for about 20 > PRU assembly instructions, which isn't many for 12 lines of C. > > Without the full code and seeing the assembly your compiler is > generating, I can only make a few suggestions. An optimizing compiler > would probably do much of this for you, but it doesn't sound like your > compiler is doing much optimization (again, let's see some listing > files!): > > * Get rid of the count variable and create a dedicated buffer pointer, > then increment that, ie: > > *(buffer_shared + cnt) = var; > cnt++; > > ...turns into: > > // Initial setup > uint32_t *buffer_ptr = buffer_shared > > // ...other code goes here... > > *(buffer_ptr) = var; > buffer_ptr++; > > * Review the generated code for the var update. The PRU has lots of > bit test and shift instructions, so changing this calculation slightly > could reduce the number of instructions needed. If I was writing in > assembly I would shift var first then conditionally or in a '1' > depending on the state of the input pin. In C it would look like this > (but I don't know if this will generate the actual assembly I'm > thinking of, it depends on your compiler): > > var >>= 1; > if (__R31&miso) var |= 0x8000; > > * Review the code generated for the various bit test instructions (eg: > __R31 & <val>). These should be a single bit test instruction in PRU > assembly, but that may not be what the compiler is generating. > > There are other "tricks" you can try (eg: get rid of the shift count > and use a bit in var instead). Without being able to see the > generated assembly you can easily wind up making things much worse, > but you can try it if you like. Make sure to initialize var to 0x8000 > and set the buffer_ptr value in your setup code: > > while(!(__R31&sclk)); //SCLK = 0 > > k++; // I assume this is needed outside the loop > > // 1 in the LSB means this is the last bit of our 32-bit word > if (var & 0x01) > { > // Shift in the last bit > var >>= 1; > if (__R31&miso) var |= 0x8000; > > // Store the value > *(buffer_ptr) = var; > > // Setup for the next word > buffer_ptr++; > var = 0x8000; > } else { > // Shift in the next bit > var >>= 1; > if (__R31&miso) var |= 0x8000; > } > > -- > Charles Steinkuehler > [email protected] > > -- > 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/95d14956-6dad-f1c4-fe34-7074cb4e926d%40steinkuehler.net > . > 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/CAJHs20z_yfufDZ227vseD4zzUiE0kUAVBG0KBJcP6UnxgGYR1A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
BBB.rar
Description: Binary data
