Ich suche momentan nach einer simplen und kleinen Lösung, um Übertragungen auf einer 5V / 3V3 UART per LED zu visualisieren..
Das ganze dient dann als einfache Betriebsanzeige auf einem Interface.
Nachdem hier oft mit kurzen Übertragungen und hohen Baudraten gearbeitet wird, wird da aktuell ein NE556 im SO14 Case nebst den obligatorischen 4 Bauteilen benutzt, um die Blinkpulse zu verlängern ...
Jetzt die Frage, kennt da jemand eine kleinere Lösung mit ggfs weniger Bauteilen (ohne direkt einen uC einzusetzen)?
Für CAN habe ich da zb mal einfach einen Transceiver verwendet, der einen C auflädt, welcher dann über die LED entladen wird..
kennt da jemand eine kleinere Lösung mit ggfs weniger Bauteilen
AVR Mikrocontroller (Überraschung). Ich würde dafür einen alten ATtiny13 aus dem Ärmel schütteln. Wenn er due LEDs abwechseln pulsierend ansteuert, braucht man nur einen einzigen Widerstand dazu.
Ja, mit dem Tiny sicherlich kein Problem -
der muss dann allerdings auch erstmal geflasht werden, und Platinenfläche für die Programmierpins braucht es auch.
Ich suche momentan nach einer simplen und kleinen Lösung
Die besteht in einem LVC-Einzelgatter nebst Vorwiderstand der LED.
Ein Pullup am Eingang verraet dann auch, ob er womoeglich "offen" ist.
Der Rest der "Ideen" hier ist Moppelkotze, und beschraenkt(!) nur
die Diagnosemoeglichkeiten im Fehlerfall.
Man sollte es natuerlich schaffen, den logischen Idlepegel in ein
optisches "Dunkel" zu uebersetzen, und nicht wie die Duennbrettbohrer
bei der c't das zu versemmeln.
Ja, Leute mit so einem Tonfall am Leib nimmt man dann auch gleich voll ernst.
Man sollte es natuerlich schaffen
... nur auf die Flanken zu reagieren, denn sonst leuchtet die Übertragung dauernd, auch wenn sich das System auf dem aktiven Pegel festgefressen hat. Und statisch "low" ausgibt.
... nur auf die Flanken zu reagieren, denn sonst leuchtet die
Übertragung dauernd, auch wenn sich das System auf dem aktiven Pegel
festgefressen hat. Und statisch "low" ausgibt.
Da bist du wohl nicht ganz im Bilde. Es geht um einen UART.
Wenn der nichts zu vermelden hat, gibt er "Idle" aus.
Und bei einer aktiven Uebertragung sorgt schon der Nachrichteninhalt
fuer eine Modulation der Helligkeit.
Nein, ich bin dir gedanklich einfach nur einen Schritt voraus (und offenbar mindestens 2 andere auch).
Es geht um einen UART.
Wenn der nichts zu vermelden hat, gibt er "Idle" aus.
Ja, wenn nicht der Ausgang einen Fehler hat oder das Program oder ein Masseschluss passiert ist. Oder was meinst, warum ich extra "festgefressen" geschrieben habe? Solche Fehler kennst du nicht? Dann mein Glückwunsch zu deiner heilen Welt.
Nein, ich bin dir gedanklich einfach nur einen Schritt voraus (und
offenbar mindestens 2 andere auch).
Es geht um einen UART.
Wenn der nichts zu vermelden hat, gibt er "Idle" aus.
Ja, wenn nicht der Ausgang einen Fehler hat oder das Program oder ein
Masseschluss passiert ist. Oder was meinst, warum ich extra
"festgefressen" geschrieben habe? Solche Fehler kennst du nicht? Dann
mein Glückwunsch zu deiner heilen Welt.
Und wie soll das ein "Blinki-Blinki" detektieren?
Mit dem Pullup kann ich wenigstens "offener" Eingang feststellen.
Mit geuebtem Auge kann man sogar die Baudrate abschaetzen.
Fuer einen Leitstand wuerde ich wohl ein retriggerbares Monoflop
verwenden, dasw eine gruene LED leuchten laesst.
Die Haltezeit wuerde ich aber auf mindestens 30 Sekunden einstellen.
Aber keineswege eine "normal" funktionierende Datenverbinbung
an einer Frontplatte mit einem "Blinker" anzeigen.
OT: Norma hat es geschafft, den Zustand "hat Kontakt", in einem
Durchgangspruefstift, mit Blinken (ca. 1 Hz) anzuzeigen.
Das ist natuerlich voellig unbrauchbar.
Nimm eine High-Efficient rote LED und Vorwiderstand etwa 5-10k.
Bei einem Signal von z.B. 5V und 5k sind das etwa 0,6mA für 10µs je 0-Bit. Das siehst Du noch blitzen, wenn ein einzelnes Byte mit 115k nur das Startbit gesetzt hat.
Wenn Du es sehr hochohmig möchtest, nimm irgendeinen Inverter oder Treiber dazwischen. Wenn es trotzdem zu dunkel ist (noch höhere Baudrate, schlechte LED), dann schalte 100nF parallel zum Vorwiderstand.
Ob das Signal invertiert ist oder nicht, spielt keine Rolle. Die LED wird entsprechend gegen VCC oder GND geschaltet, dass sie im Normalfall (1-Bit) aus ist.
Dann macht der Tiny die Strombegrenzung, mit dem Maximum was er kann
Ich weiß.
Ging hier damals um ein Flugzeug, möglichst wenig Gewicht.
Da die nur kurz blitzen sollte (Beacon), war ich der Meinung, dass das weder dem Controller noch der Led etwas anhaben kann.
Ich glaube insgesamt hatte ich das über einen Monat laufen.
Ich hatte das Stichwort schon erwähnt: die Änderung eines Pegels steckt in den Flanken. Wenn sich der Pegel eines RS232-Signals nicht mehr ändert (egal ob es auf low oder auf high oder high-z sitzt), dann wird nichts mehr übertragen. Also einfach ein flankengetriggertes Monoflop und fertig.
Habe ich als Test schon wochenlang ohne Widerstand blinken lassen.
Weder Led noch Tiny10 gingen kaputt.
Ich habe das schon mit dauerhaft angesteuertem und nach GND kurzgeschlossenem Ausgangspin gemacht. Nach einem halben Jahr hat der Pintreiber noch "funktioniert". Ob er noch in der Spec war habe ich nicht ausgemessen.
Ob er noch in der Spec war habe ich nicht ausgemessen.
Die I/O Pins der alten AVR (mit ISP, bei den neuen weiss ich es nicht) liefern im Kurzschlussfall bei 5V etwa 50mA, was außerhalb der maximum Ratings liegt.
Um einen AVR damit kaputt zu kriegen, muß man allerdings viele Pins gleichzeitig kurzschließen oder einen Fön drauf halten.
Aber eben nur ganz, ganz, ganz kurz. Viel, viel kürzer als ein
Wimpernschlag dauert.
Warum dann nicht eine Luxus-Lösung mit 2 LEDs: flankengetriggertes Monoflop + statische Anzeige des Zustands.
Beides zusammen liefert viel mehr Informationen: Ruhezustand, Leben auf der Leitung und ggf. auch Abschätzung der Übertragungsgeschwindigkeit.
Bietet sich vor allem bei der Lösung mit Mikrocontroller an. Man kann sich dabei an den LEDs von Ethernet Anschlüssen orientieren. Gerne auch mit zweifarbigen Duo LEDs.
Ich habe das schon mit dauerhaft angesteuertem und nach GND
kurzgeschlossenem Ausgangspin gemacht. Nach einem halben Jahr hat der
Pintreiber noch "funktioniert".
Ich möchte euren Erfahrungsschatz nicht schmälern.
Glaube aber auch nicht, dass man daraus eine Empfehlung ableiten kann.
Da nehme ich doch ehr die Daten aus den Datenblättern als Empfehlung.
PS:
Selber habe ich es auch schon geschafft insgesamt 2 AVR Pins zu töten.
Den ersten:
Einmal versehentlich mit 12V dran her gewischt.
Hat ihm offensichtlich nicht geschmeckt.
Den zweiten:
KA, warum. Kann eigentlich nur ein Schluss nach Vcc oder GND gewesen sein.
Lötperle, oder so.
Mit etwas Hintergrundwissen ist das gar nicht so kompliziert. Du willst den Ausgang des UART auf Funktion prüfen, und dieser arbeitet in positiver Logig mit definierter Ruhelage. Diese Ruhelage ist der High-Pegel 5V/3,3V. Bei Datentransfer wechselt der Pegel zwischen High und Low. Da Du nicht die einzelnen Bit, sondern nur die Funktion sehen willst genügt ein LED-Treiber.
Ob das nun ein Transistor, OPV, Gatter oder sonstwas ist, spielt keine Rolle. Wichtig ist nur dass die LED in Ruhelage dunkel und der Eingang des Treibers hochohmig ist.
Glaube aber auch nicht, dass man daraus eine Empfehlung ableiten kann.
Nein, auf keinen Fall! So sollte das auch nicht gemeint sein.
Das hatte sich, wie so oft im Mikrocontroller.net, dort völlig aufgeschaukelt. Eigentlich ging es ursprünglich nur darum "mal eben die Led dran halten". Irgendwer (Bedenkenträger) hatte dann ein riesiges Fass aufgemacht und das war für mich dann die Herausforderung zu beweisen, dass das bei seinen Flügen niemals zum Problem werden könnte.
Ich weiß nicht die Frequenz von so einem Beacon, aber die blitzen nur kurz auf; also kaum an, dann sind sie wieder aus.
Natürlich nimmt man einen Widerstand und bei SMD muss man wirklich nicht über das Gewicht nachdenken.
Noch ein paar ergänzende Worte. Die Helligkeit der LED wird über ihren Vorwiderstand eingestellt. Je kleiner der Widerstand, desto höher der Strom, desto heller die LED.
Da das Signal zum einschalten der LED von einer Schnittstelle kommt, ist die Gefahr eines Kurzschluß auf dieser Leitung gegen 0V (LED ein) relativ groß. Der Strom durch die LED darf in diesem Fall den maximal zulässigen Dauerstrom der verwendeten LED nicht überschreiten, damit sie keinen Schaden nimmt.
Sollte die Helligkeit der LED für die Anzeige dann noch nicht ausreichen, muss die Anzeigedauer verlängert werden. Im einfachsten Fall mit einen Kondensator oder einem Monoflop.
jeweils an Tx Rx einen OPV Impedanzfolger, effiziente LED ran, fertig.
Da sollte man dann aber einen halbwegs schnellen OPV nehmen...
Und direkt einen Digitalen, aka Gatter.
Bruno V. schrieb:
Das siehst Du noch blitzen
Aber eben nur ganz, ganz, ganz kurz. Viel, viel kürzer als ein
Wimpernschlag dauert.
Für den optischen Eindruck spielt das keine Rolle.
Wenn es darum geht, ein einziges Byte in 10s zu detektieren, dann natürlich mit Monoflop.
Wenn das Byte jede Sekunde wiederholt wird, reicht es ohne. Die Chance, einen Blitzer durch einen Wimpernschlag zu verlieren, ist vielleicht 1%. Bei n hintereinander mit >>1ms Abstand sind es dann (1%)^n
Die I/O Pins der alten AVR (mit ISP, bei den neuen weiss ich es nicht)
liefern im Kurzschlussfall bei 5V etwa 50mA, was außerhalb der maximum
Ratings liegt.
Soweit ich mich erinnern kann, waren es ca. 83mA, als ich meine Kurzschluss-Tests mit ATMEGA1284P-PU damals durchgeführt habe. Hängt aber auch von einigen Faktoren ab, z.B. der Siliziumfertigung ab, wieviel tatsächlich fließen wird.
Wenn das Byte jede Sekunde wiederholt wird, reicht es ohne. Die Chance,
einen Blitzer durch einen Wimpernschlag zu verlieren, ist vielleicht 1%.
Bei n hintereinander mit >>1ms Abstand sind es dann (1%)^n
Anstelle von "Schäfchen zählen" beobachte ich die LED des Rauchmelders, die ca. alle 40s blinkt. Ich beobachte sie im Dunkel und die "blitzt" sicher länger auf als die 100µs, die eine LED bei 115kBd aufblitzt. Und trotzdem verpasse ich ab&zu einen Blitzer und komme beim Zählen über 70...
Aber wie gesagt: meine Lösung zur Anzeige von RX und TX wäre der erwähnte 6-Pin µC, ein Blockkondensator, zwei Widerstände und die beiden LEDs. Und die Software im µC würde die Flankenerkennung machen. Wenn man ein periodisches Protokoll hat, könnte man sogar "stuck-low" und "stuck-high" durch besondere Blink-/Blitzsequenzen signalisieren, wenn sich der Pegel für eine bestimmte Zeit nicht ändert.
Der Vorwiderstand hier sollte eigentlich im Kollektor- und nicht Emitterpfad sein – bei diesem Babystrom, der da fließt, und der Spannungsreserve, die vorhanden ist, wird es trotzdem irgendwie funktionieren.
Habe ich als Test schon wochenlang ohne Widerstand blinken lassen.
Weder Led noch Tiny10 gingen kaputt.
Ich habe das schon mit dauerhaft angesteuertem und nach GND
kurzgeschlossenem Ausgangspin gemacht. Nach einem halben Jahr hat der
Pintreiber noch "funktioniert". Ob er noch in der Spec war habe ich
nicht ausgemessen.
dazukommt. Solche "Ratschlaege" braucht nun wirklich keiner.
Das konnte man das letztemal mit der unbuffered CMOS-Serie machen.
Und das ist schon eine Weile her.
Ja, wenn nicht der Ausgang einen Fehler hat oder das Program oder ein
Masseschluss passiert ist. Oder was meinst, warum ich extra
"festgefressen" geschrieben habe? Solche Fehler kennst du nicht? Dann
mein Glückwunsch zu deiner heilen Welt.
Nein, solche Fehler kenne ich nicht.
Bei korrekt konfigurierten Pins und einem richtig konfiguriertem
UART "frisst" sich kein Signal fest.
Bei "selbstkonfigurierter" Logik, aka FPGA, hat man das verwendete
Beschreibungsmodul ja auch bereits separat getestet.
Damke fuer den "Glueckwunsch".
Der Vorschlag mit einem PNP-Transistor als Treiber hat den nicht
ganz so offensichtlichen Mangel, dass die Schaltschwelle eine andere
ist, als die des RX-Eingangs. Da werden also u.U. "Daten" angezeigt,
die gar nicht beim Empfaenger ankommen.
Ueber OPVs als Impedanzwandler lasse ich mich gar nicht aus.
Kann man natuerlich machen, laesst sich, wenn der OPV wenigstens
als Komparator arbeiten wuerde, auch exakt einstellen, hat aber
gegenueber einem Einzelgatter keinen verbesserten Naehrwert.
Wenn in einem Auto etwas kaputt ist, "blinkt" etwas.
"Blinken" als Normalzustand zu definieren, zeigt nur wie ******
ihr alle schon seid.
Anstelle von "Schäfchen zählen" beobachte ich die LED des Rauchmelders,
die ca. alle 40s blinkt. Ich beobachte sie im Dunkel und die "blitzt"
sicher länger auf als die 100µs, die eine LED bei 115kBd aufblitzt. Und
trotzdem verpasse ich ab&zu einen Blitzer und komme beim Zählen über
70...
Die Kenntnisnahme eines Blitzers haette uebrigens gereicht.
Das macht die Sache in der Summe nicht wesentlich besser. Allerdings habe ich die 115kBd angenommen, wir wissen nicht, was da beim Jan tatsächlich verwendet wird.
Wenn dir solche Fehler gelaeufig sind, dann deshalb, weil sie offenbar auch immer wieder passieren. Und wenn ich weiß, dass sie immer wieder passieren und eine neue Schaltung zur Überwachung einer Kommunikation entwerfe, dann berücksichtige ich solche Fehler eben auch. Im Besonderen, wenn diese Funktion keine wesentlichen Zusatzkosten verursacht.
Man kann natuerlich aus jeder Fliege einen Elefanten machen.
Andere sagen dann eher: so ein Fehler juckt mich nicht.
Aber das unterscheidet eben den schlechten vom guten Entwickler.
Man kann natuerlich aus jeder Fliege einen Elefanten machen.
Andere sagen dann eher: so ein Fehler juckt mich nicht.
Aber das unterscheidet eben den schlechten vom guten Entwickler.
Stuck-At wird ja auch vom naiven Ansatz sofort gemeldet: Es ist ohne jedes Flackern und ohne jeden Einbruch AN.
Der Aufwand einer LED mit Vorwiderstand (oder notfalls noch eines Gatters als Treiber) ist deutlich kleiner. Und die zu beobachtenden Muster sind deutlich "direkter" als wenn ich jedesmal im Code schauen muss, welch trickreiches Flagging mit welch unerwartetem Pattern jetzt genau dies Muster erzeugt.
Anstelle von "Schäfchen zählen" beobachte ich die LED des Rauchmelders
Die Kenntnisnahme eines Blitzers haette uebrigens gereicht.
Ja, wäre tatsächlich nett, wenn zum "Schäfchen zählen" nur ein einziger Blitzer ausreichen würde und ich immer gleich nach dem ersten Blitzer eingeschlafen wäre.
Das macht die Sache in der Summe nicht wesentlich besser. Allerdings
habe ich die 115kBd angenommen, wir wissen nicht, was da beim Jan
tatsächlich verwendet wird.
Wenn dir solche Fehler gelaeufig sind, dann deshalb, weil sie offenbar
auch immer wieder passieren. Und wenn ich weiß, dass sie immer wieder
passieren und eine neue Schaltung zur Überwachung einer Kommunikation
entwerfe, dann berücksichtige ich solche Fehler eben auch. Im
Besonderen, wenn diese Funktion keine wesentlichen Zusatzkosten
verursacht.
Man kann natuerlich aus jeder Fliege einen Elefanten machen.
Andere sagen dann eher: so ein Fehler juckt mich nicht.
Aber das unterscheidet eben den schlechten vom guten Entwickler.
Solche "Stuck-at" werden von einer Gatterloesung in ein permanentes
"Dunkel" oder ein "viel heller" als normal uebersetzt. Bei der
Haeufigkeit mit der solche Fehler auftreten, voellig hinreichend.
Ich wuerde dich uebrigens fuer einen schlechten Entwickler halten.
In der Industrie wuerde ein Produktmanager, der den Sinn von einer
Entwicklung die solche seltenen Fehler erkennt, und kritisch
hinterfragt, mir wohl recht geben. Funktionieren kann sie auch nur
mit a-priori Wissen bzgl. des verwendeten hoeheren Protokolls.
Generisch ist sie schlicht nicht realisierbar.
Der BWLer wuerde bei der Kritik sicher auch fleissig nicken, wird
das Produkt durch solchen "Schnick-Schnack" und den dafuer noetigen
Entwicklungsaufwand teurer.
Es waere die Aufgabe des auf dem Empfaenger laufenden Systems, solche
Timeouts in der Kommunikation zu erkennen, und adaequat zu reagieren.
Das darf dann durchaus auch eine blinkende LED auf einer Frontplatte
sein.
Bei einem simplen Linemonitor hat sie schlichtweg nichts zu suchen.
Es waere die Aufgabe des auf dem Empfaenger laufenden Systems, solche
Timeouts in der Kommunikation zu erkennen, und adaequat zu reagieren.
Du hast grade dem Jan die Kosten optimiert und seine komplette Blinkschaltung wegrationalisiert. Denn natürlich braucht er diese Überwachungsschaltung im Grunde überhaupt nicht, weil ja der jeweilige Empfänger das Ausbleiben einer erwarteten Übertragung signalisieren kann.
Der Vorwiderstand hier sollte eigentlich im Kollektor- und nicht
Emitterpfad sein ...
Der Anfänger setzt den Vorwiderstand gerne zur LED am Kollektor, der Fortgeschrittene setzt ihn zum Emitter um eine Gegenkopplung zu erreichen. Dadurch wird der Eingangswiderstand der Transistorschaltung deutlich erhöht und damit das RxTx-Signal weniger belastet.
Einen habe ich noch! Man kann ein Monoflop durch das asymetrische umladen der Millerkapazität des Transistor erreichen. Dieser Kondensator ist im Transistor bereits vorhanden und muss nicht als Bauteil eingefügt werden.
Im Bild zeigt die blaue Linie die Low-Eingangsimpulse mit einer Breite von 1µs. Die rote Linie zeigt den Strom durch die LED. Im Beispiel beträgt die Leuchtdauer der LED cirka 4µs je Impuls. Damit wird die Leuchtdauer vervierfacht.
Wurde das mit einer einfachen Treiberstufe schon ausprobiert? Wenn die LED hell genug ist, leuchtet sie ja optisch noch ein Stückchen auf der Netzhaut nach...
Die funktioniert aber bei 5V nur dann sinnvoll, wenn für den Widerstand R1 auch noch ausreichend viel Spannung übrig bleibt und das ist hier nicht der Fall. Kurz: für eine funktionierende KSQ felt ein sinnvoller Bezugspunkt für die Basis. Üblicherweise sind da dann mindestens 2 Dioden zwischen E und B.
(...) Üblicherweise sind da dann mindestens 2
Dioden zwischen E und B.
Oder der Portpin eines Microcontrollers. Das wäre dann eine Standard-Schaltung: High-Pegel sind 3,3 V, minus Vbe gibt 2,6 V am Emitter. Geteilt durch den Wert des Emitterwiderstandes gibt den Emitterstrom, der in guter Näherung identisch zum Kollektorstrom durch die LED ist.
In PNP ist halt alles von der Polarität her umgekehrt.
Oder der Portpin eines Microcontrollers. Das wäre dann eine
Standard-Schaltung: High-Pegel sind 3,3 V, minus Vbe gibt 2,6 V am
Emitter.
Das stimmt so nicht, weil der Basisstrom durch den zumehmenden Spannungsabfall am R1 eben nicht niedriger wird, sondern einfach nur die Basisspannung immer um 0,6V negativer ist als die Emitterspannung.
Den Effekt kann man bei 3V3 Versorgung nur schlecht beobachten, weil ja die LED schon sehr viel der 3V3 "wegnimmt". Aber bei 5V ist es leicht zu sehen: die Basis muss für eine KSQ auf eine halbwegs definierte Basis-Spannung "geklemmt" werden. Nur dann stellt sich der gewünschte Konstantstrom ein, der auch "ziemlich" unabhängig ist von z.B. dem Stromverstärkungsfaktor hfe des Transistors.
