#bsp #camera #embedded-hal-driver #imaging #mt9v034

no-std px4flow_bsp

A board support package for the PX4FLOW optical flow sensor board

9 releases

0.2.0 Sep 30, 2020
0.1.8 Sep 16, 2020
0.1.5 Aug 11, 2020
0.1.3 Jul 30, 2020

#591 in Embedded development


Used in correlation_flow

BSD-3-Clause

53KB
945 lines

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 (This is WIP and may not work as expected.)

With the Segger tools installed

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

cargo run  --example play --features  rttdebug

Interrupt Handling

Currently you need to configure your application to forward interrupts from app-level interrupt handlers, ie:

/// 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 to construct your embedded application, and using its #[interrupt] to handle interrupts.

Status

Work in progress

  • Does not overwrite the default PX4FLOW bootloader that typically ships with the board
  • Example that sets up DCMI to read from the camera
  • Support for spi2 (l3gd20 gyro)
  • Support for i2c1 (offboard i2c communication)
  • Support for i2c2 (MT9V034 configuration port, and eeprom)
  • Support for USART2, USART3, and UART4 (sonar)
  • Support for serial eeprom on i2c2
  • Initial setup of DCMI peripheral
  • Initial setup of DMA2
  • Mostly working DCMI->DMA2-> image buffer pipeline
  • 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

Pin Configuration
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

Dependencies

~55MB
~1.5M SLoC