Best MCU for the lowest input capture interrupt latency - Page 1
Forum section: electronics / general

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: March 30, 2022, 04:36:44 pm
content: Hello,I need to generate pulses triggered by a..... pulse.I quickly test this by feeding a pulse into an input capture pin on a dsPIC33EP MCU @ 140Mhz ( without any signal conditionning ).Inside the ISR, I generate a pulse and measure a little less that 600nS latency between the input and output rising edges, ( nothing in the while loop, all is inside the ISR )I wonder if there is some tricks to reduce this latency. I don't have a goal to achieve, it is just by curiosity.Do you know MCU much better in this area ?Thank you very much

author: nctnico
author_rank: Super Contributor
timestamp: March 30, 2022, 04:49:44 pm
content: There are MCUs with programmable state machine / timer units. For example NXP LPC1500 series. Then there is no software involvement at all.

author: tggzzz
author_rank: Super Contributor
timestamp: March 30, 2022, 04:51:43 pm
content: Quote from: jemangedeslolos on March 30, 2022, 04:36:44 pmThe XMOS xCORE processors have a guaranteedby designprocessing time. None of the traditional execute then measure then hope you have captured the worst case rubbishThey can guarantee receiving and processing 100Mb/s ethernetbit streamsinsoftware, without a dedicated ethernet peripheral.The IDE tells you how long it takes to get from "here" to "there". Latency is minimised: no caches, no interrrupts, just one of many cores sitting idle until it needs to do something.However, often latency is less important than jitter.The most rigourous technique is to avoid going through the processor altogether, either by external hardware/FPGAs or by imaginative use of peripherals in a specific processor.

author: DavidAlfa
author_rank: Super Contributor
timestamp: March 30, 2022, 04:57:55 pm
content: You're missing a lot of details.Compiler? Optimization level? Can you attach the ISR code?600ns is ~84 instructions at 140MHz, so clearly your code is either poorly optimized or something is taking a lot of time in the ISR, ex. context saving/restoring.If you do simple taks, avoiding calling other functions inside the ISR, it should save less data and thus provide a faster interrupt.

author: JPortici
author_rank: Super Contributor
timestamp: March 30, 2022, 05:25:41 pm
content: Quote from: DavidAlfa on March 30, 2022, 04:57:55 pm42, as instructions take two clock cycles.still too long.I would expect in the order of 20 or less, as interrupts on dsPIC are fast.(14 cycles after IF is set)care to show some code?

author: DavidAlfa
author_rank: Super Contributor
timestamp: March 30, 2022, 05:31:02 pm
content: 2 cycles? Oh, I see it's different for dspic33E, I used dspic33F, they were were slower but did 1 instruction/clock.I remember adding some attributes to the ISR giving much faster response.Maybe it was this...Code:void __attribute__((interrupt, shadow)) _YourISR(void)But as far as I know, there's only one shadow register set available, so you must ensure there're no other interrupts being called on top of your ISR, that means, your ISR must have TOP priority.Using Shadow, the context is automatically saved and restored in hardware, greatly reducing the latency.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 30, 2022, 05:32:22 pm
content: Look for any MCU that has "peripheral trigger" capability. Quite a few out there these days.Note that while this *usually* has lower latency than anything interrupt-based, the external trigger signal must still be synchronized internally, so you will still have a couple clock pulses of latency.

author: JPortici
author_rank: Super Contributor
timestamp: March 30, 2022, 05:33:53 pm
content: Quote from: DavidAlfa on March 30, 2022, 05:31:02 pmYes, in dspic33c and dspic33e instructions are pipelined in two stages and flash is 48bit+8bit wide (two that instruction are fetched at the same time plus optional hamming code parity) with the obvious higher latencies on branches but overall higher throughputAnyway the OP should either-show some code (both interrupt and initialization of the peripheral, i don't remember if the IF flag is syncronized with FCY or with the IC clock, that would slow down things)-state the minimum acceptable latencyin any case, i would probably use an hardware trigger, too.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: March 30, 2022, 06:03:59 pm
content: Pretty sure I could do that with the AVR-DA I've been playing with. It could be something like: input into event into TCD "fault", fault clear --> begin output pulses (delayed by, I think 1-3 clock cycles, at 24MHz max), TCD overflow event --> TCA count event, TCA overflow --> disable TCD or input event to terminate pulse train. And if the pulse train isn't too fast, TCD overflow interrupt could set new PWM/freq settings during it.Assuming you mean pulsestriggered by pulse.Oh, if the input isn't a sustained level, then route it through the CCL (configurable custom logic) first, as a flip-flop say.I think much of these peripherals have been in use, in some form or another, in other MCP products -- tinyAVRs have 'em, I think lots of PICs had CCL or something similar, maybe some of these more advanced timers I don't know, probably something that can be adapted.As for raw interrupt latency, not sure about other systems, but AVR is fairly exemplar on this, but it's rare you get to use it at its fullest capacity, if ever. The interrupt itself occurs in a couple cycles (finish current instruction + jump into interrupt vector), but the IVT only has space for two words, traditionally aJMP .isrinstruction. If you already have address and value loaded into dedicated registers, you could put aST , r25; RETIor whatever in there, and that's it. If you guaranteed aren't using the interrupts immediately following it, you could write more code into the IVT. And, if compiled, the typical overhead goes something like: IVT JMP, preable (PUSH stack pointer, flags, registers), actual code, postable (POP everything), RETI. Which will give something like a fractional microsecond at the best of times; actually, not quite true, I've seen GCC emit the actual bare minimum when it's a copy between fixed memory locations -- no need to dirty multiple registers, save just the one and go.Similar things apply to other platforms; ARM for example stores the return address in LR, which you'd better push to the stack before doing much else (and depending on when/how interrupts might be enabled during the current ISR, if that's optional or automatic or whatever?). Maybe some operations can be done entirely from register, maybe you need to push a whole bunch of them to do much of anything.And yeah, because of pipelining, the interrupt itself costs at least that much; as a result, latencies tend not to go down much, even as you go up in frequency and power. Even if the CPU is that much faster, if all the IO operations have to propagate through bus interfaces and caches, it's still true. So like, buffered IO is mandatory for modern peripherals, that can accumulate fractional MBs in the time taken to empty their buffers. Fast response is best handled by hardware or configured logic, which, brings us back to the first point: now that MCUs are often integrating such logic, it's quite possible now that something even sub-cycle can be pulled off with them. But you'll have to go shopping, and read datasheets in detail, to figure out whether any particular thing is possible.Tim

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: March 30, 2022, 06:14:44 pm
content: You can do this pretty damn fast in an FPGA, and you can have dozens or even hundreds (depending on how many I/O pins the FPGA has) of pulse inputs and outputs.

author: Kleinstein
author_rank: Super Contributor
timestamp: March 30, 2022, 06:28:27 pm
content: Some hardware triggering is supported by some µCs. Most of the STM32 can do this and AFAIK also STM8...The idea would be to use the external signal to trigger / start a timer that produces a pulse. AFAIK many PICs also have timers with a trigger.For the interrupt latency the AVRs can be relatively good, when programmed in ASM, though the clock speed is limited. I remember code with an ISR call every 26 cylces and this still had some 10% of the processing power left for the main program.A compiler tends to add quite some overhead to the ISR code, like an extra jump vector or more registers saved to the stack.

author: jpanhalt
author_rank: Super Contributor
timestamp: March 30, 2022, 08:14:35 pm
content: An interrupt usually requires saving context. Of course, with some chips, you don't need to do that. Since "everything" is in the ISR, why have an ISR? Polling a single bit, even with a mid-range PIC at 32 MHz, takes 2 Tcy (250 ns) + a little housekeeping.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: March 30, 2022, 08:27:15 pm
content: How about a PIC32MZ? Runs at 252 MHz and has register banks to reduce interrupt latency down to a minimum.

author: 8goran8
author_rank: Contributor
timestamp: March 30, 2022, 09:00:41 pm
content: You can make a test using some 8-bit or 16-bit Microchip PIC with Core Independent Peripherals .

author: JPortici
author_rank: Super Contributor
timestamp: March 31, 2022, 03:06:31 am
content: Quote from: Sal Ammoniac on March 30, 2022, 08:27:15 pmbesides the fact that unless you write the ISR in asm interrupt latency in MIPS is horrific compared to dsPIC...peripherals run at 50MHz max and in those the interrupt flags generation latency is tied to the peripheral clockin dsPIC33E peripherals run at 70MHz max, latency is lower also because there are register banks (at least the shadow bank)

author: tggzzz
author_rank: Super Contributor
timestamp: March 31, 2022, 09:58:33 am
content: Quote from: jpanhalt on March 30, 2022, 08:14:35 pmThe xCORE devices take that approach, but are better.It can do that withallinput ports simultaneously, using one core per port.The waiting is done in hardware, and there are simple language constructs to achieve it.You can also "multiplex" multiple ports, timers/timeouts, etc into a single core, and the hardware implements which branch of the "case statement" to execute.Hardware records the clock cycle at which input occurs or output will occur.Yes, effectively there is a simple RTOS in silicon.Buy them from DigiKey

author: mon2
author_rank: Frequent Contributor
timestamp: March 31, 2022, 11:31:48 am
content: XCORE +1 ; there is a learning curve but may be a good fit; check if silicon is available; I do monitor that forum as well along with others to assist if you need helpFPGA +1 ; Gowin / Efinix Trion are low cost devices that will also fit your project; low cost kits available from both vendors

author: newbrain
author_rank: Super Contributor
timestamp: March 31, 2022, 12:06:00 pm
content: Quote from: mon2 on March 31, 2022, 11:31:48 amTo have the best of both worlds (not really*, but worth checking) the PSoC5 family has a decent amount of FPGA-like programmable logic that can be used to generate a (train of) pulse(s) from a pin change event.The programmable logic can be seamlessly connected with DMA and IRQ to provide higher level control and monitoring from the CPU.Verilog is supported, if one does not want to use the IDE.*There are drawbacks: Windows only IDE, not much support, high cost for the single part, cheap devkits but not currently available...

author: tggzzz
author_rank: Super Contributor
timestamp: March 31, 2022, 12:20:58 pm
content: Quote from: mon2 on March 31, 2022, 11:31:48 amAgreed.When I first "kicked they tyres", I wasamazedat how fast I got things working. There werezerounexpected surprises;everythingjust "worked as it says on the tin". I've never had that with any other MCU.Key points: the xCORE hardware and xC software have been designed so they work together seamlessly. Each complements the other.The documentation is brief and accurate, and I didn't see any errata or caveats. Quite remarkable; I wish all devices were as easy!The IO ports are nicely designed and have many FPGA attributes. Clock rate and width can be chosen independently of everything else, SERDES, various simple modes such as strobe, latch, etc. Can ignore the input until == or != an arbitrary value. Timers capture the clock cycle at which input occurs or output will occur, or a timeout occurs.Simple language constructs capture all of those hardware capabilities, including wait until input from this port or that port or timeout or output completed.Within a day of starting, I was able to get it to:capture two serial input streams at 62.5Mb/s, guaranteeingby designnot to miss any bitscount all the 0->1 transitionsdo front panel operationscommunicate with a PC over USBThat would have been impossible with other MCUs. At the very least I would have had to take many measurements to assess the performance, andhopethat I had captured the worst case.The XMOS devices have FPGA like attributes, and sit in a niche between conventional MCUs and FPGAs.

author: JPortici
author_rank: Super Contributor
timestamp: March 31, 2022, 12:30:20 pm
content: without changing the MCU, if the OP would also reveal the full partnumber he could be aided in how to best use the peripherals available to reduce latency (PTG / OC trigger)Maybe the ISR is not actually needed, or it's needed to control the length of the pulse, and provided the pulse is at least N* cycles long it could be done without much effort*say 20 cpu cycles, it shouldn't take more to enter the ISR, move a word from ram and to the OC compare register and let it synchronize

author: DavidAlfa
author_rank: Super Contributor
timestamp: March 31, 2022, 12:48:56 pm
content: I don't think he needs changing the whole system for this, PICs don't have a big interrupt latency.It's the compiler context saving overhead what usually causes it, can be optimized by trying few things.I recall having this issue years ago, though I can't remember the exact details, but I greatly reduced the ISR delay.- Avoid calling other funtions in the ISR- Using static or global volatiles instead the stack.- By default, Shadow registers are not used as there's only one set!- If timing it's so critical, set the ISR to highest priority and enable the shadow registers.This should reduce the context saving to the minimum, but as I already said, ensuring no other interrupts happens in top of that one.Code:void __attribute__ (( interrupt, shadow, no_auto_psv)) yourISR(void)Anyways, lately there're lots of threads with a lot of unnecessary feedback where the OP flew away.So I'd avoid extending this discussion further until he gives signs of life, adding some code/details.So many times we squeeze our brains, and when the code is finally shown, it's an ugly abomination, explaining all the issues...

author: tggzzz
author_rank: Super Contributor
timestamp: March 31, 2022, 01:38:53 pm
content: The OP statedQuote from: jemangedeslolos on March 30, 2022, 04:36:44 pmand that's just fine.I don't think specific information is required, but he is after general/universal techniques. Good for him!

