Beiträge von Gnom

    Es wusste im Vorfeld keiner wie viele GPIOs der TO nutzen wird !

    Wenn du es nicht wusstest... jeder, der das Schaltbild aufmerksam betrachtet hat, wusste es.

    Und sorry, auch wenn ich nur einen LVT 816C Single zur Hand habe, aber bei einem IInput_Forward von 1,6 mA bei UInput_Forward von 1,4 V und einer Collectorspannung von 5,0 Volt ( Emitter Pulldown - schaltend ) passiert rein gar nicht ! Wahrscheinlich wirst du jetzt behaupten mein Optokoppler sein kaputt.

    Tja, dann nimm mal was Passendes zur Hand, wie ich es auch geschrieben habe, dann geht es. Ich habe hier einen 847 Rank G (CTR 130-400%) und der kann schon bei 1,2 mA Forward-Current problemlos den mit einem ca. 9,5-K-Pullup gehaltenen Ausgang von 5 Volt auf 0,125 Volt runterziehen, was absolut ausreicht, um den gewünschten Eingang zu schalten.
    Trotzdem gilt weiterhin, dass er auch einen "HGW"-847 mit 4 mA ansteuern kann, wenn es nur um 4 Ausgänge geht.

    Da muss man keine Raketenwissenschaft draus machen! Das sture Beharren auf einer "imaginären" 1,6 mA-Grenze pro GPIO ist doch in diesem Fall absolut nicht sachdienlich.

    Das maximale Powerlimit hat keinerlei Einfluss auf die Leckströme. Denn wenn diese über 2 mA lägen, wäre das ja geradezu pervers. Eine Standard-LED hat bei 5V Reverse-Voltge laut Datenblatt einen maximalen Reverse-current von 100µA. Nachgemessen bei 3,3 V und 100 Ohm Vorwiderstand sind es tatsächlich angezeigt NULL µA.
    Ebenso sind die Leitungskapazitäten in diesem Fall mit Sicherheit absolut vernachlässigbar, wenn die Schaltung nicht mit pervers hohen Frequenzen betrieben wird.
    Bei 35 LEDs und 100 Hz Anzeigefrequenz benötigt man eine Einschaltzeit jeder LED von 1/3500 = 0,28 ms. Nehmen wir 10% davon für den Schaltvorgang, also 0.028 ms. Stellen wir und die Leitungskapazität und den 100 Ohm Vorwiderstand der LEDs als RC-Glied vor, kommen wir rechnerisch für eine Zeitkonstante von 0,028 ms in eine Größenordnung von 0,28 µF für die Kapazität. Die Kapazität einer LED liegt im unteren Picofarad-Bereich und bei Leitungen/Leiterbahnen sprechen wir von Kapazitäten im einstelligen nF- bis zweistelligen pF-Bereich pro Meter. (Wie groß mag wohl die Platine sein?) Da ist noch ein Faktor 1000 bis 100000 dazwischen.

    Dass du mit deinen Aussagen sowieso nur im Nebel rumstocherst, zeigen ja schon die Formulierungen:

    [...] kann ich dir nicht sagen.
    Darauf verlassen, [...] ich würde es nicht so machen [...]
    [...] wahrscheinlich ? potentielle Leitungskapazitäten noch nicht berücksichtigt hast.

    Das sind keine fundierten Einschätzungen, das sind nicht mal ernstzunehmende Erfahrungswerte, sondern das sind orakelhafte Schwurbeleien aus anwendungstechnischen Grenzbereichen, die mit der Praxis des hier vorliegenden Falles absolut nichts zu tun haben.


    Franky, ganz ehrlich: Wo bekommt man das Zeug, das du rauchst? Davon will ich auch was haben!

    Oder steckt da etwa eine Absicht dahinter? Dann fände ich es geradezu perfide, wie du hier arglose Bastler mit Aussagen verunsicherst, die jeder realistischen Einschätzung entbehren.

    Da Adresssebyte und DataByte immer in der zusammengehöreden Reihenfolge gesendet werden müssen[...]

    Stimmt so nicht ganz. Sofern es überhaupt ein TM1640 ist, gibt es zwei Varianten:
    - Entweder jeweils Adresse und Daten (paarweise) - Dann geht ein Fixed-Address-Comand voran
    oder
    - Anfangsadresse und dann mehrere Datenbytes, die an der Anfangsadresse fortlaufend in den Speicher geschrieben werden. Dann geht ein Address-auto+1-Comman voran.

    Insofern muss man das schon etwas differenzierter sehen. Erst muss man den Command für die Adressierungsart auswerten und dann die Adresse(n) und Date(n) entsprechend interprtieren.

    Ob nur die eine oder die andere oder sogar beide Methoden hier verwendet werden, kann man erst mal nicht sagen.

    [...] Vor jedem Datenbyte toggled zweimal der SCLK. Also kann man erst einmal damit / darüber die Datenrate des DBytes herausfinden. Dann musst du nur das Zeitliche Abbild der Periode für einDByte encodieren, und das machst du so oft, wieviele Display-/Anzeigeeinheiten angeschlossen sind. Damit erhält man den direkten im Zusammenhang der aufleuchtenden Segmente / LEDs, die man mittels einer Vergleichstabelle sofort wieder in Klartext /-zahlen verwandeln kann.

    Ich glaube, das ist sehr vereinfacht.

    Sollte es ein TM1640 sein, so werden über die Datenleitung Speicherbytes im Chip mit den "Bilddaten" beschrieben. Das kann zwar, muss aber nicht immer für alle Ziffern nacheinander passieren. Vielmehr können die Adressen für die 16 Bytes, in denen die Daten stehen, gezielt angegeben werden. Es wäre also ggf. nötig, den Datenstrom komplett zu erfassen und dann den Befehl, ggf. die Adresse und dann auch noch die eigentlichen Bilddaten auszuwerten, um den Speicherzustand jederzeit zu kennen. Die Befehle sind allerdings relativ einfach aufgebaut und von daher müsste das machbar sein.
    Sofern man es schafft, den Datenstrom mit einem µC anzuzapfen und sauber zu lesen, dürfte der Rest kein großes Problem sein. Leider ist mir nicht so ganz klar, was mit "dual line serial interface" gemeint ist. Ob das kompatibel zu den üblichen seriellen Interfaces eines µC ist, müsste man wohl ausprobieren. Vielleicht kennt sich auch hier jemand mit den Signalprotokollen von I²C/SPI aus und kann was dazu sagen.

    Masse schaltest du, indem du den GPIO auf output und low schaltest.

    Für 10 mA musst du aber in einem Register des Pico die Stärke des Treibers auf 12 mA stellen. Wie das genau geht, kann ich dir leider gerade nicht sagen. Indos gibts im Datenblatt des Pico-Chips RP2040.

    Und du musst aufpassen, dass du nicht versehentlich gleichzeitig mehrere Spalten auf HIGH und/oder mehrere Zeilen auf LOW stellst, sonst ziehst du das mehrfache an Strom.

    50 MHz erscheint mir etwas hoch. Warum so viel?

    Die erste Frage wäre, wie viel Strom deine LEDs ziehen. Unter HCD-88441 werde ich nicht fündig, was das genau sein soll.
    Hast du denn Vorwiderstände an den LEDs, um den Strom überhaupt zu begrenzen? Sollen das U2 bis U8 sein?

    Verstehe ich dich richtig, dass du eine Platine hast, bei der die Zeilen/Spalten direkt an die GPIOs des Pico angeschlossen sind, ohne Transistor, Optokoppler oder ähnliches und du nun wissen willst, ob das geht, ohne den Pico zu beschädigen?

    Theoretisch (!) kannst du standardmäßig über die GPIOs sowohl 3,3 V als auch Masse schalten mit bis 4 mA, wenn du in den Registern was änderst sogar bis 12 mA. Wenn du übliche LEDs hast, die du mit 20 mA betreiben willst, reicht das allerdings nicht. Und du müsstest dann jede einzelne LED mit (max) 12 mA ansteuern, hast also nur gut die halbe Leuchtstärke und dazu noch nur 1/35 der Zeit, also insgesamt knapp 1/60 der maximalen Helligkeit einer 20-mA-LED-Anzeige. Das dürfte etwas mager sein. Insofern kommst du um eine erweiterte Schaltung ohnehin nicht herum.

    Auf der sicheren Seite bist du mit Optokopplern auf jeden Fall. Du musst dann auch nicht jede LED einzeln ansteuern, sondern kannst ja immer eine komplette Spalte in einem Rutsch schalten. Damit brauchst du für ein 100-Hz-LED-Bild 500 Hz Ansteuerfrequenz für die fünf Spalten. Das ist für den Optokoppler kein Problem.

    Dann solltest du erstmal ausmessen, wo an den LEDs die Anoden/Kathoden sind und ob es Common Anode oder Common Cathode LEDs sind.

    Dann die Leiterbahnen verfolgen, um zu sehen, wo die am Multiplexer-Chip landen. Es müssten dann ein paar Pins übrig bleiben - für Stromversorgung und Datenverbindung. Dann könntest du entweder die Datenleitung anzuzapfen versuchen oder die Signale an den Ausgängen abgreifen. Vielleicht kannst du erst mal die Signale mit einem Logic Analizer anschauen.

    Ich hab ein paar Datenblätter von 3-Digit-Anzeigen. Die Pins 8, 9, 12 sind da jeweils die Common Cathode oder Common Anode für die drei Ziffern, die restlichen Pins sind die 7 Segmente. Auf deinem Platinenfoto beginnen die Pins unten von rechts nach links 1 bis 5, Nummer 6 fehlt, dann oben von links nach rechts 7 bis 12. Da kannst du erst mal messen, was da so ankommt.

    Mal ins Blaue spekuliert: Der Chip hat 28 Pins. 8 Segmente 16 Digits (weil es so ne schöne Binärzahl ist) wären zusammen 24. Bleiben noch vier Pins übrig. Zwei für Strom und zwei für CLK und Daten. Das könnte passen. Wer weiß... Der Chip könnte ein TM1640 sein. Der andere IC ist dann wohl der µC, der den ganzen Spaß stuert. Vielleicht ein STC8H - zumindest würde der von der Pinbelegung grob passen können.

    Auf der Platine sind noch 2 x 8 LEDs und 1 X 5 LEDs - offenbar werden die auch von dem Chip angesteuert.

    Offenbar geht es dir um die vier Taster/Schalter S1-S4, oder?

    Die sind offensichtlich mit Pullup-Widerständen auf Vcc gezogen und werden bei Betätigung auf GND gelegt.

    Wenn du das mit dem Pico ansteuern willst, kannst du das mit vier Transistoren machen (Open-Collector-Schaltung) oder du nimmst einen 4-Kanal-Optokoppler 847, das ist im Zweifel einfacher und sicherer. Du legst einfach den Ausgang des Optokopplers parallel zum Schalter - eigentlich keine große Sache.

    Ich bezog mich auf Hardware-PWM. Nutzt dein Programm Hardware-PWM? Ne, gell? Und hast du mit deinem geeichten Frequenzzähler auch den Jitter gemessen oder nur einen Mittelwert?

    Und hör doch endlich mal auf, bei jeder Gelegenheit anderen ans Bein zu treten. Oder hast du das charakterlich nötig? Minderwertigkeitskomplese? Das wäre wirklich bemitleidenswert.
    Wenn du nicht weißt, woher ich meine "zusammenhanglos herauskopierten Textpassagen" habe, woher willst du dann wissen, dass sie nicht zutreffen?


    Spar dir die Antwort - ich werde sie nicht lesen!

    [...] GPIOs die Hardware-PWM beherrschen. Damit kann man [...] via des PWM Kanals ein solches Taktsignal erzeugen.

    Meines Wissens kann der Pi nur bestimmte PWM-Frequenzen erzeugen, weil sie mit Dividern aus einem Basistakt von 19,2 MHz erzeugt werden. 48 KHz ist damit nicht möglich, weil es keinen Divider von 400 gibt.


    So, allen viel Spaß und Erfolg - ich bin dann hier mal raus.

    Ist schon seltsam, keiner hat eine Lösung, also könnt ihr das nicht oder kann der RPi das nicht?

    Vielleicht liest du nur, was du lesen willst...
    Nicht nur ich hab dir deutlich gesagt, dass der Pi das nicht kann und dafür auch gar nicht gedacht ist. Und ich hab dir zwei Lösungen genannt - einen Taktgenerator und einen Mikrocontroller mit Timer-Interrupt.
    So viel zum Thema "von oben herab", "Hilfsbereitschaft", "das kann ich auch" und "keiner hat ne Lösung".

    Vielleicht hörst du mal mit dem Gemaule auf. Nur weil Du Erwartungen an den Pi hast, die der nicht erfüllen kann, musst du hier nicht die beleidigte Leberwurst spielen.

    Und das ist doch der Sinn eines RPi, er dient dazu komplexe messtechnische Dienste zu steuern.

    Das ist mir vollkommen neu!

    Wenn du schon von "professionell" redest, dann justier mal deine Weltsicht. Ich kaufe gerade ein Gerät, das 100.000 mehrfarbige Strichcodes in der Stunde auf Codewert, Position und Farbabweichungen prüft. Das ist komplexe, professionelle Messtechnik - und die ist nicht für 400 € zu haben und wird auch nicht von einem 35-€-Pi gesteuert. Dafür legst du den Gegenwert eines VW-Golf hin.

    Du willst was 100% Professionelles - für 40 €? Jaja, man ist ja bescheiden... Und du willst mit gpiozero oder ähnlichen Libraries ein stabiles 48 KHz-Signal erzeugen - auf einem SoC, der nebenbei noch ein Multiuser-Betriebssystem, Dateizufgriffe, Netzwerk, GUI, Gerätetreiber aller Art und vieles mehr steuert? Vielleicht nebenbei noch ruckelfrei 4K-Videos schauen? Halte ich für ein ziemlich aussichtsloses Ansinnen.

    Der Pi IST eine Bastelwerkzeug - als solches wurde er erfunden und als solches versteht er sich auch. Das heißt aber nicht, dass er zu schlecht ist, um auch für ernsthafte Anwendungen eingesetzt zu werden. Wenn jemand teure Messpaltinen speziell für den Pi entwickelt, wird er dafür schon einen Grund haben. Möglicherweise hat er aber nicht vorgesehen, dass seine Käufer die Samplefrequenz über den Pi ändern - sonst stünde sicher im Handbuch, wie das geht...

    Wenn es dir, so verstehe ich es zumindest, zunächst mal ausschließlich darum geht, dem Messboard über einen dafür vorgesehenen Eingang eine andere Frequenz zu geben, dann solltest du vielleicht mal nachforschen, was man für sowas benutzt, wenn man es "professionell" haben will. Einen Pi würd ich dafür jedenfalls nicht als ideal ansehen. Man öffnet ja auch keine Bierdosen mit ner Rohrzange. Jedenfalls find ich es ziemlich schäbig, hier die gesamte Pi-Community in den Dreck zu treten, nur weil DU DEIN spezielles Problem nicht lösen kannst.

    Es gibt Quarze mit 12288000 Hz, die in der Audiotechnik eingesetzt werden und mit einem Teiler von 256 genau 48000 Hz erzeugen. Es gibt auch programmiernbare Taktgeber-ICs mit verschiedenen Frequenzen. Vielleicht schaust du dich mal nach einer geeigneten Taktgeberschaltung um. Alternativ könntest du mit einem µC und einem Timer-Interrupt auch zum Ziel kommen.