Signals and Systems for Dummies

On a sunny day (Mon, 23 Oct 2017 23:15:16 +1100) it happened Chris Jones wrote in :

Yes, PICs can be very efficient code wise. I have done analog signal video processing in a PIC 12F629, using the 2 PIC comparators as sync slicer and video level detector. Never a delay problem Same in a 18F14K22. in x dimension:

But you need to read the datasheets and understand how the hardware in it works. All in asm, mind you. Just typing some C will never work, it is all based on instruction cycle counting. got used to that in Z80 days when programming in binary :-)

Simulation??? I do not even have mplab. All I Need Is A Scope And One I/O Pin. gpasm Wrote the programming software too.

Its easy :-)

On a sunny day (Mon, 23 Oct 2017 15:54:19 +0200) it happened David Brown wrote in :

Very long time ago there was a jive about fighter software that did not use any interrupts at all (requirement). Was it called Viper? Bing does not find it, maybe the name was something else.

I didn't write the ARM code; I designed the hardware and discussed the DDS math with my embedded system programmer guy. It's easy, in fact automatic, to write the DDS code with no branches. Add the frequency control word to the phase accumulator, mask the top bits, index into the sine table, pluck the data, multiply by a gain cal factor, add

We could load the DAC first thing in the IRQ, and then calculate the next point, but there's apparently no need to do that.

If we run at 100 MHz, that would be 30 to 50 ns; my estimate was "tens of ns" of uncertainty. 50 ns p-p is about 15 ns RMS, or maybe less. To generate a 400 Hz sine wave at 125 samples per cycle.

Heck, it's only a mediocre on-chip 10 bit DAC, and its reference is the 3.3 volt power supply. 15 ns RMS jitter is trivial.

If simple works good enough, I can move on to something else.

I wrote one cross assembler for a Motorola 8-bit CPU, that showed instruction timing in the listing for every instruction. I'm glad I don't have to do that sort of thing any more.

Viper was a mid-80s provable correct processor from RSRE, except for the bit that wasn't provably correct.

But interrupts are a hack, originally required because there were insufficient processing resources that had to be shared amongst different activities. Nowadays that's not a limitation, and some enlightened processors (e.g. XMOS' xCORE) manage to avoid having interrupts (and caches).

I expect that approach to gradually become more pervasive over the next few decades. After all, transistors are no longer the principal limitation; nowadays internal interconnects, pins, power dissipation and i/o bandwidth are more problematic.

It is simple: with reasonably dense sampling error due to sampling at wrong time is timing error times derivative of your function. Assuming 400 Hz sine weave, that is sin(2*Pi*400*t) drivative is 2*Pi*400*cos(2*Pi*400*t) so maximal value of derivative is 2*Pi*400. With 120 MHz clock an 50 clock jitter the max error is

so error due to jitter is comparable to error due to 10-bit quantization. Of course main ingredient of this noise is at sampling frequency, so a little analog filtering will help a lot.

AFAIK nobody make flash working at 120 Mhz, typical is between

The interrupt latency on an ARM Cortex M3 is guaranteed to be exactly 12 cycles when coming from mainline code, and 8 cycles when coming from a lower-priority ISR. (There are caveats on this in the ARM docs, but we've found it to be so in practical cases.)

Works very nicely. JL said that there were no other interrupts, interrupts are never disabled, and the interrupt is generated synchronously with the CPU clock, so where's the jitter coming from? Seems as though the clock oscillator is the only major contributor.

Cheers

Phil Hobbs

The clock is an external XO. The internal clock wouldn't be frequency-accurate enough.

The NXP data sheet specifies zero wait states; it does some flash multi-porting and prefetch and branch anticipation stuff.

I wouldn't dream of programming an ARM in assembly. I don't program it at all; I discuss the math with my programming guy, and he does it. I prefer drawing schematics.

I didn't know DMA controllers could handle ring buffers. Can ARM Cortexes?

Cheers

Phil Hobbs

On a sunny day (Mon, 23 Oct 2017 17:43:20 +0100) it happened Tom Gardner wrote in :

Ah, yes that is the one thanks.

Possible, I code a lot in C on a multitasking OS (Linux) and multithreaded too. But indeed for fast stuff dedicated processors with processes that are not interrupted is the way to go, I do that too, and connect those via ethernet to the bigger Linux one.

This is how the human body works too, some neural pathways are reflexes, short paths. some signals go via the brain.

Have a look at the XMOS xCORE processors. They are fast enough to be able to do 100Mb/s ethernet in software, but many of them include ethernet or USB hardware. Key points: "FPGA-like" i/o, deterministic timing (the IDE inspects the binary before execution), multicore up to 4000MIPS/chip (scalable), and most importantly, the software environment so you can easiuly use those attributes.

I'm not going to repeat the, ahem, unpaid advert I've just written elsewhere in this thread.

On a sunny day (Mon, 23 Oct 2017 18:40:36 +0100) it happened Tom Gardner wrote in :

I already downloaded and did read the xCORE-Architecture-Flyer%281.1%29.pdf :-)

You'll find the programming tutorial interesting as well, I expect :)

It is unusual, and pleasant, to see hardware and software merging without unnecessary impedance mismatches.

in avr-gcc for 8 bit:

Assembly output:

No tests or branches or anything that would inject any non-deterministic latency. I mean one could try to do better using handwritten ASM.

If one uses a bunch of switch or if/else statements inside the ISR for the quadrant logic like a silly billy it won't be a nice.

They prefetch instructions from dual-port flash and apparently speculatively prefetch branch destinations, to guarantee zero waits. But I bet they don't prefetch vectors. So they can keep the chip perfectly predictable if they add a fixed delay to the interrupt process. Well, there's a lot of stuff to do to service an interrupt, too.

Nah. When C++ for example says "Zero Overhead" they mean ZERO OVERHEAD.

Not "Sometimes we add 30 extra instructions to this ISR than would be required for the same effect via asm, just cuz."

I don't know if they all use the same DMA hardware, I would have assumed not. But STM32 can do a DMA ring buffer - "circular mode". I have used it for acquiring samples from a 2MHz external serial ADC with no breaks in the data, works fine. It can also alternate between two buffers IIRC to get a similar effect.