Start a new topic

Arduino Due+Ethernet2+Nextion Library: Ethernet send fails

Hello, I wanted to add a HMI to my project and went for the 7" nextion screen.   Using the current library I have been able to get it running using serial1 at 9600.

However, now I have problems with the ethernet2.   It will receive data from my client; but when it sends back; nothing arrives at my client.   If I comment all the code that communicates with the nextion screen; then it works again.  If I have one simply statement such as number1.setValue(0,1,100) then the ethernet2 stops sending again?

Any pointers and/or help please!


about which library for the Due are you talking .... current is a bit too vague ...

I downloaded it with the IDE library manager.  V2.2.0

sorry, but the version of the library manager won't tell any about the library itself ...


this is the library

which is the official library I should use?

on the website it is clearly stated

"The code is heavily based on the official library but aims to be cleaner, more user friendly and with a bit of luck, faster."

so, when you use this, I guess it is also a good idea to contact the author for some more help ... if somebody knows this library, then him ...

There is no direct "official" library existing for the Due, sorry ...

Suppported Mainboards of ITEADLIB_Arduino_Nextion

All boards, which has one or more hardware serial, can be supported.

For example:

Iteaduino MEGA2560Iteaduino UNOArduino MEGA2560Arduino UNO

Changes must be done as documented ...

so is there any plans to make the library compatible with the due; would be a shame to bin the screens I have just received and have to begin again looking at a different screen?

sorry, there are too many different MCU's out.

    - STM
    - Stellaris
    - TI
    - PIC
    - Rpi
    - Edison
    - LPC
    - Infineon

just to mention a few besides Arduino ... and all are more or less famouse ...  and proprietary similar .... :-)
And not to forget, in which programming language should this library be available? For all this you can find compilers for all flavours ... C/C++ is not the only world for embedded devices ...

It is far beyond scope, to develope libraries for them all ... and to make a choice is also a bad solution, because there will be exactly the ones out who cry, why we didn't cover ...

So we just publish the commands, and everybody can just use them as he need, for whichever MCU he use, for the language of his choice ...

The Nextion is accepts much of its commands via text over serial
These commands can be found in the Nextion Instruction Set located here

As well as the list of Nextion commands, the Nextion Instruction Set also has
A list of the valid Nextion Return Codes and the format of the expected data being returned.

Other samples and Tutorials can be located in the Itead Blog located here


Hey Robert.

The Nextion is a serial device.  This means you need to have an ability to write to a byte via serial.  To write via serial, one must send HIGHs and LOWs over the wire at timed and spaced intervals.  The interval is known loosely as the baudrate or preferably as bits per second.  A HIGH or a LOW for one interval is a bit.  The Serial protocol provides for several other data-handling functions like error-checking, flow control, etc, but with Nextion the parameters are simple None 8 1.  Which is to say None Parity, 8 Data Bits and 1 Stop Bit. (No flow-control, no compression, no error-checking, no-encoding, just the simplest straight forward 10 Bits of N81).

Now to send out a single byte, the first interval (bit) is a LOW holding the time length of the Interval - this represents our None.  Then for each of the 8 Bits of our Byte, the Least Significant Bit is sent: If the bit is a 1 then a HIGH is held for the length of the Interval, or if the bit is a 0 then a LOW is held for the length of the Interval - then the register is shifted right to position for the next bit.  This continues for each of the 8 bits of our byte we are sending.  Finally to finish up with this byte the Stop Bit is sent holding LOW for the length of the Interval.  10 Intervals used, this is how N81 is processed to send a single byte.

What is the interval?  9600 baud or bps is 9600 such intervals every second.  On a 84MHz MCU, one 9600 baud interval is 8750 clock cycles (with many other things dependant).  At 115200 baud or bps, 115200 intervals every second.  On a 84MHz MCU, one 115200 baud interval is around 729 clock cycles, and not even divided, so slight error rate in the timing.  Techniques such as 8x or 16x oversampling helps to correct this timing error with an average determined over the Interval.

