Signals and Systems for Dummies

On a sunny day (Mon, 23 Oct 2017 13:09:02 +0200) it happened David Brown wrote in :

There are many ways to skin a cat. Here I use a 4 kB FIFO buffer on a Raspberry Pi to constantly output DVB-S 8 bits. The raspi can multitask and just do a lot of other things. Only 2 chips OK?

formatting link
buffer is refilled to full anytime the raspi sees the 'half full flag' from the chips. The buffer is clocked at a constant rate (crystal). Continuity and low jitter is essential in DVB. I am not 100% sure why one should always spare on chips, especially for test equipment. Hardware is cheap, having some flexibility is nice so you can write the code you want. If you sell your stuff for > 1k $ then 4 $ chips makes no difference.

Am I missing something? Do not lot of FPGAs with build in ARM core also have FIFO memory?

Code is also on the above link.

?
Reply to
Jan Panteltje
Loading thread data ...

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:

formatting link
Oh, end it makes the RC servo signals too, in x,y
formatting link
Just to get those F35 you know :-)

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 :-)

Reply to
Jan Panteltje

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.

Reply to
Jan Panteltje

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

512, load the DAC.

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.

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics
Reply to
John Larkin

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.

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics
Reply to
John Larkin

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.

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics
Reply to
John Larkin

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

formatting link

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.

Reply to
Tom Gardner

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

2*Pi*400*50/120.0e6 = 0.0010...

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

24-40 MHz. So most likely it is four instructions per 32 ns flash clock or even eight instructions per 64 ns flash clock. Similarly with I/O bus. And you seem to think assembler -- with high level tool there may be tons of crap that tool inserts without you beeing aware of this. On old systems one could write code that execuded in prescribed number of cycles -- this is _very_ hard on modern system and basically impossible using high level tools.
--
                              Waldek Hebisch
Reply to
antispam

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

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC 
Optics, Electro-optics, Photonics, Analog Electronics 

160 North State Road #203 
Briarcliff Manor NY 10510 

hobbs at electrooptical dot net 
http://electrooptical.net
Reply to
Phil Hobbs

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

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics
Reply to
John Larkin

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.

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics
Reply to
John Larkin

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

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC 
Optics, Electro-optics, Photonics, Analog Electronics 

160 North State Road #203 
Briarcliff Manor NY 10510 

hobbs at electrooptical dot net 
http://electrooptical.net
Reply to
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.

Reply to
Jan Panteltje

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.

Reply to
Tom Gardner

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 :-)

Reply to
Jan Panteltje

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.

Reply to
Tom Gardner

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.

Reply to
bitrex

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.

--

John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  

jlarkin att highlandtechnology dott com 
http://www.highlandtechnology.com
Reply to
John Larkin

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."

Reply to
bitrex

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.

--

John Devereux
Reply to
John Devereux

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.