Die STM32F10x Prozessor-Serie hat einen eingebauten Watchdog-Timer, die bei einem Programmfehler den Prozessor wieder auf den "Boden" zurückholen kann. Wie funktioniert das jetzt ? Hierzu gibts eine eigene Clock von 40kHz die als Basisclock verwendet wird - unabhängig von der Quarzbeschaltung. Man muss nur den Frequenzteiler mit IWDG_SetPrescaler programmieren und den Zählerwert ab wann er denn den Prozessor resettet. Sobald der Zählerwert erreicht ist, wird ein Reset ausgelöst.

Dies kann man verhindern indem man einfach den Call IWDG_ReloadCounter(); innerhalb der IWDG-Zeit aufruft.

#include "stm32f10x_iwdg.h" um die passenden defines zu haben

/* Watchdog Test - Base frequency 40kHz */
    IWDG_WriteAccessCmd(IWDG_WriteAccess_Enable);
    IWDG_SetPrescaler(IWDG_Prescaler_256);
    IWDG_SetReload(3000);    // should be about 1/256s * 3000 should be about 20s

//Calculate the frequency in s : wd-time =  1 / (40kHz/prescaler) * reload value
    IWDG_ReloadCounter();
    IWDG_Enable();

while(1)
    {
        blink_yellow();                        // let the main program do something
        delay_ms(1000);
        IWDG_ReloadCounter();// and call the wdg
    }

Das wars. Den call IWDG_ReloadCounter(); muss man geschickt in der Hauptschleife des Programms unterbringen wo es eine Chance gibt dass sich ein Prozess etc. aufhängen könnte. Sinnvoll ist dies bei embedded Applikationen die nicht stehenbleiben dürfen z.B. Alarmanlage ;-). Es gibt übrigens auch eine Window Watchdog Funktion die einen Analogwert überwacht. Auch sehr nützlich.

Einleitung

Für meine Hausautomatisierung verwende ich den CAN Bus mit 8 Byte-Telegrammlänge. Das CAN-Protokoll ist für kurze Botschaften perfekt konzipiert. Für höherwertige Funktionen wie Alarmanlagenpanels oder Anzeigedisplays etc. benötige ich aber längere Botschaften. Nach etwas Recherche kommt mir das ISO-TP Protokoll gerade richtig. Es ist einfach, man kann es leicht in Microcontrollern unterbringen und es ist einigermaßen effizient. Später gibts hier eine ISO-TP Library für den STM32 - nur Geduld.

Wie funktioniert ISO TP ?

Es basiert im Grunde auf der gleichen Basis wie das "Standard"-CAN-Protokoll, nur werden Teile der Nutzdaten von 8 Bytes für das Protokoll verwendet. Man kann also weiterhin alle vorhandenen CAN-Stacks und Implementierungen verwenden. Die maximale Telegrammlänge kann bei ISO-TP genau 4095 Bytes betragen.

Telegrammtypen bei ISO-TP

1. SF - Single Frame (Code 0)

2. FF - First Frame (Code 1)

3. CF - Consecutive Frame (Code 2)

4. FC - Flow Control Frame (Code 3)

Zur Unterscheidung der verschiedenen Telegramme werden Protocoll Control Information Bytes (PCI-Byte) in den ersten Nutzbytes untergebracht.

Man unterscheidet bei der Übertragung zwischen Single-Frameformat oder Multiframeformat. Der Telegrammtyp wir immer in den ersten 4 Bits (MSb) kodiert und kann 0,1,2,3 als Wert tragen.

Singleframe-Format (Nutzdaten 1-7 Bytes)

Das bedeutet im ersten CAN-Nutzdatenbyte (Byte 0) wird der Typ und die Länge der Botschaft kodiert, Byte 1-7 enthält dann die Nutzdaten. Also klann man maximal 7 Bytes übertragen mit einem Telegram und man benötigt keine weiteren Telegramme. Immer bezogen auf die orginalen 8 CAN-Nutzdatenbytes).Die ersten 4 Bit kodieren den Telegrammtyp (also 0) diezweiten 4 Bit kodieren die Messagelänge (also 1..7)

