Responding to Nextion touch commands

[SS396]

Hello Andy

Would it be possible to process Nextion touch commands when the screen is plugged into the modem (UART2)? Such as forwarding the following serial data from the screen back to MMDVMHost/NextionDriver?

2A F0 72 65 62 6F 6F 74 FF FF FF

It looks as if the code just reads the data from the screen and dumps it instead of forwarding it.

line 861 in SerialPort.cpp

#if defined(SERIAL_REPEATER) || defined(SERIAL_REPEATER_USART1)
  // Drain any incoming serial data
  while (availableInt(3U))
    readInt(3U);
#endif

I tried a bit of trial and error and all I can seem to come up with is a flash binary that MMDVMHost cannot communicate with, log says cannot determine firmware version. :(

Maybe you could explain a little bit how I can get the serial data from the Nextion screen back into MMDVMHost. Can you provide some detailed explanation on the communication between MMDVMHost and the modem on UART1, and how I can see it in full?

Thank you for any assistance.

[juribeparada]

Hi, the current communication is very simple, as the name says, it is just a "serial repeater". MMDVMHost sends the nextion serial payload through the MMDVM modem protocol (command MMDVM_SERIAL = 0x80), and then the modem firmware copy that payload and sends to the microcontroller nextion serial port. And yes, originally the code was not designed to read data from the nextion serial port, and currently it just discards the data (line 861). To transmit to MMDVMHost, you need to follow the write functions in SerialPort.cpp (and then follow the MMDVM modem protocol structure). For example, you can take writeDStarData() as an example and then you can write a new function like writeSerialRpt(). All these write functions send a fixed size block of data, then you need to call writeSerialRpt() when you have a block of data read from nextion serial port ready to send. Therefore, at line 861, instead of discarding data, you need to form a block of data and when this block is ready you send it with then new function writeSerialRpt(). Remember that readInt(3U) returns just one byte, you need to store in a buffer to form the block of data.

[SS396]

@juribeparada

Thank you for your guidance and detailed explanation. I was able to get serial data from the screen passed back into MMDVMHost and things seem to be working correctly. I can reboot and poweroff :)

I had a few hiccups here and there with some unexpected data, but I think I've come up with an acceptable solution, can you label this as a feature enhancement, and in the next day or so I'll figure out how to get my code in my repository and then maybe you can massage my code into your main code for the next version. I'm sure you could improve it and make it more efficient.

I've also made a few changes elsewhere:

I've added the ability to specify uart2 speed in the configs so that you can run at any speed you assign, since I wanted to run the high speed screen pages, but uart2 was defaulted to 9600. Currently I'm at 115200 with no problems encountered.

I also made the flashing firmware port speed default to 115200 to speed up flashing since the modem seems to operate at 115200 with no issues in normal operation, I don't see why you couldn't flash it at that speed.

all of my testing was done on a RPI 3B+ with Pi-Star: v4.0.0-RC3, and a ZUMspot-rpi v0.6.

Thank you again

[juribeparada]

Hi, good to know you got serial data back into MMDVMHost. I will wait for your code. Regarding flash speed, I only use the default baud speed of the serial bootloader. I think I found some problems using other speeds, but that could be another device (STM32F446), but I can't remember at this moment.

[SS396]

@juribeparada

Yes, thank you again. I was pretty amazed when when I touched the reboot area, and I heard my SSH client throw an error that it got disconnected from across the room, where every time before that either nothing happened, or the modem quit communicating with MMDVMHost, lol.

It seems that there is some unwanted formatting in the readme now, so that will need to be fixed. Where we commented out the area about building STM32Flash no longer being needed on later versions of pi-star images, it seems to have done something weird.

As far as the default flashing speeds, it seems you applied those changes to the makefile (maybe by accident), and if you don't want them set to that speed that is fine with me. It's not a big deal, it is your code to do with as you please.

We'll get the readme adjusted later tonight and notify you.

I guess we can close this now? Not sure if it needs to be open anymore.

[juribeparada]

Thank you for your PR, all now is merged and README.md is displayed correctly now. I will do tests by myself during the next days, then I will decide about the flash programming baud rate.

[SS396]

So, it seems I've made a slight mistake by setting all the configs to default the USART2 speeds at 115200. It is going to break everyone's currently functioning screens, since I doubt anyone has built a custom firmware to increase the port speed like I did.

I'm going to edit them all back to 9600, so it will mimic prior firmware versions, and should perform identical.

I'm also going to see if I can come up with a new way to initialize/configure the screen speed to match whatever speed is defined in the config.h file. That way you wouldn't have to unplug the screen and manually send the serial command to set the speed. Now that the screen is returning if commands were successful or not, it should be possible.