![Surprised :o](./images/smilies/icon_e_surprised.gif)
![Confused :?](./images/smilies/icon_e_confused.gif)
Edit by @: https://github.com/rusefi/rusefi_documentation/blob/master/misc/selecting_open_source_ecu_microcontroller.md
Not clear indeed, but looks like no code size limit - the only limitation is to only use XPS100 debug probe.Sync wrote:Well, the toolchain might be free now with the implications of a code size of 16K max from what I can understand, that part is not clear.
Cortex M4 require only 12 cycles to start IRQ handler (it will be cool to see Cortex R4 numbers). I think that the main problem of the current implementation is the software and OS latency. 12kRPM and 60 tooth wheel is not a problem for the slower MCUs and it should not be a problem for STM32F4.kb1gtt wrote:Some key limitations of the STM chip is the IRQ latency. The automotive grade devices generally have latency's that can be down around 5 to 10nS. Which rivals FPGA logic. Granted you still have software delays after that with the point being, the latency can be lower. So how low does the latency need to be? Well that depends on your crank wheel, RPM, ect. The latency we currently get easily allows a 36-2 wheel at 6kRPM. However a bike at 12kRPM and 60 tooth wheel is beyond the abilities of the STM chip. Also a direct injection system with multiple fuel pulses during combustion can also be on the fringe edges of the IRQ latency.
Code: Select all
void TIM2_IRQHandler(void)
{
if (TIM2->SR & TIM_SR_CC3IF) {
TIM2->SR = ~TIM_SR_CC3IF;
GPIOD->BSRRL = GPIO_ODR_ODR_12;
/* 265 ns latency before this line can be executed */
GPIOD->BSRRH = GPIO_ODR_ODR_12;
}
}
First of all, that's off-topic for the scope of this thread.Sync wrote:I think the latency issue is rooted in the RTOS, for a position controller project I had to give up ChibiOS because I could not process ADC data in an interrupt over a few kSPS.
Maybe the discussion should be more in the direction of whether we should try to go to a more event driven framework than the RTOS.
The stm32 boards are out there already. There is just no chance stm32 would be dropped, at least not until we get a major issue caused stm non-automotive grade. And it does not look like one is coming?Sync wrote:I just don't want to waste a lot of time developing on a platform that will be changed in the near future. :/
Sync wrote:That would be 44 cycles when running at 168MHz. Are you sure that you are running at full speed?
Yes, the MCU speed in this test is 168 MHz. But this is not only IRQ latency test it also GPIO latency test. Moreover IRQ handler contains some software stuff needed to be executed before the output pin will be toggled. For example, this code produces only 160 ns latency:kb1gtt wrote:Was that test done with the full speed STM? I seem to recall the Discovery board runs a much slower clock rate. What was the MCU XTAL rate for that test?
Code: Select all
void TIM2_IRQHandler(void)
{
GPIOD->BSRRL = GPIO_ODR_ODR_12;
...
I think calculations may look like this:abecedarian wrote:~168MHz with 160ns latency?
That's like... 1000 cycles?
At 168MHz, 1 cycle is about 6.1 ns, so 160[ns latency] * 6.1 [ns per cycle] = 976 cycles
More interesting, 976 cycles * 6.1ns = 59536ns... almost 6 microseconds.
My math could be wrong though.
TIM2 is also 32 bit timer and seems to be more suitable for capturing slow signals.kb1gtt wrote:TIM1,8 have a max clock of 168, and interface clock of 84MHz. However the test was for the more common timers including TIM2. Which has a max clock of 84MHz and interface of 42MHz. Looks like there are two options for how the IRQ is processed, one is over the DMA2, the other is through the normal bus's. Do we know if this was done via DMA or by AHB1 peripherals? Noted on PG21 found here http://datasheet.octopart.com/STM32F407VGT6-STMicroelectronics-datasheet-12357803.pdf If it was on AHB1, then there might be significant reduction in latency by going DMA.
How many layers do we have between IRQ latency and actual ignition timing? 5? 10 layers maybe? I think focusing on just one part of the total data/event flow is a bit pointless.kb1gtt wrote:I did the 2X thing because I wanted .1 deg accuracy +/- .05 deg. If you go for .1 deg accuracy +/- .1 deg you could remove the 2X thing.
If you have available to you a processor which has modules that can do crank decoding and trigger events with other peripherals/modules autonomously using few, if any, main core processor facilities, would you use it?kb1gtt wrote:... I'm currently at a bit of a loss about why we might support a different chip, other than getting that automotive check box.