Start a new topic

Baud Rate


I'm using the nextion display 7'' with an arduino mega and a stepper motor. I have some troubles about the speed (i can rotate the motor with a button on the screen and i want a text box indicating the position). So i wanted to increase the baudrate speed. I found this topic:

But what *Raphaël* posted that in NexTouch.cpp you can adjust the baudrate, but i don't find there anywhere "baud or bauds or baudrate" or something like that in the NexTouch.cpp file.

Then i wanted to do what *Vlad* posted on the second page, but i get i compiling eror 'nex_msg_end' was not declared in this scope.

What should i do?


  -  the current Nextion Instruction Set

  -  the current code for the Iteadlib Arduino Nextion Library v0.90

Such Arduino code and Nextion firmware has advanced much from 2 years ago

Such old threads from v0.09 of the Nextion Editor are interesting, but still old.

nex_msg_end would indeed create a "not declared in this scope" when you haven't coded such a function

 - as the name implies, their function would have sent out the 0xFF 0xFF 0xFF termination.

The baud rate for the communication between the MCU and the HMI has to be set to equal values on both sides before you start communicating.

If you want for example to communicate at 115200bps, you should first connect the HMI to your PC and use the IDE to send "bauds=115200" manually once for all as the default value of the Nextion display. This eliminates to send baud rate changes from the MCU (i.e. Arduino) and to reinitiate the serial communication with the modified baud rate afterwards.

Once the Nextion programmed with the new default value, you might use the same as a fixed constant in your MCU code, for example NexSerial.begin(115200);

