Good evening! thanks for the conciseness (btw with Host CPU you mean the bbb one?)!
You are fairly right about the lack of requirements in my question, the main problem is that I don't really have one! The lower the latency the better could be the tagline of my project. The original plan was to use as synchronization source (of the system clock) a ptp clock or ntp server and acquire the samples one second (200ksamples) a time and attach a timetag to every one of them, and thatìs why I was looking for a way to force the fifo counter rollover, I've the horrible feeling to have posed the question the wrong way and have mistaken the whole clock concept. I've found this thread (https://groups.google.com/forum/#!searchin/beagleboard/ptp$20adc/beagleboard/x3yolF9rNJk/_oPkIV5pC_UJ ) and maybe is how I should start, with libpruio I should be able to control the adc and at least increase the sampling rate (other adc spec I wanted to improve). Regards V. Il giorno mercoledì 12 agosto 2015 11:54:02 UTC+2, TJF ha scritto: > > Hi! > > Host CPU and TSC_ADC_SS have different clock domains. Internal ADC clock > rate is 24 MHz. The theoretical maximum sample rate is 1.6 Msamples/s (= 15 > cycles@24MHz in single shot mode) or 1.74 Msamples/s (= 14 cycles in > continous mode). In praxis it's 200 ksamples/s. > > The PRUSS are first choise for real time tasks with high timing accuracy. > > Below 10 ksamples/s the CPU latency (due to Linux non-real-time-ness) is > small (less than 10 % on a vanilla system). > > When you need concrete hints, you'll have to specify your timing > requirements: > > - Is the external clock a regular pulse train? > - What frequency? > - Which maximum latency is required between clock pulse and ADC sample? > > BR > > Am Mittwoch, 12. August 2015 08:34:02 UTC+2 schrieb Valeria M.: >> >> Hi TJF, thanks for your reply! >> I was hoping not to have to resort to use PRUs D: , for now the low >> accuracy given by the ADC clock will have to do. (btw why 10 kHz accuracy? >> it's caused by Linux non-real-time-ness? Otherwise ADC clock frequency >> should be 1,6 MHz max right?) >> >> Other random question: I suppose that if I sync the BBB system clock to >> an external clock the ADC's one won't be affected by it right? I mean they >> have different time 'domain'. >> >> Corss-compiling I'll be able to debug my procject. >> >> Valeria >> >> Il giorno martedì 11 agosto 2015 21:45:09 UTC+2, TJF ha scritto: >>> >>> Hi Valeria! >>> >>> The FSM module in the TSC_ADC_SS can either get triggered by software or >>> by an external hardware event (TIMER4-7 or PRU_ICSS pr1_host_intr0). See >>> SRM >>> chapter 12 <http://www.ti.com/lit/pdf/spruh73> for details. >>> >>> The best way how to synchronize with an external clock depends on the >>> clock frequency and the timming accuracy requirements. For high accuracy or >>> above ~10 KHz you may need customized software. >>> >>> But below that frequency you may be happy with a simple solution: The >>> ADC operates at a fast sampling rate and the host CPU just reads the >>> current value when the external clock fires. This is feasible with >>> libpruio <http://beagleboard.org/project/libpruio/>. (You may see some >>> latency when the host CPU is busy by any system interrupt.) >>> >>> BR >>> >>> BTW: Cross-compiling adds further problems. Why not compiling on the BBB? >>> >> -- 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.
