TSL2561 Lichtsensor mit dem STM32F4

Der Blog ist umgezogen: http://scholtyssek.org/blog/de/2014/11/24/tsl2561-lichtsensor-mit-dem-stm32f4/

Der TSL2561 ist ein Sensor, der die Lichtintensität messen und in einen 16-bit aufgelösten, digitalen Wert transformieren kann. Auf dem Sensor sind zwei Fotodioden enthalten, die das Lichtspektrum messen und in einen digitalen 16-Bit Wert transformieren. Die erste Fotodiode misst das Lichtspektrum inklusive dem infraroten Anteil. Die zweite Diode misst lediglich die infraroten Lichtbereich. Die synchron aufgezeichneten Messwerte werden über eigene Kanälen in Datenregister transferiert (channel0 und channel1). Die Idee dabei ist, dass beide Werte dazu verwendet werden, den infraroten Lichtanteil durch eine Subtraktion zu herauszurechnen. Das resultierende Lichtspektrum entspricht somit dem, welches das menschliche Auge erfassen kann.
Die Messwerte können über den I2C oder den SMBus ausgelesen werden. In diesem Artikel wird eine Kommunikation über den I2C-Bus eingesetzt, um Daten zwischen dem STM32F4 und dem TSL2561 auszutauschen.

Den Sensor anschließen

Der TSL2561 arbeitet mit einer Spannung von 3.8V, verwenden Sie nicht den 5V Pin des STM32F4, sonst laufen Sie Gefahr, den Sensor zu zerstören. Es gibt zwei Anschlüssen für die I2C-Kommunikation (SDA und SCL). Der SDA Pin ist für den Datenaustausch mit dem Sensor, währen SCL für den Bustakt verwendet wird. Der ADDR Pin ermöglicht es, den Sensor mit einer I2C Adresse zu konfigurieren. Solange die Standardadresse auf dem Bus nicht für ein anderes Gerät verwendet wird, kann diese problemlos verwendet werden. Die Standardadresse für den Sensor lautet 0x39, diese kann aber auf die Adressen 0x29 bzw. 0x49 angepasst werden. Außerdem kann der Sensor einen Interrupt auslösen, sodass es nicht notwendig ist, diesen zu pollen. In dieser Beispielimplementierung wird allerdings auf die Verwendung eines Sensorinterrupts verzichtet.

TSL2561 Lichtsensor

Die Software

Der STM32F4 Controller verfügt über mehrere I2C Schnittstellen. In diesem Beispiel wird I2C1 verwendet, welcher an den IOs GPIO6 (SCL) und GPIO7 (SDA) angeschlossen ist. Die Konfiguration ist übrigens in einer Konfigurationsdatei gekapselt, sodass diese leicht angepasst werden kann. Die Software kann aus dem Repository (Projektname TSL2561_example) runtergeladen werden. Die Taktfrequenz für die I2C Kommunikation liegt bei 400 kHz, diese ist, wie auch die IOs, in der Konfigurationsdatei hinterlegt. Die init_lightsensor(void) Methode konfiguriert alle benötigten IOs und die Peripherie für die I2C Kommunikation mittels initLightSensorI2C(void).
Die Messwerte werden in insgesamt vier Registern hinterlegt (zwei für jeden Kanal), welche ausgelesen werden können. Diese Register enthalten die Messwerte als 8 Bit low bzw high bytes.

Adresse 0x00	Beschreibung control register
0x8C	low byte (channel0)
0x8D	high byte (channel0)
0x8E	low byte (channel1)
0x8F	high byte (channel1)

Um Bytes aus den Registern des Moduls zu lesen, wird vorab die Registeradresse an das Control Register (0x00) des Moduls geschickt. Außerdem muss das sogenannte Command Bit gesetzt werden, damit das Modul korrekt auf die Anfragen reagiert.
Die empfangenen Daten können in die SI-Einheit LUX umgerechnet werden. Diese Berechnung ist bereits in dem Beispielprogramm enthalten. Die read_lightness_value() Methode empfängt die Datenbytes und führt die Transformation durch.

Appendix

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

STM32F4 mit ERIKA Enterprise RTOS OSEK

Dieser Blog ist umgezogen: http://scholtyssek.org/blog/de/2014/11/21/stm32f4-mit-erika-enterprise-rtos-osek/

