Header Overview

The AscTec Communication Interface Tool (ACI Tool) is a sample program which shows the usage and possibilities of the ACI. It was programmed with the Simple DirectMedia Layer (SDL) to create a cross-plattform tool for Microsoft Windows and Linux. You can download the program and the source code from the ACI Download wiki page.



You can use this tool to check, if the ACI code written on your device is working. The usage is very simple:

  1. Connect your serial device.
  2. Then you can request the available lists of variables, commands and parameters and add them to packages.
    • Variables are only readable and you can only change the rate of the incoming package. 
    • Commands are only writable, so you can set them and send them to the device. 
    • Parameters are both, readable and writable. You can also tell the device, to load or to save the parameters permanently on it. 
  3. Last but not least you can check the version and other parameters on the device and the ACI Remote for C, which this tool uses. If all lists were requested, the tool will store them on the hard drive. The next time, it will load it from the hard drive only if the stored data are the same as on the device.

On this page I will show you the usage of ACI in this program. I will not explain the usage of SDL. For that, there are some other good tutorials.

Build from source on the Mastermind

build-aci-tool.sh

 

 

Main difference of the Microsoft Windows and Linux version

Unfortunately the whole code is not completely the same in both OS versions. I have to change some includes, modified the Makefile and used the FTDI driver to easily open the serial device.
To compile the code on your own, you can use the Makefile for the OS (named Makefile.Windows and Makefile.Linux) or include the project in an IDE (like e.g. Eclipse). The necessary includes and links, can be found in the Makefile of your OS. For Linux, i used gcc and in Windows mingw32-gcc to compile my code. Let us first take a look on the Linux version:

You need only to install SDL with SDL_image and SDL_ttf. In Ubuntu, open a console and execute following command:

The Windows Makefile is a little bit more complicated:

You have to download and install the following libraries:

Please modify the paths in the Makefile with the location of the installed libraries. I used the FTDI drivers to open the serial device. You can also use it in Linux, if you want. Linking of SDLmain is only necessary in Windows.

The next thing is to define, which OS you are using. That is defined in the menu.h file:

in the forth and fifth line, you have to choose, which OS you want to use. The main differences are only in opening the device. SDL_image is also not necessary to include in the Linux version.

The Code

Let us take a look at the structure of the program:

The whole code is written in the menu.c file. In the header file (menu.h), the functions are defined:

The last ten functions are ACI-based, the other ones are the functions for the different states, as you can see in the structure.

In sdl_init(void), I define the function for saving/loading data into a file on the local machine:

So, if we receive all lists, they will be stored in a file for loading them quickly. More informations about that can be found in the Tutorial Send Parameters.

The main-loop executes the right function for the defined state:

If the state is 0, the program quits. 

Let us take a look at the connect menu. If you want to connect, you have to type in the device number (usually 0 if only one connected). After that, a connection will be established. that happens in the sdl_connectmenu(void) function:

It starts with opening the device and setting it up. The serial port shall be not blocking, use a baudrate of 57600, be read-/writable and have a bitsize of 8. After that, I initialize ACI, set some callbacks, set the engine rate, get the version info and the variable transition rate from the device and tell it to load the parameters written on its EEPROM. After a stable connection, you can check the version. If there are values for the device, you can be pretty sure, that the connection is established and that the ACI Tool can communicate with the device.

Requesting the variables, commands and parameters is written in the main-loop:

If that works, you have the possibility to create the packets for receiving/sending variables, commands and parameters. The differences in requesting are not big, so let us only take a look at requesting variables in sdl_requestvariables(void):

Normally, you first declare a variable for later calculations and put it in the packet. So normally you have a predefined number of variables. In this case, we don't have that, so we use malloc for creating a new variable and read it out later with using the function aciGetVariableItemById. With the function aciSetVarPacketTransmissionRate(unsigned char packetId, unsigned short callsPerSecond) we set the transmission rate for every packet and send them together to the device by using aciVarPacketUpdateTransmissionRates(void). Reading and Writing the commands and parameters are similar.

The last thing is to view the variables, send the command and setup the parameters. Viewing variables is quite easy. You have only to call the function aciSynchronizeVars(void) to write all received variables from the buffer to your defined declarations (in this case, our malloc-created variables), as you can see in the beginning of the loop in the function sdl_showvariables(void):

To read and display the variables, we search the variable by id and write it to the SDL surface:

Similar, it works with the parameters and the commands. To set them, we write the value in entry->ptrToVar and display it like the variable list. To send the set values, we use the function aciUpdateParamPacket(const unsigned short packetId) or aciUpdateCmdPacket(const unsigned short packetId):

For storing or loading the parameters, we use the functions aciSendParamSave(void) and aciSendParamLoad(void) in sdl_showparameters(void):

Mostly the rest of the whole code are SDL-based functions for displaying all texts and images or handling the input. That has taken most of the time creating this application and that shall be the sense of ACI: Beeing a slide and easy SDK, where you are concentrating more on your self minded idea than in the communication with the device.