you can customize the firmware upload page, for example:
- change the white background color
- insert a background image
- move and customize the texts that indicate the upload
would be a nice feature
and how much of the still available 4k sram for user code do you like to give away for such "bells and whistle" features?
your thinking is just a bit wrong ... :-)
things like different background colors for the upload process must be dynamic and indeed changable by users.
this only can happen within code ...
a dynamic handling needs always more space in code than a fixed constant handling ...
sorry, but exactly your available codespace is not endless, it is a limited ressource ...
and momentary you have around 4KB left for user code ...
and every byte more for firmware gimmicks is a byte less from your available user codespace to run your TFT ...
and I don't see the big sense to robber memory away for beautify your upload screen. The final running TFT is the important part, not your upload process ...
functional enhancements for your TFT, good, enhancements without any real function is just a waste of available ressources ...
Sorry, but such requests are surely not taken ...
With all the microcontroller programmers that use Nextion, it is a shame
that the same purposeful thoughtful logic rarely applies to requested features.
"No matter what memory" ?
Why with so little purposeful thought
towards the ramifications of implementing such on fellow users?
Doesn't matter if it breaks this and that for other user projects
Not like it is my project that will break so I care less. Just do it.
So perhaps with just a bit more thought towards community benefit.
With such requests from microcontroller programmers, I'd expect better.
For this we have up-voting.
So we will see what the rest of the community thinks about it.
When a significant number of the community will up-vote the idea
then maybe more serious thought can be given to.
Perhaps those up-voting will provide some thoughtful purposeful arguments for it.
- until then, the interests of the community must be protected
thanks to Martin for your intervention
I work with microcontrollers with less memory,
nothing is impossible, I always say: want power.
I presented the problem, because who decides to upgrade the monitor to its customers,
it would be nice to see an image instead of the white background color.
Sorry, it wasn't an intervention, rather more of an explanation.
But for a sake of argument and constructive debate.
- Nextion is able to provide a cost effective HMI solution
when its costs are not bloated with the unnecessary.
- every bloat unnecessarily raises the cost for all users.
You state you work with microcontrollers with less memory.
- then you also have a bit of understanding of limited resources
Limited resources on Nextion as well as within your own project.
Nextion is committed to provide 3584 bytes towards User HMI.
When bloat costs more than the 4608 that firmware then has
- the community must give up something so the new can fit.
This you would also understand with your microcontroller.
- if new function is larger than what you have something must go.
But, you are also in control of the selection for your project
- and the selection of a microcontroller with less memory was because?
- perhaps was to keep your costs lower?
Many in the community will perhaps reject the notion
that their costs for Nextion should rise for something they do not need.
Many in the community might see such as passing your costs onto them.
But just when you begin to figure out what functions should go to make room
- this will be some function many in the community favour and want to keep.
Image rather than a text screen will surely require more resources.
- and those resources will indeed have to come from somewhere.
Most projects are set (tft file uploaded to device) at manufacturing time.
as such, the consumer will never see such an upload.
Only an over the air upgrade where swapping tft out on the fly may need.
- and this even requires even more resources on your side to do the swap
so a microcontroller with less memory will be less likely to accomplish.
Hiding the upgrade process behind an image (as Windows upgrade does)
hides all status of success/failure and possible reasons from a failure.
This will surely increase all support costs when you can't see failure causes.
Such support costs will always have to be passed forward.
- if this was Nextion users whose costs rise, less community support for such
- if this was your customers whose costs rise, decreased sales for sure.
If an upgrade process had image and maintains the status on screen
- this is further more resources required, and perhaps even more must go.
But even when considering an OTA upgrade scenario
- perhaps updating at obscure hours means no one ever sees such white screen.
So if such cost increases can be avoided just because of logical considerations
I would expect there would be even less community support for this.
But the suggestion as it stands now still doesn't mention what functions go.
and without knowing what the community must consider to give up
it will indeed be hard for them to decide as it may be something the really need.
Everything can be done. But finally somebody must pay for ...
- in terms of money ...
- in tems of reduced ressources at another point ...
- in terms of maybe reduced functionalities at another point ...
Ressources are not free and unlmited available ...
- neither developers ...
- neither programming space ...
- neither left user coding area ...
- neither left user functions ...
See your Nextion as somekind of car trunk ... you have a limited space there, which you can use to transport your own things ...
but there are people out they like to drive on the save side, and they put 2 additional spare wheels in ... you can do this, but suddenly your user space is reduced for this size ... and suddenly the things you wanted to transport won't fit in anylonger ...
With one difference, the spare wheels you can remove by yourself. Firmware changes you can't ...
Therefore, every change, every new enhancement, must be thought very well. Especially when it comes to changes without any real functional meaning.
And 4KB left user space won't give big possibilities for implementing such visual gimmicks ...