ISR not holding Timer1 preload, M328P

Matrixx · Joined: 30 Nov 2005 Posts: 158

Hello, I'm trying to implement a 3 simultaneous tone synthesizer based on the additive synthesis using a M328P.
Although the M328 is small for this project, I started with because I can program it fast with the boot loader & the FTDI cable.
(Upon getting it work, I will migrate to Xmega128A1U as I cannot simulate the Xmega).

I use the DAC MCP4921 to generate the audio signals, and the M328 running on the 8Mhz Xtall.
The DAC is updated at fixed 15.625 Khz this mean I have 64 uS to prepare the mix, produce the sample and transfer to DAC.
I have set Timer1 to prescale = 1 and preload it with 65024 (65536 - 65024 = 512 thus 125 nS x 512 = 64 uS).
I do reload the timer inside the ISR, of course.

I do all the simple math inside the ISR. the math code takes 28 uS. The SPI write to the DAC takes 25 uS.
So the operations inside the ISR last for 53 uS. This is enough to keep the thing working ok.

The problem is:
At some point adding more sums or shift left/right inside the ISR, the CS signal takes now 8 mS on the scope. Commenting out either one of the sum
or Shift gets back to ISR period of 64 uS. I was trying to figure out what happen, 8 mS is quite far from the preload value for the
timing I set. Then it is not related to sum in particular but about the number of operations done.

What I think is happening, is the Timer1 lost the reload value because 8 mS is likely the Timer1 is counting the whole 65536
before overflow (125 nS x 65536 = 8.192 mS). Because I reload the Timer1 at the beginning of the ISR and do all the math next,
to confirm my suspects I reloaded the Timer1 just before the ISR ends, and it worked! Of course this does not account for the
time of the operations so I would need to modify the Timer1 reload value...
Looks like the doing more than certain number of operations after Timer1 is loaded, mess with the Timer1 already set value...?

So the question is, why the Timer1 lost the load value if I do more or less operations inside the ISR?

-If you say is because the operations inside the ISR are taking longer time, I set a PortD.2 pin to measure just the math timing. And
the results are the math goes up to 34 uS, so 34 + 25 = 59 uS, enough to still work inside the ISR.

-If you say something about using Pushall/PopAll, welll... I'm not using it in my ISR so I did a Try. I added PushAll/PopAll but this
does not cure the situation. Growing up the Hwstack, Swstack & FrameSize from 80 to 200 didn't help either.

-If you say I can do the math in the Do..Nothing loop, setting a flag to know when the ISR has ended; this is a solution
but by now I'm concentrated in to know why this behavior happen, and how it can be fixed, or is a sort of bug..?

BascomAvr 2.0.7.9

JC · Joined: 15 Dec 2007 Posts: 586 Location: Cleveland, OH

Two thoughts:

You probably know this but I'll mention it anyway.

You have very little "extra" time in your ISR.
Using an O'scope is a great way to measure the time the ISR takes to run, and to see it execute as expected.
Know, however, that the O'scope markers start well after the ISR begins execution, and ends well before the ISR is actually over.

Bascom, when executing an ISR, automatically pushes and pops a LOT of registers.
See the On Interrupt instruction within the Help for the details.
That means that if your timing is very tight, you may well miss interrupts.

Next, I love the Xmegas!
If you intend to switch to the Xmega anyway, why not do so now?

At 32 MHz you have 4 times the processing power, (clock cycles), you have with the Mega at 8 MHz.

Tight timing inside the ISR is then not a problem at all.

JC

i.dobson · Posted: Sun Oct 22, 2017 7:32 am Post subject:

Hi,

My tips would be:-
1) Try running the AVR at 16MHz
2) Try pushing/poping the Registers used in the ISR (rather than everything)
3) Replace the HIGH/LOW with variable overlays. Somthing like:

EDC · Joined: 26 Mar 2014 Posts: 971

With Clear_Timer (timer autoreload) and Nosave Interrupt option you should be safe to do your tasks Wink

See Code1 and screenshot.
...but if your main loop do nothing then even saving/restore registers is not needed because you can use Timer flag for timing and not use interrupts (code2).

Code1

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

Best practice (IMO) is that you set the timer just before the ISR is terminated and not on entry as you do.

So normally you set the timer in the main code just before you let the timer run, and then again in the ISR before it ends.

Of course you can also use the compare mode of the timer so you do not need to load the reload value yourself.

Matrixx · Joined: 30 Nov 2005 Posts: 158

I was playing a bit with the M328 yesterday and that is true. With 3 tones there is almost no time left inside the ISR for the rest of the features. I also consider the 16 Mhz option, but using the Pro Mini runs on 3.3V, I do not have the 16 Mhz 5V version around. But have some M2560 R3 boards that I could use.

Using Overlay bytes; a nice way to get High/Low !

It looks its time to use the Xmega now; I will start adding the rest of the features like drawbars and MIDI so it will need more time.
Xmega I have ran up to 44.2368 Mhz using a 7.3728 Mhz Xtall and a x6 multiplier.

This project I'm adapting from Roto; it produces cool sounds form the classic B3 organ.

Thank you all for your tips & clever code, I will do a try. Smile

If someone want to test, this next settings produces nice tone assuming the ISR timing is well calibrated (I did reload the timer before ISR end, compensating for the math length) for the 64 uS.

At the Indexes: