[atmocontroller] Betrieb unter Windows

hi,

im anhang befindet sich der VHDL-Code und die Block-Files (für QuartusII) des projekts (bitte lizenz beachten).

ich hab das design jetzt auf 16kanäle mit jeweils 10bit geändert.
deswegen müssen jetzt 16 * 3 * 2 = 96 Bytes gesendet werden, zuerst das lower, dann das upper byte (vom upper byte werden nur LSB und LSB+1 berücksichtigt).
ein ACK kommt erst dann, wenn das 96te byte angekommen ist.
rücklesen ist denke ich für ein 'consumer' gerät nicht notwendig. die kommunikation ist hinreichend sicher.

slime
ok - der VHDL Code schaut interessant aus - *auch wenn ich davon überhaupt keine Ahnung hab* -- hab nur ein Erfahrung mit PIC's in Assembler oder C.

Also muss ich deiner Hardware nicht den Farbwert übergeben, sondern quasi den PWM Dutycyle als 16-bit Int (Little endian) wovon nur die unteren 10bit verwendet sind?

daß heißt ich brauche eine Tabelle für die Umsetzung der RGB Werte ins Dutycycle - ggf. eine Berechnungsformel tut es auch, dann kann ich diese einmalig beim Programmstart berechnen.
Bei der klassischen Atmo Hardware ist diese LUT ja in der Firmware des Controllers enthalten...?

Igor

Zitat

Original von Igor
Also muss ich deiner Hardware nicht den Farbwert übergeben, sondern quasi den PWM Dutycyle als 16-bit Int (Little endian) wovon nur die unteren 10bit verwendet sind?

mmh... ist noch nicht little-endian, aber das ist in der hardware einfach zu drehen. momentan steht das noch so drin:

b7 b6 b5 b4 b3 b2 b1 b0 bx bx bx bx bx bx b8 b9
(b0..b9 = nutzdaten, bx = ignore)

ich werds aber auf

bx bx bx bx bx bx b9 b8 b7 b6 b5 b4 b3 b2 b1 b0

abändern.
momentan sieht das so übel aus, weils noch ein quick'n'dirty hack ist

Zitat

daß heißt ich brauche eine Tabelle für die Umsetzung der RGB Werte ins Dutycycle - ggf. eine Berechnungsformel tut es auch, dann kann ich diese einmalig beim Programmstart berechnen.
Bei der klassischen Atmo Hardware ist diese LUT ja in der Firmware des Controllers enthalten...?

die tabelle kann ich aber brechnen/erklären. das ist eine gamma-korrektur. im prinzip nix anderes als eine e-funktion, normiert zwischen 0 und 1. damit wird der PWM-Wert multipliziert. die steigung/exponent der e-funktion entspricht dem gamma-wert.
ich muss aber mal im passenden buch nachsehen, wie man die am besten an das menschliche auge fittet. eine passende formel dafür liefer ich dann nach.

sinnvoll ist es dann, in der software parameter für den max-pwm-wert und den gamma-wert der drei farben vorzusehen. daraus lässt sich dann diese LUT ableiten. weissabgleich ist dann über den maxwert implizit mit drin.

der CPLD hat leider nicht ansatzweise resourcen um das selbst zu implementieren. ich bräuchte ja 10x1024x3bit speicher für die LUT... aber der chip hat nur 1270 gates.
der chip hat noch UFM (userflashmemory), das würde sich aber nur über JTAG beschreiben lassen, scheidet dafür also aus.

Hallo zusammen,

bin neu hier im Board und hauptsächlich wegen AtmoLight und AtmoWin hier. Ich habe mir bei Carsten bereits eine Atmolight USB Platine bestellt (kommt hoffentlich morgen an) und dazu die Dioder von IKEA. Da ich die Software unter Vista betreiben möchte stellen sich mir derzeit ein paar Fragen, auf die ich auch auf den letzten gefühlten 100 Seiten dieses Themas keine passende Antwort gefunden habe.

1. Funktioniert die Bildanalyse vom AtmoWin mittlerweile auch bei aktiviertem Overlay bzw. Hardware-Beschleunigung unter Vista?

2. Wie ist der Fortschritt des DirectShow-Filter-Projekts?

3. Funktioniert Boblight / AtMoMolight DS Filter auch mit der Platine von Carsten?

4. Wie sieht es momentan mit der Performance von AtmoWin aus - sprich: Wie viel CPU Last wird aktuell verursacht im Live Modus?

Würde mich freuen wenn Ihr meine Fragen beantworten könntet.

Viele Grüße,

Cedric

Cassiel
Na dann erstmal herzlich willkommen.

Ich versuche dann mal deine Frage(n) zu beantworten ...

Zitat

1. Funktioniert die Bildanalyse vom AtmoWin mittlerweile auch bei aktiviertem Overlay bzw. Hardware-Beschleunigung unter Vista?

Hardwarebeschleunigung denke ich dürfte nicht das Problem sein.
-- Overlay hingegen wird unter keinem Windows funktionieren - an den Bildinhalt kommt man nicht heran - via Screencaptureing.
- für den normalen Desktop denke ich sollte es gehen, wenn die die 0.45 Version nimmst - und dort die GDI Framerate auf 5-10 reduzierst - dürfte sich das auch in der CPU Last nicht so stark bemerkbar machen.
(10-15% auf einem AMD X2 4600+)

Zitat

2. Wie ist der Fortschritt des DirectShow-Filter-Projekts?

vermutlich rund 0 - da brshub der das eigentlich machen wollte, nie damit richtig angefangen hat? Ich selbst hatte auch keinen Bedarf nach einem DirectShow Filter - also hab ich mich da auch nicht weiter darum gekümmert. -- Also Freiwillige vor ...

Zitat

3. Funktioniert Boblight / AtMoMolight DS Filter auch mit der Platine von Carsten?

dazu kann ich nichts sagen, da ich diese Filter nicht kenne / probiert habe? -- weiß jemand ne Antwort?

Zitat

4. Wie sieht es momentan mit der Performance von AtmoWin aus - sprich: Wie viel CPU Last wird aktuell verursacht im Live Modus?

AtmoWin kenn zwei LiveModi - der Modus welcher den Desktop captured ist am CPU lastigsten. Die alte 0.44er Version hat da je nach laufenden Programmen 20-25% auf meinem X2 4600+ gezogen. (seltsamerweise scheinen bestimmte Programme wenn, die laufen die CPU Last noch zu erhöhen, welche AtmoWin verursacht, was ich mir bis heute nicht richtig erklären kann.)

- die 0.45Version, welche ich ein paar Postings weiter oben, für Slime modifiziert habe, ermöglich eine Reduzierung der GDI Captureframerate, und somit auch ein Anpassen der CPU Last. Mit 10 Frames/s hab ich noch ca. 10-15% CPU Last.

Der zweite LiveModus - erhält seine Daten über eine externe Schnittstelle. In der Kopplung mit VideoLan wird ja kein GDI Modus verwendet, sondern ein Filter im VideoLan übergibt die Pixeldaten direkt an AtmoWin - dadurch ist beim Filmegucken die Last durch AtmoWin doch sehr gering, d.h. im einstelligen Prozentbereich.
(mit einem DirectShow Filter für die sonstigen Windows Media Player, wäre das wohl auch der Fall ;-))

Igor

Hallo Igor,

Danke für deine Ausführungen. Ich habe zum Testen gestern mal die Version 0.44 installiert und die Dummy-Ausgabe aktiviert. Komischerweise bekomme ich selbst bei 720p und Standardeinstellungen nicht höher als auf 5% CPU-Last durch AtmoWinA.exe. Kann es sein, dass Vista mit Aero auch die GDI / GDIplus hardwareseitig beschleunigt? Werde ich wohl mal ausführlicher testen müssen...

Cassiel
- mmh - ich verwende noch Windows2000 :), kann schon sein, das da noch eine Reihe anderer Faktoren ne Rolle spielen -

GDIPlus - verwende ich überhaupt nicht, kann aber trotzdem sein das unter Vista auch die GDI ein wenig besser optimiert ist - vielleicht auch von GDI Plus profitiert...?

naja - bei mir ist ja die CPU Last die AtmoWin verbrät auch nur so hoch, wenn ich z.B. Trillian laufen haben, da kommt selbst aus Gründen die mir bis heute nicht einleuchten, die VLC Spdif Ausgabe ins Stocken, nach wenigen Minuten. Was ohne laufendes Trillian nicht passiert...
(es ist aber nicht nur der Instantmessenger, welcher das Problem bei mir verursacht - es gibt ne Reihe weiterer Programme mit diesem Effekt.)

