search

betaflight / betaflight

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

SPRacingPixelOSD Support #10702

Closed hydra closed 1 year ago

hydra commented 3 years ago

This PR adds support for the SPRacingPixelOSD system. This PR replaces PR #9640.

Specs, theory-of-operation, reference schematics, binary blobs and full source for it can be found here: https://github.com/spracing/spracingpixelosd

Summary of changes:

hydra commented 3 years ago

Updated and rebased on master.

github-actions[bot] commented 2 years ago

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

hydra commented 2 years ago

I rebased the commits a couple.of days ago, will update this PR ASAP.

hydra commented 2 years ago

Rebased on master

github-actions[bot] commented 2 years ago

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

github-actions[bot] commented 2 years ago

Pull request closed automatically as inactive.

haslinghuis commented 2 years ago

@hydra this needs rebase

hydra commented 2 years ago

I have been waiting for other PR's to be merged in, now that many have I'll try and find some time to update this PR.

hydra commented 2 years ago

Rebased against master.

haslinghuis commented 2 years ago

make[2]: *** No rule to make target 'drivers/accgyro/accgyro_spi_icm42605.c', needed by 'obj/main/SPRACINGH7CINE/drivers/accgyro/accgyro_spi_icm42605.o'. Stop.

hydra commented 2 years ago

make[2]: *** No rule to make target 'drivers/accgyro/accgyro_spi_icm42605.c', needed by 'obj/main/SPRACINGH7CINE/drivers/accgyro/accgyro_spi_icm42605.o'. Stop.

Fixed the rebase issue - I was testing with the SPRacingH7NP target.

SteveCEvans commented 2 years ago

@hydra I note that that the ICM426xx driver doesn't support gyro DMA nor scheduler locking as it doesn't use the acc->readFn and gyro->readFn support in accgyro_mpu.c. Happy to fix if you send me some hardware.

hydra commented 2 years ago

@hydra I note that that the ICM426xx driver doesn't support gyro DMA nor scheduler locking as it doesn't use the acc->readFn and gyro->readFn support in accgyro_mpu.c. Happy to fix if you send me some hardware.

I'll get one shipped ASAP. Digging your address out and printing a label now... EDIT: ready to ship, I'll post it from England on Tuesday on my trip to save some transit time.

Dominic

github-actions[bot] commented 2 years ago

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

hydra commented 2 years ago

@SteveCEvans Did you get around to doing the ICM426xx driver changes using the hardware I sent to you?

This PR just requires the testing noted in the first post to be completed, if anyone has time to test please do so.

SteveCEvans commented 2 years ago

Hi @hydra I was waiting for you get basic support for the H7RF in master. Once that’s in place I can add the DMA support for that gyro.

hydra commented 2 years ago

Rebased on master

hydra commented 2 years ago

Rebased on BF master branch a63172cc1f169ebe7aacf970fd51b1121a943c9c.

This requires rework now that @SteveCEvans PR #10813 is merged which made similar changes to the OSD task to make it 'less peaky'.

asizon commented 2 years ago

So this should go in 4.4??else we need to test all video systems including frskyosd.

hydra commented 2 years ago

So this should go in 4.4??else we need to test all video systems including frskyosd.

yes, it's already scheduled for 4.4, there's not enough time between now and 4.3 for me to do the rework required, which is significant and requires a lot of testing.

asizon commented 2 years ago

Nice, good work here. Definitelly we need an opensource video systems.

hydra commented 2 years ago

These things are now gone from this PR:

This PR is still valid and works without the above changes for the H7CINE or H7NP targets in this PR but performance can be improved as time permits.

hydra commented 2 years ago 
# status
MCU H750 Clock=480MHz, Vref=3.30V, Core temp=63degC
Stack size: 2048, Stack address: 0x2001f000
Configuration: CONFIGURED, size: 3959, max available: 131072
Devices detected: SPI:1, I2C:1
Gyros detected: gyro 1 locked dma
GYRO=ICM42605, ACC=ICM42605, BARO=BMP388
OSD: SPRACINGOSD
System Uptime: 2913 seconds, Current Time: 2022-01-03T18:29:36.719+00:00
CPU:2%, cycle time: 123, GYRO rate: 8130, RX rate: 15, System rate: 9
Voltage: 75 * 0.01V (0S battery - NOT PRESENT)
I2C Errors: 1
SD card: Startup failed
Arming disable flags: RXLOSS CLI MSP

