[atmocontroller] Betrieb unter Windows

Endlich habe ich es geschafft, Atmowin+HW richtig in Betrieb zu nehmen. Vielen Dank an alle beteiligten.

Wer es mal in Action sehen will:
U Tube

swifty

Hallo, ich bin neu hier und möchte mich erst mal bei den Hard- und Softwareentwicklern bedanken.
Ich hätte da allerdings noch zwei Fragen zu dem Thema:

1. Funktioniert das momentane Atmowin auch ordentlich mit Spielen? Ich habe dazu leider nur in den Patchnotes was gefunden, aber da die meisten hier einen VDR ausstatten wollen, ist das sicherlich auch nicht das primäre Ziel gewesen, wäre allerdings wichtig für mich(WoW-Süchtling...)

2. Funktioniert die Atmowin auch mit ccfl, oder ist das auch von der Hardware abhängig? Ob die Unterstützung nun rausgeflogen ist oder nicht, kann ich nicht mehr beurteilen nach dem Lesen der ganzen Posts. Die Videos die ich bisher mit CCFLs gesehen habe, sehen auf jeden Fall schon einmal extrem gut aus.

3. Gibt es schon irgendeine fortgeschrittene Entwicklung der ganzen Angelegenheit in Sachen Filter?

swifty99: erinnert mich irgendwie an tvtotal

Firedancer
zu 1) - kommt auf die Definition "ordentlich" an - prinzipiell ja - wenn man als Quell den Screencapture Modus aktiviert - was allerdings eine merklich Erhöhung der CPU Last mit sich bringt. (Liegt in der Natur der Dinge - besser Windows... ne richtige Ursache haben wir nicht gefunden.)

zu 2) - das ist eher ein Problem der Hardware - wenn du dir ne Hardware besorgst die mit CCFL's kann und die an der seriellen Schnittstelle das gleiche Protokoll schluckt geht es sofort. Andernfalls müsste für deine Hardware eine entsprechende Adapterklasse geschrieben und in AtmoWin einkompiliert werden -- für ne Kiste gutes Bier mach ich sowas

zu 3)
Für VideoLan in den 0.9.xer Version (www.videolan.org) gibts den passenden Filter "atmo" (ist in Standardinstallation enthalten.) - der auch auf die Hardware zugreifen - oder via AtmoWin das ganze ansteuern kann -- ist auch hier im Wiki beschrieben, wie man das Gespann zum Laufen bekommt.

Der DirectShow Filter ist IHMO nie angefangen / fertig oder sonstwie entwickelt wurden... kannst dich da gerne Produzieren..*G*

Igor

Grüß Gott.

Habe mir mal den neuesten VLC gegönnt.
Seit dem geht leider das Atmolight nicht mehr.

Die Hinweise aus dem Wiki habe ich weitgehenst befolgt...

VLC installiert und dabei den alten VLC deinstallieren lassen...
(Die alte Version war glaube ich eine ältere Distri von Igor)

Im VLC strg + p:
Einstellungen zeigen: alle

links den Baum Video öffnen und auf Filter einmal links geklickt.
Dann das Häkchen auf der rechten Seite bei AtmoLight-Filter gesetzt.
Nun noch den Baum Filter geöffnet und bei AtmoLight-Filter einstellungen folgendes:
Eingebautes AtmoLight verwenden: aus
Serieller Port/Gerät: COM6
Dateiname von AtmoWinA.exe: D:\atmoWin_0.44\AtmoWinA.exe

Leider nichts.
Wenn ich ein Video im Vollbild anschaue ist das Atmolight solange weiß, wie die VLC-Bedien-Konsole angezeigt wird. Wenn die nach ein paar sekunden verschwindet, wird auch mein AtmoLight dunkel (AtmoLightProgramm in der Version 0.44 läuft im Hintergrund weiter)

An welchen Parametern kann ich denn nun mal versuchen was zu ändern?

Gruß
Ingo

Hallo,

