2

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 is

  • A 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 device

  • A 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.

Improve this question
2
  • What kind of time frame is it from sending message to receiving reply - and how long before a message is deemed to have failed (sub - second, seconds, minutes, hours?) How do these times affect the UI?
    – mattnz
    Commented Aug 10, 2014 at 7:21
  • Sending is over a UART at 57600 baud and messages are in ASCII and between 4 and 20 bytes long, so maybe 5ms tops. RX TX is non-blocking, but the polling loop updates every 1s so there is slight delay before visual feedback that everything has updated. I would say three messages in a row and it has failed. I want to keep the device as dumb as possible.
    – geometrikal
    Commented Aug 10, 2014 at 8:18

1 Answer 1

Reset to default
1

The usual approach for communicating over a protocol that can introduce errors into the messages or drop messages altogether involves

  • Adding checksums to the messages to allow the received to verify message integrity
  • The 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.

Improve this answer
7
  • If the requirement is the GUI provides feed back of pending and successful (or not) completion of the transaction, its not possible to completely isolate the higher layers.
    – mattnz
    Commented Aug 10, 2014 at 7:21
  • Thanks for your answer. I've actually implemented that kind of system quite a few times between embedded devices. I've edited the question to add the constraint that most of the logic is done on the GUI side. It is probably no longer best practice, I just want to keep the device as dumb as possible.
    – geometrikal
    Commented Aug 10, 2014 at 8:25
  • @mattnz: If the GUI must show the transaction status, then you can add a callback mechanism to the communication layer indicating if a message was successfully delivered or not. It may indeed not be possible to isolate the GUI from such a status, but it should be isolated from technical details such as error detection and retry mechanisms
    – Bart van Ingen Schenau
    Commented Aug 10, 2014 at 10:31
  • @geometrikal: You can replace the acknowledgement on a set message by performing a get and checking the returned value. That can be done in the communications layer on the Java side without bothering the GUI itself.
    – Bart van Ingen Schenau
    Commented Aug 10, 2014 at 10:35
  • @geometrikal: Not having error detection (CRC) checks in you messages gives you the risk that messages with bit errors get interpreted as a completely different message. This can result in changing a completely different parameter or retrieving the value of a completely different parameter. Do you want that risk.
    – Bart van Ingen Schenau
    Commented Aug 10, 2014 at 10:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.