next topic »

[Reply #15 on:]

analogRead() seems to be fast enough. ... But we're drifting off topic...

Well, not really, because timing seems to be important to you.

-My sample clock wants to be 125us which I think will be another timer interrupt (I'll write that part tomorrow).

A normal analogRead (save fidding with registers) will take 104 uS. So most of your 125 uS is gone in doing the analogRead alone. I'm drawing that to your attention in case you think it is instant, and that you have something like 110 uS over between reads.

One possible thing you could do which would remove the worry about interrupt latency, and also whether or not another interrupt was active, would be to use the external ADC trigger (page 252 and 266 of the datasheet). You could start the conversion highly reliably on a timer compare match event, and then just use an interrupt to gather the ADC results, when available. This also means you don't wait 104 uS doing nothing. Win win!

[Reply #16 on:]

Avoiding other issues...

There must be a slick way to turn interrupts on and off individually with minimal avr register writes.

Why do you have this "minimal avr register writes" desire?  To turn off an INDIVIDUAL interrupt, you typically have to change a single bit setting in one register:

Code:

TIMSK1 &= ~(1<<OCIE1B);  // Turn off timer interrupt
  :
TIMSK1 |= (1<<OCIE1B); // Turn timer interrupt back on

Those should run about 3 Instructions each, and this isn't some multi-GHz chip where accessing an IO register might be unusually "expensive" because it stalls the pipeline and invalidates caches or something.  If you want control of the individual interrupts, I don't think that you can get any "slicker."  Now do you need to.
Note that you do NOT need to reinitialize the rest of the timer just to turn interrupts on and off, but that may mean that you will get an interrupt as soon as you re-enable it...

[Reply #17 on:]

analogRead() seems to be fast enough. ... But we're drifting off topic...

Well, not really, because timing seems to be important to you.

-My sample clock wants to be 125us which I think will be another timer interrupt (I'll write that part tomorrow).

A normal analogRead (save fidding with registers) will take 104 uS. So most of your 125 uS is gone in doing the analogRead alone. I'm drawing that to your attention in case you think it is instant, and that you have something like 110 uS over between reads.

One possible thing you could do which would remove the worry about interrupt latency, and also whether or not another interrupt was active, would be to use the external ADC trigger (page 252 and 266 of the datasheet). You could start the conversion highly reliably on a timer compare match event, and then just use an interrupt to gather the ADC results, when available. This also means you don't wait 104 uS doing nothing. Win win!

Yeah, I was measuring ~120us max latency in the analogRead(), plus whatever to write an int to an array (I didn't measure that yet). This drove the 125us sample time goal. There's time between bursts to process the array of samples as little, and as much time as it takes to post process it after the scan.

--> I really  like the auto triggered ADC and will certainly do that. Very helpful, many thanks.

[Reply #18 on:]

Avoiding other issues...

There must be a slick way to turn interrupts on and off individually with minimal avr register writes.

Why do you have this "minimal avr register writes" desire?  To turn off an INDIVIDUAL interrupt, you typically have to change a single bit setting in one register:

Code:

TIMSK1 &= ~(1<<OCIE1B);  // Turn off timer interrupt
  :
TIMSK1 |= (1<<OCIE1B); // Turn timer interrupt back on

Those should run about 3 Instructions each, and this isn't some multi-GHz chip where accessing an IO register might be unusually "expensive" because it stalls the pipeline and invalidates caches or something.  If you want control of the individual interrupts, I don't think that you can get any "slicker."  Now do you need to.
Note that you do NOT need to reinitialize the rest of the timer just to turn interrupts on and off, but that may mean that you will get an interrupt as soon as you re-enable it...

Yes, that's what I was after, thank you. By minimal register writes this is what I had in mind (I was hoping (assuming) that I wouldn't need to re-setup all the registers, or figure out what exactly detachInterrupts() does).  Cheers.

[Reply #19 on:]

I'm just wondering if you'll be using millis() or micros() while interrupts are off?

There are fast read ADC chips you could add and 328P's have a fast read 8 bit ADC mode.
Most code runs at clock MIPs but I/O takes a bit longer.

I have timing code that does a digital read, counter increment, and counter timeout check all in just under 1 usec per while loop with zero interrupts since I'm using micros() for time as well. 

Change that to an analog read and I'm 105 usec per loop.

IIRC whole sections of the MCU shut down during ADC so as to not affect the conversion, or is that a non-default option?

You should be playing with sound chips at those speeds anyway. 8k samples per ain't much to those, even at higher resolution.

[Reply #20 on:]

The sleep mode for ADC is non-default. I'm currently using the 8-bit mode at a 32x prescaler and it works well.

[Reply #21 on:]

I never even tried 8-bit mode. How fast is it?