#hardware #stm32f4 #driver #sensors #reusable #composable #devices

bin+lib multi-mission-library-rs

This crate is designed to hold composable, reusable driver code / wrappers for various sensors and hardware output devices. Currently it does not support differing STM32 models and only supports the STM32F4, however moving into the future that will be the plan.

3 releases

0.1.2 Feb 13, 2024
0.1.1 Feb 13, 2024
0.1.0 Feb 11, 2024

#387 in Hardware support

Download history 119/week @ 2024-02-12 50/week @ 2024-02-19 47/week @ 2024-02-26 12/week @ 2024-03-11 52/week @ 2024-04-01

52 downloads per month

MIT license

26KB
548 lines

Multi-Mission Library (rs)

This crate is designed to hold composable, reusable driver code / wrappers for various sensors and hardware output devices. Currently it does not support differing STM32 models and only supports the STM32F4, however moving into the future that will be the plan.

Repo Structure

Top Level

The top level modules within the src directory are for the different categories of devices which may need driver code. Currently there is only a sensor module, but some other examples would be stepper_motor, servo, display, etc.

2nd Level

Within the top level modules, there are more specific modules that are still somewhat generalized. Examples of modules which could go within the sensor module are barometer, imu, magnetometer, etc. These modules each define at least one trait to define the behavior which all submodules within them will follow. For example, wihtin the barometer module there is a Barometer trait which defines functionality that is used by all barometers, such as reading the pressure, temperature, and determining altitude.

3rd Level

Within the next level of nesting, we have modules for specific hardware. For example, at sensor::barometer::bmp180 we have a module specifically for the BMP180 barometric pressure sensor. This module implements all of the traits defined in the modules above it, so in this specific case it would implement the Sensor and Barometer traits. This allows for extremely predictable functionality, and for switching between physical sensors without having to change any code (assuming there is already a driver written for the new sensor).

Additional Comments

Of course everything previously described are simply the initial guidelines which are set out by one person (myself). The code structure and guidelines will (and should) shift as more people begin to contribute to this crate, and as different subteams use this code for their projects.

To see a template repo of how to set up the toolchain for programming an STM32 with Rust, take a look at this link

Blackpill Development Board Special Notes

Serial:

While the board does include a USB port, I have not yet been able to get it to enumerate as a USB device in windows. For now, an external FTDI serial to uart bridge will be used for USB comms. For this to work, the clock rate must be set to 25MHz.

Dependencies

~54MB
~1.5M SLoC