Will man also genau 7 Bytes(01..07) übertragen muss der CAN Frame folgende Bytes tragen:

Beispiel : 07 01 02 03 04 05 06 08

0 = Singleframe 7 = Länge der Nutzdaten im Paket

01...07 Beispieldaten

Multiframe-Format (Nutzdaten 8-4095 Bytes)

Dieses Format wird verwendet wenn mehr als 7 und bis zu 4095 Bytes übertragen werden sollen. Beim Multiframeformat wird unterschieden zwischen Firstframe (FF-Paket) und Consecutive-Frame (CF-Paket).

Im FF-Paket sind die ersten beiden Bytes die PCI-Bytes. Die ersten 4 Bit kodieren dann den Telegrammtyp (0x02),die weiteren 12 Bits enthalten dann die Länge der gesamten Botschaft (daher auch nur 4095 Bytes Nutzdaten).

IM CF-Paket ist nur das erste Byte ein PCI-Byte, und enthält die Infomationüber den Pakettyp sowie eine fortlaufende Paketnummer die aber nur von 0 bis 15 zählt. Danach fängt der Counter wieder bei 0 an. So kann der Empfänger herausfinden ob Pakete verlorengegangen sind.

 

 

 

Weil ich nichts Brauchbares für Joomla gefunden habe, hatte ich mich entschlossen ein eigenes JOOMLA 3 Modul zu schreiben. Hierzu habe ich die JAVAScript Engine von Alex Gorbatchev in ein Modul gepackt. Nach der Installation durch den Extension Manager von JOOMLA kann man anfangen Artikel mit Quellcode-Anzeige zu schreiben.Hierzu muss man nur das jeweilige Modul enablen und gegebenfalls noch den Titel abschalten. Zunächst muss man das Modul in dem Artikel laden wo überhaupt Quelltext vorkommt, damit nicht IMMER die JAVASCRIPT Klassen geladen werden. Dies geschieht durch das loadmodule mod_sh tag. Danach muss man innerhalb des Artikels den Quellcode noch einschließen mit den pre tags. Die Programmiersprache wird mit dem brush Parameter eingestellt. Zur Auswahl stehen im Joomla Modul aktuell:

-brush:JScript
-brush:Java
-brush:CSharp
-brush:php
-brush:python
-brush:sql
-brush:xml

Weitere kann leicht hinzufügen, dann einfach die Javascript-Files z.B. shBrushBash.js etc im File /modules/mod_sh/tmpl/default.php hinzufügen. Die scripte die man nicht braucht sollte man entfernen, weil der ganze Code ja sonst auch geladen wird.

seit kurzem gibt es ein neues etwas schlankeres Modul. Siehe hier:  Syntaxhighlighter mit PRISM

Hier ist der Downloadlink zum Joomla Modul

  
/*
*
This is a JAVA programing example to demonstrate
the syntax highlighting and rendering within
a Joomla Site.
This is just for demonstration.
*
*/
package tutorial;
 
import com.opensymphony.xwork2.ActionSupport;
 
