Debugging serial communication scripts

An important advantage of Yoctopuce serial interfaces, compared with RS-232, RS-485 or TTL serial interfaces found elsewhere, is the ability to define stand-alone jobs in the module, for example to query a sensor. This week, we're releasing new firmware for these modules, which facilitates debugging of these scripts, by enabling their progress to be traced in parallel with message exchanges.

If you're not sure what you can and can't do with a communication job on a Yocto-RS232, Yocto-RS485-V2, Yocto-Serial, Yocto-SPI, or Yocto-I2C, start by reading the following posts:

You'll find various examples on our blog, including the post published a few weeks ago which explained a rather elaborate case of configuring the Yocto-I2C to query a humidity sensor, transmit the measure to a CO2 sensor in order to obtain a humidity-compensated measure, and then retrieve the CO2 measure, all autonomously.

If you've ever used the job system, you've probably made a few mistakes when developing your scripts. And until now, error diagnosis has not always been trivial, to say the least: you essentially had to determine the origin of the error by seeing the last command sent by the job.

Improvements

That's why we're bringing you this week's firmware update, which will make your life easier in a number of ways:

You can now display the value of a job's variables in the module logs.
When a job is running, the detail window displays, after each message exchanged, a trace of the job commands that were executed after the message was received. This is a kind of step-by-step debugging, displayed in real time, but also available afterwards.

Two further improvements have been made to facilitate job editing:

It is now possible to reorder job commands with a simple drag-and-drop.
For those who prefer to edit jobs in a text editor, the file saved by the Web interface is now formatted line by line, enabling fairly straightforward text editing.

Variable display in logs

The Log command, which adds a debug message to module logs, now performs the same substitutions as the writeVar command:

($x:INT) displays the value of variable $x as an integer (decimal)
($x:FLOAT) displays the value of variable $x as a real number
($x:BYTE) displays the value of variable $x as a hexadecimal byte (two hexadecimal digits)
($x:WORD) and ($x:WORDL) display the value of variable $x as a hexadecimal word (four hexadecimal digits). The suffix L allows display in little-endian format, i.e. with the most significant byte at the end.
($x:DWORD) and ($x:DWORDL) display the value of variable $x as a hexadecimal dword (eight hexadecimal digits). The suffix L allows display in little-endian format, i.e. with the most significant byte at the end.

Task execution trace

In the Web interface window that lets you view messages exchanged via the interface in real time, you can now follow the execution of the job's tasks in parallel, step by step. To the right of each message, if a job has progressed following the message, a small symbol (i) is displayed. Clicking on this symbol brings up a window which displays the job definition, and shows which steps of each task have been evaluated following this message, and in what order:

Job execution trace

This window then remains open until you explicitly close it, but its contents are updated every time you move the mouse over the (i) symbol of another message. In this way, you can trace the execution of the job as messages are exchanged:

Job progress tracking

As a bonus, when the step executed is an expect command to analyze a message, clicking on the analysis expression automatically launches the expression analyzer on the corresponding message:

Evaluating 'expect' expressions

This enables you, for example, to check the decoding of variables that has been carried out, or - in the event that an expect expression has failed - to find out precisely at which character in the message the evaluation of the expression has stopped.