Inhaltsverzeichnis

1. Vorwort Inhalt

Wie bereits am Ende der Beschreibung zum ersten Controller angekündigt, ist das System nicht optimal. Gelegentliche Farbblitzer und zu geringe Auflösung in dunklen Bereichen bei 10 Bit hinterlassen einen nicht ganz so positiven Eindruck. Zwar könnte man mit Diffusionsfolie noch ein Stück weit kommen, eines Ingenieurs ist das aber nicht würdig 🙂

Es gilt daher, die vorhandenen Schwächen mittels neuer Hardware zu beseitigen. Im Wesentlichen sind das:

• Software-PWM
• Nur 10 bit Auflösung bei 75 Hertz PWM-Grundfrequenz
• Insgesamt drei RGB-Kanäle, sprich 9 PWM-Kanäle

Die theoretischen Kapitel über Ambilight, Biologie (Gammakorrektur) und PWM aus dem Artikel Ambient Light im Eigenbau gelten auch für diesen Controller, es macht daher Sinn, den Artikel zuerst zu lesen, so noch nicht geschehen.

2. Atmels XMega-AVR Baureihe Inhalt

Wie schon in Ambient Light im Eigenbau (Seite 5) im Unterkapitel „MCU al­lei­ne oder mit de­di­zier­tem LED-?Trei­ber?“ beschrieben existierte bis dato keine vernüftige Hardware-Lösung, wenn mann einmal von FPGA-Programmierung absieht. Mittlerweile aber sind von Atmel Chips der Baureihe ATxMega lieferbar (waren seit Mitte 2008 angekündigt!). Sie zeichnen sich durch geringeren Stromverbrauch, einheitlicheres Hardware-Design und höhere Taktfrequenz aus.

Ich habe mich für einen ATxMega16A4 entschieden, da das TQFP44-Gehäuse noch einigermaßen im Eigenbau behandelbar ist, sowohl mit Ätzen wieauch zum Löten an sich. Außerdem bietet der Chip bereits alle Voraussetzungen, die wir für die neue Hardware brauchen:

• 16 PWM-Kanäle mit je 16 Bit Auflösung
• 5 USARTS (wir benötigen nur einen)
• Taktfrequenz bis 32 Mhz
• AES/DES-Crypto-Engine (die wir aber nicht brauchen)
• 3,3V Betriebsspannung
• 16 KByte Flash-ROM, optionaler Bootloader

Mit Mustern schauts relativ mau aus, ich hatte aber das Glück, bei Farnell welche zu bekommen. Leider gibt’s Stand heute (12/2009) bei Digikey nur die großen TQFP100 oder BGA-Gehäuse, offenbar dürfen sie wegen der AES-Crypto-Engine nicht exportiert werden, in den USA wären sie nämlich lieferbar. Das soll einer verstehen, vor allem, weil die großen die Crypto-Funktionen ebenfalls besitzen.

3. Schnittstelle am PC Inhalt

Etwas länger habe ich überlegt, ob Version 2 für die Datenübertragung wieder eine USB-Schnittstelle bekommen soll. Der FTDI-Chip hätte nämlich einige Vorteile. Nicht nur, dass er fast ohne externe Bauteile auskommt und sich vollständig um die Kommunikation mit dem PC kümmert, er hätte auch einen 3,3V Ausgang, um den Atmel mit Strom zu versorgen.

Ich habe mich dann aber dagegen entschieden, im Wesentlichen aus zwei Gründen:

1. Das Teil ist schweineteuer. Fünf EUR beim Reichelt sind mir einfach zu viel, v.a. wenn es ein ganzes Kabel bei eBay für knapp 4 € gibt.
2. Aus Erfahrung mit dem ersten Controller weiß ich, dass das System einen Standby mit geöffnetem COM-Port nicht überlebt, sprich man mußte den Controller nach jedem Aufwachen des Rechners erst einmal wieder abstecken und wieder hinstecken, damit der COM-Port wieder existierte. Die Software Boblight erkennt einen Standby aber nicht und läßt den COM-Port ständig offen. Das funktioniert unter Windows XP aber nur mit einer Hardware-Schnittstelle zuverlässig.

Der neue Controller wird deswegen keinen USB-Anschluss bieten. Wer möchte, kann sich einen mittels USB2Serial-Kabel selbst konstruieren, sei aber darauf hingewiesen, dass das bei mir nicht richtig funktionierte.

Hinweis: Auf der Platine sind die RX-/TX-Leitungen der seriellen Buchse vertauscht. Man kann den Controller daher nur mit einem Nullmodem-Kabel betreiben. Wenn ihr einen USB2Serial-Adapter benutzt, wird der nicht direkt an der Buchse funktionieren. Entweder ihr zieht die Leiterbahnen neu, oder schaltet noch ein Nullmodem-Kabel zwischen Controller und Adapter.