Fork me on GitHub

Quadrofly Building a quadrocopter

5Feb/130

I2C mit dem Raspberry PI

I2C Kommunikation mit dem Raspberry PI

Da ich sehr gute Erfahrungen mit der I2C-Kommunikation zwischen den Komponenten auf dem Quadrocopter gemacht habe und der Raspberry PI über seine GPIO I2C zur Verfügung stellt, kam mir die Idee, das Telemetrie-Modul mit einem Raspberry PI auszustatten. So kann ich I2C-Befehle per SSH auf den Bus schreiben und später einen Webserver implementieren um Telemetriedaten auf dem Quadrocopter in Echtzeit anzuzeigen und Variablen während der Laufzeit anzupassen.

Zum Testen der I2C-Kommunikation habe ich mir folgende Schaltung mit einem ATTiny2313 auf einem Breadboard gesteckt:

ATTiny I2C Schaltung

ATTiny I2C Schaltung

Anschließend habe ich eine vorhandene I2C-Softwareimplementierung angepasst und auf den ATTiny geflasht. Die erweiterte Firmware gibt es bei GitHub: https://github.com/ni-c/raspberry2c

Damit man die I2C-Schnittstelle auf dem Raspberry PI nutzen kann, muss man erst das dazugehörige Kernelmodul aktivieren. Dazu öffnet man die Datei /etc/modprobe.d/raspi-blacklist.conf:


$ sudo vi /etc/modprobe.d/raspi-blacklist.conf

sucht nach der Zeile:


blacklist i2c-bcm2708

und kommentiert sie aus:


#blacklist i2c-bcm2708

Dann kann man die benötigten Kernel-Module laden:


$ modprobe i2c-bcm2708
$ modprobe i2c_dev

Um komfortabel auf den I2C-Bus schreiben zu können, installiert man noch die I2C-Tools:


$ sudo apt-get install i2c-tools

Nun kann man sich die Geräte auf dem I2C-Bus 0 mit folgendem Befehl anzeigen lassen (Bei neueren Raspberry PI Modellen sind I2C-Bus 0 und 1 vertauscht, in diesem Fall liegt I2C-Bus 1 auf dem GPIO des Raspberry PI):


$ i2cdetect -y 0

0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- 1a -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Der ATTiny wurde unter der Adresse 0x1a gefunden. Um das I2C-Register des ATTinys auszugeben, benutzt man den Befehl i2cdump:


$ i2cdump -y 0 0x1a

Und um nun den Wert 0xff an Adresse 0x00 des Gerätes mit der Adresse 0x1a zu setzen und damit die LED anzuschalten führt man i2cset aus:


$ i2cset -y 0 0x1a 0x00 0xff

10Okt/120

Telemetrie mit RS-232 und Java

Da es beim Entwickeln der Algorithmen von großem Vorteil ist, die Werte der Sensoren und die Ergebnisse der Algorithmen in lesbarer Form angezeigt zu bekommen, loggt der Quadrocopter diese Daten über die UART-Schnittstelle des ATMega644. Zum Darstellen dieser Daten habe ich das Java-Programm Quadrometrics entwickelt, welches die Daten auf der seriellen Schnittstelle empfängt und in einem Swing-Fenster anzeigt.

Quadrometrics

Bis die Übertragung der Daten über Funk stattfindet, nutze ich den bereits vorhandenen Pegelwandler des Telemetriemoduls zur Pegelwandlung zwischen UART und RS-232.

Der nächste Schritt ist nun die Implementierung eines Rückkanals, um die Werte der Algorithmen zur Laufzeit anpassen zu können.

7Mrz/120

ATMega simuliert

ASM (CC BY-SA 2.0 PabloBD)

Da die Bauteile für meine RS-232-Schaltung immer noch nicht eingetroffen sind, ich die Software dafür aber bereits am Entwickeln bin, suchte ich eine Möglichkeit, den ATMega644 zu simulieren. Dabei bin ich auf das Tool Simulavr, welches für Windows und Linux zur Verfügung steht, gestoßen. Da man damit einen Mikrocontroller für die Software simulieren kann, konnte ich mit meinem Framework loslegen. Dieses ermöglicht die Ausgabe von Debug-Nachrichten über UART und in Simulavr.

Um das Programm in Simulavr zu testen, muss man die Präprozessordirektive #define SIMULAVR_AVAILABLE in der Datei main.h einkommentieren, damit die Unterstützung für den Simulator mit in die Software kompiliert wird.

Anschließend kann man den Quellcode mit make all kompilieren und die Software per Aufruf von simulavr --device atmega644a --file main.elf -W 0x20,- -m 10000000000 simulieren. --device gibt an, für welchen Mikrocontroller simuliert wird, mit --file wird das kompilierte Programm übergeben, -W 0x20,- hört auf den virtuellen Port in den die Software die Debug-Nachrichten schreibt und -m gibt die Anzahl der Millisekunden an, die unser Simulator simulieren soll.

Den kompletten Quellcode findet man bei GitHub: https://github.com/ni-c/quadrofly/tree/uart

Das Ergebnis sollte folgendermaßen aussehen:


$ simulavr --device atmega644a --file main.elf -W 0x20,- -m 10000000000
Hello debug!
Hello debug!

Ran too long. Terminated after 10000000000 simulated nanoseconds.

$