Kommentar: Einfügen von HTML im Kommentar: Link einfügen: <a href="LINKURL" target="_blank">LINKTITEL</a> Bild einfügen: <img src="BILDURL"> Text formatieren: <b>fetter Text</b> <i>kursiver Text</i> <u>unterstrichener Text</u> Kombinationen sind auch möglich z.B.: <b><i>fetter & kursiver Text</i></b> C Quellcode formatieren: <code>Quellcode</code> BASIC Quellcode formatieren: <basic>Quellcode</basic> (Innerhalb eines Quellcodeabschnitts ist kein html möglich.) Wichtig: Bitte mache Zeilenumbrüche, bevor Du am rechten Rand des Eingabefeldes ankommst ! -> I > > > > > > 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 <i>allways</i> 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 > >