Igpr

Igor

Ich werde heute Abend Aero mal deaktivieren und auf die CPU-Last achten. Außerdem sehr merkwürdig: Wenn ich ein Video in Vista Media Center laufen lasse, werden dennoch die Farbinformationen korrekt ausgelesen, ebenso beim Windows Media Player 11. Wie gesagt: Hardwarebeschleunigung ist aktiviert, demnach werden ja auch Overlays und DirectShow genutzt - trotz deiner Aussage das Overlays nicht funktionieren. Werde das die Tage aber noch genauer testen...

Cassiel
Overlay - nicht unbedingt - die neueren Schnittstellen heißen glaube ich VMR das ist was anderes als Overlay - das geht eigene Wege, das könnte auch der Grund sein, warum das Bildschirm Grabbing funktioniert.

Igor

Igor
Ach ja VMR und DXVA ... da war ja was ... stimmt! Wäre auf jeden Fall super wenn's weiterhin so gut funktioniert wie mit der Dummy-Ausgabe. Leider kommen meine Dioder laut IKEA erst nächste Woche.
Außerdem werde ich noch testen ob es mit BluRay-Wiedergabe funktioniert.

So die Platine von Carsten ist angekommen, sieht wirklich super aus und ist sehr ordentlich verarbeitet. 75 EUR die sich definitiv lohnen!

Edit: Gerade noch im Büro flink getestet, da wir noch ein paar LED-Streifen rumfliegen haben. Big Buck Bunny mit Atmolight ist ein Traum. Bin wirklich begeistert!

Hi,

ich finde es interessant, die PWM-Ansteuerung für Atmo/Aurora in ein FPGA/CPLD zu implementieren. Ich hatte ein AtmoLight in Betrieb, bei dem ein ATMega8 4 RGB-Kanäle steuern konnte. Ich habe aber nur 3 Kanäle verwendet. Ich habe aktuell ein AuroraLight mit 36 RGB-Kanälen in Betrieb, bei dem ein ATMega88 je 6 Kanäle steuert.

Du willst eine Auflösung (inklusieve Weißabgleich) von 10Bit realisieren. Ich halte das für nicht ausreichend. Ich habe mit 10Bit angefangen. Das Ergebnis war irgendwie nicht überzeugend. Ich hatte dann eine Variante, die 10 bis 14Bit konnte. Wenn von den jeweiligen RGB-Kanälen die Werte eng beieinander lagen, waren nur 10Bit möglich, sonst der Maximalwert. Jetzt bin ich bei einer konstanten Auflösung von 12Bit bei ca. 100Hz PWM-Frequenz. Ich habe auch 13Bit bei halber PWM-Frequenz getestet. Da habe ich aber gelegentlich ein Flimmern wahr genommen. Ich bin dann bei 12Bit geblieben.

Ich verwende für einen 32 Zoll-TV 36 RGB-Gruppen (je 10 links bzw. rechts und 16 oben). Für das Farberlebnis ist neben der eigentlichen Auflösung auch die Darstellung bzw. Auflösung an der beleuchteten Fläche entscheidend. Ich benutze Superflux-LED's in den Einzelfarben, bei denen die 3 Farben leider unterschiedliche Abstrahlwinkel haben. Ich benötige daher zwangsweise einen Diffusor. Der Diffusor sorgt leider auch für eine starke Vermischung der einzelnen Gruppen, sodaß ich vermutlich mit der halben Anzahl von RGB-Gruppen auf das gleiche Ergebnis kommen würde. Ich bin gerade am Testen von RGB-SMD-LED's. Das Ergebnis sieht gut aus. Die Lichtausbeute ist jedoch relativ niedrig, sodaß ich drei einzelne Superfluxs-LEDs durch mindestens 3 RGB-LEDs ersetzen muß. Für ein AuroraLight wird man mindestens 8 RGB-Gruppen für oben bzw. unten und 4 für links bzw. rechts benötigen.

Du bringst momentan 16 Gruppen bei 10Bit Auflösung in einem CPLD unter. Für ein AuroraLight wird ein einzelner CPLD nicht genügen. Die CPLDs sollten daher kaskadierbar sein. Man benötigt entweder irgendein Adress-Byte im Protokoll oder man muß den entsprechenden CPLD vor der Datenübertragung selektieren können.

