Remote IRMP
Von Frank M. (ukw)
Dieser Artikel ist eine konkrete Anwendung des IRMP-Projekts (IRMP-Dekoder = Infrarot-Multiprotokoll-Dekoder). 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.
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
Der stabil laufende Prototyp wurde mit dem Arduino Ethernet Board (erhältlich z.B. bei Pollin) 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 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
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
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 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 ipserver.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
Bitte KEINE weiteren C-Module (wie z.B. ipbootloader.c) im Projekt angeben!
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 Bootloader-Kapitel weiter unten nachzulesen.
Konfiguration
Es können etliche Parameter angepasst werden. Hier die wichtigsten Einstellungen:
ipserver.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
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
#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
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 softwaremäßig den Ethernet-Controller aktivieren 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_SELECT_AVAILABLE auf 0 stehenbleiben 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 auf weitere Erläuterungen verzichtet. Im wesentlichen wird hier definiert, welche Pins am ATmega für den IR-Empfänger und für den IR-Sender verwendet werden. Die Port-Einstellungen sind hier vorgewählt auf das oben bereits erwähnte Lochraster-Arduino-Ethernet-Shield - siehe Schaltbild. 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. 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 Android-App testen oder erstmal mit einem PC-Testprogramm, siehe weiter unten.
Ganz Mutige lassen das aber mit dem Programmieren der Remote-IRMP-Software über den ISP, sondern installieren direkt den Bootloader, siehe weiter unten. Anschließend kann man beliebig oft die IRMP-Software oder Updates davon direkt übers Netzwerk installieren.
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 IP-Bootloader-Projekt gehören dann noch folgende Includes:
- w5100.h
- w5100config.h
Bitte KEINE weiteren C-Module (wie z.B. ipserver.c o.ä.) im Projekt angeben!
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 oben. Wichtig ist die Anpassung der IP-Adresse, siehe dafür ipbootloader.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
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 win32/ipflash/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
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
Konfiguration
Nach dem ersten Start der App sollte zunächst mindestens ein Remote-IRMP-Satellit konfiguriert werden. Dazu wählt man unter dem Menü den Punkt "Server" an und wählt den ersten Server aus. Hier kann man einen Namen wählen, z.B. "Wohnzimmer". Nach Eingabe der IP-Adresse und des UDP-Ports (i.d.R. 10001) kann man zunächst die Verbindung testen. War diese erfolgreich, speichert man die Serverkonfiguration mit "OK" ab.
Bearbeiten
In der App sind bereits einige Geräte und ein paar Tasten als Beispiel gespeichert. Die verschiedenen Bildschirmseiten kann man durch Wischen nach links oder rechts anwählen.
Mit der Anwahl des Menüpunktes "Bearbeiten" kann man nun eine (oder direkt mehrere) Seiten ändern. Oben erscheint dann eine zusätzliche Schaltfläche zum Speichern. Unmittelbar darunter kann die Bezeichnung der Seite geändert werden.
Die bisherigen Tasten werden nun etwas nach unten hin "gestreckt" gezeigt. Das ist Absicht: Die Leerzeilen repräsentieren nämlich später jeweils einen kleinen Abstand zwischen Tastenzeilen. Tippt man nun auf eine leere Fläche, erscheint dort eine neue Taste. Durch erneutes Antippen wird die Konfiguration der Taste geöffnet. Nach Eingabe einer Bezeichnung (Bitte keine Smilies o.ä. eingeben, das kann beim Speichern im Moment noch die Konfiguration zerschiessen!) kann man nun die Taste anlernen. Dafür tippt man die Anlernen-Schaltfläche an. Nun hat man 5 Sekunden Zeit, die gewünschte Taste anzulernen, indem man sie auf der Fernbedienung drückt und dabei auf den IR-Empfänger zielt. Nun sollte das Protokoll, die Adresse und das Kommando erscheinen. Man kann diese Parameter zwar auch manuell eingeben, jedoch ist die Übernahme durch Anlernen doch um einiges einfacher.
Nach dem Speichern sollte ein kurzes Antippen der konfigurierten Tasten den Remote-IRMP-Sender dazu bewegen, den vorher angelernten IR-Code wieder auszusenden.
Eine Taste kann durch langes Drücken im Bearbeitungsmodus gelöscht werden.
(Beschreibung wird fortgesetzt)
Weitere Planung
- Erweiterung um Graphiksymbole für die Tasten
- Anlernen von Funksteckdosen-Fernbedienungen
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 Testprogramm 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 win32/ipclient/ipclient.c -o ipclient
Aufruf des Testprogramms
Allgemeiner Aufruf:
IR-Code senden über UDP:
ipclient udpsend ipaddress udp-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 udp-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: 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
Remote-IRMP für AVR, Unix, Linux, Windows
Version 1.3: Datei:Remote-irmp.zip
Änderungen 1.3:
- ipserver.c Bugfix im UDP-Teil: Antwort mit 'R' bei Kommando 'R' und 'S' bei Kommando 'S'
- Update IRMP auf 2.9.7b 2015-11-30
- ipclient.c für PC: zusätzliche Ausgabe des IRMP-Protokollnamens
Remote-Butler als Client für Android
Version 1.0: Datei:RemoteButler.apk
Das einfachste, um die App unter Android zu installieren, ist es, den obigen Download-Link direkt auf dem Handy anzuklicken.
Java-Sources für Interessierte: Datei:Remotebutler.zip
Version 1.1: Datei:AndroidRemoteButler.7z
Changelog:
- Konvertierung auf Android Studio
- IRMP Update auf 02.07.15
- neue Seite "Makros" angelegt
- Rudimentäre Makrofunktion: ist eine Taste auf der ersten Seite ("Makros") in der Farbe blau, so werden bei Druck auf den Button alle andersfarbigen nachfolgenden Buttons/Befehle nacheinander gesendet, so lange, bis ein ausgeblendeter Button oder ein neuer blauer Makrobutton erscheint. Den zeitlichen Abstand zwischen dem Senden der Befehle kann durch bearbeiten des blauen Makrobuttons geändert werden.
ToDo:
- Senden bei Makrofunktion im neuen Thread starten, da der gesamte Gui-Thread während des Sendens gelockt ist
Dateiliste
| Dateiname | Erläuterung |
|---|---|
| ipbootloader.aps | AVR Studio4 Projektdatei des Bootloaders |
| ipbootloader.c | main-Modul des Bootloaders |
| ipserver.aps | AVR Studio4 Projektdatei des IP-Servers |
| ipserver.c | main-Modul des IP-Servers |
| irmp.c | Der eigentliche IR-Decoder |
| irmp.h | Include-Datei für IRMP-Projekte |
| irmpconfig.h | Konfiguration für IRMP |
| irmpextlog.c | IRMP-Logging für Nicht-AVR-µCs |
| irmpextlog.h | IRMP-Interne Include-Datei |
| irmpprotocols.h | Sämtliche Definitionen zu den IR-Protokollen |
| irmpsystem.h | Vom Zielsystem abhängige Definitionen für AVR/PIC/STM32 |
| irsnd.c | Der eigentliche IR-Encoder |
| irsnd.h | Include-Datei für die Applikation |
| irsndconfig.h | Anzupassende Konfigurationsdatei |
| w5100.c | Treiber-Modul für WIZnet W5100 Netzwerk-Controller |
| w5100.h | Include-Datei für W5100-Treiber |
| w5100config.h | Konfigurationsdatei für W5100-Treiber |
| ipclient.exe | ipclient-Executable für Windows |
| ipflash.exe | ipflash-Executable für Windows |
| win32/ipclient/ipclient.c | Beispiel Client in C - übersetzbar unter Unix, Linux und Windows |
| win32/ipclient/ipclient.sln | gehört zu ipclient - für Microsoft Visual C++ 2010 Express |
| win32/ipclient/ipclient.suo | gehört zu ipclient - für Microsoft Visual C++ 2010 Express |
| win32/ipclient/ipclient.vcxproj | Projekt-Datei für Microsoft Visual C++ 2010 Express |
| win32/ipflash/ipflash.c | Flash-Programm in C - übersetzbar unter Unix, Linux und Windows |
| win32/ipflash/ipflash.sln | gehört zu ipflash - für Microsoft Visual C++ 2010 Express |
| win32/ipflash/ipflash.suo | gehört zu ipflash - für Microsoft Visual C++ 2010 Express |
| win32/ipflash/ipflash.vcxproj | Projekt-Datei für Microsoft Visual C++ 2010 Express |
Siehe auch
Viel Spaß mit Remote IRMP!