Resource Assignment for Flight Controller Boards - heliflight3d/heliflight GitHub Wiki

Resource Assignments in Heliflight 3D

Included on each flight controller board is a STM32 microcontroller (processor) that runs the Heliflight flight controller code. The STM32 chip communicates to the outside world through physical "pins" or balls on the chip that are soldered onto the printed circuit board. The pins on the STM32 microcontroller each have different capabilities. Functionality in the flight controller code can be assigned to different pins using the "resource" command in the command-line interface (CLI). These assignments cannot be made haphazardly. You must assign each function to a pin that has the capabilities required for that function, and that pin on the STM32 chip must be broken out to a solder pad, through hole, or connector that you have access to on the flight controller board.

Each flight controller board connects the various pins of the STM32 chip to different components or solder pads/holes on the PCB. The layout of a board (including the pin connections) are typically optimized for different types of quadrotor applications. This is why so many small flight controller boards only have 4 motor outputs, even though Betaflight and iNav support more than 4 motors. Our goal for using off-the-shelf flight controller boards for Heliflight 3D then becomes finding a board that has the pin connections that will allow us to use all the features and functions that we need for single-rotor helicopters.

Boards that are most likely to be useful for Heliflight will have at least 6 motor outputs, an LED_STRIP output, and multiple UARTs exposed as solder pads or connectors for the user.

Targets

Each flight controller board has a configuration file that is called a "unified target". These unified target configuration files have all of the resource, timer, and DMA assignments for each pin. They also tell Heliflight which pins have devices attached to them directly on the flight controller board, such as the gyro and accelerometer, flash storage for Blackbox logging, barometric pressure sensor, etc. The unified target configuration file can be viewed and utilized to determine which pin on the STM32 processor is mapped to a particular output pad on the flight controller board. For example, the "MOTOR 1" pad on the flight controller board might be mapped to pin "B01" with the resource assignment command: "resource MOTOR 1 B01". In this way, we can begin to look at a board and see which pads or connectors are mapped to which pins on the STM32 microcontroller.

There are various "resource" commands that can be used when connected to a board through the Configurator CLI:

  • To show all existing resource assignments, type: "resource show"
  • To remove an existing resource assignment for MOTOR 1, type: "resource MOTOR 1 none"
  • Note that resource modifications will not be reflected in "resource show" until you type "save" and the flight controller reboots.

The unified target for your board can be found here: https://github.com/betaflight/unified-targets/tree/master/configs/default

Timers

Timers are special counters that are built into the STM32 microcontroller and are limited in quantity. Each timer has multiple channels available, and sometimes these channels can be shared with functions of the same type. For example, multiple motors can share the same timer by using different timer channels. The pins on the microcontroller will have default timer channel assignments that have been made by the flight controller board manufacturer. However, the timer assignments that the board designer made are often not the only timer assignments available. Often a pin may have two or three different timers and/or timer channels available to be assigned to it. It is often necessary for us to reassign timers for each pin so that they are grouped in a way that is better for use with a helicopter.

The timers and channels available for any given pin can be viewed from the CLI while connected to the flight controller. For example, to find the Timers available for pin B01, type the following into the CLI (without the quotes): "timer B01 list". This will then show a list of timers that are available, with each one preceeded by it's name, like so:

  • # timer B01 list
  • # AF1: TIM1 CH3N
  • # AF2: TIM3 CH4
  • # AF3: TIM8 CH3N

You can then set pin B01 to any of the three available timers. To set pin B01 to use Timer 3 Channel 4, type: "timer B01 AF2"

The number of available Timers and DMA is pretty much identical between F4 and F7 processors, however F4 processors do not have hardware signal inversion built into the processor which can be annoying for certain use cases like FrSky receivers.

DMA (direct memory access) is a way that pins can set or read values directly from the STM32 processor's memory. DMA is used by UART pins. At this time DMA assignment is not technically required for any other functionality, since DSHOT can operate in BitBang mode instead of DMA mode. This is very good because it can become challenging to manage conflicts between DMA streams for multiple UART and Motor connections.

