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