Hi all, how are you?. I’m working with a NX4024T032 HMI and I’m sending to it two messages every second and since I’ve set bckmd to 1 then after every correct command received by the HMI it sends back to the main microcontroller 01 FF FF FF, I’ve also have several events like hotspots in the HMI which sends data to the main microcontroller every time they are pressed.
What I need to know is how to do to make those events to wait that confirmation message (01 FF FF FF) is sent before they send their own states from the HMI to the main microcontroller, to not interfere with the previous message.
Nevermind, Now I know that the HMI is sending correctly the data to the microcontroller, my problem is on microcontroller’s side because when a the HMI has an event to send them it transmits the confirmation message plus the event information which adds 7 more bytes to the message and it is difficult to me to handle a message which most of the time send 4 bytes and in some moment sends 11 bytes
Why don’t you set up a large enough ring buffer, i.e. 32 or 64 bytes with a head and a tail pointer? The actual size of the incoming message is head-tail and can be queried at every moment, asynchronously. The actual message is complete if byte[head], byte[head-1], and byte[head-2] are all equal to 0xFF. Then, you extract all bytes from tail until head-3 including and you have the full message. Finally, set tail=head-2 (the terminator FFs are not longer needed and can be overwritten) and wait for the next incoming message.
Hi @Fjodor, well I have a buffer longer than the message that is going to receive, since I’m not using an arduino but an STM32 microcontroller I had to adapt the libraries, the ST people offers their own HAL libraries to manage peripherals and I’m using in this case the one to comunicate through serial port. The serial libraries of ST uses a fixed quantity of bytes as arguments to transmit and/or receive, that part is working well but for what I saw the HMI doesn’t make a pause between the confirmation message and the event sending to the main microcontroller, so, if I instruct the main microcontroller to receive the confirmation message plus the event message it fails for timeout almost all the time because an event on the HMI happens rarely compared tho the quantity of confirmation messages that the HMI sends back to the main microcontroller; then, If I instruct the main microcontroller to receive only the quantity of bytes equivalent to the confirmation message and after that I instruct the main microcontroller to receive the event message then it fails to because apparently it can reconfigure the function soon enough to receive the event message and also the main microcontroller doesn’t know when an event message is coming so the error comes again. Another thing that I noted is that also aparently the HAL function doesn’t write the received bytes directly in the destination buffer but stores them in an temporary buffer so even when I tried to cut the function just after it received the three 0xff the received data is lost because the HAL receive function doesn’t receive the complete number of bytes. Thats why I’m asking if there is a way to force the HMI to wait a minimal amount of time after the confirmation message is sent to send the event message.
I also need to clarify that the receive function that I’m using is a blocking one, it means that it doesn’t use interrupts to work and I’m using it because is the only function in the library that has a timeout to force out the function if the function itself hasn’t received the complete amount of bytes in that time, ther are others with interrupts but I have to force the timeout by putting external conditions since they doesn’t have a timeout argument and internally they have the same kind of temporary buffer so I think I’ll have the same outcome using the interrupt functions.
That’s why I’m asking if there is possible to force the HMI to wait some time after send the confirmation message to send the event message.
This forum is in no way affiliated with NEXTION®, ITEAD STUDIO®, TJC®, or anyone else really. All product names, logos, and brands are property of their respective owners. All company, product, and service names used in this website are for identification purposes only. Use of these names, logos, and brands does not imply endorsement from the respective rights holder(s).