Erika Enterprise ist ein open source OSEK konformes Echtzeitbetriebssystem (RTOS), das den STM32F4-Discovery Controller unterstützt. Außerdem gibt es eine eclipse Integration, sodass es möglich ist, Software direkt in der IDE zu entwickeln. In Kombination mit dem GNU ARM Eclipse Plugin und dem stlink Debugger/Programmer, sowie den GNU Tools for ARM Embedded Processors, wird eclipse zu einer Entwicklungsumgebung, die neben der eigentlichen Entwicklung des Codes, auch das Flashen und Debuggen auf der Hardware (in-circuit-debugging) von ERIKA RTOS basierten Anwendugen für den STM32F4-Discovery Controller ermöglicht. ERIKA kann auf der Projektseite runtergeladen werden. Um weitere Informationen zu der Installation bzw. Einrichtung der Plugins oder ERIKA zu erhalten, schauen Sie bitte in die entsprechenden Wikis und Foren auf den verlinkten Seiten.

ERIKA wird über ein oil-File konfiguriert, welches die Parameter für den Kernel enthält. In dieser Datei gibt es verschiedene Einstellungsmöglichkeiten, die das Verhalten des Kernels beeinflussen. Neben diesen werden aber auch Abhängigkeiten zu externen Bibliotheken, wie beispielsweise dem Microcontroller Software Interface Standard (CMSIS), festgelegt.
Der Kernel unterstützt verschiedene Klassen von tasks (basic und extended tasks). Im Vergleich zu den basic tasks, unterstützen die extended tasks eine eventgesteuerte Synchronisation. Mehr Informationen zu den Klassen gibt es in der offiziellen Dokumentation, an dieser Stelle soll nicht weiter auf die Unterschiede eingegangen werden.

Der folgende Abschnitt beschreibt die Verwendung von ERIKA Enterprise mit extended tasks, also einem eventgesteuerten Scheduling auf dem STM32F4 Controller. Um diese Kernelkonfiguration einzusetzten, gibt es ein paar Parameter, die in der Konfigrationsdatei (*.oil) gesetzt werden müssen. Eine entsprechende Konfiguration sieht wie folgt aus:
   

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;
};

Der STM32F4-discovery verfügt über einen ARM Cortex-M4 Prozessor, welcher mit 168 MHz getaktet wird. Der genaue Takt hängt von dem verwendeten Modell ab, in diesem  Beispiel wurde ein STM32F407VG verwendet. Der APP_SRC Paramter listet die *.c Dateien auf, die mit dem Kernel kompiliert werden sollen. Um mehrere Dateien anzugeben, dann der Parameter einfach wiederholt werden. Die Entwicklung basiert auf dem GNU ARM Compiler und Debugger, deshalb wird der Parameter COMPILER_TYPE für die GNU toolchain konfiguriert. Um extended tasks zu verwenden, muss ein sogenannter MULTI_STACK mit einer statischen Größe konfiguriert werden. Der letzte Block in dem Ausschnitt der Konfigurationsdatei setzt den Controller.
Die Konfigurationsdatei wird außerdem dazu verwendet externe Bibliotheken, wie beispielsweise den ARM spezifischen CMSIS, einzubinden. Der folgende Ausschnitt zeigt, wie diese Bibliotheken eingebunden werden:

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";
};

Die Parameter sind spezifisch für den STM32F4 Controller. Als nächstes wird das Scheduling des ERIKA Kernels konfiguriert. Der Kernel unterstützt insgesamt vier Klassen, die das Scheduling beieinflussen, sogenannte conformance classes (ECC1, ECC2, BCC1, BCC2). Die BCC Klassen unterstützen basic tasks, während die ECC Klassen die extended tasks unterstützen. Extended tasks erweitern die basic tasks um die Eigenschaft, durch events aktiviert zu werden. Für weitere Informationen zu diesen Klassen, schauen Sie bitte in das ERIKA reference manual. Um in der Konfigurationsdatei eine conformance class zu definieren, wird der folgende Paramter gesetzt:

KERNEL_TYPE = ECC1;

Als nächstes werden events und tasks definiert. In diesem Beispiel wird ein task definiert, der über ein event aktiviert werden kann. Dieser Task wird setPwmTask heißen und auf ein pwmEvent reagieren. Generell können tasks auf mehrere events reagieren. Diese müssen nur entsprechend in der Konfigurationsdatei festgelegt werden. Eine entsprechende Konfiguration eines tasks mit einem event sieht wie folgt aus:

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;
};

Anschließend werden der task und das event in der Implementierung deklariert, damit der task durch die Software aktiviert werden kann:

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
}

Der letzte Schritt ist die Initialisierung des Kernels. Wurde diese durchgeführt, kann das eventbasierte Scheduling verwendet werden. Der folgende Codeausschnitt zeigt wie die Initialisierung des Kernels und die periodische Aktivierung des setPwmTask durch das pwmEvent durchgeführt werden kann:

#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));
  }
}

Mit ERIKA Enterprise bekommt man ein sehr schönes open source Echtzeitbetriebssystem, welche direkt in die eclipse IDE integriert werden kann. Die STM32F4 Unterstützung bietet einem alle netten features eines RTOS auf diesem Controller.

SRF02 Ultraschallsensoren am STM32F4-Discovery

Dieser Blog ist umgezogen: http://scholtyssek.org/blog/de/2014/08/24/srf02-ultraschallsensoren-am-stm32f4-discovery/

Der SRF02 Ultrasonic range finder ist ein Ultraschallsensor, der über nur eine Membran verfügt aber trotzdem als Tranceiver funktioniert. Dadurch ist der Sensor praktischerweise von seiner Bauart her sehr kompakt und eignet sich besonders für Einsatzbereiche, in denen es aus die Größe des Sensors ankommt. Der Sensor detektiert Hindernisse in einem Bereich von 16 - 6000 cm. Die benötigte Spannungsversorgung von 5 V erlaubt es, dass des Sensor an einer Vielzahl von  Mikroprozessoren direkt angeschlossen werden kann.
Der Sensor kann per serieller Leitung (UART) oder per i²c Bus (oder aus I2C Bus genannt) angesteuert und ausgelesen werden. Im Folgenden wird die Ansteuerung per I2C beschrieben, da dies den charmanten Vorteil hat, dass lediglich zwei Leitungen (SDA und SCL) auf dem Controller (auch bei der Verwendung mehrerer Sensoren) zur Kommunikation benötigt werden. SDA ist dabei die Datenleitung und SCL die Taktleitung. Komponenten am i²c Bus werden über eine eindeutige Adresse identifiziert. Im folgenden zeige ich beispielhaft den Einsatz von insgesamt vier SRF02 Ultraschallsensoren an einem i²c Bus, inklusive der vorhergehenden Konfiguration der eindeutigen Adressen. Als Mastercontroller wird ein ARM basierter STM32F4-Discovery (STM32F407VG) eingesetzt.

Xbox360 Controller C Integration

Dieser Blog ist umgezugen: http://scholtyssek.org/blog/de/2014/08/16/xbox360-controller-c-integration/

Heute habe ich ein Stück Code geschrieben, der es einfach ermöglicht, einen Xbox360 Controller  in ein C Programm zu integrieren. Der Code liest die Werte der Achsen und Knöpfe des Controllers aus und gibt diese Informationen auf dem Bildschirm aus. Das folgende Bild zeigt die Ausgabe dieser Informationen:

In diesem Fall wurden die Tasten "A" and "TL", welche die "top left" Taste ist, gedrückt. Das Projekt trägt den Namen xboxControllerClient und kann in meinem Repository unter https://code.google.com/p/scholtyssek-blogspot/ untergeladen werden.

Rigol DS1052D und Open Logic Sniffer

Dieser Blog ist umgezogen: http://scholtyssek.org/blog/de/2014/07/29/rigol-ds1052d-und-open-logic-sniffer/

Heute habe ich den Logic Analyzer des Rigol DS1052D ausprobiert und festgestellt, dass dieser die aufgezeichneten Signale nicht auswertet. Da es sich bei dem Oszilloskop um ein Gerät im unteren Preissegment handelt, ist das auch in Ordnung. Die gemessenen Signale können allerdings leicht exportiert und auf einem PC mit dem Open Source Tool Open Logic Sniffer ausgewertet werden. Damit das funktioniert, müssen diese im CSV Format exportiert und im Anschluss konvertiert werden. Die folgenden Schritte zeigen, dass es tatsächlich sehr einfach ist.

STM32F4 basierter Mecanum Roboter mit Odometrie

Dieser Blog ist umgezogen: http://scholtyssek.org/blog/de/2014/07/27/stm32f4-basierter-mecanum-roboter-mit-odometrie/

