CATC Scripting Language for USB LeCroy Corporation
Document Disclaimer
The information contained in this document has been carefully checked and is believed to be
reliable. However, no responsibility can be assumed for inaccuracies that may not have been
detected.
LeCroy reserves the right to revise the information presented in this document without notice or
penalty.
Trademarks and Servicemarks
LeCroy, CATC, Voyager, Advisor T3, USBTracer, USBMobile, and USBAdvisor are
trademarks of LeCroy.
All other trademarks are property of their respective companies.
CATC Scripting Language (CSL) was developed to create scripts that would allow
users to do file-based decoding with CATC USBTracer, USBMobile, and USBAdvisor analyzers. CSL is used to edit CATC Decode Scripting (CDS) files. CATC
analyzers are equipped with built-in decoders in addition to script-based decoders
that can be modified by the users or implemented as-is. Decoding scripts for
analyzers are distributed in the /scripts directory. These scripts are tools to
decode and display transactions. Users can also add entirely new, customized
decoders.
Included with the CATC USBTracer Protocol Analyzer are USB decoder scripts for
many of the USB classes, as described in the USB specification. They are located
in the USBTracer\Scripts directory and are identifiable by the .dec and .inc extensions. These scripts are tools to decode and display transactions. Users can also
add entirely new, customized decoders to fit their own, specific development needs.
USBTracer looks in the \Scripts directory and automatically loads all of the .dec
files that it finds. To prevent a particular decoder from being loaded, changed its
extension to something other than .dec or move it out of the \Scripts directory.
CSL is based on C language syntax, so anyone with a C programming background
will have no trouble learning CSL. The simple, yet powerful, structure of CSL also
enables less experienced users to easily acquire the basic knowledge needed to start
writing custom scripts.
Features of CATC Scripting Language
•Powerful -- provides a high-level API while simultaneously allowing
implementation of complex algorithms.
•Easy to learn and use -- has a simple but effective syntax.
•Self-contained -- needs no external tools to run scripts.
•Wide range of value types -- provides efficient and easy processing of data.
•Used to create built-in script-based decoders for analyzers.
•May be used to write custom decoders.
•General purpose -- is integrated in a number of CATC products.
1
CHAPTER 1
CATC Scripting Language for USBIntroduction
2
CHAPTER 2
CATC Scripting Language for USBValues
CHAPTER 2: VALUES
There are five value types that may be manipulated by a script: integers, strings,
lists, raw bytes,andnull. CSL is not a strongly typed language. Value types need
not be pre-declared. Literals, variables and constants can take on any of the five
value types, and the types can be reassigned dynamically.
Literals
Literals are data that remain unchanged when the program is compiled. Literals are
a way of expressing hard-coded data in a script.
Integers
Integer literals represent numeric values with no fractions or decimal points. Hexadecimal, octal, decimal, and binary notation are supported:
Hexadecimal numbers must be preceded by 0x: 0x2A, 0x54, 0xFFFFFF01
Octal numbers must begin with 0: 0775, 017, 0400
Decimal numbers are written as usual: 24, 1256, 2
Binary numbers are denoted with 0b: 0b01101100, 0b01, 0b100000
Strings
String literals are used to represent text. A string consists of zero or more characters
and can include numbers, letters, spaces, and punctuation. An empty string ("")
contains no characters and evaluates to false in an expression, whereas a non-empty
string evaluates to true. Double quotes surround a string, and some standard
backslash (\) escape sequences are supported.
StringRepresented text
"Quote: \"This is a string
literal.\""
"256"
"abcd!$%&*"abcd!$%&*
"June 26, 2001"June 26, 2001
Quote: "This is a string
literal."
256
**Note that this does not represent the integer
256, but only the characters that make up the number.
"[ 1, 2, 3 ]"[ 1, 2, 3 ]
Table 2.1: Examples of String Literals
3
CHAPTER 2
CATC Scripting Language for USBValues
Escape Sequences
These are the available escape sequences in CSL:
Escape
Character
backslash\\"This is a backslash: \\"This is a backslash: \
newline\n"This is how\nto get a newline." This is how
single quote\'"\'Single quote\'"'Single quote'
SequenceExampleOutput
to get a newline.
Table 2.2: Escape Sequences
Lists
A list can hold zero or more pieces of data. A list that contains zero pieces of data
is called an empty list. An empty list evaluates to false when used in an expression,
whereas a non-empty list evaluates to true. List literals are expressed using the
square bracket ([]) delimiters. List elements can be of any type, including lists.
Raw binary values are used primarily for efficient access to packet payloads. A
literal notation is supported using single quotes:
'00112233445566778899AABBCCDDEEFF'
This represents an array of 16 bytes with values starting at 00 and ranging up to
0xFF. The values can only be hexadecimal digits. Each digit represents a nybble
(four bits), and if there are not an even number of nybbles specified, an implicit zero
is added to the first byte. For example:
'FFF'
is interpreted as
'0FFF'
Null
Null indicates an absence of valid data. The keyword null represents a literal
null value and evaluates to false when used in expressions.
4
CHAPTER 2
CATC Scripting Language for USBValues
result = null;
Variables
Variables are used to store information, or data, that can be modified. A variable
can be thought of as a container that holds a value.
All variables have names. Variable names must contain only alphanumeric characters and the underscore ( _ ) character, and they cannot begin with a number. Some
possible variable names are
x
_NewValue
name_2
A variable is created when it is assigned a value. Variables can be of any value type,
and can change type with re-assignment. Values are assigned using the assignment
operator ( = ). The name of the variable goes on the left side of the operator, and the
value goes on the right:
x=[1,2,3]
New_value = x
name2 = "Smith"
If a variable is referenced before it is assigned a value, it evaluates to null.
There are two types of variables: global and local.
Global Variables
Global variables are defined outside of the scope of functions. Defining global
variables requires the use of the keyword set. Global variables are visible throughout a file (and all files that it includes).
set Global = 10;
If an assignment in a function has a global as a left-hand value, a variable will not
be created, but the global variable will be changed. For example
set Global = 10;
Function()
{
Global = "cat";
Local = 20;
}
5
CHAPTER 2
CATC Scripting Language for USBValues
will create a local variable called Local, which will only be visible within the
function Function. Additionally, it will change the value of Global to "cat",
which will be visible to all functions. This will also change its value type from an
integer to a string.
Local Variables
Local variables are not declared. Instead, they are created as needed. Local
variables are created either by being in a function's parameter list, or simply by
being assigned a value in a function body.
Function(Parameter)
{
Local = 20;
}
This function will create a local variable Parameter and a local variable Local,
which has an assigned value of 20.
Constants
A constant is similar to a variable, except that its value cannot be changed. Like
variables, constant names must contain only alphanumeric characters and the underscore ( _ ) character, and they cannot begin with a number.
Constants are declared similarly to global variables using the keyword const:
const CONSTANT = 20;
They can be assigned to any value type, but will generate an error if used in the lefthand side of an assignment statement later on. For instance,
const constant_2 = 3;
Function()
{
constant_2 = 5;
}
will generate an error.
Declaring a constant with the same name as a global, or a global with the same name
as a constant, will also generate an error. Like globals, constants can only be
declared in the file scope.
6
CHAPTER 3
CATC Scripting Language for USBExpressions
CHAPTER 3: EXPRESSIONS
An expression is a statement that calculates a value. The simplest type of expression
is assignment:
x=2
The expression x=2calculates 2 as the value of x.
All expressions contain operators, which are described in Chapter 4, Operators,on
page 9. The operators indicate how an expression should be evaluated in order to
arrive at its value. For example
x+2
saystoadd2tox to find the value of the expression. Another example is
x>2
which indicates that x is greater than 2. This is a Boolean expression, so it will
evaluate to either true or false. Therefore, if x=3, then x>2will evaluate to
true; if x=1,itwillreturnfalse.
True is denoted by a non-zero integer (any integer except 0), and false is a zero
integer (0). True and false are also supported for lists (an empty list is false, while
all others are true), and strings (an empty string is false, while all others are true),
and null is considered false. However, all Boolean operators will result in integer
values.
select expression
The select expression selects the value to which it evaluates based on Boolean
expressions. This is the format for a select expression:
The expressions are evaluated in order, and the statement that is associated with the
first true expression is executed. That value is what the entire expression evaluates
to.
7
CHAPTER 3
CATC Scripting Language for USBExpressions
x=10
Value_of_x = select {
x<5:"Lessthan 5";
x>=5:"Greater than or equal to 5";
};
The above expression will evaluate to “Greater than or equal to 5” because the first
true expression is x>=5. Note that a semicolon is required at the end of aselect expression because it is not a compound statement and can be used in an
expression context.
There is also a keyword default, which in effect always evaluates to true. An
example of its use is
Astring = select {
A==1:"one";
A==2:"two";
A == 3: "three";
A>3:"overflow";
default : null;
};
If none of the first four expressions evaluates to true, then default will be evaluated, returning a value of null for the entire expression.
select expressions can also be used to conditionally execute statements, similar
to C switch statements:
In this case the appropriate function is called depending on the value of A, but the
evaluated result of the select expression is ignored.
8
CHAPTER 4
CATC Scripting Language for USBOperators
CHAPTER 4: OPERATORS
An operator is a symbol that represents an action, such as addition or subtraction,
that can be performed on data. Operators are used to manipulate data. The data
being manipulated are called operands. Literals, function calls, constants, and
variables can all serve as operands. For example, in the operation
x+2
the variable x and the integer 2 are both operands, and + is the operator.
Operations
Operations can be performed on any combination of value types, but will result in
a null value if the operation is not defined. Defined operations are listed in the
Operand Types column of Table 4.2 on page 12. Any binary operation on a null and
a non-null value will result in the non-null value. For example, if
x = null
then
3*x
will return a value of 3.
A binary operation is an operation that contains an operand on each side of the
operator, as in the preceding examples. An operation with only one operand is
called a unary operation, and requires the use of a unary operator. An example of a
unary operation is
!1
which uses the logical negation operator. It returns a value of 0.
The unary operators are
sizeof(), head(), tail(), ~ and !.
Operator Precedence and Associativity
Operator rules of precedence and associativity determine in what order operands are
evaluated in expressions. Expressions with operators of higher precedence are
evaluated first. In the expression
4+9*5
the * operator has the highest precedence, so the multiplication is performed before
the addition. Therefore, the expression evaluates to 49.
9
CHAPTER 4
CATC Scripting Language for USBOperators
The associative operator () is used to group parts of the expression, forcing those
parts to be evaluated first. In this way, the rules of precedence can be overridden.
For example,
(4+9)*5
causes the addition to be performed before the multiplication, resulting in a value
of 65.
When operators of equal precedence occur in an expression, the operands are
evaluated according to the associativity of the operators. This means that if an operator's associativity is left to right, then the operations will be done starting from
the left side of the expression. So, the expression
4+9-6+5
would evaluate to 12. However, if the associative operator is used to group a part or
parts of the expression, those parts are evaluated first. Therefore,
(4+9)-(6+5)
has a value of 2.
In Table 4.1, Operator Precedence and Associativity, the operators are listed in
order of precedence, from highest to lowest. Operators on the same line have equal
precedence, and their associativity is shown in the second column.
Operator SymbolAssociativity
++--
[]()
~!sizeofheadtail
*/%
+-
<<>>
<><=>=
==!=
&
^
|
Right to left
Left to right
Right to left
Left to right
Left to right
Left to right
Left to right
Left to right
Left to right
Left to right
Left to right
&&
||
Table 4.1: Operator Precedence and Associativity
10
Left to right
Left to right
CHAPTER 4
CATC Scripting Language for USBOperators
Operator SymbolAssociativity
=+=-=*=/=%=>>=<<=&=
^=|=
Table 4.1: Operator Precedence and Associativity (Continued)
Right to left
11
CHAPTER 4
CATC Scripting Language for USBOperators
Operator
Symbol
Description
Operand
Types
Result
Types
Examples
Index Operator
[]Index or
subscript
Raw BytesIntegerRaw = '001122'
Raw[1] = 0x11
ListAnyList = [0, 1, 2, 3, [4, 5]]
List[2] = 2
List[4] = [4, 5]
List[4][1] = 5
*Note: if an indexed Raw value is assigned to any
value that is not a byte ( > 255 or not an integer), the
variable will be promoted to a list before the
assignment is performed.
*Note: the last example demonstrates that the
sizeof() operator returns the shallow count of a
complex list.
*Note: the Head of a list is the first item in the list.
*Note: the Tail of a list includes everything except
the Head.
Table 4.2: Operators (Continued)
15
CHAPTER 4
CATC Scripting Language for USBOperators
16
CHAPTER 5
CATC Scripting Language for USBComments
CHAPTER 5: COMMENTS
Comments may be inserted into scripts as a way of documenting what the script
does and how it does it. Comments are useful as a way to help others understand
how a particular script works. Additionally, comments can be used as an aid in
structuring the program.
Comments in CSL begin with a hash mark (#) and finish at the end of the line. The
end of the line is indicated by pressing the Return or Enter key. Anything contained
inside the comment delimiters is ignored by the compiler. Thus,
#x=2;
is not considered part of the program. CSL supports only end-of-line comments,
which means that comments can be used only at the end of a line or on their own
line. It's not possible to place a comment in the middle of a line.
Writing a multi-line comment requires surrounding each line with the comment delimiters
# otherwise the compiler would try to interpret
# anything outside of the delimiters
# as part of the code.
The most common use of comments is to explain the purpose of the code immediately following the comment. For example:
# Add a profile if we got a server channel
if(rfChannel != "Failure")
{
result = SDPAddProfileServiceRecord(rfChannel,
"ObjectPush");
Trace("SDPAddProfileServiceRecord returned ",
result, "\n");
}
17
CHAPTER 5
CATC Scripting Language for USBComments
18
CHAPTER 6
CATC Scripting Language for USBKeywords
CHAPTER 6: KEYWORDS
Keywords are reserved words that have special meanings within the language. They
cannot be used as names for variables, constants or functions.
In addition to the operators, the following are keywords in CSL:
KeywordUsage
selectselect expression
setdefine a global variable
constdefine a constant
returnreturn statement
whilewhile statement
forfor statement
ifif statement
elseif-else statement
defaultselect expression
nullnull value
ininput context
outoutput context
Table 6.1: Keywords
19
CHAPTER 6
CATC Scripting Language for USBKeywords
20
CHAPTER 7
CATC Scripting Language for USBStatements
CHAPTER 7: STATEMENTS
Statements are the building blocks of a program. A program is made up of list of
statements.
Seven kinds of statements are used in CSL: expression statements, if statements, ifelse statements, while statements, for statements, return statements, and compound
statements.
Expression Statements
An expression statement describes a value, variable, or function.
<expression>
Here are some examples of the different kinds of expression statements:
Value: x + 3;
Variable: x = 3;
Function: Trace(x+3);
The variable expression statement is also called an assignment statement, because
it assigns a value to a variable.
if Statements
An if statement follows the form
if <expression><statement>
For example,
if (3 && 3) Trace("True!");
will cause the program to evaluate whether the expression 3&&3is nonzero, or
True. It is, so the expression evaluates to True and the Trace statement will be
executed. On the other hand, the expression 3&&0is not nonzero, so it would
evaluate to False, and the statement wouldn't be executed.
if-else Statements
The form for an if-else statement is
if <expression><statement1>
else <statement2>
The following code
21
CHAPTER 7
CATC Scripting Language for USBStatements
if(3-3||2-2)Trace ( "Yes" );
else Trace ( "No" );
will cause “No” to be printed, because 3-3||2-2will evaluate to False
(neither 3-3nor 2-2is nonzero).
while Statements
A while statement is written as
while <expression><statement>
An example of this is
x=2;
while ( x < 5 )
{
Trace ( x, ", " );
x=x+1;
}
The result of this would be
2, 3, 4,
for Statements
A for statement takes the form
for (<expression1>; <expression2>; <expression3>)
<statement>
The first expression initializes, or sets, the starting value for x. It is executed one
time, before the loop begins. The second expression is a conditional expression. It
determines whether the loop will continue -- if it evaluates true, the function keeps
executing and proceeds to the statement; if it evaluates false, the loop ends. The
third expression is executed after every iteration of the statement.
Figure 7-1: Execution of a for statement
22
CHAPTER 7
CATC Scripting Language for USBStatements
The example
for(x=2;x<5;x=x+1)Trace ( x, "\n" );
would output
2
3
4
The example above works out like this: the expression x=2is executed. The
value of x is passed to x<5,resulting in 2<5. This evaluates to true, so the
statement Trace (x, "\n" ) is performed, causing 2 and a new line to print.
Next, the third expression is executed, and the value of x isincreasedto3.Now,
x<5is executed again, and is again true, so the Trace statement is executed,
causing 3 and a new line to print. The third expression increases the value of x to 4;
4<5istrue,so4andanewlineareprintedbytheTrace statement. Next, the
value of x increases to 5. 5<5is not true, so the loop ends.
return Statements
Every function returns a value, which is usually designated in a return statement.
A return statement returns the value of an expression to the calling environment.
It uses the following form:
return <expression>;
An example of a return statement and its calling environment is
Trace ( HiThere() );
...
HiThere()
{
return "Hi there";
}
The call to the primitive function Trace causes the function HiThere() to be
executed. HiThere() returns the string “Hi there” as its value. This value is
passed to the calling environment (Trace), resulting in this output:
Hi there
A return statement also causes a function to stop executing. Any statements that
come after the return statement are ignored, because return transfers control
of the program back to the calling environment. As a result,
23
CHAPTER 7
CATC Scripting Language for USBStatements
Trace ( HiThere() );
...
HiThere()
{
a = "Hi there";
return a;
b = "Goodbye";
return b;
}
will output only
Hi there
because when return a; is encountered, execution of the function terminates,
and the second return statement (return b;) is never processed. However,
Trace ( HiThere() );
...
HiThere()
{
a = "Hi there";
b = "Goodbye";
if(3!=3)return a;
else return b;
}
will output
Goodbye
because the if statement evaluates to false. This causes the first return statement
to be skipped. The function continues executing with the else statement, thereby
returning the value of b to be used as an argument to Trace.
Compound Statements
A compound statement, or statement block, is a group of one or more statements
that is treated as a single statement. A compound statement is always enclosed in
curly braces ( {} ). Each statement within the curly braces is followed by a semicolon; however, a semicolon is not used following the closing curly brace.
The syntax for a compound statement is
{
<first_statement>;
<second_statement>;
24
CHAPTER 7
CATC Scripting Language for USBStatements
...
<last_statement>;
}
An example of a compound statement is
{
x=2;
x+3;
}
It's also possible to nest compound statements, like so:
{
x=2;
{
y=3;
}
x+3;
}
Compound statements can be used anywhere that any other kind of statement can
be used.
if (3 && 3)
{
result = "True!";
Trace(result);
}
Compound statements are required for function declarations and are commonly
used in if, if-else, while,andfor statements.
25
CHAPTER 7
CATC Scripting Language for USBStatements
26
CHAPTER 8
CATC Scripting Language for USBPreprocessing
CHAPTER 8: PREPROCESSING
The preprocessing command %include can be used to insert the contents of a file
into a script. It has the effect of copying and pasting the file into the code. Using
%include allows the user to create modular script files that can then be incorporated into a script. This way, commands can easily be located and reused.
The syntax for %include is this:
%include “includefile.inc”
The quotation marks around the filename are required, and by convention, the
included file has a .inc extension.
The filenames given in the include directive are always treated as being relative to
the current file being parsed. So, if a file is referenced via the preprocessing
command in a .dec file, and no path information is provided (%include“file.inc”), the application will try to load the file from the current directory.
Files that are in a directory one level up from the current file can be referenced using
“..\file.inc”, and likewise, files one level down can be referenced using the
relative pathname (“directory\file.inc”). Last but not least, files can also
be referred to using a full pathname, such as
“C:\global_scripts\include\file.inc”.
Additionally, the directory “shared” under “Scripts” is checked too. So if you want
to reference a file in the “shared” directory, you can reference it by its name without
any explicit pathname.
27
CHAPTER 8
CATC Scripting Language for USBPreprocessing
28
CHAPTER 9
CATC Scripting Language for USBContext
CHAPTER 9: CONTEXT
The context is the mechanism by which transaction data is passed in and out of the
scripts. There is an output context that is modified by the script, and there are
possibly multiple input contexts that the script will be invoked on separately.
A context serves two roles: firstly, it functions as a symbol table whose values are
local to a particular transaction; secondly, it functions as an interface to the application. Two keywords are used to reference symbols in the context: in and out.
Dot notation is used to specify a symbol within a context:
out.symbol = "abcd";
out.type = in.type;
The output contextcan be read and written to, but the input context can only be read.
Context symbols follow the same rules as local variables: they are created on
demand, and uninitialized symbols always evaluate to null.
When a script is first invoked, it is given an input context that corresponds to a
packet or transaction that is a candidate for being a part of a larger transaction. The
output context is initially empty. It is the script's job to examine the input context
and decide if it qualifies for membership in the type of transaction that the script
was designed to decode. If it qualifies, the appropriate values will be decoded and
put in the output context symbol table, and if the transaction is complete, it will be
done. If the transaction is not complete, the script will indicate this to the application based on its return value, and will be invoked again with the same output
context, but a new input context. The script then must decide if this new input
context is a member of the transaction, and keep doing this until the transaction is
complete.
In order to accomplish all this, state information should be placed in the output
context. It should be possible to use the output context of one transaction as an
input context to another transaction.
29
CHAPTER 9
CATC Scripting Language for USBContext
30
CHAPTER 10
CATC Scripting Language for USBFunctions
CHAPTER 10: FUNCTIONS
A function is a named statement or a group of statements that are executed as one
unit. All functions have names. Function names must contain only alphanumeric
characters and the underscore ( _ ) character, and they cannot begin with a number.
A function can have zero or more parameters, which are values that are passed to
the function statement(s). Parameters are also known as arguments. Value types are
not specified for the arguments or return values. Named arguments are local to the
function body, and functions can be called recursively.
The syntax for a function declaration is
name(<parameter1>, <parameter2>, ...)
{
<statements>
}
The syntax to call a function is
name(<parameter1>, <parameter2>, ...)
So, for example, a function named add can be declared like this:
add(x, y)
{
return x + y;
}
andcalledthisway:
add(5, 6);
This would result in a return value of 11.
Every function returns a value. The return value is usually specified using a
return statement, but if no return statement is specified, the return value will
be the value of the last statement executed.
Arguments are not checked for appropriate value types or number of arguments
when a function is called. If a function is called with fewer arguments than were
defined, the specified arguments are assigned, and the remaining arguments are
assigned to null. If a function is called with more arguments than were defined, the
extra arguments are ignored. For example, if the function add is called with just
one argument
add(1);
31
CHAPTER 10
CATC Scripting Language for USBFunctions
the parameter x will be assigned to 1, and the parameter y will be assigned to null,
resulting in a return value of 1. But if add is called with more than two arguments
add(1, 2, 3);
x will be assigned to 1, y to 2, and 3 will be ignored, resulting in a return value of 3.
All parameters are passed by value, not by reference, and can be changed in the
function body without affecting the values that were passed in. For instance, the
function
add_1(x, y)
{
x=2;
y=3;
return x + y;
}
reassigns parameter values within the statements. So,
a = 10;
b = 20;
add_1(a, b);
will have a return value of 5, but the values of a and b won't be changed.
The scope of a function is the file in which it is defined (as well as included files),
with the exception of primitive functions, whose scopes are global.
Calls to undefined functions are legal, but will always evaluate to null and result in
a compiler warning.
32
CHAPTER 11
CATC Scripting Language for USBPrimitives
CHAPTER 11:PRIMITIVES
Primitive functions are called similarly to regular functions, but they are implemented outside of the language. Some primitives support multiple types for certain
arguments, but in general, if an argument of the wrong type is supplied, the function
will return null.
Call()
Call( <function_name string>, <arg_list list>)
ParameterMeaningDefault ValueComments
function_name string
arg_list listUsed as the list of parameters in the function call.
Return value
Same as that of the function that is called.
Comments
Calls a function whose name matches the function_name parameter. All scope
rules apply normally. Spaces in the function_name parameter are interpreted as
the ‘_’ (underscore) character since function names cannot contain spaces.
Example
Call("Format", ["the number is %d", 10]);
is equivalent to:
Format("the number is %d", 10);
Format()
Format (<format string>, <value string or integer>)
ParameterMeaningDefault ValueComments
format string
value string or integer
Return value
None.
33
CHAPTER 11
CATC Scripting Language for USBPrimitives
Comments
Format is used to control the way that arguments will print out. The format string
may contain conversion specifications that affect the way in which the arguments
in the value string are returned. Format conversion characters, flag characters, and
field width modifiers are used to define the conversion specifications.
Example
Format("0x%02X", 20);
would yield the string 0x14.
Format can only handle one value at a time, so
Format("%d %d", 20, 30);
would not work properly. Furthermore, types that do not match what is specified in
the format string will yield unpredictable results.
Format Conversion Characters
These are the format conversion characters used in CSL:
CodeTypeOutput
cIntegerCharacter
dIntegerSigned decimal integer.
iIntegerSigned decimal integer
oIntegerUnsigned octal integer
uIntegerUnsigned decimal integer
xIntegerUnsigned hexadecimal integer, using "abcdef."
XIntegerUnsigned hexadecimal integer, using "ABCDEF."
sStringString
Table 11.1: Format Conversion Characters
A conversion specification begins with a percent sign (%) and ends with a conversion character. The following optional items can be included, in order, between the
% and the conversion character to further control argument formatting:
•Flag characters are used to further specify the formatting. There are five flag characters:
•Aminussign(-) will cause an argument to be left-aligned in its field. Without the
minus sign, the default position of the argument is right-aligned.
•A plus sign will insert a plus sign (+) before a positive signed integer. This only works
with the conversion characters
d and i.
34
CHAPTER 11
CATC Scripting Language for USBPrimitives
•A space will insert a space before a positive signed integer. This only works with the
conversion characters
will be ignored.
•A hash mark (#) will prepend a 0 to an octal number when used with the conversion
character
number.
•A zero (0) will pad the field with zeros instead of with spaces.
o.If# is used with x or X, it will prepend 0x or 0X to a hexadecimal
d and i. If both a space and a plus sign are used, the space flag
•Field width specification is a positive integer that defines the field width, in spaces, of the
converted argument. If the number of characters in the argument is smaller than the field
width, then the field is padded with spaces. If the argument has more characters than the
field width has spaces, then the field will expand to accommodate the argument.
GetNBits()
GetNBits (<bit_source list or raw>, <bit_offset
integer>, <bit_count integer>)
ParameterMeaningDefault Value Comments
bit_source list, raw, or
integer
bit_offset integerIndex of bit to
start reading
from
bit_count integerNumber of
bits to read
Can be an integer value (4 bytes) or a list of integers that are interpreted as bytes.
Return value
None.
Comments
Reads bit_count bits from bit_source starting at bit_offset. Will
return null if bit_offset + bit_count exceeds the number of bits in
bit_source.Ifbit_count is 32 or less, the result will be returned as an
integer. Otherwise, the result will be returned in a list format that is the same as the
input format. GetNBits also sets up the bit data source and global bit offset used
by NextNBits and PeekNBits. Note that bits are indexed starting at bit 0.
Example
raw = 'F0F0';# 1111000011110000 binary
result = GetNBits ( raw, 2, 4 );
Trace ( "result = ", result );
The output would be
35
CHAPTER 11
CATC Scripting Language for USBPrimitives
result = C# The result is given in
hexadecimal. The result in binary is 1100.
In the call to GetNBits: starting at bit 2, reads 4 bits (1100), and returns the value
0xC.
NextNBits()
NextNBits (<bit_count integer>)
ParameterMeaningDefault ValueComments
bit_count integer
Return value
None.
Comments
Reads bit_count bits from the data source specified in the last call to
GetNBits, starting after the last bit that the previous call to GetNBits or
NextNBits returned. If called without a previous call to GetNBits, the result is
undefined. Note that bits are indexed starting at bit 0.
In the call to GetNBits: starting at bit 2, reads 4 bits (1100), and returns the value
0xC.
In the first call to NextNBits: starting at bit 6, reads 5 bits (00111), and returns
the value 0x7.
In the second call to NextNBits:startingatbit11(=6+5),reads2bits(10),
and returns the value 0x2.
36
CHAPTER 11
CATC Scripting Language for USBPrimitives
Resolve()
Resolve( <symbol_name string>)
ParameterMeaningDefault ValueComments
symbol_name string
Return value
The value of the symbol. Returns null if the symbol is not found.
Comments
Attempts to resolve the value of a symbol. Can resolve global, constant and local
symbols. Spaces in the symbol_name parameter are interpreted as the ‘_’ (underscore) character since symbol names cannot contain spaces.
Example
a = Resolve( "symbol" );
is equivalent to:
a = symbol;
Trace()
Trace( <arg1 any>, <arg2 any>, ...)
ParameterMeaningDefault ValueComments
arg anyThe number of arguments is variable.
Return value
None.
Comments
The values given to this function are given to the debug console (not in release).
Example
list = ["cat", "dog", "cow"];
Trace("List = ", list, "\n");
would result in the output
List = [cat, dog, cow]
37
CHAPTER 11
CATC Scripting Language for USBPrimitives
38
CHAPTER 12
CATC Scripting Language for USBDecoder Primitives
CHAPTER 12: DECODER
PRIMITIVES
Abort()
Abort()
ParameterMeaningDefault ValueComments
N/A
Return value
An integer that should be passed back to the application unchanged.
Comments
Called when an input context renders the currently pending transaction done, but is
not itself a member of that transaction. An example would be an input transaction
that represents some sort of reset condition that renders all pending transactions
invalid. The input transaction is not consumed by this action and will go on to be
considered for other pending transactions.
Example
if ( IsReset )
return Abort();
AddCell()
AddCell(<name string>, <value string>, <description
string or null>, <color integer or list>,<additional_info any>)
ParameterMeaningDefault ValueComments
name stringDisplays in the name field of the cell.
value stringDisplays in the value field of the cell.
description string or nullDisplays in tool tip.
color integer or listIf not speci-
fied, a default
color is used
Color can be specified as either a packed color
value in an integer, or as an array of RGB values
ranging from 0-255. Displays in the name field
of the cell.
39
CHAPTER 12
CATC Scripting Language for USBDecoder Primitives
ParameterMeaningDefault ValueComments
additional_info anyUsed to create special cells or to modify cell
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
Adds a display cell to the current output context. Cells are displayed in the order
that they are added. The name and value strings are displayed directly in the cell.
Example
# Create a regular cell named Normal with a value
"Cell" and tool tip "Normal cell":
AddCell( "Normal", "Value1", "Normal cell" );
# Use the _MONOCOLOR value in the additional_info
parameter to create a cell with a color value of
0x881122 in both the name and value fields:
# Use the [_FIXEDWIDTH, w] value to create a cell with
a fixed width of 20 in conjuction with the error value
to create a fixed width cell with a red value field:
Creates an expandable/collapsible cell for viewing raw data such as data payloads.
Data can be raw bytes, an integer, or a list. If an integer is used, it will be interpreted
as 4 bytes of data. Specifying _BYTES or _DWORDS in an additional_info
field will force data to be interpreted as bytes or quadlets. _COLLAPSED,
_EXPANDED, _HIDDEN and _SHOWN are all interpreted the same is in a regular
AddCell call.
41
CHAPTER 12
CATC Scripting Language for USBDecoder Primitives
Example
# Creates a data cell with 2 dwords (32-bit integers)
of data.
AddDataCell( '0123456789ABCDEF', _DWORDS );
# Creates a data cell with 4 bytes.Integer data
values are always interpreted as 32 bits of data.
AddDataCell( 0x11223344, _BYTES );
The output of the example is:
Figure 12-2: Example output for AddDataCell
AddEvent()
AddEvent(<Group string>, <Value string>)
ParameterMeaningDefault ValueComments
Group stringThenameof
the group
Va l ue stringA value that
will be
associated
with the group
Return value
None.
Comments
Events are used for transaction searching and for transaction summary. This
function is only effective when called during the ProcessData() phase of
decoding. Event groups and values are stored globally for transaction levels and
new ones are created as they are encountered. Each transaction contains information as to which events were associated with it.
Corresponds to the name of a field that might be
encountered while decoding.
Corresponds to a field value that might be
encountered while parsing.
42
CHAPTER 12
CATC Scripting Language for USBDecoder Primitives
AddSeparator()
AddSeparator(<additional_info any>, ...)
ParameterMeaningDefault ValueComments
additional_info anyUsed to create special cells or to modify cell
attributes. The values are predefined constants.
Possible values are:
_COLLAPSED
_EXPANDED
_HIDDEN
_SHOWN (default)
Return value
None.
Comments
Creates a separator cell. _COLLAPSED, _EXPANDED, _HIDDEN,and_SHOWN
are all interpreted the same is in a regular AddCell call.
Example
AddCell( "Stuff", "Things" );
# AddSeparator adds a space between the previous and
subsequent cells.
AddSeparator();
AddCell( "More stuff", "More things" );
The output of the example is:
Figure 12-3: Separator cell
example
BeginCellBlock()
BeginCellBlock(<name string>, <value string>,
<description string or null>, <color integer or list>,
<additional_info any>)
ParameterMeaningDefault ValueComments
name stringDisplays in the name field of the cell.
43
CHAPTER 12
CATC Scripting Language for USBDecoder Primitives
ParameterMeaningDefault ValueComments
value stringDisplays in the value field of the cell.
description string or nullDisplays in tool tip.
color integer or listIf not speci-
fied, a default
color is used
additional_info anyUsed to create special cells or to modify cell
Color can be specified as either a packed color
value in an integer, or as an array of RGB values
ranging from 0-255. Displays in the name field
of the cell.
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
Begins a cell block and adds a block header cell. This is a special cell that can be
collapsed and expanded. The collapsed/expanded state of this cell affects cells in
the group according to their _COLLAPSED, _EXPANDED attributes. All calls to
AddCell after a call to BeginCellBlock() will put the new cells into this
group until a call to EndCellBlock is made.
Cell blocks can be nested.
Example
# Begin the 'red' group.For clarity these cells will
be red:
Figure 12-5: Example output for BeginCellBlock with red group
expanded and blue group collapsed
Figure 12-6: Example output for BeginCellBlock with red group expanded
and blue group expanded
Complete()
Complete()
ParameterMeaningDefault ValueComments
Return value
An integer that should be passed back to the application unchanged.
Comments
This should be called when it has been decided that an input context has been
accepted into a transaction, and that the transaction is complete. The return value
of this function should be passed back to the application from the ProcessData
function. This function could be used to associate the input context with the output
context.
Example
if ( done )
return Complete();
46
CHAPTER 12
CATC Scripting Language for USBDecoder Primitives
EndCellBlock()
EndCellBlock()
ParameterMeaningDefault ValueComments
Return value
None.
Comments
Ends a cell block that was started with
BeginCellBlock().
Example
See BeginCellBlock().
GetBitOffset()
GetBitOffset()
ParameterMeaningDefault ValueComments
N/A
Return value
None.
Comments
Returns the current bit offset that is used in NextNBits or PeekNBits.
Reads bit_count bits from the data source. The difference between
PeekNBits and NextNBits is that PeekNBits does not advance the global
bit offset. PeekNBits can be used to make decisions about how to parse the next
fields without affecting subsequent calls to NextNBits.IfPeekNBits is called
without a prior call to GetNBits, the result is undefined. Note that bits are indexed
starting at bit 0.
In the call to GetNBits: starting at bit 2, reads 4 bits (1100), and returns the value
0xC.
In the call to PeekNBits: starting at bit 6, reads 5 bits (00111), and returns the
value 0x7.
In the call to NextNBits: starting at bit 6, reads 2 bits (00), and returns the value
0x0.
Pending()
Pending()
ParameterMeaningDefault ValueComments
48
CHAPTER 12
CATC Scripting Language for USBDecoder Primitives
Return value
An integer that should be passed back to the application unchanged.
Comments
This should be called when it has been decided that an input context has been
accepted into a transaction, but that the transaction still requires further input to be
complete. This function could be used to associate input contexts with the output
context. The return value of this function should be returned to the application in
the ProcessData function.
Example
if ( done )
return Complete();
else return Pending();
Reject()
Reject()
ParameterMeaningDefault ValueComments
Return value
An integer that should be passed back to the application unchanged.
Comments
Called when it is decided that the input context does not meet the criteria for being
a part of the current transaction. The output context should not be modified before
this decision is made. The return value of this function should be returned by the
ProcessData function.
Example
if ( UnknownValue )
return Reject();
49
CHAPTER 12
CATC Scripting Language for USBDecoder Primitives
50
CHAPTER 13
CATC Scripting Language for USBModules
CHAPTER 13: MODULES
Modules are a collection of functions and global data dedicated to decoding a
certain type of transaction. Each module consists of one primary file (.dec), and
possibly several included files (.inc).
Module Functions
Three functions are used as entry-points into a decoding module. They are called
by the application and are used both in the initial transaction decoding phase, and
each time that a transaction needs to be displayed.
ProcessData()
Called repeatedly with input contexts representing transactions of the specified
input types. Decides if input transaction is a member of this transaction, or if it
begins a new transaction. This function will be called first using incomplete output
transactions. If the input transaction is not accepted into any of the pending transactions, it will be called with an empty output transaction to see if it starts a new
transaction.
CollectData()
Called with each input transaction that was previously accepted by the function
ProcessData. Generates all output context data that would be required for input
into a higher level transaction.
BuildCellList()
Called with the output context generated by the call to CollectData, and no
input context. This function is responsible for adding display cells based on the data
collected by CollectData.
Note that there is some flexibility in the use of these functions. For example, if it is
easier for a particular protocol to build cells in CollectData, cells could be
generated there, and BuildCellList could be left empty. Another approach
wouldbetohaveProcessData do everything (generate output data, and build
cell lists) and then implement CollectData as a pass-thru to ProcessData.
This will be less efficient in the decoding phase but may reduce some repetition of
code. These decisions are dependent on the protocol to be decoded.
51
CHAPTER 13
CATC Scripting Language for USBModules
Module Data
There are several standard global variables that should be defined in a module
which are queried by the application to figure out what the module is supposed to
do.
ModuleType
Required. A string describing the role of the script. Currently, only
Transaction Decoder and DataBlock Decoder are valid.
Required. A string label describing the output of the script. Example : AVC
Transaction
Example
set OutputType = "AV/C Transaction";
InputType
Required. A string label describing the input to the script. Input and output types
should be matched by the application in order to decide which modules to invoke
on which contexts.
Example
set InputType = "1394 Transaction";
LevelName
Optional. A string that names this decoder.
Example
set LevelName = "AV/C Test Transactions";
DecoderDesc
Optional. A string that describes this decoder. Displays as a toolbar icon tool tip.
Example
set DecoderDesc = "View test transactions";
52
CHAPTER 13
CATC Scripting Language for USBModules
Icon
Optional. File name of an icon to display on the toolbar. Must be a 19x19 pixel
bitmap file.
Example
set Icon = "bitmap.bmp";
53
CHAPTER 13
CATC Scripting Language for USBModules
54
CHAPTER 14
CATC Scripting Language for USBUSB Decoders
CHAPTER 14: USB DECODERS
Decoding scripts for the CATC USB Analyzers can now be written in the new
CATC Script Decoding Language. The document describing this decoding
language is included with the CATC software on the CD, and also online.
USBTracer, USBMobile, and USB Advisor ship with decoder scripts for many of
the classes and their attributes. These files are located in the USBTracer
\Scripts directory (for example). Users may edit the decoder scripts or create
new scripts to accommodate specific development needs, especially decoding of
vendor- and application-specific classes and attributes.
This chapter discusses the purposes of the USBTracer decoder files, along with the
common constants, global variables, and functions that make up the USBTracer
Decoding API. The procedures for adding attribute decoders for existing management classes and for creating new management class decoders are provided as well.
Decoder Files
USBTracer decoders are used to decode packets with vendor-specific data or other
custom information so that the custom content can be displayed as a CATC Trace
in USBTracer. The view settings in the scripts may be edited to either reveal or hide
particular fields when the header cells are expanded or collapsed. For instance, it
may be desirable to have a field visible even when its header cell is collapsed; on
the other hand, cells can also be defined so that they are revealed only when the
header cell is expanded.
In addition to displaying decoded custom content as data as a trace, the decoder
scripts create a special View window that presents the decoded data in a text format.
The window is opened by left-clicking on any cell in the trace to access the pop-up
View menu and then selecting the “View fields” option.
Script Decoding Mechanisms
The older script decoding mechanism is still supported, and the scripts are now
stored in a directory called Legacy in the Scripts directory. The older mechanism
is still used for many of the decoding types, such as the Standard descriptors. The
scripts for it are the same as those used on USB Chief, the previous generation USB
Analyzer. The newer decoding scripts are NOT compatible with USB Chief.
The new script language can be implemented using 2 different methods. These are
Distinguished in the scripts by the script variable UsbScriptDecodeType.
55
CHAPTER 14
CATC Scripting Language for USBUSB Decoders
When UsbScriptDecodeType=1, the decoding for the colored fields of the trace
display are handled separately from the decoding for the text-based decoding seen
in the decoding dialogs. If this variable is not initialized in a .dec file, this is the
default behavior. The Field Displays are handled through the normal ProcessDa-ta() script function, whereas the text is handled through either the DataDecode()
or RequestDecode() functions (depending on which one you are trying to decode).
Yo u c an
build up formatted output text in a manner which looks a lot like the older script
mechanism this way. It does require some redundant code, however, since this
creates a separate execution path in the script. When using this method for creating
text, the user is essentially building up a text stream which will be retrieved for
display in the Decode Dialog or as a tooltip. An example of this usage is found in
the files in the HubClass directory under Scripts. For comparison with the old
decoding method, you can look at the old hub decoding scripts in the Scripts/
Legacy/Replaced directory. It contains the old version of the Hub and Bluetooth
HCI decoders which have been replaced with new Script Decoder based files.
An alternative method (and the one used for all the MassStorage decoders) is when
UsbScriptDecodeType=2. In these files, there is one main execution path through
ProcessData() which outputs either colored field cells or formatted text, depending
on a context variable named PrepareFldsForDlg. This is passed in as a 0 by the
software when the decoding is occurring in the normal Trace View, and is set to 1
when being called in situations where text decoding is desired by the software. This
is described in detail in earlier chapters. The advantage of this mechanism is that it
is easier to program and there is less redundancy of code. The disadvantage is that
the format of the output is fixed and not flexible. It is currently implemented to
output the decoding fields in simple columns, and the comments/tooltip strings are
provided in the last column whenever the trace view for the transfer is shown in
Expanded mode. In other words, it is not as pretty, but at least you can select the
text and copy it to an editor, etc.
Reserved Variable and Constant Names
The following names are reserved for use in the Script Decoding Files. (These are
in addition to the ones described in earlier chapters). These are case-sensitive, so
pay attention to the capitalization.
UsbDecodeType
Va l ue s: “Endpoint” or “Request”. Used to distinguish whether the .dec file
is to be used for endpoint decoding or for decoding control transfers (The
ones that start with a Setup packet).
UsbReqType
Va l ue s: “Class” or “Vendor”. Used to distinguish the request types for
decoding.
56
CHAPTER 14
CATC Scripting Language for USBUSB Decoders
UsbEndpType
Va l ue s: “Bulk” or “Interrupt”. Used to distinguish transfer types of the
endpoints.
UsbEndpDir
Va l ue s: “In” or “Out”. Used to distinguish the endpoint direction. Any
endpoint can provide 2 pipes: one in each direction.
UsbMaxPktSize
Value: The maximum packet size allowed for this endpoint/direction combination. This will be used to help decode the file.
UsbMaxXferSize
Value: The maximum transfer size allowed for this endpoint/direction
combination. This will be used to help decode the file.
UsbMaxXferDecodeSize
Value: The maximum portion of the transfer size that will be examined for
possible decoding. If, for example, each transfer had a 25 byte header at
the beginning, this value could be used to improve the speed at which the
decoding occurs, since the software would only pass the first N bytes to the
decoding logic. In cases where there might be a trailer, the value would
have to be equal to the maximum transfer length to insure that the last bytes
would be examined.
UsbClassCode
Value: The value assigned by the USB IF for this particular Class. For
example, Mass Storage is 8 and the Hub Class is 9.
UsbSubClass
Value: If defined, it is specified by the Class Specification. For example,
the Mass Storage Class provides for SubClass 4 for UFI (USB Floppy
Interface) and SubClass 6 for Transparent SCSI.
UsbProtocol
Value: If defined, it is specified by the Class Specification. For example,
57
CHAPTER 14
CATC Scripting Language for USBUSB Decoders
the Mass Storage Class provides for Protocol 0x50 for Bulk-Only Transport, and Protocol 0 for CBI (Control/Bulk/Interrupt) Transport.
UsbVendorId
Value: If defined, it is provided for by the Vendor as registered with the
USB IF. This is used in the case where you have vendor-specific decoding.
For example, if CATC created a file to decode it’s communication for it’s
analyzer’s USB connection, we would use our USB-IF identification number of 1059.
UsbProductId
Value: If defined, it is provided for by the Vendor. Used to distinguish
decoding based on product-specific differences.
UsbEndpId
Value: You must assign a unique value between 1 and 127 to differentiate
endpoint decoders used for the same Class/Vendor group. This value has
nothing to do with the actual Endpoint value the device will use for this
particular decoder, it is merely a mechanism used by the software to avoid
confusion over the mapping of an endpoint decoder to a particular instance
of an endpoint.
UsbIgnoreSetupData
Value: 0(Default) means that the data being passed to this request decoder
should include the 8 bytes of the Setup Packet. If the value is 1, the data
passed to this decoder starts with that found in the first DATA packet. This
is used to provide compatibility with decoders such as the Bluetooth HCI
decoder, which is built to be compatible with other non-USB CATC products which don’t have an 8 byte ‘header’. If this variable is not declared,
the default behavior is applied by Software: the 8 byte header is included.
UsbLsbToMsb
Value: 0(Default) means the data passed to this decoder should have its
most significant bit in bit position 7 and it’s least significant bit in bit posi-
tion 0. If 1, the opposite is true: the data is expected to be LsbToMsb. If
this variable is not declared, the default (0) behavior is applied by Software: the bytes are passed as MsbToLsb, otherwise known as “normal”.
58
CHAPTER 14
CATC Scripting Language for USBUSB Decoders
UsbReqStr
Value: This will contain the string you build up for the Request portion of
the Request text decoding when you have selected “UsbDecodeType =1”.
This string will be displayed in the left-hand pane of the text decode dialog.
UsbDescTooltipStr
Value: This will contain the string you build up for the Descriptor portion
of the Request text decoding when you have selected “UsbDecodeType=1”. This string should only contain an amount appropriate for displaying
as a ToolTip.
UsbDataDecodeStr
Value: This will contain the string you build up for the Data portion of the
Endpoint text decoding, or the Descriptor portion of a Request decoding
when you have selected “UsbDecodeType =1”. This string will be dis-
played in the text decoding dialog. If this is an endpoint decode, it will be
displayed in the only pane of the dialog. If this is a request decode, it will
display in the right-hand side pane of the dialog.
UsbDecHdrType
Value: Used to pass explicit information to the decoder to help decoding
where the normal data byte stream does not contain enough information or
context to allow it to be decoded all by itself. Currently, only the value 2 is
used in the case of Mass Storage Decoding. This tells the software that this
decoder needs the SCSI or UFI Opcode of the previous transfer to help
determine if this is supposed to be a response to a SCSI/UFI Command that
was just sent. Without this, it would be impractical to distinguish a normal
READ data stream from a SCSI/UFI control request response. This item
requires explicit support in the software, so you cannot use it arbitrarily.
UsbDecHdrLen
Value: This specifies the length (up to 8 bytes) of additional context informationthatwillbepassedinconjunctionwiththeuseof"UsbDecH-drLen". This item requires explicit support in the software, so you cannot
use it arbitrarily. It is currently only used for Mass Storage decode, and in
that case has a value of 1.
59
CHAPTER 14
CATC Scripting Language for USBUSB Decoders
UsbDecExtraInfoBytePos
Value: The byte offset in this transfer where the information byte potentially used
for decoding the next transfer exists. For example, in CBI-UFI decoding, the byte
at offset 8 contains the UFI Opcode. For Bulk-Only SCSI, the opcode is at offset
15. In both cases, this byte can be used to identify that a subsequent Transfer
contains the response data to an issued command. This item requires explicit
support in the software, so you cannot use it arbitrarily.
UsbScriptDecodeType
Value: 1(default) for explicit text decoding, 2 for combined text/field
decoding as described in earlier chapters.
Reserved Parameter Strings (Used as values in the above string declarations):
Request
Endpoint
Class
Ven do r
Bulk
Interrupt
In
Out
val=0 # global buffer for keeping temporary values
of any type.
str = ""# global buffer for keeping temporary values
of presumedly string type.
base_tooltip = ""# global buffer for keeping
temporary values of presumedly parts of tooltips.
ViewAll = 0# global variable that keeps View All
fields parameter of currently decoded attribute -this variable is the set attribute decoder responsible
for decoding of the current attribute.
HideAll = 0# global variable that keeps Hide All
fields parameter of currently decoded attribute -this variable is the set attribute decoder responsible
for decoding of the current attribute.
Prefix = ""# global variable that keeps the prefix,
which is a kind of identifier for the decoder
responsible for decoding of the current attribute.
VS = []# global variable that stores the View setting
of the cell currently being shown. It can be used only
as a list of two values: [ show_in collapsed, show in
expanded ]. When show_in collapsed > 0, it means that
the current cell will be shown in collapsed state;
otherwise, it will be hidden. show in expanded means
the same, but for expanded state only.
# The following variables are specific to dialog view:
61
CHAPTER 14
CATC Scripting Language for USBUSB Decoders
set Global_BitField_offset = 0;# global variable
that contains the offset, in bits, from the beginning
of packet for beginning of current attribute. Roughly
speaking, it is the entry point from which an
attribute decoder starts decoding.
set BitCurrentFieldOffset = 0;# global variable that
contains the offset, in bits, from the starting point
of decoding for the current field inside of the
decoder.
set BitCurrentFieldLength = 0;# the length, in bits,
of the currently decoded field.
Common Functions
Functions found in DecoderTools2.inc
These are the most commonly-used functions from DecoderTools2.inc.
RGB()
RGB(r, g, b)
ParameterMeaningDefault ValueComments
r integerred value
g integergreen value
b integerblue value
Comments
Used to define a color based on red, green, and blue values.
Example
RGB(255, 255, 255); #white
SaveFieldSettings()
SaveFieldSettings()
ParameterMeaningDefault ValueComments
N/A
62
CHAPTER 14
CATC Scripting Language for USBUSB Decoders
Comments
Saves the global field settings. Can be used in conjunction with
RestoreFieldSettings() to show one attribute inside another.
Restores the global field settings. Can be used in conjunction with
SaveFieldSettings() to show one attribute inside another.
Example
See “SaveFieldSettings()” on page 62.
Find()
Find(table, table_key)
ParameterMeaningDefault ValueComments
table
table_key string
Comments
Finds a string in the table by a key value. If the key is not found, the first string is
returned.
63
CHAPTER 14
CATC Scripting Language for USBUSB Decoders
Example
val = Find(AttrIDValue_Table, PacketType);
ShowDataBlock()
ShowDataBlock(len, no_cells)
ParameterMeaningDefault ValueComments
lenLength of Dat-
aBlock
no_cellsNo cells will
be drawn
If this parameter is set, then data cells are not
shown.
Comments
Used to display a DataBlock.
Example
ShowDataBlock(40, !VEX_MyDataBlock[in.Expanded]);
AddDecSeparator()
AddDecSeparator()
ParameterMeaningDefault ValueComments
N/A
Comments
Used to create a separator cell.
Example
AddDecSeparator();
Warning()
Warning(text, tooltip)
ParameterMeaningDefault ValueComments
text stringThis text is displayed in the warning cell.
tooltip stringThis text is displayed in the tooltip.
Comments
Creates a warning cell.
64
CHAPTER 14
CATC Scripting Language for USBUSB Decoders
Example
if(in.Expanded) Warning("Bad value", "This is example
of Warning-cell.");
WarningForDlg()
WarningForDlg(text, tooltip)
ParameterMeaningDefault ValueComments
text stringWarning text.
tooltip stringTooltip text.
Comments
Creates a warning for dialog view.
Example
WarningForDlg(Format("Not correct AttrM(0x%X)",
AttModifier),"Valid values for Attribute Modifier as
a pointer to a block of 8 GUIDs\n" + "are from 0 to
31." );
AddWarningTooltip()
AddWarningTooltip(error_tooltip)
ParameterMeaningDefault ValueComments
error_tooltip
Comments
Adds a special warning or error description part to a tooltip string.
Makes a check for next bits_reserved bits that are reserved and should be set
to zero. If the bits are not zero, a corresponding warning cell will be shown in
expanded state.
Example
ReservedCheck( reserved_bits );
IncFieldOffset()
IncFieldOffset(len)
ParameterMeaningDefault ValueComments
len
Comments
Increments the field offset by designated length (len) and sets the field length
variable equal to len. This is useful when it’s not possible to obtain a field value
using only one GetNBits_ or NextNBits_ command.
addparamUsed to create special cells or to modify cell
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
_ERROR: creates a cell with a red value field to
indicate an error.
Comments
Prepares the field for dialog view. Writes passed data to out.FieldList,using
current values of field offset and field length.
addparamUsed to create special cells or to modify cell
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
_ERROR: creates a cell with a red value field to
indicate an error.
67
CHAPTER 14
CATC Scripting Language for USBUSB Decoders
Comments
ZeroField means that the field to be added to out.FieldsList is not a data
field. Rather, it is an additional field such as a caption or a separator.
addparamUsed to create special cells or to modify cell
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
_ERROR: creates a cell with a red value field to
indicate an error.
Comments
Writes passed data to out.FieldList, using passed values of field offset and
field length.
addparamUsed to create special cells or to modify cell
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
_ERROR: creates a cell with a red value field to
indicate an error.
Comments
Writes passed data to out.FieldList as a special field called ‘CAPTION’.
Example
AddCaptionToDlg("Common USB Header", caption + " " +
text, tooltip);
AddStringToDlg()
AddStringToDlg(caption, text, tooltip, addparam)
ParameterMeaningDefault ValueComments
caption
text
tooltip
addparamUsed to create special cells or to modify cell
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
_ERROR: creates a cell with a red value field to
indicate an error.
Comments
Writes passed data to out.FieldList as a special field called ‘STRING’.
Example
AddStringToDlg(caption , text, tooltip);
AddDataBlockToDlg()
AddDataBlockToDlg(len)
ParameterMeaningDefault ValueComments
len
Comments
Makes a special record about DataBlock with length equal to len for dialog view.
69
CHAPTER 14
CATC Scripting Language for USBUSB Decoders
Example
AddDataBlockToDlg(72);
CheckBadDataLength()
CheckBadDataLength()
ParameterMeaningDefault ValueComments
N/A
Comments
Checks offset from beginning of data payload for packet with bad data length and
sets the current field color to the error color when the offset exceeds the length of
thedatapayload.
Example
CheckBadDataLength();
NextNBits_()
NextNBits_(next_n_bits)
ParameterMeaningDefault ValueComments
next_n_bits
Comments
This is a redefinition of the NextNBits primitive which increments field offset
and field length.
Example
NextNBits_(8);
PeekNBits_()
PeekNBits_(next_n_bits)
ParameterMeaningDefault ValueComments
next_n_bits
Comments
This is a redefinition of the PeekNBits primitive which increments field offset
and field length.
70
CHAPTER 14
CATC Scripting Language for USBUSB Decoders
Example
PeekNBits_(16);
GetNBits_()
GetNBits_(offset, len)
ParameterMeaningDefault ValueComments
offset
length
Comments
This is a redefinition of the GetNBits primitive which increments field offset and
field length.
Example
GetNBits_(640, 4);
GetRangeBits()
GetRangeBits(start_bit, end_bit, source)
ParameterMeaningDefault ValueComments
start_bit
end_bit
source integer
Comments
Extracts a range of bits from source starting from start_bit and ending at
end_bit. Most Significant Bit —> Least Significant Bit order is used here.
Example
GetRangeBits(10, 15, peek_value);
GetBit()
GetBit(bit_needed, source)
ParameterMeaningDefault ValueComments
bit_needed
source integer
71
CHAPTER 14
CATC Scripting Language for USBUSB Decoders
Comments
Extracts a bit (bit_needed)fromsource.
Example
GetBit(3, peek_value);
AddCaptionCell()
AddCaptionCell(caption, text, tooltip, addparam)
ParameterMeaningDefault ValueComments
captionDisplays in the name field of the cell.
textDisplays in the value field of the cell.
tooltipDisplays in tooltip.
addparamUsed to create special cells or to modify cell
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
_ERROR: creates a cell with a red value field to
indicate an error.
_WARNING: creates a cell with a yellow value
field to indicate a warning.
_MONOFIELD: cell consists of only a name
field.
_MONOCOLOR: creates a cell with the same
color in both fields.
_FIXEDWIDTH: creates a cell with a fixed,
specified width.
Comments
Used to draw a special caption cell. Note: all Add...Cell functions use colors as
defined in the global variable FieldColor.
Example
AddCaptionCell(VNDR_DATA_CAP, "VendorExample",
"Example of vendor-attribute decoder.\n\n" + "This
attribute is completely fictive and\n" + "was
contemplated for example ONLY.\n\n" + "We use
AddCaptionCell() for depiction of attribute
captions." + "\r" + "Use '\\r' - as delimiter to add
extended part of your\n" + "tooltip");
72
CHAPTER 14
CATC Scripting Language for USBUSB Decoders
AddPayLoadCell()
AddPayLoadCell(caption, text, tooltip, addparam)
ParameterMeaningDefault ValueComments
captionDisplays in the name field of the cell.
textDisplays in the value field of the cell.
tooltipDisplays in tooltip.
addparamUsed to create special cells or to modify cell
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
_ERROR: creates a cell with a red value field to
indicate an error.
_WARNING: creates a cell with a yellow value
field to indicate a warning.
_MONOFIELD: cell consists of only a name
field.
_MONOCOLOR: creates a cell with the same
color in both fields.
_FIXEDWIDTH: creates a cell with a fixed,
specified width.
Comments
Draws a payload cell. Note: all Add...Cell functions use colors as defined in the
global variable FieldColor.
Example
AddPayLoadCell("Field_1", "Value:"+
Format("0x%04X", NextNBits_(16)), "Field 1\n" + "View
setting for this field is set to show field\n" + "both
in collapsed and expanded states.\n\n" + "We use
AddPayLoadCell() to depict this cell.");
addparamUsed to create special cells or to modify cell
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
_ERROR: creates a cell with a red value field to
indicate an error.
_WARNING: creates a cell with a yellow value
field to indicate a warning.
_MONOFIELD: cell consists of only a name
field.
_MONOCOLOR: creates a cell with the same
color in both fields.
_FIXEDWIDTH: creates a cell with a fixed,
specified width.
Comments
Draws a monocolor cell that is similar to the usual payload cell except that both the
upper and lower parts of the cell are the same color. Note: all Add...Cell
functions use colors as defined in the global variable FieldColor.
Example
AddPayLoadCellMono("MonoColorField", text, tooltip +
"\n\nWe use AddPayLoadCellMono() to depict this
cell.\n" + "This monocolor cell is similar to usual
payload cell but both upper and\n" + "lower parts of
Cell are depicted by the same color defined for this
attribute\n" + "in file MAD_colors.inc");
addparamUsed to create special cells or to modify cell
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
_ERROR: creates a cell with a red value field to
indicate an error.
_WARNING: creates a cell with a yellow value
field to indicate a warning.
_MONOFIELD: cell consists of only a name
field.
_MONOCOLOR: creates a cell with the same
color in both fields.
_FIXEDWIDTH: creates a cell with a fixed,
specified width.
Comments
Used to begin new group of cells and a table in dialog view that allows the tooltip
to be shown below a table caption. Note: all Add...Cell functions use colors as
defined in the global variable FieldColor.
Example
AddPLCellMonoStr("CellMonoStr", Format("%d",
NextNBits_(8)), "CellMonoStr.\n\n" + "The
AddPLCellMonoStr function is used to begin new group
of cells\n" + "and table in dialog view allowing
tooltip to be shown below\n" + "a caption of the
table.");
addparamUsed to create special cells or to modify cell
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
_ERROR: creates a cell with a red value field to
indicate an error.
_WARNING: creates a cell with a yellow value
field to indicate a warning.
_MONOFIELD: cell consists of only a name
field.
_MONOCOLOR: creates a cell with the same
color in both fields.
_FIXEDWIDTH: creates a cell with a fixed,
specified width.
Comments
Creates a monocolored cell. It is intended to be used to start a new group of cells
and table in dialog view. Note: all Add...Cell functions use colors as defined in
the global variable FieldColor.
Example
AddPLCellMonoCap("DiagData", "->", "Vendor specific
diagnostic information.\n" +
"Format is not defined by USB specification.");
addparamUsed to create special cells or to modify cell
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
_ERROR: creates a cell with a red value field to
indicate an error.
_WARNING: creates a cell with a yellow value
field to indicate a warning.
_MONOFIELD: cell consists of only a name
field.
_MONOCOLOR: creates a cell with the same
color in both fields.
_FIXEDWIDTH: creates a cell with a fixed,
specified width.
76
CHAPTER 14
CATC Scripting Language for USBUSB Decoders
Comments
Creates a monocolored cell. It is intended to be used to start a new group of cells
but doesn’t create a table in dialog view. Note: all Add...Cell functions use
colors as defined in the global variable FieldColor.
addparamUsed to create special cells or to modify cell
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
_ERROR: creates a cell with a red value field to
indicate an error.
_WARNING: creates a cell with a yellow value
field to indicate a warning.
_MONOFIELD: cell consists of only a name
field.
_MONOCOLOR: creates a cell with the same
color in both fields.
_FIXEDWIDTH: creates a cell with a fixed,
specified width.
Comments
A ‘simple’ payload cell does not respond to view settings. It is always hidden when
collapsed and always shown when expanded. Note: all Add...Cell functions use
colors as defined in the global variable FieldColor.
Example
AddSimplePLCell("Field 6", "Value:"+
Format("0x%01X", NextNBits_(8)), "Field 6\n\n" +
"Here we use AddSimplePLCell for showing field.\n" +
"The ...SimpleCell-functions don't care about view
settings for the field.\n" + "They DON'T show cell in
collapsed state but DO show in expanded state.");
addparamUsed to create special cells or to modify cell
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
_ERROR: creates a cell with a red value field to
indicate an error.
_WARNING: creates a cell with a yellow value
field to indicate a warning.
_MONOFIELD: cell consists of only a name
field.
_MONOCOLOR: creates a cell with the same
color in both fields.
_FIXEDWIDTH: creates a cell with a fixed,
specified width.
Comments
A ‘simple’ payload cell does not respond to view settings. It is always hidden when
collapsed and always shown when expanded. Note: all Add...Cell functions use
colors as defined in the global variable FieldColor.
Example
AddSimpleCellMonoCap("Private", "Data", "This block
contains private data.\n\n" + "This is an example of
datablock.");
AddBlockPLCell()
AddBlockPLCell(caption, text, tooltip, addparam)
ParameterMeaningDefault ValueComments
captionDisplays in the name field of the cell.
textDisplays in the value field of the cell.
tooltipDisplays in tooltip.
78
CHAPTER 14
CATC Scripting Language for USBUSB Decoders
ParameterMeaningDefault ValueComments
addparamUsed to create special cells or to modify cell
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
_ERROR: creates a cell with a red value field to
indicate an error.
_WARNING: creates a cell with a yellow value
field to indicate a warning.
_MONOFIELD: cell consists of only a name
field.
_MONOCOLOR: creates a cell with the same
color in both fields.
_FIXEDWIDTH: creates a cell with a fixed,
specified width.
Comments
Used instead of AddPayLoadCell() for cells in group. ‘Block’ payload cells
use view settings contained in global view setting variable VS. This way, one view
settingcanbeappliedtoablockofcells.Note:allAdd...Cell functions use
colors as defined in the global variable FieldColor.
Example
AddBlockPLCell("Group Field_1", "Value : " +
Format("0x%04X", NextNBits_(16)), "Block Group Field
1" + "\n\nWe use AddBlockPLCell() to depict this
cell.");
addparamUsed to create special cells or to modify cell
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
_ERROR: creates a cell with a red value field to
indicate an error.
_WARNING: creates a cell with a yellow value
field to indicate a warning.
_MONOFIELD: cell consists of only a name
field.
_MONOCOLOR: creates a cell with the same
color in both fields.
_FIXEDWIDTH: creates a cell with a fixed,
specified width.
Comments
‘Block’ payload cells use view settings contained in global view setting variable
VS. This way, one view setting can be applied to a block of cells. Note: all
Add...Cell functions use colors as defined in the global variable
FieldColor.
Example
AddBlockPLCellMonoStr("BM class Notice", str,
"This block describes a BaseBoard Management classspecific part of Notice.\n\n" +
GetBASE_NTooltip());
addparamUsed to create special cells or to modify cell
attributes. The values are predefined constants,
and zero or more of them may be used at one
time. Possible values are:
_ERROR: creates a cell with a red value field to
indicate an error.
_WARNING: creates a cell with a yellow value
field to indicate a warning.
_MONOFIELD: cell consists of only a name
field.
_MONOCOLOR: creates a cell with the same
color in both fields.
_FIXEDWIDTH: creates a cell with a fixed,
specified width.
Comments
Used to start a new group of cells and table in dialog view, similarly to
AddPLCellMonoCap(), except that ‘Block’ payload cells use view settings
contained in a global view setting variable VS. This way, one view setting can be
applied to a block of cells. Note: all Add...Cell functions use colors as defined
in the global variable FieldColor.
Used to make a common check of reserved bits while taking into account the view
settings. If these bits are not zero, a corresponding warning cell will be shown in the
expanded state. Note: only up to 32 bits should be passed to this function.
Example
PLReservedCheck(32);
PLReservedCheck(8);
UnsignedCompare()
UnsignedCompare(op1, op2)
ParameterMeaningDefault ValueComments
op1Operand
op2Operand
Comments
This function returns difference between integer values and considers them to be
unsigned values. So, the value 0xFFFFFFFF is -1 and less than 0 in logical conditions, but as an unsigned integer it is so much bigger than 0. Use this function in
places where you want integer values to be thought of as unsigned.