LED-uhr, fastSPI_LED2 und NECirRemote

guten morgen,

ich steuere meine WS2812-LEDs mit der fastSPI_LED2 an, und das ist ja sehr zeitkritisch. wenn ich dann mit einer kleinen fernsteuerung drangeh', um die uhr zu stellen oder die farben zu ändern, reagiert der µC in den meisten fällen nicht, weil er gerade die 60 LEDs beschreibt (25x in der sekunde). wenn ich einen interrupt verwende, gibt's ein durcheinender. Ok. soweit klar.

ich hab's jetzt soweit gelöst, als ich mit einem taster in einen "fernsteuerungs-modus" wechsle, in dem die LEDs nur dann neu beschrieben werden, wenn ich stunden, minuten, farbe per fernsteuerung verändere. wäre ja durchaus in ordnung, aber mich juckt's natürlich, das anders zu lösen.

eine möglichkeit wäre, einen attiny85 nur für die fernsteuerung zu verwenden und über TWI auszulesen, wenn der "große" controller zeit hat (auch hier, erst eine bestimmte FB-taste für fernsteuerungs-modus).

hat jemand andere ideen dazu?

gruß stefan

Hallo Eisebär,

warum läuft die Uhr denn mit 25 fps? Ist das nötig?

Gruß

Helmuth

hi, helmut,

da wird ein verlauf gedimmt. schau im internetz nach equinox-uhr, dann siehst Du, was ich meine...

gruß stefan

Ich sehe auch nur die Möglichkeit einen Programmmodus einzufügen bei denen die LED nur bei updates angesteuert werden und nicht dauernd. Du kannst ja auf das Signal des IR Empfängers triggern. Einfach RC Glied dran und an einen Eingang anschließen. Mittels Polling diesen abfragen und bei Signalen in Programmmodus schalten bzw nach einer bestimmten Zeit ohne signale wieder zurück in Anzeigemodus. Der Nachteil ist daß dann, jede Fernsteuerung auch wenn ncht für die Uhr bestimmt diese in Programmodus bringt. Grüße Uwe

hallo, uwe,

ja, das ist das problem. wenn ich nur auf "irgendein" signal warte, bleibt die uhr dauernd stehen, das geht also nicht. und wenn ich mit der NEC-library auf bestimmte signale warte, kommt kaum mal ein befehl an. das mit dem taster würde prinzipiell reichen, aber mit einem attiny85 ist es natürlich eleganter (und auch eine schöne übung, um zwei µCs miteinander reden zu lassen, hab' ich ohnehin noch nie gemacht). ich wollte nur nichts einfaches übersehen.

danke und gruß stefan

Hi Eisebaer,

zeitkritisch ist ja nur das eigentliche strip.show(); also das pushen der Daten zum Strip.

25 fps bei 60 LEDs ist nicht viel, da bleibt doch jede Menge Zeit zum vorherigen überprüfen, ob IR Signale kommen - und ggf. dann keine Daten zu senden, da das ungestört in einem Rutsch erfolgen muss.

Ich komme mit den WS2812 auf 29 fps mit 480 LEDs - bei 60 LEDs sollten also ca. 120 fps drin sein...

Wie lange dauert denn die IR Datenübertragung?

Vielleicht funktioniert es, permanent den IR Status zu checken und nur im negativen Fall den Strip zu schreiben.

Gruß

edit: Diesen Satz verstehe ich nicht: "wenn ich nur auf "irgendein" signal warte, bleibt die uhr dauernd stehen" Kurz schauen, ob ein Signal kommt, wenn nicht, dann fix den Strip schreiben, wieder IR lauschen?!

hi, helmut,

edit: Diesen Satz verstehe ich nicht: "wenn ich nur auf "irgendein" signal warte, bleibt die uhr dauernd stehen" Kurz schauen, ob ein Signal kommt, wenn nicht, dann fix den Strip schreiben, wieder IR lauschen?!

die library für fernbedienungen gibt nur einen wert aus, wenn es ein "erkannter" wert ist, das wird aber dauernd von show gestört. ich kann also nicht auf ein bestimmtes signal warten (zb. 7234004325 für einen bestimmten knopf der fernbedienung)

wenn ich auf jedes HIGH vom pin des ir-empfängers reagiere, das heißt, ich bei "jedem" ir-signal das show ausschalte, damit ich auf bestimmte signale warte, passiert das bei jedem signal jeder IR-fernbedienung und die uhr bleibt dauernd stehen.

gruß stefan

Du meinst sicherlich, dass die Anzeige stehenbleibt? Millis() läuft doch trotzdem weiter, oder? Verstehe ich richtig: Dein Problem ist, dass die Anzeige nicht aktualisiert wird, wenn Du Deine sonstige Unterhaltungselektronik fernbedienst?

hi,

also je länger ich drüber nachdenke, umso besser gefällt mir die lösung.

ein zweites, kleineres problem ist, daß die library für's NEC-protokoll kein repeat-signal hergibt, ich also nicht einfach den finger drauflassen kann, um schnell werte rauf- oder runterzusetzen.

die irRemote-library, die viele protokolle kann, macht das, ist aber wiederum zu groß, um dann alles in 8k flash unterzubringen(attiny84). klar kann man gleich einen atmega328er nehmen, der preis ist ja nicht das problem, aber das ist doch unelegent. 8)

