Real Time Concerns

[daveythacher]

I looked over the code have a few questions about latency. Rough comments:

• Floating point is likely not required here. There is no FPU on RP2040. (Any number times 100 or 1000 then divided by some other number will be a percentage.)
• How do you stop overflow?
• Do you worry about a few cache misses?
• I saw that tacho and fanpico run on the real time core.
• MB fans can be stalled in main loop.

The last one is probably the most important one. There is a solution to it however I am not sure how much it would matter without moving certain things off flash. Anyhow the networking should not block the feedback loop.

Now on one hand I am guessing you mostly use the temperature control to drive the fan outputs. Why are the tacho status reporting the most critical thing? They do nothing but report data to the user. However the temperature sensors can also be stalled in the main loop.

There is goofy interrupt trick from a timer which could be used here. That would straight this out. I think you could do deadline regulation using this timer to block out the networking and other issues. Without this there is a possibility for CPU, GPU and other components to down clock which would compromise performance. Luckily most hardware will do this automatically as they have some level or real time protection built in.

I have no clue how much deadline regulation is required. However given your current implementation and resource consumption, I am not sure how you can support the features list beyond a certain level of feedback. More than likely the motors can only respond so much. bob-u was suggesting this too you potentially. Therefore I would not push this lower than 0.5mS. As stated by bob-u a smoothing algorithm may be desired in certain cases. I would not get into full on DSP but a simplified PID control loop later on may be a nice feature. The real time dead line however is more important.

[daveythacher]

// Integer
uint32_t get_percentage(uint32_t numerator, uint32_t denominator) {
     numerator *= 1000;
     numerator /= denominator;

     if ((numerator % 10) >= 5)
          numerator += 10;

     return numerator / 10;
}

// Floating point
uint32_t get_percentage(uint32_t numerator, uint32_t denominator) {
     float temp = number * 1.0;
     temp /= denominator;

     return (uint32_t) std::lround(temp * 100.0);
}

[daveythacher]

This would be a worthwhile optimization given things currently. Normally optimizations are recommended but this would be worth your time. (That small company I once knew did not use CRC tables, if I recall. It was in a critical path.) You can simplify some of your structures also, if I had to guess.

[daveythacher]

This was originally written in reflection of a small company I once knew. It may be of interest to you. It is likely of interest to some people on RP2040 also given XIP flash. (Which I actually like since I get 264K on a dual core RP2040. Cortex-M0+ is great for many things but does have its limits.)
https://forums.raspberrypi.com/viewtopic.php?t=348531

[tjko]

Latency has not been big concern since with air (or water) cooling don't really need very quickly reacting system.

I'm aware of the floating point math. Yes, it really should be converted to all integer math (at least on code paths that run often), but so far RP2040 has been 'fast enough' so I haven't yet gotten around to do it. RP2040 is a MCU, but on the other hand its lot more powerful than first PC I used (8MHz 8088 with 256Kb RAM)...

Network stack (in interrupt driven mode) is definitely a problem, if try to do any 'real-time' stuff since it can generate lot of interrupts that can take significant time to complete...

Currently, I'm checking for overflow, when reading MB fan inputs. Since under heavy network load LwIP network interrupts can consume so much time that PWM measurement "fails: (hardware counter overflowed).

With Pico W and TCP/IP stack I was looking to get that running on second core along with the tachometer measurements and driving display. I was thinking I moving all 'non-critical' stuff there and do any time critical stuff on first core.
However, ran into all kinds of issues with the WiFi (that was with SDK 1.4.0), so I reverted that for time-being to 'default' setup... but tachometer reading was left on the second core for now.

Maybe it would be best to put PWM/Temperature measurements onto the second core and have the second core drive the PWM outputs as well. Should be able to make the "control loop" for the fans to run all on second core without interrupts interfering.
While doing all non time-critical (network stack, driving displays, reading tachometers, etc) on the first core.

[daveythacher]

There is a way to avoid the overflow algorithmically.

[tjko]

I changed the PWM reading not to involve any (busy) wait and that brought the latency on the second core main (control) loop down over 10ms. So, now latency on the main loop on second core is in 3ms range (worst case).

[tjko]

Thanks for the pointers.

I've now moved the "control loop" to second core (core1), it does all the reading of inputs and adjusting the outputs.
So far without any optimizations (worst case) latency on the main loop on second core is around 15ms. That would seem to be order of magnitude faster than what I'd think I'll need... However need to take a look optimizing it at some point.

First core is now just doing 'non-critical' stuff i.e. processing the serial console and LwIP stack (WiFi). Main loop (worst case) latency seems to be around 200ms, which would seem to be all down to LwIP stack interrupts taking long time...