Ich habe ein paar der STM32 Blackpill mit dem STM32F401 Controller angeschafft. Für weitere Experimente. Die erste kleine Bastelei wird wohl ein Railcom Display werden, zur Gleisbelegtanzeige bei der Modellbahn. Passend dazu habe ich auch gleich STLink Programmieradapter bestellt. Zur Entwicklung verwende ich dazu die STM32CubeIDE, STM32CubeMX und den STM32CubeProgrammer.
Ich hatte den Schaltplan und das Layout für den DCC-Booster mit KiCad 8.0.0-RC2 erstellt. Die KiCad 7.0.10 Version mit flatpak war auf meinen System häufiger abgestürzt, so dass ich aus dem Gitlab Repository den Release Candidat 2 für die Version 8 selbst erstellt hatte. Was dabei noch nicht funktionierte, war die Python Console. So stand noch mal ein Build mit Python an.
KiCad selbst benötigt für die GUI die wxWidgets. Für die Python Console ist wxPython erforderlich. wxPython muss dabei zwangsweise mit der richtigen wxWidgets Version gebaut sein, sonst funktioniert die Python Console nicht. Damit begann die Odysee.
Zuerst muss die aktuelle Version von wxWidgets erstellt werden. Beginnen muss man mit einem Clone der entsprechenden Source Projekte.
git clone --recurse-submodules https://github.com/wxWidgets/wxWidgets.git cd wxWidgets ./configure --disable-glcanvasegl make sudo make install
Nach der Installation von wxWidgets (die unter /usr/local/lib/wx erfolgt) geht es weiter mit wxPython. Für wxPython gibt es eine ganze Reihe von Abhängigkeiten, wie Python Version > 3.6, setuptools 69, sip 6.8.3. Damit das alles passt, erstellt man wxPython in einer virtuellen Python Umgebung.
git clone --recurse-submodules https://github.com/wxWidgets/Phoenix.git cd Phoenix python3 -m venv env source env/bin/activate pip install sip pip install setuptools pip install tomli pip install requests python build.py dox etg --nodoc sip build python build.py --gtk3 --use_syswx build_py install_py deactivate sudo python3 build.py install_py
Mit den obigen Anweisungen wird wxPython in der virtuellen Umgebung auf Basis der vorher installierten wxWidgets Version installiert. Es kann sein, das auf anderen Systemen noch weitere Packages mit pip install installiert werden müssen.
Nach der Installation von wxWidgets 3.5.2 und wxPython 4.2.2a1 kann es nun an KiCad 8 gehen.
git clone --branch 8.00 https://gitlab.com/kicad/code/kicad.git cd kicad mkdir -p build/release mkdir -p build/debug cd build/release cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DKICAD_USE_EGL=0 -DKICAD_SCRIPTING_WXPYTHON=1 ../../ make sudo make install
Nun sollte KiCad 8 V8.00 installiert sein.
Hier noch die Links zu den Github/Gitlab Issues zum Bauen der Komponenten:
https://gitlab.com/kicad/code/kicad/-/issues/16939
https://github.com/wxWidgets/Phoenix/issues/2529
Für dieses Jahr habe ich zwei Elektronikprojekte auf dem Tisch. Das eine ist ein DCC-Booster mit ein paar Besonderheiten, das andere wird eine DCC-Zentrale auf Basis eines STM Nucleo 144 Boards.
Die Leiterplatten für den DCC-Booster gehen am Montag bei Aisler in die Fertigung. Den Booster benötige ich für die DCC-Zentrale, soll aber auch eigenständig für die Versorgung der Modellbahnanlage verwendbar sein.
Die DCC-Zentrale wird auf dem Code der Z21PG basieren, nur dass ich statt den üblichen 8-Bit ATMega2560 Controller einen STM32F746FG 32-Bit ARM Controller verwende. Mit dem Controller hat man einfach mehr Leistung zur Verfügung.
Diese Webseite ist mit Dokuwiki gemacht. Dokuwiki ist schnell, benötigt keine Datenbank und ein Wiki erfüllt meine Anforderungen besser, als ein CMS oder CMS ähnliches System. Ein Wiki ist normalerweise kein Blog. Für Dokuwiki gibt es dieses kleine Plugin, um den einen oder anderen Beitrag chronologisch zu erfassen.
Zum Test habe ich sehr alte Beiträge aus der seit Jahren nicht mehr existierenden Seite eingefügt. Auch wenn dort 2023 als Jahr steht, die Beiträge sind weit über 10 Jahre alt und nur zum Test enthalten.
Wie schon angekündigt waren wir am 11.05.2010 bei Radio Bremen zu Besuch. Wie hatten uns einen “bombigen” Tag ausgeguckt, genau zu dem Zeitpunkt der Besichtigung wurde in Bremen eine Bombenentschärfung durchgeführt, Arbeiter haben wieder mal so ein Teil aus dem 2. Weltkrieg aus der Weser gefischt. Leider wurde unser Programm deswegen etwas gekürzt, da der Fundort nur wenige Meter von Radio Bremen entfernt war. Positiv gesehen haben wir natürlich live (und auch im Studio) mitbekommen, was bei einem Radio-Sender so abläuft, wenn ein Viertel gesperrt wird und die Bevölkerung auf die Maßnahmen hingewiesen wird.
Es war ein sehr interessanter Besuch, vor allem mal live im Studio bei der aktuellen Sendung dabei zu sein. Sehr informativ und gut war die anschließende Thematik des Mittelwellensenders und die allgemeine Zukunft vom UKW-Radio. Auch die zukünftige Entwicklung zu DAB wurde kurz angesprochen.
Es waren angenehme 2 Stunden und bei Radio Bremen arbeiten nur nette Leute (das wußte man vorher ja schon aus dem Radio