Beiträge von 0xdeadbeef

    Bei einem Emulator ist man froh, wenn die Software wie erwartet läuft. Man versucht nicht unbedingt, Details wie den Multiplexer in der PotX/Y-Leitungen in jedem Detail zu simulieren, zumal in einem Emulator ja keine echte Tastatur/Maus angeschlossen ist und viele dieser Details weitestgehend witzlos wären.

    Man muß das nicht unbedingt an Demos usw. festmachen. So speziell wie die Abfrage einer Maus auf einem C64 funktioniert, wird das ein Simulator niemals exakt nachbilden.

    Insofern ist es relativ leicht, eine Mausabfrage zu schreiben, die in einem Emulator wunderbar funktioniert und auf einem echten C64 nicht.

    Auf einer FPGA-Lösung mit echten D-DUB9-Ports muß man das zeitliche Detailverhalten der PotX/Y-Pins zumindest so weit nachbilden, daß eine Maus im Prinzip funktioniert.

    Ob das Verhalten wirklich in jeder Hinsicht das eines normalen C64 ist (wobei es da wegen analoger Komponenten usw. auch eine recht große Schwankungsbreite geben wird), wage ich aber auch zu bezweifeln.

    Genauso wenig bilden FPGA-Lösungen die etwas kruden NMOS-Eigenschaften der C64-ICs nach. Oder den Jitter in der Takterzeugung usw.

    Viele Leute haben eh falsche Vorstellungen von FPGAs. Die meisten MiSTer-Cores sind aus der MAME-Implementierung abgeleitet. Da wird nicht jeder ICs auf Gatterebene nachgebildet, sondern das im Simulator (MAME) implementierte Verhalten wurde in den FPGA übertragen. Mit all den Vereinfachungen, die damit einhergehen.

    Die digitalen GPIOs des RP2040 haben keine 5V-Zertifizierung, in der Praxis passt das schon (Info und Tests). Clamping-Dioden gibt's nur an GPIO26-29 (wegen der ADCs), die hier aber nicht benutzt werden.

    Da weint mein Ingenieursherz. Auf die Messungen eines Menschen mit fragwürdigem elektrotechnischem Hintergrund zu vertrauen statt den Angaben in den Datenblättern, erscheint mir kein nachvollziehbarer Ansatz.

    Daß es an den normalen GPIO-Pins keine echten Clampingdioden (mit einem spezifizierten Maximalstrom) gibt, ist übrigens keine positive Aussage.


    "The GPIO pins not connected to the ADC have a different clamping arrangement which tolerates applied voltages higher than the VDDIO voltage, but they are still ESD clamps. Permanent connection to e.g. 5V IOs is not a rated operational condition of the RP2040. The chip will likely survive accidental connection, though."

    Nur so zwei Punkte, die mir dazu einfallen:

    1. Wieviel Strom zieht der RP2040 in so einer Situation (enge Schleife für Bitbanging)? Ich würde annehmen, daß eine moderne FPGA-Lösung vermutlich mit deutlich weniger Strom auskommt (20mA statt 40mA oder so).
    2. Soweit ich weiß, sind die GPIOs des RP2040 nicht 5V-tolerant, oder? Selbst wenn der RP2040 das eine Zeit überlebt, fließt dann ständig Strom durch die Clamping-Dioden.

    R18 auf Masse?

    Genau. Hatte beim Reinkopieren aus einem anderen Projekt ein zweites Masselayer "GND2" erzeugt, wodurch R18 auf der einen Seite nicht mit Masse verbunden war.

    War im Schaltplan kaum zu sehen und im Layout habe ich zu sehr auf die automatische Prüfung gegen den Schaltplan vertraut.

    Also mußte ich den Lötstopplack unter R18 wegkratzen, um die Masserverbindung durch eine Lötbrücke herzustellen.

    War heute recht fleißig und habe einen MicroKey2 und zwei Platinen mit Dreifach-Stromquellen für eine Sensorsimulation aufgebaut (obwohl das Projekt für das ich gerade arbeite, so etwas wirklich in keiner Weise zu schätzen weiß und meine Firma meinen Arbeitsplatz eh nach China o.ä. verlagern will):


    Die beiden weißen Platinen sollten eigentlich die letzte Version sein, nachdem die allererste Version überraschend gut funktioniert hatte und ein darauf basierender Prototyp mit Analogschaltern statt Dioden zur Umschalten der drei Stromquellen leider krachend gescheitert ist. Deshalb habe ich auch gleich zwei davon aufgebaut. Leider ist mir aber im Schaltplan ein peinlicher Copy&Paste-Fehler unterlaufen, wodurch das neue Feature (Erzeugung von 5V aus ~10V Versorgungsspannung mittels eines TL431 leider so überhaupt nicht funktioniert hat. Glücklicherweise konnte ich die Platinen durch einen Hack retten, der nicht brutal auffällig ist. Ich frag mich, ob ihn jemand sofort entdeckt.

    Nicht im eigentlichen Sinne heute, aber die letzte Woche hatte ich endlich wieder an meinem "DAB+-Radiowecker"-Projekt gearbeitet, das ich ursprünglich vor sieben Jahren beginnen wollte und Anfang 2025 mit einem RasPi Zero 2 neu aufgesetzt hatte.


    Nach einigen Ablenkungen durch anderen Kram, habe ich inzwischen einige wichtige Punkte erreicht:

    • Ich kann das DAB+-Modul per API vom RasPi aus steuern bzw. Daten auslesen (per UART).
    • Ich kann gleichzeitig einigermaßen flott (Scroll-)Text und Grafik auf dem 480x320 LCD (rechts) ausgeben. Inzwischen sogar mit Umlauten ;)
    • Ich kann die Helligkeit des LCDs über PWM dimmen.
    • Ich kann Datum und Uhrzeit auf dem I2C SSD1309 OLED (links) ausgeben.

    Im Vergleich zu meinen bisherigen Mikrocontrollerprojekten war das mit dem RasPi bisher ein ziemlich Krampf und alles dauert ewig.

    Das Debugging ist grenzwertig, und die vielen Merkwürdigkeiten des RasPi überraschen mich stets aufs Neue..

    Egal ob UART oder I2C: nichts geht auf Anhieb, alles hängt per Default am wechselnden CPU-Takt. Den I2C-Takt kann man nur in den globalen Systemeinstellungen ändern usw.

    Außerdem ist die WiringPi-Library Äonen von dem entfernt, was ich mir normalerweise auf kleineren Mkrocontrollern aus dem Ärmel schüttele. Die I2C-Funktionen sind total rudimentär und unterstützen nur maximal 255 Bytes.

    Statt alles in Interrupts mit verschiedenen Prioritäten zu machen, mußte ich jetzt für einigermaßen flüssigen Scrolltext auf Multithreading ausweichen. Im Prinzip läuft die Grafikausgabe auf dem LCD jetzt also auf einem eigenen Core.

    Aus irgendeinem Grund gibt das DAB-Modul den Radiotext usw. als "wide char" mit 32bit aus, benutzt davon aber anscheinend nur ein Byte (letztendlich also ISO). Keine Ahnung, alles komisch.

    Eigentlich war mein Plan, schon längst die Drehencoder und die beiden I2C-Sensoren in Betrieb genommen zu haben, aber irgendwie klappt nichts auf Anhieb und dauert viel länger als erwartet...

    Ich weiß nicht wie du auf 32k Samples kommst.

    Alles natürlich Zitate von der Homepage. Aber auch 380k ist mau.

    Natürlich ist das kein Profi-Gerät.

    Richtige Profigeräte kosten nach wie vor tausende Euros. Auch der DSLogic ist kein Profigerät. Aber er hat zumindest eine ganz brauchbare Hardware, eine offene Software und man kann eigene Protokolldecoder in Python dafür schreiben.

    Wenn man an die Grenzen stößt, hat man immer noch die Option tiefer in die Tasche zu greifen.

    Alles schön und gut, aber die Schubladen voll mit halbgarem Zeug zu haben, ist halt auch nicht optimal.


    Und ja, ich habe ein paar solcher halbgarer LAs in meinen Schubladen...

    Ihr seid immer so schnell begeistert, aber 32k Samples bzw. 128k im 8Bit-Modus wären schon 20 Jahren echt wenig gewesen. Man scheint den Triggerlevel nicht einstellen zu können (nur eingeschränkt über externe Vref) und ich finde keine Spezifikation der maximal zulässigen Eingangsspannung usw.

    Leider sind die DSLogic Plus inzwischen auch recht teuer geworden. Früher gab's die teils für 70€ oder so mit vollem Speicher (256MBits). Habe mir vor ein paar Jahren einen U3Pro16 mit 2Gbit Speicher und USB3 gegönnt und nie bereut. Letztes Jahr oder so habe ich sogar mein ersten komplexes Decoderskript dafür (und für Sigrok, weil gleiche Codebasis) geschrieben.