LAN to WLAN bridge

Posted by Thomas Weller on August 30, 2016
Raspberry Pi / No Comments

Background

Our training department had the issue to connect physical devices to a local test net (Ethernet) in a private address range (192.168.x.x). The participants shall also access that local Ethernet. This network has to travel, since we offer inhouse trainings. Unfortunately, the server is a SAP based machine and used by other departments as well, so it cannot move with the test net.

At customer sites, there’s often a guest WLAN available which allows Internet HTTP(S) traffic. That’s all our devices need, so the idea was born to create a LAN to WLAN bridge with the Raspberry Pi 2.

Network layout

Network Layout

The devices will get static IP addresses. In a first step, the participants will also set up static IP addresses. In a second step we might use DHCP to make it easier.

Connecting to the guest WLAN may involve difficulties: the WLAN may be protected by WPA which requires entering a key or maybe it’s an open WLAN and the registration is done on an internal website asking for credentials prior to getting Internet access. Therefore we must have a display, a keyboard and mouse and a browser. Raspbian brings a browser with the GUI, so that’s fine.

Things to consider

Normally, a WLAN connection will get a higher metric than a LAN connection, because it is considered as more expensive (in terms of cost, speed or latency). We should change this to make sure that the Raspberry will try connections on the WLAN first.

The users of the Raspberry are not familiar with it as hardware, nor with Linux to do lot of configuration or troubleshooting. Connecting to the WLAN and opening a browser is probably the maximum we can expect, so everything should be nice and easy, without too much noise. We have to set the timezone and do the keyboard configuration in advance.

The solution will be used by 3 trainers, each getting an identical setup. So it might be worth writing a single complete script to install everything.

The hardware

A Raspberry 2 or 3 should give a much better feeling on the Desktop compared to a Raspberry 1. Since we want to connect to WLAN, the Raspberry 3 seems to be the best choice.

The display needn’t be large, just enough to configure the WLAN connection and perhaps see something on the console. The official 7″ display is great, since it is supported out of the box and a nice housing is available. That display might even help us getting rid of the mouse, since it supports touch.

The keyboard could be a Bluetooth keyboard to avoid cable spaghetti.

The devices are powered over Ethernet. PoE switches are already available in our company.

Setting it up

  1. Download the latest version of Raspbian
  2. Flash the Raspbian image to SD card with Win32DiskImager
  3. Download the script
  4. Unzip it. You have 3 files now: lan2wlan.sh, asplash, splash.png
  5. Copy the 3 files onto the SD card
  6. Insert the SD card into the Pi
  7. Apply power
  8. The Raspberry will resize the partition and reboot
  9. Wait until the Desktop appears
  10. Connect to the Internet via LAN or WLAN
  11. Run the script from /boot
  12. Wait until it completed
  13. Reboot
  14. Test if everything works fine

Performance

What about the throughput of the solution? I tested using a DSL speed test website. My Internet should be 50 MBit/s / 10 MBit and I get realistic 47 MBit/s / 9.7 MBit/s with my normal PC. The Raspberry Pi 2 is connected to the WLAN with 132 MBit/s, so that should be fast enough to not limit the bandwidth during the test.

Connected with my Laptop on the test network, I get 34 MBit/s and 9.2 MBit/s. This is 72% for download and 94% for the upload. That’s fine and definitely enough for the intended test purposes.

German keyboard layout for Raspberry

Posted by Thomas Weller on Januar 24, 2016
Raspberry Pi / No Comments

I wanted to start some GPIO experiments with Raspberry on Raspbian, but I realized that the keyboard layout is not German, so that needs to be fixed first:

sudo dpkg-reconfigure keyboard-configuration

Warning: this will not work via SSH. You need a real keyboard to do that. Read below how to do it via a shell script.

This will query your keyboard settings. Choose

  • Generic 105-key (Intl) PC
  • Other
  • German
  • German – German (dead acute)
  • Right Alt (AltGr)
  • No compose key
  • Yes