mmh bei meinem Private Build vom VLC vor ner Woche gings noch
- hast du auch die AtmoCtrlLib.dll aus dem AtmoWin Ordner in den Rootordner von VLC kopiert? (d.h. dorthin wo die vlc.exe liegt.)

Den Comport musst du nur einstellen, wenn die gesamte Steuerung an Videolan abtreten willst - d.h. die AtmoWinA.exe umgehen möchtest.

Wenn auch das nicht hilft - versuch dem VLC mal ein Protokoll abzugewinnen -- "Level 3" dann helf ich da weiter...

Igor

Servus,

Hatte die AtmoCtrlLib.dll dorthin kopiert, wo auch die vlc.exe liegt...

Habe es gerade nochmal versucht...
siehe da, es geht!!!!

Wahrscheinlich hätte ich den Rechner nach der Installation neu starten müssen???

habe jetzt folgende Einstellungen:
- Eingebautes Atmolight verwenden: off
- serieller Port: COM6
- Dateiname von AtmoWinA.exe: D:\atmoWin_0.44\AtmoWinA.exe

Trotzdem vielen Dank für die Mühe und weiterhin gutes Gelingen...

Etwas, was ich noch rausgefunden habe:
Wenn ich Atmolight starte und dann ein Spiel zocken will, kommt es (je nach Spiel) vor, dass das Spiel abstürzt.
In solchen Fällen hat es fast immer geklappt, wenn ich erst das Spiel gestartet habe und dann wenn es lief, mit ALT + Tab zurück zu Windows wechsele und erst dann Atmolight starte....

Gruß
Ingo

Hallo,
na siehste geht doch

naja den COM Port brauchst du im VLC aber nicht einstellen - wenn du das in VLC eingebaute Atmolight nicht verwendested, die AtmoWinA.exe hat seine eigene Konfiguration.

Die Dll "AtmoCtrlLib.dll" ist nur die Brücke zwischen VLC und AtmoWinA.exe ... mehr nicht...

Zitat

Etwas, was ich noch rausgefunden habe:
Wenn ich Atmolight starte und dann ein Spiel zocken will, kommt es (je nach Spiel) vor, dass das Spiel abstürzt.
In solchen Fällen hat es fast immer geklappt, wenn ich erst das Spiel gestartet habe und dann wenn es lief, mit ALT + Tab zurück zu Windows wechsele und erst dann Atmolight starte....

mmh - den Effekt kenn ich bisher noch nicht - 1. da ich so selten spiele und 2. sich noch keiner weiter beschwert hat...

Was für Spiel bestimmte?
Welches Betriebssystem?
Servicepacks?
irgendwelche spezielle Grafikeinstellungen?
- Vielleicht wechselt das Spiel die Auflösung und der Code im AtmoWinA.exe baut dabei mist? (hab ich ehrlich gesagt selbst nie so richtige getestet sondern aus der OriginalVersion übernommen?)

Igor

Servus,

Im moment finde ich kein Spiel, dass Probleme macht...
Ansonsten handelt es sich um ein Win XP SP 2...

Lediglich ÜberIcon stürzt ab, wenn ich AtmoLight starte.
Bei ÜberIcon handelt es sich um ein PimpMyDesktop-Tool. Also nichts schlimmes...

Guten Tag alle zusammen,

habe meine Stereo Version vom Atmolight mit Atmowin nun auch erfolgreich in Betrieb genommen und bin begeistert...

Mit den richtigen Einstellungen zieht es sogar gleichauf mit nem Philips Ambilight ... echt klasse!

Da ich allerdings Vista als OS nutze kommt es Stellenweise zu extrem hohen Peaks bei der CPU Last... bis hin zu 80%....

Gibt es keine Möglichkeit das zu mindern?

Jedenfalls ist es schonmal viel besser als mit BobLight in der neusten Version für die Atmo Hardware, denn das lässt sich nur mit abgeschaltetem Aero starten... dann ist die CPU Last jedoch wesentlich geringer ...

