AURORA - Das Atmolight der nächsten Generation...

Hallo randy,

Zitat

also wenn ich das datenblatt richtig verstanden habe, kann man das als DC/konstant
strom betreiben mit 64 helligkeitsstufen, die auf im eeprom abgespeichert werden
koennen ("weiss abgleich"), und dann ueber die GS registert mit 4096 helligkeitsstufen
den strom regeln; aber man kann das ganze ueber PWM auch pulsen lassen - GSCLK.
das geht bis 30MHz hoch. dann sollte der verlustsstrom kein problem sein?

Hmm, müßte ich glatt mal ausprobieren. Hab hier 5 TLCs liegen.
Wie daß mit der Verlustleistung ausschaut, da bin ich im Moment überfragt.
Problematisch ist nur die Geschichte mit dem EEPROM, denn da braucht man 22V Programierspannung.

Zitat

aber da wir den chip wahrscheinlich eh nicht bekommen

Doch, bekommt man z.B. hier

Gruß,
Daniel

Zitat

Original von daniel_k

Doch, bekommt man z.B. hier

ich meinte zu vernueftigen preisen in deutschland bekommen

die kosten auf 2500er rolle um die 4 dollar/stueck. wenn ein atmega8 + mosfet gespann
gleich teuer kommt, wuerde ich letzteres nehmen wollen (nachbausicherheit).

-- randy

Nur mal am Rande eine Idee, damit der Controller Programming leichter geht, wäre es da nicht von Anfang an sinnvoll einen Controller zu nehmen, der mit einem Bootloader arbeiten kann.
So könnten die Firmeware ohne großen aufwand z.b. "automatisch" neu eingespielt werden ohne erst einen ISP-Programmer anzuschliessen.

meiner einer wäre für die ATMega8 Variante, da diese einfach zukunftssicherer ist mann kann so glaube ich mehr verändern, es flexibler einsetzen, falls noch mehr LED´s gebraucht werden usw .. oder es anders verschaltet blablabla ... daher denke ich .. wäre das Idealer ...

Und einen Rückkanal würde ich schon einbauen .. so nach dem Motto .. "Befehle sauber verstanden" .... bzw .. meinem wunsch einen Beitrag oben zu entsprechen "Firmware" sauber übertragen

Würde als Treiber für die LED´s nich auch der ULN 2003/2804 reichen ? soviele LED´s sind ja nicht dran ?

Was haltet ihr von folgendem Aufbau ( als Anhang ) ...
damit wäre mann oder frau extrem Flexibel ...
der erste Controller bekommt alle Daten und muss diese dann aufbereiten so das die Nachfolgenden Module die passenden Infos bekommen ...

die Modul ID kann hier ja "automatisch" vergeben werden, da die Daten von der ersten RS232 bis zur letzten durchgereicht werden .. somit sind "Broadcast" messages für jeden usw möglich ....

Im "VDR" Menü müsste nur eingestellt werden, welche ID was ist ( Oben / Unten / Links / Rechts ... bzw wenn mehere module genutzt werden oben 1 / 2 .. usw ... bei grösseren Plasmas z.b. nem kleinen 65 Zoller z.b. wäre das praktisch .... ) .....

Somit können auch Module mit unterschiedlichen LED Mengen realisiert werden .... usw

Unter den Controllern muss halt noch nen passendes Protokoll her .. z.b.
<protokolltyp> <daten ..... je nach protokolltyp>
somit wäre man hier auch sehr flexibel

Zitat

Original von MyLive
Was haltet ihr von folgendem Aufbau ( als Anhang ) ...
damit wäre mann oder frau extrem Flexibel ...
der erste Controller bekommt alle Daten und muss diese dann aufbereiten so das die Nachfolgenden Module die passenden Infos bekommen ...

Die Controller sollten nicht in Reihe hängen. Es dauert zu lange bis der letzte seine Daten hat. Die Controller sollten parallel geschaltet werden, RXD direkt und TxD über Wired-AND auf der TTL-Seite (vor dem Treiber). Es darf dann nur einer senden...

Zitat

die Modul ID kann hier ja "automatisch" vergeben werden, da die Daten von der ersten RS232 bis zur letzten durchgereicht werden .. somit sind "Broadcast" messages für jeden usw möglich ....

Die Modul ID sollte von Jumpern oder einem festen Wert aus dem Bool-Loader-ROM kommen.

Zitat

Unter den Controllern muss halt noch nen passendes Protokoll her .. z.b.
<protokolltyp> <daten ..... je nach protokolltyp>
somit wäre man hier auch sehr flexibel

