Start a new topic

Dynamic picture over Serial in under 15 sec

Dynamic picture over Serial in under 15 seconds

    ... just saying.


NX8048K070_011C - Enhanced Capacitive 7.0" 800x480

mp4

1 person likes this idea

Hmmm. 


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

  http://support.iteadstudio.com/support/discussions/topics/11000013640

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.


I just wonder how the code looks like, I might think of this:
A button with a while statements that splits a string into pairs of two chars, converts those in numbers and draws a point in the number specified by the numbers, incrementing internal vars for x and y (you can draw va0.val,va1.val,va2.val,va3.val,va4.val). The MCU will send a string, click the button...and then the magic happens.

 

So what of the future?

How do you mean?

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) 

I guess, no future about this ... all done ...

proof of concept, pictures, photos, QR codes can be transferred in acceptable speed via RS232 to a Nextion display ... that's all ...

but I wouldn't expect that Patrick will show the idea behind ... anybody can have the same ideas ...

and as long as you have a Nextion display, you can do the same by yourself ... not?  

:-)

 

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?


Nextion HMI displays have a completely other target than Smartphones do ... even you can use your smartphone to remote many things, but I neither  would use for many nor would I like to fix install my smartphone ...

you even can't run your smartphone completely without battery, and charging cycles of a normal lipod is already a showstopper for most commercial projects ...

or to use a non save Android system inside a critical industrial environment ... mhmhmhmhmh

Things like "Long Term Availability" or "Long Term Support" are surely not that important for a hobbyist, but no seriouse product can be brought to market without such ... or would you like to change your own product every few years only because your used Android Smartphone is nolonger available?

That's also the reason, why you still can find a simple 555 design in many todays household machines ...

A Nextion HMI display was never and will never be a replacement for your Smartphone, MP3-Player, DVD-Player, Ebook reader or any other such ...

for hobby, you can do such things, but again, that's not our real main target ...

I did some POC code. Aall you need to to add is a button b0, a text field t0 and 4 variables va0, va1, va2 and va4. Then add this script to the button:
b0.txt="00020002123499991111222233334444"
substr b0.txt,t0.txt,0,4
cov t0.txt,va0.val,0
substr b0.txt,t0.txt,4,4
cov t0.txt,va1.val,0
for(va3.val=8;va3.val<=20;va3.val=va3.val+4)
{
  substr b0.txt,t0.txt,va3.val,4
  cov t0.txt,va4.val,0
  line va0.val,va1.val,va0.val,va1.val,va4.val
  va0.val++
  fill va0.val,va1.val,4,4,va4.val
  va0.val++
  va0.val++
  va0.val++
  va0.val++
}

 

If you press the button 4 dots are painted.

The same happens when you send this over the serial line:

b0.txt="00020002123499991111222233334444"
click b0,1

 

There's no MCU code that would required to prepare the image, and there's no optimization at all (and colors are limited to 0-9999dec). First thing to optimize would be transfer space for the serial line, currently the string is simply converted to a number. However it should be possible to use at least 64 different characters which would give 64 instead of 10 possible values per char. And maybe it's possible to have even 128 different characters, if non-printable chars can be used - I didn't try. And then 64 (or 128) 'if' clauses to convert them back to a number...

Login or Signup to post a comment