Probleme mit der Signalverarbeitung mit Pi Pico

OP #7919142
Lesenswert?

Hallo allerseits

Ich brauche Rat. Nachdem ich viele Stunden damit verbracht habe, mittels PIO Signale zu erfassen, bin ich nun dahingehend angelangt, dass es offensichtlich ein Problem beim Signal gibt und nicht beim Softwarecode oder dem Signalgeber.

Bei der optischen Auswertung des Signales mittels Pico sehe ich, dass z.B. das ausgewertete Clock-Signal nicht regelmässig und sauber verläuft, sondern mit vielen Aussetzern, Abschnitte ohne logisch 1, und allgemein vielen fehlenden Signale mit highs. Es scheint, dass die highs vom Pico nicht richtig erkannt werden. Eine Prüfung mittels Pulseview und separatem Logikanalyzer zeigt, dass das Signal aber grundsätzlich richtig ankommt beim GPIO des Pico. Dort sieht das Signal sauber aus wie es sein muss.

Die low und high Signale kommen aus einem Gerät, dass mit VDD 5.00 V betrieben wird. Das originale Signal hat folgende Levels gemäss Hersteller: VIH = min. 0.8 VDD, max. 1.0 VDD => somit 4-5 Volt VIL = min. 0.0 VDD, max. 0.2 VDD => somit 0-1 Volt

Dieses Signal soll nun irgendwie auf die maximal 3.3 V gebracht werden, ohne dass an der Logik 0/1 etwas verändert wird.

Da der Pico nun ja maximal 3.3 V verträgt, wurde ich dahingehend beraten, das Signal über einen SN74AHCT125 laufen zu lassen und einfach nur 3.3 V als Betriebsspannung anzulegen. Der SN74... würde dann das Signal VIH entsprechend mit maximal 3.3 V wieder ausgeben, was der Pico verträgt. Was aber mit VIL geschieht, konnte man mir nicht genau sagen und habe ich so im Datenblatt auch nicht gefunden. Da der Tipp von jemandem kam, der in diesem Bereich tätig ist, habe ich soweit mal vertraut und den Euro für den SN74... ist auch nicht alle Welt. Aber selbst bin ich Softwareentwickler und habe von Bauelementen nicht ganz soviel Ahnung leider.

Datenblatt SN74...:

  • Damit VIH sauber erkannt wird, muss mindestens 2.0 V anliegen. Das wäre eingehalten, da ich ja 4-5 V bringe.
  • Damit VIL sauber erkannt wird, darf maximal 0.8 V anliegen. Das wäre nicht eingehalten, da ich ja bis zu 1 V bringe (was aber mit Nachmessung ausgeschlossen werden kann. Es sind je nach Signal maximal 0.6 V und ich habe ja Probleme mit fehlenden highs und nicht lows). Diese Werte gelten für eine Betriebsspannung des SN74 von 4.5-5.5 V.

Nun ja, da stehe ich nun und mache mir einen Kopf.

Darum meine Frage: Was für eine Empfehlung habt ihr mir, damit ich das Eingangssignal auf maximal 3.3 V begrenze und trotzdem saubere lows und highs bekomme? Ich habe euch ein Bild angehängt. Ihr seht oben das Signal, dass ich mit dem Logikanalyzer direkt am GPIO abfange; unten das Resulatat, wenn ich mittels PIO das Signal auswerte und visualisiere.

Vom Gerät, das ausgewertet werden soll, kommen 7 Signalleitungen und 1 GND.

Danke und Gruss Michael

Angehängte Dateien:
(Firma: 1984now) #7919210
Lesenswert?

Harald K. schrieb:

Andere lösen so etwas problemlos mit einem Widerstandsteiler.

So ist es. Selbst wenn der ein wenig zu langsam ist, kann man ihm mit einem kleinen Kondensator noch etwas Beine machen.

Das Konzept funktioniert hervorragend in den Probes für Oszis. Ich sehe keinen Grund, warum es hier nicht funktionieren sollte.

Oder ist die Quelle so hochohmig, daß die nicht belastet werden kann?

