# px4flow_bsp
Rust no_std embedded hal board support package for the PX4FLOW optical flow sensor hardware.
## Embedded Examples
The examples are designed to be used with a debug probe that supports J-Link / RTT.
We provide a couple different ways to run these:
- With the Segger tools (This is currently the default.)
- With [probe-run](https://crates.io/crates/probe-run) (This is WIP and may not work as expected.)
#### With the Segger tools installed
- Edit [config](.cargo/config) to select the `segger.gdb` runner
- In one shell run: `./start_gdb_server_jlink.sh`
- In another shell run: `JLinkRTTClient`
- Then run your choice of examples
#### With probe-run installed
- Edit [config](.cargo/config) to select the `probe-run` runner
- Run the example (see below) with a JLink debug probe attached to your PX4FLOW
- Note that RTT output to the terminal may be significantly slower than with the Segger tools.
### Running examples
```shell script
cargo run --example play --features rttdebug
```
### Interrupt Handling
Currently you need to configure your application to forward interrupts from app-level
interrupt handlers, ie:
```rust
/// should be called whenever DMA2 completes a transfer
#[interrupt]
fn DMA2_STREAM1() {
// forward to board's interrupt handler
unsafe {
(*BOARD_PTR.load(Ordering::SeqCst)).handle_dma2_stream1_interrupt();
}
}
/// should be called whenever DCMI completes a frame
#[interrupt]
fn DCMI() {
// forward to board's interrupt handler
unsafe {
(*BOARD_PTR.load(Ordering::SeqCst)).handle_dcmi_interrupt();
}
}
```
This assumes you are using the [cortex-m-rt crate](https://crates.io/crates/cortex-m-rt)
to construct your embedded application, and using its `#[interrupt]` to handle interrupts.
## Status
Work in progress
- [x] Does not overwrite the default PX4FLOW bootloader that typically ships with the board
- [x] Example that sets up DCMI to read from the camera
- [x] Support for spi2 (l3gd20 gyro)
- [x] Support for i2c1 (offboard i2c communication)
- [x] Support for i2c2 (MT9V034 configuration port, and eeprom)
- [x] Support for USART2, USART3, and UART4 (sonar)
- [x] Support for serial eeprom on i2c2
- [x] Initial setup of DCMI peripheral
- [x] Initial setup of DMA2
- [x] Mostly working DCMI->DMA2-> image buffer pipeline
- [x] Support for running examples using probe-run
- [ ] Support use of 120x120 flow frame (bin 4 of 480 height)
- [ ] Support configurable / full-frame image buffers (currently limited to 64x64)
- [ ] Support use of full 10 bpp grayscale resolution of MT9V034
## Notes
- The only supported mode for debugging is RTT with the `rttdebug` feature. This is because
the PX4FLOW 1.x and 2.x boards only make the SWD interface available (no easy ITM solution).
- The `breakout` feature is intended for library development and debugging purposes.
Currently it's setup to work with the "DevEBox STM32F4XX_M Ver:3.0" board (STM32F407VGT6), which does not
include a l3gd20 gyro or eeprom, and eg the Arducam MT9V034 breakout board ("UC-396 RevA")
- This has been tested with the CUAV PX4FLOW v2.3. On this particular board, the
SWD and SWCLK pads noted on the bottom of the board appear to be swapped
## MCU Pin Map
| PA0 | UART4_TX ("TIM5_CH1" - N/C) |
| PA1 | "TIM5_CH2" (unused - N/C) |
| PA2 | TIM5_CH3_EXPOSURE (pulled low) |
| PA3 | TIM5_CH4_STANDBY (pulled low) |
| PA4 | DCMI_HSYNC |
| PA5 | CAM_NRESET (tied to high) |
| PA6 | DCMI_PIXCK |
| PB6 | DCMI_D5 |
| PB7 | DCMI_VSYNC |
| PB8 | I2C1 SCL |
| PB9 | I2C1 SDA |
| PB10 | I2C2 SCL |
| PB11 | I2C2 SDA |
| PB12 | spi_cs_gyro |
| PB13 | SPI2 SCLK |
| PB14 | SPI2 CIPO |
| PB15 | SPI2 COPI |
| PC6 | DCMI_D0 |
| PC7 | DCMI_D1 |
| PC8 | XCLK |
| PC9 | "TIM8_CH4_LED_OUT" (unused) |
| PC10 | DCMI_D8 |
| PC11 | UART4_RX |
| PC12 | DCMI_D9 |
| PD0 | TBD |
| PD5 | TBD |
| PD6 | TBD |
| PD7 | TBD |
| PD15 | TBD |
| PE0 | DCMI_D2 |
| PE1 | DCMI_D3 |
| PE2 | user_led0 |
| PE3 | user_led1 |
| PE4 | DCMI_D4 |
| PE5 | DCMI_D6 |
| PE6 | DCMI_D7 |
| PE7 | user_led2 |