Embedded Swift

Evolution Pitches
, , ,
201

I just saw a recent presentation from an Intel engineer about C++ senders and receivers in embedded systems: CppNow 2024 - Keynote: Employing Senders & Receivers to Tame Concurrency in C++ Embedded Systems - Michael Caisse

It's interesting because it feels like Swift would be the presenter's ideal language for embedded development. He makes a case for using async sequences (C++ senders, but Swift's async sequences would work just as well) to deal with the inherently event-driven nature of embedded systems and says the things he values the most in dealing with those challenges are: local reasoning, error handling, and cancellation. Those are all strengths of Swift.

Of particular interest is Intel's groov library, which I think seems to be similar to Swift-MMIO, albeit with larger scope: it has an async interface to registers, so it can also handle remote/nontrivial-latency buses in addition to synchronous MMIO. It can also optimise accesses (e.g. turning RMWs in to plain Ws if you write all the bits), which I suppose is more important for a high-latency interface.

Possibly a future direction for Swift-MMIO?

4 Likes
202

I'm curious what the "async" register IO actually achieves (I should watch the linked talk). On the topic of "e.g. turning RMWs in to plain Ws if you write all the bits". This is a tricky optimization to make because you need to statically know that a particular register has no read side-effect and therefore can elide the read. From my experience with vendor SVD files, they are much less than 100% accurate and I wouldn't trust them to base such an optimization on.

203

groov presents an asynchronous interface for accessing registers. Hardware registers are not always local to the processor's memory bus, they could be on a remote device over I2C, SPI, CAN, or another interface with a non-trivial latency. An asynchronous interface is key to robustly and efficiently accessing registers on remote busses.

It's a generalisation of what swift-mmio does that includes registers in attached peripherals. With groov (which is quite a new, experimental library), the idea is that you declare groups of registers associated with a bus - e.g. registers exposed by a sensor which you communicate with over SPI, and that's the thing that does the reading and writing, and may be sync/async. The library comes with an mmio_bus.

Buses

groov is a library for orchestrating and managing read and write operations efficiently, but it can’t actually perform the reads and writes to hardware. That’s what a bus is for. A bus is groov ​'s interface with lower levels and it is used by read and write . So it has its own read and write API.

To provide for asynchronous behaviour, a bus’s read and write functions return senders. These can of course be async::just_result_of senders in the case of a synchronous operation like memory-mapped IO.

But that's just for registers. The use of detached tasks with async loops to implement interrupt handlers is also interesting.

auto timer_interrupt =
    async::interrupt_scheduler<Timer2Interrupt>{}.schedule()
  | async::seq(groov::write(stm32::tim2("sr.CC1IF"_f = false)))
  | async::then ([](){
      async::timer_mgr::service_task();
    )}
  | async::repeat()
  | async::start_detached()
  ;

This should immediately seem familiar to anybody who has used Swift concurrency. It comes up not infrequently:

Task.detached {
  for try await event in someEventSource {
      // Loops until cancelled by the event source (maybe forever)
  }
}

It may be worth considering whether there are ways the language/standard library could support this pattern. Should we introduce a formal "async event handler loop" concept? (which could be interrupt events on embedded)

1 Like
204

XMOS’ now-deprecated CSP extension to C, XC, also surprised me by having many similarities to Swift’s structured concurrency. If I had endless free time I would try porting Swift to their ISA…

1 Like