Ein Teufelskreis

Zufrieden bin ich jedoch allemal...

Gruß
Christian

Hallo,

das Problem mit der Aero Oberfläche ist bekannt, leider und auch die Hohe CPU Last ist uns auch schon aufgefallen - allerdings hab ich selbst dafür keine Lösung - das Hauptproblem ist hier wohl das anfertigen des Screenshots vom aktuellen Desktop ich hab da schon allerhand versucht - aber keine wirklich Verbesserung erreicht -- vielleicht gibt es unter Vista und Co. dafür bessere neuere Schnittstellen? (als die betagten GDI Funktionen...) - da ich allerdings kein Vista zum Testen oder entwickeln habe - müsste da mal jemanden den es ebenfalls stört ans forschen gehen eine bessere Screencopyroutine zu schreiben...

Naja ich benutze es ja eh nur zusammen mit VideoLan ... und da hab ich keine CPU Last Probleme *g*

Igor

Hm gute Frage...

Hilft das hier evtl. weiter?
http://msdn.microsoft.com/en-us/library/bb173477.aspx

Ist auf jedenfall manchmal ziemlich nervtötend
Aber man gewöhnt sich ja dran...

Im direkten Vergleich zu Boblight finde ich übrigens die Art und Weise wie Atmowin die Farben errechnet um längen besser...

Hi,

hat jemand es geschafft Atmowin per Com in C# einzubinden.
Bekomme es irgendwie nicht richtig hin.

Hat jemand ein beispiel dazu??? oder kann mir helfen???

Hi,

soweit ich weiss muss du für C# erstmal sowas wie eine Wrapper DLL erstellen lassen, welche die Brücke zwischen COM und .NET schließt.
(ich habe da aber auch Probleme in einem anderen Projekt damit, COM und .NET sind halt wirklich verschiedene Welten.

ggf. solltest du mal einen Blick auf die "AtmoCtrlLib.dll" werfen, damit könnte man den COM Programmierteil umgehen, statt dessen müsstest du nur ein paar "C" Funktionen importieren - d.h. Header schreiben und das ganze mit LoadLibrary laden.
(ggf. kann man die "AtmoCtrlLib.dll" auch noch für die restlichen Funktionen des COM Server erweitern - zur Zeit sind nur die Funktionen durchgereich welche ich in VideoLAN gebraucht habe.)

Igor

hallo,

ich hab mal bei boblight nachgesehen, wie das dort so gemacht wird. angeblich verbraucht der daemon wesentlich weniger power als atmowin.
vllt. kannst du das ja mal zusammenhacken, igor *liebkuck*

VOID CALLBACK Grabber( HWND hwnd, UINT uMsg, UINT_PTR idEvent, DWORD dwTime)
{
	int width, height, x, y, divide;
	int rgb[3];
	HDC hDC = GetDC(NULL);
	COLORREF pixel;


	if (hDC == NULL) return;

	width  = GetDeviceCaps(hDC, HORZRES);
	height = GetDeviceCaps(hDC, VERTRES);


	if (grab < 1) divide = 1;
	else if (grab > width) divide = width;
	else divide = grab;


	
	boblight_set_scanrange(&config, width, height);

	for (x = 0; x < width; x += width / divide)
	{
		for (y = 0; y < height; y += height / divide)
		{
			pixel = GetPixel(hDC,x,y);
			rgb[0] = (pixel >>  0) & 0xFF;
			rgb[1] = (pixel >>  8) & 0xFF;
			rgb[2] = (pixel >> 16) & 0xFF;
			boblight_add_pixel (&config, rgb, x, y);
		}
	}
	boblight_write_frame(&config);
	ReleaseDC(NULL, hDC);
}

Andernfalls müsste für deine Hardware eine entsprechende Adapterklasse geschrieben und in AtmoWin einkompiliert werden -- für ne Kiste gutes Bier mach ich sowas :-)