In den vergangenen Monaten habe ich mich in den STM32F4-Controller eingearbeitet, um ein (Roboter-)Projekt damit umzusetzen. Genauer gesagt, handelt es sich um einen Roboter, der über Mecanum-Räder (oder auch swedish-wheels) verfügt. Diese Räder zeichnen sich deshalb besonders aus, weil auf dem Außenring der Felge, Gummiwalzen im 45° Winkel angeordnet sind, welche sich passiv über den Untergrund abrollen. Dadurch verfügt der Roboter über einen weiteren Freiheitsgrad. Das bedeutet, dass der Roboter - trotz fehlender Lenkachse - alle Richtungen (X, Y und Θ) auf der Ebene erreichen kann und deshalb die maximale Bewegungsfreiheit hat. X und Y entspricht dabei Bewegungen in die die entsprechenden Richtungen und Θ bezeichnet die Drehbewegung des Roboters.

Der Roboter

Bei dem Roboter handelt es  sich um den Nexus 4WD. Dieser verfügt über vier Faulhaber Motoren, welche direkt mit Inkrementalgebern ausgestattet sind, (Ultraschall-)Distanzsensoren und einem Arduino Controller, auf dem auch direkt passende Motortreiber vorhanden sind. Die 12 V Gleichstrommotoren, wie aus die restliche Hardware werden über einen Akku versorgt, der mit einem gewöhnlichen Tamiya Stecker angeschlossen wird.

Da ich mich für den STM32F4 entschieden habe, wurden einige Modifikationen an dem Roboter durchgeführt. Insbesondere der Arduino-Controller wurde durch den STM32F4 ausgetauscht, was aber zur Folge hatte, dass die Motortreiber, welche fest auf der Platine des Arduinos verbaut waren, ebenfalls aus dem Roboter entfernt wurden. Deshalb musste eine neue Motorsteuerung mit entsprechenden Treiber (H-Brücken) entwickelt werden, damit die Motoren richtig angesteuert werden können. Zusätzlich zu den vorhandenen Sensoren und Aktoren, wurde der Roboter mit einem Gyroskop ausgestattet, damit die Orientierung, also die Drehbewegungen des Roboters, im Rahmen der Odometrie gemessen werden kann.

Die Abbildung1 und Abbildung2 zeigen den Roboter mit geöffnetem Chassis. Man kann die vier Mecanum-Räder erkennen, welche an den Wellen der Motoren befestigt sind. Außerdem sieht man - trotz der vielen Leitungen - die Hardwarekomponenten und den Akku. Abbildung2 stellt den Roboter noch einmal in der Vogelperspektive dar und Abbildung3 hebt die individuell nachgerüstete Hardware besonders hervor. 

Abbildung1: Nexus 4WD (Heckansicht)

Yakindu Statechart Tools Arduino Integration

Dieser Blog ist umgezogen: http://scholtyssek.org/blog/2013/10/21/yakindu-statechart-tools-arduino-integration/

Die Yakindu Statechart Tools sind dafür prädestiniert, Systemverhalten als Statemachine zu beschreiben, um anschließend Quellcode aus dieser Beschreibung zu generieren. Der Code kann in Java, C oder C++ generiert werden. Wir wollten den Codegenerator dazu einsetzen, Quellcode für eingebettete Systeme zu generieren, deshalb haben wir und für den Arduino Uno als Plattform entschieden. Dafür haben wir das TrafficLight Beispiel modifiziert und etwas simplen glue code (also Verbindungscode zwischen der Hardware und dem Generat) geschrieben, um die timer und die I/Os des Controllers zu mappen. Außerdem haben wir eine Ampel mit LEDs auf einer kleinen Platine entworfen, welche die Signale des Arduinos repräsentiert. Im Anhang befindet sich ein eagle-Schaltplan, sodass diese Platine leicht nachgebaut werden kann.
Das Beispiel wurde direkt für den AVR ATMEGA328P-PU Prozessor entwickelt, da dieser sich auf dem Arduino Uno befinden. Es ist ebenfalls möglich, die Programmierbibliothek für den Arduino zu verwenden, um die Ampelsteuerung zu integrieren, allerdings haben wir uns bewusst dagegen entschieden, da wir zeigen wollen, dass wir eine ganze Prozessorfamilie unterstützen können, weil die eigentliche Implementierung losgelöst von dem Generat ist. Aus diesem Grund benutzt die Implementierung die AVR-Bibliothek direkt (avr-libc).