Ja, die Impedanz der Quelle sollte man natürlich kennen, um den Teiler sinnvoll dimensionieren zu können.

#7919268
Lesenswert?

Michael schrieb:

erfassen, bin ich nun dahingehend angelangt, dass es offensichtlich ein Problem beim Signal gibt und nicht beim Softwarecode oder dem Signalgeber.

widerspricht aber dem hier:

Eine Prüfung mittels Pulseview und separatem Logikanalyzer zeigt, dass das Signal aber grundsätzlich richtig ankommt beim GPIO des Pico. Dort sieht das Signal sauber aus wie es sein muss.

Gibt es nun ein Problem beim Signal, oder doch nicht. Ansonsten liegt es auch eher nicht am Pico, sondern mit viel grßerer Wahrscheinlichkeit am Programm. Um was für Clockfrequenzen geht es hier eigentlich?

Moderator (Firma: Titel) Persönliche Seite #7919292
Lesenswert?

Michael schrieb:

Eine Prüfung mittels Pulseview und separatem Logikanalyzer zeigt, dass das Signal aber grundsätzlich richtig ankommt beim GPIO des Pico. Dort sieht das Signal sauber aus wie es sein muss.

Die hardwaremäßige Integrität eines digitalen Signals prüft man mit einem Oszi. Und zwar direkt am Eingangspin des Bauteils. Dort kann man dann erkenen, dass an der Flanke das Signal klingelt wie Harry, auch wenn das einem angeschlossenen Bauteil nichts ausmacht. Siehe z.B. den Beitrag "Re: Signalproblem bei langem Kabel"

Die low und high Signale kommen aus einem Gerät, dass mit VDD 5.00 V betrieben wird. Das originale Signal hat folgende Levels gemäss Hersteller: VIH = min. 0.8 VDD, max. 1.0 VDD => somit 4-5 Volt VIL = min. 0.0 VDD, max. 0.2 VDD => somit 0-1 Volt

Der Hersteller spezifiziert Eingangspegel (VIH und VIL) für ein Signal, das er ausgibt? Sollte er nicht eher VOH und VOL spezifizieren?

Seis drum: letztendlich interessiert nur wie das Signal direkt in deiner schaltungstechnischen Realität aussieht. Und dafür brauchst du ein Oszi.

Jens G. schrieb:

sondern mit viel grßerer Wahrscheinlichkeit am Programm.

+1

#7919471
Lesenswert?

Michael schrieb:

Da der Pico nun ja maximal 3.3 V verträgt, wurde ich dahingehend beraten, das Signal über einen SN74AHCT125 laufen zu lassen und einfach nur 3.3 V als Betriebsspannung anzulegen.

Ja, nee. Stammt die Beratung von dem ChatGPT?

Auszug aus dem Datenblatt des SN74AHCT125:

1
VCC Supply voltage: MIN 4.5 V

Ein HCT-IC ist nicht nur wegen der Versorgungsspannung ungeeignet. Mit dem SN74AHCT125 kannst du ein 3.3V-Signal in ein 5V-Signal umwandeln, umgekehrt würde er dir überhaupt nichts bringen.

Wie schnell sind deine Signale? Wahrscheinlich reicht ein einfacher Spannungsteiler.

Bei der optischen Auswertung des Signales mittels Pico ...

Wie hast du dafür die 5V-Signale (?) an den Eingangsspannungsbereich des Pico angepasst? Mit welcher Frequenz tastest du die Signale ab?

#7919500
Lesenswert?

Michael schrieb:

Die low und high Signale kommen aus einem Gerät, dass mit VDD 5.00 V betrieben wird. Das originale Signal hat folgende Levels gemäss Hersteller: VIH = min. 0.8 VDD, max. 1.0 VDD => somit 4-5 Volt VIL = min. 0.0 VDD, max. 0.2 VDD => somit 0-1 Volt

  • Damit VIL sauber erkannt wird, darf maximal 0.8 V anliegen. Das wäre nicht eingehalten, da ich ja bis zu 1 V bringe (was aber mit Nachmessung ausgeschlossen werden kann. Es sind je nach Signal maximal 0.6 V und ich habe ja Probleme mit fehlenden highs und nicht lows).

