PoE-LED-Leuchte – Teil 1

PoE-LED-Leuchte – Teil 1

Power-Over-Ethernet ist eine echt tolle Sache. Immer häufiger werden Geräte, auch im
industriellen Umfeld, mit dieser Technik ausgestattet. Die Vorteile liegen klar auf der Hand:

  • Geringer Aufwand bei der Verkabelung
  • Zentrales PoE-Netzteil am PoE-Switch
  • Netzteil kann über eine zentrale USV abgesichert werden
  • Nur ein Kabel für Energieversorgung und Datenaustausch

Kürzlich haben wir ihm Rahmen eines Kundenprojektes die komplette Firmware für ein PoE-Gerät entwickelt. Es handelt sich bei diesem Gerät um eine LED-Leuchte welche für die Beleuchtung bei Videoaufnahmen ein flicker-freies Licht abgeben soll.

Unsere Aufgabe bestand dabei aus der Entwicklung der folgenden Features:

  • Ausgabe einer PWM zur Steuerung des LED-Treibers
  • Implementierung eines TCP/IP Stacks
  • Adressierung via DHCP/AutoIP/Statisch
  • Implementierung eines Kommando-Terminals zur Steuerung der Leuchte via UDP-Broadcasts.
  • Implementierung eines einfachen Web-Servers
  • Aufbau einer kleinen kompakten Web-Seite, welche nebst der Steuerung und Einstellung der Lampe über UDP-Telegramme, die Steuerung und Einstellung auch über den Web-Server erlaubt.
  • Sämtliche Leuchten spezifischen Daten sollen in einem/zwei EEPROMs, welche an einem I²C Bus hängen, gespeichert werden
  • Firmware Updates sollen über Ethernet mittels eines Bootloaders möglich sein
  • Web-Seiten Updates sollen über Ethernet möglich sein
  • Messen von Versorgungsspannung und LED-Strom
  • Ausgabe der Werte von Versorgungsspannung und LED-Strom über Terminal und Web-Server

In diesem ersten Teil der Artikelserie gehen wir zunächst auf die hardwarenahe Entwicklung der benötigten Peripherietreiber und das für die Entwicklung genutzte Development-Board PIC-Web von Olimex ein.

Development-Boad Olimex PIC-Web

Nach der Analyse des Schaltplans der PoE-LED Leuchte zeichnete sich klar ab, dass der Schaltungsteil rund um den Mikrocontroller, sowie der Mikrocontroller selbst dem sehr nahe kommt, was Olimex mit dem PIC-Web im Angebot hat.

Kunden-Hardware

  • Mikrocontroller: PIC18F67J60
  • Schnittstellen: Ethernet
  • Power: PoE
  • ADC1: Strommessung über Shunt
  • ADC2: Spannungsmessung
  • Externer Speicher A: 2 kbit EEPROM (I²C-Bus)
  • Externer Speicher B: 64 kbit EEPROM (I²C-Bus)
  • Firmware: keine

Olimex PIC-Web

  • Mikrocontroller: PIC18F67J60
  • Schnittstellen: Ethernet, RS232
  • Power: Externes Netzteil
  • ADC1: Potentiometer
  • ADC2: NTC
  • Externer Speicher: 1 Mbit Flash (SPI-Bus)
  • Firmware: Beispielprojekt von Olimex, basierend auf dem TCP/IP-Stack von Microchip. Beinhaltet auch einen Web-Server

Damit stand fest dass sich das PIC-Web sehr gut als Ausgangsbasis für diese Entwicklung eignet. Soweit so gut…Dennoch waren die Kunden-Hardware und das PIC-Web nicht identisch. Was galt es also zu tun um die beiden Schaltungen einander anzugleichen? Oberste Priorität lag auf dem externen Speicher. Glücklicherweise sind beim PIC-Web die I2C Pins des Controllers auf die 10-polige Stiftleiste herausgeführt. Wir konnten also auch I²C-EEPROM Chips an das PIC-Web anschließen. Also mal eben etwas Lochrasterplatine aus der Schublade geholt und ein I²C-EEPROM aufgelötet. Und fertig war das Aufsteck-Board mit 1Mbit I²C-EEPROM.


Aufsteck-Board mit 1Mbit I²C-EEPROM

1 Mbit, 64 kBit, 2 kBit? Was, wie, wo?

