Beiträge von 0xdeadbeef

  • Kennt Jemand dieses Modul?

    HCF4046 ist eine PLL, HCF4518BEY ist ein 4Bit-BCD-Zähler. CA3162E ist ein ADC, der ein dreistelliges BCD-Display ansteuern kann. CA3140E ist ein Opamp.

    -> Irgendeine Art von ADC, wobei die BCD-Ansteuerung vermutlich an die Userport-Pins geht, um den Wert digital einzulesen.

    Vermutlich kann man mit dem Drehschalter die Abtastfrequenz einstellen.

    Oder so.

  • SPI-LCDs mit dem RasPi (Zero 2 W) "Best Practice"

    Ich will in einem RasPI-Projekt Text und Grafiken auf einem LCD ausgeben, aber nicht notwendigerweise im Sinne einer Desktopanwendung.

    Ich habe mir dafür ein Waveshare 3.5" LCD (B V2 version , IPS, 480×320) besorgt. Hauptgründe für dieses Display waren das IPS-Display und die Steuerung der Hintergrundbeleuchtung über PWM.

    https://www.waveshare.com/wiki/3.5inch_RPi_LCD_(B)


    Eigentlich hatte ich ursprünglich nicht vor, das Display zur Anzeige der Konsole und/oder des Desktops zu verwenden, aber um es mal auszuprobieren, habe ich auch mal versucht, es laut Anleitung zu installieren.

    Weil ich meinen Pi Zero 2 W erst gerade eben aufgesetzt habe, wurde mir BookWorm 64bit empfohlen, also habe ich das installiert.

    Neben anderen Problemen führt das leider dazu, daß die einfache Installation des Treibers nicht funktioniert.

    Ich habe mich dann durch diese etwas verworrene manuelle Konfiguration gekämpft, bei der auch so einiges nicht auf Anhieb geklappt hat:

    https://www.waveshare.com/wiki…_(B)_Manual_Configuration

    Aber am Ende wurde mir eine Konsole angezeigt. Hatte zu diesem Zeitpunkt auch "Boot to CLI (o.ä.)" ausgewählt. Umschalten auf den Desktop hat nicht funktioniert. Teils bin ich dann auch nicht mehr per SSH auf den RasPi gekommen.

    Also habe ich wieder auf "Boot to CLI" umgestellt und mal spaßeshalber versucht, mit "cp /dev/random /dev/fb1" in den Frame Buffer zu schreiben. Das hat im Prinzip funktioniert, aber ein Zeichen wurde wieder von der Konsole überschrieben.

    Vor allem aber hat in dieser Kombination der Login über SSH extrem lange gedauert (10 Sekunden oder so statt sofort). Ich vermute, daß es irgendwie daran liegt, daß der Treiber nur mit X11 funktionieren würde, aber die Umstellung auf X11 unter den neuesten Bookwork-Versionen nicht mehr funktioniert. Oder was auch immer.


    Nun war Bookwork 64bit anscheinend auch Anfang 2025 noch eine schlechte Wahl, wenn man damit eigentlich überall nur Probleme bekommt, aber eigentlich wollte ich das Display ja eh nur "direkt" ansteuern. Schreiben in den Framebuffer klang zwar irgendwie verlockend, aber direkte Kontrolle über die zu schickenden Daten ist vermutlich eh besser. Nun benutzt mein Display anscheinend einen ILI9486 und keinen IlI9341, den ich schon bei diversen Mikrocontrollerprojekten benutzt hatte, aber irgendwie bin ich davon ausgegangen, daß es da auch diverse Bibliotheken für den RasPi geben müßte. Gibt es aber anscheinend nicht. Schon gar nicht als Teil von WiringPi (will ja in C programmieren).


    Was mich zum meiner eigentlichen Frage bringt: was ist der beste/einfachste Weg, ein SPI-LCD auf dem RasPi als Ausgabe für ein einziges Programm zu benutzen (am Ende wird nur dieses Programm direkt beim Booten gestartet)? Speziell wenn man in C programmieren will.

    Anscheinend scheinen 99.9% der Leute über einen Treiber und den Framebuffer zu gehen. Gibt es dafür einen speziellen Grund? Es erscheint mir irgendwie bizarr, ein winziges Display mit niedriger Auflösung zur Darstellung der Konsole oder des Desktops zu verwenden.

    Und auf einem "nackten" Mikrocontroller ohne Linux würde man natürlich direkt per SPI Befehle schicken.

  • Heute so gecodet...

    Streng genommen habe ich noch nicht wirklich was programmiert, aber die letzten Tage habe ich rumgebastelt, um auf dem Raspberry Pi Zero 2 W von meinem PC aus zu entwickeln.

    Dank der Extension "Remote SSH" von Visual Studio Code kann man tatsächlich am PC entwickeln, kompilieren und debuggen, obwohl alles auf dem RaspPi läuft.
    Sprich: der Quelltext liegt nur auf dem RasPi, der Compiler und der Debugger laufen auf dem RasPi. Trotzdem sieht es (fast) so aus, als wäre das ein lokales Projekt auf dem PC mit lokalen Tools:



    Leider ist Visual Studio Code halt speziell beim Einrichten eines Projekts etwas "sperrig" und das ganze ist leider eine ziemliche Übung in Geduld.

    Geschätzt braucht es eine Minute, bis man nach dem Start von Visual Studio Code so richtig loslegen kann. Und wenn man eine Debug-Session startet, dauert es 15-30s bis man auf dem ersten Breakpoint steht.

    Bin mir nicht sicher, ob das am langsamen WLAN liegt oder am Zero 2, aber es ist trotzdem toll, daß so etwas überhaupt funktioniert...

  • Bobbel kämpft mit Blackscreen ASSY 250407

    Ich bin damals bei meinem 250407-Blackscreen u.a. nach den Hinweisen in diesem Buch hier vorgegangen:

    https://github.com/petersieg/R…/Buch-Retro-Computing.pdf

    War aber irgendwie nicht so hilfreich wie erhofft. Meine Scope-Messungen haben eigentlich nur gezeigt, daß der SID funktioniert und sich irgendwas auf der CPU tut, aber am Schluß habe ich doch mehr oder weniger alles gesockelt und getauscht, nur um am Ende festzustellen, daß es (entgegen der allgemeinen Meinung) doch die CPU war.

  • C64 Game Maker

    Irgendwie habe ich erst jetzt so richtig realisiert, daß der Game Maker zwar letztendlich einen C-Compiler benutzt, aber wohl innerhalb der IDE nur den eigenen Basic-Dialekt unterstützt, der dann nach C übersetzt wird.

    Das finde ich schade, denn was ich mir eigentlich wünschen würde, wäre eine Art C-IDE in einem Rundum-sorglos-Paket (mit Sprite/Char-Editoren usw.).

  • Heute so gecodet...

    Echt? Bin mir relativ sicher, daß wir vor 10 Jahren oder so in der Firma ein Excel mit >28000 Zeilen hatten, um alle möglichen Kombinationen einer "Invalid Operation" einer Float-Einheit zu erfassen.

  • guter aktueller Emulator

    Zitat von angryking

    Sooooo viele Windows VICE User, aber nicht einer war bereit, irgendwas zu tun.

    Hat nicht jeder Zeit, in absolut jedes Tool, das er mel benutzt, Zeit und Herzblut zu investieren. Zumal die Mitarbeit an solchen größeren Projekten für Quereinsteiger meist eher ultrafrustrierend ist.

    Und wenn der harte Kern beschließt, irgendwelche potentiell schrecklichen Entscheidungen zu treffen (GTK und so), kann man da eh nichts machen außer einem Fork, den man dann sein Leben lang pflegen müßte, was man aber natürlich nach einer kurzen enthusiastischen Phase aufgibt.

  • guter aktueller Emulator

    Zitat von Flexman

    Die Sache ist, dass ein Emulator schnell mal dort ist, wo die ganzen User, die nur hier und da mal ein Programm starten, keine neuen Features mehr brauchen.

    Oder man ist nicht glücklich damit, daß Features entfernt (Debugger) oder kaputtgemacht werden.

    Aus den Release-Notes der V3.9