kommst du aufs vdr-camp?
bis dahin hab ich evtl. ne neue, bessere hardware zusammen, die leider ein anderes protokoll verlangt (ist kein µC mehr, sondern FPGA. da bin ich mit dem protokoll nicht soo flexibel).

slime
http://eldo.gotdns.com/atmowin/atmoWin_0.45.zip
http://eldo.gotdns.com/atmowin/atmoWin_0.45_source.zip

Habe die Routine mit ein paar Ifdefs mal übernommen, d.h. in der Datei AtmoGdiDisplayCaptureInput.h müssen die defines
#define UseGdiGetPixel
#define UseGdiDesktopGetPixel
gesetzt sein - beide! was auch in obigem Build der Fall ist.

Dann sollte der Code auf die gleiche Weise wie bei Boblight funktionieren, allerdings kann ich dabei auf meinem PC keine wirkliche günstigere CPU Belastung erkennen.

Kommt wohl noch drauf an - wieviele Snapshots macht Boblight pro Sekunde? AtmoWin kommt auf ungefähr 25fps ...

Wie gross ist bei Boblight der Faktor "grab" der am Ende festlegt - wieviele Pixel verarbeitet werden? (Eigentlich ists der Skalierungsfaktor.)
AtmoWin kommt am Ende auf 64x48 Pixel ... sprich 3072 GetPixel Aufrufe pro Frame bzw. 76800 Aufrufe je Sekunde - wie gross ist die Anzahl bei Boblight? und die CPU Belastung?
(auf der gleichen Windows Installation versteht sich!)

Zitat

kommst du aufs vdr-camp?

weiss nicht, wo / wann findet das Statt? Lassen die auch Windows Benutzer rein - oder müssen, die draußen bleiben? (d.h. Eintritt nur gegen Vorlage eines VDR? *G*)

Zitat

bis dahin hab ich evtl. ne neue, bessere hardware zusammen,
die leider ein anderes protokoll verlangt (ist kein µC mehr, sondern FPGA. da bin ich mit dem protokoll nicht soo flexibel).

klingt Interessant - geht es dabei um Aurora Light? - ich wollte bei Gelegenheit AtmoWin sowieso nochmal ein wenig verändern, vor allem was das Handling der Anzahl an Kanäle und Zonen angeht. Von dem starrten Konzept loskommen, dass die Hardware einen Summen, Links, Rechts, Oben, Unten Kanal hat - sondern diese ganze Sache freier definierbar machen.

Hast du schon ne Beschreibung für dein Protokoll? kannst mich ja mal per PM auf den Stand bringen wie die Kommunikation ausschaut.
Wieviel Kanäle werden wir wohl am Ende brauchen 8 / 16 / 32 ??
(werde das wohl am Ende auch in Abhängigkeit der verwendeten Hardware konfigurierbar machen müssen.)

Igor

Zitat

Original von Igor
slime
http://eldo.gotdns.com/atmowin/atmoWin_0.45.zip
http://eldo.gotdns.com/atmowin/atmoWin_0.45_source.zip

Habe die Routine mit ein paar Ifdefs mal übernommen, d.h. in der Datei AtmoGdiDisplayCaptureInput.h müssen die defines
#define UseGdiGetPixel
#define UseGdiDesktopGetPixel
gesetzt sein - beide! was auch in obigem Build der Fall ist.

Dann sollte der Code auf die gleiche Weise wie bei Boblight funktionieren, allerdings kann ich dabei auf meinem PC keine wirkliche günstigere CPU Belastung erkennen.

Kommt wohl noch drauf an - wieviele Snapshots macht Boblight pro Sekunde? AtmoWin kommt auf ungefähr 25fps ...