I currently installed this version: 0.9.0 (
Here the arduino MEGA code:
#include "Nextion.h"
#include <AccelStepper.h>

/*-----( Declare Constants and Pin Numbers )-----*/
#define FULLSTEP 4
#define HALFSTEP 8
// motor pins
#define motorPin1  8     // Blue   - 28BYJ48 pin 1
#define motorPin2  9     // Pink   - 28BYJ48 pin 2
#define motorPin3  10     // Yellow - 28BYJ48 pin 3
#define motorPin4  11     // Orange - 28BYJ48 pin 4
// Red    - 28BYJ48 pin 5 (VCC)
#define LED_PIN 13
#define START_BTN 2
#define PRINT_BTN 28
#define INTERVAL 300UL

NexButton btn_start   = NexButton(0, 1, "btn_start");
NexButton btn_plus   = NexButton(0, 2, "btn_plus");
NexText t0 = NexText(0, 4, "t0");
NexNumber n0 = NexNumber(0, 5, "n0");

AccelStepper stepper1(HALFSTEP, motorPin1, motorPin3, motorPin2, motorPin4);
int ledState = LOW;
int plusingedrukt = LOW;
unsigned long previousMillis = 0;
int knipperen = LOW;

NexTouch *nex_listen_list[] =

void btn_plusactiefPushCallback(void *ptr)
  plusingedrukt = HIGH;
  digitalWrite(LED_PIN, HIGH);

void btn_plusreleasePopCallback(void *ptr)
  // dbSerialPrintln("btn_plusRELEASE");
  plusingedrukt = LOW;


void setup(void) {

  plusingedrukt = LOW;
  btn_plus.attachPush(btn_plusactiefPushCallback, &btn_plus);
  btn_plus.attachPop(btn_plusreleasePopCallback, &btn_plus);

  pinMode(LED_PIN, OUTPUT);

  dbSerialPrintln("setup done");

void loop(void) {


  if (digitalRead(PRINT_BTN) == LOW) {

  if (plusingedrukt == HIGH) {
    //	if(

 The serial monitor: First i pressed the plus button and released it, it worked. Second time when i released the motor kept running so I pressed en released the plus button again. So the commando Pop was missed.


@ Thierry Frenkel: Do i need to change in NexHardware.cpp at line 227 or is there no adjustment needed?


Depends on the default baud rate of your Nextion display. If you leave it at the slow default (9600), no changes are needed. In case you modified it manually with the "bauds=" command, you'd have to adapt the code in NextionHardware.cpp.

Basically, I don't understand why you use that library while you have only two pushbuttons, a text and a number field to handle. I think that this could be done in a more efficient and transparent way with coding your own event and dialog handler for the serial port.

Being myself an absolute "control freak", I almost never use third party libraries. I happen to study these and get the knowledge and inspiration needed to write my own, application specific, and optimized code.

I doubt it is a baudrate problem

 - more a buffer overflow issue

MCU does exactly as told.

Depending on your MCU clock and baudrate

    I bet the err came quickly, but intermittent.

But this would be the expected behaviour from the code as written


I am going to pose the argument that for a beginner, the IteadLib is advantageous.

- it supports with Nextion's two datatypes 32 bit and char arrays

- it already creates a data structure for dealing with the Nextion Component

- then it creates two procedure pointers in case needed which the user can then adjust based on when needed and be rid of it just as quick

- the nex_listen_list, also adjustable allows to focus on component HMI events as per program conditions needed

- all while still maintaining basic access to send a raw command via text

For the beginner coder,

- setting such up for its benefits as structured code would perhaps be beyond initial abilities.

- freelance style coding for beginners most often is unstructured, paying no attention to Nextion's status.

I would argue freelanced/unstructured leads to more mistakes when not aware of the pitfalls to protect against.

Basic debugging techniques would have revealed the culprit code in this case

The code reflects little of such debugging being deployed.

But thorough reading of the documentation and tracing through the library code wasn't done

 - hence a question gets posed

Debugging wasn't effectively done

 - hence why the baudrate becomes suspect, culprit becomes overlooked

User duty to know their MCU, language and toolchain - less reading was done here.

But as the code builds, I would support an argument for structure in code

And until experience allows a user to code their own

 - I'd think returning to reading documentation, manuals and app notes to discover why

Thanks for the respons.

The reason why I thought it was a baudrate problem is because my steppermotor slows down a lot when I update a value on the touchscreen. The value holds the current position of the steppermotor. So a higher baudrate means a faster update of the value. 

Now I limited the amount of updates going to the screen with a simple comparisson. 


void loop(){
    case IDLE:

    case RUN_MOTOR:
    case STOP_MOTOR:
      nextState= IDLE;


 Are there any other solution for this? The function setValue() slows down the motor a lot.

It might be (only a guess, since I don't know the details of the Accelstepper library) that this old, weak, and outdated 8bit ATmega 2560 CPU is so much occupied by bit-banging the pulses for the stepper motor, that there are just not enough free resources to handle the serial communication at the same time.
Or (second, more advantageous guess) the serial communication is just too slow and the ATmega has not enough FIFO buffer to send data over serial without being blocked. To try to solve this, I'd set the Nextion baud rate to 38400 (once on the Nextion via the IDE by sending manually "bauds=38400", and once in the Nextion library code) and to see if that reduces at least the problem. 

If not, you might always switch over to a more modern and powerful CPU. The Kinetis K20MK256DX for example has special, so called Flextimers which can do the whole stepper motor handling without "eating" CPU cycles, once the registers are correctly set.

Nothing wrong with 8 bit @ 16 MHz Thierry.

Mega2560 shouldn't need bit-banging, it has 4 hardware serials.

A "more modern" MCU is going to hit the wall even faster. faster.

1) Ignoring the Hardware of the chosen MCU

2) Ignoring the nature of TTL Serial communications and settings

3) Not adjusting settings to optimize

4) Ignoring the nature of sequential processing

5) Failure to examine and trace the code as written.

A more modern MCU will not help any of these

My post was not about bit banging the serial communication, but about bit banging the pulses for the stepper motor, which could definitively be slowed down by serial communication...

Put a loop() counter in your loop()

 - loop by itself should be running at near 200,000+ times per second.

Stuffing unbridled commands in loop is a wrong approach

Stepper motor should have specs

 - how long to get from point A to point B

There is no sense trying to do things any faster than this.

Mega2560 is sequential processing - not multi-core, multi-tasking.

Increasing baudrate for Nextion's serial is fine, Nextion max 115200 no issue but then leaving dbSerial / Serial (over USB to serial monitor) at less than capable is poor coding

  - dbSerial statements are also processed sequential and can be traced in provided Library code (which would be sitting in folder on your local computer when library was properly installed) 


But to realize the loop() should run 150,000 to 220,000 times per second on an Mega2560, the Nextion/Serial monitor writes should be programmed purposefully and less unbridled.  Doing so was the cause of hitting the 0x24 buffer overflow that was being ignored and not caught be the code.  As you weigh this info in, you will see how quickly the wall was reached - but not prevented.

Login or Signup to post a comment