Hallo Gemeinde, 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.. Danke!
Jan schrieb: > 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.
Jan schrieb: > Jetzt die Frage, kennt da jemand eine kleinere Lösung mit ggfs weniger > Bauteilen (ohne direkt einen uC einzusetzen)? Nimm ein Single Gate Monoflop SN74LVC1G123. Aber ein 6-Pin Attiny10 wäre tatsächlich noch kleiner und bräuchte nur den LED-Widerstand.
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.
:
Bearbeitet durch User
Jan schrieb: > und > Platinenfläche für die Programmierpins braucht es auch. Nein, es gibt Adapter die man direkt auf den Chip setzen kann. z.b. hier zu sehen: https://www.ebay.de/itm/374924361857
:
Bearbeitet durch User
Jan schrieb: > Platinenfläche für die Programmierpins braucht es auch. Ein Steckbrett tut es auch zum Programmieren.
Monk schrieb: > Ein Steckbrett tut es auch zum Programmieren. Wir lassen solche Dinger, die überall drauf und immer gleich sind, vorprogrammiert bestücken.
Arduino F. schrieb: > Jan schrieb: >> und >> Platinenfläche für die Programmierpins braucht es auch. > > Nein, es gibt Adapter die man direkt auf den Chip setzen kann. > z.b. hier zu sehen: https://www.ebay.de/itm/374924361857 Die Idee mit dem Clip gefällt mir.. Lothar M. schrieb: > Monk schrieb: >> Ein Steckbrett tut es auch zum Programmieren. > > Wir lassen solche Dinger, die überall drauf und immer gleich sind, > vorprogrammiert bestücken. Ja, aber das ist nicht so ganz die Kragenweite über die wir hier reden :)
Angehängte Dateien:
-
T402_16x13mm.jpg
130 KB
Blink without Delay, without KiCad, without JLCPCB, without DHL...
Jan schrieb: > 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.
Motopick schrieb: > Der Rest der "Ideen" hier ist Moppelkotze 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.
Lothar M. schrieb: >> 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. 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.
Motopick schrieb: > Da bist du wohl nicht ganz im Bilde. 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.
Lothar M. schrieb: > Motopick schrieb: >> Da bist du wohl nicht ganz im Bilde. > 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.
:
Bearbeitet durch User
Lothar M. schrieb: > Aber ein 6-Pin Attiny10 wäre tatsächlich noch kleiner und bräuchte nur > den LED-Widerstand. Habe ich als Test schon wochenlang ohne Widerstand blinken lassen. Weder Led noch Tiny10 gingen kaputt. Außerdem gibt es auch LEDs mit Widerstand.
Beitrag #7695614 wurde vom Autor gelöscht.
Jörg R. schrieb im Beitrag #7695614:
> 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.
Motopick schrieb: > Mit geuebtem Auge kann man sogar die Baudrate abschaetzen. Dazu müsstest du schon ungewöhnlich langsam übertragen. Schon bei 600Bd (max 300Hz Blinken) wird das sehr sportlich.
Chuck Norris kann einzelne Bitfehler bei 115200 Baud aus dem Augenwinkel heraus erkennen. Motopick kann das bei geschlossenen Augen.
Motopick schrieb: > Und wie soll das ein "Blinki-Blinki" detektieren? 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. Veit D. schrieb: > jeweils an Tx Rx einen OPV Impedanzfolger, effiziente LED ran, fertig. Da sollte man dann aber einen halbwegs schnellen OPV nehmen... Bruno V. schrieb: > Das siehst Du noch blitzen Aber eben nur ganz, ganz, ganz kurz. Viel, viel kürzer als ein Wimpernschlag dauert. Frank O. schrieb: > 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.
Motopick schrieb: > Mit geuebtem Auge kann man sogar die Baudrate abschaetzen. Inzwischen gibt es etwas schnellere Übertragungen als Teletype o.ä. Dann wird es sicher auch für dein schnelles geübtes Auge schwierig. Lothar M. schrieb: > Motopick schrieb: >> Der Rest der "Ideen" hier ist Moppelkotze > > Ja, Leute mit so einem Tonfall am Leib nimmt man dann auch gleich voll > ernst. Lothar, er kann nicht besser. Das beweist er immer wieder ;)
Lothar M. schrieb: > 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.
Lothar M. schrieb: > Also einfach ein flankengetriggertes Monoflop > und fertig. Lothar M. schrieb: > 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.
Dietrich L. schrieb: > Warum dann nicht eine Luxus-Lösung mit 2 LEDs 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.
Frank O. schrieb: > Weder Led noch Tiny10 gingen kaputt. Frank O. schrieb: > möglichst wenig Gewicht Tipp: Es gibt SMD Widerstände. Sonderlich schwer sind die nicht. Lothar M. schrieb: > 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.
Angehängte Dateien:
-
RxTxLED.png
15 KB
Hallo Jan. 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. Im Bild ist ein Beispiel mit Transistor. Gruß. Tom
Arduino F. schrieb: > 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. Viel Erfolg. Tom
Tom A. schrieb: > muss die Anzeigedauer verlängert werden Das war eigentlich von Anfang an eine der grundlegenden Anforderungen an die Schaltung, denn Jan schrieb: >>>> die Blinkpulse zu verlängern
Das ist schon klar, aber vielleicht genügt es ja die LED heller zu machen um die Signale zu erkennen. Wirklich wissen kann das nur Jan, indem er es ausprobiert. Gruß. Tom
Lothar M. schrieb: > Veit D. schrieb: >> 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
Monk schrieb: > 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.
:
Bearbeitet durch User
Frank O. schrieb: > Habe ich als Test schon wochenlang ohne Widerstand blinken lassen. Dann behalte das bitte für dich und verbreite das nicht noch hier im Forum. Mit so einem Konstrukt bist du abhängig von Toleranzen der Versorgungsspannung und Temperatur der LED, nur um einen Widerstand für 3ct zu sparen.
Gregor J. schrieb: > Hängt aber auch von einigen Faktoren ab, z.B. der Siliziumfertigung ab, > wieviel tatsächlich fließen wird. Und noch von wesentlich lokaleren Faktoren wie der Versorgungsspannung und der Temperatur und der Position des Pintreibers auf dem konkreten Die. Bruno V. schrieb: > 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.
Angehängte Dateien:
-
RxTxLED.png
15 KB
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.
Lothar M. schrieb: > Motopick schrieb: >> Da bist du wohl nicht ganz im Bilde. > Nein, ich bin dir gedanklich einfach nur einen Schritt voraus (und > offenbar mindestens 2 andere auch). Im uc.net steht man immer vor dem Abgrund. Und manche sind da schon einen Schritt weiter. :) Insbesondere wenn dann noch: Lothar M. schrieb: > Frank O. schrieb: >> 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.
Motopick schrieb: > Nein, solche Fehler kenne ich nicht. Offenbar eine Bildungslücke, denn es gibt sogar Fachbegriffe für solche Fehler. Ich habe sie erwähnt: - https://www.google.com/search?q=signal+stuck+high+low > Im uc.net steht man immer vor dem Abgrund. Und manche sind da schon > einen Schritt weiter. Nur interessehalber: wie ist die Aussicht dort unten?
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Motopick schrieb: >> Nein, solche Fehler kenne ich nicht. > Offenbar eine Bildungslücke, denn es gibt sogar Fachbegriffe für solche > Fehler. Ich habe sie erwähnt: > - https://www.google.com/search?q=signal+stuck+high+low Danke fuer die Nachhuelfe, aber "Stuck-at" Fehler sind mir durchaus gelaeufig. Man kann natuerlich aus jeder Fliege einen Elefanten machen. >> Im uc.net steht man immer vor dem Abgrund. Und manche sind da schon >> einen Schritt weiter. > Nur interessehalber: wie ist die Aussicht dort unten? Die Aussicht ist hier oben immer ganz vorzueglich.
Lothar M. schrieb: > Ich beobachte sie im Dunkel und die "blitzt" > sicher länger auf als die 100µs, die eine LED bei 115kBd aufblitzt. 100 µs? Es sind etwa 8.7 µs pro Bit. Und wie viele Bits die LED zum Leuchten bringen, hängt von den Nutzdaten ab. Wird beispielsweise 0xff gesendet, und gibt es kein Paritätsbit, dann wird man nur das Startbit sehen.
Harald K. schrieb: > 100 µs? Es sind etwa 8.7 µs pro Bit 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. Motopick schrieb: > Danke fuer die Nachhuelfe, Keine Ursache. > "Stuck-at" Fehler sind mir durchaus gelaeufig. 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.
:
Bearbeitet durch Moderator
Lothar M. schrieb: >> 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.
Bruno V. schrieb: > Stuck-At wird ja auch vom naiven Ansatz sofort gemeldet: Es ist ohne > jedes Flackern und ohne jeden Einbruch AN. Bei "stuck at low" **und** bei "stuck at high"? Motopick schrieb: >> 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.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Harald K. schrieb: >> 100 µs? Es sind etwa 8.7 µs pro Bit > 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. > > Motopick schrieb: >> Danke fuer die Nachhuelfe, > Keine Ursache. > >> "Stuck-at" Fehler sind mir durchaus gelaeufig. > 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.
P.S.: 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. Das zu erkennen, macht den guten Entwickler aus.
Motopick schrieb: > 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. Motopick schrieb: > Ich wuerde dich uebrigens fuer einen schlechten Entwickler halten. Das wäre mir übrigens egal. Aber ich flegle wenigstens meine Mitmenschen nicht unflätig an.
Lothar M. schrieb: > Das wäre mir übrigens egal. > Aber ich flegle wenigstens meine Mitmenschen nicht unflätig an. Deine Meinung ueber mich ist mir uebrigens auch egal. Flegeln gehoert hier zum Handwerk. Aber schlecht bleibt trotzdem schlecht. Das kann man meinungsinvariant so feststellen. > Denn natürlich braucht er diese > Überwachungsschaltung im Grunde überhaupt nicht Du hast den tieferen Sinn eines "Linemonitors" nicht verstanden.
:
Bearbeitet durch User
Hallo Gregor J. Gregor J. schrieb: > 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. Tom
Angehängte Dateien:
-
MillerFlop.png
26 KB
Hallo Jan. 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. Tom
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...
Gregor J. schrieb: > Der Vorwiderstand hier sollte eigentlich im Kollektor- und nicht > Emitterpfad sein Du hast das Prinzip der Schaltung nicht verstanden. Es handelt sich um eine Konstantstromquelle. Die Stromregelung erfolgt durch den Transistor.
:
Bearbeitet durch User
Rainer W. schrieb: > Es handelt sich um eine Konstantstromquelle 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.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > (...) Ü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.
:
Bearbeitet durch User
Danke, das war ne Menge Input, und zwischenzeitlich sogar sehr sinnvolles dabei :) Zur Anwendung: Es geht um Baudraten von 6k4 - 250k. Aktuell tendiere ich dann doch zum Tiny, das scheint mir aktuell die flexibelste Lösung zu sein (die Teile sind "eh da"..) Danke nochmal!
Angehängte Dateien:
Soul E. schrieb: > 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. Jan schrieb: > (die Teile sind "eh da"..) Und eben auch das Knowhow.
:
Bearbeitet durch Moderator
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.