und einfach aussuchen, welchen atmel man grade braucht, geht nicht so einfach, weil entweder nur bestimmte modelle angeboten werden oder man horrende (25€) portokosten bei speziellen anbietern berappen muß.

mit 2 attiny85 sollte es sich ausgehen, sofern die irRemote-library mit einem prozessor mit internem taktgeber klarkommt und auch twi zwischen zwei verschieden getakteten funktioniert. ich kann nicht beide extern takten, weil ich sonst einen pin zuwenig habe. jeder 85er hat 5 pins:

  1. 85er: 2x quarz 16MHz, 2x TWI, 1x LEDs
  2. 85er: 2x TWI, 1x LDR, 1X IR, sogar noch einer reserve

muß ich mal probieren...

so ein m...., grade als ich wegschicken wollte, ist mir eingefallen, daß ich ja auch SQW von der RTC nutze. muß ich nachdenken, aber ich glaube, das geht, nur muß ich meinen sketch komplett neu schreiben und nicht nur anpassen. oder einen 84er und einen 85er. na gut, ich geh' in tüftelmodus...

gruß stefan

hi, helmut,

Du meinst sicherlich, dass die Anzeige stehenbleibt? Millis() läuft doch trotzdem weiter, oder? Verstehe ich richtig: Dein Problem ist, dass die Anzeige nicht aktualisiert wird, wenn Du Deine sonstige Unterhaltungselektronik fernbedienst?

nein, das problem ist, daß ich die aktualisierung der leds ausschalten muß, wenn ich auf einen code warten will. wenn ich 25 fps habe, habe ich einen taktlänge von 40ms:

die led-aktualsierung dauert, sagen wir, 10ms

und die länge eines ir-codes scheint sehr lange zu dauern, sagen wir 25ms:

ich habe also kaum eine chance, einen kompletten ir-code innerhalb dieses fensters abzufragen. ich kann und habe auch gemacht: einen interrupt auf RISING am ir-pin, und wenn da was kam, eine volatile pfrnzn auf 1 gesetzt. in der loop, wenn pfrnzn 1, kein beschreiben der leds, warten auf ir-code. hat funktioniert, aber dann ist es egal, was auf den ir-sensor auftrifft, jedes HIGH schaltet in diesen modus...

gruß stefan

Nein nicht ganz so. Du überwachst über ein Pin in der loop() schleife ob der IR Empfänger Daten empfängt. Kann auch das gleiche Pin sein das IRremote benutzt. Falls die LOW-Zeit zu kurz ist um sicher erkannt zu werden mußt Du halt ein RC Glied nehmen und ein zweites Eingangs Pin benutzen. In Uhr-Modus steuerst Du die LEDs an und kontrollierst ob der Empfänger auf LOW geht. Ist der Empfänger auf LOW gegangen schaltest du in den Fernsteuer/Einstellmodus mit Update der LEDs nur bei Änderung und schaltest die IRremote Empfang scharf. So verlierst Du den ersten IR-Code aber der kann ein x-beliebiger sein. Grüße Uwe

hi,

uwe, soweit hat das ja auch funktioniert, wie ich's gemacht habe. das problem ist, daß mir der interrupt dann irgendwie dazwischengefahren ist. ich muß das nocheinmal probieren, um es genauer zu beschreiben. aber das grundproblem bleibt:

So verlierst Du den ersten IR-Code aber der kann ein x-beliebiger sein.

und einen x-beliebigen code krieg ich von jeder fernbedienung von jedem gerät.

wenn ich den fernseher lauter stelle, komm' ich in den "Fernsteuer/Einstellmodus". und das ist halt nicht sinn der sache. ich konnte aber mit meiner methode auch schon den ersten code auslesen, womit obiges problem entsorgt sein sollte. das problem war, auch wenn's seltsam wirkt, das zurückkommen in den uhrenmodus. ich muß das wirklich nochmal aufbauen, und diesmal den sangria weglassen. :cold_sweat: ich denke, der interrupt hat mir da dazwischengefunkt. uwe, Du kennst mein elektronikwissen. wie müßte das rc-glied beschaffen sein?

gruß stefan

PS.: aber das mit den zwei attiny85 reizt mich trotzdem...

gruß stefan