It should looks like this:

You can also write a shell script that does that for you:

#!/bin/sh
sudo echo "XKBMODEL=\"pc105\"" | sudo tee /etc/default/keyboard > /dev/null
sudo echo "XKBLAYOUT=\"de\"" | sudo tee --append /etc/default/keyboard > /dev/null
sudo echo "XKBVARIANT=\"deadacute\"" | sudo tee --append /etc/default/keyboard > /dev/null
sudo echo "XKBOPTIONS=\"lv3:ralt_switch,terminate:ctrl_alt_bksp\"" | sudo tee --append /etc/default/keyboard > /dev/null
sudo echo "BACKSPACE=\"guess\"" | sudo tee --append /etc/default/keyboard > /dev/null

Tags:

Raspberry Pi: Definitiv kein Problem mit der Spannungsversorgung

Posted by Thomas Weller on November 22, 2013
Allgemein / No Comments

Die erste Konfiguration von Raspberry habe ich nur über das Netzwerk ohne externe Hardware vorgenommen. Hin und wieder startete sich der Raspberry jedoch neu. Der Fehler war schnell ausgemacht: die SD-Karte soll es angeblich gewesen sein. Mit anderen Netzteilen jedoch war der Betrieb der „fehlerhaften“ SD-Karte kein Problem.

Jetzt bin ich dabei RaspBMC auszuprobieren und ich habe sowohl HDMI als auch USB-Geräte angeschlossen. Doch leider startet sich der Raspberry jetzt spontan wieder neu. Und das trotz eines 3000 mA (!) Netzteils, das beinahe so viel kostete wie der Raspberry selbst.

Die Internetrecherche brachte zutage, dass der Raspberry nicht besonders viel Leistung über die USB-Buchsen liefern kann: also muss ein USB-Hub mit eigener Stromversorgung her. Zufällig hatte ich noch einen USB-Hub mit 2500 mA (!) hier.

Doch die Ernüchterung folgte bald: sowohl Maus als auch Tastatur sind extrem langsam. Bei der Tastatur bleiben Tasten „hängen“ und wiederholen sich. Internetrecherche: angeblich Probleme mit der Stromversorgung. Ich kann es langsam echt nicht mehr hören.

Nicht geholfen hat auch der Vorschlag für ein Script im Raspberry Forum. Ebenfalls erfolglos war der Beitrag zu einem Script in /etc/rc.local. Auch die Umstellung auf eine Bluetooth Tastatur unter Befolgung der Anleitung zur Einrichtung von Bluetooth-Tastaturen brachte keine Besserung. Zwar sind alle Schritte erfolgreich, tippen kann ich jedoch nicht. Ein Firmware Update habe ich bereits im Vorfeld durchgeführt.

Dann gibt es noch die Seite, die vorschlägt, man solle möglichst eine billige Tastatur nehmen. Da ich schon die billigste bei Reichelt erhältliche Tastatur nutze, fällt dieser Punkt wohl auch aus.

Ich frage mich echt langsam, ob ich da wohl ein Montagsmodell erwischt habe. Irgendwie ist das doch nicht normal…

Mein System:

Raspberry Pi Modell B, Seriennummer 000000000e2b0481
SanDisk Extreme III, Class 6
Linux raspbmc 3.10.19+ #600 PREEMPT Sat Nov 16 20:34:43 GMT 2013 armv6l GNU/Linux

Tags: , ,

Netzteile für den Raspberry

Posted by Thomas Weller on November 18, 2013
Raspberry Pi / 1 Comment

Bei den Problemen mit meiner SD-Karte, habe ich festgestellt, dass ein starkes Netzteil für den Raspberry nützlich sein kann. Das mitbestellte Netzteil RS 7263053 mit 1200 mA hielt gerade einmal ein paar Minuten durch. Mein Eigenbau aus einem Netzteil für Festplatten (2000 mA) mit zusammengelötetem Molex-MicroUSB-Adapter schaffte das spielend. Eine Dauerlösung konnte mein Eigenbau nicht bleiben, da ich das Netzteil in Zukunft wieder für Festplatten einsetzen möchte.

