changed 3 years ago  
Linked with GitHub

Embedded Working Group Meeting 2022-10-25

Attendance

Write your GH username or Matrix handle here!

  • therealprof
  • cr1901
  • dirbaio
  • eldruin

Agenda

  • Announcements
    • svd2rust: Lots of activity, v0.27.x released. 🎉
    • IRC bridge has been restored
  • critical-section follow-up
    • Hacky solution for the MSP430 bloat on the horizon, watch the space.
    • No new insights on potential ordering problems for Cortex-M
  • Interrupt handles for async HAL development
    • Approach currently under testing. Feedback still sought after…
      Image Not Showing Possible Reasons
      • The image file may be corrupted
      • The server hosting the image is unavailable
      • The image path is incorrect
      • The image format is not supported
      Learn More →
    • Documentation has improved since last week: https://github.com/datdenkikniet/cortex-m-interrupt
  • embedded-hal
    • No news but maybe we can push for 1.0 until the end of the year
  • Blog
    • Has been dormant for a while. 😢 Would be nice to get back into the game…

Last Week's Minutes

  • Announcements
    • IRC bridge currently broken both ways
  • Cortex-M
    • Does the cortex-m critical section implementation have the problem described in https://github.com/rust-embedded/riscv/issues/116?
      • The implementation is basically the same:
      • But, it's not clear it can cause an actual problem
      • Since interrupt::disable is safe, an interrupt could disable interrupts
        in between acquire() checking if interrupts are enabled and disabling them,
        so release() would re-enable interrupts
      • However, any code inside the critical section could also disable interrupts and they'd get re-enabled afterwards, and in general code shouldn't rely on being able to disable interrupts with disable() and having them stay disabled forever after
      • So, it doesn't seem like this should cause issues on cortex-m
  • svd2rust
  • Interrupt handles for helping async HAL development (@korken89)
    • At work we have been (slowly) adding experimental async support over multiple HALs and noticed that generic interrupt allocation for async drivers is lacking in the ecosystem
    • We see our PoC as an extension to the existing interrupt allocation in cortex-m-rt
    • Trying to find an agnostic an interrupt and getting a handle to register a hander to it, so HALs can depend on the trait provided and know they can get interrupt allocated via the interface.
    • PoC: https://github.com/datdenkikniet/cortex-m-interrupt
    • Based on embassy's take! macro but with a different take
Select a repo