Hardware Serial is more "user friendly" as it works directly with your board's UART module. Think of your UART module in the MCU as a Helper or Apprentice assigned to the task of shipping and receiving the bytes over RX/TX.  As such your MCU can be busy doing other things and simply be informed when a byte has arrived in the port, handle this byte and be back to other things the MCU is handling - such as your Ethernet.

Then there are the bit-banging techniques. SoftwareSerial bit-bangs the serial protocol.  SoftwareSPI bit-bangs the SPI protocol, Software I2C bit-bangs the I2C protocol and so on.  In a bit-banging scenario the MCU doesn't have his extra Helper and must manage all these things by himself.

Now, Arduino provides for a Hardware Serial which matches your board's UART modules.  This too is dependant on if the Manufacturer of your board has sent the proper definitions to Arduino.  Some boards are close enough to others, but hey many many things to be considered when "why something just don't work".  This is an important issue if Arduino actually has a proper board definition for your board or if it is handled by Arduino as a loosely "close enough" scenario.  There is NO MCU Manufacturer that has manufactured their chip expressly to the specifications and requirements of the Arduino group.  And the Arduino group has indeed made their efforts to find some semblance of compatibility so their environment can spread further - so for Arduino a "loosely close enough" is good enough for them.

BTW have you even seen the size of your MCU documentation?  Assuming you are using a brand-name Arduino DUE and not a DUE compatible (this goes back to the loosely close enough scenario I mentioned)  The MCU datasheet for the Atmel SAM3X8E ARM Cortex-M3 CPU is whopping 1479 pages!

This is in no way my responsibility to become familiar with your MCU, and my reading the 1479 pages of your MCU documentation in no means increases your understandings of the MCU you have chosen and in no means will assist you to use your MCU.  This is your responsibility to do and to your benefit to ensure that you do.

Now, each specific MCU has its instruction set that is specific to the MCU.  Each specific MCU has its means of handling the peripherals that it has on board.  The ARM core class for the Cortex-M3 means that the core is the same as this is ARMs licenced designed that each of the licenced manufactures follow.  But how each of the manufactures handle their peripherals are up to them.  For example.  There are four USART pins assigned to a Cortex-M3 USART Module.  One for each of RX, TX, CTS, and RTS.  Now what happens when We only need RX and TX?  On an ST manufactured Cortex-M3 I can assigned the other two pins for CTS and RTS to other functions as digital pins.  On a GD manufactured Cortex-M3 the unused pins still belong to the USART module and are not re-assignable.  What is the case on yours?  Well that is your duty to find out and not mine.  But it very well can be that when you have assigned pins for this and pins for that and now you want to assign a USART, there very well could be limitations set by your manufacturer Cortex-M3 that prevents you from using that USART module.  

Now most Cortex-M3s have several such USART modules, and Arduino usually takes one for use programming and serial debug.  Perhaps if I dug into your MCU documentation I could find the answer, and it may be that the pins assigned to your Ethernet have limited your options to which USART modules you can use.  But such is not my task to understand all users MCUs but the responsibility of the user who chose to use such an MCU.

So where were we, we are at the instruction set.  This be the level where Machine code is.  The language of the specific MCU. But how does Machine code come to be?  This is done via an assembler and a linker.  These are parts of a compiler.  So what compiler have you chosen for your MCU.  My understanding is you have chosen the Arduino C++ compiler.   This was your choice and not mine.  Gerry well I know he favours BASIC programming languages - so if he were to even consider writing a library for your MCU it would probably be in a BASIC programming language and far removed from Arduino C++.  But me, well .... no I am a Pascal guy, I would probably write it in Pascal.