Wie gross ist bei Boblight der Faktor "grab" der am Ende festlegt - wieviele Pixel verarbeitet werden? (Eigentlich ists der Skalierungsfaktor.)
AtmoWin kommt am Ende auf 64x48 Pixel ... sprich 3072 GetPixel Aufrufe pro Frame bzw. 76800 Aufrufe je Sekunde - wie gross ist die Anzahl bei Boblight? und die CPU Belastung?
(auf der gleichen Windows Installation versteht sich!)

Alles anzeigen

sehr cool.
ich werde das alles mal ausgiegieg testen, und auch mal noch einen genaueren blick in die boblight-sourcen wagen.
die fragen nach dem internen processing kann ich dir nicht beantworten, das obige fragment hab ich rauskopier ohne auf den rest zu kucken.
bei der gelegenheit sollte ich mir auch mal nen compiler installieren

ich denke mal, 25fps sind mehr als genug. 5fps sollten auch reichen, das spart gleich mal rechenleistung um den faktor 5.
kannst du das einstellbar machen?

wobei ich selbst am überlegen bin, nicht auch bolblightd umzusteigen. das konzept ansich ist ganz verlockend, einen server zu haben, der die hardware bedient, und dazu clients, die farbinformationen beisteuern.
das würde z.B. einen directx-client ermöglichen. oder clients für sound, ...
der vorteil von atmowin ist allerdings die möglichkeit der zonendefinition... optimal wäre ein merge von beidem

Zitat

weiss nicht, wo / wann findet das Statt? Lassen die auch Windows Benutzer rein - oder müssen, die draußen bleiben? (d.h. Eintritt nur gegen Vorlage eines VDR? *G*)

ich werde wohl auch ohne vdr, nur mit macos oder win32 notebook aufschlagen
www.vdr-camp.de
ist in kandel, das ist ein wenig nördlich von karlsruhe.

Zitat

klingt Interessant - geht es dabei um Aurora Light? - ich wollte bei Gelegenheit AtmoWin sowieso nochmal ein wenig verändern, vor allem was das Handling der Anzahl an Kanäle und Zonen angeht. Von dem starrten Konzept loskommen, dass die Hardware einen Summen, Links, Rechts, Oben, Unten Kanal hat - sondern diese ganze Sache freier definierbar machen.

Hast du schon ne Beschreibung für dein Protokoll? kannst mich ja mal per PM auf den Stand bringen wie die Kommunikation ausschaut.
Wieviel Kanäle werden wir wohl am Ende brauchen 8 / 16 / 32 ??
(werde das wohl am Ende auch in Abhängigkeit der verwendeten Hardware konfigurierbar machen müssen.)

also bisher habe ich 16 8-bit pwm-kanäle drin. 32 passen auf keinen fall in den fpga rein, aber 16 10-bit kanäle könnte passen.
gamma-korrektur muss dann in der software gemacht werden, rechnen kann der chip nicht mehr.
optimalerweise hätte ich mir von der software vorgestellt auch zonenmasken zu haben und diese dann direkt kanälen zuzuordnen.

das protokoll sieht so aus, das einfach über usb-seriell die 16x3=48 internen register mit daten beschickt werden. addressiert werden kann nicht, der chip macht aber autoincrement.
zur kontrolle der position wird nach jedem byte die aktuelle position zurückgeschrieben.

sieht also so aus: (> zur hardware)
> 255 (channel 0, rot)
< 0
> 128 (channel 0, grün)
< 1
> 77 (channel 0, blau)
< 2
> 88 (channel 1, rot)
> 3
...

die hardware bestelt momentan noch aus einem eval-board für den chip, mit ein wenig glück hab ich bis zum camp aber eigene hardware fertig
ich wollte mich von dem ursprünglich angedachten aurora-design lösen, da mir die pwm-frequenz zu niedrig war. ausserdem wollte ich mal was mit einem cpld basteln

Zitat

wobei ich selbst am überlegen bin, nicht auch bolblightd umzusteigen. das konzept ansich ist ganz verlockend, einen server zu haben, der die hardware bedient, und dazu clients, die farbinformationen beisteuern.
das würde z.B. einen directx-client ermöglichen. oder clients für sound, ...
der vorteil von atmowin ist allerdings die möglichkeit der zonendefinition... optimal wäre ein merge von beidem