# version
# Betaflight / SPRACINGH7CINE (SP7C) 4.3.0 Jan  3 2022 / 13:39:04 (146a0b2c5c) MSP API: 1.44

image

image

Please excuse the grainy camera image caused by long cables and interference on my bench testing equipment and cheap USB video capture device. 🤣

hydra commented 2 years ago

The code for async screen clear and rx loss on disarm is now in PR #11330 which is actually also needed for RX SPI systems as well on-board OSD systems that have more expensive screen clearing and drawing routines.

hydra commented 2 years ago

Issues with ELRS / Scheduler appear to have been worked out, I'll update this PR branch as time allows.

Latest code can be found in this branch (https://github.com/spracing/betaflight/tree/spracing-20220406-2041), along with other H7RF target code, no major OSD related changes recently though.

hydra commented 1 year ago

blocked on https://github.com/betaflight/betaflight/pull/11662

hydra commented 1 year ago

rebased on master, however I still need to make sure all the latest SPRacingPixelOSD and OSD code changes from my bf-h7rf-wip-24 branch have been pulled in to this PR.

github-actions[bot] commented 1 year ago

Do you want to test this code? Here you have an automated build: Assets WARNING: It may be unstable. Use only for testing! See: https://www.youtube.com/watch?v=I1uN9CN30gw for instructions for unified targets!

hydra commented 1 year ago

Remaining changes from the H7RF WIP branch merged, Rebased against master.

Finally ready for review!

github-actions[bot] commented 1 year ago

Do you want to test this code? Here you have an automated build: Assets WARNING: It may be unstable. Use only for testing! See: https://www.youtube.com/watch?v=I1uN9CN30gw for instructions for unified targets!

sugaarK commented 1 year ago

As I’ve tried to tell you 2 times now… Betaflight won’t be adding any closed source or proprietary functionality under the current management

Quick-Flash commented 1 year ago

As I’ve tried to tell you 2 times now… Betaflight won’t be adding any closed source or proprietary functionality under the current management

This is really like saying you wont support frsky osd. It's really not too different than that.

hydra commented 1 year ago

As I’ve tried to tell you 2 times now… Betaflight won’t be adding any closed source or proprietary functionality under the current management

This is really like saying you wont support frsky osd. It's really not too different than that.

exactly, or any other GPS / RX / VTX system that has closed source code for that matter, like Futaba, Spektrum, TBS, ImmersionRC, UBLOX, etc. The only real difference is that the BIOS code for the OSD lives on the same chip and the interface is an FFI instead of UART.

What about dual core CPUs where the memory is shared and one core runs e.g. ELRS/OSD/ESC code and the other runs BF?

KarateBrot commented 1 year ago

Why don't we make an open source pixelOSD that can be run by any FC?

sugaarK commented 1 year ago

As I’ve tried to tell you 2 times now… Betaflight won’t be adding any closed source or proprietary functionality under the current management

This is really like saying you wont support frsky osd. It's really not too different than that.

If we had our way we wouldn’t support frsky osd.. what we inherited changes nothing moving forward all these closed systems would get told the same thing… make it open source or get your fork on..

sugaarK commented 1 year ago

Why don't we make an open source pixelOSD that can be run by any FC?

This @hydra… I know there are a bunch of closed source functions in Bf but they are all historical and would meet the same push back under the current management. Happy to help make it a reality and get uptake with the manufacturers but not happy to add another closed source protocol to the project

hydra commented 1 year ago

Why don't we make an open source pixelOSD that can be run by any FC?

Likely due to the amount of time and effort it takes to make one. Both my solution, and @fiam's (which became the FrSky PixelOSD took a significant amount of time and resources. There is a cost to developing one which can't easily be recovered without keeping some design secrets. With my solution, unlike the FrSky one which is all closed except for the UART protocol, most of the code is open source, you see it all in this PR. The only part of the is closed is the sync and pixel stream code. I feel that this is a pretty good compromise. This PR also makes it easier for others to design their own PixelOSD systems if they want to since all the driver code and framebuffer code can be re-used.

This @hydra… I know there are a bunch of closed source functions in Bf but they are all historical and would meet the same push back under the current management. Happy to help make it a reality and get uptake with the manufacturers but not happy to add another closed source protocol to the project

They're not all historical, CRSF, SmartAudio, Tramp, etc, all new. It's not at all clear where the line is when it comes to supporting new hardware. Only the older technologies, like SBus/Spektrum, UBLox, etc pre-date the Betaflight project.

Also, there's already precedent of closed-source code within BF itself in the form of the BMI270 driver, which uses this: https://github.com/betaflight/betaflight/blob/master/lib/main/BoschSensortec/BMI270-Sensor-API/bmi270_maximum_fifo.c#L51-L70

Unlike the BMI270 driver that this PR doesn't contain any binaries which would need to be compiled in or otherwise linked with as the OSD bios code lives on the external flash chip.

Quick-Flash commented 1 year ago

Why was recent support given for CRSF v3 when that's a closed source protocol? I really don't get it. Its really like your playing favourites here.

sugaarK commented 1 year ago

As usual you have basically no idea what you are talking about @Quick-Flash. The bf management team changed in mid December not before and it was well and truly merged by then. Also this protocol is already in use by our good friends at elrs and is a long term benefit to that project. This Pr serves the needs of the few and frankly no one with the merging rights to get it over the line agrees with merging this into the bf repo..

Quick-Flash commented 1 year ago

As usual you have basically no idea what you are talking about @Quick-Flash. The bf management team changed in mid December not before and it was well and truly merged by then. Also this protocol is already in use by our good friends at elrs and is a long term benefit to that project. This Pr serves the needs of the few and frankly no one with the merging rights to get it over the line agrees with merging this into the bf repo..

So glad that this information was made public and spread around. Really is nice that it was made clear that BF had changed their policies without telling anyone and just assuming that people would magically understand that things had changed. Great policy to have to be honest.

Also the fact that ELRS uses CRSF does not make it an open source protocol. Someone could write an opensource pixel OSD implementation, and then again, it would be like CRSF which is used by ELRS. I really don't get you guys.

sugaarK commented 1 year ago

You are owed absolutely nothing by this project @Quick-Flash especially with some of your past plagiaristic behaviour… you can keep your very poor moral compass to your self frankly..

Quick-Flash commented 1 year ago

You are owed absolutely nothing by this project @Quick-Flash especially with some of your past plagiaristic behaviour… you can keep your very poor moral compass to your self frankly..

Im so grateful that me and anyone not a part of the inner bf circle deserves no knowledge of how to properly contribute to BF. Sounds like a very good policy.

sugaarK commented 1 year ago

Haha don’t try and bring any one else into this @Quick-Flash this is about you and your relationship with Betaflight. Remember it was the current team who unbanned you from all the Betaflight platforms and even invited you to participate in our IMU overhaul..

hydra commented 1 year ago

@Quick-Flash Appreciate your support but can we keep this issue focused on getting the required policy clarification.

@sugaarK Can you please reply to https://github.com/betaflight/betaflight/pull/10702#issuecomment-1230149375

sugaarK commented 1 year ago

@hydra i can reopen this PR but the truth is no one in a position to approve it is going to as they don’t see the value of a closed system for such a frankly tiny manufacturer.. there have been over 170000 downloads so far of the 10.8 configurator how many of those users would benefit fit from this feature in any way at all ?

hydra commented 1 year ago

@sugaarK that would be great, yes please re-open it.

With regard to the benefit, there's a bit of a chicken and egg situation; software support is required for manufacturers to commit to building the hardware. The foundations for supporting different types of OSD solutions (aka DisplayPort, and Canvas) has to be developed, otherwise we'll all be stuck using MAX7456 forever.

With regard to the size of my company, yes I agree it's small, however there are some points; SP Racing (aka I) have developed many software and hardware solutions, usually before everyone else, which enables most other manufacturers build on the work already done. I've spent countless hours debugging, testing and submitting PRs, most other manufacturers barely even get involved, and when they do they often ask me when they have issues. A number of larger manufacturers who primarily only make hardware have contacted me regarding wanting to use the SPRacingPixelOSD system, some of which have already shipped hardware which already contains the PixelOSD BIOS. Lastly I'm aware of at least 2 people that are developing Pixel-based OSD solutions for which the work and code in this PR has already been extremely useful to them while they're developing their solution.

haslinghuis commented 1 year ago

Reopening as to have an alternative to MAX7456. It might have options for digital OSD.

github-actions[bot] commented 1 year ago

Do you want to test this code? Here you have an automated build: Assets WARNING: It may be unstable. Use only for testing! See: https://www.youtube.com/watch?v=I1uN9CN30gw for instructions for unified targets!

blckmn commented 1 year ago

AUTOMERGE: (FAIL)

github-actions[bot] commented 1 year ago

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.