Funny thing about the programming languages, there are so many variants and flavours of a programming language.  Take Pascal for an example, there is the Turbo style, the Delphi style, the Free Pascal style, and my preference of Kylix - all of these have variants that cause need for code changes.  What works for turbo does not necessarily work for Free Pascal or Kylix.  And what works for Kylix doesn't necessarily work for another flavour.  Even mikroPascal needs something different from the others.  But users are certainly free to choose what ever programming language they like (hundreds to choose from).  We have Python programmers using Nextion on Pi.  We have BASIC programmers on PICs.  Users choice.  But the user must not only learn their programming language, but the implementation of it specific to their chosen compiler as it is this that will be turned into the assembly language that generates the Machine code that allows your MCU to run.

So what is a library?  A library is a segment of code that can be reused by other programs.  Such examples of Libraries is the Arduino SoftwareSerial library.  Some user some where wrote some code to do a function of specific purpose and shared it.  Other users found it took less effort to use that users code rather than write it themselves - and behold a library was born.  Arduino uses popular code.  Example: Which users code they used for delivering their SoftwareSerial functions has changed several times.  From observation LibA was more popular and used by more people at the time and not because it was the best.  Users struggled with the chosen Arduino SoftwareSerial library, and soon it was discovered SoftwareSerial written by another but less popular was more reliable for a given purpose.  So soon Arduino switched which library for SoftwareSerial was included as the default.  Most times the SoftwareSerial Library includes links to other contenders that may be better for other purposes.  But it still boils down to some user somewhere made an attempt to write it and others too lazy to dig in and write there own began using it.  Even you could publish your code as a library on GitHub, and within a month you will have a following of other users too lazy to write their own now using your code.

So the library you chose was the NeoNextion Library.  Have they even kept pace with all the changes Nextion has made.  There is another popular "code segment" others use as a library simply because the two guys demoing a basic HMI design they made stuffed their functions in a file called Nextion.h.  This was not their intention for it to be used as a library - but hey, its very popular.  These two guys do not answer emails related to their code have not updated it in over a year.  But some call this a library.  Library simply means code meant to be reused for this purpose - saves hundreds of keystrokes to type it in again.  Most times these are "personal libraries" and not meant to be an official library - but hey, it is the age of the Internet and there are plenty of lazy users, so once code is shared - someone somewhere will call it a library and be using it.

The IteadLib Arduino Nextion Library is on the Github that Gerry pointed out to you.  The good thing about that library is that it contains the source code. So you have the ability to view it, study it, see how things are processed for the Nextion, and modify it to suit your purpose. After all the source code is the recipe of how to make it work, and all this is freely available - you only need to choose to download, install and use it.  But again, users are free to chose, and doing so is the users responsibility.

As far as is the IteadLib compatible with the DUE, one has to read their MCU documentation, ensure their board definitions were updated with Arduino and iron out any little details that make sense for the project.  The difficulty in saying such and such is compatible for DUE, is DUE is a 3.3V system and many all of a sudden forget things like level shifters and what ever else your project requires in differences as it is a DUE.  And then there is that thing about how all these manufacturers have put their own little spin on how they deal with the USART modules - this alone makes several variations - so it really really relies on your Cortex-M3 implementation.  It is easier to not make the claim for compatibility - but hey, you have the source code available to you, and can easily implement it for your specifics.

But you chose to use a DUE for your MCU, you chose the manufacturer of the Cortex-M3 when purchasing your DUE, you chose your Language as C++ when you chose Arduino, you chose the compiler when you let Arduino IDE do that compiling for you, you chose the library when you chose NeoNextion.  It is your responsibility to now read about your choices and ask the appropriate questions to the appropriate people.  As a parallel, I chose the Intel Edison for my MCU, I chose Pascal as my language, I chose Kylix for my compiler and I chose to write my own library.  Every user makes their own choices.  You made yours.

BTW, throwing your Nextion in the bin because someone else made a coding error in your Ethernet library makes about as much sense as throwing your cellphone in the loo because someone put too much ketchup on your chips.  Read your documentation.

SO I found out your problem - and I will not need to remind you it is not my job to debug your code.

This you must DUE for YOURSELF ...

So why does your Ethernet suddenly stop when you issue number1.setValue(0,1,100) ?

