Mikrocontroller.net - Benutzerbeiträge [de]

Diskussion:Remote IRMP

2014-03-28T11:35:13Z

217.7.89.210: Die Seite wurde neu angelegt: „Interessantes Projekt. Wäre auch auf Basis eines Pollin-NetIO und Ethersex umzusetzen.“

Interessantes Projekt.
Wäre auch auf Basis eines Pollin-NetIO und Ethersex umzusetzen.

Remote IRMP

2014-03-28T11:32:13Z

217.7.89.210: /* Bootloader-Software */

Von '''Frank M. ([http://www.mikrocontroller.net/user/show/ukw ukw])'''

[[Datei:Remote-IRMP-Screenshot1.png|thumb|Frei gestaltbare Tasten zum Senden von IR-Befehlen]]

Dieser Artikel ist eine konkrete Anwendung des [[IRMP]]-Projekts. Wir verschaffen unserem Mikrocontroller nicht nur einen IR-Sender und Empfänger, sondern auch noch einen Netzwerkanschluss. Damit wird es möglich, mit einer Android-App eine anlernbare IR-Fernbedienung zu realisieren. Der Anwender kann dann mehrere Geräte, die irgendwo im Haushalt verteilt sind, über das Handy steuern. Dabei sendet die App über WLAN zuvor gespeicherte [[IRMP]]-Codes an den gewünschten µC. Dieser strahlt dann die Signale über den IR-Sender aus, um damit unsere Geräte aus der Unterhaltungsindustrie zu schalten.

Außerdem ist eine Erweiterung von [[IRMP]] um Funksender geplant, damit zukünftig auch Funksteckdosen bequem vom Handy aus geschaltet werden können.

'''DIESER ARTIKEL IST NOCH IN BEARBEITUNG'''

== Merkmale ==

Folgende Funktionalitäten sind bereits umgesetzt:

* Anbindung des µC an einen Wiznet W5100 Ethernet-Controller
* Protokollschnittstelle über TCP/IP und UDP
* Testprogramme der Kommunikation für Unix, Linux und Windows
* Android-App mit frei konfigurierbaren Bedienertasten/Bildschirmseiten
* Anlernen von IR-Codes mit Speicherung unter Android
* Senden der IR-Codes über WLAN an den Remote-IRMP Controller

== Hardware ==

[[Datei:Remote-irmp-schaltung-arduino.png|thumb|Schaltbild des Prototyps als Shield für Arduino Ethernet]]

Der stabil laufende Prototyp wurde mit dem Arduino Ethernet Board realisiert - jedoch ohne die Verwendung der Arduino-Bibliotheken bzw. Arduino-Software. Die Verwendung des fertigen Boards hatte den Vorteil, dass der Lötaufwand sich auf ein Minimum reduziert: Es muss lediglich je ein IR-Sender- und ein Empfänger-Modul angeschlossen werden. Diese Module bestehen lediglich aus ein paar Bauteilen, welche hier auf eine Lochraster-Platine gelötet werden. Die Lochraster-Platine wird dann einfach als Shield auf das Arduino-Board aufgesteckt. Das Schaltbild dazu ist rechts zu sehen.

Dabei ist:

* 0C0A = PD6 oder in der Arduino-Nomenklatur: Digital Pin 6
* PC0 in der Arduino-Schreibweise: Analog Input 0.

