# Oxidize `impl days` main document

# Where

https://oxidizeconf.com/oxidize-chat and the projects platforms

## Time

Anytime you want to work.

There will be an intro event at [10:00 UTC](https://everytimezone.com/s/28431c3b) on our youtube channel, where we present projects. This will be recorded.

Florian Gilcher will be the host on Sunday and Monday!

## Projects

### GD32V + probe-rs = ❤️
**What?** Add support for GD32VF103 RISC-V chips in probe-rs
**Why?** Tooling for GD32V chips is not perfect, usually a custom openocd fork is the only choiсe. We want to change this.
**When?** 12:00-01:00 UTC on Sunday and Monday
**Platform:** Matrix
**Contact:** @disasm-ewg:matrix.org
**Hardware requirements:** You will need a GD32V-based board (LonganNano, GD32VF103C-START or others) and a compatible probe (FTDI-based or CMSIS-DAP-based).
More details:
First we need to do either of both of the following:
* implement support for FTDI-based adapters
* implement support for JTAG interface of CMSIS-DAP adapters

FTDI adapters are more common, but require more work to support them in probe-rs. CMSIS-DAP adapters are less common, but it's potentially possible to make one out of the BluePill board.
probe-rs support for a compatible probe is one of the steps. The next step is to implement flash algorithm (or find one that is compatible) and fix issues with the GD32V debug interface.
See also https://github.com/probe-rs/probe-rs/issues/189
**Current status:** FTDI support almost works (https://github.com/probe-rs/probe-rs/pull/313)

### ITM for probe-rs
**What?** Finalize ITM support for probe-rs. Also implement ITM support for CMSIS-DAP and J-Link possibly.
**Why?** ITM is a great way to trace your ARM cores activities and probe-rs is the perfect place to implement this!
**When?** 12:00-01:00 UTC on Sunday and Monday
**Platform:** Matrix
**Contact:** @Yatekii:matrix.org, @adamgreig:matrix.org, @bcantril:unix.house

**Current Status Document:** https://hackmd.io/YYt7eNJTQXubXm6DjeDCeg
**Coordination Room:** Matrix Room #OC2020-ITM-probe-rs:chat.berline.rs

### Fixing various issues around probe-rs
**What?** We have many open issues with proposed improvements but also small bug reports (https://github.com/probe-rs/probe-rs). Pick one that suits you best :) If you are still unsure, just come ask, we are happy to help you and get you started!
**Why?** Having a bugfree library is key and we can all profit of it!
**When?** 12:00-01:00 UTC on Sunday and Monday
**Platform:** Matrix
**Contact:** @Yatekii:matrix.org

### Adding docs to probe-rs
**What?** The guides on https://probe.rs cound use some improvements. Also the rustdocs could use some more elaborate explanations of the various errors and function intricacies we have. While writing docs may not be very appealing, it's very vital and even if you are not into the project much yet, you can contribute your experiences to the guides :)
Ferrous wrote an awesome troubleshoot guide for their workshops which could be used as a starting point for adding extended information on certain errors: https://github.com/ferrous-systems/embedded-trainings-2020/blob/main/embedded-workshop-book/src/troubleshoot-cargo-flash.md
**Why?** Having a bugfree library is key and we can all profit of it!
**When?** 12:00-01:00 UTC on Sunday and Monday
**Platform:** Matrix
**Contact:** @Yatekii:matrix.org

### Add Microchip (Atmel) EDBG and ATSAME support to probe-rs
**What?** To enable probe-rs for the ATSAM line of MCUs, we need to add support for the Atmel Embedded Debugger (EDBG) that come with many of these boards. The debugger is based on CMSIS-DAP, but uses a non-standard report size as well as possibly other differences that need to be ironed out. We will also add target support for the ATSAMD5x and ATSAME5x as a start.
**Why?** To enable probe-rs on even more targets.
**When?** 10:00-16:00 UTC on Sunday
**Platform?** Matrix
**Contact:** @jgust:matrix.org

#### Status @ 2020-06-19 15:30

SAMD51, SAME51, SAME53 and SAME54 targets were added.

Probe-rs connects to the EDBG debugger successfully. `cargo-flash`, `probe-rs-cli reset` and `probe-rs-cli dump` all seem to work, while `probe-rs-cli info` fails. More testing and debugging before this can be sent as a PR but its a good start. The code can be found [here](https://github.com/probe-rs/probe-rs/pull/308). This was tested on a SAME54-XPro board.

### Embedded Rust for Hobbiests (Codename: Patina)
**What?** Start the process for implementing some of the ideas in the slides in the link below
**Why?** There seems to be some consense that this is a good idea. The first steps is reviewing what needs to be done and what organisation needs to be done for future work
**When?** 00:00-17:00 UTC on Sunday & 07:00-17:00 UTC Monday
**Platform:** Matrix ([Tristan's Speaker Chat](https://matrix.to/#/!QUPHrbBlIBMegNuBYh:chat.berline.rs?via=chat.berline.rs&via=matrix.org&via=andvision.se)) and Github
**Contact:**
* @tl8:matrix.org
* @darneas:matrix.org (can also help you get started after 12:00 UTC)

**Reference / Working Documents:**
* Coordination Repo: https://github.com/tl8roy/patina
* More details: https://docs.google.com/presentation/d/1XJdM1ZhFA2RbumnIgHLvUFZNUB2PGNtzoQEsGe5a-Q0/edit?usp=sharing

### Implement the LE Security Manager for [Rubble](https://github.com/jonas-schievink/rubble) (the pure-Rust BLE stack)

**What?** Implement more parts of the LE Security Manager (tracked in issue [#36](https://github.com/jonas-schievink/rubble/issues/36)).
**Why?** Rubble now has support for P-256 cryptography thanks to Tony's work on RustCrypto, so more progress on the LE Security Manager can be made. This will eventually allow pairing a Rubble device with another device, as well as securely exchanging messages between them.
**When?** Until 20:00 UTC on Sunday, 9:00-20:00 UTC on Monday
**Platform:** Matrix, GitHub
**Contact:** @jschievink:matrix.org

More details:
- The Bluetooth Core Specification describes how the LE Security Manager work and is available here: https://www.bluetooth.com/specifications/bluetooth-core-specification/
- The existing stub implementation of the LE Security Manager is [here](https://github.com/jonas-schievink/rubble/blob/b040194c79b4ece318aa956aacdc79bc2e006dfa/rubble/src/security.rs).
- Rubble currently supports nRF52 and nRF51 chips, so if you participated in one of the Workshops you already have hardware you can use.

### Implement Access Address generation for Rubble

**What?** Access Addresses are created by a device that wants to initiate a connection. They need to follow specific requirements detailed in the spec and the corresponding issue, [#16](https://github.com/jonas-schievink/rubble/issues/16).
**Why?** Rubble is currently not able to initiate a connection on its own, it is only a Peripheral-side stack. Fixing this issue is one of many things that need to be done to support this.
**When?** Until 20:00 UTC on Sunday, 9:00-20:00 UTC on Monday
**Platform:** Matrix, GitHub
**Contact:** @jschievink:matrix.org

### Show of the effect of multiple optimization passes
**What?** Generate diffs for the MIR after applying multiple optimization passes
**Why?** Right now you can only generate the diff of a single pass or the state before/after a single pass, there's no way to autogenerate a diff between multiple passes
**When?** 09-15 CET Monday
**Platform:** Matrix and [zulip](https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/hello/near/203783033)
**Contact:** @oli-obk
More details:
* [How the MIR output is tested in Rust CI](https://github.com/rust-lang/rust/blob/master/src/test/mir-opt/README.md)

This is done now: https://github.com/rust-lang/rust/pull/74715

### Visualize the effect of optimization passes as a graphviz graph
**What?** Generate a graphviz graph that contains red and green parts showing which basic blocks and edges were removed by certain optimizations and which ones were added
**Why?** Sometimes MIR can get very complex and analyzing it in a textual manner just isn't that helpful
**When?** 09-15 CET Monday
**Platform:** Matrix and [zulip](https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/hello/near/203783033)
**Contact:** @oli-obk
More details:
Some flags for the rust compiler to generate graphs

-Z dump-mir-dataflow=val -- in addition to `.mir` files, create graphviz `.dot` files with dataflow results
-Z dump-mir-graphviz=val -- in addition to `.mir` files, create graphviz `.dot` files
-Z          unpretty=val -- present the input source, unstable (and less-pretty) variants;
        `mir` (the MIR), or `mir-cfg` (graphviz formatted MIR)

### no_std async-h1

**What?** port async-h1 to no_std environments
**Why?** async HTTP support in environments without a heap is basically non-existant, async-h1 can change that
**When?** 12:00-20:00 UTC on Sunday and Monday
**Platform:** berlinrs matrix or https://discord.gg/JvZeVNe
**Contact:** @skade
More details:
https://github.com/http-rs/async-h1/
https://discord.gg/JvZeVNe

### Improving onboarding for new users

**What?** Improve documentation for new embedded rust users.
**Why?** Right now, it seems to not be clear where a new user should start. The official documentation (the discovery book etc.) shows low level setup, but I'm of the opinion that one should try to use a HAL directly.
**When?** 10:00-20:00 UTC on Sunday and Monday
**Platform:** matrix
**Contact:** @thezoq2 https://matrix.to/#/!TyTDZBLESDWANougNn:matrix.org?via=matrix.org
More details:
I think our first step should be to write a "discovery book" that directly jumps into using HALs. A book might be out of scope for 1.5 days, so I'll start off with a blog post. If someone else wants to join, we can be a bit more ambitious :).
There are also a number of other issues that could be fixed: Updating awesome-embedded-rust to clean up old stuff and add new drivers etc. ([partially done](https://github.com/rust-embedded/awesome-embedded-rust/pull/288))

### Neotron

Have you heard of Monotron - the ARM microcontroller based, Rust-powered 1980s style home computer? Perhaps you saw the talks at RustFest Paris, Rust Belt Rust 2018, or RustConf 2019? Well Neotron is Monotron Mk2, and there's lots to do!

The goal is a family of open-source PCBs which all run the same OS - the Neotron OS. This OS is pretty bare bones - think early versions of MS-DOS. The portability across boards is handled through the use of ARM Cortex-M4 and higher MCUs, and the Neotron BIOS. The Neotron BIOS is the hardware abstraction layer, and provides a C foreign-function-interface API for the OS to use - must like the IBM PC BIOS (and the CP/M BIOS) provides simple APIs for MS-DOS (and CP/M respectively) to use.

Neotron lives at https://github.com/neotron-compute. The developers hang out in the Neotron chat room on Matrix (https://app.element.io/#/room/#Neotron:matrix.org)

#### Availability

I @thejpster (https://github.com/thejpster or @thejpster:matrix.org) will be around from 10am to 5pm British Summer Time (11:00 UTC to 18:00 UTC).

#### What needs to be done?

1) We use an embedded FAT32/SD card library - https://github.com/rust-embedded-community/embedded-sdmmc-rs. This currently has support for basic embedded-hal blocking SPI interfaces, but that's it. I'd love to see a BlockDevice implementation for peripherals that drive a full 4-bit SD interface, like you get on an STM32. It might also be useful to think about how it might be improved to work in an async context, with an async embedded-HAL (if such a thing exists?).

2) USB Host support. There is good progress on USB device support, but it would be great if you could plug a USB keyboard or USB flash drive into your Neotron (or any other embedded Rust system). There are lots of good C examples around - some open source, some manufacturer proprietary.

3) Porting the BIOS. There are two BIOS implementations so far, in fairly early state (basic serial and/or video only). It might be interesting to see how much of the BIOS API you can implement for a board of your choice. See https://github.com/Neotron-Compute/Neotron-XXX-BIOS as a template, plus the implementations for the Neotron 32 (a TM4C123) and the Neotron 340ST (an STM32F7 Discovery).

4) There's a PC keyboard driver crate - https://github.com/rust-embedded-community/pc-keyboard. This doesn't handle the very lowest layer of communication with a keyboard (PS/2 or USB), instead it handles the scan-codes that keyboards generate and converts them to Unicode characters or key events. It supports QWERTY UK and US keyboards, and there's a PR for AZERTY keyboards, but it would be great to see some more.

# Progress reports

* [ITM Probe-rs / JLink SWO+ITM](https://hackmd.io/YYt7eNJTQXubXm6DjeDCeg?both)
* [GD32V + probe-rs = ❤️](https://hackmd.io/brhn32aVRkaWK2sADCp_Rw)
* Embedded Rust for Hobbiests [coordination repo](https://github.com/tl8roy/patina/issues)

## Progress report for the onboarding project.

We started writing a [hal-discovery](https://hackmd.io/zeFhRHtYSxOzyB-F_sP91A) document, inspired by the Discovery book but using a HAL. So far, we show how to set up a project, get `cargo flash` running, and turning on an LED. We decided to write it for both the blue-pill and f3discovery boards, since it was the hardware we had on hand, and to highlight the differences and similarities that may be present between boards.

We also ended up finding some issues in the documentation of both crates that we have addressed https://github.com/stm32-rs/stm32f1xx-hal/pull/249 and https://github.com/stm32-rs/stm32f3xx-hal/pull/117