Embedded WG Meeting, March 12th

[jamesmunns]

8-9 PM CET (Berlin time) on #rust-embedded on irc.mozilla.org

Public Google calendar that includes these weekly meetings

Agenda.

• Reminders / announcements

  • RFC: Forming the Ecosystem Team
  • RFC: Hibernation
  • RFC: Core Team
  • Resource Team Membership

• Issues nominated for discussion, if any

• [your topic goes here]

This meeting is open for anyone to attend. If you'd like to bring up any issue / topic related to embedded Rust leave a comment in this issue so we can add it to the agenda.

[therealprof]

• Discuss logistics around minor version bumping the whole Cortex-M crate chain

cc @rust-embedded/cortex-m

[Yatekii]

The nrf52 devices (likely the other Nordic devices as well) have a DMA controller which can't access ROM. So to transfer data via DMA, the buffer from or to which you copy have to reside in RAM.

We discussed, how we should handle this circumstance. There is two fixes for this:

• Check if the buffer resides in RAM (RAM address range) and if it does not, copy it to a buffer in RAM.
• Check if the buffer resides in RAM; if it does not, return an error.

What is more of an issue too, is implicit batching. At the moment, the proposed solution does not only copy to a RAM buffer, but also automatically batches if the maximum DMA transfer size is exceeded with the given buffer.

This is the issue where I started the discussion: nrf-rs/nrf-hal#37.
While the implicit copy is convenient in most cases, it can cost you a lot of time and nerves in the cases it isn't.
This is for example the case when you want to stream perfectly timed data over UART/SPI. On the nordic devices, there is a measurable gap between two batched transfers. This is really bad if you need exact timing.
The same goes for the implicit copy, which can cost you a lot of time (even tho memcopy is cheap) which you wouldn't want in some cases and you could have put the buffer in RAM beforehand.

So since the nrf52 team couldn't agree in favor of one solution, I am raising a general question to be discussed in the meeting:

Should basic HAL functions, especially embedded-hal implementors do implicit stuff (copy, batching, etc) or should they notify the user and request them to handle the error on a case by case basis?

Maybe @rust-embedded/hal could have a look at the already had discussions in the issue and also make themselves an opinion of it.

Thanks.

[Disasm]

This meeting happened! The logs and minutes can be found in #333.

The agenda for the next meeting is at #334

[Yatekii]

I think my item got missed last time ;)