Each application program written for the BIM M13x family has at least one common part: the handling of the communication over the KNX-bus.
Though the BIM Tools prepare the code for the programmer – saving him from quite much work -, there are several issues, regarding the KNX-communication, which may occur during the program development and can cost a lot of time, until the correct solution is found.
In a former post I’ve described the process of creating application programs for the BIM M13x family, now I will be focusing on handling the communication over the KNX-bus.
As already mentioned in former posts, the program development for the BIM M13x family starts with the BIM Wizard (BIM Tools), which generates the whole workspace and the basic source code, containing inter alia the declarations of the KNX communication objects, the address table and the association table.
The BIM Wizard gives the developer the possibility to define the needed communication objects without writing lines of code, as well the needed entries in the address and association tables are generated by the tool automatically. (In the following example I will use only one 2 byte long communication object.)
The communication between devices (over the KNX-bus) is made with telegrams sent to Group addresses. A Group address is a logical name for a given topic linking the output of a sensor with the input of an actuator.
Compatible devices listen in a group. One ore more sensors emit the bits many actuators listen on a given group. This is the primary way to connect things in KNX. (openremote.org)
The group address for each communication object is generated automatically by the BIM Wizard. These group addresses can be found in the generated workspace, in the tables.c file.
#pragma constseg = ADDRTAB
__root const BYTE AdrTab[] =
{ NUM_OF_COM_OBJ + 1,
// for debug: one group address per communication object
// (group addresses must be sorted in ascending order!)
0xFF, 0xFF, // physical address // group addresses
0x11, 0x00, // padding
0x00
};
#pragma constseg = ASSOCTAB
__root const BYTE AssTab[] =
{ NUM_OF_COM_OBJ + 0,
// for debug: one association per communication object
// (sorted in ascending order by the second byte of the
// association. If a communication object has no
// association the association has to be (0xFE, [objnum]).
// A communication object has only one sending group address.
// This is the group address that is specified by the
// association at the "communication object number"-position
// in the association table.)
// grp.addr., comobj. num., grp.addr., comobj. num.,
0x01, 0x00,
// padding
0x00
};
I have written emphasized with red the group address of the only communication object I’ve declared in this example. The group addresses are stored on 2 bytes (here: 0x11 and 0x00) and, as already mentioned, are assigned automatically by the BIM Wizard. Through these group addresses, the used KNX communication objects can be accessed from an external device over the KNX-bus.
Converting the group addresses into the ETS format
Accessing the already defined communication objects from the ETS, or from the BIM Tools (Group Communication – Connectionless Mode) is possible only after converting the two byte long group addresses into the ETS format: Main Group/Middle Group/Sub Group.
The address field in the Group Communication window accepts only the ETS format, e.g.: 4/4/1. To be able to convert the group address from the 0x00 0x00 format into the x/y/z format and back, you should know the following:
- “the group addresses have following structure:
- the group address is coded on 15 bits (Bit D15 is a reserved bit)
- the first row shows how the group address is represented in a two level hierarchy (main/sub), while the second in a three level hierarchy (main/middle/sub). Note that physically on the bus, there is no difference between a two and a three level group address!”
Now, the conversion of the address from the “source code format” into the ETS format is rather easy:
- Take the address coded in hex from your source code and convert it into binary format:
0x11 0x00 –> 0001 0001 0000 0000
- Group the bits according to the structure shown on the picture above.
Sub group: 0000 0000
Middle group: 001
Main group: 0010
- Convert each group into decimal and write the result into the Main Group/Middle Group/Sub Group format.
The address in ETS format: 2/1/0
Using the BCU 2.5 API to handle the communication
The Application Programming Interface of the BCU 2.5 firmware provides a bunch of useful functions to handle the communication between the newly developed system and other KNX appliances.
The API functions that are described in the API-Reference at the point ‘Object-Handling’ act on the ram flags. (The interface between the user application program and the operating system are the ram flags.) Each time an update for a communication object was received the operating system sets the ram flags and stores the new value in the user application RAM. Therefore the user application program has to specify a table with pointers for each communication object (name: CObjects). The first pointer must point to a byte that contains the number of entries in the table.
The next pointer is the pointer to a ram variable for communication object 0, the next pointer for communication object 1 and so on. The address of this table has to be specified in the application info block.
Again… The tasks mentioned in the citation above are all done automatically by the BIM Wizard. You can find the table with pointers for each communication object (called CObjects) in the last part of main.c.
const BYTE NbComsOb = NUM_OF_COM_OBJ;
const CObjPtr CObjects[] = // set table for com objects
{
(void*)&NbComsOb, // ptr to number of cobjects
//------------------------------------------------------------------------
// Here the addresses of the communication objects are specified
//------------------------------------------------------------------------
&CommObj_0
};
If an update for a communication object is received, the new value is stored by the operating system in the user application RAM. The variables, automatically declared by the BIM Wizard, point to these ram locations, so that the new values can be accessed through them. In my case:
// communication objects USHORT CommObj_0;
When I’ve tried for the first time to implement the communication handling algorithm, I wanted to check that the communication object really has the value I expect. For that, I’ve used following code:
// communication objects
USHORT CommObj_0;
void main (void)
{
USHORT tmp;
for( ; ; )
{
if ( U._TestObject( 0 ) )
{
// Copy the content of the communication object
// into an auxiliary variable location
tmp = CommObj_0;
// Send the content of the auxiliary variable
// over the KNX-bus using the communication object 0 (data length = 2 byte)
U._SetAndTransmitObject( 0, &tmp, 2 );
}
}
}
If you use the Group Communication feature of the BIM Wizard for sending messages to your new device, you will see, that the data you’ve sent over the communication object 0 is listed again in the window as a read telegram. That way you can test, without using the debugger, that the needed data really reached your new device.
References
- The sources of the citations are the website openremote.org and the BIM M13x Documentation published on opternus.com .
- The source of the heading picture is the website directindustry.com.
Add Comment