AtmoWin ist auch ein Server, der die Hardware ansteuert, dem man extern Daten übergeben kann - so funktioniert auch die Kopplung mit VideoLan. D.h. der LiveView Modus kennt zwei unterschiedliche Quellen - einmal den GDI Capture Modus - und den "Externen Modus" über die COM Schnittstelle kann man diese Betriebsart wechseln, und Daten direkt einspeisen.

Angesprochen wird das ganze über eine COM (ActiveX) Schnittstelle...

Igor

slime

Zitat

ich denke mal, 25fps sind mehr als genug. 5fps sollten auch reichen, das spart gleich mal rechenleistung um den faktor 5.
kannst du das einstellbar machen?

kann ich mal bei Gelegenheit machen, ist recht einfach... denke ich.
zumindest für den GDI-Capture-Modus, mal sehen wo noch Platz für ein Edit zur Eingabe der Zahl ist.

das protokoll sieht so aus, das einfach über usb-seriell die 16x3=48 internen register mit daten beschickt werden. addressiert werden kann nicht, der chip macht aber autoincrement.
zur kontrolle der position wird nach jedem byte die aktuelle position zurückgeschrieben.

Zitat

sieht also so aus: (> zur hardware)
> 255 (channel 0, rot)
< 0
> 128 (channel 0, grün)
< 1
> 77 (channel 0, blau)
< 2
> 88 (channel 1, rot)
> 3
...

die hardware bestelt momentan noch aus einem eval-board für den chip, mit ein wenig glück hab ich bis zum camp aber eigene hardware fertig
ich wollte mich von dem ursprünglich angedachten aurora-design lösen, da mir die pwm-frequenz zu niedrig war. ausserdem wollte ich mal was mit einem cpld basteln

Alles anzeigen

klingt eigentlich recht einfach dafür eine passende AtmoWin Adapterklasse zu schreiben. Am Ende kann deine Hardware also 16 Kanäle / Zonen bedienen? - also 48 PWM Kanäle... in einem Chip?

Das Protokoll ist so eigentlich auch Ok - vielleicht sollte es noch eine Reset Sequenz bekommen um den internen Zähler auf 0 setzen zu können, falls mal ein Fehler aufgetreten ist.

welche Datenrate verwendet die serielle Schnittstelle? oder wie wird das Teil an den PC gehangen?

heoßt das ich müsste jedes Byte einzeln an den Controller schicken, dann auf die Response warten - und erst dann das nächste Byte senden? -- wäre ja ziemlich ineffizient? - oder kann ich auch die 48byte Nutzdaten in einem Rutsch senden? und dann in einem Rutsch 48byte lesen und so prüfen ob die Daten auch in den richtigen Kanälen gelandet sind?

Naja der größte Aufwand ist wohl am Ende das Interne AtmoWin Konzept auf 16-Kanäle zu erweitern, aber das ist wohl ne notwendige Änderung... bzw. auf open End Kanäle/Zonen zu erweitern - je nach verwendeter Hardware -- derzeit sind das ja glaube ich alles statische/globale Arrays ... nicht besonders der Bringer.

Zitat

das würde z.B. einen directx-client ermöglichen. oder clients für sound, ...
der vorteil von atmowin ist allerdings die möglichkeit der zonendefinition... optimal wäre ein merge von beidem

das kannst du auch mit AtmoWin machen, du kannst über die Programmierschnittstelle auf den laufenden AtmoWin Prozess zugreifen und dort wenn du willst direkt daten in die Outputkanäle schreiben, oder im Livemodus ein Windows Bitmap (64x48) übergeben was den gesamten Prozess durchläuft. Woher du dieses Bitmap bekommst ist dabei ja nicht festgelegt.