Im Prinzip muß das Protokoll aus Broadcast-Messages an alle und Unicast-Messages an einzeln adressierte Slaves (Module) bestehen. Broadcast werden nicht beantwortet. Unicast werden vom adressierten Slave beantwortet. Das Protokoll könnte so aussehen:

<Header><CMD><ID/Sequenz><Lenght><Data0>...<DataN><CRC>

<Header> ist ein festes Byte (z.B. 0xAA), welches sonst nicht in der Message vorkommen darf. Die Slaves können sich dadurch relativ einfach auf eine Message synchronisieren. Das Header-Byte muß in der Message durch eine Escape-Sequenz ersetzt werden. Die beginnt mit einem zweiten festen Byte (z.B. 0x55). Es muß dann mindestens zwei Escape-Sequenzen geben:

<0x55><0x00> -> <0x55>
<0x55><0x01> -> <0xAA>

Die Escape-Sequenzen werden beim Empfang 'on the fly' dekodiert. Man kann auch weitere nützliche Sequenzen definieren:

<0x55><0x02> -> <0x55><0xAA>
<0x55><0x03> -> <0xAA><0x55>
<0x55><0x13> -> Das letzte dekodierte Byte wird 3x wiederholt.
...
<0x55><0x1F> -> Das letzte dekodierte Byte wird 15x wiederholt.

<CMD> ist der eigentliche Befehl. Wenn Bit 7 (0b1xxxxxxx) gesetzt ist, ist es ein Broadcast sonst ein Unicast. <ID/Sequenz> ist die Adresse des Slaves bei einem Unicast oder eine fortlaufende Sequenz-Nummer bei einem Broadcast. Der Master (Vdr) kann über die Sequenz-Nr. einen Slave per Unicast fragen, ob der letzte Broadcast korrekt verarbeitet wurde. <Length> ist die Anzahl der folgenden Datenbytes. Damit können 0 bis 255 (oder 1 bis 256 mit 0 = 256) Byte an Nutzdaten übertragen werden. Wenn der Controller nicht genügend Speicher zum puffern hat, muß die max. zulässige Länge gegebenenfalls reduziert werden. <CRC> ist eine Checksumme über die gesamte Message.

Nach der Message folgt eine Zwangspause (z.B. 5..10ms), in der die Slaves die Message verarbeiten können. Bei einem Unicast muß der adressierte Slave danach antworten.

Das gleiche Protokoll kann auch für den Bootloader genutzen. Da kann man dann alle Slaves parallel umprogrammieren. Die Daten werden per Broadcast an alle verteilt. Das Programmieren wird gleichfalls per Broadcast gestartet. Vorher wird noch per Unicast festgelegt, ob ein spzieller Slave auf den Programmierbefehl reagieren soll. Die einzelnen Slaves werden per Unicast gefragt, ob das Programmieren (einer Page) erfolgreich war.

Gruß
e9hack

Zitat

Original von e9hack

Die Controller sollten nicht in Reihe hängen. Es dauert zu lange bis der letzte seine Daten hat. Die Controller sollten parallel geschaltet werden, RXD direkt und TxD über Wired-AND auf der TTL-Seite (vor dem Treiber). Es darf dann nur einer senden...

Die Modul ID sollte von Jumpern oder einem festen Wert aus dem Bool-Loader-ROM kommen.

Alles anzeigen

Hm .. finde ich nicht gut ....
Jumper belegen zuviele Port´s und fester Wert im Boot-Rom macht die Boot-Loader Firmware umständlicher .....

Evtl eine Initialisierungssequenz, in welcher Modul für Modul angesteckt wird und dann die ID an ein neues Modul vergeben wird ....

Zitat

Original von e9hack

Im Prinzip muß das Protokoll aus Broadcast-Messages an alle und Unicast-Messages an einzeln adressierte Slaves (Module) bestehen. Broadcast werden nicht beantwortet. Unicast werden vom adressierten Slave beantwortet. Das Protokoll könnte so aussehen:

<Header><CMD><ID/Sequenz><Lenght><Data0>...<DataN><CRC>

<Header> ist ein festes Byte (z.B. 0xAA), welches sonst nicht in der Message vorkommen darf. Die Slaves können sich dadurch relativ einfach auf eine Message synchronisieren. Das Header-Byte muß in der Message durch eine Escape-Sequenz ersetzt werden. Die beginnt mit einem zweiten festen Byte (z.B. 0x55). Es muß dann mindestens zwei Escape-Sequenzen geben:

