Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Programs to display information to LCD framebuffer
As for software ideas, I think that your ideas are really good.

However, I think some users won't want to have the info outside of the viewable area. One thing I think that could be useful is to have this info on the main viewable area (as an option) but only when a certain key combo is pressed. We have some data like this for our fbcp ( driver, but the driver is better in general once it's a bit more stable all around. Our fbcp driver has a low-batt indicator that pops up, but since it's built in to the fbcp, then it's hard to augment.

I think it's also possible that more people will start doing builds that use the entire LCD (by opening up the shell area). That's where I think it'll be good to have this data easily placable anywhere based on a parameter.
Card Fighters' Clash 2 English Translation ( )
Neo Geo Pocket Flash Cart and Linker Project ( )
Avatar art thanks to Trev-Mun ( )
I just added plot script :
Attachment as output example.

Attached Files Thumbnail(s)
Before writing outside of viewing area, I was thinking to use SDL as a overlay but since there is no real X manager this was a total fail. I was not interested about modify driver itself.

I think there is a way to add screen overlay using Dispmanx overlay :
But since "screen" is 1024x768 and then resize, you have to generate a 1024px width picture. Another problem is that is not possible to use in SDL driver :/

There is a simple way to detect the driver sleep mode, but GPIO_TFT_BACKLIGHT and BACKLIGHT_CONTROL need to be set when compiling driver, since there are some gpio pins not in use (maybe 34-39 present under compute module), checking current state of this pin is a easy task Smile

Can you provide me all arguments used to compile fbcp-ili9341 to the CM3 please?
Found a very simple way for screen overlay, the trick is to use OMX.

Some file need to be created for the test:
00:00:00,00 --> 00:00:05,00
Battery: 4.20v - 72Mbits - 18:51

Convert attached png to avi:
ffmpeg -loglevel panic -y -loop 1 -i black.png -t 5 -r 5 -vf scale=16:-2,setsar=1:1 -force_key_frames 1 black.avi

Run OMX:
omxplayer --no-osd --no-keys --alpha 150 --layer 2000 --win 0,0,1024,50 --align center --font-size 750 --no-ghost-box --subtitles black.avi

Attached Files
.png   black.png (Size: 124 bytes / Downloads: 53)
Uploaded overlay deamon to my github :
Compile using then run in 2 shells or then

Please note:
when using, Addon board hotkey button is used to display 'osd', input checking interval is for the moment hardcoded to 200ms

Attached Files Thumbnail(s)
Awesome. That's pretty cool, Porcinus!
Card Fighters' Clash 2 English Translation ( )
Neo Geo Pocket Flash Cart and Linker Project ( )
Avatar art thanks to Trev-Mun ( )
Thanks Wink
Just updated Git. each program run as 'daemon', example files and service files are provided, Info and usage are also updated.
Overlay now use the original footer png converted to avi file (low priority)

Edit: Now display picture directly, no more png->avi conversion

Attached Files Thumbnail(s)
I was thinking about this again today, so I looked up the datasheet of the MCP3021. It should be able to take 5V as its VDD. That means, in theory, that you wouldn't need the voltage devider resistors R1 and R2 to drop the battery voltage to the 3.3v range. I think that you could run the chip at 5V and then use the battery voltage as a direct input. You could also, maybe, use a different voltage regulator to drop the 5V input down to 4.5V or so to use as VDD.

The only issue I see here is that the SDA line will be 0-3.3V. The datasheet says that the minimum high-level input should be 0.7VDD. If you run the chip's VDD at 5V, that would be (0.7 x 5) 3.5V. 3.3V would be under the minimum. I'm guessing it would still work, because the maximum low-level input is 0.3VDD. Anyway, it could be worth a try.
Card Fighters' Clash 2 English Translation ( )
Neo Geo Pocket Flash Cart and Linker Project ( )
Avatar art thanks to Trev-Mun ( )
I have think about this possibility this weekend and updated my Git for this case.

The prototype "schematic" you have on hand is not up to date, at this point I can supply the battery monitoring ADC chip at 5v by cutting one trace and adding a jump wire coming from RTC VDD. This chip is the last in the MCP3021 row (not the pullup side) so no problem for this.

For the I2C line, If the chip is able to initialize I think the only issue could be some missing samples, no big deal for this use.

At 5v the samples resolution is still great, around 0.005v.

The only downside I see here is the noise due to the 5v, but since the other will be powered by a AMS1117-3.3, I think only real world testing will be relevant Smile

For who reading this, I am trying to make an "advanced" addon board with a USB Nanohub 2 ports, BL-R8188FU3 WiFi module, DS3231M RTC module, 3 MCP3021A ADC (2 for the the Joypad and one for the battery monitoring) and a cooling fan.

Thanks for the time you've take on this Flavor Wink

Forum Jump:

Users browsing this thread: 1 Guest(s)