Beispiele für die Nutzung der Schnittstelle sind im Source in den Projekten AtmoCtrlLib (vlc-com-brücke), AtmoCtrl Commandline Tool um AtmoWin zu steuern z.B. aus Batchdateien heraus...,
oder AtmoWinSampleComClient das zeigt wie man den LiveView Modus mit externen Pixeldaten füttern kann.

*g* Von wegen zu Boblight wechseln wollen, dass können wir ja garnicht leiden *g*

Zitat

ich werde wohl auch ohne vdr, nur mit macos oder win32 notebook aufschlagen
www.vdr-camp.de
ist in kandel, das ist ein wenig nördlich von karlsruhe.

ist ganzschön weit weit weg von mir (440km) - es sei denn es kommt noch jemand aus meiner Gegend in diese Richtung zwecks Kostenreduktion *g*

....EDIT....
slime lad dir von meiner Seite nochmal die 0.45er Version runter, da gibts jetzt noch eine GDI Capture Framerate zum Reduzieren der CPU Auslastung... viel Spaß beim Spielen.
(natürlich ist der Link nur Online wenn ich auch da bin..*g*)
...END OF EDIT...

Igor

Zitat

Original von Igor
klingt eigentlich recht einfach dafür eine passende AtmoWin Adapterklasse zu schreiben. Am Ende kann deine Hardware also 16 Kanäle / Zonen bedienen? - also 48 PWM Kanäle... in einem Chip?

Das Protokoll ist so eigentlich auch Ok - vielleicht sollte es noch eine Reset Sequenz bekommen um den internen Zähler auf 0 setzen zu können, falls mal ein Fehler aufgetreten ist.

welche Datenrate verwendet die serielle Schnittstelle? oder wie wird das Teil an den PC gehangen?

heoßt das ich müsste jedes Byte einzeln an den Controller schicken, dann auf die Response warten - und erst dann das nächste Byte senden? -- wäre ja ziemlich ineffizient? - oder kann ich auch die 48byte Nutzdaten in einem Rutsch senden? und dann in einem Rutsch 48byte lesen und so prüfen ob die Daten auch in den richtigen Kanälen gelandet sind?

Alles anzeigen

das ist ein CPLD (also ein kleiner FPGA), deswegen sind das auch echte karate-pwm-kanäle die laufen mit 50kHz.
ich denke, was vllt. sinnvol wäre zu ändern, ist das immer nur nach dem 48ten byte ein ack kommt. das sollte zum syncro auch reichen.
ein reset wird schwierig, dann würde das ganze ja ein echtes protokoll vorraussetzen... das geht im CPLD nicht so einfach (bzw. dafür fehlen dem chip die resourcen). der ist auch nicht wirklich nötig: falls irgendwas nicht stimmt, solange einzelne bytes senden, bis wieder ein ack kommt, dann weisst du wieder genau, wo die hardware steht.

Zitat

Beispiele für die Nutzung der Schnittstelle sind im Source in den Projekten AtmoCtrlLib (vlc-com-brücke), AtmoCtrl Commandline Tool um AtmoWin zu steuern z.B. aus Batchdateien heraus...,
oder AtmoWinSampleComClient das zeigt wie man den LiveView Modus mit externen Pixeldaten füttern kann.

*g* Von wegen zu Boblight wechseln wollen, dass können wir ja garnicht leiden *g*

mmh.. der entscheidende trick an boblightd ist die tatsache, das der multiplattform kann. gibt es eine entsprechung zu COM auf anderen plattformen?
ich bin leider selbst was C/C++ angeht ziemlich unbegabt; hacken und copy&paste coden ist das höchste der gefühle für mich.
trotzdem werde ich mich mal an einem passenden client für directX ausprobieren. ist halt nur schade, das man das ganze know-how nur schwer wieder nach linux/macos zurückholen kann.

edit: die neue version ist im test; richtig kann ich mir das aber erst am wochenende ansehen... dann werd ich mal atmowin im zusammenspiel mit WoW testen.