Ja, zunächst hatten wir uns für ein EEPROM mit einem Kapazität von 1 MBit entschieden. Dies liegt darin begründet, dass das PIC-Web mit einem, über SPI angebundenen, Flash Speicher mit ebenfalls 1 Mbit verfügt. Und das Demo-Projekt von Olimex kommt mit einer auf dem Flash Speicher gespeicherten Web-Seite daher, welche 38 kByte (304 kBit) groß ist. Für das 8 kByte (64 kBit) EEPROM der Kunden-Hardware ist das noch zu viel. Damit wir uns aber zunächst auf die Programmierung der I²C Treiber konzentrieren konnten, und nicht auch noch gleich die Web-Seite anpassen mussten, entschieden wir uns zunächst für ein, ebenfalls 1 Mbit großes EEPROM.

Ungeachtet dessen, ist es das erklärte Ziel, dass die kundenspezifische Web-Seite auf das 64 kBit EEPROM passt. Alle anderen, nicht flüchtigen Daten zur Leuchte, werden auf dem kleinen 2 kBit EEPROM gespeichert. Von diesen 2 kBit stehen aber nur die ersten 128 Byte (0x00 bis 0x7F) zur freien Verfügung. Die oberen 128 Byte sind dauerhaft schreibgeschützt, beinhalten dafür aber von 0xFA bis 0xFF eine MAC-Adresse (EUI-48TM Node Address), welche nur lesbar ist. Diese MAC-Adresse werden wir für die Ethernet-Schnittstelle verwenden.

Von SPI zu I²C

Wie bereits erwähnt, ist auf dem PIC-Web ein Flash-Speicher (1 Mbit) bestückt, welcher über den SPI-Bus an den Controller angebunden ist. Die Demo-Firmware nutzt diesen Speicher zum Ablegen der Daten zur Ethernet-Schnittstelle (IP-Adresse, Sub-Netz-Maske, Hostname, …) und zum Speichern und Laden der Web-Seite für den Web-Server. Damit wir große Teile dieser Demo-Firmware auch für unser Projekt verwenden können, ist es also nötig die Speicherzugriffe von SPI auf I²C “umzubiegen“. Und um das möglichst effizient zu tun, ersetzten wir alle “low level“ SPI-Treiber durch entsprechende Aufrufe der “low level“ I²C-Treiber. Alle darüber liegenden, mehr abstrahierten Schreib- und Lese Funktionen bekommen somit von dieser Änderung “unter der Haube“ rein gar nichts mit.


Erste Test-Web-Seite (Olimex-Demo) auf dem 1Mbit I²C-EEPROM

Nach einigen Stunden, und Bechern mit schwarzem Kaffee, war es vollbracht. Alle externen Speicherzugriffe gehen jetzt auf den I²C-Bus. Applikationsdaten und Web-Seite liegen nun auf dem 1Mbit I²C-EEPROM.

Die finale Angleichung

Nachdem also sichergestellt war, dass die Speicherzugriffe über I²C solide und zuverlässig funktionierten, war es an der Zeit, das PIC-Web vollends (bezogen auf die EEPROM Speicher) an die Gegebenheiten auf der Kunden-Hardware anzugleichen. Denn zum einen fehlte noch das kleinere 2 kBit EEPROM und zum Anderen kommt auf der Kunden-Hardware für Applikationsdaten und Web-Seite ein kleineres 64 kBit EEPROM zum Einsatz.

Finales Dev-Board

Wieder einige Becher Kaffee später gelang es, eine kleine, schlanke Web-Seite zu bauen, welche nur 7 kByte (56 kBit) Speicher benötigt. Für die Applikationsdaten nutzen wir jetzt die ersten 128 Byte des kleinen 2kBit EEPROM, was völlig ausreichend ist. Insgesamt belaufen sich die Applikationsdaten auf 57 Byte.

Als letzter Punkt auf der I²C-ToDo-Liste stand noch das auslesen und Setzen der MAC-Adresse aus dem EEPROM Adressbereich 0xFA bis 0xFF: Erledigt! Funktioniert.

Im nächsten Teil dieser Artikelserie geben wir Ihnen einen Einblick in die Entwicklung des Kommando-Terminals und des Befehls-Parsers.

Schreibe einen Kommentar