Eiwomisa 1 - v1.2 (RGBW Controller) Bausatz - aktuell mit 25% Rabatt!!!

    Hi,


    so, neues Problem. Ich benutze den ersten UART ja für die DMX Kommunikation. Den 2. UART wollte ich eigentlich für ne RS232 verwenden. Das geht jetzt aber wohl nicht.


    Problem ist das ich eine RC5 Fernbedienung nur mit einem externen Interrupt zum laufen bekomme. Da der "getrc5"-Befehl bis zu 150ms benötigt, kann man diesen in keine Hauptschleife setzen. Selbst in einer Timer ISR wäre es nicht möglich da der dann zwar selterner aufgerufen wird, aber immer noch zu oft.
    Sinnvoll ist es nur wenn man den "getrc5" nur dann aufruft wenn dieser auch benötigt wird. Das wiederum ist nur mit einem externen Interrupt möglich.


    Da die 2 externen Interrupts aber auf den selben Pins liegen wie die 2. UART, kann ich da keinen Max232 mehr anklemmen. Die Frage die sich mir nun stellt ist, RS232 oder DMX? Ich bin für DMX da ich ohnehin noch nicht gewusst hätte was ich mit der RS232 anfangen sollte. Ich kann es aber so lösen das man am 1. UART beides anklemmt und über Jumper auswählen kann was man benutzen will.


    Falls jemand Tipps für einen funktionierenden RC5 Empfang per Interrupt hat, möge dieser es doch bitte hier rein schreiben.


    Gruß, Benny.

    Also RC5 habe ich in C sehr gut gelöst. Das war auch der Grund, warum ich von Bascom auf C umgestiegen bin. Ich weiß nicht, ob ich weiter oben schon mal was dazu geschrieben hatte. Ich verwende eine Abwandlung dieses Codes:


    http://www.roboternetz.de/wiss…oder_f%C3%BCr_ATMega#Code


    bzw. dieses hier dürfte das Original sein:


    http://www.gjlay.de/pub/c-code/rc5.html


    Die bekannten Verzögerungen aus Bascom gibt es da überhaupt nicht.


    VG
    Nino

    Hi,


    ich kann vorerst nur mit Bascom was anfangen. Wobei ich natürlich offen wäre für eine ASM Einbindung falls sowas vorhanden ist.


    Mit Bascom habe ich nun eine Lösung gefunden, muss das nur noch umsetzen. Trotzdem fällt natürlich eine UART weg weil der INT0 bzw. INT1 auf der 2. UART liegt. Aber ich werde es wie schon beschrieben mit Jumper lösen damit beides benutzbar bleibt.


    Gruß, Benny.

    Hallo Benny,


    du kannst natürlich auch einen der vielen Pin-Change-Interrupts anstatt INT0 oder INT1 nutzen. Pin-Change reagiert einfach auf beide Flanken und man muss dann eben in der ISR durch Pin-Abfrage feststellen, welche Flanke (steigende oder fallende) den Interrupt ausgelöst hat. Der Vorteil ist aber, dass man praktisch jeden beliebigen Pin verwenden kann (praktisch jeder Pin der neueren AVRs bietet einen PCINT-Interrupt).


    Gruss
    Neni

    Hi,


    das wäre eine Alternative. Bei dem Code den ich gefunden habe macht dieser was spezielles mit dem INT1 Register:


    Code
    '---------------------------------------------------------------------------
 '     RC5 Interrupt
 '     Hier wird nur ein Flag gesetzt.
 '     Der FB-Code kann hier nicht geholt werden, da der Interrupt auch
 '     den Bascom Highlevelbefehl stoppt, denn dieser benutzt Timer0 und dessen Interrupt
 '---------------------------------------------------------------------------
 Isr1:
 Fbin = 1
   Set Gifr.intf1
 Return


    Es geht speziell um das "Set Gifr.intf1", wie lautet das bei den PCint und funktioniert es überhaupt damit?


    Gruß, Benny.

    Beim Studium des Datasheets ist mir aufgefallen, dass es sogar noch einfacher geht. Der ATmega164p/324p/644p hat sogar einen dritten Ext-Int "INT2" am Pin PB2, welcher dieselbe Funktionalität wie INT0 unt INT1 bietet. Damit musst du dann nur die zu deinem Code analogen Einstellungen einfach für INT2 vornehmen und brauchst ansonsten nichts zu ändern. Übrigens ist das Flag-Register bei den hier verwendeten AVRs nicht GIFR sondern EIFR. Also in dem Fall würde es im ISR-Code lauten: "SET EIFR.INTF2", allerdings musst du auch die Register EICRA und EIMSK analog zu deinem verwendeten Code entsprechend für INT2 initialisieren.


    Gruss
    Neni

    Hi,


    oh Mann, wie konnte ich das nur übersehen. Ich hab den INT2 schon gesucht, aber diese doofe Schreibweise, das die INTs immer als letztes dran stehen und bei dem INT2 nicht, ließ es mich nicht finden.


    Dann habe ich dummerweise noch im Code "$baud1 19200" stehen gehabt, das hat mir den INT1 blockiert deswegen ging es nicht. Kurz, jetzt funktioniert es mal soweit das der µC noch sauber fadet und trotzdem RC5 Codes empfängt.


    Jetzt kann ich das nächste Problem suchen gehen.....aso, dank des INT2 ist die RS232 natürlich gerettet. Auch wenn ich trotzdem noch nicht weiß was ich damit anfangen soll.



    Gruß, Benny.

    Zur Preisfrage DMX oder RS232:
    - Entweder Platz für beides (je nach Geschmack) lassen - also MAX232 und MAX485
    - Oder beides vorsehen an den verschiedenen UARTs


    Ich würde in jedem Fall die UART-Pins gesondert rausführen, damit man einfach nen anderen µC dranklemmen kann!

    Zitat von Stefan_Z

    Zur Preisfrage DMX oder RS232:
    - Entweder Platz für beides (je nach Geschmack) lassen - also MAX232 und MAX485
    - Oder beides vorsehen an den verschiedenen UARTs


    Ich würde in jedem Fall die UART-Pins gesondert rausführen, damit man einfach nen anderen µC dranklemmen kann!

    Da ja jetzt mein Wissen bezüglich des INT2 aufgebessert wurde kommen wieder beide Schnittstellen drauf. Einmal mit RS232 und DMX. Aber die Idee mit dem bereitstellen der nativen UART-Pins ist gut und wird umgesetzt.


    Was das DMX angeht, hier möchte ich den Max488 verwenden. Dieser hat den Vorteil das DMX-Senden und DMX-Empfangen voneinander getrennt sind und ich das somit nicht mehr über den µC steuern muss. Je nach dem ob man mit dem BAusatz dann senden oder empfangen will muss man dann halt die Leitungen in die richtigen Klemmen stecken. Ich sehe das als Vorteil, falls es einer als Nachteil sieht, dann bitte erläutern. Daqnn kann man ja das Für und Wider gegeneinader aufstellen.


    Gruß, Benny.

    Nope, DMX wird eben genau mit 250 kbps über RS485 übertragen, nicht mehr und nicht weniger. Allerdings wird ein Chip mit max. Datenrate von 250 kbps mit DMX natürlich gerade am Limit gefahren. Ob sich das immer gut (ohne Fehlübertragungen) ausgeht, hängt dann von weiteren Faktoren ab. Mir wäre hier die Sicherheitsmarge dann eindeutig zu klein. Aber andererseits habe ich den MAX488 nie selbst im Betrieb gehabt, möglicherweise hat er im praktischen Betrieb doch auch noch etwas Luft nach oben.


    Gruss
    Neni

    Hallo,


    danke für die Hinweise. Das eine könnte ich ja mit dem Max490 ausgleichen, mit dem dürften wir dann auf jeden Fall auf der sicheren Seite sein.


    Das andere ist nun die Frage ob jetzt Max485 oder Max490? Beim 485 ist DMX-Senden und DMX-Empfang auf einer Leitung nach aussen geführt, beim 490 ist es getrennt.
    Welche Vor- bzw. Nachteile gibt es?


    Max490:
    Vorteil:
    - man könnte eventuell 2 DMX Netze mit einander verbinden.
    - man könnte zum einen den Controller selbst mit DMX-Empfang laufen lassen und gleichzeitig als Master für andere Geräte dienen, eventuell über die RS232-Schnittstelle?
    Nachteile:
    - Eine Klemme mehr.


    Max485:
    Vorteil:
    - nur eine Klemme


    Nachteil:
    - Vorteile des Max490


    Gruß, Benny.

    Hi,


    also ich glaube ich bleibe beim Max490. Ich wollte das eigentlich so haben das man dann später 2 DMX Buchsen hat, DMX-IN und DMX-OUT. Dann könnte man versuchen das Programm so zu proggen das die LED-Zustände immer auch als DMX ausgegeben werden. Egal ob per internem Programm oder über DMX-IN betrieben. Dann könnte man auch so kleine DMX-Empfänger anklemmen die nicht anderes machen wie der Controller auch.


    Aber wie gesagt, wenn jetzt jemand etwas wichtiges einfällt warum nicht dann bitte gleich sagen!


    Gruß, Benny.

    Also DMX-In und DMX-Out muss man ja eh haben. Die zwei Buchsen sind zwar parallel angeklemmt, aber zum Kaskadieren brauchts ja nen Ausgang.
    Lötstellen für DMX-Abschlußwiderstand und Kondensator würde ich auch noch an den Buchsen vorsehen.


    Falls du Pins am µC sparen möchtest, könntest du auch noch das Display per I2C-Portexpander (z.B. PCF8574) anklemmen - dann brauchts nur noch 2 Pins und man hat den Rest des Ports frei.
    Je nachdem wie die PinChangeInterrupts liegen könnte man dann anstelle der 5 Taster ein bis zu 4x4 Tastenfeld ganz einfach integrieren (per Multiplexing und PCINT).
    Ist in Bascom auch beides recht einfach zu implementieren: http://www.mcselec.com/index.p…task=view&id=82&Itemid=57

    Hallo,


    ich habe mich ja nun schon lange nicht mehr gemeldet wegen diesem Thema, aber habe es nicht vergessen. Im Gegenteil, ich arbeite immer mal wieder an dem neuen Controller und bin gestern Nacht einen entscheidenden Schritt weitergekommen.


    Das Grundgerüst für das Menu steht und ich habe das Tastenfeld abgeändert. Es gibt nun keinen Encoder-Drehschalter mehr sondern momentan nur noch 5 Taster in Form von Oben, Links, Unten, Recht und Mitte. Wobei ich Mitte bisher noch keine Funktion zugewiesen habe, irgendwie reichen mir eigentlich die 4 Richtungstaster bisher für alles. Wenn ich den mittleren Taster nicht für irgendeine Enter-Funktion benötige, dann kommt der wieder weg.


    Der andere Fortschritt ist das ich es geschafft habe die RC5 Fernbedienung komplett in die Menuführung integriert zu haben. Also die 4 Richtungstasten auf der Fernbedienung haben exakt die gleiche Funktion wie die Taster auf der Platine. Bisher teste ich das alles mit einer ONE FOR ALL Fernbedienung die man für knappe 15,-€ in jedem Mediamarkt bekommt. Somit sollte es für jeden möglich sein sich das Teil selbst bei Bedarf zu besorgen oder dann in Zukunft bei mir mit dem Bausatz mitbestellen.


    Das Fading Programm habe ich nun schon mal in den Code eingefügt und funktioniert soweit. Dann werde ich so nach und nach die anderen Programme hinzufügen und testen. Falls also irgendjemand Ideen für Programme hat, dann soll er es mich wissen lassen.


    Aso, da ich ja eigentlich eine RS232 Schnittstelle mit eingeplant hatte, würde es mich interessieren was ich damit in Verbindung mit meinem Fader anstellen kann. Wäre ja doof wenn die Schnittstelle da ist, aber keine Funktion Programmiert wurde die diese anspricht.
    Vielleicht könnte man es ja irgendwie realisieren mit einem kleinen PC-Programm die LED-Werte per RS232 zu steuern. Eventuell findet sich hier ja ein fähiger Programmierer der so ein kleines Programm für den PC schreiben könnte. Dieser müsste mir halt mitteilen was er über RS232 genau schickt damit ich es auswerten und mit den LEDs ausgeben kann.


    Gruß, Benny.

    Zitat von benkly

    Falls also irgendjemand Ideen für Programme hat, dann soll er es mich wissen lassen.

    Wie wäre es mit einem "Farbempfinden"-bezogenen Fading? also ein Fading, das nur die Warmen Farbtöne durchfadet und eins das nur die Kalten Töne durchfadet. Also beim ersten halt so rot, gelb, orange, etc. und beim zweiten blau, grün, cyan usw

    Zitat von benkly

    Aso, da ich ja eigentlich eine RS232 Schnittstelle mit eingeplant hatte, würde es mich interessieren was ich damit in Verbindung mit meinem Fader anstellen kann. Wäre ja doof wenn die Schnittstelle da ist, aber keine Funktion Programmiert wurde die diese anspricht.

    wie wäre es mit einem Master-Slave-Modus? Dass also der eine Fader seine Daten an den anderen schickt.

    Zitat von benkly

    Vielleicht könnte man es ja irgendwie realisieren mit einem kleinen PC-Programm die LED-Werte per RS232 zu steuern. Eventuell findet sich hier ja ein fähiger Programmierer der so ein kleines Programm für den PC schreiben könnte

    Öhm... Also wenn sich garkein anderer findet könnte ich vielleicht mal schauen, was sich machen lässt, aber da lasse ich gerne anderen erstmal den Vortritt, da ich zur Zeit noch am neuen Cube-Editor schreibe und der, wie Pesi bestätigen kann, noch eine ziemliche Baustelle ist.

    Schön ,dass du mit deinem Controller weiter gekommen bist. Den mittleren Taster bitte unbedingt einplanen, du möchtest doch auch Erweiterungsmöglichkeiten lassen. Je nach Anwendung braucht man den Taster dann auch vielleicht mal. man muss ihn ja standardmäßig nicht bestücken wenn man das Programm nicht selbst abändern will.
    Die RS232 Schnittstelle finde ich sehr wichtig bei dem Controller. Immerhin biete sie die Möglichkeit mehrere der Controller gleichzeitig zu steuern. Deshalb sollten die Controller auch eine (softwaremäßig) einstellbare Adresse bekommen. Steuern müsste man einerseits die Farben direkt, und außerdem die Programme anwählen und die Parameter (Geschwindigkeiten) einstellen. Im Grunde ähnlich wie beim Chromoflex. Auf die Möglichkeit die Programme extern zu ändern kann man wohl verzichten - das könnte man ja direkt im Quellcode machen. Eventuell könntest du die Programme ja auch über eine externe Tabelle einbinden?! Beim LED-Cube von Pesi mit dem Editor von Fightclub ist das ja so gelöst.


    Ein PC-Programm dafür würde ich vielleicht auch machen, wenn es kein anderer macht natürlich - allerdings hab ich den Bereich seit meiner LED Infizierung( ;( ) etwas schleifen lassen :whistling: - da müsste ich mich sicher einige Zeit wieder einarbeiten und hab eher wenig Zeit dazu.

    Hi,


    kurzer Zwischenstand.


    Von der Master-Slave Funktion per RS232 halte ich irgendwie nicht so viel. Das wollte ich eigentlich mit DMX erschlagen.
    Mit der RS232 wollte ich eigentlich wirklich eher mit dem PC auf das Teil zugreifen, nur bräuchte ich halt jemand der dann das PC Programm dafür schreibt.


    Das Fading Programm habe ich um einige Funktionen erweitert. So kann man nun bis zu 6 Farben selber definieren zwischen denen hin und her gefadet wird. Und die Fadinggeschwindigkeit bzw. die Verweilzeit bei einer eingestellten Farbe kann für jede Farbe seperat eingestellt werden.
    Momentan kann man halt nur 6 Farben vorbelegen, falls das zu wenig sein sollte und mehr gewünscht wird, dann bitte Bescheid geben. Dann könnte ich auch mehr Farben hinzufügen.


    Dann habe ich die komplette Fading-Routine neu geschrieben, damit sind keine Wait Befehle mehr vorhanden. Allerdings ist dadurch die kürzeste Fading Zeit auf ca. 1,6 sek. angestiegen, schneller geht also ein Fading von einer Farbe zur anderen nicht. Wobei ich denke das es eher auf lange einstellbare Fadingzeiten ankommt.


    Werd heute Abend/Nacht dann noch das Menu anpassen und das 2. Programm - Manuell Modus in Angriff nehmen, das sollte gleich erledigt sein.


    Anschliessend kommt der DMX Teil, der wird dann wahrscheinlich etwas kniffliger.


    Gruß, Benny.

    Hallo,


    ich hab da eine jetzt doch dringende Frage. Ich habe je geschrieben das ich im Fading Modus 6 Farben zur Verfügung stellen möchte. Also 6 Farben zwischen denen hin und her gefadet werden kann, jede Farbe für sich einstellbar.


    Nun sehe ich aber das jede Farbe ca. 5% des Platzes im µC weg nimmt. Bei 6 Farben wären das alleine schon für den Fading Modus 30%.


    Jetzt die Frage, wie viele Farben soll mein einstellen können? Müssen es 6 sein, oder mehr oder weniger? Für mich macht das ganze nur Sinn wenn jemand nur warme oder nur kalte Farben haben will. Geht man von der ersten Stufe aus bei warmen Farben haben wir noch noch rot. In der 2. Stufe dann gelb und eventuell violett. Also bisher 3 Farben. Aus der 3 Stufe könnte man noch pink und orange mit dazu nehmen, dann wären es 5 Farben.
    Mehr macht eigentlich keinen Sinn oder? Dann könnte ich die 6. Farbe schon mal weg lassen.


    Gruß, Benny.