author: HwAoRrDk
author_rank: Super Contributor
timestamp: March 31, 2022, 03:30:03 pm
content: Quote from: Kleinstein on March 30, 2022, 06:28:27 pmYes, STM8 can do this, but I have found that there is at least 3 cycles latency (of timer clock that is, not CPU) between the trigger and timer start/reset, due to synchronisation. This makes it not so useful for some applications.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 31, 2022, 05:49:03 pm
content: Peripherals may or may not have exactly what you need, depending on the specifics of your use case.But, Cortex M4 and M7 MCUs running at some 200MHz are not expensive, and 2-3 cycles for synchronization, 12-cycle interrupt latency + maybe 3-4 cycles for the IO, you can do it in around 100ns. 500MHz Cortex M7 parts are a bit more expensive, but still only around $10 mark, and will make that down to 50ns. The advantage of the general purpose interrupt/software solution is independence of the peripheral resources. You can make the most critical IO operation as the very first thing in the ISR, and then keep doing something else, for complex cases.If something even quicker is needed, in very simple cases a good old logic IC could do (say, a flip-flop, or a logic gate). If you need more than 2-3, then you would likely want to go for CPLD.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 31, 2022, 09:01:47 pm
content: Quote from: jemangedeslolos on March 30, 2022, 04:36:44 pmIf I remember correctly, interrupt latency is 10 instruction cycles, so at 70 MHz instruction clock (that's what you get with oscillator at 140 MHz), you should get 150 ns latency. You do not need any context save to drive a pin, so you can do it right upon ISR entry, giving you the response time under 200 ns. Of course, if you write in C there will be a lot of overhead, so you must write the ISR in assembler.Newer dsPICs (CK and CH) which can run at 100 MHz instruction clock you can give you roughly 120 ns.With FPGA, you can get the reaction time under 10 ns.

author: rstofer
author_rank: Super Contributor
timestamp: March 31, 2022, 09:15:15 pm
content: For the GNU chain (and others) you can use the 'naked' attribute in the function definition to eliminate the generation of prolog and epilog code:Quotehttps://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.htmlI have no idea whether this applies to dsPICs or any other chip. It does work for ARM.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: March 31, 2022, 11:01:16 pm
content: Quote from: JPortici on March 31, 2022, 03:06:31 amWell, yes, that's generally the case with a more complex CPU (PIC32) versus a simpler one (dsPIC). The latency is more visible to the programmer for something like a PIC32 versus something like an ARM Cortex-M because the CPU does essentially nothing before jumping to the ISR, whereas with the ARM it saves registers automatically before jumping to the ISR.Overall, I'd agree--if the absolute lowest interrupt latency was important, I wouldn't use a PIC32 or even an ARM.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: March 31, 2022, 11:02:59 pm
content: Quote from: rstofer on March 31, 2022, 09:15:15 pmIt works for MIPS (PIC32) too.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 31, 2022, 11:11:29 pm
content: No need to bother with interrupts. As some of us have already said, the safest bet here is to use a MCU with peripheral hardware triggers.The OP mentioned the dsPIC33E, and they do not need to look any further if that's what they are currently using. The "output compare" peripheral can be triggered from a wide variety of hardware trigger sources. See the SYNCSEL field of the control register OCxCON2.

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: April 01, 2022, 08:42:41 am
content: So much passion for interrupt latencyI love this forumI will try to answer to all.So, to be honest, I cheated. I used CCS compiler and all is done by the built in functions :The exact MCU is a dsPIC33EP512MC806Code:#INT_IC1void ic1_isr(void){output_high(OUT1);delay_us(20);output_low(OUT1);clear_interrupt(INT_IC1);}void main(){setup_capture(1, CAPTURE_RE | INTERRUPT_EVERY_CAPTURE | CAPTURE_SYSTEM_CLOCK | CAPTURE_SYNCHRONIZE | CAPTURE_TRIG_SYNC_NONE);enable_interrupts(INT_IC1);enable_interrupts(INTR_GLOBAL);set_pulldown(TRUE, PIN_E2);while(TRUE){}}This code gives me less than 600ns latency.Just by adding the keyword "fast" after the interrupt handler "INT_IC1" to use shadow register gives me around 320ns.Without interrupt handler, just by checking the interrupt flag inside the loop, I measure around 200ns but with a lot more jitter.The result are more consistant inside the Interrupt handler.I will check the ASM generated by CCS but Im not familiar with ASM.All of your posts have made me want to dig deeper than I initially wantedI will check the new dsPIC33CK.STM32H7 would have been interesting to try but there is no stock.And I will also try MPLAB and XC16, maybe the result are better.If you have any ideas about my code, I'm all ears. I'm not a software guy.Thank you very much to all of you

author: JPortici
author_rank: Super Contributor
timestamp: April 01, 2022, 09:01:21 am
content: I don't know about CCS so it's possible it's performing a full context save before in the ISR (which would be the case for XC16 as well as you are calling functions?)i don't know what "fast" does but it's possible it uses shadow registers to speed up context save/restore.If what you need to do is a fixed length pulse on an capture then you can use an output compare module and trigger it from either the input capture event of the PTGlet's say IC1 capture triggers OC1 pulseOC1CON1, OC1 Mode is "Single Compare Single-Shot mode"OC1R is set so that the pulse time is 20us (20us = OC1R / OC1CLK)OC1CON2, OCTRIG = 1OC1CON2, SYNCSEL set so that "IC1 input capture event synchronizes or triggers OC1"that should do it, no cpu interventionon the top of my head, i don't remember if in single shot mode OC1TMR is reset every time or if you have to manually reset it, but it should be clear from the diagrams in the "Output Compare with Dedicated Timer" reference manual chapter (DS70005159A)try and experiment

author: nctnico
author_rank: Super Contributor
timestamp: April 01, 2022, 09:07:15 am
content: What would be helpfull here is a dissassembler output with source code mixed in. Likely there is a whole bunch of overhead between the interrupt firing and the function being called. The code as-is doesn't really 'link' the interrupt routine to the interrupt. I assume there is much more to it.

author: DavidAlfa
author_rank: Super Contributor
timestamp: April 01, 2022, 09:41:29 am
content: Definitely, check the dissassembly, and the compiler optimizations!Try using asm to set the pin high, ex "asm("BSET LATA,1");" for RA1 pin, the rest of the interrupt is not so critical.

author: emece67
author_rank: Frequent Contributor
timestamp: April 01, 2022, 09:42:02 am
content: .

author: mino-fm
author_rank: Regular Contributor
timestamp: April 01, 2022, 03:50:53 pm
content: Using input-capture of TIM15 of STM32H723 @ 550 MHz takes 80 ns.(Sorry for bad GND connection.)void TIM15_IRQHandler(void){TIM15_IRQHandler: (+1)0x0 0xB57C PUSH {R2-R6,LR}; push some registers// volatile uint32_t temp;// GPIOB->BSRR = (SET_GPIO << KONTROLL_AUSGANG);0x2 0x....'.... LDR.W R4,??DataTable36_8;; 0x580204000x6 0x2008 MOVS R0,#+80x8 0x61A0 STR R0,[R4, #+24]; set PortB.3// if(TIM15->SR & TIM_SR_CC2IF) {Input = falling edge (yellow)Output = rising edge (blue)

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: April 01, 2022, 04:26:00 pm
content: For the specific problem (generate a pulse from a pulse), I'd be tempted to use an RP2040. This is thesecond postI've made this morning espousing their benefits. I don't work for them, honestThey have PIO blocks, which are programmable state machines running at the clock frequency (and the RP2040 can be pushedwaybeyond 133MHz), and run independent of the ARM CPU. Peoplehave implementedSPI, I2C, UART, and even dual-display DVI output (see the other post in the link). You can do quite a bit with the state-machine language, there's DMA to/from main RAM, and you can notify the ARM when there's stuff for it to do. The general-purpose GPIOs in the dual-display DVI project are toggling at 252MHz successfully...The PIO blocks are very similar to (if more limited than) the PRUs of the beagle-board, and the idea of creating software-peripherals is very similar to the XMOS concept (though again, more limited than where XMOS took it). I always found it was hard to actually get the PRUs to work on the beagle-board though. I always wanted to use the ports for other things. The lack of "other things" is actually working out as a benefit here, and the parts are very cheap

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 01, 2022, 05:37:43 pm
content: Quote from: jemangedeslolos on April 01, 2022, 08:42:41 amI did not see any passion, just a few answers that were to the point IMO.And you are not listening. Why are you not considering using a trigger for the output compare peripheral as I suggested? Is there any valid reason?Note that if the reason for having an ISR is that you're doing more upon said event than just generate a pulse, you can still do both. Set up a hardware trigger for the OC, and set up an ISR for the same source (that'll probably be INTx), and do in it whatever else needs to be done - but with a higher latency.

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: April 03, 2022, 04:53:53 pm
content: Quote from: SiliconWizard on April 01, 2022, 05:37:43 pmSiliconWizard,This was by no means a criticism.I was rather pleasantly surprised to have so many answers in such a short time.Im listening but I wanted to try all the different suggestions.I tried to replace some C lines with assembler with my two kids in the background which is a bad idea to make things work.Now I am trying to configure the output capture module but It is not working in trigger mode. I have something on the OC1 ouput in synchronize mode and double compare continuous pulse mode which is promising.I have a 20us pulse on OC1 every rising edge in IC1 ( 2Khz 50us pulse ).Code:IC1CON1.ICTSEL = 0b111;IC1CON1.ICI = 0b00;IC1CON1.ICM = 0b011;IC1CON2.ICTRIG = 1;OC1CON2.SYNCSEL = 0b10000;OC1CON2.OCTRIG = 0;OC1CON1.OCTSEL = 0b111; // Peripheral clocl as clock sourceOC1CON1.TRIGMODE = 1; // trigstat cleared in software AND when IC1RS = OC1TMROC1CON1.OCM = 0b101;OC1R = 0;OC1RS = 1410;But in trigger mode and single compare single shot mode, I have nothing on OC1 outputCode:OC1CON2.OCTRIG = 1;OC1CON1.OCM = 0b001;Do you have any idea ?

author: NorthGuy
author_rank: Super Contributor
timestamp: April 03, 2022, 08:55:04 pm
content: Quote from: jemangedeslolos on April 03, 2022, 04:53:53 pmIt would only make sense if you needed fast ISR.What pin are you checking for the OC output? Usually, you would have to assign the pin to OC using PPS.I would suggest starting from something very simple, such as a program which generates some output on OC. Then re-write it to produce a single pulse. Then link the pulse to INT1 or INT2. It's much easier to do things by little steps rather than all at once.I don't think you need IC.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: April 04, 2022, 02:09:54 am
content: Quote from: jemangedeslolos on April 01, 2022, 08:42:41 amYou do not need to be an ASM expert at all, just scanning the listing shows 'what the compiler is up to', and your "fast" keyword almost halved the delays. That sort of change will be very visible in the ASM (see comments above about register bank switch vs multiple push/pop )Keep in mind interrupts can jitter too, depending on what opcodes are running at the time (they need to complete first)If you have other interrupts running, you need to make your vital one highest priority, otherwise it is forced to wait until the first INT completes, and you will get rare-but-large jitter.If the MCU is not doing anything else, placing it into idle can often lower the jitter in the INT response delay to smallest.If absolute delay from trigger to output edge matters, you could use config logic cells, if your MCU has them, or external logic to merge the trigger and an external pin.If the trigger is always wider than the INT response time, a simple MUX can select trigger initially, (controls leading edge) then flip to a PWM or SW pin pulse, (controls trailing edge) and your MCU will behave very like a HW monostable with sub 10ns trigger to output times.

author: tggzzz
author_rank: Super Contributor
timestamp: April 04, 2022, 08:26:34 am
content: Quote from: PCB.Wiz on April 04, 2022, 02:09:54 amAgreed.Depending on the complexity of the MCU - and they can be very complex nowadays - jitter can also be introduced by instruction/data caches and hierarchy, TLB caches. Those can introduceverylarge jitter.The xCORE devices don't have caches, and a core does idle until the relevant input arrives.Engineering is about understanding limitations of tools. If one tool (e.g. an MCU) can't guarantee timing sufficiently, then you have to use another (e.g. FPGA, external hardware, specialised peripheral)

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: April 04, 2022, 09:52:23 am
content: Hello,All hardware connections are fine.I assigned RE2 for IC1 and RE4 for OC1.I already used dsPIC in the past and I know how to use peripheral pin select.I just wanted to know how much I could lower the latency inside the ISR with assembly line instead of C line to toggle pin.I get around 300ns instead of 320ns ( The measurements are not very accurate because I use a 100 MSa/s oscilloscope ).Now I would like to try the idea from SiliconWizard and JPortici but I didn't manage to get it works in trigger mode.I don't use assembler anymore, it was just for curiosity.I have something very promising in synchronize mode and double compare continuous pulse mode.As you can see, there is a continuous 20us pulse at around 1Khz on OC1 ( yellow ) AND there is a pulse synchronized with IC1 ( blue ).But in trigger and single compare single shot mode, I have nothing on OC1.just a high level or a low level depending on OC1CON1.OCM ( 0b001 or 0b010 ).There is surely a counter or a flag to reset but I don't know which one and when to do it.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 04, 2022, 10:00:27 am
content: Quote from: tggzzz on April 04, 2022, 08:26:34 amAgain, again and again;Nobody in their right mind would put the timing critical ISR in the cached instruction area - the problem isn't cache, the problem is slow memory -; they would use ITCM, (or just fast on-chip RAM) instead. Those fancy MCUs that are fancy enough to have caches, also tend to come with ITCM for obvious reasons. Instruction cache isactuallyused to speed up average runtime of non-timing critical application code in external (slow) memory (which is there because of the sheer amount of that code; large user interfaces etc). This does not affect ISR jitter in any way because you don't put those functions there.Your continued crusade and ignorance of counterarguments suggest you might have some financial motivation behind your posts, which are written like typical guerilla marketing. I have been hesitant of making that conclusion, but the repeatability of this pattern suggests that way. Do others see this or is it just me? Maybe the forum moderation should look into this?

author: MarkF
author_rank: Super Contributor
timestamp: April 04, 2022, 10:13:05 am
content: Quote from: Sal Ammoniac on March 30, 2022, 08:27:15 pmAlso the PIC32MX series with DMA.You could setup one of the DMA channels to be triggered by the interrupt and then output any sequence you want using hardware without ANY cpu interaction or ISR routine. The delay would be based on the master clock.

author: tggzzz
author_rank: Super Contributor
timestamp: April 04, 2022, 02:48:05 pm
content: Quote from: Siwastaja on April 04, 2022, 10:00:27 amThe keywords in your statements is "...tend to come...".OK, here's the first example I came across of measured ARM MCU latencies for the differing memory and cache conditions:https://www.jblopen.com/arm-cortex-a-interrupt-latency/He then improves that, but there is still noticeable jitter:https://www.jblopen.com/improving-interrupt-latency-on-the-cortex-a9/Whether that is a problem depends on the application's constraints. Clearly in the Zynq chips it would be possible - and maybe necessary or preferable - to use the PL rather than PS where latency and jitter must be defined.Apart from that, ad hominem attacks are undesirable. The most you can accurately accuse me of is being a fanboy, and of wanting to kick people out of the mindset that conventional processors are the only (and therefore best) way of achieving hard realtime performance. Measuring hard realtime latencies is a methodological sin, of course.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 04, 2022, 03:02:43 pm
content: Cortex-A is not a microcontroller core. It's an application CPU, and very commonly code is ran out of DRAM (with large random-access latency). Does not relate to microcontrollers; so completely apples-to-oranges comparison. One of the defining factors of what microcontroller is, is the ability of timing critical control with low latency and low jitter, compared to application CPUs. Hence simplicity and lack of caches, or in more complex MCUs like Cortex-M7, addition of core-coupled memories.Now I understand completely where your strawman is coming from. You mix application CPUs and microcontrollers up.I'm not "attacking" ad hominem. I'm truly suspecting based on your behavior, and I think with good reasons. I might be wrong, though, in which case I'm sorry. On the other hand, I hope I'm right, because your continued mispresentation of facts, which seems to be on purpose, is detrimental to the discussion. I hope it at least does good on your wallet, then there would be at least one winner in this stupid reoccurring game - yourself.Interestingly, you reply to threads that talk about "MCU"s, write "MCU" yourself, but somehow, suddenly, it has been changed to "conventional processors".Nobody outside of your strawman is using Pentium or Cortex-A9 for nearly cycle-accurate hard realtime applications, or ever suggested doing that. We usemicrocontrollers, such as Cortex-M7. Caches do not affect the ISR jitter, because ISRs where this matters are not in cacheable (slow) memory. This is a fact.I want to call BS out in a well-mannered way, but continued ignorance of the arguments for years leads to certain conclusions being made. You are supplying the same completely wrong information repeatedly, and it seems this behavior can't be corrected by rational argumentation (i.e., supplying the correct information), which has been attempted by me and many others, time after time. You continue to present the same old strawman, made up by calling not-a-microcontroller a microcontroller, and pretending this strawman has any relevance to real life.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 04, 2022, 03:29:23 pm
content: Quote from: jemangedeslolos on April 04, 2022, 09:52:23 amPost the disassembly of your INT ISR code.Quote from: jemangedeslolos on April 04, 2022, 09:52:23 amVery well. Now switch to the trigger mode (OCTRIG = 1) and create an interrupt which clears the TRIGSTAT bit after the pulse is produced.

author: tggzzz
author_rank: Super Contributor
timestamp: April 04, 2022, 04:32:00 pm
content: Quote from: Siwastaja on April 04, 2022, 03:02:43 pmThe problem is that devices - whatever you call them - are becoming ever more capable and complex, at rapidly decreasing cost. The consequence is that nothing is black and white (it is shades of gray), the boundaries are becoming increasingly blurred, and there is no simple distinction that can be made.From that point of view, the key distinction is the definition of various terms - and neither of us has made our definition explicit.To me an MCU is a single chip computer, embedded within a system and not acting as a fully-fledged general purpose computer. The Zynq devices are used like that, e.g. in the Red Pitaya oscilloscope (and other embedded systems and, I believe, other scopes). Hence to me they constitute an MCU, albeit a very powerful one. They are also capable of much more.Similarly Z80s and their more integrated modern variants are also MCUs - but they are/were also general-purpose computers running general purpose operating systems. In my case I used Z80a+CP/M for cross-compiling C for an embedded Z80.Now if you use MCU to mean something without caches or where caches can be disabled, that'sone othervalid definition of the term. But only one other.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: April 04, 2022, 05:15:02 pm
content: Quote from: tggzzz on April 04, 2022, 04:32:00 pmI think this is a fair point. I think there is a 'crossover' market right now, but I don't think it really changes the definitions.Quote from: tggzzz on April 04, 2022, 04:32:00 pmWhat you're describing sounds more like a SOC to me. A Zynq can be used as a 'microcontroller' to talk to the PL, but it's a stretch. There's too much associated with a Zynq that is more APU-like (DDR ram with its vagaries, for example) although you certainly can try and use it as an MCU, I don't think that's it's real purpose - it's aimed somewhat higher IMHO. SOCs can range from something like the Zynq, or embedded IP on and FPGA, all the way up to the Apple M1, although that doesn't really fit into your 'not acting as a fully-fledged general purpose computer' clause.If you look at how ST do it, they have their MP1 which has an MCU in it (Cortex M4) but it also has APU's (Cortex A7's) - I'd say the M4 was the MCU, and the A7's were not. The reason they include the M4 is basically the laundry list already discussed, where a predictable and deterministic device is required. The reason they include the A7's is for general-purpose computing and speed, but with determinism trade-offs. Anything 'A'-designated (including the Zynq) isn't really an MCU, at least IMHO.I'd say the RP2040 was an MCU, I'd say the R-Pi was not. I'd say the PIC range, anything ARM-M-designated were MCU's, as are the XMOS chips. I'd say the SiFive SOCs (eg: U540) were not.IMHO it's pretty simple: determinism is the defining factor of an MCU. If I know I can guarantee it'll take X clocks to service my interrupt under <condition> and I can set up my code to be in <condition>, then it's a microcontroller. If there's even a chance that this can't be done, it's not.Shrug. I guess YMMV, but that's my $0.02.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 04, 2022, 05:15:54 pm
content: Quote from: jemangedeslolos on April 03, 2022, 04:53:53 pmI haven't use dSPICs for a few years, so I'll have to dig a little deeper.One first remark: you are apparently trying to trigger OC1 from IC1? Are you sure IC1 is properly configured to begin with?

author: tggzzz
author_rank: Super Contributor
timestamp: April 04, 2022, 05:44:32 pm
content: Quote from: SpacedCowboy on April 04, 2022, 05:15:02 pmAnd there's another term, SoC, that is ill-definedHaving the A9-ARM(s) operatingveryclosely with the PL is standard usage. The design tools and examples clearly indicate that is the intention.One way of using them is to have a linux running on one core, and and RTOS (or simpler) on the other core.Overall it is a fascinating, if unsurprising, development, and Xilinx appear to have executed it well.QuoteI'm not going to disagree, but I'll note that the mere existence of the various ranges of ARM cores indicates that everything is grey.QuoteThat's internally consistent, but it begs the question of what degree of determinism is required.To me an interesting system-level design decision is what to put in hardware and what in software. That needs understanding of the boundaries and how the boundaries are changing. Andthatmeans most distinctions between most processors is knowledge with a very short half-life. OTOH, being able to recognise the fundamental differences - and lack of them - will stand the test of time.I think I'll propose a rule-of-thumb. When comparing devices, the more letters/digits you have to use, the less interesting the distinctions become

author: hans
author_rank: Super Contributor
timestamp: April 04, 2022, 06:06:09 pm
content: Quote from: tggzzz on April 04, 2022, 04:32:00 pmI think the presence of caches is a BS indicator of MCU or MPU class, or embedded or application cores. Caches are a side effect of another design decision. For example, FLASH accelerators are commonly used in modern MCUs, but are also notorious in worst-case execution time prediction (upper bound of jitter), since they are effectively also caches. E.g. they may read a FLASH line size of 128-bit, and make it available in larger chunks for the I bus. This is fine for sequential access, but on random access (jumps) it will incur a small delay (wait state).To make an accurate WCET prediction is hard. Another way is to assume cache miss always occurs.Is SOC an accurate term? I doubt it. I think that's more for a CPU with integrated peripherals that are secondary to running code, for example, on board USB, ethernet, etc.Rather I think that the focus on running code from internal or external memory,only, optionally or primarily, is a decent indicator. Some MCU/MPUs are getting into a 'crossover' region, e.g. a Cortex-m7 at 0.5GHz+ will run circles around desktop PCs from 25 years ago.Running code from external ICs relies completely on caches to 'fix' performance. The external memory device is too slow, and we want to go faster. Likewise, modern PCs are also outright slow if you were to turn off speculative execution, even though it has caused many security problems in the last few years. We would be right back on MCU-level performance/MHz if we did. Many Cortex-A core variants distinguish themselves from MCUs by presence of these features, similar to out of order execution and superscalar designs. Out-of-order execution typically uses register renaming, e.g. the register file is L1, instead of a bunch of flipflops. These are quite clear design differences that application processors unique from microcontrollers, and also by design/choice not very suitable for hard real-time systems with bounded system/interrupt latencies.However, superscalar execution has just entered the Cortex-m7, and probably to come is the speculative and/or out-of-order execution so the 'crossover' region will blur even more in the future.... more shades of gray.

author: tggzzz
author_rank: Super Contributor
timestamp: April 04, 2022, 07:00:28 pm
content: To concentrate on a couple of your points...Quote from: hans on April 04, 2022, 06:06:09 pmWithout the right architectural features, that is extremely difficult to predict. In practice people fall back on measuring and hoping they come across the WET. Or doing it in hardware.QuoteI didn't realise that, but it is just another example on why it it beneficial to concentrate on the fundamental basic features, and not to become obsessive about somewhat arbitrary names.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 04, 2022, 08:03:18 pm
content: The days when microcontrollers were 100% predictable timing-wise when executing code (and in a humanly-approachable way) are over, except for the vintage stuff and a very few exceptions.Now, you can usually determine upper bounds for all timings, but even that can be tricky on modern MCUs, and the upper bounds you're going to determine are likely to leave you unimpressed. But if that meets your timing requirements, then that will be the way to go. For anything interrupt-based, you'll likely be in the order of the us on even a fast MCU (but the faster it is, and often the more complex the architecture, so it becomes difficult to get below that threshold.) That's often more than good enough for real-time "tasks", as long as you're not trying to use your MCU as an FPGA.But that's the reason why many MCUs these days come with hardware triggering, flexIO stuff, etc. That can fill the gap, because most often, when you need really very low latency, whatever needs to be done is pretty low-level.I used cycle-counting per instruction on 8-bit PIC MCUs (and then again, also actually on old CPUs like Z80, 8086, ...). I never did that on anything Cortex-based. It's certainly not what defines "MCUs" these days.

author: tggzzz
author_rank: Super Contributor
timestamp: April 04, 2022, 08:32:45 pm
content: Quote from: SiliconWizard on April 04, 2022, 08:03:18 pmYes, and beginners don't know the exceptions, nor why they are exceptions.QuoteHow? More specifically, how do you know your max figure is the upper bound.QuoteExactlyBeginners often don't realise the difference between mean and max.QuoteDefinitelyQuoteKnowing when and why hardware is required is an essential skill. Ditto understanding the wide difference between mean and max.Hand cycle counting always was a pain, even when practical.

author: hans
author_rank: Super Contributor
timestamp: April 05, 2022, 08:17:20 am
content: You can very easily estimate a theoretical upper bound for the worst-case execution time for a system. Just assume nothing works. The pipeline gets flushed for each instruction: so a 3-stage CPU only executes 1 opcode per 3 cycles. All caches miss: each memory access has the maximum penalty for that specific memory. etc. You will get an upper bound that is no where close to reality, but it's a theoretical 'correct' value for your assumptions.But when theory needs to meet practice, are the assumptions realistic? The challenge then becomes to find atightupper bound, that is valid when you do introduce the design concepts like a pipelined CPU. This still has no relationship at all to the mean execution time of a routine. Mean is only a fun figure to have if you want to design a desktop program with a certain throughput aim. It's pretty much useless in the embedded space. After all, if we design a power supply to withstand certain limits, we are only interested in the min/max so it doesn't release the magic smoke. "Typical" values as an absolute maximum make as much sense as saying something is more optimal.Measuring WCETs is to some degree valid to use (however, often with a large safety margin added on top, resulting in a non-tight bound).. but also remember that such a measurement is only worth as much as the stimuli that were applied during test. You can't expect that repeating the exact same experiment will at some point yield a different result. If that happened, then some stimuli must have changed. For extreme example, if you never tested the WCET while a nuclear bomb goes off at distance=xm away, then perhaps you don't have the WCET for all operation conditions for that system (unless the system can go down in the apocalypse, then you can abandon this test).Perhaps you can see why computer science classifies algorithms and problems into things like P, NP and NP hard. Sometimes you can know that a valid solution to a math problem exists, but finding that solution takes an extremely long time to do so. Finding a more relaxed solution (a less tight upper bound) is then the more practical thing to do.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 05, 2022, 08:19:13 am
content: Interrupt latency on Cortex-M7 at 400MHz is 30ns, and this includes automatic stacking of registers and fetching the vector address. With code in ITCM, the source for jitter is due to logic synchronization - something that can't be avoided. Let's call it 1 clock cycle. So average 30ns with 2.5 ns of jitter. Given easy-to-use interrupt priority system, heck, you can just make use of the interrupts without blinking an eye! Not having ITCM/DTCM available and sharing the RAM with heavy DMA transfers? Just assume 100% DMA utilization. Bus arbiter gives half of the cycles for CPU, so assume each load/store takes double the time. It's still blazing fast. So you have an if(condition) at the start in that critical ISR? So OK, it might run a clock cycle or two faster on the second invocation. So your jitter is now up by 5ns! There is no magical way branch prediction would sometimes make it take longer than it takes on the first round, or cause a large difference. It's very fast even with the miss, and the miss isn't some super special occurrence, you will see it on the scope screen the first time you try it.Now let's compare these numbers to the "simple" "good" old systems. Polling loop on a simple 8-bit AVR at 8MHz, which alternates IO reads and comparison and branch instructions, would be something like 5 clock cycles in length, with maybe 3 clock cycles of jitter, plus 1 unavoidable cycle from synchronization. So something like average ~400ns with another 400ns of jitter. As you can see, I had hard time coming up with exact jitter number, so it's not easy to analyze. You thought you could write "cycle-accurate" code easily on a simple instruction set with predictable instruction timing, but in reality you didn't, because you still had to interface with the external world. And this applies to any xCORE as well. It can't magically predict when the external signal comes in.Simple isn't always better. Identify what you really need. This sounds obvious, but if you need fast, then fast is fast. And MICROCONTROLLER cores, when compared to APPLICATION cores, offer fast worst-case. They do it by having on-chip SRAM, and higher end ones partitioning the RAM in multiple interfaces, some only accessible by CPU (with predictable exact 1-cycle latency). This is all blatantly obvious to everybody except guerilla marketing shills. Some uncertainty comes from the fact that Cortex-M7 is sometimeseven fasterby having branch prediction. The result is very fast worst case, and a tad better average case, with a few clock cycles of jitter. This is a big deal only if you really need to bit-bang an interfaceactuallyaccurate toa few nanoseconds. Which is extremely rare, given the sheer performance, which let's you do the job much easier, if you can accept say 10-20ns of uncertainty. Which you easily should be able to do if you were happy with the 8-bitters. Their synchronization jitter alone was in the same order!Theactualreason we don't almost ever count individual cycles (I have done it once in a project, and it's fully possible!) on modern high-end microcontrollers isnotthe difficulty of doing so, but the fact there isno need. When the complexity went up, so did the performance. If average case went up by 20x, then worst case possibly went up by 10x. Gone are the days of having to resort to counting instruction cycles to bitbang an interface; because interrupt entry now only takes equivalent to what 0.5 clock cycles was on AVR/PIC, now you can just make a timer generate interrupts and bitbang the protocol there, and let everything else run in parallel. Oh the joy of programming it.And the differentiating factor with Cortex-Arunning linux, and Cortex-Mrunning bare metal, is exactly the predictability of worst case timing. Claims about caches being relevant at all are made-up BS arguments shown wrong countless of times. Small sources of jitter do exist (M7 branch prediction; DMA and CPU arbitrating RAM access; clock domain synchronization), but these are all just a few clock cycles, easily understood and dealt with. Most importantly, even if you don't understand every detail, the amount of uncertainty is still so small it's trivially totally swamped by very modest safety margin.Compared to this, what isreallyslowing beginner's attempts to write timing-predictable down are overly complex software libraries and layers. Needless to say, for tight control of timing, you need to be in control of the code. And there is no limit how slow and bloated it can get. A perfect example which demonstrates this hasnothingto do with MCUs getting more complex, buteverythingto do with software writing practices becoming bloated, is the horribly slow timing of Arduino's DigitalWrite() and the friends. You can totally have slow and uncertain timing by using bloated libraries, even on the simple and "predictable" MCUs.

author: tggzzz
author_rank: Super Contributor
timestamp: April 05, 2022, 08:43:50 am
content: Ignoring many valid points to concentrate on one...Quote from: hans on April 05, 2022, 08:17:20 amAs someone that is a strong advocate of processors that guarantee hard realtime operation, I'll make a contrary point from my own experience.There are many applications which are soft realtime, i.e. where a deadline can be passed without it being a failure, provided that statistical guarantees are met. One example of that is the telephone system and parts of the telephone system. Consider a cost control PAYG application where a call should be terminated when the subscriber's credit falls to zero. Those are specified in terms of mean latencies, although I would prefer 95th percentile latencies.Now is that an embedded system? Is depends on the scale at which you are looking. The computer is a small part of a large system, and is dedicated to a single function; it is not acting as a general purpose computer. From that angle, it is an embedded systemIf you want others, consider the processor in a router. That's probably running a cut down linux, which can't (and doesn't need to) offer hard real time guarantees. Is it embedded?

author: T3sl4co1l
author_rank: Super Contributor
timestamp: April 05, 2022, 10:09:22 am
content: Quote from: tggzzz on April 05, 2022, 08:43:50 amAlso a good illustration of hardware support, whether lightweight or heavy; many have some variety of hardware accelerator to switch packets automatically, handling the busywork that doesn't involve actually thinking about routing, or deep packet inspection, etc.. So the propagation delays can be quite stable indeed in the average case, with occasional bumps to some ~ms if the CPU has to think about something. Every little bit adds up of course, but there's only a couple dozen routers between most nodes on the internet, so a few ms each is tolerable compared to physical delay.Tim

author: tggzzz
author_rank: Super Contributor
timestamp: April 05, 2022, 12:09:31 pm
content: Quote from: T3sl4co1l on April 05, 2022, 10:09:22 amTrue.There are other ways to minimise mean latency, when that is critical. The FinTech mob go to the lengths of coding everything - up to and including business trading rules - in FPGAs. Microseconds matter in the high frequency trading world.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: April 05, 2022, 02:26:41 pm
content: *shrug* clock-cycle counting is indeed a thing. Whether it’s *your* thing is a different matter.As part of a project, I wanted to provide ‘memory apertures’ on an old Atari XL/XE external bus, so by writing to register-space in the ‘external ROM’ area of the memory map, I could configure an offset and length (number of 256-byte pages) where memory i/o would be directed to external DRAM instead of internal RAM. Throw 64MB of RAM on the back, have several (8 in this case) of these memory apertures and there’s a few fun tricks you can play.Ok, scene set: now the Atari line had two signals that need to be asserted to handle external memory (/MPD and /EXTSEL), these act as signals to turn off access to the system RAM, leaving the external RAM to work unimpeded. They were supposed to be implemented in hardware logic plugged into the back of the machine, so from the point where the address is valid on the bus, to the point where they are asserted low if needed, you have ~40ns within the bus-cycle according to the timing diagrams. In my case this part of the system had to- read the address off the bus- compare with the memory ranges that indicate external access- assert signals if requiredAll in a hard time budget of 40ns. Has to work every single time or you have memory-access failure. Oh, and since these are old boxes, you also need to take into account any delays for level-changing. Nanoseconds count.Micro-controllers would be easier, so I looked at the STM32 (just about possible with polling), I looked at XMOS, the RP2040 with its PIO didn’t really have enough pins. Considered the beagle-bone with its PRUs, but in the end went with an FPGA. A few tens of ns more and I’d have gone with a microcontroller. Anything running Linux wasn’t in contention. Anything that couldn’t guarantee a response latency, even if the CPU was doing something critical, wasn’t an option.And for the record, I wanted the CPU to do more than just provide memory - this was an expansion slots system, and it had its own things to worry about. Going with polling meant extra complexity when managing the rest of the tasks I wanted the system to do. The timing was a lot more relaxed past that critical 40ns period, but it *had* to get that right.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: April 05, 2022, 03:43:03 pm
content: I guess it's kind of interesting that, as simple as parallel buses are, and as powerful as MCUs get -- doing the one with the other, is still one of the most difficult tasks for them to perform.I suppose that kind of goes all the way up to the root of computing, and what it means: to be able to computeanything, infinitetime -- that is, to do it at all, not also within a given time constraint! MCUs break up complex operations into simpler bits repeated (and varied) many times over: the complexity is broken up over time, so that the hardware (instant-to-instant computation) can be simpler. So, it's difficult to do much of anything in more than a handful of clock cycles, when that's the case. At least without very specially written instructions (like the absolute diversity of extensions, SIMD and whatnot, available on the most advanced CPUs) -- or support hardware.Whereas combinatorial logic, can potentially be very flat and wide, but is a pain to do much of anything with -- it must be configured, or built that way from scratch, and then can only do that one narrow thing (or a few related things, given a bit more flexibility in the logic design).And, it also speaks to the purpose of such things. MCUs are very egoist, they aren't made to cooperate with other CPUs (or DMAs or other multi-master things) on a single shared bus, they're made to stand alone and do their one thing very well. And acting as a parallel bus receiver isn't one of them, heh. And other than that, if you need more power, just get a better one, don't waste time trying to communicate between many. Whereas the CPUs of old, were often made that way, including parallel bus interface logic right on the chip obviously, but also not being hard to use on a multi-master bus, or multi-CPU system, etc..So, being able to pull off such a function, with an MCU, is certainly a testament to its raw speed.Tim

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: April 05, 2022, 03:57:55 pm
content: Quote from: NorthGuy on April 04, 2022, 03:29:23 pmQuote from: SiliconWizard on April 04, 2022, 05:15:54 pmHello,I just want to take my biggest hammer, and hit as hard as I can on my board ( with my head between them )I tried to set a flag in the IC1 interrupt handler, and then clear OC1CON2.TRIGSTAT in the main loop but it didn't work.I tried to clear OC1CON2.TRIGSTAT inside the isr, but it didn't work either.In the datasheet, TRIGSTAT is cleared when IC1RS = OC1TMR if TRIGMODE = 1 so Im not sure if I have to do this.( But with TRIGMODE = 0, I have no more success ).Im not 100% sure because it didn't work but I assume IC1 is configured correctly.If I toggle a pin inside the IC1 handler, I have a pulse synced to the waveform generator on the rising edge.And in synchronized mode, there is a pulse on OC1 synced to IC1.In trigger and single shot mode OC1 interrupt fires only once.inside the isr or inside the main loop, if I setup again OC1CON1.OCM = 0b010, it changes nothing.In synchronize mode, OC1 interrupt fires every falling edge on the OC1 pin so it is working as expect in this mode.I must forget something but I don't know what and I can't find anything in the datasheet or in the reference manual.It's a shame because in synchronized mode I only have around 80ns between IC1 and OC1 rising edges.If you have any ideas it is very welcome

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 05, 2022, 06:10:43 pm
content: In the end, I'm not completely sure what you have tried here. In trigger mode, have you gotten anything on the OC output pin? Nothing? Or a pulse just once and never again?To move forward, I would suggest setting the trigger source as INT1 or INT2 and try that first. (But you need to have access to one of the corresponding pins.)

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 05, 2022, 09:20:36 pm
content: Quote from: SpacedCowboy on April 05, 2022, 02:26:41 pmIt's probably not a thing with most embedded systems, which don't need that level of performance. The vast majority of MCUs are used in devices that either spend most of their time waiting around for user input, or control slowly changing systems.Some people have a distorted idea of how fast an embedded system needs to respond to external events. Sure, there are cases where it really does matter, but those aren't typical. And we're lulled by the vast amount of resources (CPU, RAM, flash) we have now compared to what we had in the past. When I started doing embedded decades ago, we had microprocessors running at just a few MHz and just a few KB of RAM and EPROM, yet we were able to do a lot even with those restrictions. Contrast that to the several hundred MHz, 64-256 KB or RAM, and a MB or two of flash we have in MCUs today. And if a fast MCU can't handle it, we have the option of using an FPGA or an ASIC.Another historical comparison: the Apollo guidance computer used on the moon landing missions. This was certainly an embedded application, and it controlled a spacecraft hurtling towards the moon at thousands of MPH in real-time with little input from the astronauts. The AGC ran at perhaps 1 MHz and had 2K words of RAM and 36K of fixed storage, and most of the guidance and autopilot code was written in an interpreted language that ran even slower than native code. Cycle times were measured inmilliseconds, notnanoseconds, yet the whole thing worked fine for its intended purpose. It was able to do this because even with a 100 millisecond control loop it was able to maintain control of the vehicle. Even if they had a modern MCU back then, they probably wouldn't have run the control loop any faster (because it wasn't necessary).

author: uer166
author_rank: Super Contributor
timestamp: April 05, 2022, 10:03:52 pm
content: Quote from: Sal Ammoniac on April 05, 2022, 09:20:36 pmNot only that, but everywhere where itdidmatter (i.e. integrating accelerometers and reading gyros), was done using hardware counters. Just like today, if you need some special ultra-fast response time in a current mode controller, you'd use a dedicated peripheral, and not try to shoehorn general purpose computing at it by default. Nothing has fundamentally changed in the last 50 years, and I don't understand people pushing for Xcore or whatever newfangled thing comes up. The AGC wasn't even realtime in a sense that it had a large number of peripherals stealing bus cycles, so the control code execution had variable timing, and was done at a 1 second cadence.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 05, 2022, 10:14:46 pm
content: Quote from: jemangedeslolos on April 05, 2022, 03:57:55 pmIf you do things methodically, with little steps, the hummer may not be needed.You already have the synchronization working as you have shown on your screenshot. Hang on to that. Now you only need to switch to trigger mode. So, keepeverythingin the setup you already have and make only one change - switch to the trigger mode (OCTRIG = 1). Once you do this, the input pulse will reset and trigger the timer and it will continue to run as is. Further pulses will not affect the timer. So, when you start it, there will be no signal at first, but once you get even a single pulse, the signal should appear and should generate pulses forever. Did you get to this point?

author: NorthGuy
author_rank: Super Contributor
timestamp: April 05, 2022, 10:21:48 pm
content: Quote from: Siwastaja on April 05, 2022, 08:19:13 amAre these theoretical, or have you tried this in the real world? If theoretical, I suggest you try to measure the reaction time and jitter and post the results. It'll be interesting to see.

author: nctnico
author_rank: Super Contributor
timestamp: April 05, 2022, 11:01:28 pm
content: Quote from: Sal Ammoniac on April 05, 2022, 09:20:36 pmI fully agree! And often it is a much better idea to let hardware deal with critical timing instead of trying to shoehorn that into software. Especially when you take into consideration that a lot of embedded code runs many parallel tasks nowadays.QuoteThat is an excellent example!I have another one: some people loath the use of soft floating point. In one of my more recent projects I used just that from within an interrupt that needs to update a realtime process with similar cycle times and more than enough processing power to spare. Hardware took care of doing time critical stuff like updating the DAC at precise intervals. If a solution serves it's purpose, it is good. Job done.

author: tggzzz
author_rank: Super Contributor
timestamp: April 05, 2022, 11:42:53 pm
content: Quote from: Sal Ammoniac on April 05, 2022, 09:20:36 pmEr, not quite.You should look up "program alarm 1202".Good defensive system design saved the day; the 25 year old controllers made the right call to ignore that alarm.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: April 06, 2022, 12:26:21 am
content: Just to be clear here, I thought my first line "Whether it’s *your* thing is a different matter" was indicative, but ...I'm not saying that all microcontrollers ought to be used in this way, my point was that it's a valid use-case for them. If something is predictable and has sufficiently deterministic latency to provide a solution, then it's a candidate - in my book at least. There may be *better* candidates, and if so, choose that. Sometimes the criterion is price, and specialist hardware doesn't win out over general purpose software....In my case, the microcontroller was *almost* there, and would have been cheaper if it was. The FPGA needs more support chips for level-changers (non-H STMs are 5v-tolerant) and need reset-supervisors, multiple sequenced voltage rails etc., and availability meant a BGA part, which is more expensive in manufacturing and more complex to design for.It's good to have choices.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 06, 2022, 05:58:25 am
content: Quote from: NorthGuy on April 05, 2022, 10:21:48 pmGood thing about theory is that it matches with reality. Otherwise, theory is faulty.ARM Cortex-M7 interrupt latency is guaranteed by ARM, by design. There is no need for me to test it.But the thing is, we are not discussing any full real-world problem here, just limiting us to the CPU. In reality, we need inputs and outputs, and their synchronization to whatever clock domains (and across clock domains) will be a source for delay and jitter. But this applies to any design. It would not be trivial to write a custom FPGA processing core which could run at 400MHz, for example, either.This is also what makes the claim of "jitterless" and "predictable" xCORE funny. It is limited by the exact same mechanism as all other MCUs and even FPGAs: the nature of synchronous digital logic and its synchronization requirements. The jitter is in the same order of magnitude as on an ARM CPU.

author: tggzzz
author_rank: Super Contributor
timestamp: April 06, 2022, 07:28:20 am
content: Quote from: Siwastaja on April 06, 2022, 05:58:25 amSomeARM cpus, not others. Some programs running on ARMs, not others.Do any of the ARM toolchains state how long it takes for the program to get from this instruction to that instruction?Of course there is irreduceable jitter related to the clock period and clock jitter. I didn't think that needed to be stated explicitly.

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: April 06, 2022, 09:16:42 am
content: Quote from: SiliconWizard on April 05, 2022, 06:10:43 pmHello, I will try with INT1 instead of IC1. As this MCU has peripheral pin select, I can assign INTx to almost any pinQuote from: NorthGuy on April 05, 2022, 10:14:46 pmHello,If I only switch OCTRIG to 1 ( and keep OC1CON1.OCM to 0b101 ), I have nothing on OC1 ( high level ) until I enable pulse in the IC1 pin.And then, I have continuous 20us pulses on OC1 just like you saidWith OCTRIG = 1 and OC1CON1.OCM = 0b010, I have nothing on OC1 ( low level ) with or without pulse in the IC1 pin.OC1 interrupt fires only one time and never fires again. It is the same with OC1CON1.TRIGMODE = 0 or OC1CON1.TRIGMODE = 1In both cases I tried to reset OC1CON2.TRIGSTAT flag inside the OC1_isr but without any success

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: April 06, 2022, 02:33:34 pm
content: Hello again,I have the exact same result with INT1 ( external interrupt 1 ) instead of IC1 ( input capture 1 ).With OC1CON2.OCTRIG = 0, the results are as expected but I can't get it working with OC1CON2.OCTRIG = 1.OC1 interrupt fires only one time and never fires again.The interesting thing is that the latency is lower with external interrupt. I measure only around 50ns between input and output rising edges instead of 80ns with input capture.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 06, 2022, 05:05:05 pm
content: Quote from: Siwastaja on April 06, 2022, 05:58:25 amWell, there's some time needed to sync and route the external signal to ARM. And then there will be some slowing down due to execution from non-cached memory. And there's further delays with getting the signal out of the CPU and syncing it to the output flops/latches. Because of the above considerations, the reality will also depend on the vendor, not only ARM. Your theory doesn't take any account of these factors, so it is clear that the theory is faulty.Of course, if you're not interested in reality, there's no need to test.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 06, 2022, 05:15:31 pm
content: Code:[quote author=jemangedeslolos link=topic=318628.msg4104136#msg4104136 date=1649255614]I have the exact same result with INT1 ( external interrupt 1 ) instead of IC1 ( input capture 1 ).With OC1CON2.OCTRIG = 0, the results are as expected but I can get it working with OC1CON2.OCTRIG = 1.OC1 interrupt fires only ont time and never fires again.What happens when you set OCTRIG = 1 without changing anything else?What do you do in your OC1 ISR?Quote from: jemangedeslolos on April 06, 2022, 02:33:34 pmIC needs to capture the timer and store the result in the IC buffer. Only after the result is saved, it signals the interrupt. INT generates the interrupt request right away. Some chips have hard-wired dedicated INT pins (as opposed to PPS'ed ones) which are even faster because they remove the PPS delay.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 06, 2022, 08:40:57 pm
content: Quote from: tggzzz on April 05, 2022, 11:42:53 pmI'm not sure what you're implying by your comment "er, not quite"... Not quite what? The fact that the computer gracefully handled the problem? That has nothing to do with the fact that the computer was primitive, slow, and lacking in memory by modern standards, yet still got the job done.I don't need to look up program alarm 1202. I'm very familiar with the architecture of the AGC hardware and software and know exactly what it means.Specifically, for those interested, a 1202 program alarm occurs because the software used "core sets", 12-word chunks of erasable memory used by the executive to manage jobs (analogous to a task control block in a modern RTOS). The LM AGC code only had eight core sets available, and if the executive tried to start a new job and no core sets were available, it generated a 1202 program alarm. The similar 1201 program alarm was caused by no available VAC (vector accumulator) areas when creating an interpretive job. Both the 1201 and 1202 alarms were due to jobs not being able to complete because something was "stealing" time.This "time stealing" turned out to be coming from the rendezvous radar. The rendezvous radar is not using during a landing, but Aldrin turned it on anyway just in case they had to abort and navigate back to the CSM in orbit. The rendezvous radar had two axes of movement and each axis had a resolver feeding a CDU (coupling data unit--essentially an analog-to-digital converter). The CDU read the analog signals from the resolvers and converted them into digital pulses it fed to the AGC. When a pulse occurred, the AGC hardware incremented or decremented a counter by stealing a cycle from the CPU. The problem was an oversight--the rendezvous radar used a different 800 Hz reference oscillator than the computer, and the two where out of phase, and this caused a pulse storm of spurious pulses to the AGC. Each spurious pulse stole a CPU memory cycle of ~12 microseconds and this placed about a 15% extra load on the CPU, which caused the overload, and the program alarms.As you mentioned, the designers had put (at the insistence of NASA) restart code into the software that would cause a soft reset and shed any low priority jobs (like updating the DSKY, which is why it blanked out for ten seconds during all this) while retaining all the important stuff, like the digital autopilot. Restarts happened so quickly that Armstrong didn't even notice any change in the handling of the LM (because all the important stuff was still running).BTW, if anyone is interested in reading the AGC source code, you can find it here:https://github.com/chrislgarry/Apollo-11"Luminary" is the code running on the Apollo 11 LM computer.

author: tggzzz
author_rank: Super Contributor
timestamp: April 06, 2022, 09:21:10 pm
content: Running out of available processing power and having to abort processing indicates that it didn't "work fine". The pilots and ground control were distracted at a critical time. Fortunately good defensive system design saved the day.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 06, 2022, 09:39:40 pm
content: Quote from: tggzzz on April 06, 2022, 09:21:10 pmIt would be analogous to a modern embedded system connected to an external peripheral with an interrupt input to the CPU that kept firing continuously and preventing the CPU from doing anything other than servicing the interrupt. You'd have to say that system wasn't "working fine" either.You'd hope issues like this would have been caught in ground testing, but that didn't happen.

author: tggzzz
author_rank: Super Contributor
timestamp: April 06, 2022, 10:14:15 pm
content: Analogies are usually dangerous, since they encourage over thinking the analogy, not the real issue.It didn't work fine; it coped - just.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 06, 2022, 11:07:48 pm
content: Quote from: tggzzz on April 06, 2022, 10:14:15 pmAh, so any embedded systems that use error recovery code to recover from problems don't work fine, they "just cope". Got it.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: April 07, 2022, 03:01:06 am
content: Quote from: jemangedeslolos on April 06, 2022, 02:33:34 pmDid you check for edge filter options in input capture ?- but you are right, it would be rare for a SW path, to be faster than a configured HW path.Also keep in mind "latency is lower with external interrupt" is highly dependent on what the MCU is doing at the time of interrupt.An idling MCU would expected to respond the fastest, whilst a MCU executing one of the slower opcodes, has to complete that first, & a MCU in another interrupt has to complete that, unless your event INT has highest priority.(in that case, you added jitter and latency to the over-ruled interrupt)

author: NorthGuy
author_rank: Super Contributor
timestamp: April 07, 2022, 03:36:46 am
content: Quote from: PCB.Wiz on April 07, 2022, 03:01:06 amThis is not a real interrupt - just a signal which triggers the other peripheral - this happens independently of the MCU.However, if it was the interrupt, with this MCU the latency would be the same every time. Actually, the MCU has a setting for that. You can chose constant latency (default) or you can chose faster, but variable latency.

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: April 07, 2022, 07:26:01 am
content: Quote from: NorthGuy on April 06, 2022, 05:15:31 pmOh sorry I made a typo, I meant "I can'tget it working with OC1CON2.OCTRIG = 1"So with OC1CON2.OCTRIG = 1 and OC1CON1.OCM = 0b101, I have continuous 20us pulse on OC1Don't look at noise and crosstalk on channel 1, I'm using a Digilent Analog Discovery 2 without shielded probe :And with OC1CON2.OCTRIG = 1 and OC1CON1.OCM = 0b010, OC1 interrupt fires only one time and never fires again.TRIGMODE setting change nothing to the story and Im doing almost nothing inside the OC1 interrypt handler :Code:#INT_OC1void oc1_isr(void){//delay_cycles(16);//output_high(OUT1);//delay_us(1);//output_low(OUT1);//OC1CON2.TRIGSTAT = 0;//OC1TMR = 0;//OC1CON1.OCM = 0b010;OC1IT_Flag = TRUE;IFS0.OC1IF = 0;}I left a few lines of commented code that I tested but that does not change anything either.

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: April 07, 2022, 07:35:49 am
content: And to be very clear, without changing anything else, here is a screenshot with OC1CON2.OCTRIG = 1 and OC1CON1.OCM = 0b101The input pulse on IC1 is 500Hz 10% :And with input pulse > OC1 period ( 2kHz 10% ) :

author: tggzzz
author_rank: Super Contributor
timestamp: April 07, 2022, 07:39:06 am
content: Quote from: Sal Ammoniac on April 06, 2022, 11:07:48 pmNo, any embedded system thatrepeatedly invokeserror recovery - especially in a critical situation - isn't working fine. If it is a timing problem then it is just coping.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: April 07, 2022, 12:56:25 pm
content: Quote from: tggzzz on April 07, 2022, 07:39:06 amWow, that's crazy! TIL literally every WiFi radio ever -- really, any networking device at all, CD player, hard drive, etc. literally can't work fine, in addition to "just coping"!Tim

author: tggzzz
author_rank: Super Contributor
timestamp: April 07, 2022, 01:17:11 pm
content: Quote from: T3sl4co1l on April 07, 2022, 12:56:25 pmI should have written "internal fault recovery", not "error recovery". Coping with external packet loss and Reed-Solomon codes is normal operation.Intermittentlytelling the user "failed to do what you requested" is not normal operation.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 07, 2022, 03:39:14 pm
content: Quote from: tggzzz on April 07, 2022, 07:39:06 amSemantics. The software was working as designed; the hardware wasn't.

author: tggzzz
author_rank: Super Contributor
timestamp: April 07, 2022, 04:33:47 pm
content: Quote from: Sal Ammoniac on April 07, 2022, 03:39:14 pmSo you believe it wasdesignedto run out of processing power at a critical point in the flight, alarm/distract the pilots, confuse CAPCOM, and leave it to a 25yo on the ground to say "ignore the alarm"?I think not.AUAI the hardware (both computer and external) was not faulty and was working as designed.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 07, 2022, 05:28:48 pm
content: Quote from: jemangedeslolos on April 07, 2022, 07:35:49 amI assume these are with OCTRIG = 0 (that's what it seems from the pictures), otherwise you would get the 20 us pulses as in the screenshot from the previous post.On the 20 us pulses - looks like the module gets triggered immediately after the pulse.This means that something must drive TRIGSTAT low at the end of the pulse. This is either because you set TRIGMODE = 1 or something else in your code. This is how it should be.But the OC must not re-trigger immediately, it must wait for the next trigger. I cannot tell what re-triggers it. But you need to find out. I have two ideas:1) This may be somehow related to the trigger source, e.g. changing from IC to INT may somehow change this.2) The falling edge of the OC output couples onto the input line, which produces high enough voltage level to cause a new IC trigger.I don't know why you get only one OC interrupt. However, if your chip has TRIGMODE you don't need the OC interrupt anyway.

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: April 07, 2022, 07:04:19 pm
content: Quote from: NorthGuy on April 07, 2022, 05:28:48 pmgrrrrr sorry, typo againYou are right, the last screenshots are with OCTRIG = 0.Thank you very much for your help and your ideas.I will investigate tomorrow with my real oscilloscope.I'm using a homemade dev board that I've had for several years. I assumed everything was fine on the hardware side because I've never had a problem with it.I attributed the noise to be related to the Analog Discovery unshielded wires.I will keep you in touch

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 07, 2022, 08:27:52 pm
content: Quote from: tggzzz on April 07, 2022, 04:33:47 pmOf course it wasn't. The design goal was to use a maximum of 85% of the available CPU, and they did meet that goal. A hardware issue outside the computer caused counter events that pushed the CPU usage to 100%, which was the result of a hardware design issue that wasn't caught in testing. How should this have been handled by the software design team? By allowing more than the 15% margin they did? That wasn't feasible considering how resource-constrained the design was. The whole thing, which never had been done before, was a team effort, and it resulted in successful landings on every attempt, despite issues like the program alarms on Apollo 11 and the abort discrete issue on Apollo 14. The teams found effective workarounds (ignore the alarms on 11 and fool the computer into thinking it was already in abort mode on 14) under great pressure and time constraints.But I'm sure a British moon mission will do much better and have a much better designed and tested computer system that will do more thanjust cope... On the other hand, considering my experience with the electrical systems on British cars, the rocket probably won't get off the ground.

author: tggzzz
author_rank: Super Contributor
timestamp: April 07, 2022, 09:10:48 pm
content: Quote from: Sal Ammoniac on April 07, 2022, 08:27:52 pmThat last comment is revealing.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: April 08, 2022, 01:42:30 am
content: Quote from: Sal Ammoniac on April 07, 2022, 08:27:52 pmWow. I can only assume some Brit pissed in your cornflakes this morning. Just ... wow.

author: hans
author_rank: Super Contributor
timestamp: April 08, 2022, 07:12:45 am
content: Quote from: tggzzz on April 07, 2022, 01:17:11 pmAren't those called design limits? Packet error rate can be OK or also very devastating above a certain threshold. A bit error rate: likewise, at some point Reed-Solomon will fail. Not every real-time system is the same. Some are hard real-time.. they can't miss anything and any deadline. Others have softer requirements (like video/audio playback with the infrequent hickup)There's plenty of research going on that investigate systems that can operate with intermittent behaviour, such as intermittent, stochastic or approximate computing. It's a similar story to the worst-case execution times again: setting a design limit and designing with tighter system tolerances, instead of going overkill.. As we've discussed, the time that CPU cycles were easily countable and 100% deterministic are pretty much gone.Now personally I'm not a too big fan of introducing a large stochastic property into computational efforts. It's harder to grasp and debug, but I also think it's removing the property where computers are good at: consistent computational power or 'attention' (which has led to super reliable infrastructure such as electrical grids and the internet). Consistent attention.. something opposed to us humans, which can get grumpy if we hadn't had our coffee/tea or move discussions to personal level just so we can evaluate the hasDiscussionBeenWon() to be True.

author: tggzzz
author_rank: Super Contributor
timestamp: April 08, 2022, 08:35:49 am
content: Snipped sensible points to concentrate on...Quote from: hans on April 08, 2022, 07:12:45 amI can tolerate that in many cases.I am less tolerant of the so-called machine learning techniques, which - by design - don't have a known envelope. They are TDD taken to extremes, and presume "youcantest quality into a product"

author: Siwastaja
author_rank: Super Contributor
timestamp: April 08, 2022, 08:45:10 am
content: If I understood the Apollo thing correctly, a simplified equivalent problem would be wiring a signal directly into an interrupt pin of a CPU, and not thinking about maximum interrupt rate that can occur, during normal or less-than-normal conditions.It's good the complete system was able to cope, but it came with the expense of other processes; this is a last-resort attempt to save the day, due to failure at lower level, at which the problem would have been much easier to deal with.Really the right thing to do is to condition/process the signal on hardware level: for example, use a timer peripheral to count the cycles; something which can deal with whatever pulse rate. Failing to have hardware for that and having to resort to CPU interrupt, then the only sane thing you can do is to turn off the interrupt source for some time, and re-enable it with a timer, setting a maximum limit for interrupts. But then you need something else to detect the "unexpected pulses between allowed interrupt time window" error case.In modern microcontrollers, the key is the good availability of peripherals. For example, STM32F334 HRTIM has one asynchronous input, which can be configured to asynchronously drive outputs, bypassing the synchronization delays and jitters we have been talking; exactly because theyaresignificant in most demanding DC/DC control applications.Counting cycles of processing is a red herring. Most often the instruction timing (or interrupt latency) is not the source of unexpected jitter in microcontroller systems. NorthGuy completely missed my point, challenging the claim about 12-cycle Cortex-M7 interrupt latency. I was purposely not talking about the complete system, because the xCORE sales guy* isn't doing that, either. That interrupt latency is what is being compared to counting instruction cycles on a "simple" core running a blocking wait-for-event instruction. But it's totally the wrong metric. Neither the Cortex-M7, nor the xCORE are actually completely predictable and jitter-free, because they need to interface with the external world, and this interface is almost always asynchronous, yet the CPU is synchronous (to its own clock).And this is the point if someone still missed it: a Cortex-M7 predicting a branch and "unexpectedly" saving 5 nanoseconds is totally the same order of magnitude as synchronization jitter is! The claims about interrupt jitter being in range of thousands of ns due to caches, backed up by measurements of application processors, does not apply to microcontrollers at all: it's a classic strawman argument, purpose of which is to confuse the reader.Repeat after me until understood: caches do not apply to microcontrollers. Caches do not apply to microcontrollers. Even if they have caches available. Usage of caches is not mandatory. Microcontrollers come with fast memory. Microcontrollers allow running ISRs out of fast memory. Cortex-A CPUs are not microcontrollers. Look at what the name of this subforum is. Look what the "Subject:" line says. Got it?*) yes, someone PM'd me some more references, which made me even more convinced. I might still be wrong, though; it's entirely possible to look like a duck, quack like a duck, and still not be a duck.

author: nctnico
author_rank: Super Contributor
timestamp: April 08, 2022, 09:43:28 am
content: Quote from: Siwastaja on April 08, 2022, 08:45:10 amActually those application processors (using a Cortex A series as the main CPU) are often paired with a Cortex-M series sub-system where the latter can do hard-realtime stuff.

author: tggzzz
author_rank: Super Contributor
timestamp: April 08, 2022, 02:43:55 pm
content: Quote from: Siwastaja on April 08, 2022, 08:45:10 amYour third sentence invalidates your first and second sentences! Cache coherence problems?QuoteThat's merelyyourdefinition of MCU, and is not universally acknowledged.An alternative (and arguably more useful) definition of an MCU is a chip where it can use internal memory and peripherals, and does not require external memory nor peripherals. Some Cortex-A devices fit that description.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 08, 2022, 03:34:42 pm
content: Quote from: tggzzz on April 08, 2022, 02:43:55 pmNo. There is no inconsistency, within the context which was discussed - interrupt latency. I have explained it too many times to do it again, and I also understand getting me to waste more time in re-explaining it is just part of your game. I can totally see what you are doing, and alsohowyou do it. You have totally lost your game in my eyes. And I will totally continue debunking your marketing BS every time I see it; no matter how you try to shift goalposts, create strawmen, and confuse others.I will also do my best to convince people avoid XMOS products wherever I have the power to affect the choice.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 08, 2022, 03:38:28 pm
content: Quote from: Siwastaja on April 08, 2022, 08:45:10 amI didn't challenge any claims. The OP tries to get the best latency between the signal and response from an ISR. You suggested that an abstract Cortex-M7 400 MHz MCU will give you the best latency with very low jitter. I was interested in seeing real world measurements. Not to argue any point, but to see real data. You don't have any, don't want to, not gonna. Case closed.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 08, 2022, 03:53:47 pm
content: Quote from: NorthGuy on April 08, 2022, 03:38:28 pmI did not reply to the OP. On discussion forums, discussions are not always linear and without branches. It's quite revealing you missed the pointagaineven after that was pointed out. Partial problem was compared to another partial problem, to demonstrate how stupid it is to look at partial problems. We are probably in total agreement but you are unable to see it.You are free to perform any real-world measurement you think you want to see. I don't understand why you need me to do it.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 08, 2022, 04:38:52 pm
content: Quote from: Siwastaja on April 08, 2022, 08:45:10 amThe Apollo 11 situation was similar to wiring a signal directly to an interrupt pin on an MCU. The rendezvous radar inputs to the AGC were in the form of positions of the shaft axis and trunnion axis. These had analog resolvers that were input to a CDU, which converted the analog position information into a series of digital pulses--the further the radar moves on one of its axes, the larger the number of pulses to the AGC. The AGC handled the pulses by directly incrementing or decrementing (depending on which direction the radar antenna moved) counters without the need to execute any code. Each counter pulse stole one CPU cycle, which was ~12 microseconds. Most of the other data inputs to the AGC also used this pulse counting technique, including the gyros, accelerometers, and the landing radar. The raw data was conditioned by the CDUs and not fed directly to the AGC itself.The LM used 800 Hz AC power, and, for some reason, the power supply to the rendezvous radar was not phase-locked to the power supply of the AGC, and that caused the radar CDU to to think the radar antenna was oscillating rapidly around its current position, so it generated a series of pulses reflecting that to the AGC. Yes, the CDUs should perhaps have been designed to recognize that condition and filter the data so the AGC wouldn't see the pulse storms that it did, but this was early 1960s technology and it either wasn't feasible or the designers didn't foresee it.The MIT IL people never saw the issue in testing because they used a single 800 Hz power supply instead of separate ones. Curiously, since 800 Hz AC supplies weren't too common, at one point the MIT people used McIntosh audio amplifiers fed with an 800 Hz audio tone as power supplies for their test setups.The decision to leave the rendezvous radar on during the descent was a late change to the flight plan suggested by Aldrin, who thought that leaving it on would save time in the event that they had to abort the landing and return to the CSM. It's ironic that this precaution itself almost caused an abort.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 08, 2022, 04:58:20 pm
content: Quote from: Sal Ammoniac on April 08, 2022, 04:38:52 pmI think the really correct way would have been exactly what a modern $0.40 microcontroller does in its quadrature encoder timer module: count the cycles on a simple hardware counter (reg + adder), then have the CPU data bus connected so that this counter can be accessed whenever CPU needs the latest value.This pattern is completely obvious today, ranging from lowest cost toys to high-reliability stuff. But the Apollo story is interesting because it shows it takes time and iterations to find simple, reliable and effective design patterns, and mistakes are made in the process.It's best to completely avoid an error scenario, instead of detecting it and working around. In this example, it could have been done in numerous ways.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 08, 2022, 05:25:12 pm
content: Quote from: NorthGuy on April 08, 2022, 03:38:28 pmNot to add to something that's beginning to be fruitless, but 12-cycle latency or whatever is never going to be achieved if, say, the ISR is in Flash and currently not in instruction cache.There are ways to circumvent that, including putting your ISRs (at least the critical ones) in RAM (and, core-coupled RAM if possible). That's usually doable but many do not even bother doing it or even know how to.Also, obviously you won't get that latency if another interrupt fires, with a higher priority. There are many real-world cases for which setting up appropriate priorities for "tasks" that are of equivalent importance is nothing trivial, or even tractable.Again the point is that's exactly why more and more MCUs have hardware trigger capabilities. Use them whenever possible instead of trying to outsmart the whole thing with ISRs.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 08, 2022, 05:37:45 pm
content: Quote from: Siwastaja on April 08, 2022, 03:53:47 pmI thought you use them regularly and probably have couple of them sitting on your table. That's why.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 08, 2022, 05:48:46 pm
content: Quote from: SiliconWizard on April 08, 2022, 05:25:12 pmI am sure Siwastaja would know how to place the ISR to achieve the best latency and minimize jitter.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 08, 2022, 06:23:35 pm
content: I dunno, he stated that caches did not apply to microcontrollers.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 08, 2022, 06:45:33 pm
content: Quote from: SiliconWizard on April 08, 2022, 06:23:35 pmCaches do not affect timing of critical ISR handlers on microcontrolers because no one in their right mind would place critical ISRs on slow, cached memory (such as SD card or external DRAM). This is what I meant because of the context.But I'm sure you know this. What I don't understand is why you participate on this trolling, and continue feeding the same old strawman argument.Functions can be placed in ITCM by modifying the linker script and using section attributes. If you don't know how, you can Google. It's not rocket science. Interrupt priorities is also a very simple concept, almost trivial. One function call to set the priority as you wish: higher priority interrupt pre-empts lower priority one; trivial worst-case timing. You can also demote to lower priority by invoking software interrupt through NVIC->STIR; this is something I regularly do.I don't understand how this is difficult to anyone except beginners. And beginners can learn.But I can see what disgusting social game is going on. Surprisingly, I have got private messages with very opposite tone, confirming my suspicions. I would like to ask these frequent posters to come out publicly, but OTOH I can totally see why it is not happening.But yeah, this thread gives a good idea about the level of mental honesty of certain people. Enjoy, and good luck with that attitude.

author: nctnico
author_rank: Super Contributor
timestamp: April 08, 2022, 07:11:20 pm
content: Quote from: Siwastaja on April 08, 2022, 06:45:33 pmYes, although some microcontrollers have flash accellerators that serve like a very small (few words at most) cache that could incur a variable delay.QuoteYou can ofcourse theorise that having interrupts at different priorities will affect latency but in the end that is part of the design constraints. Servicing two interrupts at the highest priority with the lowest possible latency is impossible so something has got to give.IMHO the bottom line is that if you really need to rely on theoretical limits of interrupt latency and/or instruction cycle timing, there is something seriously wrong with your system's design to begin with. Finding the limits is more like an academic exersize to get a feel for the platform rather than having a real practical use.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 08, 2022, 07:28:33 pm
content: Quote from: SpacedCowboy on April 08, 2022, 01:42:30 amSorry. Sometimes I just get tired of people, who have never done something themselves, second guessing and criticizing those who have. Hindsight is always 20:20 after all.Another example: For years and years I heard that PAL is so much better than NTSC. Well sure, PAL was developed a decade after NTSC and had the advantage of learning from NTSC's example. Sometimes being first is a disadvantage because you lock yourself in and have to maintain backwards compatibility with older implementations, like the NTSC designers had to do when they added color (which they did brilliantly, IMO). This kind of Monday morning quarterbacking (sorry all you non-Americans--Google it) annoys me.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 08, 2022, 09:11:56 pm
content: I found an interesting NXP app note about Cortex M-7 which provides real measurements for i.MX RT1050:https://www.nxp.com/docs/en/application-note/AN12078.pdfThe case we would be interested in is in the chapter 5.3 - "GPIO interrupt latency"They send a pulse, fire an interrupt and use 3 commands to produce the output - LDR/MOV/STR (compiled from the C code):Code:void GPIO5_Combined_0_15_IRQHandler (void){GPIO2->DR = 1u << 23GPIO2->DR = 0u;GPIO_ClearPinsInterruptFlags(SW_GPIO_BASE, 1u << SW_GPIO_PIN);}Running at 600 MHz, they verify that the interrupt latency is 11 cycles (18 ns), but they get 75 ns interval between in and out pulses on the scope. The majority of this time - 34 cycles (57 ns) - is consumed by the execution of 3 (presumably uncached) commands. I don't know where thir ISR was located. Running from ITCM could probably cut down on the number of the cycles, but nobody knows by how much.BTW: Unrelated, but interesting: When they move processing to a RTOS task, the latency goes to almost a microsecond.

author: uer166
author_rank: Super Contributor
timestamp: April 08, 2022, 10:30:07 pm
content: Quote from: Siwastaja on April 08, 2022, 04:58:20 pmI don't think that pattern would work, every transistor is precious when you only have 2-3 per chip, there is no way they could afford that many counters (one per peripheral), when you have a few dozen sensors. They re-used hardware that was already there, which happened to be there for CPU as well. Of course today there's no excuse for that, but that amazing system worked for what it was intended in the end, and was probably the densest computing entity at the time.

author: hans
author_rank: Super Contributor
timestamp: April 09, 2022, 07:21:20 am
content: Quote from: NorthGuy on April 08, 2022, 09:11:56 pmInteresting numbers.Perhaps the limitation is also in a different part of the MCU, though. But I don't know the i.MX chips too well, only talking from investigations in STM32s..I think on most microcontrollers running up to the 100-200MHz range, they have their GPIO peripherals directly onto the main AHB bus, along with CPU, FLASH, RAM etc. However for these high-speed MCUs that run at 500MHz+ or so, the GPIOs may be behind several peripheral bridges that increase latency. For example on the STM32H7, the GPIO peripheral is behind an AXI bus matrix and a AHB bus matrix. The AXI and AHB4 bus runs "only" at 200MHz.I don't have a STM32H7 board in my desk. But I've read stories from people "complaining" about slow GPIO speed, in the order of 10 cycles per register write. That way a simple pin toggle could even be slower than on STM32F7. Perhaps this is also the case on the NXP chip. In that case 34 cycles could be explained, e.g. 3x 9 = 27, leaves 7 extra for loading constants and stack maintenance.Or there is still some latency in there from FLASH. Who knows. If the test program is small (just this IRQ and main() with an infinite loop), then caches should also "do their job" even when it's not placed in ITCM.So even though the IRQ latency can be great, the time till GPIO toggle can be still quite high if ran through software.And those 2 goals can also be quite different.

author: mino-fm
author_rank: Regular Contributor
timestamp: April 09, 2022, 10:08:45 am
content: Now I tried to get max. speed of IO-response using EXTI-signal from PE5 and watching PB3 as output.STM32H723 @ 550 MHz ISR looks like this:#define PE5_RISING (1 << 5)#define PB3 3void EXTI9_5_IRQHandler(void){GPIOB->BSRR = (SET_GPIO << PB3); // IO-Bit setGPIOB->BSRR = (RESET_GPIO << PB3); // IO-Bit resetGPIOB->BSRR = (SET_GPIO << PB3); // IO-Bit setGPIOB->BSRR = (RESET_GPIO << PB3); // IO-Bit resetEXTI->PR1 = PE5_RISING; // clear flag__DSB();}Caches are enabled and ISR has highest priority. 1. picture shows a typical response of arround 70 ns. 2. picture shows jitter of >= 10s sampling time of 100 kHz input signal.Although PB3 is set and reset writing directly to BSRR, output signal needs 12 cycles of 550 MHz (22 ns) to set or reset the output pin.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 09, 2022, 02:37:12 pm
content: Quote from: NorthGuy on April 08, 2022, 09:11:56 pmNo, I thinkyouauthors misinterpret the results; the "majority" of time is not used to fetch and execute the instructions; majority of the delay is:* Synchronization of the input to the IPG clock domain and generating the interrupt signal to the CPU clock domain - this part is completely lacking from the analysis,and then,* STR instruction writing from the CPU clock domain to the IPG clock domain.They seem to give the impression that the STR instruction "stalls" until the result is seen on the scope screen, but this is not the case.Instructions run fast. IO clock domain runs slower. That's exactly why we have data barrier instructions; when we need to "slow down" the instructions.And this is where assumptions go wrong. You scope like they did on the paper, and calculate it took 34 cycles. But it really didn't. The CPU went on executing the code faster; the IO is just slower than the CPU! That's also why it's not fruitful to count CPU cycles because it's not the bottleneck.Not 100% sure, but I'd guess most M7 MCUs would prefetch the first ISR instructions in parallel to stacking registers from flash, so there should be no difference in the first few linear instructions whether running from flash or ITCM. This could be proven, too, if necessary, but it's needless extra work when you can just place the routine in ITCM (or main RAM); that's why it exists. The benefit of ITCM compared to main RAM is independence of DMA transfers affecting the timing.Having IPG set at 150MHz, IO operations are way slower than the 600MHz CPU clock might indicate for a casual reader. As you say, it's not said where the ISR resides, moving it to ITCMmightshed out a few clock cycles, but OTOH might not due to parallel flash prefetch making it already as fast as possible from the CPU point of view.STM32H7 series, which I have used on quite a few projects since the introduction, for example supports IO clock domain (D3 domain; AHB3 or AHB4 IIRC) up to 240MHz. With fCPU of "only" 480MHz, the performance would be still better than the iMX running at IPG = 150MHz. The revision history of that pdf indicates they accidentally ran at IPG=300MHz at first, which is beyond the allowed range, but the results would have been interesting to see.But I don't actually live in my lab so I can't measure anything now.The point is, the clock domain speed is the most defining factor. Instruction counting is secondary, especially because CPU core tends to run at higher clock speed than the IO, so even if you have 1-2 cycles of jitter there, it's just... insignificant. Hence, the separation of computing timing from the everything else. Instruction timing might have mattered a lot more when it happened at 8MHz in a CPU with lousy peripherals.But I'm sure I know nothing because I dare to challenge a "well respected" member.EDIT: Even with FLASH prefetch going in parallel with stacking, that piece of LDR-MOV-STR code does have one disadvantage: the LDR (which loads the IO port address, I guess) likely accesses outside of the FLASH prefetch range, requiring spending the number of FLASH wait states anyway. So it pays off to have the ISR in ITCM (or even just main RAM) anyway.

author: tggzzz
author_rank: Super Contributor
timestamp: April 09, 2022, 03:18:46 pm
content: Quote from: Siwastaja on April 09, 2022, 02:37:12 pmPassive-aggressive statements don't do you a favour; they are often intended to shut down discussion.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 09, 2022, 04:49:04 pm
content: Quote from: Siwastaja on April 09, 2022, 02:37:12 pmYou're right. And the mino-fm's data are more telling because they show jitter. The peripheral clock is running at, perhaps 50 MHz, then you get up to 2 cycles of jitter because of the phase errors, then 1 cycle to sync, then there's interrupt inovocation - roughly 20 ns, then the output stage (STR instruction) takes 1 cycle to get it out.Or it might be that the peripheral clock is 100 MHz, or 150 MHz with longer pipelines, but for such clocks the jitter would have been smaller I think. It should be possible to run the peripheral clock faster (to some extent) and thus to make the reaction time shorter.The net result - roughly 80 ns average latency with 40 ns peak-to-peak jitter, with worst case being 100 ns. The interrupt latency is not very significant in the great scheme of things - only 20 ns out of the 60 ns minumum latency.

author: mino-fm
author_rank: Regular Contributor
timestamp: April 09, 2022, 05:45:33 pm
content: Quote from: NorthGuy on April 09, 2022, 04:49:04 pmAHB4 clock is running at 275 MHz - as fast as possible ;-)I didn't expect that it takes so much time. As said before, instruction timing doesn't matter at all.There is one thing to say: I added this ISR to an operating system (frequency counter) which accesses PORTB and PORTE too. It looks like this will slow down synchronisation and append this jitter.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 09, 2022, 09:24:15 pm
content: Quote from: mino-fm on April 09, 2022, 05:45:33 pmWow! The output pulse is slightly longer than 20 ns, so it's most likely 6 peripheral clocks (or 12 instruction clocks). It does need to do a lot - at least 3 instruction clocks for the execution, there there may be wait states for CPU accesses to the bus, then the periphery must read from the bus and process it somehow.The numbers look very similar to i.MX RT1050 so it looks typical.I don't quite understand why the jitter is so high - 10-11 peripheral clocks. May be some sort of bus contention.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 10, 2022, 06:26:47 am
content: Quote from: tggzzz on April 09, 2022, 03:18:46 pmI'm not passive-aggressive, I am active-aggressive. I have called you out explicitly, and honestly stated I think you really are a guerilla marketing shill. I did ask the question does anybody else see like this, and would have preferred honest answers. I only got those via PM. Publicly, no one except me dares to say either "yes" or "no". Instead they go for passive-aggressive attacks against me. I think this tells a lot about these people and their moral. Heck, if you really disagree, just say so.I encourage everyone to run a forum search with search term "xcore" and look at the results. Almost 100% are by a single person, date back for years and years, and are written exactly like marketing people write ("silver bullet points" style). Most are on-topic, but you will be able to see some that stand out in a bizarre way, just like having to meet a certain quota of writing xcore-positive messages, and no one happened to ask about timing that month.And, I might still be wrong. But I also might not.

author: tggzzz
author_rank: Super Contributor
timestamp: April 10, 2022, 08:06:26 am
content: Quote from: Siwastaja on April 10, 2022, 06:26:47 amYourswasa passive-aggressivestatement. Yourpersonalityis a strawman argument in that context.QuoteObviously there cannot be any reponse whatsoever to those unpleasant innuendos. They have no place in a technical discussion.SpacedCowboy made this observation, earlier in this thread:https://www.eevblog.com/forum/microcontrollers/best-mcu-for-the-lowest-input-capture-interrupt-latency/msg4106905/#msg4106905QuoteWhat on earth are you on about?!When I disagree, I say so -and give my reasons. I don't resort to innuendos.QuoteThat's the very important point, although I would think 100% are on topic.QuoteYou are wrong. Completely wrong.

author: mino-fm
author_rank: Regular Contributor
timestamp: April 10, 2022, 11:32:24 am
content: To get minimal jitter - avoiding distortion of other functions - I made a CubeMX startup-file and added only one init-function and the ISR. Now jitter is reduced to less than 10 ns. Sampling time of 100 kHz input signal has been several minutes. This is for H7xx.Going on, I wanted to see how F746 will response to an external signal. Again I made a small startup-file configuring SystemCoreClock and AHB1 to 216 MHz and looked what happens.Response time is about 110 ns but - surprising for me - speed of GPIO now is four times faster as H7. So I had to proof H7-code again, but it will not work faster as before.To get better control of timing F746 generates 4 output periods at PB3.

author: nctnico
author_rank: Super Contributor
timestamp: April 10, 2022, 11:33:50 am
content: Quote from: Siwastaja on April 10, 2022, 06:26:47 amI have to agree with this. I think most people are not very interested in Xcore processors. First of all it is much easier to deal with a single threaded or single CPU solution compared to dealing with a whole bunch of cores running asynchronously. Secondly being locked into a vendor specific tool for software development in a very specific way is something to avoid as well. If you need more cores, you can buy multi-core microcontrollers nowadays that are using industry standard ARM cores + tools. So that only leaves very niche applications that need massive parallel processing to get a job done. The typical example of tggzzz which implies of having a core sitting idle to wait for input makes no practical sense. Peripherals have buffers and/or DMA to relax the timing requirements. Using an entire processor core to deal with I/O is a waste of resources; Xcore doesn't bring anything to the table for these purposes. Solution looking for a problem.

author: tggzzz
author_rank: Super Contributor
timestamp: April 10, 2022, 11:58:14 am
content: Quote from: nctnico on April 10, 2022, 11:33:50 amThe vendor-specific point is very valid.Dealing with multiple asynchronous cores is tricky, not because of the hardware but because of the software and software mindset of parallelism as an "advanced afterthought". Yes, C, I'm looking at you!The XMOS ecosystemstartsbypresumingparallelism and therefore being based around concepts that simplify parallelism. Those concepts were developed in the 70 (Hoare's CSP), deployed in the 80s (Transputer/Occam), partially deployed in many processors in the 90s and 00s (e.g. some TMS320 DSPs) - and are becoming more mainstream (in Go and Rust) in the 10s and 20s. They deserve to be better understood and appreciated.As for having an entire core doing nothing being wasteful, that's just wrong. While that is theconceptualmodel, it isn'timplementedthat way. The implementation is SMT taken to an extreme: cores are "multiplexed" onto a tile, the only duplication being a small (invisible) set of registers.That's the same as Sun inplemented in their Niagara T-series processors. Almost 20 years ago they had 8 "tiles" of 8 "cores" per chip, hence being able to "service" 64 threads in hardware. For the appropriate "embarassilbly parallel" server workload, that workedstunninglywell.Overall, what XMOS brings to the table is neatly integrated software and hardware that parallelism easy. Nothing else manages that; there have been many failed attempts by other companies. Since high levels of parallelism is the future, whether or not you realise it, XMOS is showing one way forward. There are others, and need to be still more.

author: free_electron
author_rank: Super Contributor
timestamp: April 10, 2022, 02:37:35 pm
content: TL;DR; but have you looked ad Cypress pSOC ? they have programmable hardware blocks. Put your time critical functions in there.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: April 10, 2022, 03:23:32 pm
content: I pretty much like the XMOS cores, appently unlike someI do think they’re expensive for what you get though, and the point about the conceptual model not matching the implementation is double-edged. Yes, it means you can PAR several tasks onto one core, but you’re bringing back the complexity that the conceptual model hid away. Similarly, the moveable pointer idea - its clever, it’s well-implemented, but it’s different, and like anything wizardly, it is subtle and easy to anger…OTOH I don’t think many people would implement an SDRAM controller insoftwareon a microcontroller, but you can, fairly easily, on an XMOS chip, and then vend that memory to other cores/tasks. Few microcontrollers provide time-stamped, clocked input/output of multi-bit ports, with SERDES available in hardware. If that sort of thing solves your problem, XMOS is your friend.I don’t think they excel as general-purpose chips (too slow, too expensive, not a lot of RAM), but within the realm of problems they *are* applicable to, they are pretty much spot on. I’ve seen them a lot in audio processing for example, where hard real-time processing is crucial. Data acquisition is another.Some of this ‘jitter is a myth’ talk seems a bit misguided to me - sure you can show negligible jitter for a single incoming signal by using ITCM, high interrupt priority, and it all works nicely. Now show me 8 different signals,allbeing equally important, all being asynchronous to each other, and all needing that same latency response. A single-core CPU can perform one interrupt at a time, the benefit of the Xcore is that it can handle multiple signals/inputs at a guaranteed latency, without requiring a whole new MPU, clock, maybe external flash, and passives. Again, if you need that, it’s awesome.Horses for courses, choose what works. Given the steady progression of low-end, low-cost FPGA parts, the XMOS advantage is being eroded IMHO, but all things pass - maybe XMOS will come out with something that can extend the line’s life, again, in its sphere of specialty.

author: tggzzz
author_rank: Super Contributor
timestamp: April 10, 2022, 03:28:54 pm
content: Quote from: free_electron on April 10, 2022, 02:37:35 pmThere is a good argument that some classes of time critical functions should be put in hardware. Nobody argues against that! Sometimes the hardware can even be FPGAs with ARM A class processors, e.g. Zynq devicesThe key point is to know what you will be able to guarantee when the fully functioning system has finally become operational. Finding infrequent timing failures at that stage is very expensive.In non-trivial systems, microbenchmarks have limited predictive value.

author: tggzzz
author_rank: Super Contributor
timestamp: April 10, 2022, 03:48:08 pm
content: Looks like our posts crossed in the æther!Quote from: SpacedCowboy on April 10, 2022, 03:23:32 pmI agree with all that.My point about conceptual model and implementation wasn't intended to be about merging several tasks onto one core. I didn't make it very clear, but my point was about the lack of hardware duplication. In most multicore devices, each core has its own ALU, instruction sequencer, addressing mechanism etc. In SMT devices, such as xCORE and Sun's Niagara, there is only one sequencer, one ALU, one addressing mechanism and they are all timeshared between each core; only the registers are per-core. One of those timeshared computational blocks is, in xCORE terms, called a "tile", and each tile has 8 cores. A given device can have up to 4 tiles, making a total of 32 cores (but only 4 ALUs etc).QuoteI agree.I'll add that even though an xCORE device can process 100Mb/s ethernet bit streams, in most cases it probably makes more sense to do that in hardware. Indeed, some xCORE devices have such ethernet hardware.QuoteAnd that's the point: "horses for courses".There's no doubt that xCORE is hitting a niche market - but it is worth knowing what that niche is and how XMOS matches it. Some of the concepts they use are applicable to far more than the xCORE niche.QuotePrecisely. Spot on.I like being able topredictperformance, not measure it and hope. I appreciate that is unfashionable with the TDD/Agile "if it passes the(overly simplistic)tests, then it is working" brigade.QuoteFPGA costs come in two forms: per chip and staffing/conceptual. It is much easier to find softies than FPGA engineers, let alone find those that can understand the other's technology!

author: NorthGuy
author_rank: Super Contributor
timestamp: April 10, 2022, 05:03:50 pm
content: Quote from: mino-fm on April 10, 2022, 11:32:24 amThis is more understandable. If the peripheral clock is 275 MHz, you would expect the jitter to be roughly 1/275 = 3.6 ns jitter. That's about what you see. You can zoom in to measure the jitter more accurately.

author: mino-fm
author_rank: Regular Contributor
timestamp: April 11, 2022, 07:50:34 am
content: Quote from: NorthGuy on April 10, 2022, 05:03:50 pmHere it is. If each ns really matters dedicated hardware is necessary.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 11, 2022, 10:05:01 am
content: Quote from: mino-fm on April 11, 2022, 07:50:34 amYeah, andasynchronoushardware, to be specific: a wait-for-event instruction on an xCORE core, for example, won't make a difference, because you are just seeing synchronization logic jitter.Some MCUs include peripherals with asynchronous control paths. I have used said feature in STM32F334 HRTIM in a DC/DC converter with 2MHz BW for current sense (LT1999). Inductor current rises fast enough that even one clock cycle at 72MHz makes a difference. Although to be fair, at 200MHz, that would have been totally acceptable.Obviously, even with asynchronous logic, there will be delay and jitter, just significantly smaller than what you can get with some 72MHz IO clock as in the F334.With today's MCUs running IO happily at 200MHz and core at 400MHz, all this matters less and less, and you can just do the simple thing and use general purpose interrupts and code to do things which absolutely required special peripheral features earlier. This increases flexibility, and makes special solutions like xCORE less appealing than they were in the past.

author: tggzzz
author_rank: Super Contributor
timestamp: April 11, 2022, 11:10:51 am
content: Quote from: Siwastaja on April 11, 2022, 10:05:01 amYou appear to have something against xCORE, or at least don't understand what it offers!If you use a fast conventional single-core processor to do multiple tasks that can't reasonably be offloaded to hardware, what timingguaranteescan you give?For example, consider "multiple tasks" to be continuous i/o (e.g. every 1µs), plus front panel control, plus some undefined computation of complexity, plus USB comms to a PC (or ethernet comms if you prefer).Please don't bother to tell us not many systems are like that; we know - but some are. Horses for courses.

author: pandy
author_rank: Contributor
timestamp: April 11, 2022, 09:38:46 pm
content: Strangely no one mentioned RP2040 (RPi Pico) with PIO on board. Small, interesting uC available and cheap.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: April 11, 2022, 09:51:44 pm
content: Quote from: pandy on April 11, 2022, 09:38:46 pmReply35

author: pandy
author_rank: Contributor
timestamp: April 11, 2022, 10:18:59 pm
content: Indeed, sorry, performed search in browser and didn't found RP2040... so my proposal...

author: mino-fm
author_rank: Regular Contributor
timestamp: April 12, 2022, 08:29:23 am
content: Quote from: pandy on April 11, 2022, 09:38:46 pmDon't talk about it. Do it and show us the results of a real application.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 12, 2022, 09:32:13 am
content: People are cautious about new players with just one or two products. Raspberry Pi "foundation" has a track record of uncertain/poor product availability, support and failure to cater professional/industrial market. It's well possible they have solved these problems when they went into silicon/microcontroller market, but only time and experience will prove that, people don't start trusting their product line overnight.And I hope the best for them, competition is only good.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 12, 2022, 05:09:04 pm
content: The RP2040 is honestly great for a cheap MCU, with some interesting features. And yes, the problem is that availability, even for mid-term, is unknown for any commercial application. (And as I mentioned on other occasions, its power consumption in low power modes is not that low, so it's not a good candidate for low-power, battery-operated devices IMO, but it is for many other purposes.)That said, the whole idea that I already mentioned a couple times in this thread is to use hardware trigger features whenever available - the RP2040 PIO is great for this, but there are now many MCUs out there with such features. Use them!

author: hans
author_rank: Super Contributor
timestamp: April 12, 2022, 05:16:15 pm
content: The RP2040 is an educational product, priced for educational markets, with educational/academically interesting peripherals and features (dual M0+, PIO, etc.)The problem is that the MCU doesn't have any code protection features. So either roll your own that executes from RAM (good luck) or buy something that isn't going to be instantly copy-pasted as soon someone pulls the FLASH chip from the PCB..(I've also seen people joke about ESP32 being a bad choice for commercial applications.. but atleast it has decryption on the fly for code from external FLASH. Something which also can't be said of all STM32s with QuadSPI or FMC, by the way.)

author: pandy
author_rank: Contributor
timestamp: April 12, 2022, 07:58:30 pm
content: Quote from: mino-fm on April 12, 2022, 08:29:23 amAfraid you can't afford for my services so you are not in position to demand something from me...

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: April 13, 2022, 02:00:41 pm
content: I feel like tension is growing....Is it really necessary ?I don't think that mino-fm is really asking you some king of services.Maybe he just wanted everyone to stop coming up with architectures without giving real numbers.Or maybe he already knows the RP2040 isn't good when it comes to latency ?Me on the other hand, I gave up.Either I am too stupid, or there is a silicon bug.With proper oscilloscope probe, I didn't see any coupling between the output capture pin and the input.Im using a dsPIC33EP512MC806, I will try with a dsPIC33EP256MU806 which is pin to pin compatible.I have also an other PCB on the way to evaluate dsPIC33CK.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 13, 2022, 05:47:39 pm
content: Quote from: hans on April 12, 2022, 05:16:15 pmIs this thing documented, or is it like the Broadcom CPUs used on the other Raspberry Pi products where you can't get a reference manual?

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 13, 2022, 05:58:37 pm
content: Quote from: jemangedeslolos on April 13, 2022, 02:00:41 pmIt's not, but pretty common on forums and social media in general. I guess we have to live with it.Quote from: jemangedeslolos on April 13, 2022, 02:00:41 pmThe reason some people mentioned the RP2040 and explicitely its PIO, is precisely that you can implement this kind of thing with low latency without using interrupts. You can get ahold of the datasheet and read about the PIO, it's interesting.Quote from: jemangedeslolos on April 13, 2022, 02:00:41 pmI would have gladly given the hardware trigger a try - and shared my findings - if I still had any board with a dsPIC33EP...If there's a silicon bug, have you read the errata, just in case?

author: pandy
author_rank: Contributor
timestamp: April 14, 2022, 08:26:29 pm
content: Quote from: jemangedeslolos on April 13, 2022, 02:00:41 pmSorry but satisfying someone overgrown ego is not my core business... Personally I do not start conversation from challenging anyone (with unspoken "if you can't prove it then shut-up and get lost") - as this is public forum and i don't violate forum rules then I simply consider such approach as rude.RP2040 PIO by definition is deterministic as such jitter and latency are predictable as already expressed by SiliconWizard - can't add anything more.

author: DavidAlfa
author_rank: Super Contributor
timestamp: April 14, 2022, 08:53:33 pm
content: It seems I came in just in time!Final Destination! PIC vs Xcore vs Stm32 vs Rpi !!

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: April 14, 2022, 09:36:05 pm
content: Quote from: Sal Ammoniac on April 13, 2022, 05:47:39 pmThere is reasonable documentation:-datasheet-hardware design-SDKatGitHubI wouldn't say it's perfect, but then I rarely consider documentation perfect, and that's subjective anyway. It took me about 20 minutes from deciding to try it, to getting the LED to blink on the Pico...The SDK at least doesn't try to be all things to all (wo)men, and provide a HAL that tries to cope with all possible code-contortions and therefore ends up being useless for high-performance code. It doesn't hold your hand that much, but some of the nicer touches are that you can configure the serial output to be sent over USB to a tty, just by adding a line or two to CMakeLists.txt.The PIO 'WAIT' instruction appears to have 1 cycle of latency, apparently because it samples the value to WAIT on too early in the clock cycle for it to become stable, or perhaps because of the synchronizers, in any event, the codeCode:wait 1 pin 0. ; wait for high value on pin 0set pins, 1  ; output high value on output pin and delay for 15 clocksset pins, 0 ; output low value on pin... which (apart from boilerplate) is all you'd need to await one pin going high and then setting another high for 15 clocks - would be sufficient for the OP's question. Assemble that with the provided PIO assembler, load it up, configure the input/output pins (there are SDK functions for all this) and Bob's your Auntie's live-in-lover.The clock can run at anything up to ~250MHz, though it's only guaranteed to ~130. At 200MHz with a 2-clock latency (1 for the WAIT, one for the SET), you'd be looking at ~10ns response.You can get fancier, and use a register & loop to make the output pulse longer, or trigger an interrupt on the ARM when it happens, or set up a DMA stream from main memory, and have it automatically pull into the PIO FIFO and output data one bit per clock until the FIFO empties, or ... I mean, it's software...

author: mino-fm
author_rank: Regular Contributor
timestamp: April 15, 2022, 07:39:46 am
content: Quote from: pandy on April 12, 2022, 07:58:30 pmOh, a very stupid answer. Jemangedeslolos asked for help not me.I'd shown several pictures and some code. If someone ask me for complete code he/she can get it.So let us discuss about your solution. Let's talk about nothing.

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: April 22, 2022, 05:22:18 pm
content: Hello everyoneI received my PCB and I gave a try to a dsPIC33CK ( exact ref:dsPIC33CK128MP503 ).There are more parameters than with dsPIC33EP so I don't know if I was doing something wrong with dsPIC33EP but I was able to make it work with this little dsPIC33CKThe latency is not as low as other settings but at leat It works

author: NorthGuy
author_rank: Super Contributor
timestamp: April 22, 2022, 06:20:58 pm
content: Quote from: jemangedeslolos on April 22, 2022, 05:22:18 pmCongratulations!I'm sure, on EP, there was some sort of small thing you somehow overlooked.Roughly 60 ns (if judging by the 1/2 voltage level). I would expect it to be a little bit better. Is the CPU running at 100 MHz (200 MHz Fosc)? Have you used the dedicated INT pin (pin #19) for the signal?Anyway, this is way faster than you would get with the interrupt.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: September 23, 2022, 06:36:57 pm
content: Resurrecting an old thread, but I happened to be searching for IO expanders and the results I found reminded me of this. TheSX150xchips are IO expanders that embed a PLD, and you can use the I2C interface to determine what happens when an IO changes state. The max response time looks to be 25ns if you're running your VDD/VIO at 5v, going down to 125ns if you're running at 1.2v VDD/IO. 25ns is, I suspect, a reasonably good figure for anything that's not a dedicated FPGA/CPLD; probably way too late to be useful but thought it was worth mentioning...

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 24, 2022, 02:48:47 am
content: Quote from: SpacedCowboy on September 23, 2022, 06:36:57 pmInteresting parts, the Logic looks to be very simple, non registered, with maximum of 3 line to 1 line any pattern defined by a single byte bit pattern. ( ie a 3 input universal gate level )If you were using external parts for this, the SiLego GreenPAK parts have more advanced logic capabilitieshttps://www.renesas.com/us/en/products/programmable-mixed-signal-asic-ip-products/greenpak-programmable-mixed-signal-products#parametric_optionsThey started with OTP parts, but have expanded recently to include MTP parts config over i2c