mirror of
https://github.com/iNavFlight/inav.git
synced 2025-07-15 20:35:29 +03:00
Darren Lines
GitHub
commit
58fb50c01a
355 changed files with 149947 additions and 675 deletions
|
|
@ -1,18 +1,22 @@
|
|||
# Betaflight 4.3 compatible MSP DisplayPort OSD (DJI O3 "Canvas Mode")
|
||||
|
||||
INAV 6.0 includes a special mode for MSP DisplayPort that supports incomplete implementations of MSP DisplayPort that only support BetaFlight, like the DJI O3 Air Unit.
|
||||
INAV 6.0 includes a special mode for MSP DisplayPort that supports incomplete implementations of MSP DisplayPort that only support BetaFlight, like the DJI O3 Air Unit. INAV 6.1 expands this to include HD canvas sizes from BetaFlight 4.4.
|
||||
|
||||
Different flight controllers have different OSD symbols and elements and require different fonts. BetaFlight's font is a single page and supports a maximum of 256 glyphs, INAV's font is currently 2 pages and supports up to 512 different glyphs.
|
||||
|
||||
While there is some overlap between the glyphs in BetaFlight and INAV, it is not possible to perform a 1 to 1 mapping for all the them. In cases where there is no suitable glyph in the BetaFlight font, a question mark `?` will be displayed.
|
||||
|
||||
This mode can be enabled by selecting BF43COMPAT as video format in the OSD tab of the configurator or by typing the following command on the CLI:
|
||||
This mode can be enabled by selecting BF43COMPAT or BFHDCOMPAT as video format in the OSD tab of the configurator or by typing the following command on the CLI:
|
||||
|
||||
`set osd_video_system = BF43COMPAT`
|
||||
|
||||
or
|
||||
|
||||
`set osd_video_system = BFHDCOMPAT`
|
||||
|
||||
## Limitations
|
||||
|
||||
* Canvas size is limited to PAL's canvas size.
|
||||
* Canvas size needs to be manually changed to HD on the Display menu in DJI's goggles (you may need a firmware update) and set as BFHDCOMPAT in the OSD tab of the configurator.
|
||||
* Unsupported Glyphs show up as `?`
|
||||
|
||||
## FAQ
|
||||
|
|
@ -43,4 +47,4 @@ While it might technically be possible to replace some glyphs with text in multi
|
|||
|
||||
### Does DJI support Canvas Mode?
|
||||
|
||||
Actually, no. What DJI calls Canvas Mode is actually MSP DisplayPort and is a character based OSD.
|
||||
Actually, no. What DJI calls Canvas Mode is actually MSP DisplayPort and is a character based OSD.
|
||||
|
|
|
|||
|
|
@ -51,7 +51,8 @@ IPF can be edited using INAV Configurator user interface, or via CLI
|
|||
| 15 | SUB | Substract `Operand B` from `Operand A` and returns the result |
|
||||
| 16 | MUL | Multiply `Operand A` by `Operand B` and returns the result |
|
||||
| 17 | DIV | Divide `Operand A` by `Operand B` and returns the result |
|
||||
| 18 | GVAR SET | Store value from `Operand B` into the Global Variable addressed by `Operand B`. Bear in mind, that operand `Global Variable` means: Value stored in Global Variable of an index! To store in GVAR 1 use `Value 1` not `Global Variable 1` |
|
||||
| 18 | GVAR SET | Store value from `Operand B` into the Global Variable addressed by
|
||||
`Operand A`. Bear in mind, that operand `Global Variable` means: Value stored in Global Variable of an index! To store in GVAR 1 use `Value 1` not `Global Variable 1` |
|
||||
| 19 | GVAR INC | Increase the GVAR indexed by `Operand A` (use `Value 1` for Global Variable 1) with value from `Operand B` |
|
||||
| 20 | GVAR DEC | Decrease the GVAR indexed by `Operand A` (use `Value 1` for Global Variable 1) with value from `Operand B` |
|
||||
| 21 | IO PORT SET | Set I2C IO Expander pin `Operand A` to value of `Operand B`. `Operand A` accepts values `0-7` and `Operand B` accepts `0` and `1` |
|
||||
|
|
|
|||
24
docs/SITL/RealFlight.md
Normal file
24
docs/SITL/RealFlight.md
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
# RealFlight
|
||||
|
||||
Supported are RealFlight 9.5S and RealFlight Evolution, NOT RealFlight-X.
|
||||
|
||||
RealFlight is very well suited to simulate the model flight specific aspects. Autolaunch and the mixers can be used.
|
||||
However, since the sceneries do not correspond to a real environment, the GPS data must be "faked". The position is always shown somewhere in southern Nevada ;).
|
||||
GPS data and flight modes work fine though, only for missions with waypoints it is of course not ideal.
|
||||
|
||||
## Joystick
|
||||
In the settings, calibrate the joystick, set it up and assign the axes in the same order as in INAV.
|
||||
Channel 1 (Aileron) in RealFlight is Cannel 1 (Aileron in INAV) and so on.
|
||||
|
||||
## General settings
|
||||
Under Settings / Physics / Quality Switch on "RealFlight Link enabled".
|
||||
As a command line option for SITL, the port does not need to be specified, the port is fixed.
|
||||
For better results, set the difficulty level to "Realistic".
|
||||
|
||||
## Prepare the models
|
||||
All mixer and servo influencing settings should be deactivated.
|
||||
In the model editor under "Electronis" all mixers should be deleted and the servos should be connected directly to the virtual receiver output.
|
||||
In the "Radio" tab also deactivate Expo and low rates: "Activadd when: Never".
|
||||
Configure the model in the same way as a real model would be set up in INAV including Mixer, Expo, etc. depending on the selected model in RealFlight.
|
||||
|
||||
Then adjust the channelmap im the Configurator or via command line accordingly.
|
||||
146
docs/SITL/SITL.md
Normal file
146
docs/SITL/SITL.md
Normal file
|
|
@ -0,0 +1,146 @@
|
|||
# SITL
|
||||
|
||||
|
||||
|
||||
## ATTENTION!
|
||||
SITL is currently still under development.
|
||||
|
||||
SITL (Software in the loop) allows to run INAV completely in software on the PC without using a flight controller and simulate complete FPV flights.
|
||||
For this, INAV is compiled with a normal PC compiler.
|
||||
|
||||
The sensors are replaced by data provided by a simulator.
|
||||
Currently supported are
|
||||
- RealFlight https://www.realflight.com/
|
||||
- X-Plane https://www.x-plane.com/
|
||||
|
||||
INAV SITL communicates for sensor data and control directly with the corresponding simulator, see the documentation of the individual simulators and the Configurator or the command line options.
|
||||
|
||||
## Sensors
|
||||
The following sensors are emulated:
|
||||
- IMU (Gyro, Accelerometer)
|
||||
- GPS
|
||||
- Pitot
|
||||
- Magnetometer (Compass)
|
||||
- Rangefinder
|
||||
- Barometer
|
||||
- Battery (current and voltage), depending on simulator
|
||||
|
||||
|
||||
|
||||
Select "FAKE" as type for all mentioned, so that they receive the data from the simulator.
|
||||
|
||||
## Serial ports+
|
||||
UARTs are replaced by TCP starting with port 5760 ascending. UART 1 port 5760, UART2 6761, ...
|
||||
By default, UART1 and UART2 are available as MSP connections.
|
||||
To connect the Configurator to SITL: Select TCP and connect to ```127.0.0.1:5760``` (if SITL is running on the same machine).
|
||||
IPv4 and IPv6 are supported, either raw addresses of hostname lookup.
|
||||
|
||||
The assignment and status of user UART/TCP connections is displayed on the console.
|
||||
|
||||
|
||||
|
||||
All other interfaces (I2C, SPI, etc.) are not emulated.
|
||||
|
||||
## Remote control
|
||||
Joystick (via simulator) or serial receiver via USB/Serial interface are supported.
|
||||
|
||||
### Joystick interface
|
||||
Only 8 channels are supported.
|
||||
Select "SIM (SITL)" as the receiver and set up a joystick in the simulator, details of which can be found in the documentation for the individual simulators.
|
||||
|
||||
### Serial Receiver via USB
|
||||
Connect a serial receiver (e.g. SBUS) to the PC via a UART/USB adapter. Configure the receiver in the Configurator as usual.
|
||||
|
||||
The Configurator offers a built-in option for forwarding the serial data to the SITL TCP port, if SITL is started manually the following option can be used:
|
||||
|
||||
The connection can then be established with a programme that forwards the serial data unaltered to TCP, e.g. with the Python script tcp_serial_redirect.py (https://github.com/Scavanger/TCP-Serial-Redirect)
|
||||
If necessary, please download the required runtime environment from https://www.python.org/.
|
||||
Please use the linked version, which has a smaller buffer, otherwise the control response is relatively slow.
|
||||
|
||||
### Example SBUS:
|
||||
For this you need a FT232 module. With FT-Prog (https://ftdichip.com/utilities/) the signals can be inverted: Devices->Scan and Parse, then Hardware Specific -> Invert RS232 Signals -> Invert RXD.
|
||||
|
||||
|
||||
|
||||
For SBUS, the command line arguments of the python script are:
|
||||
```python tcp_serial_redirect.py --parity E --stopbits 2 -c 127.0.0.1:[INAV-UART-PORT] COMXX 100000```
|
||||
|
||||
Note: Telemetry via return channel through the receiver is not supported by SITL (yet).
|
||||
|
||||
## OSD
|
||||
For the OSD the program INAV-Sim-OSD is available: https://github.com/Scavanger/INAV-SIM-OSD.
|
||||
For this, activate MSP-Displayport on a UART/TCP port and connect to the corresponding port.
|
||||
|
||||
Note: INAV-Sim-OSD only works if the simulator is in window mode.
|
||||
|
||||
## Command line
|
||||
The command line options are only necessary if the SITL executable is started by hand, e.g. when debugging.
|
||||
For normal use, please use the SITL tab in the configurator.
|
||||
|
||||
The following SITL specific command line options are available:
|
||||
|
||||
If SITL is started without command line options, only a serial MSP / CLI connection can be used (e.g. Configurator or other application) can be used.
|
||||
|
||||
```--path``` Full path and file name to config file, if not present, eeprom.bin in the current directory is used. Example: ```C:\INAV_SITL\flying-wing.bin```
|
||||
|
||||
```--sim=[sim]``` Select the simulator. xp = X-Plane, rf = RealFlight. Example: ```--sim=xp```
|
||||
|
||||
```--simip=[ip]``` IP address of the simulator, if you specify a simulator with "--sim" and omit this option localhost (127.0.0.1) will be used. Example: ```--simip=172.65.21.15```
|
||||
|
||||
```--simport=[port]``` Port number of the simulator, not necessary for all simulators. Example: ```--simport=4900```
|
||||
|
||||
```--useimu``` Use IMU sensor data from the simulator instead of using attitude data directly from the simulator. Not recommended, use only for debugging.
|
||||
|
||||
```--chanmap=[chanmap]``` The channelmap to map the motor and servo outputs from INAV to the virtual receiver channel or control surfaces around simulator.
|
||||
Syntax: (M(otor)|S(ervo)<INAV-OUT>-<RECEIVER_OUT>),..., all numbers must have two digits.
|
||||
Example:
|
||||
To assign motor1 to virtual receiver channel 1, servo 1 to channel 2, and servo2 to channel 3:
|
||||
```--chanmap:M01-01,S01-02,S02-03```
|
||||
Please also read the documentation of the individual simulators.
|
||||
|
||||
```--help``` Displays help for the command line options.
|
||||
|
||||
## Running SITL
|
||||
It is recommended to start the tools in the following order:
|
||||
1. Simulator, aircraft should be ready for take-off
|
||||
2. INAV-SITL
|
||||
3. OSD
|
||||
4. serial redirect for RC input
|
||||
|
||||
## Compile
|
||||
|
||||
### Linux and FreeBSD:
|
||||
Almost like normal, ruby, cmake and make are also required.
|
||||
With cmake, the option "-DSITL=ON" must be specified.
|
||||
|
||||
```
|
||||
mkdir build_SITL
|
||||
cd build_SITL
|
||||
cmake -DSITL=ON ..
|
||||
make
|
||||
```
|
||||
|
||||
### Windows:
|
||||
Compile under cygwin, then as in Linux.
|
||||
Copy cygwin1.dll into the directory, or include cygwin's /bin/ directory in the environment variable PATH.
|
||||
|
||||
#### Build manager
|
||||
|
||||
`ninja` may also be used (parallel builds without `-j $(nproc)`):
|
||||
|
||||
```
|
||||
cmake -GNinja -DSITL=ON ..
|
||||
ninja
|
||||
```
|
||||
|
||||
### Compiler requirements
|
||||
|
||||
* Modern GCC. Must be a *real* GCC, macOS faking it with clang will not work.
|
||||
* Unix sockets networking. Cygwin is required on Windows (vice `winsock`).
|
||||
* Pthreads
|
||||
|
||||
## Supported environments
|
||||
|
||||
* Linux on x86_64, Aarch64 (e.g. Rpi4), RISC-V (e.g. VisionFive2)
|
||||
* Windows on x86_64
|
||||
* FreeBSD (x86_64 at least).
|
||||
44
docs/SITL/X-Plane.md
Normal file
44
docs/SITL/X-Plane.md
Normal file
|
|
@ -0,0 +1,44 @@
|
|||
# X-Plane
|
||||
|
||||
Tested on X-Plane 11, 12 should(!) work but not tested.
|
||||
|
||||
X-Plane is not a model flight simulator, but is based on real world data and is therefore suitable for GPS missions with waypoints.
|
||||
|
||||
## Aircraft
|
||||
It is recommended to use the "AR Wing" of the INAV HITL project: https://github.com/RomanLut/INAV-X-Plane-HITL
|
||||
|
||||
## General settings
|
||||
In Settings / Network select "Accept incoming connections".
|
||||
The port can be found under "UDP PORTS", "Port we receive on". If no connection is established, the port can be changed.
|
||||
You may want to incease the "Flight model per frame" value under "General"
|
||||
|
||||
## Joystick
|
||||
In the settings, calibrate the joystick, set it up and assign the axes as follows:
|
||||
|
||||
| INAV | X-Plane |
|
||||
|------|---------|
|
||||
| Roll | Roll |
|
||||
| Pitch | Pitch |
|
||||
| Throttle | Cowl Flap 1 |
|
||||
| Yaw | Yaw |
|
||||
| Channel 5 | Cowl Flap 2 |
|
||||
| Channel 6 | Cowl Flap 3 |
|
||||
| Channel 7 | Cowl Flap 4 |
|
||||
| Channel 8 | Cowl Flap 5 |
|
||||
|
||||
Reverse axis in X-Plane if necessary.
|
||||
|
||||
## Channelmap:
|
||||
The assignment of the "virtual receiver" is fixed:
|
||||
1 - Throttle
|
||||
2 - Roll
|
||||
3 - Pitch
|
||||
4 - Yaw
|
||||
|
||||
The internal mixer (e.g. for flying wings) cannot be deactivated without further ado, therefore always select "Aircraft with tail" in INAV.
|
||||
For the standard Aircraft preset the channelmap is:
|
||||
```--chanmap=M01-01,S01-03,S03-02,S04-04```
|
||||
|
||||
## Other applications
|
||||
|
||||
[fl2sitl](https://github.com/stronnag/bbl2kml/wiki/fl2sitl) is an open source application to replay an INAV Blackbox log through the INAV SITL via `blackbox_decode`. The output may be visualised in any MSP capable application, such as the INAV Configurator or [mwp](https://github.com/stronnag/mwptools). fl2sitl uses the X-plane protocol.
|
||||
BIN
docs/SITL/assets/INAV-SIM-OSD.png
Normal file
BIN
docs/SITL/assets/INAV-SIM-OSD.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 346 KiB |
BIN
docs/SITL/assets/SITL-Fake-Sensors.png
Normal file
BIN
docs/SITL/assets/SITL-Fake-Sensors.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
BIN
docs/SITL/assets/SITL-SBUS-FT232.png
Normal file
BIN
docs/SITL/assets/SITL-SBUS-FT232.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
BIN
docs/SITL/assets/SITL-UART-TCP-Connecion.png
Normal file
BIN
docs/SITL/assets/SITL-UART-TCP-Connecion.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 2.8 KiB |
|
|
@ -2648,7 +2648,7 @@ If set to ON drone won't arm if no GPS fix and any navigation mode like RTH or P
|
|||
|
||||
| Default | Min | Max |
|
||||
| --- | --- | --- |
|
||||
| ON | | |
|
||||
| ALLOW_BYPASS | | |
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -4958,7 +4958,7 @@ When enabled, INAV will set RC filtering based on refresh rate and smoothing fac
|
|||
|
||||
| Default | Min | Max |
|
||||
| --- | --- | --- |
|
||||
| OFF | OFF | ON |
|
||||
| ON | OFF | ON |
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,30 +1,118 @@
|
|||
# USB Flashing
|
||||
Some newer boards with full USB support must be flashed in USB DFU mode. This is a straightforward process in Configurator versions 0.67 and newer. The standard flashing procedure should work successfully with the caveat of some platform specific problems as noted below. The "No reboot sequence" checkbox has no effect as the device will automatically be detected when already in bootloader mode (a DFU device will appear in the connect dropdown if this is the case). The Full chip erase checkbox operates as normal. The baudrate checkbox is ignored as it has no relevance to USB.
|
||||
|
||||
Modern flight controllers are typically flashed in USB DFU mode. This is a straight-forward process in Configurator. The standard flashing procedure should work successfully with the caveat of some platform specific matters as noted below.
|
||||
|
||||
* If the board is placed in DFU mode manually (by hardware button), then check "No reboot sequence"
|
||||
* Baudrate is not relevant for DFU flashing.
|
||||
* For version upgrades, enable "Full chip erase"
|
||||
|
||||
|
||||
## Platform Specific: Linux
|
||||
Linux requires udev rules to allow write access to USB devices for users. An example shell command to acheive this on Ubuntu is shown here:
|
||||
|
||||
Linux requires `udev` rules to allow write access to USB devices for users.
|
||||
|
||||
|
||||
### Simple unconditional rule
|
||||
|
||||
The simplest rule is to allow DFU access unconditionally; this avoids having to set up specific groups which may be distro independent. If you have previously flashed OpenTX or EdgeTX you will already have such a rule as `/etc/udev/rules.d/45-companion-taranis.rules` and no further action is required. Otherwise, you can add (as root) a file for example `/etc/udev/rules.d/45-stdfu-permissions.rules` containing the single line:
|
||||
|
||||
```
|
||||
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", MODE:="0666"
|
||||
```
|
||||
|
||||
### More complex group example
|
||||
|
||||
As an alternative, you can make a distro specific rule restricting DFU a group; an example shell command to achieve this on Ubuntu is:
|
||||
|
||||
```
|
||||
(echo '# DFU (Internal bootloader for STM32 MCUs)'
|
||||
echo 'SUBSYSTEM=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", MODE="0664", GROUP="plugdev"') | sudo tee /etc/udev/rules.d/45-stdfu-permissions.rules > /dev/null
|
||||
```
|
||||
|
||||
This assigns the device to the plugdev group(a standard group in Ubuntu). To check that your account is in the plugdev group type `groups` in the shell and ensure plugdev is listed. If not you can add yourself as shown (replacing `<username>` with your username):
|
||||
This assigns the device to the `plugdev` group(a standard group in Ubuntu). To check that your account is in the `plugdev` group type `groups` in the shell and ensure `plugdev` is listed. If not you can add yourself as shown (replacing `<username>` with your username):
|
||||
```
|
||||
sudo usermod -a -G plugdev <username>
|
||||
```
|
||||
On Arch and its derivatives the group would be uucp and the command:
|
||||
Then log out and back again to acquire the new group.
|
||||
|
||||
On Arch and its derivatives the group would be `uucp` (in the rule and the `usermod` command:
|
||||
```
|
||||
sudo usermod -a -G uucp <username>
|
||||
```
|
||||
|
||||
## Platform Specific: Windows
|
||||
Chrome can have problems accessing USB devices on Windows. A driver should be automatically installed by Windows for the ST Device in DFU Mode but this doesn't always allow access for Chrome. The solution is to replace the ST driver with a libusb driver. The easiest way to do that is to download [Zadig](http://zadig.akeo.ie/).
|
||||
With the board connected and in bootloader mode (reset it by sending the character R via serial, or simply attempt to flash it with the correct serial port selected in Configurator):
|
||||
|
||||
The Configurator can have problems accessing USB devices on Windows. A driver should be automatically installed by Windows for the ST Device in DFU Mode but this doesn't always allow access. One solution is to replace the ST driver with a libusb driver. The easiest way to do that is to download [Zadig](http://zadig.akeo.ie/).
|
||||
With the board connected and in bootloader mode (reset it by sending the character R via serial, or simply attempt to flash it with the correct serial port selected in Configurator):
|
||||
|
||||
* Open Zadig
|
||||
* Choose Options > List All Devices
|
||||
* Select `STM32 BOOTLOADER` in the device list
|
||||
* Choose `WinUSB (v6.x.x.x)` in the right hand box
|
||||
|
||||
|
||||
|
||||
* Click Replace Driver
|
||||
* Restart Chrome (make sure it is completely closed, logout and login if unsure)
|
||||
* Restart the Configurator (make sure it is completely closed, logout and login if unsure)
|
||||
* Now the DFU device should be seen by Configurator
|
||||
|
||||
|
||||
## Using `dfu-util`
|
||||
|
||||
`dfu-util` is a command line tool to flash ARM devices via DFU. It is available via the package manager on most Linux systems or from [source forge](http://sourceforge.net/p/dfu-util).
|
||||
|
||||
Put the device into DFU mode by **one** of the following:
|
||||
|
||||
* Use the hardware button on the board
|
||||
* Send a single 'R' character to the serial device, e.g. on POSIX OS using `/dev/ttyACM0` at 115200 baudrate.
|
||||
|
||||
```
|
||||
stty 115200 < /dev/ttyACM0
|
||||
echo -ne 'R' > /dev/ttyACM0
|
||||
```
|
||||
* Use the CLI command `dfu`
|
||||
|
||||
It is necessary to convert the `.hex` file into `Intel binary`. This can be done using the GCC `objcopy` command; e.g. for the notional `inav_x.y.z_NNNNNN.hex`.
|
||||
|
||||
```
|
||||
objcopy -I ihex inav_x.y.z_NNNNNN.hex -O binary inav_x.y.z_NNNNNN.bin
|
||||
```
|
||||
|
||||
You can now DFU flash the `.bin` file:
|
||||
|
||||
```
|
||||
dfu-util -d 0483:df11 --alt 0 -s 0x08000000:force:leave -D inav_x.y.z_NNNNNN.bin
|
||||
```
|
||||
or with full erase
|
||||
|
||||
```
|
||||
dfu-util -d 0483:df11 --alt 0 -s 0x08000000:mass-erase:force:leave -D inav_x.y.z_NNNNNN.bin
|
||||
```
|
||||
|
||||
## Caveats
|
||||
|
||||
Once the board is placed in DFU mode, the hardware boot loader polls for activity on the USB device and *some MCU dependent* UARTS (often UART1 and UART3). If you have a device on one of these UARTS that transmits unconditionally (GPS, RX for example), then that port may win the "active device" race, and DFU flashing will fail.
|
||||
|
||||
Ensure that such devices are either disconnected or not powered during flashing.
|
||||
|
||||
## Older devices / broken USB ports
|
||||
|
||||
If you have a older (unsupported) FC that does not support DFU, or a modern board with a broken USB port, it is possible to flash the board via a UART (typically UART1) using the ST serial flashing protocol.
|
||||
|
||||
|
||||
This is supported by (very) old Configurators, the open source [stm32flash](https://sourceforge.net/projects/stm32flash/) tool and some ST proprietary tools.
|
||||
|
||||
Examples:
|
||||
|
||||
* Erase the device (assumed `/dev/ttyUSB0`)
|
||||
|
||||
```
|
||||
stm32flash -o -b 57600 /dev/ttyUSB0
|
||||
```
|
||||
* Flash a HEX file (notionally `inav_x.y.z_NNNNNN.hex`)
|
||||
|
||||
```
|
||||
stm32flash -w inav_x.y.z_NNNNNN.hex -v -g 0x0 -b 57600 /dev/ttyUSB0
|
||||
```
|
||||
|
||||
replace `/dev/ttyUSB0` as appropriate for your OS. You will probably be more successful at 57600 baud than 115200. The speed is auto-detected by the FC.
|
||||
|
|
|
|||
|
|
@ -1,58 +1,61 @@
|
|||
# Building in Windows with MSYS2
|
||||
- This environment does not require installing WSL which may not be available or would get in the way of other virtualization and/or anti-cheat softwares.
|
||||
- It is also much faster to install and get set up because of its small size(~2 GB download and ~3.12 GB total after building hex file).
|
||||
|
||||
- This environment does not require installing WSL, which may not be available or would get in the way of other virtualization and/or anti-cheat software
|
||||
- It is also much faster to install and get set up because of its small size(~3.65 GB total after building hex file as of 6.0.0)
|
||||
## Setting up the environment
|
||||
|
||||
1. Download and install the latest MSYS2 release from https://repo.msys2.org/distrib/x86_64/
|
||||
- Scroll all the way down for an executable
|
||||
- Scroll halfway down for a self-extracting archive
|
||||
|
||||
### Download and install MSYS2
|
||||
1. For 6.0.0, the last version that works is [20220603](https://repo.msys2.org/distrib/x86_64/msys2-x86_64-20220603.exe)
|
||||
- [20220503](https://repo.msys2.org/distrib/x86_64/msys2-x86_64-20220503.exe) is also known to work
|
||||
- MSYS2 releases can be viewed at https://repo.msys2.org/distrib/x86_64/
|
||||
- Scroll all the way down for an executable, scroll halfway down for a self-extracting archive
|
||||
1. Open an MSYS2 terminal by running C:\msys64\msys2_shell.cmd
|
||||
|
||||
1. In the newly opened shell, set up your work path
|
||||
- To paste commands, use "Shift+Insert" or Right-click and select "Paste"
|
||||
```
|
||||
mkdir /c/Workspace
|
||||
```
|
||||
## Downloading and installing dependencies
|
||||
### Installing other dependencies:
|
||||
```
|
||||
pacman -S git ruby make cmake gcc mingw-w64-x86_64-libwinpthread-git unzip wget
|
||||
```
|
||||
- Note: If some fails to download, use the following command to install the rest without reinstalling everything:
|
||||
```
|
||||
pacman -S git ruby make cmake gcc mingw-w64-x86_64-libwinpthread-git unzip wget --needed
|
||||
```
|
||||
### Download the INAV repository
|
||||
#### Go to the working directory
|
||||
```
|
||||
cd /c/Workspace
|
||||
```
|
||||
|
||||
## Downloading the INAV repository
|
||||
|
||||
#### Download INAV source code
|
||||
- For master:
|
||||
```
|
||||
git clone https://github.com/iNavFlight/inav
|
||||
```
|
||||
- For [a branch](https://github.com/iNavFlight/inav/branches) or [a tag](https://github.com/iNavFlight/inav/tags):
|
||||
```
|
||||
# "5.1.0" here can be the name of a branch or a tag
|
||||
git clone --branch 5.1.0 https://github.com/iNavFlight/inav
|
||||
# "release_6.0.0" here can be the name of a branch or a tag
|
||||
git clone --branch release_6.0.0 https://github.com/iNavFlight/inav
|
||||
```
|
||||
- If you are internet speed or space restrained, you can also use `--depth 1` which won't download the whole history and `--single-branch` which won't download other branches:
|
||||
- If you are internet speed or space restrained, you can also use `--depth 1`, which won't download the whole history, and `--single-branch`, which won't download other branches:
|
||||
```
|
||||
git clone --depth 1 --single-branch --branch 5.1.0 https://github.com/iNavFlight/inav
|
||||
git clone --depth 1 --single-branch --branch release_6.0.0 https://github.com/iNavFlight/inav
|
||||
```
|
||||
This results in ~315 MB instead of ~476 MB download/install size
|
||||
|
||||
## Installing dependencies
|
||||
|
||||
### Installing other dependencies:
|
||||
```
|
||||
pacman -S git ruby make cmake gcc mingw-w64-x86_64-libwinpthread-git unzip wget
|
||||
```
|
||||
|
||||
This results in ~302 MB instead of ~468 MB download/install size(as of 6.0.0)
|
||||
### Installing xPack
|
||||
1. Create xPack directory:
|
||||
```
|
||||
mkdir /c/Workspace/xpack
|
||||
cd /c/Workspace/xpack
|
||||
```
|
||||
2. Get the xPack version you need for your INAV version:
|
||||
2. Find out which version of xPack you need for your INAV version:
|
||||
```
|
||||
# Currently, this is 10.2.1 for 6.0.0 and 10.3.1 for master
|
||||
cat /c/Workspace/inav/cmake/arm-none-eabi-checks.cmake | grep "set(arm_none_eabi_gcc_version" | cut -d\" -f2
|
||||
```
|
||||
3. Find the version you need from the [releases page](https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases/), then either:
|
||||
- Download the "...-win32-x64.zip" and copy the folder inside, or
|
||||
- Right click, choose "Copy link address" and paste it into the following commands:
|
||||
- Right-click, choose "Copy link address" and paste it into the following commands:
|
||||
```
|
||||
cd /c/Workspace/xpack
|
||||
# paste the link after "wget"
|
||||
|
|
@ -62,48 +65,42 @@ unzip xpack-arm-none-eabi-gcc-10.2.1-1.1-win32-x64.zip
|
|||
# you can delete the zip file after as it is no longer needed
|
||||
rm xpack-arm-none-eabi-gcc-10.2.1-1.1-win32-x64.zip
|
||||
```
|
||||
3. This is important, put the toolkit first before your path so that it is picked up ahead of any other versions that may be present on your system:
|
||||
3. This is important. Put the toolkit first before your path so that it is picked up ahead of any other versions that may be present on your system:
|
||||
```
|
||||
export PATH=/c/Workspace/xpack/xpack-arm-none-eabi-gcc-10.2.1-1.1/bin:$PATH
|
||||
cd /c/Workspace/inav/build
|
||||
```
|
||||
|
||||
## Building the INAV firmware
|
||||
1. Create the build directory:
|
||||
```
|
||||
cd /c/Workspace/inav
|
||||
mkdir build
|
||||
mkdir /c/Workspace/inav/build
|
||||
```
|
||||
2. Go into the build directory:
|
||||
```
|
||||
cd build
|
||||
cd /c/Workspace/inav/build
|
||||
```
|
||||
3. Run cmake
|
||||
- This may take a while. If you only want to test one target, remove the rest of the folders from C:\Workspace\inav\src\main\target\
|
||||
```
|
||||
cmake ..
|
||||
```
|
||||
4. Compile the firmware for your flight controller.
|
||||
```
|
||||
make MATEKF405
|
||||
make MATEKH743
|
||||
```
|
||||
- The list of available targets in INAV can be found here: https://github.com/inavflight/inav/tree/master/src/main/target
|
||||
|
||||
- The generated hex file will be in the /c/Workspace/inav/build folder
|
||||
|
||||
- For the following runs, repeat steps 2 to 4
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### *** multiple target patterns. Stop. | Error 2
|
||||
#### Delete everything in the build directory that contains previous runs
|
||||
You can either use file explorer and delete everything inside C:\Workspace\inav\build
|
||||
or run:
|
||||
```
|
||||
cd /c/Workspace/inav/build
|
||||
rm -rf *
|
||||
cd /c/Workspace/inav/build && rm -rf *
|
||||
```
|
||||
### -- could not find arm-none-eabi-gcc
|
||||
#### Redo export PATH:
|
||||
#### Redo export PATH, make sure xpack version number is correct:
|
||||
```
|
||||
export PATH=/c/Workspace/xpack/xpack-arm-none-eabi-gcc-10.2.1-1.1/bin:$PATH
|
||||
```
|
||||
### make: the '-j' option requires a positive integer argument
|
||||
#### You are using too new version of MSYS2, uninstall and reinstall version [20220603](https://repo.msys2.org/distrib/x86_64/msys2-x86_64-20220603.exe) or [20220503](https://repo.msys2.org/distrib/x86_64/msys2-x86_64-20220503.exe)
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ sudo udevadm control --reload-rules
|
|||
- Just for info: `usbipd detach --busid ID_OF_DEVICE_FROM_FIRST_COMMAND` - will deattach USB device from WSL
|
||||
### Back to WSL2 prompt
|
||||
- `lsusb` - should show you just attached USB device
|
||||
- `st-info -probe` - should "see" ST-Link and MCU
|
||||
- `st-info --probe` - should "see" ST-Link and MCU
|
||||
|
||||
#### Leave Command Prompt and WSL Prompt minimized (for later usage)
|
||||
#### **NOTE:** Due to some USB reconnect issues, sometimes, is need to execute `usbipd wsl list` and `usbipd wsl attach...` commands again, to reconnect ST-Link to WSL
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue