Considered all 4 approaches from examples:

1. Using sysclock - simplest and runs without problems
2. Using timer5 - as simple as sysclock but the timing was much less accurate - need more research
3. Using interrupts - Easiest way to make some code asynchronous. Interrupts need an unsafe clausure- was advised not to use this solution.
4. Using DWT - Simmilar to the first 2 but gives more options with stopwatch "lap times" and measuring ticks as time. A bit more complicated.

I chose the 1 approach becouse of simplicity. DWT seem the most usefull though.

Looks like there are no crates that handle GPS communication, so we will need to write our own. We will be using ublox NEO-7M gps.

• example C implementation for ublox
• Rust nmea parser

I know a couple of ways to achieve concurrency:

• threads - not available with #![no_std]
• raw Interrupts - complex, feels like there is a proper abstraction missing, see stm32f4xx-hal example
• async - easy to use, but lack ability to add priorities to tasks
• cortex-m-rtic - provides a nice abstraction for interrupt based tasks. This seems awesome and mature enough for our use case. See rtic-* examples in stm32f4xx-hal

Further reading

• Concurrency Patterns in Embedded Rust - Ferrous Systems
• async/await on embedded Rust - Ferrous Systems

Design notes

• Configured usart3
• Added usart3 interrupt handler that reads data into static ringbuffer
• Added a loop in idle task that reads messages from ringbuffer and logs them

Related issues

• #5

closes #2

Design Notes

• This PR adds a CI that builds, formats, and lints the code for every PR.
• It leverages cargo-make crate to allow building all the crates from workspace root. cargo make build changes directories before building particular crates, so it uses their .cargo/config.toml, as opposed to cargo build.
• I also added a new cargo-make task called embed to cansat-stm32f446 crate that runs cargo embed, but changes the default log level to info.

RTIC - Real-Time Interrupt-driven Concurrency framework for ARM Cortex-M microcontrollers

Related issues

• https://github.com/grupacosmo/cansat/issues/11

https://github.com/knurling-rs/defmt

It supports multiple logging levels that you can set using env variables. It's especially useful for disabling logging entirely in release builds. defmt is also great for performance, as it defers formatting to the host machine

Led should blink every 1 second. See stm32f4xx-hal for examples. There are 4 blinky examples as there are multiple ways you can implement delays: dwt, timer, syst and irq. Do a little research, chose one implementation and explain the differences in the PR.

What we want is something of this structure: https://github.com/actions-rs/example/blob/master/.github/workflows/quickstart.yml, so check, fmt, clippy and maybe test.

Cargo is a bit primitive as it doesn't support building all crates from root in a single command if they target different platforms. We could use cargo-make to define proper build tasks and simplify CI scripts.

GPS will frequently trigger interrupts because there is a constant stream of data. This will waste precious CPU cycles.

Useful resources

• https://dev.to/apollolabsbin/stm32f4-embedded-rust-at-the-hal-dma-controllers-daf
• https://docs.rust-embedded.org/embedonomicon/dma.html

We need to be able to send data such as position, altitude and whetever we will find useful.

I think we should use SX1276 or similar lora module. There are multiple libraries and examples for this particular module such as sx127x_lora.

We need an SD card for persistent logs during the flight. There is a embedded-sdmmc crate that we should use, it even supports logging through defmt crate. Latest release is quite old, we'd need to download the crate directly from github to access defmt-log feature.