Die für den Prototyp entwickelte Software funktioniert aber auch mit einem WIZnet WIZ812MJ-Modul, welches man zum Beispiel bei [http://www.watterott.com/de/WIZnet-WIZ812MJ-Ethernet-Modul Watterott] erstehen kann. Dieses Modul wird dann auf eine eigens zu entwickelnde Platine aufgesteckt.

Die dafür notwendige Hauptplatine als endgültige Version mit ATmega, Infrarot-Sender/Empfänger und Funksteckdosen-Sendermodul ist noch nicht ganz fertig - dazu später mehr. Der Prototyp mit dem Arduino Ethernet Board ist aber durchaus jetzt schon einsatzfähig.

== Protokoll ==

[[Datei:Remote-IRMP-Screenshot3.png|thumb|Beispiel für einen DVD-Player]]

Das Kommunikationsprotokoll für die Remote-IRMP-Satelliten wurde bewusst einfach gehalten. Dabei kann sowohl TCP/IP als auch UDP verwendet werden.

=== Senden eines IRMP-Codes ===

In diesem Fall sind 7 Bytes zu übertragen:

* Byte 1: 'S' als Kommmando "Send"
* Byte 2: [[IRMP]]-Protokollnummer
* Byte 3: Upper Byte der [[IRMP]]-Adresse
* Byte 4: Lower Byte der [[IRMP]]-Adresse
* Byte 5: Upper Byte des [[IRMP]]-Kommandos
* Byte 6: Lower Byte des [[IRMP]]-Kommandos
* Byte 7: [[IRMP]]-Flag

Antwort:

* Byte 1: 'S'
* Byte 2: '+' im Erfolgsfall

oder:

* Byte 1: 'S'
* Byte 2: '-' als Fehlercode, wenn das Protokoll unbekannt ist.

=== Empfangen eines IRMP-Codes (Anlernen) ===

Es wird lediglich 1 Byte gesandt:

* Byte 1: 'R' als Kommmando "Receive"

Wenn man als Anwender innerhalb von 5 Sekunden nun eine Fernbedienung betätigt, wird der angelernte Code als Antwort zurückgeschickt, nämlich:

* Byte 1: 'R' als Bestätigung
* Byte 2: '+' als Erfolgscode
* Byte 3: [[IRMP]]-Protokollnummer
* Byte 4: Upper Byte der [[IRMP]]-Adresse
* Byte 5: Lower Byte der [[IRMP]]-Adresse
* Byte 6: Upper Byte des [[IRMP]]-Kommandos
* Byte 7: Lower Byte des [[IRMP]]-Kommandos
* Byte 8: [[IRMP]]-Flag

Sollte keine Fernbedienungstaste betätigt oder das verwendete IR-Protokoll von IRMP nicht verstanden werden, werden als Antwort auch 8 Bytes zurückgesandt, aber:

* Byte 1: 'R' als Bestätigung
* Byte 2: '-' als Fehlercode
* Byte 3-8: 0x00

=== Weitere Netzwerkbefehle ===

[[Datei:Remote-IRMP-Screenshot4.png|thumb|Bis zu 8 Remote-IRMP Server sind ansprechbar]]

Außerdem wurde noch ein Kommando eingebaut, um die Kommunikation über IP selbst zu testen:

* Byte 1: 'P' als "Ping"-Kommando

Antwort:

* Byte 1: 'P' als Bestätigung
* Byte 2: '+' als Erfolgscode

Es gibt noch ein weiteres Kommando - dieses jedoch nur für TCP/IP, nicht für UDP:

* Byte 1: 'B' als Bootloader-Sprungkommando

Es kommt keine Antwort zurück, sondern der ATmega328 springt dann direkt in den Ethernet-Bootloader, damit man ein Update flashen kann, ohne extra die RESET-Taste drücken zu müssen. Siehe dazu auch das Kapitel [http://www.mikrocontroller.net/articles/Remote_IRMP#Bootloader_-_Flashen_.C3.BCbers_Netzwerk Bootloader - Flashen übers Netzwerk].

== IRMP-Software mit LAN-Anbindung ==

Der Source-Code lässt sich einfach für AVR-µCs übersetzen, indem man unter Windows die Projekt-Datei irmp.aps in das AVR Studio 4 lädt. Jedoch sollte der avr-gcc schon ein neuerer sein, als ursprünglich mal 2010 mit dem AVR Studio 4 ausgeliefert wurde. Ich persönlich nutze avr-gcc 4.7.2.

Bei neueren Entwicklungsumgebungen bzw. Linux ist es auch kein Problem, ein eigenes Projekt bzw. Makefile zu erstellen. Folgende Sources müssen dafür ins Projekt übernommen werden:

* ipserver.c - das main-Modul
* irmp.c - der IR-Multiprotokoll-Decoder
* irsnd.c - der IR-Encoder
* w5100.c - der Wiznet W5100 Treiber

Zum Projekt gehören dann noch folgende Includes:

* irmp.h
* irmpconfig.h
* irmpextlog.h
* irmpprotocols.h
* irmpsystem.h
* irsnd.h
* irsndconfig.h
* w5100.h
* w5100config.h

Zusatzlich zu den Standard-Compiler-Optionen (Prozessor-Typ etc.) sollten dem Projekt für alle C-Dateien folgende Optionen hinzugefügt werden:

-DF_CPU=16000000UL
-Os
-flto
-ffunction-sections
-fdata-sections

Als Linker-Optionen:

-Os
-flto
-ffunction-sections
-fdata-sections
-Wl,--gc-sections

=== Fuses ===
Wichtig sind auch die Fuses. Wenn das Arduino Ethernet Board verwendet wird, muss auf jeden Fall der standardmäßig installierte Bootloader deaktiviert werden. Aber auch für eine eigene Platine müssen die Fuses angepasst werden, nämlich auf:

* lfuse: 0xFF
* hfuse: 0xD1
* efuse: 0xFD

Nur wenn der eigene IP-Bootloader auch verwendet werden soll, ist die hfuse nochmals zu ändern. Das ist dann im [http://www.mikrocontroller.net/articles/Remote_IRMP#Bootloader_-_Flashen_.C3.BCbers_Netzwerk Bootloader-Kapitel] weiter unten nachzulesen.

=== Konfiguration ===

[[Datei:Remote-IRMP-Screenshot5.png|thumb|Konfiguration und Test eines Remote-IRMP Servers]]

Es können etliche Parameter angepasst werden. Hier die wichtigsten Einstellungen:

'''ipserver.c'''

<syntaxhighlight lang="c">
#define DEBUG 1

#define MAC_ADDRESS {0x90,0xA2,0xDA,0x00,0xF4,0x65} // mac address
#define IP_ADDRESS {192,168,10,233} // ip address
#define IP_NETMASK {255,255,255,0} // netmask
#define IP_GATEWAY {192,168,10,1} // gateway address

#define DBG_PORT 10000 // debug tcp listen port
#define TCP_PORT 10001 // normal tcp listen port
#define UDP_PORT 10001 // udp port

#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_BIT PB1
</syntaxhighlight>

Als MAC-Adresse (MAC_ADDRESS) wählt man beim Arduino Ethernet Board am besten die aufgeklebte MAC-Adresse. Dann kann es nicht zu Konflikten kommen. Die IP-Adresse (IP_ADDRESS) sollte an das lokale Netzwerk angepasst werden. Ebenso die Netzwerkmaske (IP_NETMASK), wenn sie im lokalen Netz abweicht. Die Angabe eines Gateways (IP_GATEWAY) ist nicht unbedingt notwendig, wenn die IRMP-Server nur im lokalen Netz erreichbar sein sollen. In diesem Fall kann {0,0,0,0} angegeben werden.

Normalerweise horchen die IRMP-Server auf dem TCP- und UDP-Port 10001. Wenn gewünscht, können die Ports sowohl für TCP (TCP_PORT) als auch für UDP (UDP_PORT) geändert werden. Sie können auch verschieden sein. Normalerweise ist aber eine Änderung nicht notwendig.

Bleibt noch der Debug-Port (DBG_PORT). Nur wenn die Präprozessor-Konstante DEBUG auf 1 steht, spielt dieser eine Rolle. Dann protokolliert der IRMP-Server nämlich alle eingehenden IRMP-Befehle, wenn man eine telnet-Session für die konfigurierte IP-Adresse und den Debug-Port öffnet. Unter Windows eignet sich dafür hervorragend PuTTY, welches man aus dem Internet herunterladen kann. Bei unixoiden Systemen ist telnet sowieso verfügbar - meist schon standardmäßig installiert.

Wird Debugging nicht gewünscht, kann man DEBUG auf 0 setzen und der Wert des DBG_PORTs wird irrelevant.

Außerdem gibt es noch die Definitionen für eine am ATmega angeschlossene LED (Konstanten LED_xxx). Hier werden dann ausgesandte IR-Signale parallel auf der LED visualisiert. Außerdem leuchtet diese LED, solange man einen IR-Code anlernt.

Die obigen Werte dafür entsprechen der bereits vorhandenen LED auf dem Arduino-Board. Sie können natürlich für andere Hardware (z.B. eigene Platine mit WIZ812MJ-Modul) angepasst werden. Besser: Man wählt beim Entwurf einer eigenen Hauptplatine einfach denselben Port.

'''w5100config.h'''

<syntaxhighlight lang="c">
#define CHIP_SELECT_AVAILABLE 0 // set to 1 if CS will be controlled by other pin than SS of the µC
#define CHIP_RESET_AVAILABLE 0 // set to 1 if RESET can be controlled by µC

#if CHIP_SELECT_AVAILABLE == 1 // if CS can be controlled , enter port/pin of µC
# define CS_DDR DDRD
# define CS_PORT PORTD
# define CS_BIT 4
#endif

#if CHIP_RESET_AVAILABLE == 1 // if RESET can be controlled by µC, enter port/pin of µC
# define RESET_DDR DDRD
# define RESET_PORT PORTD
# define RESET_BIT 5
#endif
</syntaxhighlight>

Die obigen Konstanten beschreiben, wie der W5100-Controller an den ATmega angebunden ist.

Ist CS (Chip-Select) des W5100 '''nicht''' an SS des ATmegas angeschlossen, muss CHIP_SELECT_AVAILABE auf 1 gesetzt werden und mittels CS_xxx-Konstanten der für CS verwendete Port-Pin des ATmegas angegeben werden, damit der ATmega software-mäßig den Ethernet-Controller aktiovieren kann. Beim Arduino Ethernet Board ist CS mit SS fest verbunden, so dass CHIP_SELECT_AVAILABLE auf 0 stehen bleibt und die CS_xxx-Konstanten nicht weiter beachtet werden.

Muss der W5100-Controller explizit über den RESET-Pin softwaremäßig zurückgesetzt werden, dann sollte dies über den ATmega geschehen. In diesem Fall setzt man CHIP_RESET_AVAILABLE auf 1 und definiert weiter unten den Portpin (RESET_xxx), an welchem ATmega-Portpin der RESET-Pin des W51000 angeschlossen ist. Beim Arduino Ethernet Board hängt der W5100 an einer eigenen Hardware-Reset-Schaltung, so dass CHIP_SELEVT_AVAILABLE auf 0 stehen bleiben kann und damit die RESET_xxx-Konstanten irrelevant werden.

'''irmpconfig.h''' und '''irsndconfig.h'''

Die Konstanten in den IRMP-Konfigurationsdateien sind ausführlich im [[IRMP]]-Artikel erklärt. Daher wird hier darauf verzichtet. Im wesentlichen wird hier definiert, welche Pins am ATmega für den IR-Empfänger und für den IR-Sender verwendet werden. Ausserdem kann man hier die IR-Protokolle auswählen, die IRMP/IRSND mit einbinden soll. Insgsamt sind 36 Protokolle wählbar. Die häufigsten 6 Protokolle sind bereits aktiviert.

'''Erster Start'''

Der erste Start mit dem Arduino Ethernet Board kann durchaus auch ohne selbstgebautes "Shield" auf Lochrasterplatine gewagt werden. Hierzu wird die vom Compiler erzeugte Hex-Datei über den 6-poligen ISP-Stecker des Boards eingespielt. [http://www.mikrocontroller.net/articles/Remote_IRMP#Fuses Fuses] nicht vergessen! Anschließend sollte man vom PC aus das Modul per ping-Befehl ansprechen können. Wenn das funktioniert, ist man schon fast am Ziel. Nun sollte man das Board von der Stromversorgung trennen und die Platine mit IR-Empfänger und Sender als Shield aufstecken. Nach Neustart kann man nun entweder direkt die Funktionen mit der [http://www.mikrocontroller.net/articles/Remote_IRMP#Android-Software Android-App] testen oder erstmal mit einem [http://www.mikrocontroller.net/articles/Remote_IRMP#Andere_Betriebssysteme_als_Clients PC-Testprogramm], siehe weiter unten.

Ganz Mutige lassen das aber mit dem Programmieren der Remote-IRMP-Software über den ISP, sondern installieren direkt den [http://www.mikrocontroller.net/articles/Remote_IRMP#Bootloader_-_Flashen_.C3.BCbers_Netzwerk Bootloader], siehe weiter [http://www.mikrocontroller.net/articles/Remote_IRMP#Bootloader_-_Flashen_.C3.BCbers_Netzwerk unten]. Anschließend kann man beliebig oft die IRMP-Software oder Updates davon direkt übers Netzwerk installieren.

Weitere Beschreibung der AVR-Software folgt in den nächsten Tagen.

== Bootloader - Flashen übers Netzwerk ==

Wenn man schon einen netzwerkfähigen ATmega hat, dann möchte man Updates auch über das angesteckte Netzwerkkabel einspielen. Dafür wurde ein Bootloader entwickelt, welcher mit 1,6 KB Größe leicht in den oberen Flash-Bereich des ATmega328 passt. Das eigentliche Flash-Programm sendet dann per TCP/IP die Daten an den Bootloader. Das Flash-Programm ist für Unix, Linux und Windows verfügbar.

=== Bootloader-Kommunikationsprotokoll ===

* Bootloader (BL) horcht auf TCP/Port 22222 und wartet für 3 Sekunden auf das Zeichen '$' (1 Byte)
* Falls dieses eintrifft, antwortet BL ebenfalls mit dem '$'-Zeichen (1 Byte), anderenfalls hier Ende
* BL sendet die µC-spezifische "Page-Size" des Flashs zum Programmieren an den PC (1 Byte)
* PC sendet erste Page-Nummer des zu schreibenden Programms (2 Bytes, LSB, i.d.R. 0x00 0x00)
* PC sendet die Anzahl der zu übertragenden Pages (2 Bytes, LSB)
* PC sendet die Daten für eine Page - gefolgt von einem Prüfsummen-Byte
* BL antwortet mit '1', wenn das Prüfsummen-Byte passt, anderenfalls mit '0' und bricht ab
* Weiter gehts mit der nächsten Page, also 2 Schritte höher...

=== Bootloader-Software ===

Der Source-Code lässt sich einfach für AVR-µCs übersetzen, indem man unter Windows die Projekt-Datei ipbootloader.aps in das AVR Studio 4 lädt. Der avr-gcc muss jedoch neuer sein als der, welcher ursprünglich im Jahre 2010 mit dem AVR Studio 4 ausgeliefert wurde. Empfehlung: avr-gcc 4.7.2 oder neuer.

Bei neueren AVR-Entwicklungsumgebungen bzw. Linux ist es auch kein Problem, ein eigenes Projekt bzw. Makefile zu erstellen. Folgende Sources müssen dafür ins Projekt übernommen werden:

* ipbootloader.c - der Bootloader
* w5100.c - der Wiznet W5100 Treiber

Zum Projekt gehören dann noch folgende Includes:

* w5100.h
* w5100config.h

Zusatzlich zu den Standard-Compiler-Optionen (Prozessor-Typ etc.) müssen dem Projekt für alle C-Dateien folgende Optionen hinzugefügt werden:

-DF_CPU=16000000UL
-Os
-flto
-ffunction-sections
-fdata-sections

Als Linker-Optionen:

-Os
-flto
-ffunction-sections
-fdata-sections
-Wl,--gc-sections
-Wl,--section-start=.text=0x7800

Mit der letzten Linker-Option wird das Programm derart übersetzt, dass es ab Adresse 0x7800 lauffähig ist. Damit liegt es in den letzten 2KB des ATmega328-Flash-Speichers. Beim Übersetzen ist dringendst darauf zu achten, dass das Compilat eine "Program Size" von ca. 1,6KB hat. Wird es größer als 2KB, dann sind offensichtlich die obigen Compiler- und Linker-Optionen nicht korrekt eingetragen und das Programm ist als Bootloader unbrauchbar.

=== Konfiguration des Bootloaders ===

Hier gelten im wesentlichen dieselben Konfigurationsparameter für w5100config.h wie [http://www.mikrocontroller.net/articles/Remote_IRMP#Konfiguration oben]. Wichtig ist die Anpassung der IP-Adresse, siehe dafür ipbootloader.c:

<syntaxhighlight lang="c">
#define MAC_ADDRESS {0x90,0xA2,0xDA,0x00,0xF4,0x65} // mac address
#define IP_ADDRESS {192,168,10,233} // ip address
#define IP_NETMASK {255,255,255,0} // netmask
#define IP_GATEWAY {192,168,10,1} // gateway address

#define TCP_PORT 22222 // listen port
</syntaxhighlight>

=== Fuses für den Bootloader ===

Die Fuses sind in diesem Fall auf folgende Werte zu ändern:

* lfuse: 0xFF
* hfuse: 0xD2
* efuse: 0xFD

Damit werden die letzten 2KB im Flash für den Bootloader reserviert. Dieser kann dann über den ISP-Stecker installiert werden. Updates der Remote-IRMP-Software können anschließend bequem über das Netzwerk eingespielt werden. Der Anschluss eines ISP-Programmers ist dann nicht mehr notwendig.

=== Flashprogramm ===

Das Flashprogramm ist unter Unix, Linux und Windows verfügbar. Als Executable für Windows benutzt man einfach ipflash.exe, unter unixoiden System kompiliert man sich das Programm selbst mit:

cc -O ipflash.c -o ipflash

Der Aufruf ist dann allgemein:

ipflash [-b ipserver-tcp-port] ip-address tcp-port hex-file

oder konkret für die Windows-Eingabeaufforderung:

ipflash.exe 192.168.10.233 22222 ipserver.hex

bzw. linux:

./ipflash 192.168.10.233 22222 ipserver.hex

Wichtig ist dabei, kurz vorher den RESET-Button auf dem Board zu drücken und dann innerhalb von 3 Sekunden das Flash-Programm zu starten.

Ist einmal das ipserver-Programm installiert, kann man sich das Drücken des RESET-Buttons zukünftig auch sparen. Dann kann das Flash-Programm den ATmega auch über das Netzwerk resetten. Hierbei ist zusätzlich der TCP-Port des ipserver-Programms anzugeben, also:

ipflash.exe -b 10001 192.168.10.233 22222 ipserver.hex

bzw.

./ipflash -b 10001 192.168.10.233 22222 ipserver.hex

In diesem Fall schickt das Flash-Programm zunächst den Boot-Befehl auf Port 10001, wartet dann ein paar Sekunden und führt dann erst den eigentlichen Flash-Prozess aus. So kann man dann bequem vom Arbeitsplatz aus alle IRMP-Netzwerkserver im Haushalt aktualisieren, ohne direkt "vor Ort" zu sein.

== Android-Software ==

[[Datei:Remote-IRMP-Screenshot2.png|thumb|Anlernen eines IR-Befehls]]

'''Merkmale:'''

* Ansteuerung von mehreren im Haushalt verteilten IRMP-Satelliten
* Erstellung von mehreren Bildschirmseiten
* Frei definierbares Tastenfeld pro Bildschirmseite
* Anlernen von IR-Codes
* Senden von IR-Codes

'''Weitere Planung:'''

* Erweiterung um Graphiksymbole für die Tasten
* Makros, um mehrere nachfolgende Befehle über eine Taste zu senden
* Anlernen von Funksteckdosen-Fernbedienungen

Hier folgt die Beschreibung der Android Software in den nächsten Tagen.

== Andere Betriebssysteme als Clients ==

Es ist auch möglich, für andere Betriebssysteme einen Remote-IRMP-Client zu entwickeln. Ein entsprechendes C-Programm inkl. Quelltext, welches IRMP-Codes an einen IRMP-Satelliten schickt bzw. die angelernten Codes empfängt, habe ich beigefügt. Der C-Quelltext ist unter Unix, Linux und Windows compilierbar. Dieses Tesprogramm ist als Vorlage für ambitionierte Anwender gedacht, die selbst ein eigenes PC-Projekt für Remote-IRMP realisieren möchten.

Als Executable für Windows kann man auch einfach ipclient.exe benutzen, unter Unix bzw. Linux kompiliert man das Programm selbst mit:

cc -O ipclient.c -o ipclient

=== Aufruf des Testprogramms ===

Der Aufruf ist dann allgemein:

IR-Code senden über UDP:

ipclient udpsend ipaddress tcp-port ir-protocol ir-addr-in-hex ir-command-in-hex flag-in-hex

IR-Code senden über TCP:

ipclient send ipaddress tcp-port ir-protocol ir-addr-in-hex ir-command-in-hex flag-in-hex

IR-Code empfangen über UDP:

ipclient udprec ipaddress tcp-port

IR-Code empfangen über TCP:

ipclient rec ipaddress tcp-port

=== Beispiel: Senden eines IRMP-Codes ===

IR-Code senden über UDP, z.B. NEC-Protokoll (Nr. 2), Adresse 0xFF00, Kommando: 0x0020, Flag: 0x00

Der Aufruf ist dann in der Windows-Eingabeaufforderung:

ipclient.exe udpsend 192.168.10.233 10001 2 FF00 0020 0

bzw. unter Linux:

./ipclient udpsend 192.168.10.233 10001 2 FF00 0020 0

Wichtig ist dabei, dass die Protokollnummer in dezimal, alle anderen IR-Parameter in hexadezimal angegeben werden. Eine Liste der IR-Protokollnummern findet man hier: [http://www.mikrocontroller.net/svnbrowser/irmp/irmpprotocols.h?view=markup irmpprotocols.h]

=== Beispiel: Empfangen eines IRMP-Codes ===

Man kann natürlich auch IR-Telegramme empfangen, z.B. über TCP mit dem folgenden Befehl:

Windows-Eingabeaufforderung:

ipclient.exe rec 192.168.10.233 10001

Linux:

./ipclient rec 192.168.10.233 10001

Sendet man nun innerhalb von 5 Sekunden mit irgendeiner Fernbedienung ein Signal an den IR-Empfänger, wird dieses dann als IRMP-Code (Protokoll, Adresse, Kommando, Flag) auf dem PC ausgegeben.

== Downloads ==

Hier folgen die Download-Links... später ;-)

== Siehe auch ==

* Diskussion zu diesem Projekt: Link später.
* [[IRMP]]

[[Kategorie:Infrarot]]
[[Kategorie:AVR-Projekte]]

AVR-Tutorial: Timer

2014-03-19T06:38:44Z

217.7.89.210: Vandalismus

Timer sind eines der Hauptarbeitspferde in unserem Mikrocontroller. Mit ihrer Hilfe ist es möglich, in regelmäßigen Zeitabständen Aktionen zu veranlassen. Aber Timer können noch mehr!
* Timer können mit einem externen Pin hochgezählt werden
* Es gibt Möglichkeiten, bei bestimmten Zählerständen einen Interrupt auslösen zu lassen
* Timer können aber auch völlig selbstständig Signale an einem Ausgabepin erzeugen
* ...

Aber der Reihe nach und kurz zur Erinnerung: Die Beispiele passen zu einem ATmega8 und ggf. einer Reihe anderer AVR, können bei einigen Typen aber abweichen.

==Was ist ein Timer?==

Ein Timer ist im Grunde nichts anderes als ein bestimmtes Register im Mikrocontroller, das hardwaregesteuert fortlaufend um 1 erhöht (oder erniedrigt) wird (statt um 1 erhöhen sagt man auch '''inkrementieren''', und das Gegenstück, '''dekrementieren''', bedeutet um 1 verringern). Anstatt also Befehle im Programm vorzusehen, die regelmäßig ausgeführt werden und ein Register inkrementieren, erledigt dies der Mikrocontroller ganz von alleine. Dazu ist es möglich, den Timer mit dem Systemtakt zu verbinden und so die Genauigkeit des Quarzes auszunutzen, um ein Register regelmäßig und vor allen Dingen unabhängig vom restlichen Programmfluss (!) hochzählen zu lassen.

Davon alleine hätte man aber noch keinen großen Gewinn. Nützlich wird das Ganze erst dann, wenn man bei bestimmten Zählerständen eine Aktion ausführen lassen kann. Einer der 'bestimmten Zählerstände' ist zum Beispiel der '''Overflow'''. Das Zählregister eines Timers kann natürlich nicht beliebig lange inkrementiert werden – z. B. ist der höchste Zählerstand, den ein 8-Bit-Timer erreichen kann, 28 – 1 = 255. Beim nächsten Inkrementierschritt tritt ein Überlauf (engl. Overflow) auf, der den Timerstand wieder zu 0 werden lässt. Und hier liegt der springende Punkt. Wir können uns nämlich an diesen Overflow "anhängen" und den Controller so konfigurieren, dass beim Auftreten des Timer-Overflows ein Interrupt ausgelöst wird.

Kann auch alles nochmal nachgelesen werden im Datenblatt von Atmel zu einigen ATMega Datenblättern http://www.atmel.com/Images/doc8161.pdf

==Der Vorteiler (Prescaler)==

Wenn also der Quarzoszillator mit 4 MHz schwingt, dann würde auch der Timer 4 Millionen mal in der Sekunde erhöht werden. Da der Timer jedes Mal von 0 bis 255 zählt, bevor ein Overflow auftritt, heißt das auch, dass in einer Sekunde 4000000 / 256 = 15625 Overflows vorkommen. Ganz schön schnell! Nur: Oft ist das nicht sinnvoll. Um diese Raten zu verzögern, gibt es den Vorteiler, oder auf Englisch, Prescaler. Er kann z.B. auf die Werte 1, 8, 64, 256 oder 1024 eingestellt werden, je nach Timer (Bitte Datenblatt konsultieren!). Seine Aufgabe ist es, den Systemtakt um den angegebenen Faktor zu teilen. Steht der Vorteiler also auf 1024, so wird nur bei jedem 1024-ten Impuls vom Systemtakt das Timerregister um 1 erhöht. Entsprechend weniger häufig kommen dann natürlich die Overflows. Der Systemtakt sei wieder 4000000. Dann wird der Timer in 1 Sekunde 4000000 / 1024 = 3906.25 mal erhöht. Da der Timer wieder jedesmal bis 255 zählen muss bis ein Overflow auftritt, bedeutet dies, dass in 1 Sekunde 3906.25 / 256 = 15.25 Overflows auftreten.

Systemtakt: 4Mhz

Vorteiler Overflows/Sekunde Zeit zwischen
2 Overflows [s]

1 15625 0.000064
8 1953.125 0.000512
64 244.1406 0.004096
256 61.0351 0.016384
1024 15.2587 0.065536

Die Zeit zwischen 2 Overflows lässt sich sehr leicht berechnen:
<math>t=\frac{2^\text{Bit des Timers} \cdot \text{Vorteiler}}{\text{Systemtakt in Hz}} \text{s}</math>.

==Erste Tests==

Ein Programm, das einen Timer Overflow in Aktion zeigt, könnte z. B. so aussehen:

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16
.def leds = r17

.org 0x0000
rjmp main ; Reset Handler
.org OVF0addr
rjmp timer0_overflow ; Timer Overflow Handler

main:
; Stackpointer initialisieren
ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND)
out SPL, temp

ldi temp, 0xFF ; Port B auf Ausgang
out DDRB, temp

ldi leds, 0xFF

ldi temp, (1<<CS00) ; CS00 setzen: Teiler 1
out TCCR0, temp

ldi temp, (1<<TOIE0) ; TOIE0: Interrupt bei Timer Overflow
out TIMSK, temp

sei

loop: rjmp loop

timer0_overflow: ; Timer 0 Overflow Handler
out PORTB, leds
com leds
reti
</syntaxhighlight>

Das Programm beginnt mit der [[AVR-Tutorial:_Interrupts|Interrupt-Vektoren-Tabelle]]. Dort ist an der Adresse OVF0Addr ein Sprung zur Marke timer0_overflow eingetragen. Wenn also ein Overflow Interrupt vom Timer 0 auftritt, so wird dieser Interrupt durch den '''rjmp''' weitergeleitet an die Stelle timer0_overflow.

Das Hauptprogramm beginnt ganz normal mit der Belegung des Stackpointers. Danach wird der Port B auf Ausgang geschaltet, wir wollen hier wieder die LED anschliessen.

Durch Beschreiben von TCCR0 mit dem Bitmuster 0b00000001, hier ausgedrückt durch (1<<CS00), wird der Vorteiler auf 1 gesetzt. Für die ersten Versuche empfiehlt es sich, das Programm mit dem AVR-Studio zunächst zu simulieren. Würden wir einen größeren Vorteiler benutzen, so müsste man ziemlich oft mittels F11 einen simulierten Schritt ausführen, um eine Änderung im Timerregister zu erreichen.

Die nächsten Anweisungen setzen im TIMSK Register das TOIE0 Bit. Sinn der Sache ist es, dem Timer zu erlauben, bei Erreichen eines Overflow einen Interrupt auszulösen.

Zum Schluss noch die Interrupts generell mittels '''sei''' freigeben. Dieser Schritt ist obligatorisch. Im Mikrocontroller können viele Quellen einen Interrupt auslösen. Daraus folgt: Für jede mögliche Quelle muss festgelegt werden, ob sie einen Interrupt erzeugen darf oder nicht. Die Oberhoheit hat aber das globale Interrupt Flag. Mit ihm können alle Interrupts, egal von welcher Quelle sie kommen, unterdrückt werden.

Damit ist die Initialisierung beendet und das Hauptprogramm kann sich schlafen legen. Die '''loop: rjmp loop''' Schleife macht genau dieses.

Tritt nun ein Overflow am Timer auf, so wird über den Umweg über die Interrupt Vektor Tabelle der Programmteil timer0_overflow angesprungen. Dieser gibt einfach nur den Inhalt des Registers leds am Port B aus. Danach wird das leds Register mit einer '''com''' Operation negiert, so dass aus allen 0 Bits eine 1 wird und umgekehrt. Die Overflow Behandlung ist damit beendet und mittels '''reti''' wird der Interrupt Handler wieder verlassen.

==Simulation im AVR-Studio==

Es lohnt sich, den ganzen Vorgang im AVR-Studio simulieren zu lassen. Dazu am besten in der linken I/O View Ansicht die Einträge für PORTB und TIMER_COUNTER_0 öffnen. Wird mittels F11 durch das Programm gegangen, so sieht man, dass ab dem Moment, ab dem der Vorteiler auf 1 gesetzt wird, der Timer 0 im TCNT0 Register zu zählen anfängt. Mit jedem Druck auf F11 erhöht sich der Zählerstand. Irgendwann ist dann die Endlosschleife loop erreicht. Drücken Sie weiterhin F11 und beobachten sie, wie TCNT0 immer höher zählt, bis der Overflow erreicht wird. In dem Moment, in dem der Overflow erreicht wird, wird der Interrupt ausgelöst. Mit dem nächsten F11 landen sie in der Interrupt Vektor Tabelle und von dort geht es weiter zu timer_0_overflow. Weitere Tastendrücke von F11 erledigen dann die Ausgabe auf den Port B, das Invertieren des Registers r17 und der Interrupt ist damit behandelt. Nach dem '''reti''' macht der Microcontroller genau an der Stelle weiter, an der er vom Interrupt unterbrochen wurde. Und der Timer 0 hat in der Zwischenzeit weitergezählt! Nach exakt weiteren 256 Schritten, vom Auftreten des ersten Overflows an gerechnet, wird der nächste Overflow ausgelöst.

==Wie schnell schaltet denn jetzt der Port?==

Eine berechtigte Frage. Dazu müssen wir etwas rechnen. Keine Angst, es ist nicht schwer, und wer das Prinzip bisher verstanden hat, der sollte keine Schwierigkeiten haben, die Berechnung nachzuvollziehen.

Der Quarzoszillator schwingt mit 4 MHz. Das heißt, in 1 Sekunde werden 4000000 Taktzyklen generiert. Durch die Wahl des Vorteilers von 1 bedeutet das auch, dass der Timer 4000000 mal in der Sekunde erhöht wird. Von einem Overflow zum nächsten muss der Timer 256 Zählvorgänge ausführen. Also werden in 1 Sekunde 4000000 / 256 = 15625 Overflows generiert. Bei jedem Overflow schalten wir die LEDs jeweils in den anderen Zustand. D.h die LEDs blinken mit einer Frequenz von 7812.5 Hz. Das ist zuviel als dass wir es noch sehen könnten.

Was können wir also tun, um diese Blinkfrequenz zu verringern? Im Moment ist unsere einzige Einflussgröße der Vorteiler. Wie sieht die Rechnung aus, wenn wir einen Vorteiler von 1024 wählen?

Wiederrum: Der Systemtakt sei 4 Mhz. Durch den Vorteiler von 1024 werden daraus 4000000 / 1024 = 3906.25 Pulse pro Sekunde für den Timer. Der zählt wiederum 256 Zustände von einem Overflow zum nächsten. 3906.25 / 256 = 15.2587. Und wiederum: Im Overflow werden die LEDs ja abwechselnd ein und ausgeschaltet, also dividieren wir noch durch 2: 15.2587 / 2 = 7.629. Also knapp 7 Hz. Diese Frequenz müsste man schon mit freiem Auge sehen. Die LEDs werden ziemlich schnell vor sich hin blinken.

Reicht diese Verzögerung noch immer nicht, dann haben wir 2 Möglichkeiten:
* Entweder wir benutzen einen anderen Timer. Timer 1 beispielsweise ist ein 16 Bit Timer. Der Timer zählt also nicht von 0 bis 255 sondern von 0 bis 65535. Bei entsprechender Umarbeitung des Programms und einem Vorteiler von 1024 bedeutet das, dass die LEDs einen Ein/Aus Zyklus in 33 Sekunden absolvieren.
* Oder wir schalten die LEDs nicht bei jedem Timer Overflow um. Man könnte zum Beispiel in einem Register bis 7 zählen und nur dann, wenn dieses Register 7 erreicht hat, wird
** das Register wieder auf 0 gesetzt und
** die LEDs umgeschaltet.

==Timer 0==

Timer 0 ist ein 8 Bit Timer.

* Overflow Interrupt

===TCCR0===
====TCCR - Timer/Counter Control Register====
{{Byte |TCCR0 | | | | | | CS02 | CS01 | CS00 }}

====CS02/CS00 - Clock Select====

{| {{Tabelle}}
|- style="background-color:#ffddcc"
! CS02 || CS01 || CS00 || Bedeutung
|-
|align="center"|0
|align="center"|0
|align="center"|0
||keine (Der Timer ist angehalten)
|-
|align="center"|0
|align="center"|0
|align="center"|1
||Vorteiler: 1
|-
|align="center"|0
|align="center"|1
|align="center"|0
||Vorteiler: 8
|-
|align="center"|0
|align="center"|1
|align="center"|1
||Vorteiler: 64
|-
|align="center"|1
|align="center"|0
|align="center"|0
||Vorteiler: 256
|-
|align="center"|1
|align="center"|0
|align="center"|1
||Vorteiler: 1024
|-
|align="center"|1
|align="center"|1
|align="center"|0
||Vorteiler: Externer Takt vom Pin T0, fallende Flanke
|-
|align="center"|1
|align="center"|1
|align="center"|1
||Vorteiler: Externer Takt vom Pin T0, steigende Flanke
|}

===TIMSK===

{{Byte|TIMSK| | | | | | | | TOIE0 }}

====TOIE0 - Timer 0 Overflow Interrupt Enable====
Ist dieses Bit gesetzt, so wird beim Auftreten eines Overflows am Timer ein Interrupt ausgelöst.

Anstatt der Schreibweise
<syntaxhighlight lang="avrasm">
ldi temp, 0b00000001 ; TOIE0: Interrupt bei Timer Overflow
out TIMSK, temp
</syntaxhighlight>
ist es besser, die Schreibweise
<syntaxhighlight lang="avrasm">
ldi temp, 1 << TOIE0
out TIMSK, temp
</syntaxhighlight>
zu wählen, da hier unmittelbar aus dem Ladekommando hervorgeht, welche Bedeutung das gesetzte Bit hat. Die vorher inkludierte m8def.inc definiert dazu alles Notwendige.

==Timer 1==

Timer 1 ist ein 16 Bit Timer

* Overflow Interrupt
* Clear Timer on Compare Match
* Input Capture
* 2 Compare Einheiten
* div. PWM Modi

===TCCR1B===

{{Byte|TCCR1B| ICNC1| ICES1| | WGM13| WGM12| CS12 | CS11 | CS10 }}

====CS12/CS10 - Clock Select====

{| {{Tabelle}}
|- style="background-color:#ffddcc"
! CS12 || CS11 || CS10 || Bedeutung
|-
|align="center"|0
|align="center"|0
|align="center"|0
||keine (Der Timer ist angehalten)
|-
|align="center"|0
|align="center"|0
|align="center"|1
||Vorteiler: 1
|-
|align="center"|0
|align="center"|1
|align="center"|0
||Vorteiler: 8
|-
|align="center"|0
|align="center"|1
|align="center"|1
||Vorteiler: 64
|-
|align="center"|1
|align="center"|0
|align="center"|0
||Vorteiler: 256
|-
|align="center"|1
|align="center"|0
|align="center"|1
||Vorteiler: 1024
|-
|align="center"|1
|align="center"|1
|align="center"|0
||Vorteiler: Externer Takt vom Pin T1, fallende Flanke
|-
|align="center"|1
|align="center"|1
|align="center"|1
||Vorteiler: Externer Takt vom Pin T1, steigende Flanke
|}

====ICES1 - Input Capture Edge Select====

====ICNC1 - Input Capture Noise Canceler====

===TCCR1A===

{{Byte|TCCR1A|COM1A1|COM1A0|COM1B1|COM1B0|FOC1A |FOC1B |WGM11 |WGM10 }}

===OCR1A===

{{Byte|| |||||||}}

{{Byte|| |||||||}}

===OCR1B===
{{Byte|| |||||||}}

{{Byte|| |||||||}}

===ICR1===
{{Byte|| |||||||}}

{{Byte|| |||||||}}

===TIMSK1===
{{Byte|TIMSK| | |TICIE1|OCIE1A|OCIE1B| | |TOIE1}}

====TICIE1 - Timer 1 Input Capture Interrupt Enable====
====OCIE1A - Timer 1 Output Compare A Match Interrupt Enable====

====OCIE1B - Timer 1 Output Compare B Match Interrupt Enable====

====TOIE1 - Timer 1 Overflow Interrupt Enable====

==Timer 2==
Timer 2 ist ein 8 Bit Timer.

* Overflow Interrupt
* Compare Match Interrupt
* Clear Timer on Compare Match
* Phasen korrekte PWM

===TCCR2===

{{Byte|TCCR2| FOC2 | WGM20| COM21| COM20| WGM21| CS22 | CS21 | CS20 }}

====CS22/CS20 - Clock Select====

{| {{Tabelle}}
|- style="background-color:#ffddcc"
! CS22 || CS21 || CS20 || Bedeutung
|-
|align="center"|0
|align="center"|0
|align="center"|0
||keine (Der Timer ist angehalten)
|-
|align="center"|0
|align="center"|0
|align="center"|1
||Vorteiler: 1
|-
|align="center"|0
|align="center"|1
|align="center"|0
||Vorteiler: 8
|-
|align="center"|0
|align="center"|1
|align="center"|1
||Vorteiler: 32
|-
|align="center"|1
|align="center"|0
|align="center"|0
||Vorteiler: 64
|-
|align="center"|1
|align="center"|0
|align="center"|1
||Vorteiler: 128
|-
|align="center"|1
|align="center"|1
|align="center"|0
||Vorteiler: 256
|-
|align="center"|1
|align="center"|1
|align="center"|1
||Vorteiler: 1024
|}

===OCR2===

{{Byte|| |||||||}}

===TIMSK2===
{{Byte|TIMSK| OCIE2| TOIE2| | | | | | }}

====OCIE2 - Timer 2 Output Compare Interrupt Enable====
====TOIE2 Timer 2 Overflow Interrupt Enable====

==Was geht noch mit einem Timer?==

Timer sind sehr universelle Microcontroller Bestandteile. Für weitergehende Studien ist es daher unerlässlich, das entsprechende Datenblatt des Microcontrollers zu studieren. Oft ist es z. B. möglich, dass der Timer bei erreichen von bestimmten Zählerständen einen Ausgabepin von sich aus ein-/aus-/umschaltet. Er erledigt dann das, was wir oben noch mit einem Interrupt gemacht haben, eigenständig komplett in Hardware. Bei einigen Timern ist es möglich, damit eine [[PWM]] (Pulsweiten-Modulation) aufzubauen.

Ein paar der Timermodule lassen sich auch als Counter verwenden. Damit kann man z. B. die Anzahl externer Ereignisse wie Schaltvorgänge eines Inkrementalgebers bestimmen.

Andere bieten die Möglichkeit, über einen externen Uhrenquarz getaktet zu werden (Anwendung z. B. eine "Echtzeituhr" oder als "Weckfunktion" aus einem Standby/Powerdownmodus).

Durch geschickte Umprogrammierung in Echtzeit, lässt sich mit einem Timer eine [[PLL]] aufbauen, die sich fortwährend auf einen Eingangstakt synchronisiert. Damit wird vermieden, dass der Controller ein Signal ständig abpollen muss, sondern das Signale wird per Timer-Interrupt verarbeitet. Massgeblich ist die Messung der aktuellen- und Schätzung der kommenden Flanke mithilfe eines einstellbaren [[Taktteiler]]-verhältnisses.

== Weblinks ==
* [http://www.uni-koblenz.de/~physik/informatik/MCU/Timer.pdf Timer/Counter und PWM beim ATMega16 Mikrocontroller] Proseminar von Marcel Jakobs, September 2006 (PDF)
* [http://frank.circleofcurrent.com/cache/avrtimercalc.htm AVR Timer Calculator]

----

{{Navigation_zurückhochvor|
zurücktext=Speicher|
zurücklink=AVR-Tutorial: Speicher|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=Uhr|
vorlink=AVR-Tutorial: Uhr}}

[[Category:AVR-Tutorial|Timer]]
[[Category:Timer und Uhren]]