Beiträge von MyLive

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

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 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 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

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

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

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

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.