Well what do you suppose was suppose to happen when you make a coding error

 - where such error now needs to raise an exception

 - where you have made no coding mechanism for such exceptions

 - where you have made no coding provisions for handling such exceptions

You MCU runs into an invalid situation and code halts to protect the MCU.

Now on most MCUs there is simply not enough resources available to build up such coding mechanisms and as such the code you provide your MCU needs to be exacting.  You could use your Serial Monitor and Serial.print statements to build debugging so you can see what is happening on your MCU side.  But this you did not do, too lazy to make simple Serial.prints to investigate your own code.  Too lazy to read the provided documentation NeoNextion created.  To lazy to pull up a simple ino text files of the many examples NeoNextion provided - like NeoNextion's Number.ino found here:

Instead you come here and jump quickly blame the Nextion for your coding mistakes when you open a BUG Report - must be Nextions fault, since I was trying to send something to the Nextion.  I resent that users use the Bug Report channel to jump queue for priority handling of their coding issues.  Coding issues are to be handled in Free Chat.  Bug Reports are for Nextion Editor Bugs and Firmware Bugs - not for help with user coding errors.  But how quick you are to blame Nextion when it isn't even our code.  The library is NeoNextion the code is yours.

Of course such a line of code would cause the MCU to choke. 

Properly formatted NeoNextion style is merely  Number1.setValue(100);

It has no clue what to do with all the extra parameters you tried passing to it.

Hi Patrick,

Thank you for critique!

I have already tried the above which did not work; I hope this shows some effort on my part; ultimately I am reaching out for help, to see if someone else in the community has experience of this and therefore a solution?

Unfortunately my knowledge and time doesn't allow me to easily debug the inner workings!

The nextion screen is "perfect" for my project; for reasons I wont bore you with; I have had to move from the mega to the due .. and thus I find myself with this problem to resolve or to change hardware and move on .. the first option is my preferred choice!



My suggestion if you want community help - Post in Free Chat  

Bug Reports are for reporting bugs in the Nextion Editor of the firmware.

A Bug Report usually means that we have to find the BUG you are reporting (prove or debunk), our day workflow becomes interrupted to chase down the BUG to make report on what is causing such a BUG.  So when this is a general user question that should have been posted in Free Chat, the other users see this as queue jumping.  It isn't a fair means to the rest of the community to jump queue.   Also the Community doesn't generally think of going through the Bug Reports to locate user questions.  So I hope you understand. As this queue jumping continues, it's going to lead to a result of the Bug Reports being ignored.

I'll also state my post was not meant to be a critique.  You state now that your knowledge of and time doesn't allow you to easily debug the inner workings. But I provided a fairly accurate overview of how serial works, how the software works, how Arduino works, and links to your documentation for your quick reference.  When you don't have the knowledge - that is where you find the knowledge you are missing.  I have now spent about 4 hours skimming Due related materials and even now have setup a Due (Atmel ATSAM3X8E AU) on my desk. So you will have more time and experience with your Due than I have.  Understand this is not my task - but yours.

But as you have posted, and I can not move the thread to Free Chat, continue to use this thread.

You state your knowledge and time doesn't allow you to easily debug the inner works  So let's demark your side, and my side.  Mine is the Nextion - screen side of the RX/TX pair.  Ask about things on the screen side of those RX/TX wires - happy to help, more than happy to help.  I need you to give the Nextion a clean 5V on the Nexion 5V line, I need you to tie Nextion GND common to your DUE GND, Nextion TX to your DUEs RX2 and Nextion RX to your DUEs TX2 line.  Now the Nextion is my side.  The DUE will be your side.  Everything that is not on my Nextion side of that RX/TX pair is your side.  So I will help you Nextion, you will need to dig into that 1479 pages for your side if need be and do what ever it takes for your side.

When you say you have already tried the above I need to know without me assuming, of which you speak?

Also which DUE do you have? - I now have IteadLib working on the Iteaduino DUE
Also which Nextion do you have?

Login or Signup to post a comment