Tweet
Communication Protocol with Nextioan
@Mdtoday, since you have had experience in communication with the Nextion Enhanced Display, I woild like to go over my proposed approach:
(1) Since the smallest message that can be received from the Nextion is 4 bytes, set the FIFO trigger level of the 16550 Uart to 4. That way we will not be flooded with interrupts.
(2) when a recv_data nterrupt is received from the uart (4 bytes in the FIFO) issue a read_request to the Uart for 4 bytes.
(3) depending on the value of the 1st byte issue a read request for the outstanding number of bytes. There is only 1 response where the total length of the message is not known until you parse the complete message and don't think that our application will ever issue the command that will invoke that response. The response is a 0x70 "string data enclosed" which is to a respone to a get <string object >command from the mcu (after all bytes that we are concerned with are received, flush the receive FIFO (don't want extraneouse data hanging around).
After communications has established between Nextion and our embedded application, issue a "baud=<new baud rate> from the application, change the baud rate in the Uart, and issue a "get baud" (which should elicit a response) to the Nextion to verify we still have communication. From that point we are in our main loop looking for interupt flags from all connected interrupts. When a recv_data interrupt ooccurs, perform the processing listed in steps <1,2,3>, take action based on the data received. When processing interrupts for thr RX and Filters, when appro[riate do a data assignment of the appropriate varioable in the Nextion (e.g. sys0=<0xff,0xff,0xff,0xff> or a0.val=<0xff,0xff,0xff,0xff>). Most of the communication will be assignment commands of target data from our embedded application. The only messages comming from the nextion will be responses to "get commands (in the case of TX/RX parameters, and the event notifications resulting from navigation of some of the pages of the Nextion menus.
I think that is pretty much it, everything else (the RX/TX and the Nextion application) just merrily go along on their own... after initialization, all our embedded application does is play traffic cop.
@Mdtoday, since you have had experience in communication with the Nextion Enhanced Display, I woild like to go over my proposed approach:
(1) Since the smallest message that can be received from the Nextion is 4 bytes, set the FIFO trigger level of the 16550 Uart to 4. That way we will not be flooded with interrupts.
(2) when a recv_data nterrupt is received from the uart (4 bytes in the FIFO) issue a read_request to the Uart for 4 bytes.
(3) depending on the value of the 1st byte issue a read request for the outstanding number of bytes. There is only 1 response where the total length of the message is not known until you parse the complete message and don't think that our application will ever issue the command that will invoke that response. The response is a 0x70 "string data enclosed" which is to a respone to a get <string object >command from the mcu (after all bytes that we are concerned with are received, flush the receive FIFO (don't want extraneouse data hanging around).
After communications has established between Nextion and our embedded application, issue a "baud=<new baud rate> from the application, change the baud rate in the Uart, and issue a "get baud" (which should elicit a response) to the Nextion to verify we still have communication. From that point we are in our main loop looking for interupt flags from all connected interrupts. When a recv_data interrupt ooccurs, perform the processing listed in steps <1,2,3>, take action based on the data received. When processing interrupts for thr RX and Filters, when appro[riate do a data assignment of the appropriate varioable in the Nextion (e.g. sys0=<0xff,0xff,0xff,0xff> or a0.val=<0xff,0xff,0xff,0xff>). Most of the communication will be assignment commands of target data from our embedded application. The only messages comming from the nextion will be responses to "get commands (in the case of TX/RX parameters, and the event notifications resulting from navigation of some of the pages of the Nextion menus.
I think that is pretty much it, everything else (the RX/TX and the Nextion application) just merrily go along on their own... after initialization, all our embedded application does is play traffic cop.
Comment