Its been a year since I started this OSD project,
or 6 months since I stopped, and I want to give an update on what happened along the way.
When I started I thought an open sourced OSD with graphics would generate a lot of interest in the betaflight community. I saw it as low hanging fruit that could be done rather cheap and quick, but I misjudged the interest. This cause me to make certain software design decisions that in retrospect, I should not have made.
The software mixes 2 display layers in realtime, one for text, and another for graphics. This barely fits on a M0+ and required some creative optimizations to work as it runs a 15K IRQ/second line rate. A single layer approach is around 70% nops, so I wanted to do something useful with those cycles, the 2 layer display was born. This ends up causing minor tearing (1-2 pixel) when betaflight sends SPI commands. This could be overcome if commands are sent during a VBI so I have a pin go low, but this would require a betaflight modification. Having 70% NOPs in your is useful to give the DMA some time to run. Other differences such as changing the display from 30x12 characters to 32x13 characters (or interlace) seems like an improvement but would require changes on the betaflight side to get any benefit.
The betaflight code changed from compile time binding to run time binding, AKA unified targets. This put size pressure on their code. They had to pick what features would be included. I was offered support on the H7 mcu (1 Meg flash) chip, but I decided that a 'high end' chip was not a good match for my sub 2 dollar M0+ OSD design. Then there is the switch to digital video, Pixel OSD support on the mainstream 512K flash build, low interest from resellers, low traffic to this site, it just made no sense to add addition time to this project.
or 6 months since I stopped, and I want to give an update on what happened along the way.
When I started I thought an open sourced OSD with graphics would generate a lot of interest in the betaflight community. I saw it as low hanging fruit that could be done rather cheap and quick, but I misjudged the interest. This cause me to make certain software design decisions that in retrospect, I should not have made.
The software mixes 2 display layers in realtime, one for text, and another for graphics. This barely fits on a M0+ and required some creative optimizations to work as it runs a 15K IRQ/second line rate. A single layer approach is around 70% nops, so I wanted to do something useful with those cycles, the 2 layer display was born. This ends up causing minor tearing (1-2 pixel) when betaflight sends SPI commands. This could be overcome if commands are sent during a VBI so I have a pin go low, but this would require a betaflight modification. Having 70% NOPs in your is useful to give the DMA some time to run. Other differences such as changing the display from 30x12 characters to 32x13 characters (or interlace) seems like an improvement but would require changes on the betaflight side to get any benefit.
The betaflight code changed from compile time binding to run time binding, AKA unified targets. This put size pressure on their code. They had to pick what features would be included. I was offered support on the H7 mcu (1 Meg flash) chip, but I decided that a 'high end' chip was not a good match for my sub 2 dollar M0+ OSD design. Then there is the switch to digital video, Pixel OSD support on the mainstream 512K flash build, low interest from resellers, low traffic to this site, it just made no sense to add addition time to this project.
Hi! I am interested in your findings when working on the OSD system and your flight computer. I am trying to create an open-source, low-cost flight computer for fixed wing planes for iNav / Betaflight and would love to hear your thoughts on what to use in place of the deprecated MAX7456. Does your open-source FC have software to go with it? Did you end up getting it working in Betaflight? What are you using instead?
ReplyDeleteIt runs fine, I compiled the code in December, it works as designed.
DeleteIt will work in betaflight because it understands normal MAX7456 spi commands, in compatibility mode. The issue is that a MAX7456 uses 12x18 pixel characters on a grid of 13 rows by 30 columns NTSC. This project uses 12x16 pixel characters on a grid of 14 rows by 32 columns. So in compatibility mode, the last row and the first and last column is always left blank. Without changes on betaflight's side, it will just look worse than an AT7456 would, so why sell an inferior product.
I like what I wrote (in the program), Its a good design and it works very well. but i added too many innovative features that the market did not ask for. I felt it best to publish the hardware schematic and leave the software for the next guy. (there was a lot of 'I am going to do this too', during my 3 month encounter with the betaflight team in late 2019. )
Anyways I rarely fly anymore, so I really would not know what the people are using today, the AT7456 should be available in china.