Start a new topic

Non-Arduino library for Nextion display?

Are there any non-Arduino/C++ libraries for the Nextion displays? I want to use one with a straight C embedded app. I could hack the Arduino library but if someone else has done it first I'd be happy to tag along...

check the FreeChat threads.

I've gone back 20 pages and can't see anything - any hints on how far back I need to go?

Sorry Peterm

I don't know how far back, or if you were just skimming title. But I do know this has been a topic of discussion with a few of the users already.  To work with what has already been started is easier to hop in on their thread, they may share what they have when they receive the email (when you post in their threads).  It may be longer of a wait in a new thread.

SoftwareSerial as a base has been used and is popular with some.   Lots of ESP programming in done in straight C.

Personally, I am a pascal guy.

Okay, so lets say we were to work on a C library
For which mcu?  what are the limitations in terms of SRAM and flash. 

What communications library, or are you suggesting from scratch as well?

I'll take another look back through - I only looked at threads that had an appropriate subject. There were some talking about SoftwareSerial but I thought they were talking about using the code with different Arduino chips rather than without the Arduino environment.


Re C Library

I'd prefer a conversion of the Arduino library to straight C with the serial routines broken out into a separate module (ReceiveByte, SendCommand). 

It would mean getting rid of the string operations and converting them into byte arrays.

ReceiveByte(uint8_t Data) could be called byte by byte as data is received. The library could then do all the framing and command processing (ie rejecting bad data, processing responses, etc).

SendCommand(uint_t *DataPtr, uint8_t DataLength) could send a command - perhaps an implementation could be provided that called SendByte(uint8_t Data) multiple times however I think it's important to include something that sends the whole byte in one go because some systems are set up to send a buffer using DMA.

There is no need for it to be micro specific - I guess you could provide examples for various micros if you wanted. That's not the hard part - I'm guessing most people would have a UART working already. The only micro specific bit is the sending/receiving.

As for SRAM/Flash limitations - if you just port the Arduino library it won't use much SRAM/Flash. If anything the Arduino is more limited than lots of micros today on those fronts so anything that will work on an Arduino will probably work elsewhere.

See I have Non Arduino MCUs, an Intel Edison, STM32F030F4P6, STM32F103C8T6, a few PICs.

    (forgot to mention a few ESP-8285 modules.)

Now, a C library without the UART doesn't really make the library? It is kind of needed or it is broken, no?

In my mind the library ITEAD provide doesn't need the UART code for a specific micro - it needs hooks where I can put my UART code in. All of those boards will have different UART code and there are far too many different micros around for you to attempt all of them.

Most micros will have some sort of example code which can send/receive characters on the UART - that's the easy bit. I use 4-5 different micros and on each I have the UART code working. If I pick up a new micro there will be examples around for the uart.

The harder part is getting the Nextion display working - processing the replies, sending the commands. That's where ITEAD can add value by creating a C only library.

So the send and receive needs to be part of your mcu uart code file, the rest of Nextion added on from there.

Yes - it's only the send/receive part that is specific to a microprocessor. The rest should be generic to any processor.

The biggest problem for me with the Arduino library is that it's written in C++ rather than C.

And in actuality, the ITEAD provided library doesn't really have the "UART" code for the specific micro.  That is handled by Arduino and the board that you have selected.  Arduino has spanned into STM32s, ESP-8266 modules, and many others that are not Arduino brands.  But it follows the expectations that Serial, Serial1, Serial2 and Serial3 has been defined in the board level files and that that defined serial class has the serial functions defined in the Arduino compatible format

from Serial.begin, Serial.print ... to Serial.end.

It looks like the serial port timeouts would also need to be managed in a different way...

Okay, so if the issue is the class structures of C++, unravelling it into C shouldn't be that hard.

It would require a different usability and user understanding for the unravelled version.  Obviously taking advantage of writing a function once across 16 components now becomes 12 functions (could be better efficiency realized), but the Nextion Instruction Set is far from complicated.

When you look at the 16 components there are about 57 attributes total across the components, some are shared, some are exclusive, but the main concept of terminating incoming and outgoing with the triple 0xFF is easy enough.

And the other bigger issue would be which compiler the library was to work with ...

Many compilers have specifics that need to be watched for.

I've started doing it myself. I'm taking a slightly different approach to the Nextion Arduino library - it seems to have lots of code in each child class which could be pushed up to the parent NexObject class (eg things like Set_background_color_bco). I have one set of common functions which take a pointer to the Nextion objects (instead of being a sub class) and then do whatever is requested.

I'm also doing the serial stuff a bit differently to try and make it non-blocking. Not sure how that will work out - I'll update this once I've worked things out.

Login or Signup to post a comment