<0x55><0x00> -> <0x55>
<0x55><0x01> -> <0xAA>

Die Escape-Sequenzen werden beim Empfang 'on the fly' dekodiert. Man kann auch weitere nützliche Sequenzen definieren:

<0x55><0x02> -> <0x55><0xAA>
<0x55><0x03> -> <0xAA><0x55>
<0x55><0x13> -> Das letzte dekodierte Byte wird 3x wiederholt.
...
<0x55><0x1F> -> Das letzte dekodierte Byte wird 15x wiederholt.

<CMD> ist der eigentliche Befehl. Wenn Bit 7 (0b1xxxxxxx) gesetzt ist, ist es ein Broadcast sonst ein Unicast. <ID/Sequenz> ist die Adresse des Slaves bei einem Unicast oder eine fortlaufende Sequenz-Nummer bei einem Broadcast. Der Master (Vdr) kann über die Sequenz-Nr. einen Slave per Unicast fragen, ob der letzte Broadcast korrekt verarbeitet wurde. <Length> ist die Anzahl der folgenden Datenbytes. Damit können 0 bis 255 (oder 1 bis 256 mit 0 = 256) Byte an Nutzdaten übertragen werden. Wenn der Controller nicht genügend Speicher zum puffern hat, muß die max. zulässige Länge gegebenenfalls reduziert werden. <CRC> ist eine Checksumme über die gesamte Message.

Nach der Message folgt eine Zwangspause (z.B. 5..10ms), in der die Slaves die Message verarbeiten können. Bei einem Unicast muß der adressierte Slave danach antworten.

Das gleiche Protokoll kann auch für den Bootloader genutzen. Da kann man dann alle Slaves parallel umprogrammieren. Die Daten werden per Broadcast an alle verteilt. Das Programmieren wird gleichfalls per Broadcast gestartet. Vorher wird noch per Unicast festgelegt, ob ein spzieller Slave auf den Programmierbefehl reagieren soll. Die einzelnen Slaves werden per Unicast gefragt, ob das Programmieren (einer Page) erfolgreich war.

Gruß
e9hack

Alles anzeigen

Hallo MyLive,

ich hatte weiter oben im Thread schon einen konkreten Hardwarevorschlag gemacht der ähnlich deinen Überlegungen ist. Mein Vorschlag setzt nur parallel geschaltete AVR's ein (hier ATmega162 da meine Firmware mehr als 512Byte RAM benötigt). Auf einen Rückkanal habe ich verzichtet und stattdessen eine Handshakeleitung (CTS) eingeplant um den Datenfluss vom PC bremsen zu können. Als Rückmeldung käme ja nur Kommando erfolgreich/fehlgeschlagen in frage und bei einem Fehlschlag wäre dann ja zu überlegen was die PC-Software dann machen soll. Da fällt mir nur "Fehlermeldung ausgeben" ein da die "Störung" sehr wahrscheinlich einen manuellen Eingriff erfordert.
Ein visuelles Feedback könnte man aber auch über die RGB-Leds signalisieren.

Die (bereits existierende!) Firmware für meinen Vorschlag setzt ein Protokoll mit Broadcast-Telegrammen ein. Es gibt ein (DMX ähnliches) Kommando zu Übertragung der Helligkeitswerte dass mit dem Escape 0xFF beginnt und per Timeout überwacht wird. Alle weiteren Kommandos bestehen nur aus ASCII-Zeichen < 0x80 und werden mit <CR> und/oder <LF> abgeschlosssen ohne Timeoutüberwachung. Damit lassen sich alle Kommandos auch von "Hand" in einem Terminalprogramm einfach ausprobieren.

Die Idee mit einem Bootloader finde ich gut. Den könnte man in meiner Firmware durchaus noch nachrüsten.

Gruss
durchflieger

Zitat

Original von durchflieger
Hallo MyLive,

ich hatte weiter oben im Thread schon einen konkreten Hardwarevorschlag gemacht der ähnlich deinen Überlegungen ist. Mein Vorschlag setzt nur parallel geschaltete AVR's ein (hier ATmega162 da meine Firmware mehr als 512Byte RAM benötigt). Auf einen Rückkanal habe ich verzichtet und stattdessen eine Handshakeleitung (CTS) eingeplant um den Datenfluss vom PC bremsen zu können. Als Rückmeldung käme ja nur Kommando erfolgreich/fehlgeschlagen in frage und bei einem Fehlschlag wäre dann ja zu überlegen was die PC-Software dann machen soll. Da fällt mir nur "Fehlermeldung ausgeben" ein da die "Störung" sehr wahrscheinlich einen manuellen Eingriff erfordert.
Ein visuelles Feedback könnte man aber auch über die RGB-Leds signalisieren.

