search

betaflight / betaflight

Open Source Flight Controller Firmware
GNU General Public License v3.0
8k stars 2.86k forks source link

SPRacingPixelOSD Support (2024) #13603

Open hydra opened 2 weeks ago

hydra commented 2 weeks ago

Important points:

Given that the only analog OSD system currently supported by BF is no longer viable, an alternative approach is required.

This PR provides support for the open-source SPRacingPixelOSD system.

Schematics and source are here: https://github.com/spracing/spracingpixelosd

Commercially available FCs using this system include the SPRacingH7RF, available here:

http://www.seriouslypro.com/spracingh7rf https://shop.seriouslypro.com/sp-racing-h7-rf

Example overlay, with one pixel-based OSD element from this PR:

IMG_20240429_120559

github-actions[bot] commented 2 weeks ago

Do you want to test this code? You can flash it directly from Betaflight Configurator:

WARNING: It may be unstable. Use only for testing!

hydra commented 2 weeks ago

Updated branch, all builds passing.

Binaries for testing: betaflight_4.5.0_STM32H730_SPRACINGH7RF_17c4fe0c6a.zip

sugaarK commented 1 week ago

@haslinghuis do you have hardware to test this? and @SteveCEvans ?

haslinghuis commented 1 week ago 
# version
# Betaflight / STM32H730 (SP7R) 4.5.0 May  8 2024 / 12:24:47 (71b892d3b) MSP API: 1.46
# config rev: 8d48619
# board: manufacturer_id: SPRO, board_name: SPRACINGH7RF

# tasks
Task list             rate/hz  max/us  avg/us maxload avgload  total/ms   late    run reqd/us
00 - (         SYSTEM)     10       3       0    0.0%    0.0%        21      0     66      24
01 - (         SYSTEM)    990      19       3    1.8%    0.3%      6803      4   6475      10
02 - (           GYRO)   8104      39       9   31.6%    7.2%    151113      0  56452       0
03 - (         FILTER)   8104      26       8   21.0%    7.1%    158135      0  56452       0
04 - (            PID)   8104      93      26   75.3%   21.0%    431479      0  56452       0
05 - (            ACC)    977      29      10    2.8%    0.9%     18111     10   6439      16
06 - (       ATTITUDE)    100      56      33    0.5%    0.3%      6465      2    636      52
07 - (             RX)     10      60      47    0.0%    0.0%      2853     23    198      58
08 - (         SERIAL)    100    9218       5   92.1%    0.0%      7762      0    659      20
09 - (       DISPATCH)    989       7       0    0.6%    0.0%       787     17   6489       5
10 - (BATTERY_VOLTAGE)     50      11       3    0.0%    0.0%       362      0    330      14
11 - (BATTERY_CURRENT)     50       7       2    0.0%    0.0%       205      0    330       7
12 - ( BATTERY_ALERTS)      5      18      12    0.0%    0.0%       119      0     33      37
13 - (         BEEPER)    100       9       2    0.0%    0.0%       298      0    659       7
17 - (           BARO)     12      47      18    0.0%    0.0%      3090     22    480      83
18 - (       ALTITUDE)    100      17       2    0.1%    0.0%       600      1    659      13
19 - (      TELEMETRY)    491       5       0    0.2%    0.0%       915      7   3251       2
20 - (       LEDSTRIP)     12      31       2    0.0%    0.0%      2557      0   2779      44
21 - (            OSD)     12      50       0    0.0%    0.0%     11377     26  51799       5
22 - (PIXEL_OSD_VIDEO)     72       5       0    0.0%    0.0%        55      0    489       4
24 - (            CMS)     20       8       3    0.0%    0.0%       199      0    132      14
26 - (    ADCINTERNAL)      1       6       5    0.0%    0.0%         9      0      7      11
28 - (SPEED_NEGOTIATION)     94       7       0    0.0%    0.0%        88      0    626       5
RX Check Function                  21       2                     28530
Total (excluding SERIAL)                                36.8%
haslinghuis commented 1 week ago

@hydra

EDIT: pressing the boot button a few times and FC will go in serial mode, but after save and reboot it returns to DFU mode.

blckmn commented 1 week ago

This would be perfect on a 7x7 AT32 and put onto the VTX with canvas support via serial. The preference is to move all video processing OFF the flight controller and onto dedicated hardware (namely the VTX). This follows the digital model.

For those wanting to use existing VTXs there could simply be a small daughter board manufactured (like the minimOSD of old). This would then minimise the video cable runs - as it could be mounted nearer to the camera or VTX.

sugaarK commented 1 week ago

