AtmoLight Firmware Frage

Moin,

die Firmware stammt von samc.

Zitat

Für die Einstellung diese Werte d.h. schreiben ins EEprom - würde ich nen ähnlichen Ansatz vorschlagen, wie für das Schreiben der Werte für den Weissabgleich.

Der Weißabgleich findet im Plugin und nicht im Controller statt.

Gruß Samael

Hi,

Carsten Presser hat eine überarbeitete Atmolight Platine gemacht und auch die Firmware etwas ergänzt. Diese kann auch den Weissabgleich im Controller speichern.

Frag mal, vielleicht kann er die dabei helfen.

Hier seine Homepage : Page

Grüße Magicdragon67

Zitat

Original von Igor
mmh - es gibt aber auch ne Firmware, welche den Weißabgleich direkt selber kann -- oder war das ein Hack von einem dritten?
(so dass der Abgleich nicht in der Software gemacht werden muss.)

korrekt, die original-firmware beherrscht das nicht.
auch die firmware, die ich auf 'meine' controller aufspiele beherrscht das nicht (weil es die originale ist).
diese ominöse 'dritte' firmware beherrscht diesen modus, allerdings kann ich diese nirgends mehr finden. ich habe noch im hinterkopf das diese auch in ansi-C geschrieben ist.

ich bin aber dabei, eine eigene, neue firmware zu erstellen, die diese features auch bekommen kann. wann und ob die fertig wird steht allerdings noch in den sternen.
der plan ist, das protokoll an das 'mondo-light'-protokoll anzupassen.

Hi,

ich habe für meinen eigenen Atmo-Controller die Firmware in C u. Assembler neu geschrieben. Die erledigt den Weißabgleich. Die Werte müssen im EEPROM vorliegen und werden nicht per Protokoll übertragen. Das müßte noch jemand nachrüsten. Wenn in der Konfiguration vom AVRStudio -DOLD_VERSION eingefügt wird, sollte eine Firmware für die originale Version vom Atmo-Controller erzeugt werden. Ich habe das aber nie getestet. Ich habe meinen Atmo-Controller auch nicht mehr in Betrieb, da ich vor ca. einem Jahr auf Aurora umgestiegen bin. Bei Aurora wird der Weißabgleich im Controller gemacht. Die Werte werden per serieller Schnittstelle übertragen. Das Protokoll ist aber komplett anders als bei Atmo oder Mondo-Light.

Gruß
e9hack

Zitat

Original von Igor
schonmal ein Anfang - jetzt müsste ich mich nur noch durch den Code hangeln

Erstmal sollte das auf dem originalen Atmo-Controller laufen.

Zitat

- das ändern der Weissabgleichsparameter im EEprom neu schreiben? - das fehlt dem Code scheinbar - richtig?

Es werden zwar die Parameter aus dem EEprom gelesen - aber man kann diese nicht via Schnittstelle ändern?

Die Parameter werden beim Starten aus dem EEPROM ins RAM geladen. Man kann jeden Kanal einzeln abgleichen.

Die Auswertung der empfangenen Daten erfolgt in einer Pseudo-State-Maschine. Wenn 0xff 0x00 0x00 0x0f gesehen wurde, werden die folgenden 15 Byte als RGB-Werte der einzelnen Kanäle interpretiert.

Man müßte bei einer anderen Byte-Folge auf das Aktualisieren der Weißabgleichswerte umschalten.

Zitat

Schritt zwei wäre dann das gleiche noch für die Startwerte der Farben zu realisieren?

Man könnte den Timer-Puffer mit den gewünschten Werten statisch vorinitialisieren. Dann wäre kein zusätzlicher Kode für das setzen der Initwerte erforderlich.

Gruß
e9hack

Hi,

Zitat

Man könnte den Timer-Puffer mit den gewünschten Werten statisch vorinitialisieren. Dann wäre kein zusätzlicher Kode für das setzen der Initwerte erforderlich.

Das könnte man ja in der bestehenden Firmware einfach in den soucen ändern?? Pder übersehe ich da wa ??

Grüße

OK!!

Ist so besser, jeder hat andere Wünsche.

Zitat

Original von magicdragon67
Das könnte man ja in der bestehenden Firmware einfach in den soucen ändern?? Pder übersehe ich da wa ??

Ich habe da nur von meiner Firmware gesprochen.

Das Nachrüsten von einem ladbaren Weißabgleich bzw. Initialwerten halte ich für trivial. Wenn meine Firmware auf dem originalem Atmo-Controller läuft, kramme ich meinen Controller noch mal raus und implementiere das.

Der Protokollvorschlag aus dem Eröffnungspost ist übrigens komplett falsch. Das vierte Byte gibt immer die Anzahl der Datenbytes im Datenpaket an. Weißabgleich bzw. Power-On-Initwerte müßen über weitere Index-Werte definiert werden. Momentan ist der Bereich von 0 bis 14 für die fünf RGB-Kanäle reserviert.

Der Aufbau vom Header war mir bei der Implementierung nicht wirklich klar. Heute würde ich die Auswertung der Daten nicht mehr On-the-fly währen des Empfangs machen. Bei der Aurora-Firmware werden die Daten für 6 RGB-Kanäle ausgewertet und aufbereitet. Das dauert max. 4ms. Man kann das daher nach dem Empfang eines kompletten Datenpaketes machen.

Gruß
e9hack

aloah,

hier mal noch eine alternativ-implementierung der atmo-firmware in plain C.
http://ca.rstenpresser.de/websvn/listing.php?repname=atmo

da würde sich das gewünschte feature auch leicht einbauen lassen.
werde ich bei gelegenheit auch mal machen

und implementiert (siehe svn-repository)

Leider muss jedes byte einzeln geschrieben werden (der UART ist schneller als das eeprom-schreiben).

Um z.B. am unteren Kanal die Start-farbe auf rot zu setzen, müssen folgende Kommandos abgesetzt werden:

0xFF 0x00 0x00 0x66 0x09 0xFF
0xFF 0x00 0x00 0x66 0xA0 0x00
0xFF 0x00 0x00 0x66 0xB0 0x00
^------------^ ^--^ ^--^ ^--^
 |              |    |    | 
 |              |    |    Farbwert
 |              |    Adresse (entspricht der Kanaladresse, also 0..0x0E)    
 |              Kommando-Code zum EEprom-schreiben der farb-start-werte
 Default Header