100% found this document useful (2 votes)
5K views

CAPL CheatSheet

The document discusses program structure and data types in CAPL including global variables, events, comments, own types, and messages. It covers basic syntax, operators, conditional statements, and switching. Fundamental data types include integers, floats, characters, messages, and associative fields. CAPL is event-driven and uses handlers for events like signals, timers, and messages.

Uploaded by

emilfrancu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
100% found this document useful (2 votes)
5K views

CAPL CheatSheet

The document discusses program structure and data types in CAPL including global variables, events, comments, own types, and messages. It covers basic syntax, operators, conditional statements, and switching. Fundamental data types include integers, floats, characters, messages, and associative fields. CAPL is event-driven and uses handlers for events like signals, timers, and messages.

Uploaded by

emilfrancu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

CAPL Cheat Sheet CAN

Program Structure and Data Types Program Structure and Data Types - continued C-Syntax

Parts marked with *) are not available for CANalyzer. Access to struct members: Operators
gMyStruct.aLong = 22; a = 23 + b; add and assign
Including other Files textually (CAPL Include)
Includes Constants */- multiplication, division, subtraction
{ const <type> = <val>; r = 37 % 7; modulo division for integer, here: 2
#include "MySource.cin" a++; b--; increment or decrement an integer type
} Events c+=22.0; increment and assignment
CAPL is 100% event driven, event handler syntax: -= *= /= decrement, multiplication, division and assignment
Global Variables, <type> = data type on <event type> [additional parameter]
variables { a==b comparison operator „equal“
{ // variable declaration < <= > >= ! = other comparison operators
<type> myVar[=val]; // elementary // program code ! (a<7) && (b>20) logical not(!), and (&&)
<type> myArray[10]; // array } || logical or
char myString[20] [="val"]; &|~ bitwise and, or, complement
} <event type>
^ bitwise exclusive or (XOR)
<type> a) System Events a = 2<<3; bit-shift left (afterwards a is 16)
► signed int(16), long(32), int64(64) ► key 'character' or * keyboard events
► unsigned byte(8), word(16), dword(32), qword(64) ► timer <tmr> Timer expired >> bit-shift right
► Floating point float(64), double(64) ► preStart pre measurement start Please note: Don’t mix up comparison (==) and assignment (=) operator!
► character char(8) ► start after measurement start
If Decision
► Messages message <CAN-id> name ► stopMeasurement before measurement stop if (c <= 50)
message <DBC-Name> name b) Value Objects { // if c less or equal to 50
► Other types Associative Fields → Help ► signal <sig> Signal value changed *) }
Domain specific types → Help ► signal_update <sig> Signal write access *) Optional branches:
Values in round brackets: Number of bits (not in the source code!). ► sysvar <sys> System variable value changed else if ((c > 50) && (c <= 70))
All types are usable as local variables. ► sysvar_update <sys> System variable write access { // if c in ]50,70]
elcount(myString) returns the array size. ► envvar Value change environment variable }

Please note: c) Messages else
► Local variables are implicitly static. ► message <msg> CAN1.frmStatus { … } // in all other cases
► No program statements prior to variable declarations ► message <id>-<id> 0x100-999 Switch Selection
► message * any message switch (c) // integer
Comments
… // rest of line is comment {
message [*] All messages, also those that are processed by
/* all inside is comment */ case 50: // if c==50: …
another event handler in this CAPL source code. …
Ctrl-k-c: comment the selected area This break; // leave this branch
Ctrl-k-u: uncomment Event data can be accessed via this. case 100:
case 101: // cntr==100 or cntr==101
Own Types – Enums on key * this = character break;
Type definition in the variables section: on signal this[.raw] = physical [raw] value *) …
enum eMyEnumType {eMyEnum1 [=1],eMyEnum2 [=2]}; default: // in all other cases
on message this.<selector>
break;
Declaration of an enum variable & initialization: ► TIME measurement time }
enum eMyEnumType gMyEnum = eMyEnum1; ► ID CAN-ID
► DLC message length (data) For Loop
Usage:
► DIR RX, TX for (initialization; condition; modification):
if (gMyEnum == eMyEnum2)
► CAN channel number int i;
Own Types – Structs for (i=0; i<10; i=i+1)
► BYTE(0…7), { // statements
Type definition in the variables section: WORD(0..6), }
struct MyStructType DWORD(0…4),
{ QWORD(0) raw data While Loop
int anInt; while(c<50)
► Signals { // statements
long aLong; on message <msg>
}; }
{
Declaration of a struct variable and initialization: this.sigTemp
struct MyStructType gMyStruct [= {20,-1}]; Raw data of the temperature signal is returned (compare to “on signal this“).
Physical values are accessed with .phys.

Page 1 | 3 See all Technical Trainings at


© 2018. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V1.0 | 2018-12-21 www.vector.com
CAPL Cheat Sheet CAN

C-Syntax - continued CAPL & CANoe - continued Useful CAPL Functions

do while – loop Timer Write Window


Loop is executed at least once
Declaration in the variables section:
► Write window output void write(char format[], ...);
do write("Sig phys=%f, Raw=%d", $sig, $sig.raw);
msTimer myTmr;
{ // statements %... = Format expression
} while (c<50); Simple Timer: %d decimal %4d 4 digits
setTimer(myTmr, <time>); %f float %6.2f 6 digits in total, including 2 dec. places
Please note:
Do not implement infinite loops. CANoe must be terminated via task manager. Start periodic timer, times in milliseconds: %x hex %08X 8 digits, leading zeroes, capital letters
setTimerCyclic(myTmr,<period>[,first period]); %s string for character arrays
Functions
[<return type>] MyFunction (<type> arg1, …) Stopping ► writeCreate create a new write window tab → Help
{ cancelTimer(myTmr);
[return [constant | Variable];] ► writeClear clear a write tab → Help
} Check if active: ► writeEx extended write → Help
isTimerActive(myTmr) ► snprintf output to a string buffer → Help
return type: int, long, int64, byte, word, dword, float, double
Event Handler Interaction Layer (control from within the node)
void: no return value
on timer myTmr ► Stop message sending
Calling a function { … } ILDisableMsg(<msg>)
[var=]MyFunction([val][,val]…); ► Activate message sending
Messages
Signals and system variables as function parameters ILEnableMsg(<msg>)
Declaration of message variables: ► Other:
void MyFunction(signal *sig, sysvar * sys, message * msg)
message <*|id|msg> myMsg;
{ IL…() → Help
$sig = 20.0; Modification:
@sys = 20.0; myMsg.<selector> = <val>;
$sig = DBLookup(sig).maximum; // see attributes
output(msg); <selector> see section this.
}
Copy messages: CAPL Tips
DBlookup([msg|sig]) allows to access database attributes. myMsg2 = myMsg1;

CAPL & CANoe or in an event handler (e.g. a gateway) ► Watch for compiler warnings, enable them all in CANoe options
on message CAN1.* ► Use comments
{ ► Use name prefixes, e.g.
Signals and system variables should be accessed via symbol explorer or per auto- message * myMsg2;
completion. c<Name> constants
myMsg2 = this;
myMsg2.sigA = this.sigA * 2.0;
g<Name> global variables
Signals ut<Name> utility functions
myMsg2.CAN = 2;
$<sig> = 1; phys. signal value is set and with next message output(myMsg); // send p<Name> Function parameters
it will be sent by the interaction layer. } ► Avoid complex calculations in conditions (readability, debugging)
$<sig>.raw = 1; assign signal raw data Instead: assign intermediate results to local variables
access last received Signal[raw] value. Attributes
v = $<sig>[.raw]; ► Even if not needed for single statements after if: use curly brackets
Physical values are of type double. Attribute names with (*) are OEM specific. Vector IL: ► Event handler should not be a long runner
$<sig> =<msg>.<sig>::<text> Access to text table definitions <msg>.<attribute> ► Allow reuse with CAPL include files
► GenMsgSendType* ► Return values should be assigned to local variables.
System Variables
► GenMsgCycleTime* Their values are visible when debugging.
Assigning values:
@<sys> = 1;
► GenMsgILSupport* ► Check return values
Notation on this Sheet
@sysvar::<sys> is also possible <sig>.<attribute>
Reading values: ► GenSigStartValue* <> mandatory
if (@<sys>==2.0) ► GenSigInactiveValue* [] optional or array index
Special system variables, arrays:
► GenSigSendType* val value or string
SysSetVariable<type>(<sys>,buffer[]); ► factor // for conversion sig a signal name
SysGetVariable<type>(<sys>,buffer[],size); ► offset // for conversion sys a system variable name
► unit // string var a CAPL variable
<type>: String, IntArray, LongArray, FloatArray, Data ► maximum // physical my… user identifier
SysVar with conversion formula also as .raw for raw values. ► minimum // physical msg message name
→ Help see online help (F1)

Page 2 | 3 See all Technical Trainings at


© 2018. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V1.0 | 2018-12-21 www.vector.com
CAPL Cheat Sheet CAN

Test Modules *) Test Modules - continued Test Modules - continued


Check as constraint (=observation of the test environment)
Structure Waiting for Events → Help:
long testWaitFor<what>(…, <max time in millisec.>); or as condition (=observation of the ECU behavior). Both write events to the
MainTest is called upon test module start and determines the sequence of test
<what> report and impact the verdict:
cases. Test groups organize the test module structure and reporting.
testAdd<Condition|Constraint>(dword[,1])
void MainTest() ► Timeout fixed time span
{ With the optional second parameter being 1 the verdict is not influenced.
► SignalIn/OutSideRange sys / sig value within / outside range
… variables declaration ► SignalMatch sys / sig value Stimulations
MyTestcase1(…);
► ValueInput user input Create signal value sequences. Creation with
testGroupBegin (<title>, <description>);
► Message message reception <dword> = stmCreate_<what>(<signal>,<parameter>)
MyTestcase1(…);
… ► TesterConfirmation user confirmation → Help <what>
MyTestcaseN(…); ► MeasurementEnd wait for measurement end ► CSV comma separated values
testGroupEnd(); ► Ramp
Return value: 0 = timeout; 1 = event
} ► Toggle
Functions marked with testcase are test cases. They do not have return Evaluation ► … → Help
values. Using C statements:
testcase MyTestcase1() Control:
if … else …
{ … } stmControl_Start|Stop(<dword>)
Better for signals and system variables:
Accordance with Simulation Nodes: testValidateSignalMatch("id",<Sys/Sig>,<val>); Diagnostics
testValidateSignalIn/OutRange -> Help Diagnostic objects must be declared. The service qualifier should be inserted via
► All event handler
► C-syntax Reporting Drag & Drop from the Symbol Explorer:
testCaseTitle DiagRequest <service qualifier> myReq;
► Data types DiagResponse <service qualifier> myResp;
► System variables und signal access testModuleTitle
teststep[Pass|Fail]("id", "text …%d text", <var>); Selecting the diagnostic target:
Test verdict testreportAdd<what>(…) DiagSetTarget("<ECU qualifier>");
Every test step, test case, test group and the test module has a test result Fail or <what>
Pass. ► EngineerInfo Set a request parameter, the parameter qualifier taken from the Symbol
► ExternalRef Explorer:
Test cases diagSetParameter(myReq, "<Parameter>", val);
► Image
Most test cases can be structured logically into three phases:
► WindowCapture Send:
1. Stimulation: signals, IOs, messages … DiagSendRequest(myReq);
► … → Help
2. Wait for a reaction
3. Evaluation Fault Insertion Wait for a response:
From the test module for all simulation nodes int = testWaitForDiagResponse(myName,10000);
The phases are made of test steps that set the test verdict:
testcase myTestcase() ► TestDisableMessage<(msg>) Evaluation, the response can be addressed with the request (request and
{ … ► TestEnableMessage(<msg>) response belong together):
testStep<Pass|Fail>("id", "description"); ► TestEnableCRCCalculation(<msg> double = DiagGetRespParameter(myReq, "Para");
… ► TestResetAllFaultInjections()
testStep ("id", "description"); // w/o verdict Alternative:
► … → Help DiagGetLastResponse(myReq, myResp);
}
id is a user definable text for identification. Background Checks Other functions:
Configuration: (identification is done with a dword handle) ► DiagGetLastResponseCode(myReq) -1 upon positive response,
Functions / Test Functions <dword> = ChkCreate_<checktype> (<parameter>)
Frequently used tests should be implemented as test functions or functions ( for else negative response code
<Check type>
re-use). Both produce different reporting data. ► DiagGetComplexParameter(…) dynamic data → Help
► MsgAbsCycleTimeViolation
► Diag… → Help
Stimulation ► ErrorFramesOccured
@<sys> = <val>; // system variable ► … → Help Test Module Tips
$<sig> = <val>; // with interaction layer
output(<msg>); // local message object
Control:
chkControl_<Start|Stop|Reset|Destroy(<dword>) ► Implement functions for re-use in test cases (readability, maintenance,
effort).
Evaluation: ► Check return values and document problems with TestStepFail().
chkQuery_<what>(<dword>)
<what>
► NumEvents
► EventStatus
► … → Help

Page 3 | 3 See all Technical Trainings at


© 2018. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V1.0 | 2018-12-21 www.vector.com

You might also like