Ein weiterer Grund für den Kauf einiger Netzteile zum Test war die Tatsache, dass der Raspberry als Telefonanlage eingesetzt werden soll. Da wünsche ich mir Uptimes von mindestens 2 Monaten. So viel Zeit habe ich für die Testläufe nicht, daher wollte ich meine Tests auf etwa 7 Tage begrenzen.

Uptimes in der Übersicht (nicht repräsentativ, da geringe Anzahl Stichproben)

Netzteil Preis Stärke Uptime Testläufe
RS 7263053 6,29 € 1200 mA <10 Minuten > 10
Eigenbau -/- € 2000 mA > 20 Stunden 1
Innergie ADP-15AB AF 28,95 € + USB Kabel benötigt 3000 mA > 8 Tage 1
mumbi OTB CP0520 9,70 € + Adapter benötigt 2000 mA <10 Minuten 2
xubix 5,90 € + USB Kabel benötigt 2000 mA > 9 Tage 1

Das mit 28,95 € teuerste Netzteil in meinem Test ist das Innergie ADP-15AB AF, was allerdings auch 3000 mA liefern soll. Praktischerweise hat es eine USB-A-Buchse, wodurch man gleich ein passendes MicroUSB-Kabel anschließen kann. Bestellt habe ich es bei Reichelt. Nach acht Tagen im Dauerbetrieb habe ich den Test beendet.

Das xubix USB Ladegerät ohne weitere Typenbezeichnung enttäuscht schon bei der Lieferung. Anstatt der auf der Rechnung ausgewiesenen 2100 mAh (was völliger Quatsch ist), liefert es nur 2000 mA laut Aufdruck auf dem Steckernetzteil. Gekauft habe ich es bei Amazon. Bei der ersten Stichprobe war Putty plötzlich verschwunden und auch eine neue Verbindung konnte nicht hergestellt werden.Beim zweiten Testlauf hielt es dann über neun Tage durch, bis ich den Test beendete.

Das mumbi ist nicht nur vom Namen ähnlich zum xubix, es kommt auch mit fehlerhaften 2000 mAh daher, bleibt dann aber wenigstens bei dieser Zahl: 2000 mA. Vom Aussehen sind die beiden ebenfalls sehr ähnlich. Wenn das mumbi anstatt des Kabels eine USB-Buchse hätte, könnte man sie kaum auseinanderhalten. Bestellt habe ich dieses Netzteil bei Amazon. Getestet habe ich es bei der Installation von RaspBMC. In beiden Versuchen hat das mumbi keine 10 Minuten durchgehalten. Allerdings war hier auch der HDMI-Anschluss mit im Spiel, was bei den anderen Versuchen mangels Adapter nicht der Fall war.

Tags: ,

Schnelle SD-Karten mit dem Raspberry nutzen

Posted by Thomas Weller on Januar 15, 2013
Raspberry Pi / No Comments

Seit 7. Januar 2013 bin ich stolzer Besitzer eines Raspberry Pi. Mein erstes Projekt sollte Asterisk for Raspberry nutzen. Sehr weit bin ich allerdings nicht gekommen, denn der Raspberry unterbrach ziemlich früh die SSH-Verbindung und verweigerte sie dann. Ein Blick auf die Status-LEDs zeigt ein Bild von ständigen Reboots. Da es schon spät war und ich kein externes Display zum Überprüfen der Ursache hatte, unterbrach ich die Stomversorgung und ging erst mal ins Bett.

Am nächsten Tag sah die Situation schon wieder besser aus. Eingeloggt per SSH konnte ich sogar SMB-Support nachinstallieren und die Logdateien auf ein Netzlaufwerk kopieren:

