Signals and Systems for Dummies

The interrupt hardware could just do a timeout that's longer than the longest instruction.

Some divides can take 12 clocks in an M3, coincidence?, but I doubt that we'll be doing any divides.

Den mandag den 23. oktober 2017 kl. 20.18.35 UTC+2 skrev John Larkin:

on the registers are pushed on the stack in parallel with the fetch of the interrupt handler

afaiu the M0 and M0+ also have an option to always force the maximum latency so it'll have zero jitter

Den mandag den 23. oktober 2017 kl. 21.05.44 UTC+2 skrev John Larkin:

the 12 cycles is because the interrupt controller stacks a number of registers so the interrupt can be written in straight C

instructions that take multiple cycles will just be aborted and retried after the return, multiple load/store will remember their state and continue where they were interrupted

I think the only thing that adds a cycle is bitbanding and unaligned access

Well, if it times out until the current instruction is done executing it's not really an "interrupt", then. And could cause a problem if e.g. the instruction it failed to interrupt modified something the ISR expected to be unmodified.

But it would be straightforward to overcome the execution-clock jitter in software. You can look at the hardware timer register and the program counter and instruction pointer etc. whatever you need so you can add the delay required to compensate.

If you're not doing anything too computationally intensive in the main "thread" you can often also get cycle-accuracy in the ISR by always going into the ISR as a wake-up from a sleep mode

It's guaranteed to be 12, anyway.

Cheers

Phil Hobbs

I need to do something similar to that but with an 8 bit uP off an SDcard, for audio.

Think it would be fast enough to send 16 bit 22kHz audio to a DAC using the 'half-full' method using say 1k of internal SRAM as the buffer?

tell that an 8051 ...

what? an interrupt can happen at any time, it can't rely on it happening before or after some arbitrary instruction

hmm good luck..

Ping-ponging I know about, but being able to have jitter-free output sequences of any length just by keeping the buffer from going empty would be pretty cool.

Otherwise it's hard to avoid jitter at the end of each DMA sequence, no?

Cheers

Phil Hobbs

If I really zoom up on the filtered sine wave, I see a little time jitter at the zero crossings. The flatish tops of the sines look fine.

Here's the unfiltered DAC output.

It's pretty obvious that the 20 mV DAC quantization is a bigger influence than any time jitter.

Increasing the IRQ rate would make the phase accumulator increment in smaller amounts so would skip fewer points in the lookup table, and use the DAC a little more efficiently. The improvement would probably be marginal.

RMS voltage measurements emphasize the tops of the sine wave and practically ignore the zero crossings. Gotta think about that one.

On an AC DVM, the RMS voltage wiggles in the 5th decimal point.

The ARM processors I have used (M0, M0+ and M3) all has circular DMA buffers

It's an obvious application, so I think any decent manufactor is going to add that feature

Cheers

Klaus

John Larkin wrote on 10/23/2017 11:57 AM:

I figured Larkin was not doing anything about the CPU interrupt jitter simply because he didn't think of it. Then he denied that it had a significant impact without doing any analysis. Now he is blaming me for not doing the analysis *for* him! Wow! Some people are lazy.

So denial without any information, much like his climate change denial. And he claims to design good electronics.

John Larkin wrote on 10/23/2017 12:35 PM:

And yet, here you are attempting to defend not having done a very simple analysis instead of moving on. It's amazing how much effort people will put into defending their actions rather than doing what makes the most sense.

Looks like my programmer guy did exactly that, 90 degrees of sine table. The chip has 512 Kbytes of flash, so it would be a no-brainer to do a 1024 or 2048-word full-cycle lookup table. I'll have to talk to him.

People seem to recommend two to four more bits in the table than DAC bits, so a 4K table might be good with my 10-bit DAC.

John Larkin wrote on 10/23/2017 10:30 PM:

I'm not clear on why more than two extra bits would be useful. The slope of the sine is such that it can be described in an N bit look up table (LUT) with some inaccuracy at the low end. So use an extra bit and the phase error is better than the quantization error. If you want to minimize the phase error use an extra 2 bits for your LUT input and you are have more than a bit lower phase noise than quantization noise. Unless you have special requirements, you will have a hard time seeing the benefit of using more phase bits into the LUT.

Oh, I see you talk about a "full cycle" lookup table. I assume that means a table the covers all four quadrants. That is a bit wasteful. My description above assumes you are willing at least to use a single quadrant LUT to generate the output for all four quadrants. The math for that is blindingly simple. It doesn't require conditionals. You can do the math without conditional code. Multiply by 1 or -1 as a function of the input data, etc.

With a sine it's trivial to do a linear interpolation interpreting the "fractional" bits of the phase accumulator as a weighting multiplier to get points in-between stored samples, too

Yeah, what's your point?

It's only a 10 bit DAC, and I can have a giant sine table, so it wouldn't help much. We do make arbs that have high-res DACs and small waveform memory, the opposite situation, so we do interplate there, in FPGA hardware.

Certainly ARMs are great devices (as are AVRs mentioned by Bitrex, and Tom's favourite XMOS devices). That does not mean you get zero jitter for zero effort. It does not mean that a scope is a good tool to be sure you get no glitches - testing is great to prove the existence of errors, but not their absence. It does not mean that your system will continue to be as low jitter once you start adding more to it. And it certainly does not mean that careful software without branches is the sensible way to write this kind of thing, when the microcontrollers come with hardware features specifically designed to get you simple, reliable, guaranteed behaviour here!

Your programmer may be great at being sure the code is small and branch free - but he is still not giving you the best code the device could support, with the strongest guaranties of minimal glitching and jitter.

Of course, you might not /need/ such good quality signals - good enough is good enough, and there is no need to learn how to do it better if you are already within spec.