public class HelloWorld extends ActionSupport {
    private String name;
    public String getName() {
    return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public String execute() {
        name = "Hello, " + name + "!";
            return SUCCESS;
    }
}
 

Beagle Bone Black

mit angeschlossenem seriellem Terminal (blau = Ausgang grün =Eingang)

 

Einleitung

Dieses Board ist mit 86mm * 53mm recht klein und in etwa vergleichbar mit dem Raspberry Pi, also auch ein Minirechner mit Linux als OS - jedoch sehe ich die folgenden Vorteile:

Das Board braucht nur etwa 60% der Power eines Raspberry Pi. Wenn man den Rechner also dauerhaft als kleinen Dienstleister im Haus verwenden will, macht sich dies schon im Stromverbrauch bemerkbar. Aber ich hab es auch nachgemessen. Heraus kamen 500mA Stromaufnahme bei 5V. Keyboard, Maus und Bildschirm waren aber auch angeschlossen.

Betreibt man das Board nur am Ethernet-Netzwerk - ohne weitere USB-Geräte - verbraucht es nur etwa 310mA. Dies entspricht etwa 1.5W.

1GHz Taktrate mit dem TI Prozessor, 512MBRAMsowie 2GByte Onboard flash machen das ganze dann auch schon richtig luxuriös.

Mein Ziel ist es die bestehende Elektronik der Alarmanlage zu ersetzen, da die Hardware aber insbesondere die Software grottenschlecht sind - aber es gibt ja nicht so viele Anbieter mit Konfigurationssoftware auf dem Stand von Windows 3.11.... aaarrrrg. Wer so eine hat weiß welche gemeint ist.

Installation DEBIAN

Weil ich mich mit der Debian Distribution besser auskenne als mit Angstrom, musste ich erst mal das Angstrom Linux ersetzen. Nachfolgend noch ein paar Links wie das alles geht.

Hier findet sich ein fertiges bootbares Image sowie die Anleitung zur Installation:

http://www.armhf.com/index.php/boards/beaglebone-black/

Unter dem folgenden Weblink findet sich eine Beschreibung in deutscher Sprache.

http://www.welzels.de/blog/projekte/beaglebone/debian-auf-beaglebone-und-beaglebone-black-installieren/

Und hier findet sich alles zum Cross-Compilieren und Kernel bauen..

http://eewiki.net/display/linuxonarm/BeagleBone+Black

Meine erste Aktion ist es den CAN-Bus - der direkt am Prozessor zur Verfügung steht - auszuprobieren, weil dies für mein Ziel absolut erforderlich ist. Leider gibt’s dazu bisher noch wenige Informationsbruchstücke im Netz wie man den CAN Port unter Linux in Gang bringt.

CAN-BUS auf BeagleBone

Einen weiteren großen Vorteil hat die Beaglebone Version gegenüber dem Raspberry Pi. Er hat ein eingebautes CAN-Bus-Interface welches man nur noch mit einem CAN-Transceiver ergänzen muss. Zur einfachen Kommunikation mit anderen CAN Teilnehmern ist das Board perfekt. Auch als Datenlogger für CAN-Nachrichten eines Automobil CAN-Busses ist das Board perfekt, man muss jedoch darauf achten das man bei der Verarbeitung innerhalb des Anwendungsprogrammes nicht unabsichtlich den Durchsatz limitiert - z.B. durch Terminalausgaben ;-)

Nur der Port1 also CAN1 ist ohne Einschränkungen auf dem Beaglebone Black nutzbar, da der CAN2 Port aufgrund des Pin-MUX durch andere Devices (I2C2 und HDMI) verwendet wird.

Nachfolgend ist beschrieben wie das alles funktioniert.

http://www.embedded-things.com/bbb/enable-canbus-on-the-beaglebone-black/

