I am writing a JavaFX GUI program for user configuration of an embedded systems device. The device will be connected by a wired or wireless serial connection which is not 100% reliable. Therefore when the user makes settings changes in the GUI, the program sends a set message to the device, then must verify they are set.My question is what program structures are useful for this purpose. My current approach isA class called Sync which contains two variables related to the particular setting. One is bound to the setting as it appears in the GUI and another to the setting as it has been received from the device.A property in Sync that describes if the two settings are the same, the device is setting is newer or the GUI setting is newer. Field decorations then bind to this setting.A button called set that sends a set message to the deviceA loop that continually polls the device for its settings (which are stored in the Sync class). The decorators then give feedback to the user whether the settings have synced.I'd like to do something a bit more elegant where the Sync class takes care of sending messages and checking if the setting were set.Some specific questions:Should I remove the 'set' button and have the Sync class update the device whenever it has valid settings?Is a decoration enough to indicate whether or not the setting has been set? Would a dialog box be better?Some general questions:Is there a best practice approach to this problem?Are there common classes that would be useful?Any other alternative designs?Edit:A constraint: I'd like to keep the device as dumb as possible. I've implemented custom protocols with CRC, ack/nack, retries, message buffers, etc. before, albeit between two embedded systems. The software will be modified for different beginner Arduino projects and I want to keep most of the logic (even validation) on the GUI side.
Updating settings on embedded systems device with non-reliable comms
communication;embedded systems
The usual approach for communicating over a protocol that can introduce errors into the messages or drop messages altogether involvesAdding checksums to the messages to allow the received to verify message integrityThe sending of positive or negative acknowledge messages to inform the sender that a message has respectively been successfully received or has been missed. Positive acknowledgement is usually easier to implement.A retry mechanism to re-send messages that have not been acknowledges within a reasonable time.With these facilities in the communication protocol, the higher level components in both sides can regard the communication as reliable and don't need to take special measures to ensure that the message was received. 