Whew ! If you're looking for "fast", you're not going about it the right
way.
1) Nested loops are bad.
2) A file open, and close every cycle on the outer loop ? Is that really
necessary ? Big time performance hit.
3) spintf() as I recall is a fairly slow function.
A few things you can do to fix these issues.
Remove the nested loops and replace with a, if/else control block. Make the
conditions checks that are most likely to pass more often - first. Also,
simplify your math. If the numbers are going to be consistent, and non
changing. Hard code the values. Multiplication and division on fast moving
code will slow you down. Especially if done on floating point numbers. So
unless I missed an assignment somewhere . . .
*while(io->DRam[0] < (bStep+1) * bsSize && io->DRam[0] > bStep * bsSize)
{ ...}*
if bsStep which seems to be left unassigned ( 0 ) + 1 = 1
1 * <any value> is going to be that <any value> . . . Some compilers may
optimize this out, but why ? It also makes the code less readable.
Also . . .
*fwrite(io->Adc->Value, sizeof(uint16), 16000, oFile);*
Is a potential performance hit. Quite honestly I am not sure *if*
*sizeof(uint16)
*would be checked once at compile time, or if it would be checked every
cycle at run time. But you can "fix" this simply by hard coding the value.
Make it a constant if you feel it makes the code more readable.
Open the file once before the loop, and close it after the loop is done.
That is, if at all possible. Also there is a "trap for new players", in
that if the application exits abnormally, the file may still be left
opened. So a check when the application first starts may be in order.
As an aside, you can simplify the whole application by just gathering raw
data, and shifting it out to the the general purpose processor ( ARM ).
Which then the main processor can be made to do all the heavy math
"lifting".
Anyway I hope this is useful information, and my posting is not meant to
demean, or otherwise come across as "smart-ass".
On Thu, Nov 6, 2014 at 4:18 PM, <[email protected]> wrote:
> Hey TJF,
>
> I've got it compiled and working. I can't yet test if the adc keeps up
> since I the function generator we've ordered got out of stock.... However I
> changed my code a bit so it would close the files and the whole program has
> a end statement. It's currently 1 channel at ~220 kS/s. I haven't pushed it
> further because I don't know what will happen. With my understanding of the
> PRU I guess the PRU can't break anything on the BBB while doing that, but I
> don't know so I don't want to push my luck.
>
> #include "unistd.h"
> #include "stdio.h"
> #include "../c_wrapper/pruio.h"
>
>
> //! The main function.
> int main(int argc, char **argv)
> {
> FILE* oFile;
> uint8 bDiv = 4, bStep;
> uint32 bSize = 1e6;
> uint32 bsSize = bSize/bDiv;
> uint8 cycles = 2;
> char fName[12];
> int i = 0;
>
>
> pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 1); //! create new
> driver structure
> pruio_adc_setStep(io, 9, 4, 0, 0, 0); // step 9 for AIN-4
> if (pruio_config(io, bSize, 1 << 9, 4545, 0)){ // '1 << 9' -> step 9,
> '6285' ns -> 159.1 kHz
> printf("config failed (%s)\n", io->Errr);}
> else{
> pruio_rb_start(io);
> sleep(1);
> for(i=0; i<cycles; i++){
> sprintf(fName, "output.%u",i);
> oFile = fopen(fName,"wb");
> while(bStep<bDiv){
> while(io->DRam[0] < (bStep+1) * bsSize && io->DRam[0] > bStep *
> bsSize){
> sleep(1);
> }
> printf("writing samples %u-%u\n",bStep*bsSize, (bStep+1)*bsSize);
> fwrite(io->Adc->Value, sizeof(uint16), 16000, oFile);
> bStep++;
> }
> bStep=0;
> fclose(oFile);
> }
> }
> pruio_destroy(io);
> return 0;
> }
>
>
> Greetings,
> Nils Kohrs
>
> --
> 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].
> 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].
For more options, visit https://groups.google.com/d/optout.