alte Seite :(http://www.aero-box.co.uk/beaglebone-black#TOC-Enable-CANbus-device)

Kurzversion der Schritte:

1. Device-Tree Overlay File erstellen mit folgendem Befehl:

dtc -O dtb -o BB-DCAN1-00A0.dtbo -b 0 -@ BB-DCAN1-00A0.dts 

Dazu benötigt man ein DTS-Descriptionfile was dann mit dem Devicetree-Compiler übersetzt werden muss.

Hier ist das fertige DTS-File:BB-DCAN1-00A0.dts als Download

2. Compiliertes File in den Firmwareordner kopieren:

sudo cp BB-DCAN1-00A0.dtbo /lib/firmware 

3. CAN Module laden mit:

sudo modprobe can
sudo modprobe can-dev
sudo modprobe can-raw

4. Device aktivieren mit:

echo BB-DCAN1 > /sys/devices/bone_capemgr.*/slots 

5. Baudrate (125kHz) einstellen und CAN device starten mit:

sudo ip link set can0 up type can bitrate 125000
sudo ifconfig can0 up

Nachschauen obs geklapt hat mit :

sudo ifconfig

Achtung: Obwohl CAN1 als Firmwarefile definiert wurde, wird unter den devices can0 angezeigt. Das liegt daran, daß es eben nur eine CAN-Schnittstelle gibt und die wird mit 0 enumeriert.

SocketCAN Lib

Für den ersten Test zum Senden oder Empfangen von CAN-Botschaften kann man socket-can verwenden. Diese muss man aber für den Beaglebone erst noch bauen. Also herunterladen der Quellen von berlios und übersetzen. Hierzu müssen natürlich die notwendigen Tools (GCC etc.) installiert sein - aber das ist unter Debian ja einfach.

Hinweis von Oliver : Unter Debian Jessi sind die CAN utils bereits enthalten. Dann einfach mit : apt-get install can-utils installieren.

installieren.

svn co svn://svn.berlios.de/socketcan/trunk
ACHTUNG das Repository ist umgezogen und zwar hierhin (Danke an Oliver Hartkopp)
https://github.com/linux-can/
Ist also mit git zu bearbeiten statt mit svn.
und hier sind jetzt die Utils zu finden
https://github.com/linux-can/can-utils/

cd trunk/can-utils/ make
cd /home/socketcan/trunk/can-utils/
CAN Send
./cansend can0 5A1#1.2.3.4.5
Can Dump
./candump can0

Die folgenden Befehle sind jedes mal nach einem Neustart erforderlich - außer man macht sie persistent.


sudo modprobe can
sudo modprobe can-dev
sudo modprobe can-raw
echo BB-DCAN1 > /sys/devices/bone_capemgr.*/slots
sudo ip link set can0 up type can bitrate 125000
sudo ifconfig can0 up
ifconfig

 

Wichtig: Man kann nur den CAN1 Bus verwenden (DCAN1 auf Pin 24 und 26) , sonst verliert man I2C2 sowie die HDMI-Schnittstelle.

DCAN1 Rx = P9 pin24

DCAN1 Tx = P9 pin26

Um einen echten CAN-Bus anzuschließen kann man natürlich nicht direkt die Pins 24 und 26 verwenden, sondern man benötigt noch einen CAN-Transceiver der die digitalen Signale des Beaglebones in die CAN-Pegel umsetzt. Ich habe zum Test den Texas Instruments Chip SN65HVD231D auf einem kleinen Breakoutboard benutzt. Der hat auf der Digitalseite 3.3V-Pegel, also perfekt für die Beaglebone IO-Pegel. Hier noch die Anschlussbelegung des Texas-Chips.

Die Pins 1 und 4 müssen am Beaglebone entsprechend auf P9 Pin24 bzw. PIN P9 Pin26 gelegt werden.

Sofern man nur kurze Leitungslängen hat (<1m) kann man auf den Abschlusswiderstand von 120 Ohm verzichten.

Nachtrag 2018: Es gibt weitaus bessere Interface-Chips die die CAN Schnittstelle komplett galvanisch trennen wie z.B. ADM3053 von Analog Devices

 

Die Baudrate der Bus-Teilnehmer muss übereinstimmen, sonst kann keine Kommunikation stattfinden.

Wenn die CAN Bus-Baudrate nicht stimmt, dann sendet der Treiber je nach Konfiguration immer weiter bzw. es wird NIE ein Paket empfangen. Daher am besten die CAN-Bitbreite anhand des letzten Bits mit dem Scope ausmessen. Im Bild sind dies 125kBit/s oder 8us.

Mit den socketcan-tools z.B. candump kann man dann die CAN Messages in der Konsole anzeigen lassen.

CANDump Messages

Mit dem Beaglebone alleine kann man aber den CAN-Bus nicht wirklich testen, sondern man benötigt noch mindestens einen weiteren CAN-Teilnehmer auf dem Bus. Der weitere Teilnehmer kann ein zweites Beaglebone Board sein, oder z.B. das Olimexino STM32 mit dem Cortex Prozessor STM32F103RB. Das Board ist sehr preiswert und hat bereits alle CAN-Transceiver etc. an Bord. Da ist es eigentlich auch recht einfach einen CAN Teilnehmer für erste Tests zu erstellen.

Unter OLIMEXINO STM32 Beispiele findet man wie man das Beaglebone-Board zusammen mit dem Olimexino betreibt.

Digital IO

Wie spricht man die digitalen Ein- und Ausgänge am Pfostensteckverbinder an ?

Beispiel wie man die folgenden Pins als IO-Signale verwendet:

Die folgenden Anschlüsse auf der Anschlussleiste P9 mappen dann auf die entsprechenden GPIO-Signale:

P9/pin 12 --> gpio60
P9/pin 14 --> gpio50 
P9/pin 15 --> gpio48
P9/pin 16 --> gpio51


auf der Konsole einfach die folgenden Befehle eintippen um die Signale im Device-Zugriff zu haben.
echo 48 > /sys/class/gpio/export
echo 50 > /sys/class/gpio/export
echo 51 > /sys/class/gpio/export
echo 60 > /sys/class/gpio/export
Die folgenden Befehle setzen den jeweiligen Ausgang auf high: 
echo high > /sys/class/gpio/gpio48/direction
echo high > /sys/class/gpio/gpio50/direction
echo high > /sys/class/gpio/gpio51/direction
echo high > /sys/class/gpio/gpio60/direction
Die folgenden Befehle setzen den jeweiligen Ausgang auf low: 
echo low > /sys/class/gpio/gpio48/direction
echo low > /sys/class/gpio/gpio50/direction
echo low > /sys/class/gpio/gpio51/direction
echo low > /sys/class/gpio/gpio60/direction
Mit dem folgenden Befehl setzt man jeweils grundsätzlich Eingabe/Ausgaberichtung:
echo out > /sys/class/gpio/gpio48/direction
echo out > /sys/class/gpio/gpio50/direction
echo out > /sys/class/gpio/gpio51/direction
echo out > /sys/class/gpio/gpio60/direction

Lesen von Eingängen ist ähnlich einfach:
cat /sys/class/gpio/gpio60/value
Um die Pins auf Eingang oder Ausgang zu setzen schreibt man einfach auf das entsprechende device-file:
Pin auf Eingang: echo in > /sys/class/gpio/gpio60/direction
Pin auf Ausgang setzen: echo out > /sys/class/gpio/gpio60/direction
Mit cat /sys/class/gpio/gpio60/value
kann man sich anzeigen lassen wie der Pin Mode gesetzt ist.

I2C-Bus

Um mittels I2C-Bus zu kommunizieren, muss man zunächst die I2C-Tools installieren:

apt-get install i2c-tools

Danach stehen die i2c command line tools zur Verfügung.

Mittels

sudo apt-get install python-smbus

hat man gleiche Funktionen unter Python zur Verfügung - sehr schön.

Welche Funktionen stehen auf den I2C Bus zur Verfügung ?

1. Welche I2C Busse stehen zur Verfügung ?

i2cdetect -l oder i2cdetect -F 1 (Check Bus 1)

2. Welche Adressen sind in Benutzung ?

sudo i2cdetect -r 1 (0,1,2..usw ist die Bus Nummer)

3. Wo findet man die logischen devices im Debian Linux ?

cd /sys/bus/i2c/devices

(Hinweis: unter UBUNTU liegen diese in /sys/devices/platform/omap..)

Getestet habe ich dies mit dem Beschleunigungssensor LIS331HH. Das war leider der einzige I2C-Chip den ich zum Testen zur Hand hatte.

Angeschlossen wird der I2C Bus an de folgenden Pins:

I2C2 an P9:
Pin 19 SCL, Pin 20 SDA

Mit i2cdetect habe ich herausgefunden dass der Sensor auf Adresse 19 liegt. Einfach den obigen Befehl jeweils mit - und einmal ohne angeschlossenem Device eingeben. Dann sieht man sofort welche Adresse neu hinzugekommen ist.

root@debian-armhf:/sys/bus/i2c/devices# i2cdetect -r 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1 using read byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n]
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- 19 -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Wie liest man Bytes aus einem Device ab einer bestimmten Adresse ?

sudo i2cdump 1 0x19

Damit der Chip überhaupt erst mal anfängt zu messen, muss man das Controlregister 0x20 entsprechend programmieren:

ctrlRegByte = 0x37; // 00111111 : normal mode, 1000Hz, x+y+z enabled

Programmieren der Messrate: sudo i2cset 1 0x19 0x20 0x37

Bus 1, Chipadresse 0x19 Controlregister 0x20 auf 0x37 setzen.

Auslesen der Beschleunigung in der X-Achse steht auf Adresse 28h und 29h.

Diese liest man mit: sudo i2cget -y 1 0x19 0x28 w

SPI-Interface SPI0

Zur "einfachen" Kommunikation mit der Umwelt will ich noch ein einfaches LCD Display per SPI anschliessen. Dazu muss erst mal der SPI Bus enabled werden -> Devicetree.

Bei Verwendung der HDMI-Schnittstelle kann man allerdings nicht den SPI1 verwenden da dort schon IO-Pins benutzt werden, es bleibt dann nur SPI0.

Wie enabled man den SPI-Bus ? Nun man benötigt mal wieder ein passendes Device-Tree Definitionsfile.

Dieses File muss man dann mit dem Device-Tree-Compiler übersetzen, das dtbo File ins Systemverzeichnis kopieren und den Alias erzeugen:

dtc -O dtb -o BB-SPI0-01-00A0.dtbo -b 0 -@ BB-SPI0-01-00A0.dts
cp BB-SPI0-01-00A0.dtbo /lib/firmware/und noch enablen:
echo BB-SPI0-01 > /sys/devices/bone_capemgr.*/slots

So das SPI-device ist jetzt erzeugt und man kann die IOs ansprechen.

Python und die Hardware

Tja, die im Netz vorhandenen Python Libs waren entweder nicht richtig oder zu umständlich zu installieren. Daher habe ich meine eigenen Libraries gebaut. Die finden sich demnächst hier zum Download.

Ein weiterer Vorteil ist, dass man dann auch selbst festlegen kann welche Pins genau verwendet werden sollen und welche eben auch noch zur Verwendung frei sind.

Zunächst muss man verstehen wie die IOs in ARM-Linux funktionieren. Dies funktioniert sehr elegant über "file"-IO, was über den sogenannten device-tree beim booten des Systems definiert wird.

Zugriff auf die Hardware bekommt man also einfach über das Lesen oder Schreiben auf die "IO-Punkt-Files".

Mehr muss ich hier nicht schreiben, ein paar Beispiele findet man hier:

http://www.nathandumont.com/node/250

IO-Expander MCP23017

Das BeagleBone Black Board hat noch ein "Problem". Die Ein- und Ausgänge sind auf Basis von 3.3V Pegel ausgelegt und relativ empfindlich in Bezug auf korrekte Pegel. Insbesondere durch den geringen Fan-Out in Form von wenigen mA (ja bei 2mA oder so ist das Maximum erreicht) ist es ratsam einen Treiberbaustein anzubinden, sonst ist das Board defekt.

Mit sogenannten IO-Expandern kann man die Anzahl der IOs nochmal erhöhen. Man gewinnt so mit wenigen IO-Leitungen des Beaglebones eine Menge "richtiger IOS", die auch mal einen höheren Strom vertragen - so bis ca 25mA !!

MCP23017 ist ein IO-Expander von Microchip. Er kann einfach per I2C-Bus am Beaglebone angeschlossen werden. I2C Bustakt ist übrigens 400Kbit/s. Nachdem dies erfolgt ist kann man mit den I2C-Tools oder den SM-Bus-Tools versuchen den Chip auch im Betriebssystem zu finden:

Device auf dem Bus finden:

i2cdetect -y 1 

ergibt folgenden output:


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

Das bedeutet der Chip wurde auf Adresse 24h gefunden. Die Adresse des Chips wird - in begrenztem Umfang - mit den Adressbits A0,A1,A2 eingestellt.

MCP23017 Port Expander Anschlussbelegung

 

Zum Test wurden die Pins A0 und A1 auf GND sowie A2 auf +Ub geschaltet. Die Chipadresse ist fest eingestellt immer auf Adresse 2x, wobei x durch die Adressleitungen A0...A2 noch definert werden können. Das nachfolgende Bild erklärt wie die Adresse zusammengesetzt wird.

MCP32017 Addressbits

 

Bevor man die IOs verwenden kann muss man festlegen ob ein Port Eingang oder Ausgang sein soll.

i2cset -y 1 0x24 0x00 0x10

Dies bedeutet man muss das Richtungsregister DDRA (unter 00h) entsprechend beschreiben, in diesem Fall mit 0x10 um den Pin GPA0 als Ausgang zu setzen.

Hier nun die Register des Chips:

MCP23017 Register

Eingänge:

Um die IOs als Eingänge zu benutzen muss man zunächst die IODIRA oder IODIRB Register als Eingang programmieren:

i2cset -y 1 0x24 0x00 0xFF

Dies setzt alle PortA Pins als Eingang. Dies kann man auch wieder zurücklesen um zu sehen obs auch geklappt hat mit:

i2cget -y 1 0x24 0x00

Man kann jetzt die Eingänge noch mit internen Pullupwiderständen versehen bzw. die Eingänge passend programmieren um sich so externe Widerstände zu ersparen. Die erfolgt über das GPPUA oder GPPUB Register (Pullup Register)

i2cset -y 1 0x24 0x0C 0xFF

Die Eingänge kann man jetzt durch Lesen des GPIOA Registers einlesen:

i2cget -y 1 0x24 0x12

Hier steht wie das ganze unter Python funktioniert.

Watchdog auf BeagleBone

Der Sitara Chip hat einen eingebauten Watchdog, den man recht einfach einschalten kann. Dies ist recht sinnvoll wenn die Anwendungssoftware nicht stehenbleiben oder crashen darf. Dazu muss man nur das entsprechende logische Device öffnen und einfach ein Zeichen darauf ausgeben.

1. /dev/watchdog

2. cat > /dev/watchdog

Nach etwa 60 Sekunden wird der BeagleBone neu gestartet sofern man nicht <=alle 59 Sekunden in das device schreibt.

Achtung: Man darf das Device nicht schließen, sonst wird der Watchdog wieder ausgeschaltet.

Mit über 20000 Zugriffen innerhalb kurzer Zeit ist dies ein Beitrag der am häufigsten angeklickt wurde.

Nachtrag: Der neue Raspberry PI3 hat aufgrund der zur Verfügung stehenden Resourcen mein Interesse neu geweckt... dazu gibts bald mehr.. ;-)

 

