Out of interest, I took a 800x480 png (that I currently use as a
splashscreen):
* png size: 56KiB
* C file, using LVGL image converter: 5.4MiB
Eek!
On 28/03/2025 13:06, Nathan Hartman wrote:
Replying inline below:
On Thu, Mar 27, 2025 at 5:15 PM Tim Hardisty<timhardist...@gmail.com>
wrote:
Hi Nathan,
Thanks for your thoughts. It has made me think more logically (I hope)
about why and when you might want a splashscreen.
I'm currently thinking that it is only a pretty "hello world" that
allows branding. With that in mind:
* Embedded devices, using NuttX, may not have an LCD of course
* Whether to display a splashscreen is a decision only the product
design team (team of 1 in my case lol) can make
o Likewise: how long it's displayed for
* NXboot should only be there for a brief time -as you say - so not
really a place for a "wow, look at what you've just powered up"
pretty-pretty graphic
o If things go wrong during the bootloader process, a splashscreen
is irrelevant: that's where my error recovery suggestion comes in.
* NXboot - as I understand it and currently use it - boots an image
which is a complete standalone NuttX kernel and startup app: nsh to
get you going; a custom app, most likely, in the RW.
So:
* I think a splashscreen in the kernel *does* make sense.
* It should be enabled/disabled via Kconfig. But what default?
o Default "on" - would be good for new users
o Default "off" - doesn't change anything for current users
I think Default "off" makes the most sense. As you pointed out elsewhere,
systems running NuttX don't necessarily have displays. In fact, until now
everything I use NuttX for is deeply embedded, nothing visual you can see.
Even for systems that do come with displays, the developer might not want a
splash screen because the graphic consumes limited flash memory, or perhaps
because NuttX boots instantaneously so the graphic wouldn't be visible for
long enough to justify it being there. New users should have a relatively
easy time getting a splash screen if they want it, since it's only a
Kconfig away.
* If enabled, it will be displayed when the framebuffer driver is
registered
o default graphic would be NuttX logo
Agreed, there should be a default NuttX logo in case another one isn't
provided.
o custom logo can be supported via Kconfig choice
+ I favour a "c" or header file created using an online tool,
rather than messing around with converting jpegs on the fly.
Agreed a C header (of hex values) is preferred.
I wonder what would save flash memory--converting the image to a bitmap in
advance, and then the splash program just copies the bitmap to framebuffer
(more flash usage for the image, less flash usage for code to display it)
or saving the JPEG to flash (as a C header of hex values) at the cost of a
more complicated display code (less flash usage for the image, more flash usage
for code to display it).
I suppose one benefit of converting images to a framebuffer bitmap at build
time: any format can be supported (jpeg, png, svg, whatever).
* Timeout. Hmmm...
o "none" could mean display it and forget about it until something
comes along to reinit/overwrite. Onus on the developer.
o "auto" could mean display until NuttX is done loading. Is there
a signal or anything we could use to check this?
o a non-zero value "n" could mean keep it there for "n" seconds
regardless - and delay finishing NuttX load until that timeout
expires or NuttX is ready (whichever is longer). Also needs a
signal or something so we know when NuttX is ready.
* With the above implemented:
o the NXboot app could build it's minimal kernel with no
splashscreen enabled
o the "main" app could build it with a splashscreen enabled (if
wanted)
WDYT ;-)
Makes sense to me!
Cheers,
Nathan
