SPRacingPixelOSD Support (2024)

[hydra]

Important points:

• The MAX7456 was discontinued many years ago.
• The AT7456 and AT7456E are now also unobtanium at major electronic retailers, like LCSC (https://www.lcsc.com/product-detail/Microcontroller-Units-MCUs-MPUs-SOCs_ZHONGKEWEI-AT7456E_C82351.html)
• If you use LCSC's RFQ you'll get this reponse:
  

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:

[github-actions]

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

• Simply put #13603 (this pull request number) in the Select commit field of the Configurator firmware flasher tab (you need to Enable expert mode, Show release candidates and Development).

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

[hydra]

Updated branch, all builds passing.

Binaries for testing:
betaflight_4.5.0_STM32H730_SPRACINGH7RF_17c4fe0c6a.zip

[sugaarK]

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

[haslinghuis]

# 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]

@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.

[blckmn]

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]

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]

@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]

@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:

betaflight/src/main/fc/init.c

Lines 469 to 482 in 71b892d

	#if defined(USE_SPEKTRUM_BIND)
	if (featureIsEnabled(FEATURE_RX_SERIAL)) {
	switch (rxConfig()->serialrx_provider) {
	case SERIALRX_SPEKTRUM1024:
	case SERIALRX_SPEKTRUM2048:
	case SERIALRX_SRXL:
	// Spektrum satellite binding if enabled on startup.
	// Must be called before that 100ms sleep so that we don't lose satellite's binding window after startup.
	// The rest of Spektrum initialization will happen later - via spektrumInit()
	spektrumBind(rxConfigMutable());
	break;
	}
	}
	#endif

[hydra]

@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 #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]

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:

betaflight/src/main/fc/init.c

Lines 469 to 482 in 71b892d

	#if defined(USE_SPEKTRUM_BIND)
	if (featureIsEnabled(FEATURE_RX_SERIAL)) {
	switch (rxConfig()->serialrx_provider) {
	case SERIALRX_SPEKTRUM1024:
	case SERIALRX_SPEKTRUM2048:
	case SERIALRX_SRXL:
	// Spektrum satellite binding if enabled on startup.
	// Must be called before that 100ms sleep so that we don't lose satellite's binding window after startup.
	// The rest of Spektrum initialization will happen later - via spektrumInit()
	spektrumBind(rxConfigMutable());
	break;
	}
	}
	#endif

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.