Anyone here using a nextion display with arduino Due?
I am able to make the touch screen work on Arduino Uno and Mega but not on Due and I really need to make it work on Due.
Hi Filipe, you can use a bidirectional TTL level shifter (3.3V to 5V). You can find different options with different number of inputs, but in your instance you need at least 2 channels (RX and TX pins).
I bought one and my Nextion is working perfect. Now I'm waiting for another level shifter and I'll try to drive my 5V relay shield and a PH sensor which is not working with DUE.
My DUE is working without any changes. I didn't need a level shifter.
I just have to delete the line 17 at the File "NexUpload.cpp" of the Library: https://github.com/itead/ITEADLIB_Arduino_Nextion to disable SWSerial.
First, I didn't write that library ... But I would think the NexUpload should be an independent application of the library and not that NexButton is to be effected by NexUpload's presence? No?
So its conflict is a result of?
you could be right. I don't debuged the hole code.
But, i couldn't compile the Code with Arduino 1.6.13 IDE because of a not working SoftwareSerial.h for Arduino DUE. I also don't need the SoftwareSerial.h for the Due because of three UARTs on the Board.
So I have do disable the SoftwareSerial to compile and get everthing workable with DUE and Arduino 1.6.13 IDE.
I am trying to use nexupload with arduino due, it gives erros as it requires compatible sd library, did any have any success compiling it without errors,
Yes Chris figured that too but even with adafruit sd library that support Arduino due the nextion code is not compatible, https://github.com/adafruit/SD , i hope nextion will find a working solution for this problem very soon.
I might take a different approach.
Rather than trying to mess with the code problems of Arduino and NexUpload, it may be easier and more straight forward to program the logic of the upload protocol independent of a library as your own internal procedure.
will you kindly execute your thoughts beautiful words in actions to show us your codes in solving such mess so we can thank you 24/7 and beyond.
That's ok, I get 100+ individual thanks and a thank you thread per month.
My language of choice is pascal, so I will not be posting my bad C code here.
But my thoughts are this :
Configure your serial, proper baud and 8N1
- and try to use HardwareSerial port where ever possible.
- Nextion baudrate you already should have ("get bauds")
You will also need a 4096 byte buffer for the upload
- any less and you risk timeouts
1) Send an empty command string - primes the line.
2) you need to send "connect", proper baud and 8N1
After you connect, your Nextion sends back its data string
- you see this in the Nextion Debug simulator on connection.
- if it begins with comok, you should be good to go
- if it doesn't, then you will need to attempt a reconnect
- there NEEDS to be a delay between attempts,
- this delay is a math formulae based on baudrate, not 500ms
(formulae is 1000000/baudrate + 30ms) so this table
at 2400 baud then delay 447ms before retry
at 4800 baud then delay 239ms before retry
at 9600 baud then delay 135ms before retry
at 19200 baud then delay 82ms before retry
at 38400 baud then delay 56ms before retry
at 57600 baud then delay 48ms before retry
at 115200 baud then delay 39ms before retry
When you get your comok, then you'll need to issue
3) wrhmi-wri 453236,115200,X (as in whmi-wri filesize,baud,res0)
4) Delay upto 500ms and you will receive a 0x05 byte
- this says Nextion is ready to receive
- the upto 500ms delay here is needed to clear Nextion firmware and load the TFT loader.
So now comes your upload
you need to fetch 4096 bytes of your TFT into your buffer for it to be ready to dump out to TX
- you do not want any of your flash access delays creating a timeout, so have it ready
5) Send your first 4096 bytes out
6) receive one byte back from Nextion saying it was a success, but wait for it
- if it failed, your upload is bust, may as well prep to start from scratch
- if the 0x05 byte is received, first 4K is up and golden
Repeat steps 5 and 6 for each full 4K portion of the TFT.
- me, since there is only one byte coming back it can sit in the RX buffer while I make
use of that time to fetch another 4K chunk into my 4096 byte buffer. Then check RX for 0x05.
On the final chunk, you will only have a partial
7) send last partial chunk
8) again wait for last 0x05 byte to arrive
If all 0x05 bytes have been received, you have a golden upload.
9) Reboot and new TFT should be running
10) Monitor for 0x00 0x00 0x00 0xFF 0xFF 0xFF - Nextion start
11) Monitor for 0x88 0xFF 0xFF 0xFF - Nextion loaded and ready
If not, and you are confident there is no error in your TFT, then
perhaps prepare to upload again at a reduced baudrate
So those steps to me certainly don't seem to difficult to put into a loop
- But attention to the time needed and don't make the Nextion wait
for your partial chunks because you are fetching from some other
source when it wants 4096 bytes in this chunk. Don't give her the
opportunity to think your chunk was incomplete and fail you for it.
Something tells me Arduino just gets in the way of good coding,
some straight forward MCU code without Arduino may be best.
The upload protocol is publically posted on the Itead Blog May 2016
You can find this in the Tools, Tips, Tricks and How-To Gallery thread.
Arduino NexUpload.cpp and NexUpload code is located
yes Chris685 will be kind of you to share with us as I really want to do the upload through arduino due as an embedded solution not through pc based. I am also using the latest arduino 1.8 but nothing working yet.
I went to Nextion and expected to see working code without bugs. regards
For what Chris685 refers to as the library is
Arduino NexUpload.cpp and NexUpload code is located
But I will make something super clear.
The Nextion is supported by 1000 MCUs - PICS, STMs, Intels, ESPs ...
The Nextion is programmed in Hundreds of languages, C, Basic, Pixaxe, Pascal, Python ...
Now for all but Arduino C, these other MCUs and abstract languages
- the users read their manuals and independently program their MCUs
So why is this become so different for only the Arduino C crowd.
There is one thing for users to want to share their code and show off. But I will put
a quick end to users coming here and arrogantly demanding that others program
someone else's MCU for free because they don't want to do their own work.
I worked 1/2 the day on fiddling around for an Arduino C based upload for the Due.
I am only 70% completed.
I was feeling pretty good about showing "how it is done" as I spoke about,
But coming here and demanding of other users - forget it !!
Read the specs, write your own code.
No one will be forced, pressured or coerced into doing someone else's work.