Hello, Guest the thread was called1.7k times and contains 26 replays

last post from Ruudi at the

ESP-12 Rx/Tx anderweitig nutzen

    Das Entprellen mache ich mit Software. Ein schöner Codeschnipsel ist mir über den Weg gelaufen, mit Modis für den Taster (kurzer Klick, Langklick, Doppelklick usw.). Die Entprellroutine war auch gleich dabei und scheint soweit zu funzen.


    Die 20mA sind ja Obergrenze, soviel werde ich sicher nicht verbraten. Die LEDs welche ich gerade habe kommen ab 8mA aus. Low-current's hab ich keine da. Zudem werden die nicht permanent bestrahlen, nur kurz die Activity signalisieren.


    MOSFETs habe ich genug, natürlich für 3V3 LL mit sehr niedrigem Vth. Hier habe ich mit Absicht ein paar herausgekramt mit höherem RDSon. A) um sie endlich zu verbauen, b) in der LED Leitung juckt es nicht.

    Sollten sie nicht komplett öffnen, nehme ich einfach die "Guten" :) Ebenso auf den Workern, welche batteriebetrieben sind, dort fällt die Vcc auch gerne mal runter auf 2.8V. Dann kommt der Supervisior und legt alles still.


    Bzgl. der Flackerei, wo sollte ich die Glättung reinlegen? Parallel zur LED? Oder gar in Serie?


    Das wird schon. Nachbessern kann man immer noch :)

    Bin echt froh mit den bescheuerten LEDs durch zu sein.

    Glättung: Gatewiderstand erhöhen und parallel zw. Gate und Source (Masse) einen Kondensator (am besten keramisch, darf keinesfalls Leckströme haben, also kein Elko oder Tantal..). Dann reagiert der FET deutlich träger und somit wird das kurzzeitige Ausschalten des Hi-Pegels zur Tastenabfrage nicht mehr sichtbar...

    Die genaue RC Kombination kannst DU über die Zeitkonstante ja dann festlegen. Sollte größer sein als Deine Pausenzeit zum Einlesen des Tasters...


    Sehe grad: Dein Pullup ist aber EXTREM kontraproduktiv, zumindest, wenn ein FET eingesetzt werden soll! Dann müsstest Du via I/O aktiv auf Masse schalten, wenn die LED ausgehen soll, bei Umschaltung auf Eingang würde sie angehen, wenn auch möglicherweise gedimmt (je nach FET und dessen Vth, resp. Temperatur und Exemplarstreuung...)


    Und das auf Masse ziehen willst Du doch eigentlich vermeiden, oder habe ich das immer noch nicht richtig verstanden?

    Quote from Ruudi

    Sehe grad: Dein Pullup ist aber EXTREM kontraproduktiv, zumindest, wenn ein FET eingesetzt werden soll!

    Shit, das ist mir im Gefecht total entgangen.

    Na dann lasse ich den NPN drinnen. Vielleicht spiele ich noch bischen mit den Werten bis es ohne passt.


    Da ich gerade Ferien habe, komme ich nicht an den Oszi heran. und mein kleiner China-DSO zeigt mehr Müll als...


    Quote from Ruudi

    Und das auf Masse ziehen willst Du doch eigentlich vermeiden, oder habe ich das immer noch nicht richtig verstanden?

    Der Pullup muss leider sein. Bei starten/aufwachen braucht er unbedingt ein definiertes high, sonst fährt er in den falschen Modus und wartet auf Daten zum flashen :) Zumindest den IO0 betreffend.

    Ich kann echt nicht mehr klar denken, totales overflow.

    Sei mir nicht böse.

    Könntest du es bitte, es aus deiner Sicht, skizzieren?


    Anforderung:

    - Die beiden GPIOs müssen ein definiertes high haben (4k7-10k)

    - Eine LED und ein Taster per GPIO, mit output angesteuert bzw. input eingelesen

    - Transistor oder MOSFET falls nötig

    - Die LED etwas geglättet, Taster können/müssen nicht entprellt werden


    Bin echt am rotieren. Danke dir.



    Also:


    an "Sig-IO" hängst Du Deinen GPIO.


    Über Vorwiderstand R2 fliesst von der pos. Versorgung (3V3) ein Strom durch die LED, sobald Du den GPIO auf Ausgang und auf "Low" oder "0" umstellst.

    Über die Reihenschaltung von R3, R2 und R1 ist beim Einschalten und im Zustand "Eingang" sichergestellt, dass der Ruhepegel "High" ist.


    Wenn an Sig-IO ein GPIO im Modus "Eingang" hängt, dann ist dieser hochohmig, d.h. sieht High-Pegel, durch die LED fliesst aber kaum Strom und diese leuchtet somit NICHT. (Chip-Eingänge sind üblicherweise hochohmig, Ausnahmen gibts für extrem schnelle und/oder differenzielle Eingänge...)


    Wenn der Taster gedrückt wird, geht die LED an UND am GPIO liegt ein "Low"-Pegel an, wenn dieser auf Eingang gestellt ist. Ist dieser auf Ausgang und Pegel "High" gestellt (LED aus), sorgt R3 für eine Strombegrenzung, solange S1 gedrückt wird. R3 kann höher gewählt werden, dafür dann R2 niedriger, in Summe stellen R2 und R3 den Betriebsstrom der LED ein.


    R3 könnte sogar entfallen (durch Leiterbahnstück ersetzt), wenn via Software sichergestellt wird, dass NIE ein aktiver "High"-Pegel am als Ausgang geschalteten GPIO anliegt. (der Eingangspegel ist davon unberührt, s.o.!)


    Die Werte für R2 und R3 gehören natürlich an die jeweilige LED und gewünschte LED-Helligkeit angepasst!



    N.B.1: Für andere Anwendungen möglicherweise mal wichtig, hier bei nur 2 GPIO und 2 LED hingegen nicht:


    Zusätzlich zu der Fähigkeit jedes einzelnen I/O genügend Strom für eine LED zu liefern (source) oder gg. GND abzuführen (sink), muss das auch für den ganzen Chip gelten, es gibt dort für Versorgung und insb. GND-Anschluss ebenso einen Maximalwert, wie viel Strom in Summe fliessen darf. Davon ist der Eigenverbrauch des Chips noch abzuziehen, meist reicht es für 8 Low-Power-LEDs oder 5 normale LEDs, die GLEICHZEITIG aktiv sein dürfen.


    N.B.2: parallel zu S1 könnte noch eine weitere LED ergänzt werden, welche leuchtet, wenn an Sig-IO ein Ausgang mit Pegel "High" angeschlossen ist. dennoch wäre man in der Lage, noch den Schalter abzufragen und kann im Wechsel beide LEDs betreiben und bei 3V3 als Versorgung sogar auch beide ausschalten (über Umschaltung Sig-IO auf Input), da die 3V3 Versorgung nicht für 2 LEDs in Serie ausreicht (ok, bei roten LEDs mit niediger Vf könnts eng werden, sprich die LED zumindest etwas glimmen, bei grün, gelb oder gar weiß oder blau gehts aber problemlos. Bei Rot noch je eine 1N4148 in Serie zur LED, dann klappts auch da sicher...)

    Danke Ruudi


    Das entspricht ja fast haargenau meinem ersten Aufbau. Ja, das hat in der Tat und auf Anhieb funktioniert. Nur mit einem kleinen Nebeneffekt - einer leuchtenden LED beim gedrückten Taster. Genau dies versuchte ich zu fixen. Daher die lange Diskussion.

    Ich werde deinen Vorschlag heute Nacht oder morgen so aufbauen.


    Nun hänge ich nochmal meine Skizzen an. Zum besseren Verständnis und Unterscheidung sind nun die Designatoren eingetragen. Die 4 einzelnen Aufbauten getrennt. Ein paar zusätzliche Kommentare eingefügt.


    Kurz zum Ablauf:

    1a) Häckchen dran, funktioniert. Nebeneffekt eine leuchtende LED.

    1b) Versuch das ganze umgedreht. Hat mit einer MCU funktioniert, mit der zweiten nicht.

    1c) Um das Nebenleuchten weg zu bekommen den R1 stark vergrößert. Dann schrittweise auch R2 erhöht (bis knapp unter dem Pullup-Wert). Keine Ahnung was ich da wirklich vor hatte :)

    2) Aus 1a die NPN Version aufgebaut. Die funktionierte auf beiden MCUs.

    2a) Theorie den NPN durch N-Ch zu ersetzen.


    So jetzt muss ich weg, der Sonntag gehört der Familie. Ich komme aber wieder :)


    PS: Mir ist klar ohne Simulationssoftware ist und bleibt es herumtappen in der Dunkelheit. Das muss ich mir noch angewöhnen bzw. beibringen.

    Ich wünsche euch was...

    Quote from mratix

    Mir ist klar ohne Simulationssoftware ist und bleibt es herumtappen in der Dunkelheit. Das muss ich mir noch angewöhnen bzw. beibringen.

    Nö, genau andersrum: mit Simulationssoftware wirst Du NIE ein Gefühl dafür bekommen, die Simulation muss im KOPF laufen, den hat man immer dabei ;-)


    Wenn Du das Leuchten der LED beim Betätigen des Schalters verhindern willst (wozu eigentlich? Its not a bug, its a feature, wie ich viel weiter oben schon schrieb), dann musst Du entweder mit Öffnerkontakten (und umgekehrter Logik) arbeiten, oder aber mit min. 2-3 FETs die LED immer dann vom Pin entkoppeln, wenn der Taster gedrückt wird, dabei aber auch den Taster selbst entkoppeln, sonst wirds ne Selbsthalteschaltung...