Hallo,

"somit 0-1 Volt" ?

ich verstehe nicht wie du auf 1V Low Pegel kommst. Laut Hersteller nur max. 0,2V. Du misst 0,6V. Hast du ein Masseproblem? Ist das Signal belastet?

Abgesehen davon wenn die Datenrichtung gleich bleibt und das Signal unbelastet bleibt, wäre ein Spannungsteiler aus 2 Widerständen ausreichend. Ansonsten gibt es von TI TXB/TXSxxx Levelshifter. https://www.ti.com/product-category/logic-voltage-translation/voltage-translators-level-shifters/overview.html

Übrigens ersetzt ein Logic Analyzer kein Oszi, wenn man Probleme mit dem Signal vermutet. Wenn deine Spannungspegel nicht stimmen, dann kann auch der Logic Analyzer diese nicht als High/Low erkennen. Er tastet digital ab und nicht analog.

#7919511
Lesenswert?

Michael schrieb:

Das originale Signal hat folgende Levels gemäss Hersteller: VIH = min. 0.8 VDD, max. 1.0 VDD => somit 4-5 Volt VIL = min. 0.0 VDD, max. 0.2 VDD => somit 0-1 Volt

Das 'I' in der Signalbezeichnung deutet darauf hin, dass es sich hierbei um die Spezifikation der Pegel für irgendwelche Eingänge ('I' für Input) handelt. Für die Ausgangssignale muss es entsprechend Spezifikationen für VOH und VOL geben ('O' für Output). So ist es jedenfalls allgemein üblich. Zeig doch einmal die Spezifikationen.

OP #7920544
Lesenswert?

Harald K. schrieb:

Ob der Threadstarter sich hier noch blicken lässt?

Ja hier bin ich. Danke für alle Tipps und Hinweise. Ich sehe aber auch, dass es offene Fragen gab. Zwei möchte ich kurz beantworten. Beispiel 1: Ich schrieb zum Beispiel, das logisch 0 max. 0.2 VDD ist. VDD = 5 V. 0.2 x 5 V = 1 V. Also nicht 0.2 V sondern 0.2 VDD. Sorry, wenn das verwirrt hat, aber ich habe einfach die Bezeichnung gemäss Datenblatt übernommen. Beispiel 2: VIH/VIH -> Dazu zur Erklärung: Das Gerät bekommt von einem MPU (MSM6255) die Signale. Darum sind die Signale für das Gerät ein Input. Gleichzeitig hat das Gerät eine Buchse, an der genau diese Signale abgegriffen werden kann, was ich mache. Darum gemäss Datenblatt I und nicht wie es logisch wäre O.

Und nun zur Auflösung, an was es gelegen hatte: Der PIO erfasst den Pin, und schreibt 0/1 in den ISR, der nach 32 bit in den RX FIFO gepusht wird. Der RX FIFO wird mittels DMA in einen Array geschrieben. Nach stopp der Erfassung, wird der Array grafisch dargestellt. So, würde man den PIO direkt mittels sm.get() in den Array schieben, ist es schnell einleuchtend, dass der PIO zu schnell ist und hier Daten verloren gehen. Und genau das ist, trotz DMA , passiert. Der FIFO wurde nicht schnell genug geleert, was zu einem RX Overflow geführt hat. Will heissen, neue Daten sind angestanden, aber der Fifo randvoll, was offensichtlich Daten aus dem Fifo hinten „rausgeschoben“ hat. Die Einbrüche bei logisch 1 sind also gar keine Einbrüche, sondern genau dort fehlen jeweils 32 bit an 0 und 1. Sozusagen einen Streifen herausgeschnitten und zusammengeschoben. Der Fehler konnte über fdebug erkannt werden (RX Overflow). Warum dies trotz DMA passiert ist, ist nur ekne Vermutung. Nach dem erneuten aufspielen der Firmware bei gleichem Code ist der Fehler nicht mehr aufgetreten, warum kann ich nicht sagen momentan.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren