Hi Rathin! Am Mittwoch, 30. September 2015 21:26:11 UTC+2 schrieb Rathin Dholakia: > > Well, second things is you mean to say if I use 8 ADCs I cant achieve > 1.25Khz+ sample rate, Than should I use external ADC? would it be easier? >
The internal ADC can achieve up to 25 kHz sampling rate for 8 channels. Using an external ADC wouldn't be easier, but you may have reasons for that (which you didn't specify yet): ie. like more than 12 bit resolution, lower impedancy, ... and to be frank I have plenty of doubts in the pruio construct and > pruio_config, I which are as follows: > > > - You said I have 183 cycle open delay - but where is it? I have made > everything 0 ( zero!!) you can have a look at option setting in line > bellow!! > - pruio_new(PRUIO_DEF_ACTIVE, 0, 0, 0) > > I missed that line, sorry. (I'm not used to C syntax.) This is one way to override the default step configuration. So your code already solves point 1 in my above post. > - And in my pruio_config, I have made averaging to 0 (you can see that > as well). delay 0, > - pruio_config(io, 1, PRUIO_DEF_STPMSK , 0, 4) > > The zero in that line means Tmr = 0. Since you set Samp = 1, you're operating in IO mode. In that case parameter Tmr has no function. Tmr is used in MM or RB mode. It specifies the sampling rate (for all channels). So, is my configuration is wrong or the approach? > Your configuration is OK, but your main loop is too slow. The fprintf statement is too slow to get the desired sampling rate. libpruio serves the samples, but the ARM CPU doesn't get them all (some get skipped). Instead of using fprintf(), you could try to write binary numbers by function fwrite() and convert to ASCII numbers later. > few queries with respect to your new example > > - This is also for only 3 ADC channels, so if I extend it for 8, will > this one also become slow? > > As Wulf Man said: > There is only one ADC in the sitara processor. > There is a 8 to 1 mux to provide you with 8 inputs. Each additional channels slows down the overall sampling rate, which is 200 kHz for one step, 100 kHz for two steps, ..., 25 kHz for 8 steps > > - > - I am going to "monitor" the inputs continuously, so I require > continuous stream of input, will this approach work? > > It isn't easy to monitor 8 channels @ 20 kHz by the ARM CPU. The CPU load generated by the OS like interrupts or multitasking may get too big. I'd do the measurements by libpruio running on PRU-1 in RB mode and do the monitoring by customized real-time ASM code running on PRU-0. > - Its later part of my project but I saw u using system timer so > asking that I also want to time stamp the data with system time, so can it > be done here or should I do it later? > > Sorry, I've not enough infromation to give any statement here. BR -- 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.