Die (bereits existierende!) Firmware für meinen Vorschlag setzt ein Protokoll mit Broadcast-Telegrammen ein. Es gibt ein (DMX ähnliches) Kommando zu Übertragung der Helligkeitswerte dass mit dem Escape 0xFF beginnt und per Timeout überwacht wird. Alle weiteren Kommandos bestehen nur aus ASCII-Zeichen < 0x80 und werden mit <CR> und/oder <LF> abgeschlosssen ohne Timeoutüberwachung. Damit lassen sich alle Kommandos auch von "Hand" in einem Terminalprogramm einfach ausprobieren.

Die Idee mit einem Bootloader finde ich gut. Den könnte man in meiner Firmware durchaus noch nachrüsten.

Gruss
durchflieger

Alles anzeigen

Hallo Durchflieger

Was bei einem Fehler z.b. gemacht werden kann ist es nocheinmal senden, falls "irgendwelche" Störungen gerade kurzzeitig das Signal versaut haben .. ansonsten eine Rückmeldung, entweder an den User oder direkt an das Projekt um zu sehen, wo Fehler entstehen, ob es "massen" Fehler oder vereinzelte Probleme sind ...

Hast du deine Firmware in C geschrieben ? oder in ASM ?
evtl ist es ja möglich durch eine "Überarbeitung" mit 512 Byte Ram auszukommen, keine Ahnung ....

beste grüße

MyLive

Zitat

Original von MyLive
Was bei einem Fehler z.b. gemacht werden kann ist es nocheinmal senden, falls "irgendwelche" Störungen gerade kurzzeitig das Signal versaut haben .. ansonsten eine Rückmeldung, entweder an den User oder direkt an das Projekt um zu sehen, wo Fehler entstehen, ob es "massen" Fehler oder vereinzelte Probleme sind ...

Hast du deine Firmware in C geschrieben ? oder in ASM ?
evtl ist es ja möglich durch eine "Überarbeitung" mit 512 Byte Ram auszukommen, keine Ahnung ....
MyLive

Das wichtigste Kommando "Helligkeitswerte" wird vom VDR sowieso schon alle 20ms gesendet und somit wird ein "versautes" Telegramm sehr schnell wiederholt. Alle anderen Kommandos werden ja nur selten während des "Setup" benötigt. Da kann der Anwender durchaus selber mal das Kommando wiederholen. Als Feedback für fehlgeschlagene Kommandos könnte man hier ja die RGB-Leds blinken lassen. Gegen "versaute" Telegramme sieht der Hardwarevorschlag überigens RS422 Treiber für die TXD-Leitung vor damit wir bei der hohen Baudrate (115Kbit) auf der sicheren Seite sind.

Die Firmware ist kpl. in C (WinAVR) implementiert und verfügt über alle wichtigen Funktionen wie Weissabgleich und Gammakorrektur im Controller mit interner Auflösung (1051 Steps). Das RAM-Bedarf wird aufgrund der verwendeten Algorithmen (insbesondere die effiziente PWM-Generierung) benötigt und ist nicht durch die Codierung in "C" bedingt. Ich denke die Mehrkosten von ca. €1,80 für den Atmega162 sind tragbar.

Gruss durchflieger

Zitat

Original von durchflieger

Das wichtigste Kommando "Helligkeitswerte" wird vom VDR sowieso schon alle 20ms gesendet und somit wird ein "versautes" Telegramm sehr schnell wiederholt. Alle anderen Kommandos werden ja nur selten während des "Setup" benötigt. Da kann der Anwender durchaus selber mal das Kommando wiederholen. Als Feedback für fehlgeschlagene Kommandos könnte man hier ja die RGB-Leds blinken lassen. Gegen "versaute" Telegramme sieht der Hardwarevorschlag überigens RS422 Treiber für die TXD-Leitung vor damit wir bei der hohen Baudrate (115Kbit) auf der sicheren Seite sind.

Die Firmware ist kpl. in C (WinAVR) implementiert und verfügt über alle wichtigen Funktionen wie Weissabgleich und Gammakorrektur im Controller mit interner Auflösung (1051 Steps). Das RAM-Bedarf wird aufgrund der verwendeten Algorithmen (insbesondere die effiziente PWM-Generierung) benötigt und ist nicht durch die Codierung in "C" bedingt. Ich denke die Mehrkosten von ca. €1,80 für den Atmega162 sind tragbar.

