Nextion connections and terms explained

All things relating to the Nextion Screen(s)
Post Reply
KE7FNS
Pi-Star Team
Posts: 2293
Joined: Wed Apr 17, 2019 11:11 pm

Nextion connections and terms explained

Post by KE7FNS »

I commonly see the term Bi-directional used incorrectly in regards to using a Nextion, and it seems to cause confusion to those who don't understand what exactly it means.

First I'll start with explaining what "Bi-directional serial communications" are.
Bi-directional serial communications are those where each device can receive and send data at the same time. They use special flow control signals that allow Bi-directional operation to happen such as DCD (Carrier Detect), DTR (Data Terminal Ready) and CTS (Clear To Send). There is also Bi-directional serial communications that can happen over one wire, but that is way out of scope for this discussion, so lets ignore that definition.

This is NOT the way a Nextion communicates using RS-232 serial communications, for one thing it doesn't have the needed DCD, DTR, or CTS signals.

A Nextion has 4 wires. One wire for receiving serial data (RxData) and one for transmitting serial data (TxData), ground (GND) and power (+5v). Yes, both data signals "could" operate at exactly the same time, but the software isn't programmed for that situation, so it can never actually happen, which is why it isn't bi-directional, it is actually half-duplex. Messages just get stored in a queue ( called a ringbuffer) until the software checks for something in the queue and then if it sees something in the queue it processes it. I think this is where people confuse what Bi-directional actually is, and don't understand that standard RS-232 communications work in both transmit and receive separately. Think of it like a 2 lane road, traffic moves on one side in one direction, and on the other side in the opposite direction. The traffic on one side of the road has no relation to the other side of the road.

The Nextion has two ways of receiving messages and human input. The first is it is just sitting there listening for messages over the serial bus for it to be told what to do and what to display. The second is it is listening/waiting to receive a human touch input from a mechanical interaction with a persons finger or stylus. In normal operation the only time a Nextion is sending any messages back to MMDVMHost is when it has detected a touch input, the rest of the time it is just sitting there receiving messages from MMDVMHost.


The difference between, /dev/ttyAMA0, /dev/ttyUSB0, /dev/ttyNextionDriver and "modem"

/dev/ttyAMA0

Is the built in serial port on Raspberry Pi board. It is on GPIO pins 8 (TxData), and 10 (RxData). It is used by GPIO connected MMDVM/MMDVM_HS hats to communicate with the RPi. The only time it can be assigned to a Nextion is if you plug a Nextion into pin 8 and 10, 2 (or 4), and 6 and you are using a USB connected MMDVM/MMDVM_HS hat (if you set the software to use /dev/ttyAMA0 and you are using a GPIO connected hat the hat will stop communicating and halt, because you cannot have two different devices operating on one serial port).


/dev/ttyUSB0

Is the device assigned to a USB connected device. For Nextions this requires a USB/TTL (Transistor-Transistor Logic) adapter to convert the USB into serial TTL for the Nextion to communicate. It is basically a converter from USB to serial, and serial back to USB.


/dev/ttyNextionDriver

Is a pseudo terminal used to transfer information/messages between MMDVMHost and the Nextion Driver for special messages that get displayed on the Nextion. It is required when using the Nextion Driver and the Nextion Driver Installer should automatically configure it for you when you execute the script to install it.

"modem"

Is a special "keyword" used in the MMDVMHost software to tell the MMDVMHost software that the Nextion is connected to the Nextion port on MMDVM/MMDVM_HS hats. This piggy backs communications by sending messages for the Nextion on the already established MMDVM/MMDVM_HS serial communications over the GPIO. The STM32 microprocessor on the MMDVM/MMDVM_HS hat then forwards the messages to the Nextion through the STM32 and out of the Nextion port on the hat.

Note*, modem it is different than "/dev/modem" so do not use "/dev/modem".

The differences between USB/TTL connected Nextions and "modem" connected Nextions.

THERE IS NO MAJOR DIFFERENCE IN DAILY OPERATION. THEY BOTH FUNCTION EXACTLY THE SAME. Both configurations will display messages and data from MMDVMHost.

USB/TTL adapters are faster by default at 115200 baud, while "modem" connected Nextions operate at 9600 baud by default**. Speed is not critical to operation and messages cannot be missed or lost, because it uses queues. 9600 baud is 9600 symbols per second, and the amount of symbols being passed from MMDVMHost every second is no where near 9600, so speed is never an issue.

Note** = custom MMDVM_HS firmware can use the following baud rates to communicate:

Code: Select all

  1200
  2400
  4800
  9600
 14400
 19200
 28800
 38400
 57600
 76800
115200
230400
460800
921600
I run my Nextions at 921600 with no issues. I have never experienced any serial data corruption even at the maximum speeds possible.

