Start a new topic

Wemos D1 uart with Nextion

Hi,

I am trying to make an room termostat for my daughter's room. 

I will send DHT22 temp and hum. values to Nextion. And I will get an number value from nextion to start a relay. 

My code is using Software Serial at HMISerial (4, 5) pins. But comminication is awful.

So Patrick advised me to use Uart comminication instead of SoftwareSerial. But I am not a programmer, I am just a naval architecture, Programming is just my hobby. So I do not know how to make an uart connection between wemos d1 mini and nextion 2.4". I am using arduino ide 1.8.2.


ino

Check my WIoT-2 write-up. I use a NodeMCU Mini which is pretty much the same MCU. Its connected using harware serial. http://www.plastibots.com/index.php/2017/01/03/wiot-2-weather-station-nextion-tft-with-esp8266/

1 person likes this

Dave has a good project, proof success can also be yours too.

Onder, try reading Nextion TTL Serial thread
 - here I try to explain how the Serial works.

Now the big difference is Software Serial is "Very Manual"
  and in not being a programmer, you are indeed trusting

  that whomever wrote your software serial library has done

  so with your applied use in mind.
  - indeed, many things to break with software serial.

  When the byte is coming across the wire,

     the timing needs to be evenly spaced at defined interval

     the exact interval used for 10 bits in a row = baudrate.

  Anything on your programming that interrupts this timing

     is huge potential for losing that byte, or worse

     ... you think you have your byte, but data is inaccurate.

  As such, so many precautions have to be made

     like reading the value 16 or 32 times per bit (oversampling)

     and average the results to get a consensus if 0 or 1

   All this oversampling means slower final baud rates

  Too many things to really mention all considerations needed.


   If the only task your MCU had was just to receive on the line

   you would be okay for software serial, but the other side of

   receive is sending.  Sending is kind of easier as you do not

   need oversampling on your side, just impeccable timing and

   let the other side deal with oversampling.

     ... so we see quickly that when something happens and an

     event occurs, you most likely want to do something at that

     time the event arrived - maybe calculations, or store the

     result to SD card, or as a Wifi ESP MCU - send to the Net


  Is your MCU only focused on receiving?  No.

   - receive on RX

   - send over TX

   - calculations

   - store data

   - send to the Net

  So quickly, these other tasks can interfere with Software Serial.


Now imagine, specially that you are not Programmer First Class

That you had a subordinate who you can task to do both RX/TX

This subordinate is not a rookie but best at doing RX/TX tasks

  - one you can rely on and he does his job impeccably

All you need to do is say Joe, send this out - handing him details

    Serial.print("n0.val=23ÿÿÿ");


or ask Joe, how many bytes arrived since I last checked with you?

... Joe has been piling them up in exact order as he got them.

     Serial.available();

and to get each byte from the oldest (first to arrive) to newest

     Serial.read();

and Joe passes you the next byte.  Reliably and just impeccable,

He handles everything about the line timing and the 0s and 1s.

You only need to give Joe enough space to work, (buffers)

and check in with him before he runs out of space (overflow)


So this you see is the difference between Hardware Serial (UART)
and Software Serial, where some other programmer like yourself

tries to simulate Joe in software, just that you don't really know how

good that simulation was, ... or if a mistake was made, how to fix it.

An ESP-8266 has two Joe's (Hardware UARTs) on board.
The first Joe, has both hands free one for RX the other TX
The second Joe only has a TX hand free

   (They tied his other hand to the SPI Flash)


So while some will fight with trying to get Software Serial to work

 - there are two (or 1 1/2) very good Joes sitting in the mess hall.

You only need to ask them to come and work your project.

Patrick,

Thanks for your explanation. I did not think this will hard like this much. But I could not see the circumstances like programmers. But now I learned Serial connection is one of the master thing when making this kind of things. In my case I also understood Software Serial is not reliable. Too much data should transfered quickly. It could not even catch sometimes if I pushed button or not. I am learning a lot from you guys. I mailed to Dave about his code.


Surprised me that, there is no clear examples about Serial connections on the internet. I tried some of them but did not work. 


Member indev2 also explained Serial1, (second Joe as your explanation), I also tried but not get it work yet. 


I will continue trying, you, Dave and indev2 posts will show me the light I believe. I will share the results. 

The size of your ino file above is too much for trying.

You need a bit more understandings before combining all.

- try smaller programs in alternative sketches to test

  then incorporate the alternative sketches together

  Have a means of going back to what worked.


"It could not even catch sometimes if I pushed button or not"

I see in parts of your code you have a delay(1000);


delay is a "Halt in place and do absolutely nothing" command

 - think of it as an MCU wide all workers strike, until times up.

Absolutely nothing is operating except for the guy keeping time.

For 1000 ms is a full 1 second that itself is on a schedule.


Your missing press is most likely occurring during this strike,

 - even a Serial interrupt can not work (Joe receiving) during delay


consider the following code

 

 

uint32_t resume_at;

// create a wait on spot for 995ms
resume_at=millis()+995;
while(millis() < resume_at) {
}
// continues to next line after 995ms

 

 

and delay

 

// halt everything till 995ms has passed
delay(995);
// continues to next line after 995ms 

 

Both wait on their respective line until 995ms expires
The difference is the first will still allow interrupts to work

allowing a byte over serial to still be received by Joe and
put in the buffer until your ready.

Buffers are generally not huge, say 256 bytes, maybe 1024
at 115200 baud, 11520 bytes could arrive within 1000ms.

So you see if Joe runs out of space, the next bytes gets tossed

out and your data in the buffer no longer makes sense.


At 9600 baud, 960 bytes could arrive in 1000ms

cutting it close to an overflow if buffer was 1024 and 960 arrive.


But during a delay() an incoming byte is ignored

  - the MCU wide strike has no one manning the serial interrupt

  - picture your needed bytes as a tomatoes hitting a brick wall

  - the brick wall that you placed there in your code with delay()

    essentially saying, the shop is closed.


So when this type of thing MUST occur

  - send status to Nextion indicating busy and disable button
  - when the condition has passed

  - clear that status to Nextion and re-enable the button.


But in all honesty, delay() never needs to occur

  - it only requires a few more keystrokes as you see above.


Delay is a quick and dirty pause and people forget to go back

and adjust their code to more purposeful commands.

Login or Signup to post a comment