MATLAB Language Using serial ports Chosing your communication mode
Example
Matlab supports synchronous and asynchronous communication with a serial port. It is important to chose the right communication mode. The choice will depend on:
- how the instrument you are communicating with behave.
- what other functions your main program (or GUI) will have to do aside from managing the serial port.
I'll define 3 different cases to illustrate, from the simplest to the most demanding. For the 3 examples, the instrument I am connecting to is a circuit board with an inclinometer, which can work in the 3 modes I will be describing below.
Mode 1: Synchronous (Master/Slave)
This mode is the simplest one. It correspond to the case where the PC is the Master and the instrument is the slave. The instrument does not send anything to the serial port on it's own, it only replies an answer after being asked a question/command by the Master (the PC, your program). For example:
- The PC sends a command: "Give me a measurement now"
- The instrument receive the command, take the measurement then send back the measurement value to the serial line: "The inclinometer value is XXX".
OR
- The PC sends a command: "Change from mode X to mode Y"
- The instrument receive the command, execute it, then send a confirmation message back to the serial line: "Command executed" (or "Command NOT executed"). This is commonly called an ACK/NACK reply (for "Acknowledge(d)" / "NOT Acknowledged").
Summary: in this mode, the instrument (the Slave) only send data to the serial line immediately after having been asked by the PC (the Master)
Mode 2: Asynchronous
Now suppose I started my instrument, but it is more than just a dumb sensor. It constantly monitor it's own inclination and as long as it is vertical (within a tolerance, let's say +/-15 degrees), it stays silent. If the device is tilted by more than 15 degrees and get close to horizontal, it sends an alarm message to the serial line, immediately followed by a reading of the inclination. As long as the inclination is above the threshold, it continues to send an inclination reading every 5s.
If your main program (or GUI) is constantly "waiting" for message arriving on the serial line, it can do that well ... but it cannot do anything else in the meantime. If the main program is a GUI, it is highly frustrating to have a GUI seemingly "frozen" because it won't accept any input from the user. Essentially, it became the Slave and the instrument is the Master. Unless you have a fancy way of controlling your GUI from the instrument, this is something to avoid. Fortunately, the asynchronous communication mode will let you:
- define a separate function which tells your program what to do when a message is received
- keep this function in a corner, it will only be called and executed when a message arrives on the serial line. The rest of the time the GUI can execute any other code it has to run.
Summary: In this mode, the instrument may send message to the serial line at anytime (but not necessarily all the time). The PC does not wait permanently for a message to process. It is allowed to run any other code. Only when a message arrives, it activates a function which will then read and process this message.
Mode 3: Streaming (Real time)
Now let's unleash the full power of my instrument. I put it in a mode where it will constantly send measurements to the serial line. My program want to receive these packets and display that on a curve or a digital display. If it only send a value every 5s as above, no problem, keep the above mode. But my instrument at full whack sends a data point to the serial line at 1000Hz, i.e. it sends a new value every single millisecond. If I stay in the asynchronous mode described above, there is a high risk (actually a guaranteed certainty) that the special function we defined to process every new packet will take more than 1ms to execute (if you want to plot or display the value, graphic functions are quite slow, not even considering filtering or FFT'ing the signal). It means the function will start to execute, but before it finishes, a new packet will arrive and trigger the function again. The second function is placed in a queue for execution, and will only starts when the first one is done ... but by this time a few new packets arrived and each placed a function to execute in the queue. You can quickly foresee the result: By the time I am plotting the 5th points, I have already hundreds waiting to be plotted too ... the gui slows down, eventually freezes, the stack grows, the buffers fill up, until something gives. Eventually you are left with a completely frozen program or simply a crashed one.
To overcome this, we will disconnect even further the synchronisation link between the PC and the instrument. We will let the instrument send data at it's own pace, without immediately triggering a function at each packet arrival. The serial port buffer will just accumulate the packets received. The PC will only collect data in the buffer at a pace it can manage (a regular interval, set up on the PC side), do something with it (while the buffer is getting refilled by the instrument), then collect a new batch of data from the buffer ... and so on.
Summary: In this mode, the instrument sends data continuously, which are collected by the serial port buffer. At regular interval, the PC collect data from the buffer and do something with it. There is no hard synchronisation link between the PC and the instrument. Both execute their tasks on their own timing.