Here are some examples of how to hook up the two different types

USB/TTL adapter: default baud rate must be set to 115200 in the Nextion prior to operation.
USB.jpg
USB.jpg (177.26 KiB) Viewed 681 times
"modem" connection on the MMDVM/MMDVM_HS hat. default baud rate must be set to 9600 in the Nextion prior to operation.
modem.jpg
modem.jpg (167.64 KiB) Viewed 681 times
These diagrams show how in the USB/TTL adapter configuration the messages for a Nextion are sent out of the USB port and displayed on the Nextion. In the "modem" configuration the messages pass through /dev/ttyAMA0 to the STM32 on the MMDVM/MMDVM_HS hat, and then are forwarded out of the STM32 to the Nextion. The serial communications happening over /dev/ttyAMA0 between MMDVMHost and the STM32 are at 115200 baud and have no increased latency with the added messages destined for the Nextion. Also message/data loss is pretty much impossible.

I hope this explains that there really is no operational difference between the two connection types so others will quit regurgitating incorrect information to others.
If someones previous actions are any indication of their future actions, then I predict the deletion and removal of access will happen at any moment. 7-11-2020.

"07/13/20 This Website Has Been Taken Down" ... again :lol: and again
KE7FNS
Pi-Star Team
Posts: 2293
Joined: Wed Apr 17, 2019 11:11 pm

Re: Nextion connections and terms explained

Post by KE7FNS »

It appears that my explanation above was not enough convincing for someone to adjust their improper teaching.

The reason the serial messages are NOT bi-directional (aka full-duplex aka "happening at the same time") is simply because the software is not written in a way that parallel operation (both sending and receiving) is possible.

The NextionDriver software from ON7LDS is responsible for checking for serial data on the serial port and passing it back to MMDVMHost. MMDVMHost does not process ANY serial data coming from a Nextion. In other words for a touch screen command to perform an operation the NextionDriver must be installed and configured correctly. (If the NextionDriver is not installed and configured correctly Nextion touch commands do nothing.)

Two serial messages simply cannot be handled and processed in parallel at the same time EVER, because the NextionDriver software is written to check one signal (RX from the Host) before it checks for another signal (TX from the serial port).

Here is a detailed log of all of the messages being sent back and forth to and from a USB/TTL adapter connected Nextion. (notice I specifically used a USB/TTL adapter in this case to refute those who claim it is "bi-directional")

I adjusted the time to give 6 digits of millisecond accuracy to show that things can never happen at the same time.

Code: Select all

