TSL2561 light sensor with STM32F4

This blog has been moved: http://scholtyssek.org/blog/2014/11/24/tsl2561-light-sensor-with-stm32f4/

The TSL2561 is a sensor that measures the light-intensity and transforms it to a 16-bit resolution digital value. There are two photodiodes on the sensor, one to sense the light intensity plus infrared light and a second one to measure only infrared light. These two photodiodes convert the measured light-intensity simultaneously. There are two channels available on the sensor to transfer the values into the data register (channel 0 and channel 1). The idea is to subtract the infrared part of the light, so that the resulting light spectrum is the human seeable light.

The measured data can be received via I2C or SMBus. In this article the I2C bus will be for the communicatation between the STM32F4 and the with the TSL2561. 

Connect the device

The TSL2561 works with 3.8V, don't use the 5V pin, you may destroy the sensor. Futher there are two pins (SDA and SCL) for the I2C bus communication. The SDA is the data line, while SCL is the clock. The address pin is to set a unique I2C bus address. The default address can be used, unless there is another device with the same address on the bus. The default address is 0x39, but it can also be set to 0x29 or 0x49. The sensor can generate an interrupt, so that it is not necessary to poll the device. In this example the interrupt signal is not used.

TSL2561 light sensor

The software part

The STM32F4 controller has several I2C interfaces. The example implementation uses the I2C1, which is connected to GPIO6 (SCL) and GPIO7 (SDA). The configuration is encapsulated to an configuration header, so it is easy to change the bus. The software can be downloaded from the repository (the project is called TSL2561_example). The maximum clock frequency for the device is 400kHz, so this frequency is set in the configuration file. The init_lightsensor(void) method is the configures the necessary IOs and the I2C communication via initLightSensorI2C(void).

To read the measured values, there are four register (two for every channel), that can be read. First there is a 8 bit register that contains the values low byte an then there is a second register for the high byte.

address 0x00	description control register
0x8C	low byte (channel0)
0x8D	high byte (channel0)
0x8E	low byte (channel1)
0x8F	high byte (channel1)

To read bytes from the device registers, the requested register addresses should be send bytewise to the control register (0x00). There is a command bit that must be set so that the device reacts on the request.

The received data can be calculated to the SI unit LUX. This calculation is already implemented in the example code. The read_lightness_value() method receives the data bytes via I2C and processes the calculation to LUX.

Appendix

http://www.adafruit.com/datasheets/TSL2561.pdf

STM32F4 with ERIKA Enterprise RTOS OSEK

This blog has been moved: http://scholtyssek.org/blog/2014/11/21/stm32f4-with-erika-enterprise-rtos-osek/

Erika Enterprise is an open source OSEK compliant real time operating system (RTOS) that support the STM32F4-Discovery controller. There is a eclipse tool chain integration available, so it is possible to develop software directly in this IDE. Combined with the GNU ARM Eclipse Plugin, the stlink debugger and programmer and the GNU Tools for ARM Embedded Processors, eclipse is a great tool for developing, flashing and in-circuit-debugging applications based on the ERIKA real time kernel for STM32F4 devices. The OS can be downloaded here, if there are any questions about the installation, please have a look at the wiki or the forum on the ERIKA website. 

The OS comes with an oil-file, which is a configuration file for the kernel. In this file, there are several options to config the kernel and to define dependencies for used libraries, e.g. the Cortex Microcontroller Software Interface Standard (CMSIS).

The ERIKA kernel supports several classes of tasks (basic and extended tasks). Compared to the basic tasks, the extended tasks support synchronization via system events. This nice feature allows to activate a task by sending an event within the software. To learn more about the operating system, please have a look at the official documentation.

The following section describes the usage of ERIKA Enterprise with extended tasks and event based scheduling on the STM32F4 controller. To use this kernel configuration, there are some necessary options that can be set in the oil-file. A configuration for the controller looks like this:

