EEVblog® Electronics Community Forum
Electronics => Microcontrollers => Topic started by: jemangedeslolos on March 30, 2022, 04:36:44 pm
-
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 :)
-
There are MCUs with programmable state machine / timer units. For example NXP LPC1500 series. Then there is no software involvement at all.
-
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 :)
The XMOS xCORE processors have a guaranteed by design processing time. None of the traditional execute then measure then hope you have captured the worst case rubbish :) They can guarantee receiving and processing 100Mb/s ethernet bit streams in software, 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.
-
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.
-
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.
42, 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?
-
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...
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.
-
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.
-
2 cycles? Oh, I see it's different for dspic33E, I used dspic33F, they were were slower but did 1 instruction/clock.
Yes, 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 throughput
Anyway 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 latency
in any case, i would probably use an hardware trigger, too.
-
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 pulses triggered 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 a JMP .isr instruction. If you already have address and value loaded into dedicated registers, you could put a ST [X], r25; RETI or 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
-
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.
-
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.
-
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.
-
How about a PIC32MZ? Runs at 252 MHz and has register banks to reduce interrupt latency down to a minimum.
-
You can make a test using some 8-bit or 16-bit Microchip PIC with Core Independent Peripherals .
-
How about a PIC32MZ? Runs at 252 MHz and has register banks to reduce interrupt latency down to a minimum.
besides 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 clock
in dsPIC33E peripherals run at 70MHz max, latency is lower also because there are register banks (at least the shadow bank)
-
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.
The xCORE devices take that approach, but are better.
It can do that with all input 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 :)
-
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 help
FPGA +1 ; Gowin / Efinix Trion are low cost devices that will also fit your project; low cost kits available from both vendors
-
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 help
FPGA +1 ; Gowin / Efinix Trion are low cost devices that will also fit your project; low cost kits available from both vendors
To 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...
-
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 help
Agreed.
When I first "kicked they tyres", I was amazed at how fast I got things working. There were zero unexpected surprises; everything just "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, guaranteeing by design not to miss any bits
- count all the 0->1 transitions
- do front panel operations
- communicate with a PC over USB
That would have been impossible with other MCUs. At the very least I would have had to take many measurements to assess the performance, and hope that I had captured the worst case.
The XMOS devices have FPGA like attributes, and sit in a niche between conventional MCUs and FPGAs.
-
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
-
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.
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... :-DD
-
The OP stated
I don't have a goal to achieve, it is just by curiosity.
and that's just fine.
I don't think specific information is required, but he is after general/universal techniques. Good for him!
-
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.
Yes, 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.
-
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.
-
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 )
If 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.
-
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:
naked
Use this attribute on the ARM, AVR, MCORE, RX and SPU ports to indicate that the specified function does not need prologue/epilogue sequences generated by the compiler. It is up to the programmer to provide these sequences. The only statements that can be safely included in naked functions are asm statements that do not have operands. All other statements, including declarations of local variables, if statements, and so forth, should be avoided. Naked functions should be used to implement the body of an assembly function, while allowing the compiler to construct the requisite function declaration for the assembler
https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html
I have no idea whether this applies to dsPICs or any other chip. It does work for ARM.
-
How about a PIC32MZ? Runs at 252 MHz and has register banks to reduce interrupt latency down to a minimum.
besides the fact that unless you write the ISR in asm interrupt latency in MIPS is horrific compared to dsPIC...
Well, 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.
-
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:
naked
Use this attribute on the ARM, AVR, MCORE, RX and SPU ports to indicate that the specified function does not need prologue/epilogue sequences generated by the compiler. It is up to the programmer to provide these sequences. The only statements that can be safely included in naked functions are asm statements that do not have operands. All other statements, including declarations of local variables, if statements, and so forth, should be avoided. Naked functions should be used to implement the body of an assembly function, while allowing the compiler to construct the requisite function declaration for the assembler
https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html
I have no idea whether this applies to dsPICs or any other chip. It does work for ARM.
It works for MIPS (PIC32) too.
-
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.
-
So much passion for interrupt latency :-DD
I love this forum ;)
I 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 dsPIC33EP512MC806
#INT_IC1
void 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 wanted |O
I 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 :)
-
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 PTG
let's say IC1 capture triggers OC1 pulse
OC1CON1, OC1 Mode is "Single Compare Single-Shot mode"
OC1R is set so that the pulse time is 20us (20us = OC1R / OC1CLK)
OC1CON2, OCTRIG = 1
OC1CON2, SYNCSEL set so that "IC1 input capture event synchronizes or triggers OC1"
that should do it, no cpu intervention
on 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
-
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.
-
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.
-
.
-
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;; 0x58020400
0x6 0x2008 MOVS R0,#+8
0x8 0x61A0 STR R0,[R4, #+24]; set PortB.3
// if(TIM15->SR & TIM_SR_CC2IF) {
Input = falling edge (yellow)
Output = rising edge (blue)
-
For the specific problem (generate a pulse from a pulse), I'd be tempted to use an RP2040. This is the second post (https://www.eevblog.com/forum/fpga/high-speed-bidirectional-mpu-interface/msg4094707/#msg4094707) I've made this morning espousing their benefits. I don't work for them, honest :)
They have PIO blocks, which are programmable state machines running at the clock frequency (and the RP2040 can be pushed way beyond 133MHz), and run independent of the ARM CPU. People have implemented (https://github.com/raspberrypi/pico-examples) SPI, 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 :)
-
So much passion for interrupt latency :-DD
I 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.
-
So much passion for interrupt latency :-DD
I 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.
SiliconWizard,
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 ).
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 source
OC1CON1.TRIGMODE = 1; // trigstat cleared in software AND when IC1RS = OC1TMR
OC1CON1.OCM = 0b101;
OC1R = 0;
OC1RS = 1410;
But in trigger mode and single compare single shot mode, I have nothing on OC1 output :palm:
OC1CON2.OCTRIG = 1;
OC1CON1.OCM = 0b001;
Do you have any idea ?
-
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.
It 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.
-
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 consistent inside the Interrupt handler.
I will check the ASM generated by CCS but Im not familiar with ASM.
You 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.
-
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 consistent inside the Interrupt handler.
I will check the ASM generated by CCS but Im not familiar with ASM.
You 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.
Agreed.
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 introduce very large 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)
-
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.
(https://i.postimg.cc/Z0qZTSJT/2-ms.jpg) (https://postimg.cc/Z0qZTSJT)
(https://i.postimg.cc/7b5csYxT/200-us.jpg) (https://postimg.cc/7b5csYxT)
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.
-
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 introduce very large jitter.
Again, 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 is actually used 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?
-
How about a PIC32MZ? Runs at 252 MHz and has register banks to reduce interrupt latency down to a minimum.
Also 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.
-
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 introduce very large jitter.
Again, 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 is actually used 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?
The 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/ (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/ (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.
-
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 use microcontrollers, 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.
-
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 ).
Post the disassembly of your INT ISR code.
I have something very promising in synchronize mode and double compare continuous pulse mode.
Very well. Now switch to the trigger mode (OCTRIG = 1) and create an interrupt which clears the TRIGSTAT bit after the pulse is produced.
-
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 use microcontrollers, 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.
The 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's one other valid definition of the term. But only one other.
-
The 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.
I 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.
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.
What 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.
-
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 ).
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 source
OC1CON1.TRIGMODE = 1; // trigstat cleared in software AND when IC1RS = OC1TMR
OC1CON1.OCM = 0b101;
OC1R = 0;
OC1RS = 1410;
But in trigger mode and single compare single shot mode, I have nothing on OC1 output :palm:
OC1CON2.OCTRIG = 1;
OC1CON1.OCM = 0b001;
Do you have any idea ?
I 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?
-
The 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.
I 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.
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.
What 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.
And there's another term, SoC, that is ill-defined :)
Having the A9-ARM(s) operating very closely 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.
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.
I'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.
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.
That'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. And that means 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 :)
-
The 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's one other valid definition of the term. But only one other.
I 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.
-
To concentrate on a couple of your points...
To make an accurate WCET prediction is hard. Another way is to assume cache miss always occurs.
Without 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.
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.
I 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.
-
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.
-
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.
Yes, and beginners don't know the exceptions, nor why they are exceptions.
Now, you can usually determine upper bounds for all timings,
How? More specifically, how do you know your max figure is the upper bound.
but even that can be tricky on modern MCUs, and the upper bounds you're going to determine are likely to leave you unimpressed.
Exactly :( Beginners often don't realise the difference between mean and max.
But if that meets your timing requirements, then that will be the way to go.
Definitely
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.
Knowing 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.
-
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 a tight upper 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=x m 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.
-
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 sometimes even faster by 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 interface actually accurate to a 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!
The actual reason 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 is not the difficulty of doing so, but the fact there is no 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-A running linux, and Cortex-M running 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 is really slowing 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 has nothing to do with MCUs getting more complex, but everything to 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.
-
Ignoring many valid points to concentrate on one...
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.
As 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 system :)
If 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?
-
If 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?
Also 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
-
If 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?
Also 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
True.
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.
-
*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 required
All 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.
-
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 compute anything, in finite time -- 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
-
Very well. Now switch to the trigger mode (OCTRIG = 1) and create an interrupt which clears the TRIGSTAT bit after the pulse is produced.
I 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?
Hello,
I just want to take my biggest hammer, and hit as hard as I can on my board ( with my head between them ) |O
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 :'(
-
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.)
-
*shrug* clock-cycle counting is indeed a thing. Whether it’s *your* thing is a different matter.
It'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 in milliseconds, not nanoseconds, 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).
-
*shrug* clock-cycle counting is indeed a thing. Whether it’s *your* thing is a different matter.
It'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 in milliseconds, not nanoseconds, 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).
Not only that, but everywhere where it did matter (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.
-
I just want to take my biggest hammer, and hit as hard as I can on my board ( with my head between them ) |O
If 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, keep everything in 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?
-
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.
Are 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.
-
*shrug* clock-cycle counting is indeed a thing. Whether it’s *your* thing is a different matter.
It'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.
I 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.
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 in milliseconds, not nanoseconds, 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).
That 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.
-
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 in milliseconds, not nanoseconds, 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).
Er, 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.
-
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.
-
Are 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.
Good 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.
-
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.
Some ARM 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.
-
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.)
Hello, I will try with INT1 instead of IC1. As this MCU has peripheral pin select, I can assign INTx to almost any pin :)
I just want to take my biggest hammer, and hit as hard as I can on my board ( with my head between them ) |O
If 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, keep everything in 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?
Hello,
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 said :-+
With 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 = 1
In both cases I tried to reset OC1CON2.TRIGSTAT flag inside the OC1_isr but without any success :'(
-
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.
-
Good 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.
Well, 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.
-
[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?
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.
IC 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.
-
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 in milliseconds, not nanoseconds, 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).
Er, 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.
I'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.
-
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.
-
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.
It 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.
-
Analogies are usually dangerous, since they encourage over thinking the analogy, not the real issue.
It didn't work fine; it coped - just.
-
It didn't work fine; it coped - just.
Ah, so any embedded systems that use error recovery code to recover from problems don't work fine, they "just cope". Got it.
-
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 get it working with OC1CON2.OCTRIG = 1.
OC1 interrupt fires only ont 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.
Did 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)
-
Also keep in mind "latency is lower with external interrupt" is highly dependent on what the MCU is doing at the time of interrupt.
This 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.
-
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 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.
What happens when you set OCTRIG = 1 without changing anything else?
What do you do in your OC1 ISR?
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.
IC 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.
Oh sorry I made a typo, I meant "I can't get it working with OC1CON2.OCTRIG = 1"
So with OC1CON2.OCTRIG = 1 and OC1CON1.OCM = 0b101, I have continuous 20us pulse on OC1
Don't look at noise and crosstalk on channel 1, I'm using a Digilent Analog Discovery 2 without shielded probe :
(https://i.postimg.cc/7CkrkZy5/continuous-pulse.jpg) (https://postimg.cc/7CkrkZy5)
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 :
#INT_OC1
void 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.
-
And to be very clear, without changing anything else, here is a screenshot with OC1CON2.OCTRIG = 1 and OC1CON1.OCM = 0b101
The input pulse on IC1 is 500Hz 10% :
(https://i.postimg.cc/1g7t5FRW/500hz.jpg) (https://postimg.cc/1g7t5FRW)
And with input pulse > OC1 period ( 2kHz 10% ) :
(https://i.postimg.cc/D8Q1fx9B/2000hz.jpg) (https://postimg.cc/D8Q1fx9B)
-
It didn't work fine; it coped - just.
Ah, so any embedded systems that use error recovery code to recover from problems don't work fine, they "just cope". Got it.
No, any embedded system that repeatedly invokes error recovery - especially in a critical situation - isn't working fine. If it is a timing problem then it is just coping.
-
Ah, so any embedded systems that use error recovery code to recover from problems don't work fine, they "just cope". Got it.
No, any embedded system that repeatedly invokes error recovery - especially in a critical situation - isn't working fine. If it is a timing problem then it is just coping.
Wow, 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
-
Ah, so any embedded systems that use error recovery code to recover from problems don't work fine, they "just cope". Got it.
No, any embedded system that repeatedly invokes error recovery - especially in a critical situation - isn't working fine. If it is a timing problem then it is just coping.
Wow, 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"!
I should have written "internal fault recovery", not "error recovery". Coping with external packet loss and Reed-Solomon codes is normal operation.
Intermittently telling the user "failed to do what you requested" is not normal operation.
-
It didn't work fine; it coped - just.
Ah, so any embedded systems that use error recovery code to recover from problems don't work fine, they "just cope". Got it.
No, any embedded system that repeatedly invokes error recovery - especially in a critical situation - isn't working fine. If it is a timing problem then it is just coping.
Semantics. The software was working as designed; the hardware wasn't.
-
It didn't work fine; it coped - just.
Ah, so any embedded systems that use error recovery code to recover from problems don't work fine, they "just cope". Got it.
No, any embedded system that repeatedly invokes error recovery - especially in a critical situation - isn't working fine. If it is a timing problem then it is just coping.
Semantics. The software was working as designed; the hardware wasn't.
So you believe it was designed to 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.
-
And to be very clear, without changing anything else, here is a screenshot with OC1CON2.OCTRIG = 1 and OC1CON1.OCM = 0b101
I 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.
-
And to be very clear, without changing anything else, here is a screenshot with OC1CON2.OCTRIG = 1 and OC1CON1.OCM = 0b101
I 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.
grrrrr sorry, typo again :palm:
You 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 ;)
-
It didn't work fine; it coped - just.
Ah, so any embedded systems that use error recovery code to recover from problems don't work fine, they "just cope". Got it.
No, any embedded system that repeatedly invokes error recovery - especially in a critical situation - isn't working fine. If it is a timing problem then it is just coping.
Semantics. The software was working as designed; the hardware wasn't.
So you believe it was designed to 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"?
Of 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 than just cope... On the other hand, considering my experience with the electrical systems on British cars, the rocket probably won't get off the ground. :-DD
-
Of 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 than just cope... On the other hand, considering my experience with the electrical systems on British cars, the rocket probably won't get off the ground. :-DD
That last comment is revealing.
-
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 than just cope... On the other hand, considering my experience with the electrical systems on British cars, the rocket probably won't get off the ground. :-DD
Wow. I can only assume some Brit pissed in your cornflakes this morning. Just ... wow.
-
I should have written "internal fault recovery", not "error recovery". Coping with external packet loss and Reed-Solomon codes is normal operation.
Intermittently telling the user "failed to do what you requested" is not normal operation.
Aren'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.
-
Snipped sensible points to concentrate on...
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.
I 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 "you can test quality into a product" :(
-
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 they are significant 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.
-
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.
Actually 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.
-
Repeat after me until understood: caches do not apply to microcontrollers. Caches do not apply to microcontrollers. Even if they have caches available.
Your third sentence invalidates your first and second sentences! Cache coherence problems? :)
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
That's merely your definition 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.
-
Repeat after me until understood: caches do not apply to microcontrollers. Caches do not apply to microcontrollers. Even if they have caches available.
Your third sentence invalidates your first and second sentences! Cache coherence problems? :)
No. 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 also how you 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.
-
NorthGuy completely missed my point, challenging the claim about 12-cycle Cortex-M7 interrupt latency.
I 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.
-
NorthGuy completely missed my point, challenging the claim about 12-cycle Cortex-M7 interrupt latency.
I 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.
I did not reply to the OP. On discussion forums, discussions are not always linear and without branches. It's quite revealing you missed the point again even 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.
-
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.
The 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.
-
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.
I 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.
-
NorthGuy completely missed my point, challenging the claim about 12-cycle Cortex-M7 interrupt latency.
I 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.
Not 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.
-
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.
I thought you use them regularly and probably have couple of them sitting on your table. That's why.
-
Not 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.
I am sure Siwastaja would know how to place the ISR to achieve the best latency and minimize jitter.
-
I dunno, he stated that caches did not apply to microcontrollers. ::)
-
I dunno, he stated that caches did not apply to microcontrollers. ::)
Caches 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.
-
I dunno, he stated that caches did not apply to microcontrollers. ::)
Caches 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.
Yes, although some microcontrollers have flash accellerators that serve like a very small (few words at most) cache that could incur a variable delay.
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.
You 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.
-
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 than just cope... On the other hand, considering my experience with the electrical systems on British cars, the rocket probably won't get off the ground. :-DD
Wow. I can only assume some Brit pissed in your cornflakes this morning. Just ... wow.
Sorry. 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.
-
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.pdf (https://www.nxp.com/docs/en/application-note/AN12078.pdf)
The 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):
void GPIO5_Combined_0_15_IRQHandler (void)
{
GPIO2->DR = 1u << 23
GPIO2->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.
-
I 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.
I 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.
-
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.pdf (https://www.nxp.com/docs/en/application-note/AN12078.pdf)
The 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):
void GPIO5_Combined_0_15_IRQHandler (void)
{
GPIO2->DR = 1u << 23
GPIO2->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.
Interesting 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.
-
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 3
void EXTI9_5_IRQHandler(void)
{
GPIOB->BSRR = (SET_GPIO << PB3); // IO-Bit set
GPIOB->BSRR = (RESET_GPIO << PB3); // IO-Bit reset
GPIOB->BSRR = (SET_GPIO << PB3); // IO-Bit set
GPIOB->BSRR = (RESET_GPIO << PB3); // IO-Bit reset
EXTI->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.
-
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
No, I think you authors 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 ITCM might shed 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.
-
But I'm sure I know nothing because I dare to challenge a "well respected" member.
Passive-aggressive statements don't do you a favour; they are often intended to shut down discussion.
-
Instructions run fast. IO clock domain runs slower.
You'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.
-
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.
AHB4 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.
-
AHB4 clock is running at 275 MHz - as fast as possible ;-)
Wow! 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.
-
But I'm sure I know nothing because I dare to challenge a "well respected" member.
Passive-aggressive statements don't do you a favour; they are often intended to shut down discussion.
I'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.
-
But I'm sure I know nothing because I dare to challenge a "well respected" member.
Passive-aggressive statements don't do you a favour; they are often intended to shut down discussion.
I'm not passive-aggressive, I am active-aggressive.
Yours was a passive-aggressive statement. Your personality is a strawman argument in that context.
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.
Obviously 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/#msg4106905 (https://www.eevblog.com/forum/microcontrollers/best-mcu-for-the-lowest-input-capture-interrupt-latency/msg4106905/#msg4106905)
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.
What on earth are you on about?!
When I disagree, I say so - and give my reasons. I don't resort to innuendos.
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,
That's the very important point, although I would think 100% 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.
You are wrong. Completely wrong.
-
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.
-
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.
I 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.
-
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.
I 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.
The 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 ecosystem starts by presuming parallelism 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 the conceptual model, it isn't implemented that 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 worked stunningly well.
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.
-
TL;DR; but have you looked ad Cypress pSOC ? they have programmable hardware blocks. Put your time critical functions in there.
-
I pretty much like the XMOS cores, appently unlike some :)
I 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 in software on 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, all being 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.
-
TL;DR; but have you looked ad Cypress pSOC ? they have programmable hardware blocks. Put your time critical functions in there.
There 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 devices :)
The 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.
-
Looks like our posts crossed in the æther!
I pretty much like the XMOS cores, appently unlike some :)
I 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…
I 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).
OTOH I don’t think many people would implement an SDRAM controller in software on a microcontroller, but you can, fairly easily, on an XMOS chip, and then vend that memory to other cores/tasks.
I 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.
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.
And 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.
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, all being 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.
Precisely. Spot on.
I like being able to predict performance, 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.
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.
FPGA 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!
-
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.
This 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.
-
This 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.
Here it is. If each ns really matters dedicated hardware is necessary.
-
This 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.
Here it is. If each ns really matters dedicated hardware is necessary.
Yeah, and asynchronous hardware, 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.
-
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.
You 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 timing guarantees can 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.
-
Strangely no one mentioned RP2040 (RPi Pico) with PIO on board. Small, interesting uC available and cheap.
-
Strangely no one mentioned RP2040 (RPi Pico) with PIO on board. Small, interesting uC available and cheap.
Reply 35 (https://www.eevblog.com/forum/microcontrollers/best-mcu-for-the-lowest-input-capture-interrupt-latency/msg4094800/#msg4094800) :)
-
Indeed, sorry, performed search in browser and didn't found RP2040... so my proposal...
-
Strangely no one mentioned RP2040 (RPi Pico) with PIO on board. Small, interesting uC available and cheap.
Don't talk about it. Do it and show us the results of a real application.
-
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.
-
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!
-
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.)
-
Don't talk about it. Do it and show us the results of a real application.
Afraid you can't afford for my services so you are not in position to demand something from me...
-
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.
-
The RP2040 is an educational product, priced for educational markets, with educational/academically interesting peripherals and features (dual M0+, PIO, etc.)
Is 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?
-
I feel like tension is growing....
Is it really necessary ?
It's not, but pretty common on forums and social media in general. I guess we have to live with it.
Or maybe he already knows the RP2040 isn't good when it comes to latency ?
The 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.
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.
I 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?
-
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 ?
Sorry 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.
-
It seems I came in just in time!
Final Destination! PIC vs Xcore vs Stm32 vs Rpi !!
:popcorn:
-
Is 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?
There is reasonable documentation:
- datasheet (https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf)
- hardware design (https://datasheets.raspberrypi.com/rp2040/hardware-design-with-rp2040.pdf)
- SDK (https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf) at GitHub (https://github.com/raspberrypi/pico-sdk)
I 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 code
wait 1 pin 0. ; wait for high value on pin 0
set pins, 1 [15] ; output high value on output pin and delay for 15 clocks
set 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...
-
Afraid you can't afford for my services so you are not in position to demand something from me...
Oh, 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.
-
(https://assets-global.website-files.com/6185b708a2657014268d2eaf/61f8b1d52c38422b530505ab_shoebox-big-man.jpeg)
-
Hello everyone :)
I 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 dsPIC33CK 8)
(https://i.postimg.cc/9D47QTbd/ds-PIC33-CK-2ms.jpg) (https://postimg.cc/9D47QTbd)
The latency is not as low as other settings but at leat It works >:D
(https://i.postimg.cc/XGwVHN8B/ds-PIC33-CK-50ns.jpg) (https://postimg.cc/XGwVHN8B)
-
The latency is not as low as other settings but at leat It works >:D
Congratulations!
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.
-
Resurrecting an old thread, but I happened to be searching for IO expanders and the results I found reminded me of this. The SX150x (https://media.digikey.com/pdf/Data%20Sheets/Semtech%20PDFs/SX1501-03_Rev7_10-2-08.pdf) chips 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...
-
Resurrecting an old thread, but I happened to be searching for IO expanders and the results I found reminded me of this. The SX150x (https://media.digikey.com/pdf/Data%20Sheets/Semtech%20PDFs/SX1501-03_Rev7_10-2-08.pdf) chips are IO expanders that embed a PLD, and you can use the I2C interface to determine what happens when an IO changes state...
Interesting 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 capabilities
https://www.renesas.com/us/en/products/programmable-mixed-signal-asic-ip-products/greenpak-programmable-mixed-signal-products#parametric_options (https://www.renesas.com/us/en/products/programmable-mixed-signal-asic-ip-products/greenpak-programmable-mixed-signal-products#parametric_options)
They started with OTP parts, but have expanded recently to include MTP parts config over i2c
-
Necrobumping an old thread for the record.
Timing
On the STM32H743 (SYSCLK = 480 MHz from PLL1, Revision V), the absolute best pure GPIO input-to-output IRQ latency I was able to achieve was 70 ns, WFE busy-polling latency was 60 ns. The test code was written in C, HAL was used, but without calling high-level HAL functions in the handler, SYSTICK is also turned off. Both the vector table and the IRQ handler running in ITCM, and the handler does nothing but to toggle the GPIO's ODR register, clear the IRQ pending bit, and return after a slight NOP delay loop (because the cleared flag takes time to propagate to NVIC). All code complied by GCC with -O3 and Link Time Optimization (LTO) enabled to maximize inlining.
Source code available upon request (because it no longer exists, and takes time to replicate).
If the vector table was not properly relocated by reprogramming VTOR, the latency is increased to 100 ns. This can be solved by either enabling the cache (not recommending), or by relocating the vector table. When both the vector table and the handler are relocated in ITCM, ICache and DCache have no effect on the latency. In fact enabling the cache becomes a useful debugging tool - if latency decreases, Flash reads are performed by mistake, which must be corrected.
Instead of using an IRQ, busy-polling the EXTI event in the main loop via _WFE() instead of an IRQ reduced it further to 60 ns.
In comparison, a naive HAL example would take around 300 to 500 ns because of the slow Flash and the dynamic decision-making code in the HAL.
I also found a GPIO pulse can’t be shorter than 25 ns, which means software-controlled GPIO toggling is limited to a 20 MHz square wave. Perhaps there's a way, but so far I’m not able to overcome this limitation.
Phase-Shifted Clock Generation
If the external pulse is periodic, such as a clock, I found it’s possible to hide the IRQ latency for all but the first pulse by triggering an internal timer and wait for the timer IRQ instead. The timer is programmed to fire slightly before next edge of the real pulse arrives. For example, if the pulse has a period of 1000 ns and the IRQ latency is 100 ns, you can use the GPIO pulse to trigger a timer to count for 900 ns (100 ns earlier), effectively predicting the next pulse and eliminating the IRQ latency for all subsequent IRQs.
The timer is triggered from GPIO via TIMx_CHx, or TIMx_ETR on every rising edge, so it's always phase-locked with the source with no long-term drift.
Unsuccessful Peripheral Exploitation
There's a general agreement online that STM32H7 has a notoriously slow GPIO controller, because it's on the D3 AHB4 bus, far away from the CPU's D1 domain, requests travel from the AXI port to the AXI matrix, to the AXI-to-D3 AHB bridge, to the D3 AHB matrix, to the GPIO controller. The GPIO pins themselves are much faster (> 100 MHz) in alternate function modes, but they are not designed for bitbanging.
In theory, we can speed it up by two methods.
BDMA
The first idea is to try driving it via the BDMA controller in domain D3, so the traffic stays locally in the same domain and matrix. Unfortunately, the 25 ns barrier remains, even if the transactions are initiated by BDMA. This makes me suspect that the long delay from the CPU is not the main source of latency, instead, the culprit is perhaps the synchronization or wait states within the GPIO controller itself or the AHB4. Alternatively, BDMA and SRAM4 themselves are too slow, so the gain of data locality is nearly canceled out.
static void dma_config(void)
{
__attribute__((section (".sram4_data")))
static const uint32_t gpio_data[8] = {
0xFFFFFFFF, 0x00000000, 0xFFFFFFFF, 0x00000000,
0xFFFFFFFF, 0x00000000, 0xFFFFFFFF, 0x00000000,
};
LL_AHB4_GRP1_EnableClock(LL_AHB4_GRP1_PERIPH_BDMA);
static LL_BDMA_InitTypeDef bdma_ctx = {
.PeriphOrM2MSrcAddress = (uint32_t) &gpio_data,
.MemoryOrM2MDstAddress = (uint32_t) &GPIOA->ODR,
.Direction = LL_BDMA_DIRECTION_MEMORY_TO_MEMORY,
.Mode = LL_BDMA_MODE_NORMAL,
.PeriphOrM2MSrcIncMode = LL_BDMA_PERIPH_INCREMENT,
.MemoryOrM2MDstIncMode = LL_BDMA_MEMORY_NOINCREMENT,
.PeriphOrM2MSrcDataSize = LL_BDMA_PDATAALIGN_WORD,
.MemoryOrM2MDstDataSize = LL_BDMA_MDATAALIGN_WORD,
.NbData = sizeof(gpio_data) / sizeof(gpio_data[0]),
.PeriphRequest = LL_DMAMUX2_REQ_MEM2MEM,
.Priority = LL_BDMA_PRIORITY_VERYHIGH,
.DoubleBufferMode = LL_BDMA_DOUBLEBUFFER_MODE_DISABLE,
/* don't care */
.TargetMemInDoubleBufferMode = LL_BDMA_CURRENTTARGETMEM0,
};
LL_BDMA_Init(BDMA, LL_BDMA_CHANNEL_0, &bdma_ctx);
}
static void mainloop(void)
{
dma_config();
while (true) {
LL_BDMA_EnableChannel(BDMA, LL_BDMA_CHANNEL_0);
LL_mDelay(1000);
LL_BDMA_DisableChannel(BDMA, LL_BDMA_CHANNEL_0);
LL_BDMA_SetDataLength(BDMA, LL_BDMA_CHANNEL_0, 8);
}
}
I also tried to use BDMA's "data unpacking" feature, with the hope that the BDMA can read once from SRAM and write 4 times.
.PeriphOrM2MSrcDataSize = LL_BDMA_PDATAALIGN_WORD,
.MemoryOrM2MDstDataSize = LL_BDMA_MDATAALIGN_BYTE,
But it also doesn't overcome the 25 ns barrier, suggesting either the BDMA doesn't support optimized data unpacking (generating 4 fetches or 3 dummy cycles instead), or AHB4 bus write / GPIO controller itself is bottlenecked.
Peripheral Abuse
Another way is to abuse peripherals on the D1 AXI bus instead for bitbanging, such as the SDMMC, LTDC, FMC, QuadSPI. I decided to try the QSPI because it was easy to use, but without success.
I found the QSPI controller has a "dual Flash" mode, each half is 4-bit, which is potentially a useful 8-bit bus transmitter. But latency also did not improve by abusing QSPI controller at 133 MHz to generate a write request. I got a < 10 ns pulse train, which broke the 25 ns pulse width barrier, but in fact the latency slightly degraded, even if the QSPI controller is physically close to the CPU. I blame the half-cycle chip enable delay. To write Flash in "indirect mode" (e.g. register-based, not memory-mapped), the first half-clock cycle is used for enabling /CE before the first bit is transmitted, I don't see anyway to skip this step. The /CE is held low only if the SPI Flash is in memory-mapped mode. If I read the datasheet correctly, this is used for Flash prefetching, meaning that the controller will keep generating commands on the 8-bit bus, writing garbage on the data bus. I don't see a way to have no prefetching and no /CE delay, perhaps there's a hack (potential solution that I didn't try: if we're using MMIO writes only, the controller is allowed to prefetch garbage, but we can deselect the alternate function to tristate the pins).
But I ran out of patience. Perhaps it can be improved through alternative solutions, such as the QSPI MMIO mode, or by exploiting SDMMC/LTDC/FMC.
-
Necrobumping an old thread for the record.
On the STM32H743 (SYSCLK = 480 MHz from PLL1, Revision V), the absolute best pure GPIO input-to-output IRQ latency I was able to achieve was 70 ns.
Sanity check:
AHB4 bus maximum speed 200MHz (which I assume you obviously would have used for the test), standard synchronization logic delay of 2 clock cycles:
10ns has passed when the peripheral register sees the input
Re-synchronize to 480MHz bus -> again 2 clock cycles of delay (at destination bus speed):
10ns + 4.2ns has passed when the NVIC sees it.
Now the actual interrupt latency of 12 cycles at 480MHz:
10ns + 4.2ns + 25ns
Now execute the instructions - load the peripheral register address, load the value to be written, write to peripheral. 2+2+2 cycles:
10ns + 4.2ns + 25ns + 12.5ns
Now synchronize to the 200MHz AHB4 clock domain: 2 cycles of the target:
10ns + 4.2ns + 25ns + 12.5ns + 10ns ...
and we are at 61.7ns, pretty close to the 70ns.
So I forgot something, or got some number off - but as you can see, with quick analysis, pretty close. So I asked AI what I'm missing, and it says:
Input pad schmitt trigger 1-2ns, another 2-4ns for output slew rate / capacitance
EXTI (edge detection) logic takes 1-2 cycles
AXI-AHB bridge handshake is slower than my estimated 2 target cycles
All believable. No surprises.
Now compare to some XMOS etc. and you get rid of interrupt latency and the internal bridge (due to simpler clock domain design), but input pad delay, initial synchronization, edge detection, and output pad delay still all apply, so the delay is maybe one third, and jitter probably too (still have the original synchronization jitter). Half an order of magnitude improvement.
-
Necrobumping an old thread for the record.
On the STM32H743 (SYSCLK = 480 MHz from PLL1, Revision V), the absolute best pure GPIO input-to-output IRQ latency I was able to achieve was 70 ns.
Sanity check:
AHB4 bus maximum speed 200MHz (which I assume you obviously would have used for the test), standard synchronization logic delay of 2 clock cycles:
240 MHz to be exact. Pre-V silicon was limited to SYSCLK = 400 MHz, AHBCLK's PLL is DIV2, so 200 MHz. Revision V (since 2019) ICs are rated for SYSCLK = 480 MHz (if Tj < 105 °C can be guaranteed), so AHBCLK is 240 MHz.
-
Now compare to some XMOS etc. and you get rid of interrupt latency and the internal bridge (due to simpler clock domain design), but input pad delay, initial synchronization, edge detection, and output pad delay still all apply, so the delay is maybe one third, and jitter probably too (still have the original synchronization jitter). Half an order of magnitude improvement.
I'm not sure that's actually true - the improvement I mean. Some time ago I wanted to pair an FTDI FT600Q to an XMOS device and I was chatting to one of their engineers on xcore.com. My reading of the datasheet was that I was limited to 60MHz as a synchronised input clock rate, and he was gently pointing out that they run 133MHz, in software, to do their QSPI implementation, which is somewhat tested since that's how they read the chip's program on boot.
That's reading new bits every ~7.5ns, which is really down to how the ports on an XMOS chip are different to those on (say) an STM32. The ports can synchronise to an input clock to help them latch their data, and they have SERDES built in, so (I'm assuming) in this case the 4 bits are clocked into a 32-bit word and *that* being sent down the wire to the CPU is far less than the max 60MHz rate. You don't have to use the SERDES of course, but then you're going to hit that 60MHz cap faster.
Since the XMOS chips are inherently parallel, you don't incur any interrupt cost to respond to the signal, you tell the CPU core to wait on i/o. it's sitting there waiting for the data to arrive - like a busy-wait but without the busy-part - and it's prepared to go as soon as the data does arrive. If what you want to do is toggle a LED or drive an output to measure on a scope, the next instruction can do that.
Bear in mind that the CPU (although it can be running at up to 800 MHz) is round-robinning between a minimum of 5 instances, so your real MHz is more like a max of 160MHz. Given that it's ready to go, though, that is still a very rapid response.
The code:
#include <xs1.h>
#include <xcore/port.h>
port_t oneBit = XS1_PORT_1A;
port_t counter = XS1_PORT_4A;
int main(void) {
int x;
int i = 0;
port_enable(oneBit);
port_enable(counter);
x = port_in(oneBit);
while (1) {
port_set_trigger_in_not_equal(oneBit, x);
x = port_in(oneBit);
port_out(counter, ++i);
}
}
sets a hardware trigger on the CPU to wait on a transition on the 'oneBit' port, and immediately output a counter value to the 'counter' port.
XMOS parts are actually very good at i/o, that's one of their strengths. They suffer in terms of clock speed, memory (though the newer 'ai' cores can have DDR3) and a curiously laid out set of ports which seem almost intentionally engineered to be as annoying as possible (oh, you want a 32-bit port, how about 27 of those bits but not the other 5?)
Still, I did get it to read that FT600Q, pretty simply in the end, at a 66MHz synchronous clock. That's the fastest I've synced input on an XMOS device, but having seen how it worked, I quite easily believe that it could go twice as fast, as long as you can use the SERDES in the port hardware itself.
-
Keep optimizing and benchmarking the IRQ latency of the STM32H743 @ 480 MHz. Ultimately, I was able to achieve a WFE polling latency of 38 ns, and an IRQ latency of 45 ns. I think these numbers are close to the theoretical limits.
[attach=1]
[attach=2]
The slow AHB bus and the GPIO controller prevented me from measuring the true IRQ latency of the core itself accurately. But I found a way out: EVENTOUT. Inside the ARM IP core, there's an internal signal called TXEV, originally meant for synchronizing multicore systems (by connecting it to the RXEV input of another core). On the STM32, TXEV can be mapped to any GPIO pin, allowing single-cycle pulse generation directly from the core via the SEV instruction without any controller overhead.
Full project files: https://codeberg.org/niconiconi/stm32h7-exti-latency
-
Keep optimizing and benchmarking the GPIO latency of the STM32H743 @ 480 MHz. :box: I was able to find a way to break the GPIO latency barrier using DMA1 with FIFO and burst mode, now generating a pulse train with a latency of 45 ns and a frequency of 127 MHz.
[attach=3]
Triggering a DMA from GPIO is complicated on the STM32H7. So there are some notes on implementing it.
BDMA Triggering
Remark 1: The SYSCFG_EXTICRx registers provide 16 configuration 4-bit bitfields, each bitfield select a GPIO bank from A to K, the input pin must have the name number as the bitfield number. For example, bitfield 0 select the input GPIO bank of pin 0. This provides 16 multiplexed signal outputs EXTI[0:15].
Remark 2: Syscfg_extiX_mux is the raw output of EXTI[0:15]. Since only Syscfg_exti0_mux and Syscfg_exti2_mux are available as input, you can only use the signal EXTI[0] and EXTI[2], which correspond to GPIO[A:K] pin 0 and GPIO[A:K] pin 2. You cannot use other pins to trigger the DMA because of the lack of connections, but they don't need EXTI or NVIC.
Even better, because it's in the D3 domain, it keeps working autonomously even if the CPU core is halted in the debugger, or if the D1 domain is powered off completely. Unfortunately, only Pin 0 and Pin 2 of a GPIO bank can be used for that. For other pins you need to do it via a real peripheral.
[attach=1]
Code:
static void bdma_config(void)
{
/*
* Select GPIO bank B as the source of the EXTI input line 0.
* GPIOB Pin 0 would generate a signal on EXTI Line 0.
*/
LL_SYSCFG_SetEXTISource(LL_SYSCFG_EXTI_PORTB, LL_SYSCFG_EXTI_LINE0);
LL_AHB4_GRP1_EnableClock(LL_AHB4_GRP1_PERIPH_BDMA);
/* Use EXTI line 0's rising edge to generate DMA Request 0 */
LL_DMAMUX_SetRequestSignalID(
DMAMUX2, LL_DMAMUX_REQ_GEN_0, LL_DMAMUX2_REQ_GEN_EXTI0
);
LL_DMAMUX_SetRequestGenPolarity(
DMAMUX2, LL_DMAMUX_REQ_GEN_0, LL_DMAMUX_REQ_GEN_POL_RISING
);
/* Trigger 2 DMA transfers per request */
LL_DMAMUX_SetGenRequestNb(DMAMUX2, LL_DMAMUX_REQ_GEN_0, 2);
LL_DMAMUX_EnableRequestGen(DMAMUX2, LL_DMAMUX_REQ_GEN_0);
__attribute__((section (".sram4_data")))
static const uint32_t gpio_data[] = { 0xFFFFFFFF, 0x00000000 };
static LL_BDMA_InitTypeDef bdma_ctx = {
.PeriphOrM2MSrcAddress = (uint32_t) &GPIOD->ODR,
.MemoryOrM2MDstAddress = (uint32_t) &gpio_data,
.Direction = LL_BDMA_DIRECTION_MEMORY_TO_PERIPH,
/* auto-reload if NbData goes to 0, otherwise DMA stops */
.Mode = LL_BDMA_MODE_CIRCULAR,
.PeriphOrM2MSrcIncMode = LL_BDMA_PERIPH_NOINCREMENT,
.MemoryOrM2MDstIncMode = LL_BDMA_MEMORY_INCREMENT,
.PeriphOrM2MSrcDataSize = LL_BDMA_PDATAALIGN_WORD,
.MemoryOrM2MDstDataSize = LL_BDMA_MDATAALIGN_WORD,
.NbData = sizeof(gpio_data) / sizeof(gpio_data[0]),
.PeriphRequest = LL_DMAMUX2_REQ_GENERATOR0,
.Priority = LL_BDMA_PRIORITY_VERYHIGH,
.DoubleBufferMode = LL_BDMA_DOUBLEBUFFER_MODE_DISABLE,
/* don't care */
.TargetMemInDoubleBufferMode = LL_BDMA_CURRENTTARGETMEM0,
};
LL_BDMA_Init(BDMA, LL_BDMA_CHANNEL_0, &bdma_ctx);
LL_BDMA_EnableChannel(BDMA, LL_BDMA_CHANNEL_0);
}
static void mainloop(void)
{
/*
* Set GPIO pin A9 as OUTPUT, this is connected to an LED on my devboard
* for indicating the firmware status. Can be removed.
*/
LL_GPIO_SetPinMode(GPIOA, LL_GPIO_PIN_9, LL_GPIO_MODE_OUTPUT);
LL_GPIO_SetOutputPin(GPIOA, LL_GPIO_PIN_9);
while (true) {
__NOP();
}
}
DMA1 Triggering
Remark 3: exti_exti0_it is the output of the EXTI interrupt controller, the same signal also goes to the CPU's NVIC. The same signal is connected to the DMAMUX controllers, which can use the interrupt's edge to initiate DMAs. But to use these signals to trigger DMA, EXTI's interrupt output to NVIC must also be enabled. This creates a problem: if you don't call LL_EXTI_ClearFlag, the EXTI's IRQ output line remains high, which means the DMA stops after the first rising edge.
So, after each DMA triggering, you either have to also enable an IRQ for the sole purpose of clearing this flag, or you have to clear the EXTI interrupt pending bit by polling, or by another DMA. This is why it's not recommended by ST.
[attach=2]
Why should you use DMA1/DMA2 instead of BDMA? The D2 domain can access any memory, the D3 domain can only access SRAM4. Furthermore, the D2 domain's SRAM1 and DMA1 are faster than D3 domain's SRAM4 and BDMA (even though D2 still needs to access D3's GPIO controller). I'm not sure about the exact timing, but from the examples above, BDMA generates a GPIO pulse of 33 ns, but DMA1 generates a GPIO pulse of only 20 ns.
Code:
static void dma_config(void)
{
/*
* Select GPIO bank B as the source of the EXTI input line 0.
* GPIOB Pin 0 would generate a signal on EXTI Line 0.
*/
LL_SYSCFG_SetEXTISource(LL_SYSCFG_EXTI_PORTB, LL_SYSCFG_EXTI_LINE0);
/* Use EXTI Line 0 input's rising edge to trigger an IRQ. */
static LL_EXTI_InitTypeDef exti_ctx = {
.Line_0_31 = LL_EXTI_LINE_0,
.Line_32_63 = LL_EXTI_LINE_NONE,
.Line_64_95 = LL_EXTI_LINE_NONE,
.LineCommand = ENABLE,
.Mode = LL_EXTI_MODE_IT,
.Trigger = LL_EXTI_TRIGGER_RISING,
};
LL_EXTI_Init(&exti_ctx);
LL_AHB1_GRP1_EnableClock(LL_AHB1_GRP1_PERIPH_DMA1);
/* Use EXTI line 0's rising edge to generate DMA Request 0 */
LL_DMAMUX_SetRequestSignalID(
DMAMUX1, LL_DMAMUX_REQ_GEN_0, LL_DMAMUX1_REQ_GEN_EXTI0
);
LL_DMAMUX_SetRequestGenPolarity(
DMAMUX1, LL_DMAMUX_REQ_GEN_0, LL_DMAMUX_REQ_GEN_POL_RISING
);
/* Trigger 4 DMA transfers per request */
LL_DMAMUX_SetGenRequestNb(DMAMUX1, LL_DMAMUX_REQ_GEN_0, 4);
LL_DMAMUX_EnableRequestGen(DMAMUX1, LL_DMAMUX_REQ_GEN_0);
__attribute__((section (".sram1_data")))
static const uint32_t gpio_data[] = {
0xFFFFFFFF, 0x00000000, 0xFFFFFFFF, 0x00000000
};
static LL_DMA_InitTypeDef dma_ctx = {
.PeriphOrM2MSrcAddress = (uint32_t) &GPIOD->ODR,
.MemoryOrM2MDstAddress = (uint32_t) &gpio_data,
.Direction = LL_DMA_DIRECTION_MEMORY_TO_PERIPH,
.Mode = LL_DMA_MODE_CIRCULAR,
.PeriphOrM2MSrcIncMode = LL_DMA_PERIPH_NOINCREMENT,
.MemoryOrM2MDstIncMode = LL_DMA_MEMORY_INCREMENT,
.PeriphOrM2MSrcDataSize = LL_DMA_PDATAALIGN_WORD,
.MemoryOrM2MDstDataSize = LL_DMA_MDATAALIGN_WORD,
.NbData = sizeof(gpio_data) / sizeof(gpio_data[0]),
.PeriphRequest = LL_DMAMUX1_REQ_GENERATOR0,
.Priority = LL_DMA_PRIORITY_VERYHIGH,
.FIFOMode = LL_DMA_FIFOMODE_ENABLE,
.FIFOThreshold = LL_DMA_FIFOTHRESHOLD_FULL,
.MemBurst = LL_DMA_MBURST_INC4,
.PeriphBurst = LL_DMA_PBURST_SINGLE,
.DoubleBufferMode = LL_DMA_DOUBLEBUFFER_MODE_DISABLE,
/* don't care */
.TargetMemInDoubleBufferMode = LL_DMA_CURRENTTARGETMEM0,
};
LL_DMA_Init(DMA1, LL_DMA_STREAM_0, &dma_ctx);
LL_DMA_EnableStream(DMA1, LL_DMA_STREAM_0);
}
/*
* Use "noinline" to prevent this function from being inlined to main(),
* which is in Flash.
*/
__attribute__((section (".itcm_text"), noinline))
static void mainloop(void)
{
/*
* Set GPIO pin A9 as OUTPUT, this is connected to an LED on my devboard
* for indicating the firmware status. Can be removed.
*/
LL_GPIO_SetPinMode(GPIOA, LL_GPIO_PIN_9, LL_GPIO_MODE_OUTPUT);
LL_GPIO_SetOutputPin(GPIOA, LL_GPIO_PIN_9);
/*
* Because DMAMUX is edge-triggered by EXTI's IRQ output, not input, we
* must clear the EXTI flag LL_EXTI_ClearFlag_0_31(LL_EXTI_LINE_0); after
* every IRQ, otherwise the output flatlines and DMA stops. This can be
* done in a real ISR by enabling the IRQ.
*
* NVIC_SetPriority(EXTI0_IRQn, 0);
* NVIC_EnableIRQ(EXTI0_IRQn);
*
* Because we don't want the actual IRQ, NVIC is not enabled on this
* signal. But we still need to simulate the IRQ flag clearing
* by polling (or potentially another DMA transaction). This convoluted
* procedure is the reason that GPIO DMA triggering via EXTI is not
* recommended. Use another peripheral such as a timer if possible.
*/
while (true) {
/*
* Use WFI, not polling, because polling itself consumes bus
* bandwidth, which makes DMA transfer themselves if we're still
* polling during the DMA. If you must use polling, it's better
* to pull the NVIC, not the EXTI.
*
* NVIC_GetPendingIRQ(EXTI0_IRQn)
*
* // after LL_EXTI_ClearFlag_0_31 + 20 _NOP()
* NVIC_ClearPendingIRQ(EXTI0_IRQn)
*/
__WFI();
/* Clear IRQ flags immediately, otherwise DMA stops. */
LL_EXTI_ClearFlag_0_31(LL_EXTI_LINE_0);
/*
* The STM32H7 has a notorious "spurious IRQ" limitation because
* LL_*_ClearFlag() must travel across multiple buses and buffers
* with a long delay, causing the IRQ to retrigger. It can be worked
* around by clearing the IRQ flag early and relying on the natural
* ISR code delay. Adjust this delay if the CPU clock frequency or
* emulator performance changes. Always verify with an oscilloscope.
*
* http://efton.sk/STM32/gotcha/g7.html
*
*/
for (uint8_t i = 0; i < 20; i++) {
__NOP();
}
}
}
DMA1 Triggering With FIFO
Furthermore, DMA1/DMA2 has a FIFO, which means the DMA doesn't need to access memory for every transfer, it can preload data and write that the destination in a burst. In this process, the DMA uses the "burst transfer" type in the AHB protocol, reducing the latency between consecutive words.
Here's an example of bitbanging GPIO via DMA1 using 8 16-bit burst, generating 8 transitions with a period of 7.8 ns, which is a frequency greater than 127 MHz (the real pulse width is below my oscilloscope's rise time, so I can't measure it). I think this is likely the fastest way to bitbang the GPIO on the STM32H7.
[attach=3] [attach=4]
The number of pulses in the pulse train is limited to 4, 8, or 16. Note that time is needed to reload the DMA after each burst, the reloading time depends on the burst settings. In this example, it's 50 ns.
[attach=5]
This shows the raw GPIO controller can be fairly fast, it's just challenging to feed it with data due to the lack of a fast master on its local domain.
Code:
static void dma_config(void)
{
/*
* Select GPIO bank B as the source of the EXTI input line 0.
* GPIOB Pin 0 would generate a signal on EXTI Line 0.
*/
LL_SYSCFG_SetEXTISource(LL_SYSCFG_EXTI_PORTB, LL_SYSCFG_EXTI_LINE0);
/* Use EXTI Line 0 input's rising edge to trigger an IRQ. */
static LL_EXTI_InitTypeDef exti_ctx = {
.Line_0_31 = LL_EXTI_LINE_0,
.Line_32_63 = LL_EXTI_LINE_NONE,
.Line_64_95 = LL_EXTI_LINE_NONE,
.LineCommand = ENABLE,
.Mode = LL_EXTI_MODE_IT,
.Trigger = LL_EXTI_TRIGGER_RISING,
};
LL_EXTI_Init(&exti_ctx);
LL_AHB1_GRP1_EnableClock(LL_AHB1_GRP1_PERIPH_DMA1);
/* Use EXTI line 0's rising edge to generate DMA Request 0 */
LL_DMAMUX_SetRequestSignalID(
DMAMUX1, LL_DMAMUX_REQ_GEN_0, LL_DMAMUX1_REQ_GEN_EXTI0
);
LL_DMAMUX_SetRequestGenPolarity(
DMAMUX1, LL_DMAMUX_REQ_GEN_0, LL_DMAMUX_REQ_GEN_POL_RISING
);
LL_DMAMUX_SetGenRequestNb(DMAMUX1, LL_DMAMUX_REQ_GEN_0, 2);
LL_DMAMUX_EnableRequestGen(DMAMUX1, LL_DMAMUX_REQ_GEN_0);
__attribute__((section (".sram1_data")))
static const uint16_t gpio_data[] = {
0xFFFF, 0x0000, 0xFFFF, 0x0000,
0xFFFF, 0x0000, 0xFFFF, 0x0000,
0xFFFF, 0x0000, 0xFFFF, 0x0000,
0xFFFF, 0x0000, 0xFFFF, 0x0000,
};
static LL_DMA_InitTypeDef dma_ctx = {
.PeriphOrM2MSrcAddress = (uint32_t) &GPIOD->ODR,
.MemoryOrM2MDstAddress = (uint32_t) &gpio_data,
.Direction = LL_DMA_DIRECTION_MEMORY_TO_PERIPH,
.Mode = LL_DMA_MODE_CIRCULAR,
.PeriphOrM2MSrcIncMode = LL_DMA_PERIPH_NOINCREMENT,
.MemoryOrM2MDstIncMode = LL_DMA_MEMORY_INCREMENT,
.PeriphOrM2MSrcDataSize = LL_DMA_PDATAALIGN_HALFWORD,
.MemoryOrM2MDstDataSize = LL_DMA_MDATAALIGN_HALFWORD,
.NbData = sizeof(gpio_data) / sizeof(gpio_data[0]),
.PeriphRequest = LL_DMAMUX1_REQ_GENERATOR0,
.Priority = LL_DMA_PRIORITY_VERYHIGH,
.FIFOMode = LL_DMA_FIFOMODE_ENABLE,
.FIFOThreshold = LL_DMA_FIFOTHRESHOLD_FULL,
.MemBurst = LL_DMA_MBURST_INC8,
.PeriphBurst = LL_DMA_PBURST_INC8,
.DoubleBufferMode = LL_DMA_DOUBLEBUFFER_MODE_DISABLE,
/* don't care */
.TargetMemInDoubleBufferMode = LL_DMA_CURRENTTARGETMEM0,
};
LL_DMA_Init(DMA1, LL_DMA_STREAM_0, &dma_ctx);
LL_DMA_EnableStream(DMA1, LL_DMA_STREAM_0);
}
Just make sure gpio_data is located in SRAM 1 (0x30000000) for DMA1, or SRAM 4 (0x38000000) for BDMA, may require custom startup and linker code. How to implement this is out of scope of this thread. I'm using a bare-metal environment, your mileage may vary.
What I do at startup:
void flash_to_mem(
char *flash_start,
volatile char *mem_start,
volatile char *mem_end
)
{
size_t len = mem_end - mem_start;
#ifdef SEMIHOSTING
printf(
"relocate %p-%p to %p, %d bytes\n",
flash_start,
flash_start + len,
mem_start,
len
);
#endif
/*
* Language Lawyering.
*
* Don't use memcpy(). This is widely used in embedded libraries, but it's
* a theoretical Undefined Behavior as C compilers can remove memcpy()
* when they don't have any visible effects to C code under the "as-if"
* rule. Mark destination variables as "volatile char *", and copy manual-
* ly. Keyword "volatile" ensures it's always executed, and "char *" is
* the only data type in C that is safe to cast into without breaking
* aliasing or alignment rules (even "uint8_t *" does not enjoy this
* exception).
*/
for (size_t i = 0; i < len; i++) {
mem_start[i] = flash_start[i];
}
}
void relocate_to_itcm(void)
{
extern char _si_isr_vector;
extern volatile char __isr_vector_start, __isr_vector_end;
flash_to_mem(&_si_isr_vector, &__isr_vector_start, &__isr_vector_end);
extern char _si_itcm_text;
extern volatile char __itcm_text_start, __itcm_text_end;
flash_to_mem(&_si_itcm_text, &__itcm_text_start, &__itcm_text_end);
SCB->VTOR = D1_ITCMRAM_BASE;
/*
* Test memory access latency by declaring arrays with:
*
* __attribute__((section (".axisram_data")))
* __attribute__((section (".sram1_data")))
* __attribute__((section (".sram2_data")))
* __attribute__((section (".sram3_data")))
* __attribute__((section (".sram4_data")))
*
* Note that different SRAMs have different access latency due
* to their bus locations. Some peripherals can only read from
* a specific SRAM bank (e.g. BDMA can only read from SRAM4).
*
* Not used in this example, can be removed.
*/
extern char _si_axisram_data;
extern volatile char __axisram_data_start, __axisram_data_end;
LL_AHB3_GRP1_EnableClock(LL_AHB3_GRP1_PERIPH_AXISRAM);
flash_to_mem(
&_si_axisram_data, &__axisram_data_start, &__axisram_data_end
);
extern char _si_sram1_data;
extern volatile char __sram1_data_start, __sram1_data_end;
LL_AHB2_GRP1_EnableClock(LL_AHB2_GRP1_PERIPH_D2SRAM1);
flash_to_mem(&_si_sram1_data, &__sram1_data_start, &__sram1_data_end);
extern char _si_sram2_data;
extern volatile char __sram2_data_start, __sram2_data_end;
LL_AHB2_GRP1_EnableClock(LL_AHB2_GRP1_PERIPH_D2SRAM2);
flash_to_mem(&_si_sram2_data, &__sram2_data_start, &__sram2_data_end);
extern char _si_sram3_data;
extern volatile char __sram3_data_start, __sram3_data_end;
LL_AHB2_GRP1_EnableClock(LL_AHB2_GRP1_PERIPH_D2SRAM3);
flash_to_mem(&_si_sram3_data, &__sram3_data_start, &__sram3_data_end);
extern char _si_sram4_data;
extern volatile char __sram4_data_start, __sram4_data_end;
LL_AHB4_GRP1_EnableClock(LL_AHB4_GRP1_PERIPH_SRAM4);
flash_to_mem(&_si_sram4_data, &__sram4_data_start, &__sram4_data_end);
}
With the linker file:
/* SPDX-License-Identifier: Apache-2.0 AND (0BSD OR CC0-1.0) */
/*
******************************************************************************
**
** File : LinkerScript.ld
**
**
** Abstract : Linker script for STM32H7 series
** 2048Kbytes FLASH, 64Kbytes ITCMRAM, 128Kbytes DTCMRAM
**
** Set heap size, stack size and stack location according
** to application requirements.
**
** Set memory bank area and size if external memory is used.
**
** Target : STMicroelectronics STM32
**
** Distribution: The file is distributed as is without any warranty
** of any kind.
**
*****************************************************************************
** @attention
**
** Copyright (C) 2026 niconiconi.
**
** Modified from stm32h745xx_flash_CM7.ld to stm32h743xx_flash_CM7.ld,
** for STM32H7 support, including project-specific ITCM/DTCM customizations.
**
** This file is free software: you may copy, redistribute and/or modify it
** under the terms of the BSD Zero Clause License, or (at your option)
** Creative Commons Zero v1.0 Universal license. See "SPDX-License-Identifier"
** for more details.
**
** This file is distributed in the hope that it will be useful, but WITHOUT ANY
** WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
** FOR A PARTICULAR PURPOSE.
**
** This file incorporates work covered by the following copyright and
** permission notice:
**
** Copyright (c) 2019 STMicroelectronics.
** All rights reserved.
**
** This software is licensed under terms that can be found in the LICENSE
** file in the root directory of this software component. If no LICENSE
** file comes with this software, it is provided AS-IS.
**
** LICENSE file in the root directory of the origin:
**
** Component: CMSIS Device
** Copyright: ARM Limited, STMicroelectronics
** License: Apache License 2.0
**
******************************************************************************
*/
/* Entry Point */
ENTRY(Reset_Handler)
/* Highest address of the user mode stack */
_estack = 0x20020000; /* end of RAM */
/* Generate a link error if heap and stack don't fit into RAM */
_Min_Heap_Size = 0x200; /* required amount of heap */
_Min_Stack_Size = 0x400; /* required amount of stack */
/* Specify the memory areas */
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 2048K
ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K
DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
AXISRAM (rw) : ORIGIN = 0x24000000, LENGTH = 512K
SRAM1 (rw) : ORIGIN = 0x30000000, LENGTH = 128K
SRAM2 (rw) : ORIGIN = 0x30020000, LENGTH = 128K
SRAM3 (rw) : ORIGIN = 0x30040000, LENGTH = 32K
SRAM4 (rw) : ORIGIN = 0x38000000, LENGTH = 64K
}
/* Define output sections */
SECTIONS
{
/* The startup code goes into ITCM (relocated from FLASH) */
.isr_vector :
{
. = ALIGN(4);
__isr_vector_start = .;
KEEP(*(.isr_vector)) /* Startup code */
. = ALIGN(4);
__isr_vector_end = .;
} >ITCMRAM AT> FLASH
.itcm_text :
{
. = ALIGN(4);
__itcm_text_start = .;
*(.itcm_text)
*(.itcm_text*)
. = ALIGN(4);
__itcm_text_end = .;
} > ITCMRAM AT> FLASH
/* used by the startup to initialize data */
_si_isr_vector = LOADADDR(.isr_vector);
_si_itcm_text = LOADADDR(".itcm_text");
/* The program code and other data goes into FLASH */
.text :
{
. = ALIGN(4);
*(.text) /* .text sections (code) */
*(.text*) /* .text* sections (code) */
*(.glue_7) /* glue arm to thumb code */
*(.glue_7t) /* glue thumb to arm code */
*(.eh_frame)
KEEP (*(.init))
KEEP (*(.fini))
. = ALIGN(4);
_etext = .; /* define a global symbols at end of code */
} >FLASH
/* Constant data goes into FLASH */
.rodata :
{
. = ALIGN(4);
*(.rodata) /* .rodata sections (constants, strings, etc.) */
*(.rodata*) /* .rodata* sections (constants, strings, etc.) */
. = ALIGN(4);
} >FLASH
.ARM.extab (READONLY) : /* The READONLY keyword is only supported in GCC11 and later, remove it if using GCC10 or earlier. */
{
. = ALIGN(4);
*(.ARM.extab* .gnu.linkonce.armextab.*)
. = ALIGN(4);
} >FLASH
.ARM (READONLY) : /* The READONLY keyword is only supported in GCC11 and later, remove it if using GCC10 or earlier. */
{
. = ALIGN(4);
__exidx_start = .;
*(.ARM.exidx*)
__exidx_end = .;
. = ALIGN(4);
} >FLASH
.preinit_array (READONLY) : /* The READONLY keyword is only supported in GCC11 and later, remove it if using GCC10 or earlier. */
{
. = ALIGN(4);
PROVIDE_HIDDEN (__preinit_array_start = .);
KEEP (*(.preinit_array*))
PROVIDE_HIDDEN (__preinit_array_end = .);
. = ALIGN(4);
} >FLASH
.init_array (READONLY) : /* The READONLY keyword is only supported in GCC11 and later, remove it if using GCC10 or earlier. */
{
. = ALIGN(4);
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array*))
PROVIDE_HIDDEN (__init_array_end = .);
. = ALIGN(4);
} >FLASH
.fini_array (READONLY) : /* The READONLY keyword is only supported in GCC11 and later, remove it if using GCC10 or earlier. */
{
. = ALIGN(4);
PROVIDE_HIDDEN (__fini_array_start = .);
KEEP (*(SORT(.fini_array.*)))
KEEP (*(.fini_array*))
PROVIDE_HIDDEN (__fini_array_end = .);
. = ALIGN(4);
} >FLASH
/* used by the startup to initialize data */
_sidata = LOADADDR(.data);
_si_sram1_data = LOADADDR(.sram1_data);
_si_sram2_data = LOADADDR(.sram2_data);
_si_sram3_data = LOADADDR(.sram3_data);
_si_sram4_data = LOADADDR(.sram4_data);
_si_axisram_data = LOADADDR(.axisram_data);
/* Initialized data sections goes into RAM, load LMA copy after code */
.data :
{
. = ALIGN(4);
_sdata = .; /* create a global symbol at data start */
*(.data) /* .data sections */
*(.data*) /* .data* sections */
. = ALIGN(4);
_edata = .; /* define a global symbol at data end */
} >DTCMRAM AT> FLASH
.axisram_data :
{
. = ALIGN(4);
__axisram_data_start = .;
*(.axisram_data)
*(.axisram_data*)
. = ALIGN(4);
__axisram_data_end = .;
} >AXISRAM AT> FLASH
.sram1_data :
{
. = ALIGN(4);
__sram1_data_start = .;
*(.sram1_data)
*(.sram1_data*)
. = ALIGN(4);
__sram1_data_end = .;
} >SRAM1 AT> FLASH
.sram2_data :
{
. = ALIGN(4);
__sram2_data_start = .;
*(.sram2_data)
*(.sram2_data*)
. = ALIGN(4);
__sram2_data_end = .;
} >SRAM2 AT> FLASH
.sram3_data :
{
. = ALIGN(4);
__sram3_data_start = .;
*(.sram3_data)
*(.sram3_data*)
. = ALIGN(4);
__sram3_data_end = .;
} >SRAM3 AT> FLASH
.sram4_data :
{
. = ALIGN(4);
__sram4_data_start = .;
*(.sram4_data)
*(.sram4_data*)
. = ALIGN(4);
__sram4_data_end = .;
} >SRAM4 AT> FLASH
/* Uninitialized data section */
. = ALIGN(4);
.bss :
{
/* This is used by the startup in order to initialize the .bss section */
_sbss = .; /* define a global symbol at bss start */
__bss_start__ = _sbss;
*(.bss)
*(.bss*)
*(COMMON)
. = ALIGN(4);
_ebss = .; /* define a global symbol at bss end */
__bss_end__ = _ebss;
} >DTCMRAM
/* User_heap_stack section, used to check that there is enough RAM left */
._user_heap_stack :
{
. = ALIGN(8);
PROVIDE ( end = . );
PROVIDE ( _end = . );
. = . + _Min_Heap_Size;
. = . + _Min_Stack_Size;
. = ALIGN(8);
} >DTCMRAM
/* Remove information from the standard libraries */
/DISCARD/ :
{
libc.a ( * )
libm.a ( * )
libgcc.a ( * )
}
.ARM.attributes 0 : { *(.ARM.attributes) }
}