2021-08-28T21:44:36.928577-07:00 pi-star NextionDriver: Start of loop
2021-08-28T21:44:36.929473-07:00 pi-star NextionDriver: calling checkSerial() from inside talkToNextion()
2021-08-28T21:44:36.930335-07:00 pi-star NextionDriver: Start of checkSerial() function
2021-08-28T21:44:37.028954-07:00 pi-star NextionDriver: End of loop
2021-08-28T21:44:37.029864-07:00 pi-star NextionDriver: Start of loop
2021-08-28T21:44:37.030750-07:00 pi-star NextionDriver: calling checkSerial() from inside talkToNextion()
2021-08-28T21:44:37.031661-07:00 pi-star NextionDriver: Start of checkSerial() function
2021-08-28T21:44:37.130445-07:00 pi-star NextionDriver: End of loop
2021-08-28T21:44:37.131396-07:00 pi-star NextionDriver: Start of loop
2021-08-28T21:44:37.132359-07:00 pi-star NextionDriver: Received 29 bytes from host
2021-08-28T21:44:37.133196-07:00 pi-star NextionDriver: Process t2.txt="28/08/21 21:44:37"
2021-08-28T21:44:37.134011-07:00 pi-star NextionDriver: RX:   t2.txt="28/08/21 21:44:37"
2021-08-28T21:44:37.134846-07:00 pi-star NextionDriver:  TX:  t2.txt="28/08/21 21:44:37"
2021-08-28T21:44:37.159092-07:00 pi-star NextionDriver:   LH: check [t2.txt="28/08/21 21:44:37"] on page 0
2021-08-28T21:44:37.159987-07:00 pi-star NextionDriver:   LH: page 0 field 2 is [txt="28/08/21 21:44:37"]
2021-08-28T21:44:37.160836-07:00 pi-star NextionDriver:   LH: statusval 0
2021-08-28T21:44:37.161743-07:00 pi-star NextionDriver: calling checkSerial() from inside talkToNextion()
2021-08-28T21:44:37.162588-07:00 pi-star NextionDriver: Start of checkSerial() function
2021-08-28T21:44:37.260682-07:00 pi-star NextionDriver: calling checkSerial() from inside talkToNextion()
2021-08-28T21:44:37.261644-07:00 pi-star NextionDriver: Start of checkSerial() function
2021-08-28T21:44:37.362143-07:00 pi-star NextionDriver: End of loop
2021-08-28T21:44:37.363011-07:00 pi-star NextionDriver: Start of loop
2021-08-28T21:44:37.363850-07:00 pi-star NextionDriver: calling checkSerial() from inside talkToNextion()
2021-08-28T21:44:37.364672-07:00 pi-star NextionDriver: Start of checkSerial() function
2021-08-28T21:44:37.463608-07:00 pi-star NextionDriver: End of loop
2021-08-28T21:44:37.464471-07:00 pi-star NextionDriver: Start of loop
2021-08-28T21:44:37.465283-07:00 pi-star NextionDriver: Received 29 bytes from host
2021-08-28T21:44:37.466081-07:00 pi-star NextionDriver: Process t2.txt="28/08/21 21:44:37"
2021-08-28T21:44:37.466894-07:00 pi-star NextionDriver: RX:   t2.txt="28/08/21 21:44:37"
2021-08-28T21:44:37.467530-07:00 pi-star NextionDriver:  TX:  t2.txt="28/08/21 21:44:37"
2021-08-28T21:44:37.492407-07:00 pi-star NextionDriver:   LH: check [t2.txt="28/08/21 21:44:37"] on page 0
2021-08-28T21:44:37.493103-07:00 pi-star NextionDriver:   LH: page 0 field 2 is [txt="28/08/21 21:44:37"]
2021-08-28T21:44:37.493702-07:00 pi-star NextionDriver:   LH: statusval 0
2021-08-28T21:44:37.494279-07:00 pi-star NextionDriver: calling checkSerial() from inside talkToNextion()
2021-08-28T21:44:37.494858-07:00 pi-star NextionDriver: Start of checkSerial() function
2021-08-28T21:44:37.594068-07:00 pi-star NextionDriver: calling checkSerial() from inside talkToNextion()
2021-08-28T21:44:37.596515-07:00 pi-star NextionDriver: Start of checkSerial() function
2021-08-28T21:44:37.695328-07:00 pi-star NextionDriver: End of loop
2021-08-28T21:44:37.696255-07:00 pi-star NextionDriver: Start of loop
2021-08-28T21:44:37.697127-07:00 pi-star NextionDriver: calling checkSerial() from inside talkToNextion()
2021-08-28T21:44:37.698001-07:00 pi-star NextionDriver: Start of checkSerial() function
2021-08-28T21:44:37.712438-07:00 pi-star NextionDriver: Receive 11 bytes from serial
2021-08-28T21:44:37.713372-07:00 pi-star NextionDriver: Endmarker found
2021-08-28T21:44:37.714269-07:00 pi-star NextionDriver: RX: 8 (2A F1 72 65 62 6F 6F 74 )
2021-08-28T21:44:37.715141-07:00 pi-star NextionDriver: Received command 0xF1
2021-08-28T21:44:37.715993-07:00 pi-star NextionDriver:  Execute command "reboot"
2021-08-28T21:44:37.716816-07:00 pi-star NextionDriver:  TX:  msg.txt="Execute reboot"
2021-08-28T21:44:37.738991-07:00 pi-star NextionDriver:   LH: check [msg.txt="Execute reboot"] on page 0
2021-08-28T21:44:37.739958-07:00 pi-star NextionDriver:   LH: page 0 field 0 is [txt="Execute reboot"]
2021-08-28T21:44:37.740908-07:00 pi-star NextionDriver:   LH: statusval 0
What this detailed log shows is that the loop begins and nothing is needing to be processed, so we loop again.
The second time again nothing is needing to be processed.
at "2021-08-28T21:44:37.132359-07:00 pi-star NextionDriver: Received 29 bytes from host" a message from the host was detected and starting to be processed.
Notice that at 2021-08-28T21:44:37.466081-07:00, the same message (t2.txt="28/08/21 21:44:37") was detected and processed again, the reason is because MMDVMHost sends time updates every half second so that it doesn't overload the serial bus.
then we continue on, and when I happen to tap the reboot button on PD0DIB's model 10 screen, it detects that a message is waiting on the serial port. "2021-08-28T21:44:37.712438-07:00 pi-star NextionDriver: Receive 11 bytes from serial." its 11 bytes because it is 8 bytes + 3. 2A F1 72 65 62 6F 6F 74 FF FF FF

Due to how software performs commands one line after another parallel operation in this style of programming is not possible. A message from a Nextion will sit in the queue until it is detected and handled on the next time through the checkSerial() function.
If someones previous actions are any indication of their future actions, then I predict the deletion and removal of access will happen at any moment. 7-11-2020.

"07/13/20 This Website Has Been Taken Down" ... again :lol: and again
Post Reply