This would be perfect on a 7x7 AT32 and put onto the VTX with canvas support via serial. The preference is to move all video processing OFF the flight controller and onto dedicated hardware (namely the VTX). This follows the digital model.

For those wanting to use existing VTXs there could simply be a small daughter board manufactured (like the minimOSD of old). This would then minimise the video cable runs - as it could be mounted nearer to the camera or VTX.

the f421, f423 and f425 are all available in 4x4mm package's

blckmn commented 1 week ago

@hydra For this to be merged you'll need to move all aspects of your implementation into the lib directory, provide a non specific interface in 'main' so other implementations could use it, and your implementation can be easily excluded or preferably if possible tap into the existing osd interface so there's no specific spracing defines in 'main', ie if absolutely necessary use generic terms for pixelosd and move all nvic priority adjustments to config.h

LD files should also be moved to your lib, and we might need to think about an extra option in config.h that's extracted in config.mk to specify the LD file to use.

The above code in BF option is purely because you have targets already. The reason for the above is to remove as much pain for the rest of the team to work around the pixelosd code whilst developing other features for such few targets using it.

It will also make it easier for you to include and to distribute your own custom firmware should the feature be dropped in some future version of BF.

Manufacturers please note: The absolute preference is still that this is implemented on a small mcu (the io requirement is low) and implemented / mounted on the vtx, and it's connected to the FC via serial. Please reach out to discuss any design prior to manufacturing.

hydra commented 4 days ago

@hydra For this to be merged you'll need to move all aspects of your implementation into the lib directory, provide a non specific interface in 'main' so other implementations could use it, and your implementation can be easily excluded or preferably if possible tap into the existing osd interface so there's no specific spracing defines in 'main', ie if absolutely necessary use generic terms for pixelosd and move all nvic priority adjustments to config.h

Firstly, hi, thanks for the update!

Can you clarify why there should be no specific spracing defines in 'main', as this is the approach we take for all drivers, e.g. ICMxxxx, BOSCH, FRSKY, Spektrum, etc.

The generic code vs driver code is already gated appropriately.

Example of generic gating: https://github.com/betaflight/betaflight/pull/13603/files#diff-abe609384eb39bf65d2de0c1e5af3c2c1b51ce3f632a0ad394ece1acc9c6783aR406-R409

Example of driver specific gating: https://github.com/betaflight/betaflight/pull/13603/files#diff-f1295987bea33eb28fa10499c47023925c50045c50ab2c6b23295e0de89dba09R675-R679

Example of pre-existing manufacturer specific code in init.c: https://github.com/betaflight/betaflight/blob/71b892d3bc97fd6ae7c6fc91c787c7323533947c/src/main/fc/init.c#L469-L482

hydra commented 4 days ago

@hydra

  • after second test (cold boot) the board only gets into DFU mode after cloud build.
  • even happening after flashing the supplied firmware here.
  • bare board EDIT: pressing the boot button a few times and FC will go in serial mode, but after save and reboot it returns to DFU mode.

I was encountering similar random reboots into DFU mode recently due to an ELRS receiver on the UART sending 'R' on power up, especially on cold-boot. Please re-test with nothing attached to any serial port that has MSP enabled. See https://github.com/betaflight/betaflight/pull/13572

The only reason the board will reboot from BF to the BL is if BF tells it to by writing the reboot reason into the RTC backup registers and then issuing a reset. I went though this very recent for #13572.

If this is still an issue PM me on discord and I'll work though the issue with you.

blckmn commented 1 day ago

Firstly, hi, thanks for the update!

Can you clarify why there should be no specific spracing defines in 'main', as this is the approach we take for all drivers, e.g. ICMxxxx, BOSCH, FRSKY, Spektrum, etc.

The generic code vs driver code is already gated appropriately.

Example of generic gating: https://github.com/betaflight/betaflight/pull/13603/files#diff-abe609384eb39bf65d2de0c1e5af3c2c1b51ce3f632a0ad394ece1acc9c6783aR406-R409

Example of driver specific gating: https://github.com/betaflight/betaflight/pull/13603/files#diff-f1295987bea33eb28fa10499c47023925c50045c50ab2c6b23295e0de89dba09R675-R679

Example of pre-existing manufacturer specific code in init.c:

https://github.com/betaflight/betaflight/blob/71b892d3bc97fd6ae7c6fc91c787c7323533947c/src/main/fc/init.c#L469-L482

Something we do not want to perpetuate, i.e. it is related to historical usage. We have progressively been moving away from this approach, and an example is with the MCUs themselves - being moved into areas of "containment" and not being riddled throughout the code base. We will continue to get further down the track such that the core code is free of these cases. What we can't do is add to it.