Using resumable functions with RTOS (ThreadX)

[ClemensElflein]

Hello,
I'm trying to use modm with an RTOS (ThreadX) on STM32H7. I'd like to use ThreadX, because I have a somewhat stable Ethernet implementation working using ThreadX and NetxDuo.

I'm currently looking into device drivers (specifically I2C EEPROM) and I see that you are using Protothreads. Basically what happens is the I2C Master processes a transaction through ISR (which is a nice implementation), but in parallel the protothread basically busy waits for the transaction to finish (because my other threads are ThreadX threads and not protothreads).

ThreadX supports time slicing, so my code works, but if I'd be able to actually use ThreadX primitives to wait for the transaction to finish (event flags), ThreadX would not need to do time slicing but instead knows that the IO thread is still blocked.

I'm not sure how hard it is to implement this and how to go about it. I'd appreciate some input!

Thank you so much for this great project!

[ClemensElflein]

My current solution is like this (but this way I cannot use I2cDevice and therefore also not the modm-provided device drivers), but it at least works well:

I wrap the I2cTransaction and provide a blocking wait function:

namespace modm {

template <class Transaction> requires std::derived_from<Transaction, I2cTransaction>
class TxI2cTransaction : public Transaction {
 public:
  explicit TxI2cTransaction(uint8_t address) : Transaction(address) {
    tx_semaphore_create(&sema, "i2c_sema", sizeof(sema));
  }

  virtual ~TxI2cTransaction() { tx_semaphore_delete(&sema); }

  void detaching(I2cTransaction::DetachCause cause) override {
    Transaction::detaching(cause);
    tx_semaphore_put(&sema);
  }

  bool isBusy() {
    blockingWait();
    return Transaction::isBusy();
  }

  void blockingWait() { tx_semaphore_get(&sema, TX_WAIT_FOREVER); }

 private:
  TX_SEMAPHORE sema{};
};

}  // namespace modm

Then I use the I2cMaster to write my transaction (here an EEPROM read):

  modm::TxI2cTransaction<modm::I2cWriteReadTransaction> tx{EEPROM_ADDRESS};
  u_int8_t address = MEMORY_ADDRESS;
  tx.configureWriteRead(&address, 1, buf, sizeof(buf));
  Board::id::I2C::start(&tx);
  tx.blockingWait();
  // Here I have my result in the buffer and can check the success using the tx.

I feel like there is a better solution though

[salkinium]

I'm afraid modm doesn't support yield hinting in any way, it's purely based on polling. modm was never meant to be used in an RTOS, since most RTOS have their own HAL. You can only hack the I2C implementation to add the semaphore into the driver.
Does ThreadX not have it's own HAL for STM32H7? modm doesn't support a lot of the advanced peripherals on the H7.

It's something I want to change with the stackful fiber scheduler, but progress is slow.
For FreeRTOS, there recently was a PR that added FreeRTOS specialization for UART buffers, something like this would be needed for other RTOS as well.

[ClemensElflein]

Thank you for the quick reply!

Unfortunately ThreadX does not come with HAL and I dislike the STM32 CubeMX HAL. I really like the way modm is structured with the code generation.

Thank you for the hint at the fibers, since it reuses the same macros i.e. RF_WAITWHILE( something() ), the yielding will just round-robin call the something() all the time resulting in polling again, whereas with a "real" RTOS implementation we could just use a semaphore.

I have also looked at the FreeRTOS buffer code already, basically in order to have good RTOS support we'd need to do it for all peripheral drivers.

So basically I have three options now:

• Use modm with polling and only have two RTOS tasks (one ethernet with high priority, one for everything else with lower priority)
• Add ThreadX support to modm (which is probably not possible for me for all the architectures, so this would probably result in a modm fork which gets out of sync at some point), I don't really like this
• Use some other HAL implementation

Do you by any chance have experience with a good HAL for STM32H7? I've tried Zephyr and RIOT but I had a hard time modifying both of them to work with a custom board (especially ethernet with a non-standard PHY; Edit: The issue with RIOT is, it doesn't support the H7 at all). Modm's modularity looked promising to me and I got up and running fairly quick.