Embedded WG meeting, July 30

[japaric]

6-7 PM CEST on #rust-embedded on irc.mozilla.org

Agenda.

• Maintaining the embedded / Cortex-M ecosystem. cf #46. More details will be posted in the issue during the weekend before the meeting.

• "Could we briefly mention talking to chip companies about Rust?" @thejpster

• Triaging issues on the Preview 2 milestone.

• 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.

[johnthagen]

I'd be interested in the topic of CAN communication for embedded-hal and specifically STM32 if that would fit into the discussion.

Possible questions:

• Are there any Rust CAN implementations for embedded devices (even just minimal viable products)?
• Is anyone else pursuing Rust embedded CAN?
• Which STM32 crates would I use if I needed to try to bit-bang it myself? stm32f30x-hal vs stm32f3 vs. ?
• Any roadmap to add support for CAN?

Things I know of:

• rust-embedded/embedded-hal#77
  • (older) rust-embedded/embedded-hal#53
• (Just register defs?) https://docs.rs/stm32f3/0.2.2/stm32f3/stm32f303/can/index.html

Thanks.

[japaric]

Disclaimer: I know next to nothing about CAN

@johnthagen I would suggest creating an coordination issue like #40 first. We can then publicize it during the meeting and / or in the newsletter to increase visibility. However, If you think synchronously discussing CAN during a meeting would be more productive to do first then we can allocate you a time slot in one of the next meetings where you can lead a discussion on the topic of CAN.

Are there any Rust CAN implementations for embedded devices (even just minimal viable products)?

Have you seen / checked https://github.com/UAVCAN/uavcan.rs? (I know it exists but I don't know what's its current state).

Is anyone else pursuing Rust embedded CAN?

The people in rust-embedded/embedded-hal#53 and rust-embedded/embedded-hal#77 are potentially working on CAN, knowledgeable about CAN, or at least interested in Rust support for CAN. Have you reached out to them?

Which STM32 crates would I use if I needed to try to bit-bang it myself?

Bit bang it? I'm pretty sure there are Cortex-M microcontrollers out there with hardware support for CAN which you can use. embedded-hal doesn't contain an interface or API for CAN so using stm32f30x-hal or stm32f3 won't make too much difference (same starting line) when it comes to building a CAN stack.

Any roadmap to add support for CAN?

The top priority for the WG is the 2018 edition milestone. The 2018 edition marks the beginning of stable support for embedded Rust and it's by no means the point where "Rust, the language and its library ecosystem, has a solution for every single embedded use case". Rather it's a point where the foundation is stable enough to develop a rich ecosystem of libraries.

As such the WG is not leading any effort towards creating solutions for any specific communication protocol. However, we encourage individual efforts around creating such solutions and are happy to assist with increasing visibility (cf. projects and help wanted sections in the newsletter) and communicating needs (e.g. feature / API X being unstable prevents my crate from working on stable) to the language and library teams.

[japaric]

As such the WG is not leading any effort towards creating solutions for any specific communication protocol.

I should clarify that here I meant "not leading any effort at this time". After we are done with the 2018 edition we'll spent some time discussing what should we focus on next.

[johnthagen]

Bit bang it? I'm pretty sure there are Cortex-M microcontrollers out there with hardware support for CAN which you can use.

Sorry, "bit bang" was entirely the wrong verb to use. I meant manually writing bits into configuration registers specific to a microcontroller as opposed to using some kind of higher more-generic CAN HAL API.

However, If you think synchronously discussing CAN during a meeting would be more productive to do first then we can allocate you a time slot in one of the next meetings where you can lead a discussion on the topic of CAN.

Thanks for all of the info, suggestions and links (I hadn't found UVCAN at all yet!). I agree that with 2018 edition coming up, this isn't the best time to allocate meeting resources to CAN. But thanks for the consideration!

[japaric]

Maintaining the embedded / Cortex-M ecosystem. cf #46. More details will be posted in the issue during the weekend before the meeting.

I've written an RFC on the topic: #130. Let's discuss it in the meeting. If you can't make it to the IRC meeting leave a comment on the RFC PR. If you can comment before the meeting that would be ideal; if not don't worry we'll continue to accept suggestions and address concerns for at least a week before officially accepting the RFC.

[japaric]

This meeting happened! The logs are here and there are some notes here. The issue for the next meeting is up at #149