CPU mySystem {
 OS myOs {
  CPU_CLOCK = 168.0;
  MODEL = M4;
   
  APP_SRC = "src/code.c";
  APP_SRC = "src/pwm.c";
  COMPILER_TYPE = GNU;
  MULTI_STACK = TRUE {
   IRQ_STACK = TRUE {
    SYS_SIZE = 512;
   };
  };

  EE_OPT = "DEBUG";
  CFLAGS = "-std=c99";
};

MCU_DATA = STM32 {
 MODEL = STM32F4xx;
};

The STM32F4-Discovery has an ARM Cortex-M4 cpu which works with a frequency of 168 MHz, so the CPU_CLOCK parameter is set to an appropriate value. The cpu clock depends on the exact model, in this example I used the STM32F407VG. The APP_SRC parameter is used to list every *.c file that should be compiled with the kernel. To use multiple files, the parameter can be repeated. The development is based on the GNU ARM compiler and debugger, so the COMPILER_TYPE is used to declare the GNU toolchain. To use extended tasks, it is necessary to specify a MULTI_STACK and with a static size. The last block defines the CPU model. It is set to the STM32F4 processor family.

To integrate external libraries, like the  ARM specific CMSIS, there is a possibility to add some libraries to the kernel. The following configuration shows how to defines the usage of the additional libraries:

EE_OPT = "__USE_CMSIS_ALL__";
EE_OPT = "__USE_SPD_ALL__";
EE_OPT = "__USE_SYSTICK__";
EE_OPT = "__ADD_LIBS__";

LIB = ENABLE {
 NAME = "ST_CMSIS";
};

LIB = ENABLE {
  NAME = "STM32F4XX_SPD";
  STM32F4XX_SPD = ENABLE {
   USETIM = TRUE; 
   USEI2C = TRUE;
   USEMISC = TRUE;
   USESPI = TRUE;
   USEUSART = TRUE;
  };
};
  
LIB = ENABLE {
  NAME = "STM32F4_DISCOVERY";
};

These parameter are processor specific for the STM32F4 controller. The next configuration part describes the options to configure the ERIKA kernel scheduling. The kernel supports four conformance classes, that can be set (BCC1, BCC2, ECC1, ECC2). The BCC classes support basic tasks during the ECC classes support extended tasks. Extended tasks are necessary for event driven scheduling. To read more about the conformance classes, please have a look at the ERIKA reference manual. The  conformance class can be set with the following parameter:

KERNEL_TYPE = ECC1;

The next step is to configure events and tasks. In this example there will be one task that is triggered by one event. This task will be called setPwmTask and it reacts on a pwmEvent. Tasks can react on a set of events, these have to be assigned in the configuration file. Accordingly a configuration for one task that reacts on one event looks like this:

EVENT pwmEvent {
  MASK = AUTO;
};
 
TASK setPwmTask {
  PRIORITY = 0x03; /* lower priority */
  AUTOSTART = FALSE;
  STACK = PRIVATE {
    SYS_SIZE = 512;
};
  ACTIVATION = 1;  /* only one pending activation */
  SCHEDULE = FULL;
  EVENT = pwmEvent;
};

The next step is to declare them in the implementation, so that it could be activated by the software:

DeclareTask(setPwmTask);
DeclareEvent(pwmEvent);

TASK( setPwmTask) {
  EventMaskType current;
  while (1) {
    if(WaitEvent(pwmEvent) == E_OK){
    /* error handling */
  }
  getEvent(setPwmTask, &current); /* save event */
  ClearEvent(pwmEvent);

  /* do some fancy task work */
  }
  TerminateTask(); // never reached
}

The last step is the initialization of the kernel. After this, the task can be activated by setting the pwmEvent event. The following snippet shows how to initialize the kernel and then activate the setPwmTask periodically:

#include "ee.h"
#include "ee_api.h"
#include "kernel/oo/inc/ee_oo_api.h"

int main(void) {
  /* Initialize Erika related stuff */
  EE_system_init();

  while (1) {
    SetEvent(setPwmTask, pwmEvent);  
    Delay(MILLISECONDS_TO_TICKS(100, SystemCoreClock));
  }
}

With ERIKA Enterprise comes a very nice open source real-time OS that can easily be integrated in the eclipse IDE. It runs on the STM32F4-Discovery controller, so that all the nice features of a RTOS are available.

SRF02 ultrasonic sensor with STM32F4-Discovery

This blog has been moved: http://scholtyssek.org/blog/2014/08/24/srf02-ultrasonic-sensor-with-stm32f4-discovery/

The SRF02 Ultrasonic range finder is a ultrasonic distance sensor, which is a transceiver with only one membrane. That's practical, because the sensor is very small and so it is perfect for small sized hardware applications. It detects distances from 16 to 6000 cm. The Sensors needs a 5 V source, so it can be directly connected to many microcontroller. It communicates through serial interface or through i²c bus (also I2C bus called). The following article describes how to connect and use the sensor with a STM32F4 through I2C. The databus is very handy because it needs only two wires (SDA and SCL) for communication. SDA is the data wire and SCL is the clock. Components can be distinguished by a unique I2c address. In this example there are four SRF02 sensors on one bus. The configuration of the address will be described too. The I2C master is a ARM based STM32F4-Discovery (STM32F407VG) controller.

Xbox360 controller C integration

This blog has been moved: http://scholtyssek.org/blog/2014/08/16/xbox360-controller-c-integration/

Today I have written some simple example code to integrate a Xbox360 controller into a C-based program. It reads the values of the controller axis and the buttons and displays them on the screen. The following picture shows the output of the code:

In this case the buttons "A" and "TL", which is the top left button, were pressed. The project is called xboxControllerClient can be downloaded from my repository at https://code.google.com/p/scholtyssek-blogspot/.

Rigol DS1052D and Open Logic Sniffer

This blog has been moved: http://scholtyssek.org/blog/2014/07/29/rigol-ds1052d-and-open-logic-sniffer/

Today I have tested the logic analyzer of the Rigol DS1052D oscilloscope and I noticed that the LA does not interprete the measured signals. The Rigol DS1052D is a lower priced model, so it is ok that the data is not interpreted by the oscilloscope. But it is possible to export the signals and process them on a PC with the open source tool Open Logic Sniffer. To do so you can export them as a CSV datafile. After an easy converting the data can be read by OLS. The following step describe what you have to do.

STM32F4 controlled omnidirectional mecanum robot with odometry

This blog has been moved: http://scholtyssek.org/blog/2014/07/27/stm32f4-controlled-omnidirectional-mecanum-robot-with-odometry/

In the last months I worked on a new project based on an ARM STM32F4 controller. The goal was to implement a software to control a robot with mecanum wheels (also called swedish wheels). These wheels are very special, because there are rubber rollers arranged at 45 degree on the outer rim that roll passively on the ground. Thus the robot has a further degree of freedom. This means all directions (X, Y, Θ) can be reached by the robot on a plane. Despite the lack of steering axle it has the maximum freedom of movement. X and Y corresponds to the movement in the respective directions, and Θ represents the rotational movement of the robot.

the robot 

In the robot is a Nexus 4WD. It has four Faulhaber motors which are directly equipped with incremental encoders furthermore it also has (ultrasonic) distance sensors and an Arduino controller with suitable motor drivers. The 12 V DC motors are powered by a battery that is connected with a standard Tamiya plug.
Since I have decided to use the STM32F4, I performed some modifications on the robot. In particular, the Arduino controller was replaced by the STM32F4, but this had the consequence that the motor drivers that were permanently installed on the board of Arduino, were also removed from the robot. Therefore, a new engine controller with appropriate drivers (h-bridge) had to be developed so that the motors can be controlled properly.  In addition to the existing sensors and actuators, the robot is equipped with a gyroscope so that the orientation, that is, the rotation movements of the robot, can be measured in the context of odometry.

Figure1 and figure2 are showing the robot with a open chassis. They also show the four Mecanum wheels which are fixed to the shafts of the motors. In addition, you can see - despite the bunch of wires - the hardware components and the battery. Figure2 shows the robot in a top view and figure3 shows the individually hardware highlighted.

Figure1: Nexus 4WD (back view)