The Executable Section

The executable section is where the real decoding work is done. As its statements are processed, an implicit pointer is moved through the layer being decoded from beginning to end.

FIELD command_code (Fixed 1 Byte) (Table tableCommands) IN_SUMMARY "Command/Response" 150 "Command"

FIELD actuator_number (Fixed 1 Byte) (Decimal) "Actuator Number" VERIFY (FieldIsBetween 1 32)

FIELD actuator_value (Fixed 2 Bytes) (Decimal) "Value to set"

FIELD checksum (Fixed 1 Byte) (Hex) IN_SUMMARY "C'sum" 40 "Checksum" VERIFY (FPChecksum)

END_MAIN_PATH

Normally each FIELD statement decodes a given number of bits or bytes and then moves the pointer forward by that amount ready for the next FIELD. As we shall see, however, we can manipulate the pointer in various ways in order to process fields out of sequence or to process them twice when the need arises - as it often does. Strictly speaking this pointer is a bit pointer. If you are dealing with a protocol that is totally octet-oriented, you may safely imagine the pointer as a byte pointer.

Eight types of statements appear in the executable section. Five of them, FIELD, RESERVED, GROUP, GROUP FIELD and BRANCH, we refer to collectively as executable statements. The sixth, PARAMETER, is a pseudo-field, the seventh is the INCLUDE keyword and the eighth is END_MAIN_PATH. When the protocol analyzer sees END_ MAIN_PATH, it stops decoding that layer and goes on to the next.

Every statement except BRANCH, RESERVED and INCLUDE defines some kind of protocol field or group of fields and every such entity must be given a unique name within a decoder. Thus, not only must all FIELDs have unique names, but you cannot have a FIELD with the same name as a GROUP or a PARAMETER. By convention we use names that are all lower case and with words separated by underscores.

We encourage you to follow along with the tutorial examples. FP.dec, the Fictitious Protocol decoder file, is in the My Decoders directory of your product installation. We also provide a capture file of FP data called FP.cfa. You can load FP.cfa into your protocol analyzer and see how the different types of data appear on the screen. FP.cfd is the capture file declaration used to create FP.cfa. This is a text file that can be loaded into CFA Maker to create a capture file. FP.cfd shows the data we used to create FP.cfa and explains what type of data is in each frame. For information on how to obtain a copy of CFA Maker, please contact Technical Support.

Throughout this tutorial, hexadecimal numbers will be prefixed with "0x" to distinguish them from decimal values.

Fictitious Protocol is the next example we will use to further explain DecoderScript writing. First let's look at the type of data we want to decode. Then we will build our decoder.