sudo apt-get install cifs-utils
mount -t cifs /home/nas/ -o user=Xxx
cp -R /var/log/* /home/nas/

Während ich gerade dokumentierte, was ich alles so an Änderungen am System vornehme (man will ja später vielleicht mal jemandem erklären, was man gemacht hat), wurde die SSH-Verbindung wieder getrennt. Diesmal stehen die LEDs auf Stillstand. Spätestens jetzt fragte ich mich, warum der Raspberry keinen Reset-Knopf hat.

Eine Analyse der Logdateien zeigte keine Auffälligkeiten. Da ich die Zeitzonendaten und Uhrzeit noch vor den Reboots aktualisieren konnte, sollten Auffälligkeiten in den Logs wenigstens das aktuelle Datum tragen. Doch damit kam ich nicht weiter.

Ich probierte zunächst einmal ein Upgrade. Gemäß der Anleitung soll man beim ersten Mal ein wget durchführen. Bei Durchsicht der Logs habe ich allerdings festgestellt, dass raspbx-upgrade auf einem Image schon installiert war. Die Ausführung konnte allerdings gerade mal die Paketlisten aktualisieren, bevor die Verbindung wieder abbrach.

Der Zustand war einfach untragbar, daher sollte eine Google-Suche weiterhelfen. Ich fand zunächst die Beschreibung über ungeeignete Netzteile. Der eingebaute Watchdog (vermutlich in Hardware, Software würde ja nichts bringen) startet in einem solchen Fall den Raspberry neu. Das hört sich vernünftig an und würde auch zu meinen nicht vorhandenen Einträgen in den Logdateien passen.

Bei meinem Netzteil handelt es sich um ein RS 7263053 mit 1200 mA. Das ist zwar nicht exakt das auf der Liste der überprüften Geräte, aber immerhin nahe dran am Modell RS 7263069. Als Alternative hätte ich nur das Ladegerät meines Handys, was mit 1000 mA aber noch schwächer ist. Auch in meiner Sammlung an Steckernetzteilen befindet sich derzeit kein stärkeres Netzteil mit 5 Volt.

Ein Computernetzteil würde sicherlich ordentlich Power auf 5 Volt liefern. Bei der Gelegenheit fällt mir ein Netzteil für den temporären Anschluss von Festplatten ein: es hat 12 und 5 Volt und liefert 2000 mA. bevor ich mich jedoch ans Zusammenlöten einer eigenen USB-Stromversorgung mache, suche ich mal nach dem Problem im Internet.

Ein Spannungseinbruch und damit verbundene Instabilitäten treten ja meist bei hoher Stromlast auf. Ich frage mich, woher die Stromaufnahme kommen mag, denn USB-Geräte habe ich noch gar nicht angeschlossen. Auch Ethernet sollte ja einen konstanten Wert haben. Einzig die SD-Karte von SanDisk könnte ich mir als Übeltäter vorstellen. Derzeit nutze ich eine 8 GB SanDisk Extreme III Class 6. Es gibt auf jeden Fall Warnungen, Karten von SanDisk einzusetzen, z.B. von Alexander Langer. Ein Umtauschen der ist bei mir eher nicht möglich, da ich eine Karte aus meiner Fotokamera recycled habe.

Natürlich ist die Fehlfunktion theoretisch nicht auf SanDisk beschränkt. Auch Intenso, Extrememory, Transcend, DeLock, Hama, Kingston, Platinum, Samsung oder Verbatim können betroffen sein. Ebenfalls sagt die Geschwindigkeitsklasse nichts über Fehler aus auch Class 8 und Class 10 SD-Karten sind sicherlich von dem Problem betroffen.

Was ich allerdings nicht glauben kann, ist, dass der Herstellungsprozess die Eigenschaften so verändert, dass die Karte nicht mehr funktioniert. Warum gibt es die Probleme dann mit Foto- und Videokameras nicht? Was ich mir wiederum gut vorstellen kann ist, dass eine schnelle SD Karte entsprechend viel Leistung benötigt, ggf. auch kurzfristig. Dadurch könnte die Spannung einbrechen und diverse Nebenwirkungen auslösen.

Also kam ich zum Schluss, dass ich mal die Spannung beobachten sollte. Ein Multimeter bringt in solchen Fällen jedoch nicht viel, da sie Schwankung kurzzeitig auftreten kann. Mein Oszilloskop ist aufgrund seltenen Gebrauchs derzeit als Dauerleihgabe verliehen. Da muss ich wohl noch ein bisschen Geduld haben.

Für einen kurzfristigen Versuch blieb mir nur die Lösung mit meinem Netzteil für externe Festplatten. Ein getöteter Molex Stecker liefert mit den Anschlüssen rot und schwarz 5 Volt. Für die Konvertierung auf Micro-USB musste ein USB-MicroUSB-Adapter sein Leben lassen. Die stromführenden Leitungen sind ebenfalls rot und schwarz. Tipp, wenn die USB-Kabel zu dünn für die Abisolierzange sind: man kann sie oft auch mit den Fingernägeln abisolieren. Mit etwas rotem und schwarzem Schrumpfschlauch zur gegenseitigen Isolierung sieht der Molex-MicroUSB-Adapter gar nicht so schlecht aus.

Messen lässt sich am MicroUSB-Anschluss ohne weitere Adapter auf größere USB-Arten auch nichts, daher wagte ich den Versuch am lebenden Objekt. Der Raspberry bootete.

Ein Aufruf von raspbx-upgrade sollte sowohl auf dem Netzwerk als auch auf der SD-Karte für etwas Traffic sorgen. Mit einer zweiten SSH-Session beobachtete ich die Aktivitäten mit dem Befehl top. Sollte die Verbindung abbrechen, sehe ich bei top auch die zuletzt gemessene Uptime.

Die Übertragung der 103 MB Daten für das Upgrade klappte problemlos. Auch bei der anschließenden Installation der Pakete und Load-Werten über 1,0 blieb das System stabil. Insgesamt erreichte ich mit dem selbstgebastelten Netzteil eine nie zuvor dagewesene Uptime von Minuten. Hier der Screenshot von top nach Abschluss der Installation:

Auch ein anschließendes

cat /dev/zero > sdtest

was eine Menge Daten (in diesem Fall 1,9 GB) schreibt, konnte dem Raspberry nichts mehr anhaben. In diesem Szenario stieg die Last noch weiter:

Fazit: das Problem mit den SD-Karten lässt sich ggf. durch ein besseres Netzteil beheben. Derzeit offen bleibt die Frage, ob der Raspberry die hohen Ströme auch längerfristig aushält, beispielsweise wenn noch zusätzliche USB-Geräte angeschlossen werden.

Netzteile mit mehr als 1200 mA sind nicht gerade häufig. Es gibt zum Beispiel das Innergie ADP15-AB AF bei Reichelt für knapp 30 Euro. Immerhin hat es zwei Ausgänge, so dass es vielleicht für zwei Raspberries reicht. Bei Conrad habe ich das mit 16 Euro günstigere HN Power HNP-USBAC-DUO gefunden. Diverse Händler bei Amazon liefern auch schon ab 6 Euro, wobei ich mich bei den Preisen frage, wie stabil die Spannung dort auch unter Normallast ist. Ich habe mal ein paar Netzteile bestellt und werde die Ergebnisse in weiteren Artikeln berichten.

Tags: , , , , ,

Chronos Flying Mouse im Praxiseinsatz

Posted by Thomas Weller on März 12, 2012
eZ430 Chronos / No Comments

Die Chronos Flying Mouse hat mich derart fasziniert, dass ich sie tatsächlich für eine meiner Präsentationen einsetzen wollte. Doch beim Üben der Präsentation fiel mir auf, dass die Flying Mouse auch bei unterschiedlichsten Einstellungen häufig mehrfach hintereinander klickt. Das ist in Powerpoint natürlich ärgerlich, denn wer mag schon viele Folien auf einmal überspringen?

Eine kleine Änderung am Source Code ermöglichte mir, eine Verzögerung von fünf Sekunden einzubauen. Dazu habe ich in der Datei transform.cpp eine neue Variable namens last_click_time hinzugefügt und in der Methode transform() entsprechend ausgewertet:

if (been_clicking == 1)
{
if (static_cast<int32>(GetTickCount()) - last_click_time > 5000)
{
SetCursorPos(last_stable_pos.x, last_stable_pos.y);
click_mouse(MOUSEEVENTF_LEFTDOWN);
click_mouse(MOUSEEVENTF_LEFTUP);
last_click_time = static_cast<int32>(GetTickCount());
}
}

Auf diese Art muss zwischen zwei Klicks mindestens fünf Sekunden liegen.

Beim Test auf meinem Rechner zu Hause führte dies zu sehr brauchbaren Ergebnissen. Beim tatsächlichen Vortrag traten allerdings Schwierigkeiten auf. Ich vermute, dass es an der Referentenansicht über zwei Bildschirme lag. Klickt man mit der Maus in der Referentenansicht, sind die Aktionen abhängig von der Mausposition. Nur ein Klick auf die Folie selbst schaltet weiter.

Ich muss wohl noch weitere Änderungen vornehmen, damit ich zuverlässig mit der Flying Mouse präsentieren kann. Eine Idee dafür habe ich schon: im nächsten Anlauf werde ich Tastendrücke an Powerpoint absetzen. Den Quellcode stelle ich auf jeden Fall wieder hier zur Verfügung.

Tags: , , ,

Upgrade auf Code Composer Studio 5

Posted by Thomas Weller on Februar 12, 2012
eZ430 Chronos / No Comments

Mein Bruder teilte mir mit, dass die neue Version des Code Composer Studios (Version 5) deutlich schneller arbeitet als die im Original mit der eZ430 Chronos mitgelieferte Version 4. Darum habe ich mir das 1,2 GB große Paket von Texas Instruments heruntergeladen und installiert.

Das Ergebnis ist wirklich beeindruckend. Die Debug-Geschwindigkeit ist wirklich signifikant gestiegen. Bislang dachte ich, die Uhr sei so langsam, aber offensichtlich lag es nicht an der Hardware sondern an der Entwicklungsumgebung.

Die Free-Edition ist ausreichend, um MSP430 Projekte zu erzeugen. Die Einschränkung liegt hauptsächlich in der Menge an Binärcode, die erzeugt werden kann. Die Grenze liegt bei 16 kB. Texas Instruments verlangt für den Download eine Registrierung, bei der man einige persönliche Daten preisgeben muss.

Verglichen mit der Erstellung des Hello World Projekts in Code Composer Studio 4 ist auch die Anzahl der Schritte zur Erstellung des Hello World Beispiels deutlich reduziert:

Beim Update geht leider die vorprogrammierte Firmware für die eZ Chronos verloren und befindet sich nicht mehr im Workspace. Wie bereits zuvor beschrieben, lässt sich diese aber wieder herunterladen.

Tags:

Original Firmware aufspielen

Posted by Thomas Weller on Februar 06, 2012
eZ430 Chronos / No Comments

Hat man die eZ Chronos erst einmal umprogrammiert, ist der Speicher auf der Uhr erst einmal überschrieben. Wenn man dann nette Zusatzprogramme wie die Chronos Flying Mouse findet und ausprobieren will, muss man die Original Firmware wieder aufspielen.

Dazu lädt man zunächst die aktuelle Version der Firmware von Texas Instruments herunter. Das Projekt kann dann von seinem Installationspfad (C:\Program Files (x86)\Texas Instruments\eZ430-Chronos\Software Projects\Chronos Watch\CCS\Sports Watch) in Eclipse importiert werden. Beim Importieren sollte man zumindest auf Windows 7 Systemen den Zusatz „Copy into workspace“ auswählen, da ansonten der Compile-Vorgang aufgrund unzureichender Rechte fehlschlagen kann.

Da die Firmware noch für Compiler-Version 3.1 geschrieben wurde, ergibt dies ein Warning beim Übersetzen.  Man kann aber auch die Compiler-Version auf 4.0 festlegen. Vor dem Compilieren wählt man noch die passende Konfiguration (in meinem Fall die 433 MHz Variante) und spielt die Firmware wieder auf.

Und so sieht das dann im Code Composer Studio (Version 5) aus:

 

Tags: ,

Hello World

Posted by Thomas Weller on Januar 31, 2012
eZ430 Chronos / No Comments

Nach der Untersuchung, welche Display-Segmente sich an welcher Adresse befinden, war es ein einfaches, das Display mit dem Schriftzug „Hello World“ zu versehen. Allerdings ist das Display typischerweise nicht in der Lage, zweimal fünf Buchstaben anzuzeigen. In diesem Fall lassen sich die beiden Ls jedoch in einer 7-Segment-Anzeige unterbringen und für die Lesbarkeit habe ich das W auf 1 1/2 7-Segment-Anzeigen verteilt, was auch nicht immer möglich ist.

Zunächst die Schritte in der Entwicklungsumgebung Code Composer Studio 4.

Hier ist der Code für main.c, basierend auf dem spanischen Original, aber an der ein oder anderen Stelle optimiert.
// Hello World
// Description: Shows "hEllo WorLd"

#include "cc430x613x.h"

void main(void) {
unsigned char * lcdmem;

// Clear entire display memory
LCDBMEMCTL |= LCDCLRBM + LCDCLRM;

// LCD_FREQ = ACLK/16/8 = 256Hz
// Frame frequency = 256Hz/4 = 64Hz, LCD mux 4, LCD on
LCDBCTL0 = (LCDDIV0 + LCDDIV1 + LCDDIV2 + LCDDIV3) | (LCDPRE0 + LCDPRE1)
| LCD4MUX | LCDON;

// LCB_BLK_FREQ = ACLK/8/4096 = 1Hz
LCDBBLKCTL = LCDBLKPRE0 | LCDBLKPRE1 | LCDBLKDIV0 | LCDBLKDIV1 | LCDBLKDIV2
| LCDBLKMOD0;

// I/O to COM outputs
P5SEL |= (BIT5 | BIT6 | BIT7);
P5DIR |= (BIT5 | BIT6 | BIT7);

// Activate LCD output
LCDBPCTL0 = 0xFFFF; // Select LCD segments S0-S15
LCDBPCTL1 = 0x00FF; // Select LCD segments S16-S22

lcdmem = (unsigned char *) 0x0A21;
*lcdmem = BIT0 + BIT1 + BIT2 + BIT6; // "h"
*(++lcdmem) = BIT0 + BIT1 + BIT2 + BIT4 + BIT7; // "E"
*(++lcdmem) = BIT0 + BIT2 + BIT5 + BIT6; // "ll"
lcdmem = (unsigned char *) 0x0A25;
*lcdmem = BIT1 + BIT2 + BIT6 + BIT7; // "o"

lcdmem = (unsigned char *) 0x0A2B;
*lcdmem = BIT6 + BIT2 + BIT3 + BIT7 + BIT4 + BIT1; // "W"
*(--lcdmem) = BIT2 + BIT3 + BIT5 + BIT6; // "o"
*(--lcdmem) = BIT6 + BIT5; // "r"
*(--lcdmem) = BIT4 + BIT6 + BIT3; // "L"
*(--lcdmem) = BIT1 + BIT2 + BIT3 + BIT6 + BIT5; // "d"

__no_operation(); // For debugger
}

Das Ergebnis auf der Uhr:

Das Display auf diese Art zur Anzeige zu bringen ist auf Dauer allerdings mühselig. Ich werde mir wohl als nächstes ein paar Hilfsfunktionen programmieren, die mir den Aufwand reduzieren.

Tags: , ,

Vorbereitung von Hello World

Posted by Thomas Weller on Januar 02, 2012
eZ430 Chronos / 1 Comment

Normalerweise fängt man eine neue Programmierumgebung, eine neue Programmiersprache oder eine neue Hardware mit einem Hello-World-Projekt an. Doch im Falle der programmierbaren Uhr eZ430 Chronos ist das nicht so einfach. Glücklicherweise fand ich auf einer spanischen Webseite eine Abwandlung von Hello World, nämlich Hi Earth. Meine Bemühungen, daraus ein Hello World zu machen waren nicht sonderlich erfolgreich, weil ich nicht wusste, wie das Display genau angesteuert wird.

Also musste ich für die Vorbereitung von Hello World zunächst die Belegung des Displays herausfinden. Dazu muss man zunächst die Register des Displays überhaupt kennen. Hier hilft Texas Instruments mit einem PDF Dokument. Auf Seite 38 steht, dass der Offset für das Display selbst bei 0x0A00 liegt. Weitere 0x20 später fängt der LCD Speicher an und reicht bis 0x2D. In einer einfachen Schleife habe ich dann die Segmente nacheinander eingeschaltet und bin im Debugger Schritt für Schritt durchgegangen.

// Display Test
// Description: Activates all segments on the display
#include "cc430x613x.h"
#include <string.h>
void main(void)
{
unsigned char * lcdmem;
    int i;
    // Clear entire display memory
    LCDBMEMCTL |= LCDCLRBM + LCDCLRM;
    // LCD_FREQ = ACLK/16/8 = 256Hz
    // Frame frequency = 256Hz/4 = 64Hz, LCD mux 4, LCD on
    LCDBCTL0 = (LCDDIV0 + LCDDIV1 + LCDDIV2 + LCDDIV3) | (LCDPRE0 + LCDPRE1) | LCD4MUX | LCDON;
    // LCB_BLK_FREQ = ACLK/8/4096 = 1Hz
    LCDBBLKCTL = LCDBLKPRE0 | LCDBLKPRE1 | LCDBLKDIV0 | LCDBLKDIV1 | LCDBLKDIV2 | LCDBLKMOD0;
    // I/O to COM outputs
    P5SEL |= (BIT5 | BIT6 | BIT7);
    P5DIR |= (BIT5 | BIT6 | BIT7);
    // Activate LCD output
    LCDBPCTL0 = 0xFFFF; // Select LCD segments S0-S15
    LCDBPCTL1 = 0x00FF; // Select LCD segments S16-S22
    // Loop through all display memory
    for ( i=0x0A20;i<0xA2D;i++)
    {
        lcdmem = (unsigned char *)i;
        // Set one bit after another
        // so that we can see during debugging which one is activated
        *lcdmem = (unsigned char)(*lcdmem | (BIT0));
        *lcdmem = (unsigned char)(*lcdmem | (BIT1));
        *lcdmem = (unsigned char)(*lcdmem | (BIT2));
        *lcdmem = (unsigned char)(*lcdmem | (BIT3));
        *lcdmem = (unsigned char)(*lcdmem | (BIT4));
        *lcdmem = (unsigned char)(*lcdmem | (BIT5));
        *lcdmem = (unsigned char)(*lcdmem | (BIT6));
        *lcdmem = (unsigned char)(*lcdmem | (BIT7));
    }
    __no_operation(); // For debugger
}

Das Ergebnis ist ein Bildschirm, bei dem alle Segmente aktiviert sind. Wichtiger ist jedoch der Weg dorthin im Debugger, so dass man nachvollziehen kann, welches Segment gerade aktiviert wurde.

Auf diese Art erhält man eine Zuordnungstabelle, die in etwa dem Handbuch (Seite 77, Figure 4-25) entspricht, wenn man weiß, wie man die Adressen zuordnen muss.

Mit dieser Tabelle ist es nun möglich, das Hello World Beispiel zu implementieren.

Tags: , ,