Hallo zusammen, ich möchte Temperaturwerte von einem Feuchtigkeitssensor über einen MSP430 auslesen. Der DHT12 Sensor lässt sich über einen MCP2221-Adaper einwandfrei auslesen: > I2C Write, Address = 5C, Data: 00 Delay = 0 OK > I2C Read, Address = 5C, Read 5 bytes, Delay = 0 OK < 29 09 1B 07 54 Erklärung: 29h 09h = 41,9% 1Bh 07h = 27,7°C 54 CRC Ich habe einen DHT12 Sensor an die Pins 1.6, 1.7, Vcc und Gnd an den Launchpad MSP-EXP430G2 angeschlossen. Die Spannung beträgt 3.5V. I2C Frequenz ca. 85 bis 100 KHz. Compiler ist IAR 6.4. Lese ich nun den DHT12 Sensor über den Launchpad aus, dann bekomme ich zunächst keine Antwort. Siehe Bild FehlerNACK.jpg. Debugge ich den Code (siehe main.c) mehrfach langsam durch dann funzt alles; und zwar ab dann immer! (siehe Bild Ohne Fehler.jpg, main.c) Initialisierung fehlerhaft? Welchen Denkfehler begehe ich? Dank in voraus!
Angehängte Dateien:
-
FehlerNACK.jpg
21 KB -
OhneFehler.jpg
41 KB
Vor/während Initialisierung des I2C-Interfaces irgendwelche undefinierten Zustände. Abhilfe: https://www.st.com/resource/en/application_note/cd00004295.pdf
Soll das heissen ich soll das Interface des MSP430 mehrfach initialisieren? Oder soll ich auf das NACK reagieren? Aber wie soll denn das funzen?
Andreas V. schrieb: > Soll das heissen ich soll das Interface des MSP430 mehrfach > initialisieren? Oder soll ich auf das NACK reagieren? Aber wie soll denn > das funzen? Nein, dass heißt nur, dass es sich empfiehlt, bei einem Fehler oder (einfach auf Verdacht) bei der Initialisierung (egal woher/warum), diese Sequenz (manuell ...) durchzuführen. Beim Controller legt man doch auch ein Reset an. Da die I2C-Chips i. d. R. keinen Reset-Pin haben, muss man es halt irgendwie anders machen.
Was für Pullup Widerstände sind an SCL und SDA bestückt?
Joe F. schrieb: > Was für Pullup Widerstände sind an SCL und SDA bestückt? Anfangs hatte ich 1k Widerstände drinnen. Momentan sind 10k Widerstände beschaltet.
Warum auf 10K geändert? 2.2K ist Standard. Bei 100Khz und 3.5V dürften auch noch 4.7K gehen, aber 10K würde ich nicht machen.
Joe F. schrieb: > Warum auf 10K geändert? Mit 1k funzte die Initialisierung nicht. Da änderte ich die Pullups auf 10k, weil ich davon ausging dass 1k vieleicht etwas zu klein sein könnten und die Belastung zu gross wird. Ich wollte nur auf Nummer sicher gehen. Ergebnis: keine Änderung! Zwischen 1k und 100k sollte bei der Geschwindigkeit von 100kbit doch alles funktionieren... Ein Veruch mit 2.2k (Standard? Bei Low Power?) ist es in jedem Fall wert.
Andreas V. schrieb: > 100k auf keinen Fall. Um sicher zu gehen: Signale mit dem Oszilloskop angucken. Wenn die zu "rund" werden, ists nicht gut. Der Logic-Analyzer ist hierfür kein geeignetes Maß. Er kann eine niedrigere Threshold haben als I2C master oder slave.
:
Bearbeitet durch User
Auch ist das Timing deines I2C Masters schlecht. SDA und SCL sollten sich nicht gleichzeitig ändern. Hier besteht die Gefahr, dass ungewollte start/stopp Konditionen "erkannt" werden. Bei der Interpretation solcher grenzwertigen Zustände können sich I2C-Slave und Analyzer durchaus unterscheiden. Sniffe mal mit, wie die es mit dem MCP2221 aussieht, evtl. ist da einfach das Timing besser (SCL=low, SDA wird geändert, SCL geht high, SCL geht wieder low, und erst dann wird SDA wieder geändert). http://i2c.info/i2c-bus-specification
:
Bearbeitet durch User
Angehängte Dateien:
-
Oszi.jpg
38 KB
Joe F. schrieb: > Um sicher zu gehen: Signale mit dem Oszilloskop angucken. > Wenn die zu "rund" werden, ists nicht gut. Der Logic-Analyzer ist > hierfür kein geeignetes Maß. Er kann eine niedrigere Threshold haben als > I2C master oder slave. Ich hab es mal mit dem Oszi nachgemessen! Das Diagramm sieht doch ziemlich rund aus...
Sieht aber noch relativ gut aus. Ich vermute eher, dass es die gleichzeitig fallenden Flanken von SDA und SCL sind. Wenn der Slave SDA nur geringfügig früher fallen sieht, detektiert er eine repeated-start condition.
Angehängte Dateien:
-
Oszi3.jpg
38 KB
Ich habe den Client resetted und dann funzt es mit der Ausgabe Oszi3.jpg. Ob das jetzt immer so funktioniert....
Angehängte Dateien:
-
Oszi4.jpg
38 KB
Was mir auffällt ist der Peak am Ende des Signals...
:
Bearbeitet durch User
Andreas V. schrieb: > Ich habe den Client resetted und dann funzt es mit der Ausgabe > Oszi3.jpg. > Ob das jetzt immer so funktioniert.... Nur bei Vollmond und Windstille. Miss doch mal mit dem MCP2221, wie die Signal da aussehen. Die gleichzeitig fallenden Flanken, du weisst schon... Andreas V. schrieb: > Was mir auffällt ist der Peak am Ende des Signals... Das ist eine kurze tri-state Phase auf dem Bus (durch den Pullup in Richtung high gezogen), wenn der Master die Leitung für das ACK freigibt, und der Slave die 0 noch nicht angelegt hat.
:
Bearbeitet durch User
Bis zu 3x wiederhole ich mich, aber nicht öfter: gleichzeitig fallende Flanken.
Joe F. schrieb: > gleichzeitig fallende Flanken. Aber was mache ich dagegen? Da wo der Peak auftritt wird das Signal manchmal high und dann bekomme ich einen NACK statt ACK. Vergleich Oszi4.jpg und Oszi5.jpg. Bei NACK bleibt der µC hängen.
Angehängte Dateien:
-
Oszi6_MCP2221Bridge.jpg
39 KB
Joe F. schrieb: > Nur bei Vollmond und Windstille. > Miss doch mal mit dem MCP2221, wie die Signal da aussehen. > Die gleichzeitig fallenden Flanken, du weisst schon... Mit dem MCP2221 sieht das Bild jetzt erst mal fast identisch aus. Nur ist das Signal an der Stelle des Peaks Low! Ich vermute mal das ist ein Schwingquarz/Kreis Problem (Toleranzen)...
Andreas V. schrieb: > Aber was mache ich dagegen? SDA nur ändern, während CLK low ist. Und messen, ob das der Grund ist (Vergleichsmessung mit MCP2221, da funktioniert es ja einwandfrei). Andreas V. schrieb: > Da wo der Peak auftritt wird das Signal manchmal high und dann bekomme > ich einen NACK statt ACK. Ja. Der Slave hat die Adresse nicht richtig mitbekommen und ACKt nicht. > Vergleich Oszi4.jpg und Oszi5.jpg. > > Bei NACK bleibt der µC hängen. Das kann man ja ändern (timeout, retry...)
:
Bearbeitet durch User
Hallo Andreas! Erstens: Vergiß bitte das Geschwafel von Joe F bzgl. der fallenden Flanken - das ist gem. I2C-Spec. zulässig und das Thema somit erledigt. Hinsichtlich Pullups: Wenn ich das Datenblatt auf die Schnelle richtig gelesen habe, hat der Sensor schon 4k7-Pullups drin. Da der MSP430 nicht mehr als 100kHz bei I2C kann (warum auch immer so wenig), sind auch schon 10kOhm ok - aber achte darauf, daß Dir dein Oszi-Kabel nicht unnötig hohe Kapazitäten einbringt; sofern Du mit 15pF-Tastkopf arbeitest, sollte das aber kein Problem sein). Der Spike, den Du am Ende des Signal siehst, entsteht durch die Reaktionszeit des Sensors, d.h. er zieht für ACK den SDA-Pin auf Masse, sobald SCL=0 ist - das ergibt dann halt ein paar 100ns, in denen durch den Pull-up die SDA-Spannung etwas ansteigt. Bzgl. schrittweisem Debuggen: Die IAR Workbench hat, sobald Du den Debugger startest, einen Menüpunkt "Emulator->Advanced->Clock Control". Beim schrittweisen Debuggen kann es also sein, daß die Clocks Stück für Stück abgearbeitet werden und Du somit ein Timing-Problem nicht erkennen kannst - schau Dir die Einstellungen dazu an. Was sind übrigens die Variablen "IFG2" und "IE2"? Ich kann's mir zwar denken, aber gehört da nicht UCB0IFG und UCB0IE hin? Beim Empfangen solltest Du außerdem das RXIFG-Flag löschen. Nach dem Senden des Adreßbytes schickst du außerdem jedesmal eine Stop-Bedingung hinterher - das solltest Du aus der ISR-Routine herausnehmen und Stop bzw. Repeated Start im Hauptprogramm ausführen lassen. Bzgl. Deiner ISR-Routine: Die scheint nur für TX-Flags zu sein, oder? Ich bin mir da nicht sicher, weil meine Anwendungen meist in Assembler geschrieben sind. Du sollest außerdem das Lesen nicht byteweise organisieren, sondern einfach ein Array machen und einen rxByteCnt hinaufzählen lassen. Das Ende wird ja ohnehin durch das NACK vom Sensor angezeigt. Ein paar stilistische Anmerkungen: * Bitte die einleitenden geschweifte Klammer in eine separate Zeile geben - das sieht ordentlicher aus. * Benutze für Variablen am besten lowerCamelCase - Du vermischt aktuell die typischen großgeschriebenen Konstanten mit großgeschriebenen Variablen. Beispiel TXByteCtr => txByteCnt (ich bevorzuge Cnt statt Ctr für Counter).
Jürgen W. schrieb: > Erstens: Vergiß bitte das Geschwafel von Joe F bzgl. der fallenden > Flanken - das ist gem. I2C-Spec. zulässig und das Thema somit erledigt. Sorry, aber deine Ausdrucksweise ist vollkommen unangemessen. Zeige mir, wo die Spec. sagt, dass das zulässig ist. Ich zeige dir das Gegenteil: I2C Spec: https://www.nxp.com/docs/en/user-guide/UM10204.pdf
1 | 3.2.3: |
2 | Data validity |
3 | The data on the USDA line must be stable during the HIGH period of the clock. The HIGH or LOW state of the data line can only change when the clock signal on the USCL line is LOW (see Figure 23). One clock pulse is generated for each data bit transferred. |
Wenn du dir Fig 24. anguckst, siehst du warum es eine schlechte Idee ist beide Flanken "gleichzeitig" fallen zu lassen. Wenn aufgrund von parasitären Kapazitäten SCL auch nur einen Ticken langsamer fällt, entsteht hier unbeabsichtigt eine START condition. Bie Fast-Mode slaves reichen hier bereits 0.6us um das Kriterium einer repeated START condition zu erfüllen (Table 10, tSU;STA). Bei tHD;DAT steht für I2C-bus devices zwar 0, aber Anmerkung [3] sagt:
1 | A device must internally provide a hold time of at least 300 ns for the SDA signal (with respect to the VIH(min) of the SCL signal) to bridge the undefined region of the falling edge of SCL. |
D.h. die interne hold time reicht u.U. gerade mal für 300ns. Wenn SCL also mehr als 300 ns ggü. SDA verzögert ist kommt man schon in einen kritischen Bereich. Ich spreche diese Thema deswegen an, weil es eben nicht einfach nur auf meinem Mist gewachsen ist. Ich hatte genau diese Probleme schon zig mal in der Praxis. Das traurige ist, dass sehr viele I2C Libraries für uCs genau diesen Mist machen (gleichzeitig fallende Flanken), und massenhaft Leute dann rumweinen, weil es nicht funktioniert. Meine Theorie ist, dass genau dadurch auch der schlechte Ruf von I2C herrührt. Mistige Master-Implementierungen.
:
Bearbeitet durch User
Joe F. schrieb: > Das traurige ist, dass sehr viele I2C Libraries für uCs genau diesen > Mist machen Der 'G2453 macht I2C in Hardware, mit der USCI_B0. Das wird auch von der vorliegenden Software genutzt. Das aber wiederum würde bedeuten, daß die Hardwareimplementierung von TI hier fehlerhaft ist. Hmm.
Rufus Τ. F. schrieb: > Das aber wiederum würde bedeuten, daß die Hardwareimplementierung von TI > hier fehlerhaft ist. Es heisst zumindest, dass die Hardwareimplementierung von TI schlecht ist (tHD,DAT=0ns). I2C slaves, die intern eine hold-time implementiert haben, werden bei optimalem PCB Layout funktionieren. Mit parasitären Kapazitäten auf SCL wird es da schnell kritisch. Und das möchte man eigentlich nicht haben. SMBus slaves sind dadurch ebenfalls nicht ansprechbar. Wenn ich mal 2 beliebige Datenblätter von Maxim rausfische: https://datasheets.maximintegrated.com/en/ds/MAX31629.pdf https://datasheets.maximintegrated.com/en/ds/MAX7367-MAX7369.pdf Dort steht in der Tabelle bei tHD;DAT zwar jeweils 0us, in der Anmerkung 4 jedoch: "A master device must provide a hold time of at least 300ns for the SDA signal (referred to the VIL of the SCL) in order to bridge the undefined region of SCL’s falling edge." Das verstehe ich so, dass der Master die 300ns einhalten muss. Meine Erfahrungen aus der Praxis bestätigen dies. Das Diagramm zum verwendeten Sensor DHT12 macht keine Angaben zu tHD;DAT, allerdings legen die Diagramme nahe, dass die Flanken NICHT synchron fallen sollen. http://www.robototehnika.ru/file/DHT12.pdf
:
Bearbeitet durch User
Hallo Jürgen, Dein Post hat es in sich! Dafür brauchte ich Zeit. Jürgen W. schrieb: > Erstens: Vergiß bitte das Geschwafel von Joe F bzgl. der fallenden > Flanken - das ist gem. I2C-Spec. zulässig und das Thema somit erledigt. Es ist heiss. Bleibt alle cool! Aber ob Spezikikations konform oder nicht: Ich kann für die fallenden Flanken nicht den Grund für das Problem finden. Der MCP2221 verhält sich an dieser Stelle exakt genauso! Jürgen W. schrieb: > Hinsichtlich Pullups: Wenn ich das Datenblatt auf die Schnelle richtig > gelesen habe, hat der Sensor schon 4k7-Pullups drin. Da der MSP430 nicht > mehr als 100kHz bei I2C kann (warum auch immer so wenig), sind auch > schon 10kOhm ok - aber achte darauf, daß Dir dein Oszi-Kabel nicht > unnötig hohe Kapazitäten einbringt; sofern Du mit 15pF-Tastkopf > arbeitest, sollte das aber kein Problem sein). Das Einzige was ich dazu finden kann: 1.Typical application circuit recommended cable length is shorter than the 20 Meter use 5.1K Pull-up resistor, is greater than 20 Meters lower the pullup resistor value according to actual situation. 2. Each numerical readout of temperature and humidity is the result of the last measurement, to get real-time data, need to read twice in a row, but not recommended > > to read several times in succession, each read sensor spacing is greater > than 2 Seconds to obtain accurate data... und DHT12 A simplified single bus communication. That only a single bus cable, system of data exchange,Control is done by a single bus communication. Devices (hosts) through a drain or a three State port is connected to the data cable to allow device does not send data will be released when the bus, while letting the other device uses the bus; usually require add-ins a single bus around 4.7KΩ Pull-up resistor, so that when the bus is idle by default high State. Von intern verschalteten Pullups ist nichts zu lesen. Haben wir unterschiedliche Infoquellen? :-) Allerdings fand ich auf der Rückseite der Sensorplatine zwei Widerstände.... Jürgen W. schrieb: > Da der MSP430 nicht > mehr als 100kHz bei I2C kann (warum auch immer so wenig), sind auch > schon 10kOhm ok Der MSP430 kostete 1,99€ und kommt fast ohne externe Beschaltung aus. Man darf nicht zu viel erwarten! Jürgen W. schrieb: > aber achte darauf, daß Dir dein Oszi-Kabel nicht > unnötig hohe Kapazitäten einbringt; sofern Du mit 15pF-Tastkopf > arbeitest, sollte das aber kein Problem sein). Ich kürzte alle Kabel und entfernte alle Messgeräte. Ich habe Schrödingers Haustier vergessen!!! Mein bester Tastkopf dürfte 25pF(200MHz) haben. Jürgen W. schrieb: > Der Spike, den Du am Ende des Signal siehst, entsteht durch die > Reaktionszeit des Sensors, d.h. er zieht für ACK den SDA-Pin auf Masse, > sobald SCL=0 ist - das ergibt dann halt ein paar 100ns, in denen durch > den Pull-up die SDA-Spannung etwas ansteigt. Hängt das auch mit den Kapazitäten zusammen? Entschärfe ich das durch eine kleinere Taktfrequenz? Jürgen W. schrieb: > Bzgl. schrittweisem Debuggen: Die IAR Workbench hat, sobald Du den > Debugger startest, einen Menüpunkt "Emulator->Advanced->Clock Control". > Beim schrittweisen Debuggen kann es also sein, daß die Clocks Stück für > Stück abgearbeitet werden und Du somit ein Timing-Problem nicht erkennen > kannst - schau Dir die Einstellungen dazu an. Da waren alle Optionen(ACL, SMCLK, TACLK) angekreuzt. Jürgen W. schrieb: > Was sind übrigens die Variablen "IFG2" und "IE2"? Ich kann's mir zwar > denken, aber gehört da nicht UCB0IFG und UCB0IE hin? IE = Interrupt Enable IFG = Interrupt Flag So habe ich halt alle IE's eingeschaltet! Oder? Deine Lösung scheint eleganter zu sein. Da habe ich noch nachzuarben... Jürgen W. schrieb: > Bzgl. Deiner ISR-Routine: Die scheint nur für TX-Flags zu sein, oder? > Ich bin mir da nicht sicher, weil meine Anwendungen meist in Assembler > geschrieben sind. > Du sollest außerdem das Lesen nicht byteweise organisieren, sondern > einfach ein Array machen und einen rxByteCnt hinaufzählen lassen. Das > Ende wird ja ohnehin durch das NACK vom Sensor angezeigt. Eigentlich sollte das nicht nur für TX sein. Ich wollte es erst einmal simple halten. Da habe ich noch nachzuarben... Jürgen W. schrieb: > Ein paar stilistische Anmerkungen: > * Bitte die einleitenden geschweifte Klammer in eine separate Zeile > geben - das sieht ordentlicher aus. > * Benutze für Variablen am besten lowerCamelCase - Du vermischt aktuell > die typischen großgeschriebenen Konstanten mit großgeschriebenen > Variablen. > Beispiel TXByteCtr => txByteCnt (ich bevorzuge Cnt statt Ctr für > Counter). Es ist schön dass solche "Kleinigkeiten" heute noch bemerkt werden!!!!! Das ist alles nur zusammenkopiert und mir kraust es dabei auch! Mea Culpa!!! Das ändere ich noch.
:
Bearbeitet durch User
Ich belebte die Katze wieder und ließ die Pullups weg. Zwei Sekunden warten! Die Otionen (ACL, SMCLK, TACLK) deselektierte ich. Seit dem funzt die Schaltung recht zuverlässig! Ein Watchdog ist dennoch angebracht denke ich...
Ich würde auch erst einmal eine stabilere Umgebung herstellen: Kein Lowpower Mode Definierten Takt konfigurieren Delay entfernen ...
Step by Step schrieb: > Ich würde auch erst einmal eine stabilere Umgebung herstellen: > Definierten Takt konfigurieren > Delay entfernen > ... Ja! Aber Low Power will ich schon haben...
:
Bearbeitet durch User
Wieso eigentlich soll der 'G2553 nur 100 kHz I2C-Takt unterstützen? Der kann natürlich auch mit 400 kHz betrieben werden - das zumindest steht im Datenblatt auf Seite 35 (Tabelle USCI, I2C Mode, Parameter fscl).
:
Bearbeitet durch User
Du sollst auch low power haben. Aber erst, wenn I2C funktioniert. Nimm den Kram ersteinmal raus.
Rufus Τ. F. schrieb: > Der kann natürlich auch mit 400 kHz betrieben werden - das zumindest > steht im Datenblatt auf Seite 35 (Tabelle USCI, I2C Mode, Parameter > fscl). Natürlich kann er das. Allerdings ist das Betrieb an den max. Ratings. UCB0BR0 = 12; // fSCL = SMCLK/12 = ~100kHz Die folgende Zeile takted auf 400kHz: UCB0BR0 = 3; // fSCL = SMCLK/3 = ~400kHz Ob das die Schaltung stabiler macht und ob die Sensoren das mitmachen sei darhingestellt. Der DHT12 steigt bei mir bei mehr als 375000 bps aus (auch beim MCP2221).
Andreas V. schrieb: > Allerdings ist das Betrieb an den max. Ratings. Magst Du mir das erklären? In Deinem Beispiel beträgt SMCLK gerade mal 1.2 MHz, was hat das mit irgendwelchen "max. Ratings" zu tun? Was verstehe ich hier nicht?
Step by Step schrieb: > Du sollst auch low power haben. Aber erst, wenn I2C funktioniert. > > Nimm den Kram ersteinmal raus. Warum? Wie gesagt: Seit dem Entfernen der externen Pull-ups, kürzen der Leitungen und Enternung aller Messgeräte funktioniert der Sensor sehr viel stabiler(fast zu 100%). Manchmal bleibt das Program noch am Ende der Funktion Transmit hängen....
Andreas V. schrieb: > Seit dem Entfernen der externen Pull-ups, kürzen der Leitungen und > Enternung aller Messgeräte funktioniert der Sensor sehr viel > stabiler(fast zu 100%) Weist alles eindeutig auf ein Timing-Problem auf dem Bus hin.
Rufus Τ. F. schrieb: > Magst Du mir das erklären? In Deinem Beispiel beträgt SMCLK gerade mal > 1.2 MHz, was hat das mit irgendwelchen "max. Ratings" zu tun? > > Was verstehe ich hier nicht? Seite 35 der MSP430G2553 Spezifikation: f_SCL clock-frequency 3V 0 - 400 kHz 400kHz ist somit die absolut max. Clock-Frequenz SCL/I2C(eher theoretisch). 0Hz als min. Frequenz kann ich nicht bestätigen ;-), da ich erst ab 25 Hz brauchbare Ergebnisse bekomme. Ähnlich sehe ich das mit den 400kHz. 200 kHz kann ich mir durchaus vostellen. Wie das da mit dem Energieverbrauch aussieht kann ich momentan noch nicht abschätzen. Optimiert ist das Bauteil somit für 100 kHz bis 200 kHz(So sehe ich das zumindest momentan).
Andreas V. schrieb: > Seite 35 der MSP430G2553 Spezifikation: Das sind nicht die "absolute maximum ratings". Interpretier' das nicht falsch. 400 kHz sind hier eine zulässige Frequenz, man sollte nur keine höhere verwenden.
Rufus Τ. F. schrieb: > 400 kHz sind hier eine zulässige Frequenz, man sollte nur keine höhere > verwenden. Ja! Aber wenn man die Taktfrequenz durch zwei teilt dann ist man schon bei 600kHz. 400kHz teste ich bei Gelegenheit. 100kHz funzen jedenfalls sicher. Bei 5 Datenbytes pro 10 Minuten die ich vom DHT12 holen will sollten 100kHz nicht das Problem sein.
:
Bearbeitet durch User
Bzgl. der Frequenz: Asche auf mein Haupt - da hab' ich wohl irgendeinen langsamen Sensor im Kopf gehabt. In allen anderen Timing-Belangen: Die I2C-Spec hat eine Set-up-time für die Daten definiert, bevor die positive SCL-Flanke 30% erreicht - ich kenne die I2C-Realisierungen zwar nicht auswendig, aber das spricht für ein Master-Slave-FF am Dateneingang eines I2C-Gerätes. Bitte beachten: die Anstiegszeit als der wichtigere Parameter ist sowohl für SDA als auch SCL bei 100kHz und 400kHz max. 300ns: 0,7=1-exp(-t2/tau) => t1 = -Tau*ln(0,3) 0,3=1-exp(-t1/tau) => t2 = -Tau*ln(0,7) 300ns >= t2-t1 300ns >= Tau*ln(0,7/0,3) Tau <= 300ns/0,8473 = 354ns Also, 4k7 als PU sind schon ok, 3k3 wären evtl. noch günstiger; bei kurzen Leitungen auf der Leiterplatte mit <50pF gehen, wie oben beschrieben, auch 10kOhm - das ist allerdings wirklich schon die Grenze.
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.