Dynamic picture over Serial in under 15 seconds
... just saying.
NX8048K070_011C - Enhanced Capacitive 7.0" 800x480
How did you do this? Regardless of transferring the image over serial or not, I tried to paint an image pixel by pixel (using fill method for individual pixels) but it was a bit slower than this?
Also how did you transfer the image? use EEPROM with serial writes 1024 bytes at a time? (=512 pixels with 16bit color)
All within the Nextion Instruction Set ... PC to Nextion, 115200 baud.
Now I really would have thought EEPROM to be the fastest, but
EEPROM writing and access is much much slower. Especially over serial.
EEPROM also has a finite number of uses, though I certainly spent a few testing
the transfer it to eeprom and read out from (wept/rept) method.
EEPROM has less than 1024 byte abilities with rept/wept
this has to do with the serial buffer would overflow before 1024 bytes.
Nextion also has delays from interpreted code and not native machine code.
In the end serial was the fastest.
A bit of graphics preprocessing (on PC side), a rough data compression before
transfer, then Nextion side, unpack and draw rough graphic out to display
Thanks - just to check you effectively looped pixel by pixel and used fill command? I was disappointing with the looping speed of interpreted code on the nextion, even NOP loops take > 10 seconds to loop across 800x480 pixels - yet display a jpg flashed on can be displayed very very quickly.
Anyone worked out how to write native code so we can run custom firmware like the sonoffs?
Nextion Editor already creates a custom design that in turn is uploaded
and run on the Nextion device. Firmware is code that runs on an MCU.
In essence each HMI design already is a custom firmware, made easiest
by not having to crawl down into such low level MCU code. No?
The route for Native code is also rather simple. An STM32F030C8T6
(64K Flash, 8K SRAM) MCU with an SPI Flash, and a touch screen.
Write whatever code one likes, compile and upload.
But the rather interesting aspect of Nextion is not having to write all that
native MCU code to rock an HMI design and one is Nextion side ready in
hours instead of days, or days instead of months. So I might argue that
even if one could write natively, who wants to spend all the extra time
need to create each and every project.
Sure agree, nextion editor makes it very very easy to make simple applications, but it is also impossible to do more complicated things (for example, you can't even do binary operations like & << >>) let alone things like sending a bigger buffer over serial and directly displaying an image. The hardware is still quite cheap and nice (especially capacitive version) but it is quite limited for advanced operations (realize this isn't your target market).
Thanks for heads up on native code, I will take a look around.
impossible to do more complicated things? Indeed you can ...
the fact, that people "can't" do has nothing to do with the Nextion itself, but more with the "skills" of the user ...
- games? do it ... games corner shows many examples
- calculations? do it ... gallery shows many examples
- even things like sprites, sprite collision detection ... do it ...
we even run a "Stump the Chump" challenge, where users could ask for code and features they miss ...
honestly, we didn't get one single request, where we haven't been able to show a working solution within hours ...
The Nextion offers a nifty subset of commands which can be used very efficient. But sorry, the ideas how to use are not implemented ...
I am not disputing that Nextion is not full access to its MCU
- but you need to use a bit more facts if considering bashing it.
In fact & | << >> is coming
I let the cat out of the bag on this one 15 days ago.
But limited? I will be honest
I was using shift operations long before a << >> operator was available
- mind you I created crafty code to accomplish.
I created a Nextion side EEPROM Editor - all in Nextion logic.
- I would say advanced in in the hands of the programmer.
And I would argue about a advanced operations
Advanced operations is done MCU side and display is merely updated.
- Combine Nextion with a PIC 12F683 ... perhaps limited
- Combine Nextion with an Intel Edison or PI .. hardly limited
MCU chosen by the user is definitely a deciding factor
As a display that can also do co-processing - you don't get that in a display.
Bet even your desktop display doesn't do co-processing.
If I had the requirement to transfer images to the display I'd rather go with a ESP8266 or PI and a standard display - just because I don't want my user to wait for a picture longer than 200ms. The 15 seconds are OK for a proof of concept, but of no practical use.
The nextion display is very usable for a control panel, because there's usually no need to display pictures others than the predefined ones.
If you'd really need an option to transfer images over the serial port the best option would be adding a new 'pic' command that would take x,y,width,height and a hex string as input, displaying the bitmap provided in the hex string.
Ahh not really (to adding a new pic command).
Space for firmware is limited ... very limited.
What goes into firmware has to be worth it
- not just for a single project, but all projects
But to add a new pic command can be done in user code
- x.val, y.val, w.val, h.val,and data.txt in hex
But you'd also have to have to add a hex translation
How long will someone wait for a pic to display?
... depends on what the alternative is ... no picture? or picture?
To trigger a visual image representation also doesn't need 480x800 pixels.
So time required also could also be reduced. 1/4 screen image 1/4 time.
But as Nextion is an Human Machine Interface,
proper planning can have an image displayed in well under 200ms
Just include the image as an embedded resource.
So what of the future?
How do you mean?
Was just thinking out loud, will there be a Nextion II, where we can do stuff like this over a faster interface?
Nice job Patrick, but sub 15 seconds? as Maze says, no practical use, and just post the code anyways, there won't be many takers, your talents are wasted on version 1 :) Yeah we can interpret on the interpreter.
Just imagine what a toolset like HTML5 with SPI, I2C or wifi could bring, the competition is the smartphone, Nextion has to evolve!
Case in subject, I can now 3D print a nice cradle for my phone, that has a USB connected rotary encoder with an HTML5 page doing all the fancy interface stuff (in stunning HD!), why do I need a Nextion?
And don't get all defensive guys, the future is bright, provided Nextion moves with the times!
easy speaking, completely different market ...
or would you like to use an Android Smartphone as HMI touch interface for any kind of industrial machinery or any other commercial product out?