Gruss durchflieger

Alles anzeigen

Hm ... das mit dem 422 Bus macht sinn ...
Eine andere Frage, macht eine Auflösung von 1051 Steps sinn ?
Würden nicht weniger auch reichen ? pro PWM z.b. 256 ?

nur mal am Rande, evtl lässt sich damit der RAM bedarf reudzieren

Zitat

Original von MyLive
Hm ... das mit dem 422 Bus macht sinn ...
Eine andere Frage, macht eine Auflösung von 1051 Steps sinn ?
Würden nicht weniger auch reichen ? pro PWM z.b. 256 ?

nur mal am Rande, evtl lässt sich damit der RAM bedarf reudzieren

Ich denke die hohe Auflösung macht schon Sinn da ansonsten nach Weissabgleich und Gammakorrektur doch sehr viel weniger unterschiedliche Helligkeitswerte übrig blieben. Z.B. ist es bei meinen LED-Stripes so, das für ein reines Weiss ich die blauen Leds auf einen Wert um 130 reduzieren musste. Nach Gammakorrektur blieben dann weniger wie 100 Helligkeitswerte übrig. Ich habe allerdings keine realen Tests mit unterschiedlichen Auflösungen durchgeführt sondern mich auf die Erfahrungswerte aus dem Atmolight-Thread gestützt.
Weiterhin würde eine Reduzierung der Auflösung zu keinen Einsparung beim RAM führen da die Tabellen für Weissabgleich und Gammakorrektur in der Firmware sowieso schon im Flash abgelegt werden. Ansonsten hätten schon die 1KB nicht gereicht.

Zitat

Original von durchflieger
Das RAM-Bedarf wird aufgrund der verwendeten Algorithmen (insbesondere die effiziente PWM-Generierung) benötigt und ist nicht durch die Codierung in "C" bedingt.

Du kannst ca. 440 Byte einsparen, wenn Du die Gammakorrekturwerte über Stützstellen (z.B. 32) 'on the fly' berechnest. Dann benötigst Du die 512 Byte für die Look-Up Tabelle nicht mehr.

Du solltest auch mit drei Puffern arbeiten. Wenn die Daten mal schneller als wie mit der zweifachen PWM-Zykluszeit kommen (<20ms) , wird möglicherweise der Puffer überschrieben, der gerade im Interrupt ausgegeben wird.

Gruß
e9hack

Zitat

Original von e9hack
Du kannst ca. 440 Byte einsparen, wenn Du die Gammakorrekturwerte über Stützstellen (z.B. 32) 'on the fly' berechnest. Dann benötigst Du die 512 Byte für die Look-Up Tabelle nicht mehr.

Du solltest auch mit drei Puffern arbeiten. Wenn die Daten mal schneller als wie mit der zweifachen PWM-Zykluszeit kommen (<20ms) , wird möglicherweise der Puffer überschrieben, der gerade im Interrupt ausgegeben wird.

Gruß
e9hack

wie bereits gesagt liegen die Gammatabellen in meiner aktuellen Firmware im Flash und davon haben wir genug im AVR. Die Firmware arbeitet bereits mit drei Puffern so das die Daten durchaus schneller eintreffen dürfen

Gruß
durchflieger

Wer macht das Plugin für den VCR ? gibt es denn da schon jemand ? oder wird nur erstmal die "Hardware" inkl der Firmware entwickelt ?

Wird das Projekt noch weiterverfolgt?

MfG Hugo

randy hat zumindestens n beta layout fertig, ich gehe daher mal stark davon aus.

im moment habe ich 3 layouts fuer led leisten fertig, einmal mit dem tlc und 15 leds,
einmal mega8 mit 6 leds und einmal mega16 mit 15; moechte noch einen mit mega8
mit 12 leds (jeweils 2 parallel) anfertigen - die sind schmaeler (etwa 2cm).

das ganze via serieller ansteuerung/durchleitung.

-- randy

Wie schaut am Ende das Protokoll aus? - wenns da was fertiges an Beschreibung gibt - melde ich hiermit schonmal Interesse an?*g*

Wieviel Kanäle / Zonen - wird deine Version am Ende haben 12? 16? .. "unendlich?"

sofern natürlich Bedarf nach einer passenden AtmoWin Software besteht...

Igor