Unabhängig von Deinem Ansatz mittels CPLD, halte ich aber die µC Variante für die flexiblere Lösung. Mann kann die µC einfach kaskadieren. Es sind mit meinem Protokoll max. 32 Controller mit je 8 RGB-Gruppen möglich. Der ATMega88 reduziert die Anzahl der RGB-Gruppen auf 6 pro Controller. Es wären damit in Summe 192 oder 256 Gruppen möglich.

Gruß
e9hack

also ich muss zugeben, das ich das ganze noch nicht am fernseher getestet habe. angesehen hab ich mir das design bisher nur am oszi

die idee mit dem CPLD hatte ich, da mit das konzept der daisy-chain-µC nicht gefallen hat. ich gebe zu, vor allem der aufbau von einfach kaskadierbaren platinen ist eine hübsche sache, aber ich wollte von der soft-pwm weg. und da es keine µC mit 'genug' pwm-kanälen gibt, kam halt der CPLD ins spiel.
mein ziel ist eher, zwei-drei ikea-dioder-sets an einem fernseher ansteuern zu können, weniger die beliebig hohe anzahl an pwm-gruppen. mit der hohen pwm-grundfrequenz schaffe ich auch das flimmer, welches das sonderbare ikea-netzteil mitbringt aus der welt (inteferenz mit den 170Hz des original-atmos). bei ungünstigen beleuchtungsverhältnissen kann es bei den eher geringeren soft-pwm-frequenzen auch zu inteferenz mit anderer beleuchtung (leuchtstoffröhren) kommen. dies habe ich auch schon beobachtet.
das ganze wird dann am ende kein aurora-light, sondern nennt sich "mondolight"

der CPLD hat natürlich den nachteil, das ein 'richtiges' protokoll für die datenübertragung eher schwer zu bewerkstelligen ist. soetwas habe ich zwar schon praktisch implementiert, allerdings brauche ich dafür dann auch mehr gates, was dann schon direkt zu einem FPGA führen würde. den wollte ich aber aus kostengründen (40Euro++) aussen vorlassen.

aber auch ohne protokoll lassen sich die chips theoretisch kaskadieren.
meine aktuelle überlegung ist, immer 16bits in ein register zu schreiben, das übertragene MSB ist dann auch das MSB der pwm, und die unteren 2-6bits werden einfach ignoriert, je nach PWM-Auflösung. dann kann die userspace-software einfach immer mit 16bit raushauen und muss sich nicht um die auflösung der hardware kümmern.

Die Auflösung ist auch einfach anzupassen, ich werde heute abend mal ein neues design ansetzen, das 14bits mit 16kanälen (vllt. passen auch 20rein) hat, und einen master - jemand muss mit dem ftdi-chip reden- und einige slaves (über portpins konfigurierbar) erlaubt. damit sind dann 256/2/3 = maximal 42 gruppen möglich; es läuft dann wohl auf einen slave hinaus.

slime
(und wens sonst noch interessiert:)
http://eldo.gotdns.com/atmowin/atmoWin_0.45.zip
http://eldo.gotdns.com/atmowin/atmoWin_0.45_source.zip

bzw. auf der Seite in meiner Signatur ganz unten... als BETA VERSION!

Woran ich gerade arbeite? - Diese Version erlaubt es die Zonenanzahl zu konfigurieren die Analysiert werden - es gibt einen neuen Parameter für:
- Anzahl der Zonen am oberen Rand
- Anzahl der Zonen am unteren Rand
- Anzahl der Zonen Links/Rechts - es wird für beide die gleiche Anzahl genommen.

Insgesamt ist diese Version derzeit auf 16 Zonen limitiert - aber dieses Limit fällt auch noch.

Wozu man das konfigurieren kann? - Damit die Atmo Software auch die richtigen gradienten (Wichtungsfaktoren) bei Bedarf selbst ermitteln kann - wenn keine geeignet Bitmaps vorliegen. Dazu muss die Software ja wissen - wo wieviel Streifen /Zonen sind.

Weiterhin habe ich die Logik erweitert wie AtmoWin nach den .bmp Dateien für die Gradienten sucht - es ist möglich je verwendeter Hardware die Bitmaps zu hinterlegen bzw. je verwendeter Zonen Konfiguration - die notwendigen Ordner (leer) entstehen automatisch.

