| Re: ADC in free running mode Kategorie: Pro-Bot128 (von PepeV - 5.01.2012 16:09) | ||
| Als Antwort auf Re: ADC in free running mode von PeterS - 5.01.2012 11:32 | ||
| ||
|
> > > > > Hello Pepe, > > > > > > > > > > if you look into the datasheet, you see that an A/D conversion takes between 65µs > > > > > and 260 µs. This is because an ADC is internally a capacitor that is filled. The > > > > > circuit measures the time that is needed to fill the capacitor, that is the > > > > > conversion value. So you see, an A/D conversion needs a different amount of time > > > > > depending on its value. > > > > > > > > > > The 2nd problem is that this is no real assembler interrupt. When the interrupt > > > > > occurs when the interpreter is in a floating point multiplication bytecode, the > > > > > IRQ routine is called after the bytecode in progress is finished. The latency of > > > > > the interrupt may therefore differ in dependency of the nature of the bytecode > > > > > that is running. > > > > > > > > > > Regards, > > > > > > > > > > Peter > > > > > > > > Hi Peter, > > > > > > > > I don't think your first remark plays a role here. The datasheet explicitly states that > > > > exactly 13 clock cycles are needed for an ADC in free running mode (see figure 112 > > > > on p. 235 and table 95 on p. 236). > > > > > > Pepe, please take a deeper look. When you read carefully, you see that they are talking > > > about ADC clocks. In the moment the ADC clock is set to 115khz. We cannot use an other > > > prescaler, because you are losing accuracy when you clock the ADC higher than 200khz. > > > So 13 ADC clocks are about 120µs for a single conversion. > > > > Oh sorry, I read all the postings again, and I saw you already pointed out, that a conversion > > takes about 120µs. Perhaps you should investigate the return value of Irq_GetCount(INT_ADC) > > to check if they are really interrupts missing. Some I/O (debug, rs232) bytecodes may take > > longer than 40µs. > > There is the 100Hz interrupt, that does some multithreading stuff, checks > for running servos, increments counters and every second updates clock and > calendar values. So every second this interrupt likely needs more than 40µs. > You can check this, if you temporarily disable this interrupt when you disable > Timer2. > > > > > Regards, > > > > Peter > > > > > > > > > > > > > Your second remark could be an issue but I don't see how my code could possibly > > > > delay the interrupt since it only runs an empty while loop. Is it then that there is > > > > bytecode running in the background that is so time consuming (chunks of more than > > > > about 40 µs) that it causes my program to miss interrupts? > > > > If so, is there something that can be done about it? > > > > > > > > Regards, > > > > Pepe Hi Peter, I found a workable solution now. From your Benchmark program I concluded that I can never make the ADC_ISR fast enough to avoid missing interrupts. What I have done now, is program the ADC_ISR so that it is just slow enough to allways cause the missing of one ADC interrupt. (I use some dummy statements for this purpose.) This leaves (a little less than) 113 µs for the 100Hz interrupt to do what it should, before the third interrupt is missed. It appears that this is sufficient. I can now take samples of the microphone signal at half the theoretical maximum of 8861.54 SPS, i.e. at 4431.77 SPS. The time between the interrupts fluctuates because of the background activity but the time between the ADC's is a stable and precise 225.69 µs as result of the free running mode. This is what I need to be able to perform accurate FFT on the microphone signal in order to let the robot respond to whistles with different pitch. (I had realised this earlier with timer controlled ADC_Read commands but because of the mentioned background activities the length of the intervals is not constant. This made the FFT (and thus the robot action) not very reliable. Also the maximum sample rate I could attain was 3438.8 SPS which is considerably lower than the 4431.77 SPS I have now.) Thanks a lot for your help! Pepe | ||
Antwort schreiben Antworten:  Re: ADC in free running mode (von PepeV - 7.01.2012 13:45)Re: ADC in free running mode (von PeterS - 7.01.2012 16:27)Re: ADC in free running mode (von PepeV - 13.01.2012 11:55) | ||
Zur Übersicht - INFO - Neueste 50 Beiträge - Neuer Beitrag - Suchen - Zum C-Control-I-Forum - Zum C-Control-II-Forum