-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SPRacingPixelOSD Support (2024) #13603
base: master
Are you sure you want to change the base?
SPRacingPixelOSD Support (2024) #13603
Conversation
It's potentially possible to initialize the pixel osd system even when the OSD feature is disabled.
…hat all calls to clearScreen are within transactions.
* Some tools, like readelf, don't display long section names well.
Do you want to test this code? You can flash it directly from Betaflight Configurator:
WARNING: It may be unstable. Use only for testing! |
9af2fc3
to
3c7bec8
Compare
the target config includes '#define USE_SPRACING_PIXEL_OSD'.
per-mcu shortlist. Note that this is an identical approach to the use of 'bbTimerHardware' in dshot_bitbang.h where 'pacer' timers are required.
…don't preempt the video ISRs. Without this, display corruption and loss-of-sync occurs. Especially noticable on H730 EXST targets. Less so on H750 EXST targets that run code from RAM.
…ultiple framebuffers to avoid flickering and artifacts.
USE_SPRACING_PIXEL_OSD is enabled.
The linker scripts were based on the H750 linker scripts, the memory layout comments have been deleted as they were incorrect. Refer to the MEMORY section.
missed packets which is more useful and less obtrustive and eye-catching.
Pixel OSD targets.
3c7bec8
to
71b892d
Compare
Updated branch, all builds passing. Binaries for testing: |
@haslinghuis do you have hardware to test this? and @SteveCEvans ? |
# 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% |
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. |
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 |
@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. |
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: Lines 469 to 482 in 71b892d
|
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. |
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. |
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: