"Reprint" CANoe Introduction Step by Step Series (c) An analysis of simple examples

Source: http://www.cnblogs.com/dongdonghuihui/archive/2012/09/26/2704623.html

What is the best way to learn? Imitate. Some people will ask, isn't that a cottage? But I think that is the initial stage of imitation, when the best design of others has melted into their own blood, become their own things, and flexible use of time, is the real advanced stage. The so-called painting tiger painted skin difficult to draw bone. But the primary stage is still the process that must be experienced, he will make you in the process of reaching the advanced stage of a lot less detours, we take this step. Let's look at some simple examples of others.

The best example is the demo of the vector itself, which is automatically installed after the canoe is installed. First look at the simplest one, the name is easy, but it is not simple, oh, than we introduced before the integration of all the things together, very simple, but very comprehensive. But if you say that I can write it myself (not just to understand it), then I can certainly say that in the work, you can fully qualified for the general task requirements Oh ~, the rest is only the workload of the problem. But I believe that so far, many of you have been unable to write such a procedure, so I suggest that you study this procedure well enough to understand that this is important. Nonsense not much to say, the following is the open run after the interface.

Through the Panel can control, and display a lot of animation effect, do very beautiful. The rest of the form also presents the main data as a chart, and so on.

Let's take a look at the DBC content first.

Signals:

Enginespeed Speed Information

Flashlight Double Jump Light

Headlight Headlight

ONOFF Engine Status

Messages:

EngineState Engine Status: Contains the signal has Onoff,enginespeed

Lightstate Light Status: Contains the signal is Flashlight,headlight

Network nodes:

Display node, receive all messages

Engine node, sending enginestate messages

Light lighting node, sending lightstate messages

Environment variables: Environment variables, generally associated with the interface components, so that the graphical interface control and display, the following is the associated interface components

Envenginespeeddspmeter

Envenginespeeddsptext

Envenginespeedentry

Envenginestatedsp

Envenginestateswitch

Envhazardlightsswitch

Envheadlightswitch

Envlightdsp

Note the signal information:

Definition page, init.val input box enabled, before the state of Gray, for what? Click on the blue underlined connection to pop up the window sill as follows:

This means that the value of the setting, must be defined by the property to be valid, has not mentioned the signal properties, this is the first time to meet OH. A personal understanding of signal properties is a series of parameters that indicate the characteristics of a signal, and of course the messages and nodes have corresponding properties. To learn more about this attribute, we turn to help.

Oh, I see, it was originally used to initialize the data. In fact, the definition represents a physical value that is converted to a raw value to be saved to the Gensigstartvalue attribute. In the creation of attributes we have not mentioned before, here to tell, please in the candb++ Editor menu, View->attribute definitions

Right button, New, fill in the good information. Property behind the behavior is closely related, even with the underlying DLL, some other properties please refer to the Help document, of course, the important attributes we will also be mentioned later.

DBC also has a few details, that is, the definition of the message that is accepted, is not introduced between, for example, the display node only receives messages, then you should be configured on the node's properties, by right-clicking node and clicking Edit node, mapped Rx The Sig can define the received signal, ADD ...

It is also possible to not define a receive message, but it will show an alarm in the File->consistency check for non-receiving nodes. For example the previous first example of the DBC check is as follows:

Look at the CAPL program again.

The Engine.can program is as follows:

Variables
{
}

On Envvar envenginestateswitch//When a toggle switch is made, the signal from the engine is changed
{
$EngineState:: OnOff = @this; Note that the signal and environment variables are directly assigned the symbol, the signal with $, environment variable with @
if (@this)
$EngineState:: Enginespeed = @EnvEngineSpeedEntry;
Else
$EngineState:: enginespeed = 0;
}

On Envvar envenginespeedentry//When moving the car speed slider, the signal from the engine is changed
{
if (@EnvEngineStateSwitch)
{
$EngineState:: Enginespeed = @this;
}
}

On start//the event that all environment variables are called when the program starts running
{
Callallonenvvar (); Call all Envvar procedures of the This model and
Thus consider the START VALUES of all environment
Variables for:
-Initialization of all message variables
-Starting of any timers
-Sending messages (output) with start values
}

The Light.can program is as follows:

Variables
{
Mstimer tflashlightfrequency; Defining a strobe Timer
const int gflashlightfrequency = 500; Define strobe frequency, initialize to 500ms
int ghazardlightsstatus = 0; Define a hazard light signal

int gdebugcountertx = 0; For commissioning, record the number of TX messages
int GDEBUGCOUNTERTXRQ = 0; For debugging, recording the number of TXRQ messages
int gdebugcounterrx = 0; For commissioning, record the number of RX messages
}

On Envvar envheadlightswitch//Headlight switch status changes, the signal to update the light message
{
Assign EV value to the message signal
$LightState:: headlight = @this;
}

On start
{
Callallonenvvar (); Call all Envvar procedures of the This model and
Thus consider the START VALUES of all environment
Variables for:
-Initialization of all message variables
-Starting of any timers
-Sending messages (output) with start values

Setwritedbglevel (0); Set dbglevel = 1 to get more information in Write-window
}

On message lightstate//debugging, printing related information
{
if (This.dir = = TX)
{
gdebugcountertx++;
if (Gdebugcountertx = = 10)
{
Writedbglevel (1, "Lightstate TX received by Node%node_name%");
Gdebugcountertx = 0;
}
}
if (This.dir = = txrequest)
{
gdebugcountertxrq++;
if (Gdebugcountertxrq = = 10)
{
Writedbglevel (1, "Lightstate Txrequest received by Node%node_name%");
GDEBUGCOUNTERTXRQ = 0;
}
}
if (This.dir = = RX)
{
gdebugcounterrx++;
if (Gdebugcounterrx = = 10)
{
Writedbglevel (1, "Error:lightstate RX received by Node%node_name%");
Gdebugcounterrx = 0;
}
}
}

On Envvar envhazardlightsswitch//hazard warning light switch, update the flashing signal of the light message
{
if (@this)
{
Ghazardlightsstatus = 1;
SetTimer (tflashlightfrequency, gflashlightfrequency);
}
Else
{
Canceltimer (tflashlightfrequency);
Ghazardlightsstatus = 0;
}

$LightState:: Flashlight = ghazardlightsstatus;
}

On timer tflashlightfrequency//control of the interval flicker of the hazard alarm lamp
{
Ghazardlightsstatus = (Ghazardlightsstatus = = 1? 0:1);
$LightState:: Flashlight = ghazardlightsstatus;
SetTimer (this, gflashlightfrequency);
}

On key ' 0 '//key event to define the level of print debug information
{
Setwritedbglevel (0);
}

On key ' 1 '//key event to define the level of print debug information
{
Setwritedbglevel (1);
}

The above procedures, C-language basic students should be able to understand, there is no detailed introduction.

After reading the program you may have a question, did not call any function to send the can message (just change the signal), but the message is actually sent out, this is why?

This is because the cycle of sending a message is already defined in the properties of the message, so that the message is sent automatically periodically. As follows:

This interface in the property view of the message, of course, can also be modified and viewed in the View->attribute definitions described above, but the difference is that this is only for individual messages, View->attribute Definitions, is for all the cases. There are also message attributes, which are categorized into the interaction layer, which is the interface of can communication. Please refer to the Help documentation for detailed instructions on the specific meanings of each of the above properties.

Let's talk about the interface.

Select an interface component to display information such as his type, associated objects, and so on in the status bar. To the right is the Properties window, which defines the properties of the selected component

This component type is: Switch/indicator

In the property bar:

Image represents the picture used by the component because it is to represent several states, so the size 105x34 pix

State Count indicates the number of states

Other properties do not introduce each one, and try it out for yourself basic can know, really do not ask for help documentation, here is not introduced.

To the present the whole project analysis basically ended, but said these insufficient to cover all the details, but the basic context is already very clear, the rest can be researched, it is not difficult to understand. Personal advice to create your own project in the actual work, when the problem is, refer to the implementation of the example, this is more helpful to understand. Progress is also the fastest.

"Reprint" CANoe Introduction Step by Step Series (c) An analysis of simple examples