Start a new topic
Not Taken

Nextion interface

Hey guys,

I would like to say thank you for the cool stuff you provide. 

It would be outstanding to have JSON interface to the display. Unfortunately the c++ library you provide is not suitable for me.

Perhaps this is like saying that the Nextion Library is not suitable because it doesn't contain my sensors?

Just add JSON to the library.

Understandably, the library goes out vanilla so it can be used with any kind of project

Don't want to adapt library code to my needs. It simpler for me to utilize currently provided interface where the way to set e.g. text box content is to send a following string  


    I just thought it would be cool if I were able to send to the device something like this 


  "my-text-box": {
     "txt": "content",
     "color": "red"

 And get the result in JSON if bkcmd != 0 from the device.

I think this is low priority task (it would really cool if you implemented font smoothing instead of this) but I also think it would increase the usability of the product.

I buy your devices

I am your Nextion support.  Taking posture "I buy your devices" is merely the wrong manner.

Such "I don't want to adapt library code to my needs." is tough luck.

65000 MCUs are used with Nextion in more than 130 programming languages.

I surely won't be writing your project, rather you are writing your project

- this is, has been, and will continue to be user duty.

JSON has been implemented by others

Smoothed font also accomplished by others.

But these again are user duty, unless via Project Units and user pays for.

For those not wanting to bloat their MCU side code with unneeded JSON

 - such is less value for them, especially when such a library will exceed their MCU capacities.

The hurdle you face with JSON for Nextion is

 - in which programming language

 - using which compiler

 - for which MCU target.

But it is not something that can be generic and encompass

all MCUs in all compilers in all programming languages.

When a project requirement has

 - JSON adapter

 - Smoothed Fonts

Then these all cost in terms of memory, space, performance.

The Nextion HMI only has 3584 Bytes of SRAM for the user.

 - to encroach on this space and give the user even less 

   is not a good idea

 - so this is then accomplished user side in MCU side code

Users must have the ability to select what they wish to give

away their precious little resources to.

And too few will select to give those resources away for such.

there are many such descriptive language's out ...
  • JSON
  • UML
  • XML
  • ...
  • ...
  • ...

all "great" when you have your big PC with nearly unlimited ressources ...

but when you must deal with embedded devices and maybe send your commands via RS232 such are just the wrong way to go ...

sorry, no implementation, that is not the world of embedded devices ...


Did not mean to offend you guys, sorry if I did. I just wanted to say that I have a relation to the device and we are going to use it in serial production.

You know better how it is actually going. I wanted to post the message to Free Chat instead of Feature Request, sorry for off topic.

Anyway as we talk. You told that the fonts smoothing is already solved. But before, I found a topic where is told that the fonts implemented like raster image with 1bit per pixel encoding. I also found this topic and I didn't succeed.  Even using fixed width fonts. Where am I wrong? Could you point me?


Today MCUs (like ARMs, I don't speak about tiny cases) are very powerful and have much resources. There is also this wonderful ArduinoJson library that is compiled everywhere I tried. It efficiently manages memory to construct objects. I talk just about JSON. UML, XML and other are not applicable.

 This is the a common mistake to think that we don't do this stuff due to we have too poor platform. 

JSON string has acceptable overhead in compare with plain string. 

They are easily streamed via RS232 especially on 115200. 

The advantage is that JSON is the standard de facto. 

This is really suitable and convenient way to exchange data used around the real world.

Thank you.

I have to debate, and argue JSON is not de facto standard even though popular.

When all go over the cliff, does not mean one should go as well because it is popular.

Nextion MCU on backside is an STM32F030C8T6, or other depending on model.

As experienced MCU programmer

 - Nextion capabilities exist in under 4608 bytes SRAM leaving promised 3584 for user.

 - when JSON can be implemented along with existing functionality and not exceed 4608 bytes

   then perhaps it becomes a little more serious of a discussion

 - until such time such is not possible.

One has to ponder, what functions they wish to give up.

And even though I can use an MCU such as Intel's retired Edison with 1GB ram 4GB resources

and I can implement such JSON in such amply resources MCU side, such resources are less common.

Nextion is for use with 65000+ MCUs types 

  TTL Serial using a UART module or via bitbanging 2 pins.

When such would break many implementations due to being to resource hungry

Nextion would not decrease its market simply for a few use cases

 - especially when such can be accomplished user side as desired.

Simple adapter on user side MCU

  Nextion format  <=> ADAPTER <=> JSON format

But such "interpreting JSON" inside Nextion, is not going to occur in Basic or Enhanced models.

It is unfortunate that many such requests by experienced MCU programmers fail

to take into account the available resources Nextion has.

apples vs. bananas ...

"Today MCUs (like ARMs, I don't speak about tiny cases)" ...

Unfortunately you won't find such on the backside of your Nextion ... a simple pcb-turn should be enough to show up which mcu is used ... :-)

You are right, when you use a RaspberryPi or even a SnapDragon with 4 cores, driving a complete Linux or Android opeating system, then you can play with nearly every development tool you like ...

people who need such can just stay with, no need even to use a Nextion ...
but even to think about to implement such into a 4/8K Nextion mcu is far away from real world and Nextion HMI scope ...

I use NX4832T035. It has STM32F MCU on the board. I see that it has 20 Kbytes of SRAM. 

So, I quite sure this approach is not applicable if we have no enough RAM for severity tasks. This case mostly happens on weak MCUs (I mean having low memory) like ATTiny, ATMega128. But for MCUs that have 20Kb and more it happens not too frequent. 

I don't know what MCUs Nextion use for other displays. If they have enough memory it's quite possible.

It's quite enough for current protocol to have 2 static buffers with 128-256 bytes capacity (total 0.25Kb - 0.5Kb). To find out exact size it's necessary to try.

RaspberryPi is a single board computer with huge amount of resources on board. Where MCU is a one-chip computer. Don't confuse this together. I use e.g. ATSAM3X8E it has 96Kb of SRAM.  I don't care about memory too (avoiding early optimization, but not doing pessimisation too). The arm-none-eabi-size give me this. I use JSON via ArduinoJson.


As you can see I have ~100Kb code and ~12Kb of bss (static data) where all the numerous json buffers I use live.

$ ./arm-none-eabi-size -B app.elf 
   text	data	bss	dec	hex	filename
 109620	0	12556	122176	1dd40 app.elf 


You should use extra 0.25-0.5Kb of memory. But your users get better experience via clear and straitforward protocol like rails. You just say that we transfer JSON that carry object's properties and extra stuff. In this case e.g. you get the native structure support of interface via such a languages like Python, JavaScript, Ruby and etc. out of the box. 

Not to nit-pick, but either your model is incorrect or the specs for your STM32 is off.

The 3.5" T model uses an STM32F030C8T6  and that SRAM is then < 4608 bytes  firmware 3584 user HMI.
Flash size on this STM32 is 64k.


So already you blew your available resources, and still haven't proven being able to have the functionality

Nextion has - so such a proposal would break many projects.  When you talk about Raspberry PI, or the DUE,

you have already blown your budget.

So you are beginning to think closer to the right lines, but miss such details for being serious.

JSON with Buffers of 128 and 256?  Are you joking?  Now you are just toying.

The buffers are blown through in under 25ms.  Users can't manage with 1024

and it should be reduced to 1/4 or 1/8th?

I love a serious debate, but we have to be somewhat serious if we are debating.

t0.txt is max 254 bytes making content: length 254.  This isn't accounting for the remainder of the description overhead and if you add any of that, such as the name of the object, you have blown the buffer in an overflow and the whole buffer content may as well be scrapped.  One command received at a time gives no leeway for the user, and your Nextion interface is bricked.

Further you've reduced any of the two-byte characters to working with less content: than twitter.