Use with ThreadX - SysTick conflict

[rsgrimes]

I am trying real hard to use modm with ThreadX, but I'm running into a conflict with the SysTick Handler. ThreadX really wants to use SysTick for its RTOS tick, and modm seems to really want it too for low-level busy waits. Has anyone run into this problem, and more importantly, worked out an acceptable solution?

[salkinium]

Yes, use any other timer to provide ms and us time. The systick module is optional and you should be able to provide your own now() functions.

However, keep in mind that modm is polling based and RTOSes are not, so I wouldn't expect a great experience of integrating ThreadX and modm. Doesn't ThreadX have it's own HAL?

[rsgrimes]

Thanks for your prompt answer! I'm not sure what you mean by "Yes, use any other timer to provide ms and us time" - is that for modm or for ThreadX? I am new to both, and I think ThreadX assumes SysTick is for itself, but that might be changeable.

Yeah, so the systick module (you do mean in modm, right?) is indeed optional, though pulling in something as simple as modm:platform:gpio will pull in src/modm/platform/clock/systick_timer.cpp into the generated modm CMakeLists. I was at first hoping to just use SysTick for ThreadX and forego any modm-level timing facilities, but maybe that is not wise. I suppose I could use a simple timer that is likely otherwise unused, so that is probably my workaround; the only question is whether that is used by mbed or by ThreadX - right now, it seems mbed is pretty strongly tied to SysTick - hopefully, ThreadX can use another...

Ultimately, of course any RTOS is not polling, but I would think modm is also not - except at the very lowest levels, as your blog post on the ns-level timing facilities describes in great detail. I do expect a great experience mixing the two, however, as I would not be using the polling-based times except where they are needed. In particular, none of my application code would use the modm facilities; only the low-level hardware drivers that you discussed in that post. The only issue, in my mind, is making sure both can co-exist peacefully. It seems systick_timer.cpp gets pulled in by pretty low-level modm modules, so SysTick a hard requirement for mdom?

Finally, ThreadX doesn't have its own HAL, and in my opinion, it shouldn't; an RTOS should be above the hardware level - except for its basic time and cpu-level requirements. I am hoping modm will serve as that layer for ThreadX and device drivers, as I'm hoping it provides more abstraction than using vendor libraries and some home-grown layer on top of those libraries. I notice how modm does (optionally) provide lightweight facilities that extend into the "OS kernel" realm, but my app is more involved and really is better suited to a full RTOS. That said, I really, REALLY like what mbod's core philosophy is - generate a custom HAL that provides a great deal of "misuse prevention", and I really want to prove it a better solution to other alternatives.

[salkinium]

I would perhaps recommend that you start by using our stackful, cooperative, round-robin scheduled fibers and then if you run into timing issues, you can upgrade to using a few preemptive threads with our the integrated FreeRTOS port.

While it would be an interesting academic project to do so, I don't think that you should be nesting a cooperative fiber scheduler inside a preemtive RTOS scheduler unless you have a specific reason and a whole lot of extra time for debugging on your hands. Especially using an RTOS without a HAL specifically designed for it makes no sense to me as you combine the problems of preemtive scheduling, namely the lack of defined yield points, with all of the disadvantages of cooperative scheduling, namely the lack of low latency response to events.

Take this from someone who debugs[1] and traces [1][2] the NuttX RTOS inside the PX4 Autopilot for a living.

[rsgrimes]

I have no interest in nesting a cooperative scheduler within a preemptive RTOS scheduler! Given I have given you the wrong impression when answering your "However" statement, it seems we're not speaking quite the same about this - a so-called "failure to communicate" situation! No worries, though, as I've resolved this.