Nextion screen firmware upload / generic serial.

[rawbengal]

I have a Nextion screen wired to the MMDVM modem and would like to be able to upload firmware to it without having to remove the display from its case or reconnect it. From what I can tell, the existing serial repeater code is very specific to Nextion packets that end in 3 0xFF characters. Unfortunately, the Nextion firmware upload does not send back packets formatted this way. Instead it sends back a 0x05 byte for every 4096 bytes of raw data sent during the upload.

The upload protocol also allows for one to specify a different baud rate for the data transfer.

1. Perhaps I am misreading the code that handles the modem serial port but it seems very Nextion specific rather than just acting as a generic serial interface.
2. From my reading of the code, it would not be possible to use the serial repeater to upload new firmware to the Nextion because it only handles frames that end in 3 0xFF chars.
3. There does not seem to be support for dynamic setting of the modem serial port baud rate. This means any desire to use a different rate requires recompilation.

I propose that the serial repeater interface be modified to allow more generic support of serial data. This would include being able to specify a host-specified end-frame character (or none, meaning, send characters as quickly as possible), specification of the serial interface parameters dynamically. The goal would be to support Nextion firmware updates via the serial interface.

I would be happy to code this up and submit a pull request but wanted to make sure I'm not missing something in my analysis of the current situation. Perhaps this is already implemented?

[rawbengal]

Adding @plainpylut since they implemented the original Nextion receive support and might have comment.

[rawbengal]

In reading the code again, I just noticed this comment in SerialPort.cpp

      //  TODO - BG5HHP
      //   modem serial data repeat should be generic instead of coupling with the nextion protocol.

Looks like he/she agrees with my concern... Adding @shawnchain for comment before I go down the rabbit-hole of making these changes.

[rawbengal]

Thanks for the feedback @SS396. I guess my general thinking is that, even though most uses of the serial repeater will be for Nextion displays, we can anticipate other ways in which people will use/misuse the modem board port. Additionally, since even Nextion doesn't hold firmly to the "every message ends in FFFFFF" rule, we cannot only use that rule if we want a full featured driver. This feels like a place in which we don't want to hard code a specific use case or operating mode into the firmware. Essentially, the repeater should do just that... repeat. Since RS232 is not a packet-based protocol, we probably shouldn't enforce that in the firmware. It is up to the host-side software to handle interpretation of the serial stream. This also has the benefit that the same code which handles DIRECT serial port communication with the device will also work when used through the repeater. They both just see a stream of bytes which must be interpreted or broken into packets. In the ideal situation, the modem-based serial port should just look like any other device based serial port and leave it to the host-side program to deal with formatting.

Now, that said, I understand what you are saying about potential issues with the two UART's on the modem board having contention issues, especially when you consider that the host interface needs to add extra packet information to the stream. This could especially have impact if the baud rates are similar and we are saturating the communication channel.

I'll experiment with it and see what I learn.

[shawnchain]

I think the serial data repeat via MMDVM MCU has limitations. Small packets will be fine to be pass through, but it's not a good idea to transfer long-lasting, huge data at high speed.

The quick reason for that is the modem firmware has no RTOS and you have to do a lot of work to support slow(compare to the mcu speed and ISR handler) USART I/O read/write.

As to my code, I just make minimum changes to let the nextion-touch-screen events get through. I don't see any necessary to make it be generic indeed under current firmware code.

[rawbengal]

This is all good feedback. Thanks.

The current behavior of the MMDVM firmware is to buffer up all return data from the Nextion until it sees FFFFFF and then send ALL data back. The only time it does not send ALL the data back is on an empty message (just FFFFFF). With the exception of this corner case, the firmware is already sending all the bytes back. The change of behavior I am describing is to allow a host-specified mode in which the buffering on return bytes is turned off. This would allow a single 05 character (an ACK for 4K bytes during firmware upload) to pass without being held up. The default behavior would be the current, buffered, behavior so no other software should need to change.

The current firmware, will ONLY support a Nextion device to be connected to the modem serial port and will not allow firmware update. The change I propose will allow either. The MMDVM Host software will continue to need to be Nextion-specific. "Generic" serial device support comes for free from implementing support for Nextion firmware upload.

As far as @shawnchain's concerns about speed and amount of data, it seems that there is some practical limit on both of these.

I have a simple fix to the firmware which will let me test this behavior out. I suspect Shawn is right about throughput issues though, so I think I'll hold off on any further discussion. I'm also prepping for my general class license upgrade so I need to spend some time on that. Wish me luck. :)

[rd0fun]

This is all good feedback. Thanks.

The current behavior of the MMDVM firmware is to buffer up all return data from the Nextion until it sees FFFFFF and then send ALL data back. The only time it does not send ALL the data back is on an empty message (just FFFFFF). With the exception of this corner case, the firmware is already sending all the bytes back. The change of behavior I am describing is to allow a host-specified mode in which the buffering on return bytes is turned off. This would allow a single 05 character (an ACK for 4K bytes during firmware upload) to pass without being held up. The default behavior would be the current, buffered, behavior so no other software should need to change.

The current firmware, will ONLY support a Nextion device to be connected to the modem serial port and will not allow firmware update. The change I propose will allow either. The MMDVM Host software will continue to need to be Nextion-specific. "Generic" serial device support comes for free from implementing support for Nextion firmware upload.

As far as @shawnchain's concerns about speed and amount of data, it seems that there is some practical limit on both of these.

I have a simple fix to the firmware which will let me test this behavior out. I suspect Shawn is right about throughput issues though, so I think I'll hold off on any further discussion. I'm also prepping for my general class license upgrade so I need to spend some time on that. Wish me luck. :)

Just curious if you ever implemented the change?

The only thing requiring people to use TTL to USB converters is updating the Nextion screen. It would be awesome if a small change enabled this! Most cases do not allow for easy removal of the screen to insert (then remove) an SD Card. This would be a VERY welcome change for sure!