mit einem Rigol-Oszi möchte ich ein RS485-Signal Entziffern, welches von einem pH-Sensor generiert wird. Der Sensor hat vier Litzen:
gelb: Signal (RS485-A)
blau: Signal (RS485-B)
braun: positive Versorgung (12...24V DC)
schwarz: negative Versorgung (0V)
Kann ich diese abgebildete Spitze verwenden um das RS485-Signal abzutasten? Ist die kleine Krokodilklemme in diesem Fall Ground oder "nur" um Impedanz-Probleme vorzubeugen? Bisher verwendete ich immer nur für langsame, analoge Signale mit BNC. Mit seriellen Schnittstellen kenn ich mich nur wenig aus.
Ist die kleine Krokodilklemme in diesem Fall Ground oder
"nur" um Impedanz-Probleme vorzubeugen?
Diese doofen Krokoklemmen sind GND und muessen selbstverstaendlich mit Ground
deines Signals verbunden sein. Bei Signalen von hoher Frequenz ist diese Verbindung wegen der Impedanz der 10cm Zuleitung nicht ausreichend, deshalb gehoert zu einem Tastkopf auch immer so eine kleine Massefeder.
Bei RS485 wirst du vermutlich nur so 9600 bis 115200Baud uebertragungsrate haben. Also wirst du Signale bis maximal 1Mhz Bandbreite sehen wollen und deshalb ist dann die Krokoklemme ausreichend und erforderlich.
Wenn man mit mehreren Tastkoepfen misst dann sollte man eigentlich auch jeden irgendwo mit der Krokoklemme an GND anklemmen. Allerdings wenn man weiss was man da macht und keine sauberen Bilder rumzeigen muss, dann kann man da schon mal etwas vernachlaessigen. .-)
Ich empfehle dir mal die unterschiedlichen Klemmungen, auch mit Massefeder, auszuprobieren damit du den Unterschied siehst und ein Gefuehl dafuer bekommst wann man etwas locker sehen kann und wann nicht.
Die "richtige" Methode, ein differenzielles Signal wie RS-485 zu messen, ist zwei Kanäle für A und B (jeweils relativ zur Masse) zu benutzen und das Oszilloskop A−B berechnen zu lassen. Aber wenn du nicht viele Störungen hast, dann geht auch einfach nur A.
Die "richtige" Methode, ein differenzielles Signal wie RS-485 zu messen,
ist zwei Kanäle für A und B
Ach komm, das ist die richtige Methode um stoerungsfreien Betrieb fuer ein 1000m langes Kabel im harten Industrieeinsatz sicher zu stellen. Aber um mit dem Oszi ein paar Daten abzuschnorcheln reicht es einfach nur A oder B zu belauschen.
Vielen Dank schon mal.
Langsam tut sich etwas (s. Foto)
Leider sieht man noch nicht scharfe Kanten und Pulse, wie erwartet...und der RX-Decoder zeigt zwar Zahlen an, aber noch keine Wörter.. Irgendwelche Ideen?
Und es könnte Sinn machen, die GND-Klemme des Tastkopfs auch auf GND zu legen.
Da es sich da um PE der Steckdose handelt in der das Oszi steckt, könnte es je nach Restschaltung und Netzteil schlecht sein, A oder B nach PE kurzzuschließen...
Da es sich da um PE der Steckdose handelt in der das Oszi steckt, könnte
es je nach Restschaltung und Netzteil schlecht sein, A oder B nach PE
kurzzuschließen...
Die Gnd-Klemme hat weder an A noch an B irgendetwas zu suchen.
Sonst muss der RS485-Treiber den ganzen Aufbau mit durch die Gegend schleifen.
Laut einige im Internet zu findender Beschreibungen sprechen diese Bodensensoren offenbar Modbus RTU, vermutlich als Slave. Dementsprechend sollte sich gar nichts auf den Datenleitungen tun. Je nachdem, ob die EIA-485 korrekt abgeschlossen und mit Failsafe-Beschaltung versehen ist, sollte A dann irgendwo zwischen ca. 1,5 V und 5 V hängen und B zwischen 0V und ca. 2,5 V, wobei A immer positiver als B sein dürfte.
Folglich muss der Sensor also an einen Modbus Master angeschlossen sein, der ihn periodisch mit der richtigen Baudrate, Übertragungsparametern und Adresse abfragt. Auf dem Oszilloskop kann man meist Master und Slave sehr gut daran unterscheiden, dass sie leicht unterschiedliche Signalpegel treiben.
Du misst Mist (aka. Störungen). Kein Wunder bei dem Messaufbau. Als Tipp: um zu sehen, was da grade so an Störungen unterwegs ist, halte ich kurz vor der Messung die Tastspitze mal kurz an die angeklemmte Masseklemme. Wenn du dann keine schnurgerade Linie auf 0V siehst, sind eh schon Störungen ubterwegs.
und der RX-Decoder zeigt zwar Zahlen an
Und so gut wie jede Zahl endet mit einem Fragezeichen...
Kurz:
der wird aus jedem Signal irgendwas herausrechnen. Halt einfach mal nur den Finger an die Spitze. Du wirst die Lottozahlen sehen.
Der Decoder bemühst sich, aus den 50mV-Spitzen zu machen was er kann.
Normal sollten da eher ganze Volt rauskommen, und nicht so schön regelmäßige Elkonachladekurven.
Tatsächlich steht in der Anleitung (aus Fernost, die Übersetzung ist so-la-la), dass man ein Modbus-RTU einsetzen soll. Verstehe ich es richtig, dass ich die Messwerte über einen "Host" aktiv abfragen muss, über Leitung "B" ? Ich hatte gehofft, dass der Sensor mit einer festen Rate die Werte liefert...
Ja, wenn es ModbusRTU ist musst du den Sensor abfragen.
Aber nicht über B, A & B gehören zusammen, das ist eine differentielle Übertragung, d.h. "A+ und B-" ist ein Bit, "A- und B+" das andere.
Im Prinzip eine normale Halbduplex Serielle Schnittstelle, nur mit anderen Spannungspegeln.
Tatsächlich steht in der Anleitung (aus Fernost, die Übersetzung ist
so-la-la), dass man ein Modbus-RTU einsetzen soll. Verstehe ich es
richtig, dass ich die Messwerte über einen "Host" aktiv abfragen muss,
über Leitung "B" ? Ich hatte gehofft, dass der Sensor mit einer festen
Rate die Werte liefert...
Das ist bei Modbus unüblich. Der Sensor ist höchstwahrscheinlich als Slave implementiert und sendet von sich aus nichts.
Wenn Du eine Doku des Sensors hast, stelle sie hier doch mal ein
Die "richtige" Methode, ein differenzielles Signal wie RS-485 zu messen,
ist zwei Kanäle für A und B
Ach komm, das ist die richtige Methode um stoerungsfreien Betrieb fuer
ein 1000m langes Kabel im harten Industrieeinsatz sicher zu stellen.
Aber um mit dem Oszi ein paar Daten abzuschnorcheln reicht es einfach
nur A oder B zu belauschen.
Vanye
Außer irgendwer sendet Stuss auf der Leitung wodurch das Signal nicht korrekt ist.
Aus eigener Erfahrung: das ist keine geeignete Basis für erfolgreiche Elektronikentwicklung.
Wenn man ein Bussystem verwenden will, dann muss man sich zuallererst mal die Grundlagen dieses Bussystems aneignen. Dann kann man versuchen, selber mit diesem Bus zu fahren. Aber einfach nur "reinsitzen" und hoffen, dass der Bus dorthin fährt, wo man gerne hinwill, führt in den allermeisten Fällen nicht zum gewünschten Ziel.
Ich hatte den TO auch schon gebeten alle Unterlagen einzustellen. Denn er hat welche: "Tatsächlich steht in der Anleitung (aus Fernost, die Übersetzung ist
so-la-la), dass man ein Modbus-RTU einsetzen soll"...
In der Anleitung sind doch die meisten wichtigen Parameter beschrieben. Und wie zu erwarten war, handelt es sich um einen Modbus Slave.
Und noch einmal die wichtige Frage:
Was glaubst Du denn mit dem Oszilloskop messen zu können, wenn der Sensor nicht von einem Host abgefragt wird? Die einzigen Informationen, die man darüber herausbekommen kann, sind gg. die Terminierung und die Fail-Safe-Pegel.
Gut, jetzt ist einiges klarer. Vielen Dank euch allen
Habe gerade über Minicom (ähnlich wie PuTTy) versucht eine Verbindung aufzubauen aber es passiert nichts; ich kann keine Commands über den Rechner an den Sensor senden...Es ist als ob der USB/RS485-Converter den Sensor nicht bemerkt. Ich versuche es womöglich jetzt mit einem Microcontroller.
ich kann keine Commands über den Rechner an den Sensor senden...
Warum glaubst du wohl hab ich oben hterm gesagt? Du glaubst doch nicht im Ernst das ein Empfaenger die Ewigkeiten warten welche die glibbrige Masse zwischen deinen Ohren braucht um einzelne Zeichen zu tippen oder?
Du must eine korrekte Nachricht mit korrekter Pruefsumme an einem Stueck schicken.
Habe gerade über Minicom (ähnlich wie PuTTy) versucht eine Verbindung
aufzubauen aber es passiert nichts; ich kann keine Commands über den
Rechner an den Sensor senden...
Hast Du mittels Oszilloskop verifiziert, dass Minicom keine Zeichen an den Sensor schickt?
Wie erzeugst Du die binären(!) Zeichenfolge mit dem Befehl?
Wie erzeugst und sendest Du die korrekte CRC?
Woher stammt das zugehörige Generatorpolynom?
Hast Du verifiziert, dass die Zeichen schnell genug gesendet werden, d.h. Modbus T35 einghalten wird?
Es ist als ob der USB/RS485-Converter den
Sensor nicht bemerkt.
Das hast Du wie verifiziert?
Ich versuche es womöglich jetzt mit einem Microcontroller.
Um Dir die nächsten Probleme einzuhandeln, ohne dass Du die Ursache der Fehlversuche mit dem PC geklärt hast?
Hast Du denn die offizielle Modbus-RTU-Spezifikation konsultiert und verstanden, was darin enthalten ist?
Vielleicht schickst du auch nur das falsche Kommando!?
Ich vermute ja sehr stark, dass er händisch ein paar ASCII-Zeichen schickt, inklusive der Zeichenfolge "CRC". Und T35 läuft zwischendurch jeweils hundertmal ab.
Habe gerade über Minicom (ähnlich wie PuTTy) versucht eine Verbindung
aufzubauen aber es passiert nichts; ich kann keine Commands über den
Rechner an den Sensor senden...Es ist als ob der USB/RS485-Converter den
Sensor nicht bemerkt. Ich versuche es womöglich jetzt mit einem
Microcontroller.
Ist das wirklich die serielle Schnittstelle /dev/tty.usbserial-AK966VDV
Schau mal mit ls -la /dev/tty* nach, was es da alles gibt
Und ja: Linux unterscheidet zwischen Gross- und Kleinschreibung,
also auch ls -la /dev/USB und ls -la /dev/ACM, denn serielle Schnittstellen können auch /dev/ttyACMx heissen
Hey zusammen, aktuell sende ich keine Befehle an den Sensor. Bin noch nicht soweit. Hatte erwartet, dass im Minicomputer etwas wie "waiting for commands" erscheint, und ich dann eine Zeichenreihe rausschicken kann. Ich hänge jetzt den Oszi drann. Viele Grüße
Hatte erwartet, dass im Minicomputer etwas wie "waiting
for commands" erscheint, und ich dann eine Zeichenreihe rausschicken
kann.
Wo genau hast Du das in der offiziellen Modbus-Spezifikation gelesen?
Ich hänge jetzt den Oszi drann.
Das ist generell eine gute Idee, um zu schauen, ob überhaupt Zeichen geschickt werden. Aber ohne Kenntnisse des Protokolls wirst Du nicht beurteilen können, ob das einigermaßen Modbus RTU entspricht.
Lade Dir QModMaster runter, stelle ModbusRTU und 9k6 8N1 ein und lese die in der Doku angegebenen Register aus.
Wenn das dann klappt kannst du dir die Kommunikation gerne mit dem Oszi ansehen.
Ist aber eigentlich unnötig, ModBusRTu ist sehr gut dokumentiert.
Ob Du dann einen eigenen Modbus-Master programmieren willst oder lieber was fertiges nimmst kannst Du dir dann überlegen.
Ach so: Modbus-Frames müssen am Stück geschickt werde. Zeichenweises eintippen klappt nicht. Wenn Du das Modbus-Telegramm von Hand erzeugen möchtest musst Du es vorher zusammentippen und dann am Stück abschicken. Für solche Sachen nehme ich gerne Realterm, einfach weil ich das schon seit Ewigkeiten benutze :-)
==> USB/RS485-Konverter: keinerlei Artikelnummer oder Datenblatt vorhanden.
Wie würdet ihr den Sensor am besten verdrahten? Braucht es überhaupt das MAX485-Board? Macht der USB-Adapter dasselbe? Soll ich aus dem Computer oder aus dem Mikrocontroller am besten dem Sensor den Befehl senden, dass er mir die Messewerte bitte zurücksendet?
Beantwortest Du vielleicht auch noch mal alle Dir gestellten Fragen?
Die Pinbelegungen und -bedeutungen folgen doch direkt aus den üblichen Signalbezeichnungen für EIA-422/485 auf der UART-Seite. In den meisten Fällen können hierbei für EIA-485 DE und RE miteinander verbunden werden, abhängig davon, ob man ein lokalen Echo der gesendeten Daten wünscht oder nicht. Das hängt natürlich von Deiner konkreten Implementierung des Modbus-Protokolls(tacks) ab.
Hast Du denn mittlerweile mal die Modbus-Spezifikation gelesen und verstanden?
Hi, danke schon mal.
Ja, auf https://modbus.org habe ich die Spezifikation gelesen und langsam checke ich es. Ich frage mich, wie ich nun die benötigte Bitfolge vom Rechner an den Sensor sende. Habe per "minicom" eine Verbindung zum USB-Konverter aufgebaut. Und dieser blinkt, sobald ich auf der Tastatur drücke. Auch am Oszilloskop tut sich was, aber dessen RS232-Decoder zeigt mir nicht den Buchstaben an, auf den ich drücke :/ Mir ist auch noch nicht klar, wie ich jetzt eine ganze Bit-Abfolge inkl. Addressfeld, Functionscode et.c. auf ein Mal sende. Ist dieser Link sinnvoll? https://unix.stackexchange.com/questions/117037/how-to-send-data-to-a-serial-port-and-see-any-answer
Habe es jetzt probiert, mit CoolTerm.
Obwohl ich Charakter-Strings senden kann und dabei die TX-Leuchte kurzzeitig aufblinkt, erhalte ich keine Antwort: die RX-Leuchte bleibt Dunkel.
Der Sensor zieht konstant etwa 10mA, was eigentlich plausibel ist. Wie könnte ich das Troubleshooten?
Danke
Habe es jetzt probiert, mit CoolTerm.
Obwohl ich Charakter-Strings senden kann und dabei die TX-Leuchte
kurzzeitig aufblinkt, erhalte ich keine Antwort: die RX-Leuchte bleibt
Dunkel.
Ich weiß nicht wie Coolterm arbeitet, aber ich glaube deine Eingabe ist falsch. Die Schreibweise 0x als Vorsilbe wird nur in C und anderen Programmiersprachen verwendet, aber meist nicht bei der Eingabe in Terminalprogrammen. Da schreibt man nur die reinen Hexzahlen. Probier mal.
010300060001640B
Das solltest du auf deinem Oszi prüfen, ob die Zeichen so auch rauskommen.
Hi, danke euch allen.
Jetzt kommt zumindest etwas zurück auf RX :)
Es ist allerdings noch nicht lesbar...Habe alle Einstellungen nochmals geprüft: Baudrate, Data-Bits, Parity, Stop-Bits. Trotzdem erhalte ich noch keine lesbaren Werte :/ Und wenn ich die Baudrate ändere (aktuell bei 9600), dann kommt nichts mehr zurück.
Die Tatsache, dass der Sensor überhaupt antwortet, ist schon ein sehr deutliches Zeichen dafür, dass Deine Requests gültig sind und auch die physikalische Verbindung funktioniert.
Was erwartest Du denn für eine Darstellung? Wie sehen denn die Zeichen der Antwort in Binär- oder Hex-Darstellung aus?
Wenn Du die Modbus-Spezifikation gelesen und VERSTANDEN hättest, wäre Dir das auch klar. Willst Du eigentlich für die echte Anwendung auf eine der vielen vorhandenen Modbus-Implementierungen zurückgreifen oder alles selbst implementieren? Auch wenn Du letzteres vorhast, ist es äußerst lehrreich, sich mal die Quellcodes anderer Implementierungen anzuschauen und diese auch untereinander zu vergleichen, denn es gibt viele verschiedene Wege, Protokollstacks zu implementieren.
Ebenfalls sehr wichtig bei der Auswahl solch einer Implementierung ist natürlich die Frage, von welcher Programmiersprache bzw. Laufzeitumgebung heraus die Verwendung erfolgen soll.
Doch doch, wenn der Sensor antwortet, kann man seine Werte auch lesen.
Du bist schon wieder drauf reingefallen wie Zahlen dargestellt werden, damit Mensch sie lesen kann.
Der nächste Schritt ist dann, das du begreifst wie die Prüfsumme erstellt wird.
Endlich funktioniert es, ihr habt recht gehabt:)
Die ASCII-Antworten direkt in HEX umwandeln zu lassen war ein guter Tipp. Dies kann man ja leicht in Dezimal umrechnen. Und wie die Prüfsumme erstellt wird mittels CRC-16 checke ich.
Ich versuche jetzt das ganze in Zephyr RTOS umzusetzen, deren Beispiel ist allerdings etwas kryptisch. Falls ich Fragen habe, melde ich mich wieder
habe jetzt den Rechner durch ein Nordic-μCU ersetzt und versuche von dort aus mit dem Sensor zu kommunizieren, per MAX485. Jedes mal wenn auf Boot-Klicke, sollte die μCU als Modbus-Kunde eine Anfrage senden.
Mich wundert ist folgendes:
das DE-Signal (Driver-Enable) in türkis, sieht nicht gut aus und ist verzerrt.
das DI-Signal (Driver-Input) in gelb, scheint einen konstant Offset zu haben und es ist kaum eine Bit-Sequenz erkennbar
habe jetzt den Rechner durch ein Nordic-μCU ersetzt und versuche von
dort aus mit dem Sensor zu kommunizieren, per MAX485. Jedes mal wenn auf
Boot-Klicke, sollte die μCU als Modbus-Kunde eine Anfrage senden.
Mich wundert ist folgendes:
das DE-Signal (Driver-Enable) in türkis, sieht nicht gut aus und ist
verzerrt.
Da ist nichts verzerrt, nur eine HF-Störung überlagert.
das DI-Signal (Driver-Input) in gelb, scheint einen konstant Offset
zu haben und es ist kaum eine Bit-Sequenz erkennbar
Deine Amplitude ist mit ca. 400mV auch "etwas" klein. Da gibt es einen Kurzschluß und es treiben zwei Ausgänge gegeneinander.
Hat jemand evtl. Hinweise?
Du solltest die Screenshot Funktion des Oszilloskops nutzen.
Dein Masseanschluß der Tastköpfe ist fragwürdig.
DE ist high active und darf logischerweise nur aktiv sein, wenn dein Modbus Sender sendet. Das muss direkt nach dem letzten, gesendeten Zeichen wieder LOW werden, damit du die Antwort vom Bus/Sensor empfangen kannst. Denn das ist alles halbduplex.
Außerdem hängt dein RE in de Luft. Das macht man nicht, selbst wenn das Ding einen internen Pull-Up Widerstand hätte. Meistens verbindet man RE und DE direkt, dann hört man seine gesendeten Daten nicht. Dann braucht es noch einen Pull-Up Widerstand an RX vom uC. Denn RO geht auf Tristate, wenn RE inaktiv ist.
An deinem Bus fehlt das Bias-Netzwerk, damit der Bus bei Inaktivität auf HIGH gezogen wird. Klassischer Fehler.
Am Tastkopf den "1x<->10x Schieber" beachten auf 10x stellen und den jeweiligen Oszi-Kanal bei "Probe" entsprechend auch auf "10x" einstellen. Sieht hier so aus, als ob das nicht ganz übereinstimmt.
Hallo zusammen, habe jetzt das RE mit dem DE kurzgeschlossen. Und zunächst den Sensor entfernt um zu sehen, was der MAX485 alleine macht.
Folgende Hürde entsteht: Das TTL-Signal aus dem μCU wird vom Oszi sauber dekodiert, allerdings nur, solange es nicht am DI (Driver-Input) des MAX485 verbunden ist...Wenn ich es am MAX485 anschließe, dann läuft die Dekodierung so la-la, oft werden die falschen Bitfolgen entziffert...
Das ist kein TTL-Signal, sondern ein 5V-CMOS-Signal.
Wenn ich es am MAX485 anschließe, dann läuft die
Dekodierung so la-la, oft werden die falschen Bitfolgen entziffert...
Wenn der aktuelle Aufbau immer noch so wie auf dem zuvor veröffentlichten Foto aussieht, dann liegt das an der fehlenden Masseverbindung zwischen Microcontrollerboard und dem Pegelwandler. Und NEIN, das ist nicht verhandelbar, auch wenn Du irgendwo von jemand anderem ahnungslosen aufgeschnappt hat, dass das ja nicht wichtig wäre und der Onkel des Dackels seines Schwippschwagers neulich auch keine Masseverbindung gemacht hatte und Muttis Haartrockner trotzdem funktionierte.
Warum sind so viele Leute heutzutage nicht mehr bereit, sich auch nur ansatzweise mal mit den allerelementarsten Grundlagen der Elektrotechnik und Physik zu beschäftigen, die wir früher(tm) schon im Kindergarten vermittelt bekamen?
inzwischen habe ich den μCU-Ground auf den IC-Ground gelegt und es sieht gut aus! Das Signal bleibt gut erkennbar. Leider kommt nach dem MAX485, bei "A" noch bei "B" garnichts an...man sieht nur dass sich der Pegel ändert, wenn man das Signal am DI rausschickt. Aber es ist keinerlei Bitfolge erkennbar.
Na dann hast du es vermutlich mal wieder geschafft, das DE-Signal zu unterbrechen. Dann sind die Treiber inaktiv (tristate). Du bist schon ein echter Künstler . . .
Hi nochmal, die Screenshot-Funktion ist leider nicht verfügbar aufgrund von USB-Vorschriften (IT).
Jetzt kommt das richtige Signal hinten (zwischen A/B) an, allerdings nur wenn der DE-Pin komplett offen bleibt und von der μCU entkoppelt wird^^ Dann liegen nämlich bei DE von alleine ca. 5V an, woher verstehe ich nicht. Irgendwie machen meine 3.3V-DE aus dem Mikrocontroller Probleme:/ So werde ich auch keine Signale an RI vorerst empfangen können...
Hi nochmal, die Screenshot-Funktion ist leider nicht verfügbar aufgrund
von USB-Vorschriften (IT).
Wollen wir wetten, daß die in dem OSZI NICHT gesperrt ist?
Jetzt kommt das richtige Signal hinten (zwischen A/B) an, allerdings nur
wenn der DE-Pin komplett offen bleibt und von der μCU entkoppelt wird^^
Unsinn.
Dann liegen nämlich bei DE von alleine ca. 5V an, woher verstehe ich
nicht.
Dann hast du was falsch verbunden oder sonstigen Kurzschluß. Denn der MAX485 hat keinerlei interne Pull-up/Down Widerstände.
Irgendwie machen meine 3.3V-DE aus dem Mikrocontroller Probleme:/
So werde ich auch keine Signale an RI vorerst empfangen können...
Nö. Der MAX485 hat TTL Schaltschwellen und kann sicher mit 3,3V angesteuert werden. Da gibt es eher ein Problem in der Gegenrichtung. Zwischen RO und deinem RXD des Mikrocontrollers sollte man 1-5k zur Strombegrenzung schalten, denn der MAX485 gibt 5V aus und dein 3,3V uC ist vermutlich NICHT 5V tolerant.
Vielen Dank nochmal, mein DE-Pin war invers programmiert, sprich active=low. Das war der Fehler. Ich schaue mir das mit den Pull-up/Down Widerständen nochmals genauer an.
Beste Grüße
Ich schaue mir das mit den Pull-up/Down
Widerständen nochmals genauer an.
Wenn Dein Microcontrollereingang nicht 5V-tolerant ist, dann ist womöglich der Microcontroller eh schon hinüber. Das muss sich nicht in einem Totalausfall äußern, sondern es kann auch deutlich subtilere Fehlfunktionen geben. Und dabei geht es nicht nur um Pull-Up/-Down, sondern eben um die Pegelanpassung in Empfangsrichtung.
Ein einfacher Serienwiderstand kann ggf. ausreichen. Ich würde auf Nummer Sicher gehen und einen Spannungsteiler vorsehen. Letzterer verhindert zuverlässig, dass es insbesondere bei niedriger Stromaufnahme des Microcontrollerteils zu einem "Durchschlagen" des Signals auf die Versorgungsspannung kommen kann. Das führt dann zwar zu keinem Defekt, aber z.B. Oszillatoren oder PLLs können aus dem Tritt geraten. Falls der ADC verwendet wird und die Versorgungsspannung als Referenz verwendet, kann es ggf. zu unnötig großen Messfehlern kommen.
Setup.JPG
(230 KB)