Es gewinnt dabei für die jeweilige Zone immer die Datei welche am weitesten unten in Ordnerstruktur gefunden wird. (wenn man das so beschreiben kann.)

Zur Zeit kann man sich das Ergebnis nur mit dem Dummy Device anschauen...- oder damit halt simulieren... da die "alte" Atmo Hardware hat ja höchstens 5 Kanäle.

Evtl. könnte der User VDR+DMX noch hiervon profitieren, welcher eine DMX Hardware mit der Software steuert...

slime - welche Baudrate / Seriellen Schnittstellenparameter braucht deine Hardware?

Igor

coole sache,
an der realen hardware kann ich aber auch erst in ca. 3 wochen testen, da ich das eval-board wieder abgeben musste *heul*
aber chips habe ich schon bestellt, und platinen werde ich hoffentlich am wochenende ordern können (muss noch ein PCB entwerfen).

baudrate/parameter sind egal, da es ein usb-chip ist (FT245RL). da muss nur der com-port stimmen.

Hi Igor,

gibt es den eine Möglichkeit bzw. kannst du in deine Software das einbauen, das man zwei Atmo-Platinen ansteuern kann???

mmh - dürfte eigentlich kein größeres Problem sein - mal schaun,
wenn ich mit den aktuellen umbauten fertig bin.
- Muss dafür ja nur nen neuen Connection Typ ableiten, und ggf. ne zweite serielle Schnittstelle konfigurierbar machen.

oder sowas in diese Richtung.

du willst dir also zwei Quatro Platinen bauen, um somit auf 8 Kanäle zu kommen? -- weil zwei - Zweikanalplatinen kannst du ja schon Hardwaremäßig hintereinander schalten.

Igor

Ja, habe hier zwei Platinen. Eine hinterm Fernseher und eine hinterm Sofa.

Benutze z.Z. Atmowin und Boblight. Atmowin für den Fernseher und Boblight für Sofabeleuchtung. Wäre nicht schlecht, wenn das gehen würde. Und vielleicht das man für jede Platine andere Einstellungen verwenden kann.

Hallo,

mmh - also komplett getrennte Einstellung das wird wohl nix werden, das geht vom Ansatz her nicht, ich hätte dann höchstens die Möglichkeit gehabt - beide physischen Geräte in AtmoWin als ein logisches Gerät mit 8 Kanälen anzusprechen.

Igor

Update
für die Version AtmoWin 0.44 - muss ich doch mal ein Update nachschieben, was denke ich jeder installieren sollte - es hatte sich ein Fehler eingeschlichen in die Funktion welche die Gewichtung der Pixel den Zonen zuteiltete.

Dabei wurde das Rechte Drittel des Bildschirms sogut wie überhaupt nicht - beachtet, bzw. mit zufälligen Werten gewichtet.

Wer also bei seinem AtmoWin unter Windows - bemerkt hat das die Farbe an der rechten Seite sich komisch verhält - z.T. auf Farben reagiert die schon deutlich links der Mitte liegen, obwohl rechts noch genügend hellere Farben vorhanden waren - sollte das Update installieren.
(hat aber auch Auswirkung auf die anderen Kanäle - bloss da vielleicht nicht ganz so offensichtlich.) --> speziell wenn man EdgeWeightning auf 10 oder höher stellt bekommt man es mit.

Wo war der Bug?
AtmoZoneDefinition.cpp in der Funktion UpdateWeighting statt die Variable cols bis CAP_WIDTH zu zählen, stand dort CAP_HEIGHT - so blieben immer 16 Pixelspalten der 64x48 Pixel grossen Probe am rechten Rand unberücksichtigt.

http://eldo.gotdns.com/atmowin/atmoWin_0.44b.zip
http://eldo.gotdns.com/atmowin/atmoWin_0.44b_source.zip

(ebenso auf meiner primacom seite verfügbar)

Im Wiki kann ich sie gerade nicht verlinken, weil bei mir irgendwie keine Verbindung dorthin zustande kommt... lädt und lädt - aber es passiert nix.

Igor

PS.: der Bug hat mich jetzt zwei Tage bei meiner Weiterentwicklung genarrt... weil plötzlich nach einer kleinen Änderung überhaupt nix mehr ging...