Hallo mikrocontroller.net, ich habe bei mir um's Haus ein Bussystem, an das verschiedene I/O Geräte mit jeweils eigenen Adressen angeschlossen sind, damit ich sie über ein Wandpanel einzeln abfragen kann. Hauptsächlich geht es darum, Tür- und Fensterkontakte zu prüfen, Lichtsensor, Temperatur, etc. Ist aber auch eigentlich nebensächlich. ;) Ich würde mir jetzt gerne einen 8-Kanal (1 x in / 8 x out) Splitter bauen um einerseits Kabel zu sparen und andererseits Gebäudeteile (Haus, Werkstatt, Garage) zu trennen. Den Splitter selber habe ich bereits fertig. Beim Gestalten des Gehäuses kam mir dann noch die Idee, für jeden Ausgangskanal eine 3mm RX LED einzubauen. Wenn also Antworten auf einem der Kanäle kommen, soll das für den jeweiligen Kanal optisch angezeigt werden. Ein erstes Experiment, die LED einfach über einen Schmitt-Trigger Inverter an die RX Leitung zu hängen, hat prinzipiell schonmal funktioniert. Aber das Geblinke ist sehr unregelmäßig und manchmal auch zu kurz, um es deutlich wahrzunehmen (weil abhängig von den Einsen und Nullen auf der Leitung). Wie könnte man sowas mit vorgegebener Blinkfrequenz machen? Also sagen wir mal bspw.: 1) Daten werden erkannt (HIGH => LOW Flanke an RX) 2) LED blinkt mit 80ms on/80ms off 3) wenn keine Daten mehr kommen und ein RX "Timeout" erreicht ist wird das Blinken gestoppt. Meine erste Idee war, einen NE555 als Multivibrator zu betreiben um den Blinktakt für alle Kanäle zu definieren. Und dann für jeden Kanal einen weiteren 555 als monostabile Kippstufe um das Timeout zu definieren und natürlich die RX Aktivität überhaupt zu erkennen (LOW an RX löst den 555 aus). Multivibrator und Monostabile Kippstufe dann mittels HCT08 ver-unden-en und am Ausgang des *08 dann die LED für den jeweiligen Kanal. Sind dann allerdings mit der insgesamt 9-fachen Beschaltung der NE555 ziemlich viele Bauteile. :/ Wie könnte man es eventuell sonst noch lösen? Ich bin leider nicht so bewandert in der Mikrocontroller-Programmierung. Das wäre vermutlich die platzsparendste Variante, oder? Danke für jede Idee ;) Werner
Ein uController kann das sicherlich recht einfach bewerkstelligen. Irgendein einfach PIC, Atmel oder was auch immer. Dann kannst du jede LED "La Paloma" pfeifen lassen :-) Wenn schon Bus, warum kein RS485 ? Dann brauchst du für die gesamte Kommunikation nur 2 Leitungen.
Also ich würde das einfacher und ohne blinken machen: an RX ein retriggerbares Monoflop hängen. Da gibt es 2 Stück in einem Gehäuse: 74HC123. Dann brauchst du 4*74HC123 + 8*R + 8*C.
Werner schrieb: > Den Splitter selber habe ich bereits fertig. Beim Gestalten des Gehäuses > kam mir dann noch die Idee, für jeden Ausgangskanal eine 3mm RX LED > einzubauen. Das einfachste wird sein, dem Splitter noch die LEDs aufs Auge zu drücken. Der Splitter weiss doch, wann Daten kommen. Falls die IO-Pins schon knapp sind, hängst du die LEDs z.B. über einen I2C-Port-Expander oder über SPI mit SIPO Schieberegister ran. Kostet dich kaum Hardware und nur wenige IOs.
Wenn Du via Pupille "messen willst, darfst Du Dich nicht wundern, wenn Du anschließend Kopfschmerzen hast;) Eine Meldung dauert (so sie nicht dauernd wiederholt wird) meist nur ein paar Millisekunden. Das dann auch zu "sehen" ist richtig anstrengend. Vor allem, wenn Du nicht weist, wann sie kommt. Meist dauert es nicht lange, und Du glaubst daß ständig Meldungen kommen - oder etwa nicht?
Hallo die Herren, vielen Dank für die Antworten. > Schorsch: > Ein uController kann das sicherlich recht einfach bewerkstelligen. > ... > Wenn schon Bus, warum kein RS485 ? Dann brauchst du für die gesamte > Kommunikation nur 2 Leitungen. Tja, vielleicht werde ich mich mal an einem Mikrocontroller versuchen. Das scheint mir irgendwie an der Zeit ;) Und zu RS-485: Absolut richtig, allerdings habe ich dieses System vor ungefähr 10 Jahren zusammen mit meinem Schwager begonnen. Und wir hatten die tollsten Ideen, was man damit alles machen könnte. Irgendeine von diesen Ideen erforderte Full-Duplex Kommunikation. Natürlich ist nie was draus geworden und der ganze Laden redet ausschließlich halb-duplex. Insofern könnte man theoretisch auch alles mit RS-485 machen. Aber ändern werd' ich das jetzt auch nicht mehr... Dann würde ich eher eines der vielen Hausbus Systeme nehmen, die es heute ja überall gibt. > Dietrich: > Also ich würde das einfacher und ohne blinken machen: an RX ein > retriggerbares Monoflop hängen. > Da gibt es 2 Stück in einem Gehäuse: 74HC123. Dann brauchst du 4*74HC123 > + 8*R + 8*C. Das wäre auch eine Möglichkeit. Lasse ich mir mal durch den Kopf gehen. Vielen Dank! > Wolfgang: > Der Splitter weiss doch, wann Daten kommen. Falls die IO-Pins > schon knapp sind,... Also genau genommen, weiß der Splitter ziemlich wenig. Der besteht ja nur aus einem Schwung MAX485, ein paar Optokopplern und einer Hand voll Logikgatter. Einen Controller gibt es hier noch gar nicht. Der käme eben erst jetzt ins Spiel, wenn ich die Aktivitätsanzeige noch mit dazu baue. ;) > Sebastian: > Eine Meldung dauert (so sie nicht dauernd wiederholt wird) meist nur ein > paar Millisekunden. Das dann auch zu "sehen" ist richtig anstrengend. > Vor allem, wenn Du nicht weist, wann sie kommt. Meist dauert es nicht > lange, und Du glaubst daß ständig Meldungen kommen - oder etwa nicht? Ach, so ziemlich alles ist inzwischen anstrengend für meine Augen. ;) Aber gern erläutere ich: Prinzipiell hast Du Recht. Wenn ich einen Raum einmal abfrage, dürfte die LED schon wieder aus sein, bevor ich meinen Blick auf sie gerichtet habe. Wobei genau das ja auch ein Grund war, das Blinken nicht direkt aus den Einsen und Nullen auf der RX Leitung zu erzeugen, sondern eben altersgerecht "beruhigt" ;) Weiterhin kann ich bestimmte Funktionen aber auch im Dauerlauf abfragen und protokollieren. Die Temperatur, zum Beispiel. Dann ist die LED natürlich viel besser wahrnehmbar. Nun denn, ich werde mich mal in die Werkstatt begeben und schauen, das ich mal was auf's Papier bekomme. Vielleicht kann ja jemenad nachher nochmal einen Blick darauf werfen. Recht herzlichen Dank, Werner
Sebastian S. schrieb: > Eine Meldung dauert (so sie nicht dauernd wiederholt wird) meist nur ein > paar Millisekunden. Das dann auch zu "sehen" ist richtig anstrengend. Genau deswegen ist "autonomes" Blinken mit Timeout eine vernünftige Lösung zur Anzeige des Datenverkehrs. Werner schrieb: > 3) wenn keine Daten mehr kommen und ein RX "Timeout" erreicht ist wird > das Blinken gestoppt. Werner schrieb: > Also genau genommen, weiß der Splitter ziemlich wenig. Der besteht ja > nur aus einem Schwung MAX485, ein paar Optokopplern und einer Hand voll > Logikgatter. Einen Controller gibt es hier noch gar nicht. Sorry, ich war von einem Multiplexer ausgegangen. Dann brauchst du vielleicht doch noch einen kleinen µC, der sich die 8 TX-Leitungen deiner I/O-Geräte anguckt, ggf. wieder über Port-Expander.
Angehängte Dateien:
-
RX_Indicator.png
14 KB
Soooo, da will ich es natürlich nicht versäumen, das Ergebnis der letzten Nachtschicht hier auch mal zu zeigen, damit ihr wisst, wie es weitergeht. Zunächst mal habe ich mich entschieden, dass mittels eines Mikrocontrollers umzusetzen. Rein in Logik erschien es mir dann letztlich zu unflexibel, insbesondere, wenn ich an dem Blinkmuster mal was verändern möchte oder dieses Projekt mal an anderer Stelle in ähnlicher Form wiederverwenden möchte. Da ich hier ein Arduino Uno Board mit einem Atmega328 in der Schublade hatte, fiel die Wahl auch eben diesen Controller. Der wird dann noch mit auf der Splitter-Platine verbaut. Die LEDs hingegen kommen auf eine zweite Platine, die hinter dem Frontpanel sitzt. Das zugehörige Schieberegister ebenfalls. Die Programmierung ist das Resultat mehrer Anläufe und Internetrecherchen. Das Prinzip ist nun so: Jeder RS/422 Kanal hat UART-seitig nun einen Abzweig auf der RX Leitung, die zu den RX-Sense Pins (so nenne ich sie mal) am Controller geführt wurde. Ein Pin-Change Interrupt erkennt auf diesen Pins Bewegung und aktualisiert ein Status-Array. Dieses Statusarray enthält im Grunde nur Zählerstände, wie oft der jeweilige Kanal noch zu blinken hat. Hier im Beispiel sind es immer mindestens 6 x blinken. Gibt es also nur eine kurze Flanke auf der Leitung, dann blinkt die zugehörige LED 6 Mal... Ist mehr Datenverkehr, setzt der Interrupt den Zähler immer wieder erneut auf 6, so dass nach Ende der Übertragung noch 6 mal geblinkt wird, bevor endgültig Ruhe ist. In der Funktion update_activity_indicator() wird dann anhand des Status-Arrays die Ausgabe auf den LEDs im Dauerlauf erzeugt. Nach jedem Shift-Vorgang wird der o.g. Zählerstand um eins reduziert. Was ich noch nicht herausgefunden habe: Dieser Pin-Change Interrupt scheint nur bei einer Flanke von LOW nach HIGH auszulösen. Der Perfektionist hätte es sicher gern andersrum, denn HIGH ist die RX Leitung ja dann, wenn nix passiert... Die Übertragung beginnt mit der ersten Flanke auf LOW. Aber seis drum - es funktioniert ja auch so herum. Im Anhang ein Schaltplan und der Code für den Atmega328. (Hier reduziert auf einen Eingang und 4 Ausgänge, da mir die Ausbaustufe auf 8-1 noch bevorsteht. (zwei Schieberegister, zweiter Port für RX-Sense, noch eine ISR, etc.) Falls jemand Lust hat, das Ganze zu überfliegen, freue ich mich natürlich sehr über Rückmeldung und stehe Rede Antwort. ;) Ansonsten ein schönes Wochenende, Werner
Werner schrieb: > Dieser Pin-Change Interrupt scheint nur bei einer Flanke von LOW nach > HIGH auszulösen. Wenn du die RX Signale per Wired-OR alle auf Int0 oder Int1 legst, kannst du dir im EICRA die gewünschte Interruptbedingung einstellen. In der ISR würdest du dann den ganzen Port mit allen RX Signalen einlesen und gucken, wer aktiv ist. Das gibt dir auch die Möglichkeit, mehr Kanäle (über Schieberegister) abzufragen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.