One properly constructed experiment is worth a thousand expert opinions, bu t it takes at least one expert to construct an experiment that will test th e hypothesis you want tested - and you probably need the same expert, or so mebody like him, to frame the hypothesis in a form that is testable and fal sifiable.
Tinkerers thrashing about can construct all sort of inconclusive experiment s, and draw loads of misleading conclusions from them, as anybody who has h ad to debug a board with a committee will tell you, at tedious length.
One of my superiors at Cambridge Instruments was brilliant at sorting out w hat an experiment was really telling you. He wasn't as great at sorting out the problem once it had been identified, but we had plenty of John Larkin types around to do that.
It would not be difficult to make sure that the current instruction (being executed when the interrupt occurs) would always take two cycles, even if it would normally take one cycle in the absence of an interrupt. I can't say whether they did that until I do some testing.
On a sunny day (Tue, 24 Oct 2017 15:46:17 -0400) it happened bitrex wrote in :
If you were a US citizen then you did not even have to worry about a letter from The Hague, as Bush the little Jr threatened to invade the Netherlands and 'free' his soldiers if any were to put to trial there for war crimes in Iraq. US was still stronger back then. Now Europe and the rest of the world is uniting, you won't get the letter, but a more loud notice.
On Tuesday, October 24, 2017 at 10:34:51 PM UTC-7, Chris Jones wrote: ...
One way to do that if the software can be synchronized to the interrupt adequately is to use the Wait for Interrupt Instruction available on some processors.
We have considered using soft cores in an FPGA, but the usual problem is runnning out of on-chip ram for program space. So we have so far used an outboard ARM chip, or a ZYNQ, usually with DRAM. One can use a soft core with DRAM and cache, but it's easier to use a chip with a real ARM (and floating point) onboard; that boots Linux right out of the box on an eval board like a microZed.
There is of course a cultural separation between the people who do procedural C and parallel VHDL. How might the xCore fit in there?
The VHDL tends to be a lot more signals-and-systems, whereas the C is usually qualitative controls and communications.
--
John Larkin Highland Technology, Inc
lunatic fringe electronics
That completely fits my way of thinking, although I might prefer an RTOS to linux.
Precisely, and there are few of us that have straddled it over the decades. Don't know why, it seems easy enough to me!
The 30000ft design patterns are: - for each peripheral, use a separate task running on a dedicated core (tasks can be automatically combined onto a single core, provided they meet some restrictions)
- model input, output and communications as discrete events; bog-standard concepts familiar to both embedded programmers and hardware engineers
- comms between tasks are messages sent through synchronised "channels". Inputs and outputs are syntactically and semantically the same, an important unification.
- model each task as an FSM; setup() while (1) { // forever waitFor input or comms or timer do output or comms } again, bog-standard concepts familiar to both embedded programmers and hardware engineers
The "waitFor..." is a new construct, "select", which looks like a C "switch" statement except that each "case" is continuously evaluated in hardware. The core sleeps until one "case" is matched, whereupon the core continues processing with 10ns latency. That simply cannot be done with conventional processors.
xC detects and prevents whole classes of errors associated with improper misuse of shared memory, especially those related to cross-core comms.
The best, and remarkably readable, introduction to those design patterns is
formatting link
That inevitably introduces and refers to other concepts
formatting link
formatting link
The XMOS systems have got several things tied very nicely together: - "FPGA-like" IO, e.g. SERDES, multiple clock tiles (up to 250MHz), per-port timers so software can specify the clock cycle at which the next output will occur, or record when the last input did occur. That enables precise IO timing under software control; bit-bashing with accurate timing is trivial
- multicore processors where the cores and i/o ports are interconnected by a parallel switch fabric. There are no caches and no interrupts to foul up timing. That means comms and i/o are unified and have dependable latencies.
- a familiar (but safer) language, xC, that enables multiple cooperating tasks to work with the i/o and each other
- in effect the RTOS is now implemented in hardware, with the speed/latencies that implies
- a familiar IDE (Eclipse/LLVM/gdb) with the traditional speed of software development and debugging turnaround
Importantly, all of those attributes are necessary and sufficient for the IDE to be able to examine the (optimised) compiled call-flow graph, and state unambiguously that between "here" and "there" the code will take a maximum of 1020ns and a minimum of 340ns. For hard realtime you only care about the will-not-exceed maximum time, of course. You can setup the build process so that it fails if your critical timings would be exceeded (no measurements needed :) )
Overall, the documents are remarkably easy to read and are without bizarre restrictions and "gotchas". That's because the hardware and software has been built together from the ground up, based on 40 years of practical experience. 70s: communicating sequential processes 80s: Transputers and Occam naughties: XMOS and xCORE and xC
The linux/windows software is freely downloadable. Cheapest devkit (effectively an Arduino on steroids) is $15 from Digikey or Farnell
The capabilities are worth understanding, even if you choose not to use them.
Will they take over from FPGAs? Of course not. But they do extend "pure software" into territory that was previously the preserve of FPGAs.
Do they solve all parallel processing problems? Of course not. But all the design choices benefits and restrictions are understandable, provided you have a grasp of the core essentials, as opposed to hardware and languages that have merely metastasised over the decades.
AFAIK you can, but I have not actually tried it for output.
Well the "ping-pong" is in hardware. So I don't see that there is any fundamental difference between the memory pointer being switched to another buffer, or to the start of the same buffer.
For output from a circular buffer you have to make sure your software stays ahead of the DMA pointer. For the ping-pong... it's the same, really. But it is probably slightly easier to write the software, or at least easier to think about. Since you don't have to be doing modulo N all the time for the accesses.
The win would be to have continuous DMAs to the circular buffer, with the DMA controller smart enough to manage the write pointer and keep looping round and round.
Old time FIFO buffer chips had "almost-full" and "almost empty" flags. BITD I used to use the IDT 7204 to interface flash ADCs to PC parallel ports, and found its "half-full" flag very handy.
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 xCore architecture is nice for implementing various kinds of sampled systems, including DSP (Digital Signal Processing) and PLC (Programmable Logic Controller).
While the xCore doesn't have interrupts, each core can wait for an external signal and then do the "ISR" job.
Just assign a single core for each "pseudo-interrupt", activate it by an external hardware signal (sample clock) , read input, do sample processing and write output. After that, go to wait state to be activated by the hardware signal in the future.
With each activation of a core will produce a single audio/analog/binary output channel. With a large numbers of core, multichannel audio/wideo can be easily handled or a large number of PLC binary outputs can be produced easily. Typically all "pseudo-interrupts" are activated from a single hardware sample clock.
If the processing of a single sample in one core takes too long, just assign more cores for processing a single sample. While the first core processes the first part of the current sample, the nest processor is simultaneously processing the 2nd part of the previous sample an so on.
Thus the full sample rate can be maintained, but with 8 cores assigned to the same signal, the total delay through the system is 8 sample clock cycles. This absolute delay is not an issue for processing stored (audio) signals, but can produce problems in a PLC PID closed control loop.
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.