Syntax Highlighting auf Webseiten Artikeln von Joomla

Dieser Artikel beschreibt wie man Syntax-Highlighting in Webseiten des Joomla CMS einbettet. Da ich nichts Brauchbares für Joomla gefunden habe, habe ich mich wiedermal ;-)  entschlossen ein eigenes JOOMLA 3.x Modul zu schreiben.

Hierzu habe ich die JAVAScript Engine PRISM in ein Modul gepackt. Nach der Installation durch den Extension Manager von JOOMLA kann man anfangen Artikel mit Quellcode-Anzeige zu schreiben.

/**This is a JAVA programing example to demonstrate
the syntax highlighting and rendering within a Joomla Site. This is just for demonstration. **/
package tutorial;
 
import com.opensymphony.xwork2.ActionSupport;
 
public class HelloWorld extends ActionSupport {
    private String name;
    public String getName() {
    return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public String execute() {
        name = "Hello, " + name + "!";
            return SUCCESS;
    }
}

Hierzu muss man nur das Modul installieren und im Modulmanager enablen.

Zunächst muss man das Modul in dem Artikel laden wo überhaupt Quelltext vorkommt, damit nicht IMMER die JAVASCRIPT Klassen geladen werden. Dies geschieht durch das loadmodule mod_prism tag. Danach muss man innerhalb des Artikels den Quellcode noch einschließen mit den <pre> und den <code> tags. Die Programmiersprache wird mit dem class Parameter eingestellt. Im Joomla-Mdul steht aktuell zur Verfügung: JAVA, CLIKE, CSS, SQL,PYTHON,MARKUP,JAVASCRIPT. Wer möchte kann sich die fehlenden Programmiersprachen als JS files von der PRISM Seite laden.

Das ganze sieht dann im Artikeleditor so aus:


 

Hier ist der Downloadlink zum Joomla Modul auf Basis von PRISM