The section below describes the timer requirements for each of the different functions in Heliflight:

Servos

  • Servos require a channel on a timer that is dedicated to servos operating at the same frequency (update rate). The timer for cyclic and tail servos can be the same if you run the servos at the same frequency (Hz). Different pulse lengths (1520us and 760us for example) can be used on the same timer, as long as the frequency is the same.
  • Typically you should try to use three different channels on one shared timer for the three cyclic servos and a channel on a different timer that is dedicated to only the tail servo. This will allow for running the cyclic and tail servos at different update frequencies in the future and only uses up two total timers on the STM32 processor.
  • Servos cannot share a timer with the motor outputs as they typically run at differnet PWM frequencies (or no PWM frequency at all, in the case of DSHOT or other serial motor protocols).

Motors

  • ESCs using all currently available motor protocols will require a channel on a timer dedicated to the motors. Typically you want all motors to share channels on the same timer to conserve timers for other uses. If you are only using one main motor, then assign it to a channel on a timer you are dedicating to that motor.
  • Some ESCs require a PWM signal command (Hobbywing, Castle, Kontronik, YGE, etc).
  • Some ESCs require a serial signal like DSHOT. DSHOT ESCs can be operated in BitBang mode or DMA mode. In BitBang mode only a timer is necessary on the pin. In DMA mode a DMA channel must also be assigned to the pin. BitBang is the default when DSHOT bitbang is configured to "AUTO". Bi-Directional DSHOT (with RPM telemetry) can work in either BitBang or DMA mode.

ESC Sensor Telemetry

  • ESC Sensor Telemetry for DSHOT and Hobbywing ESCs requires a pin with UART RX functionality. Any UART RX pin will work, however do not try to use the accompanying UART TX pin (with the same UART number) for some other function.
  • No timer assignment is necessary for UART operation. UARTs do require a DMA stream to be assigned.

Frequency sensor (RPM sensor)

  • Frequency sensor functionality requires a timer dedicated to each frequency sensor being used. The timer assigned to a frequency sensor cannot be shared with any other functions or with another frequency sensor due to the way that the hardware prescaler (which is shared with every timer channel) is used to track changes in the signal's frequency. This is done to give the most stable RPM reading possible.

Serial Receiver (RX)

  • Serial receiver protocols such as F.Port, SBUS, and SmartPort require UART TX or RX functionality on the pin. No timer assignment is necessary for UART operation. UARTs do require a DMA stream to be assigned.
  • Some receiver protocols are bi-directional with channel values and telemetry over the same wire (such as Fport) and only require connecting to a UART TX pin. Other protocols use two UART connections, such as SBUS + SmartPort which requires the SBUS connection to a UART RX pin and the SmartPort connection to a different UART TX pin.

OpenLager

  • OpenLager serial logging devices require UART TX functionality. No timer assignment is necessary for UART operation. UARTs do require a DMA stream to be assigned.
  • An OpenLager device is nice to have because it can be used with a large (up to 32GB has been tested) microSD card to store logs from hundreds of flights.

Example pin assignments for various flight controllers

(NOTE: Each board has labeled pads or connector positions for the function that was originally assigned in the Betaflight unified target meant for mini-quad use. The new resource assignments that are made must be referenced to the assigned pin, and then that pin must be referenced to the name from the original unified target in Betaflight in order to figure out which pad on the board corresponds with the new resource assignment.)

THE INFORMATION BELOW IS NOT COMPLETE YET.... TO BE DONE:

iFlight Succex-D Mini 20x20 F722 with dual-DSHOT ESCs and only 3 servos (motor-driven tail)

Flywoo Goku F722 Mini 20x20 with DSHOT main motor ESC and 4 servos (3 cyclic + 1 tail)

Flywoo Goku F722 Mini 20x20 with Hobbywing main motor ESC and 4 servos (3 cyclic + 1 tail)

• MOTOR 1 = PWM output to Hobbywing ESC
• FREQ 1 = RPM Sensor input from Hobbywing ESC

UART 6 RX = Telemetry input from Hobbywing ESC