Inzwischen veraltete und obsolete Dokumentation, die nur noch verwirrt.
Das Gesamtkonzept ist wegen der Schaltschränke IMHO völlig aus dem Ruder gelaufen, und nun folgt kurz vor der Präsentation eine Feuerlöschaktion auf die nächste.
Software-Stand (nicht von mir) (Ich schieße mir nicht mit Englisch kommentarlos ins Knie.)
Grober Überblick:es laufen einzelne Services (unter vehicle/services) diese kommunizieren über mqtt (hauptsächlich posaunen sie ihre aktuellen Werte heraus) in der lib/car.py befindet sich eine Klasse ArtikulatedAxisVehicle; die hält die z.Z. die zentralen Infos über den Fahrzeug-Status und hält Methoden zur Berechnung der Fahrmaneuver bereit der Service "driver" steuert das Fahrzeug; driver.py enthält den Low-Level-PWM-Kram; dirver-server.py nimmt die mqtt-Nachrichten auf und löst letztlich Bewegungen und Maneuver aus.
Eingesetzt wurde zunächst diese USV um den Stromversorgunsproblemen des Raspberry Pi 4 (RPi4) Herr zu werden. Ist aber für die Katz', im Nachhinein weil der RPi4 lieber 5,4 V haben möchte und hier nichts einstellbar ist. Es ist halt nur eine 08/15-Powerbank, die nur von den Montagemaßen (Löcher) her zum RPi passt. Daran ist so ziemlich alles zu kritisieren:
Bedienungsanleitung (PDF-Scan, 10 Seiten A4)
Konformitätserklärung
(PDF-Scan, 3 Seiten A4, identisch mit jener zum Radlader)
Seriennummern: Fahrzeug: -, Fernbedienung: 1G047198, Empfänger: 1G047223
Das Not-Aus schaltet den Output-Enable-Eingang der PWM-Platine
und nicht mehr die dicke Leitung vom Hauptakku.
Der Akkuanschluss wurde auf die originale, unangezapfte
Leitung mit XT60-Stecker
rückgebaut.
Der „Magic Controller“ ist verzichtbar; die PWM-Platine hat noch genügend
Anschlüsse für die Beleuchtung.
Dinosauriergeräusche sind kein Muss, der Ton kann vom Raspberry mit einem
sparsamen Verstärker kommen.
TODO: Bei der nächsten Revision steht das Zurücksetzen der Kamera
und der gesamten Baugruppe nach hinten an,
um die Kameralinse nicht jedesmal durch die Frontscheibe fädeln zu müssen.
Dazu muss der Tiefsetzer auf die andere Seite, unter die Kamera.
Problem: Autonomie oder wenigstens Positionskorrektur anhand optischer Marker in weiter Ferne. Lenk- und Verwindungspoti zerstört durch ungeschicktes Anheben des Lasters. (Verwindungsbegrenzer aus Alu gefertigt.) Bei reiner Zeitsteuerung (Fahrantrieb, Lenkung) deutliche Abhängigkeit vom Ladezustand des Fahrakkus. Als Spielzeug konzipiert ist eine reine PWM-Servosteuerung drin und kein Istwertaufnehmer bspw. für Radumdrehungen, wie das bei Rasenmährobotern gemacht wird.
Lösung: (Gelöst)
Die ursprünglich vorgesehene Weitwinkel-Kamera („Fischauge“, 230326 gemessener horizontaler Öffnungswinkel 94°) für den Raspberry wurde schließlich durch eine „normale“ Kamera ersetzt und dafür ein Adapter + Halter konstruiert und 3D-gedruckt. Wichtig ist nämlich, dass die kleine Kamera nicht wackelt! Diese ist nämlich nur lose befestigt.
Am RaspberryPi4 scheint folgendes angeschlossen zu sein:
An seinem Pfostenstecker ist folgendes angeschlossen:
Peripheriebausteine: Ganz nach Arduino-Manier nichts selbstgebasteltes sondern ausschließlich gekauftes, was mechanisch nicht zusammenpasst, und dann irgendwie in wilder Verkabelung in das Fahrerhaus gepresst:
Idiotischerweise werkelt da noch ein Stereo-Soundgenerator, der das Geräusch eines startenden Dieselmotors, das Fahrgeräusch, Relaisklicken (beim Licht schalten) und den Rückfahrpieper nachäfft. Wie Dinosaurier in der Mondrakete.
Wie der originale Funkempfänger totgelegt wurde konnte nicht nachvollzogen werden. Das Totlegen ist schade, denn ohne Funkfernbedienung lässt sich das Auto nur umständlich mit dem Raspberry steuern, was gerade für die Inbetriebnahme von angebauter Sensorik (Überprüfung von Freiheiten) sehr umständlich ist.
Ist nicht obsolet.
Zum I-Bus siehe Abschnitt zum Originalcontroller.
Der Ultraschallsensor versagt nach einigen Minuten, an der seriellen Schnittstelle kommt nur noch Müll. Nur unter Python?
Deshalb mal eben schnell (gut, dauerte trotzdem 3 Stunden) ein C++-Wegwerfprogramm für Linux geschrieben und am hiesigen Barebone + USB-Seriell-Konverter getestet: Läuft völlig problemlos an einem Linux-Barebone.
Inzwischen gelöst durch Neuzuordnung der Raspberry-internen Schnittstellen zur externen: Beim Compute-Module liegt da standardmäßig eine sog. „Mini-UART“, die vermutlich per Energiesparmodus nach einiger Zeit mit falschem Bittakt gefüttert wird. Hier steht 'was dazu.
Weiteres Problem: Interferenz mit den Ultraschall-Abstandsmessern
von der Torsteuerung!
Da dieser vergossene Typ in keiner Weise synchronisiert werden kann
bleibt nichts anderes übrig als diesen vor dem Tor auszuschalten.
Dadurch entfällt dort die Hinderniserkennung.
Beim Einsatz der (einfachen, unvergossenen)
HC-SR04
wäre es ratsam sich über deren Synchronisierung Gedanken machen.
Will man die Schaltungstechnik behalten, geht das nur mit einem
hinreichend zeitpräzisen Funkkanal zum Schaltschrank.
Ansonsten wäre es ganz klar besser, wenn sich die Sensoren gefälligst
per Ultraschall „synchronisieren“
(= das Maul halten wenn jemand anderes sendet)
und nach Möglichkeit kodierte Signale verwenden:
Das schreit nach komplettem Neubau, zumindest für's Auto.
Und ist schon ein eigenes (studentisches?) Forschungsthema wert.
Bedienungsanleitung (PDF-Scan, 9 Seiten A4)
Konformitätserklärung
(PDF-Scan, 3 Seiten A4, identisch mit jener zum Muldenkipper)
Seriennummern: Fahrzeug: -, Fernbedienung: ?, Empfänger: 1G047204
Kein Licht leuchtet, der Magic Controller bekommt seine 6 V,
keine Spannung kommt da 'raus.
Verdacht: Im Magic Controller ist eine durchgebrannte SMD-Sicherung.
Dieser ließ sich vergleichsweise leicht ausbauen und aufschrauben.
Keine Sicherung drin, die kaputt gehen könnte, sieht alles OK aus.
Die 9 vermeintlichen Lampenanschlüsse sind nur 8 Ausgänge,
der vorletzte Anschluss macht 'was besonderes, und der letzte
geht nicht über den
ULN2003
sondern über einen gesonderten MOSFET.
Suchen nach „CXSTUDIO“ und „RC16-2“ bleibt ergebnislos. Also Bauteile recherchieren und Schaltplan erstellen:
Warum das Licht aus bleibt ist rätselhaft. Vermutlich gibt es eine Einstellmöglichkeit über die originale Funkfernbedienung, und es wurde „aus Versehen“ eine PWM-Folge generiert, die das Licht dauerhaft ausgeschaltet hat: Das Herumwursteln mit Closed Source ist und bleibt ein Martyrium!
Zum I-Bus siehe Abschnitt zum Originalcontroller.
Die ersten vier Zuordnungen (der Steuerknüppel) sind fix im Controller vorgegeben. Die Kanäle 5-9 sind im Controller-Setup konfigurierbar. Dabei ist bei beiden Spielzeugen die Hydraulikpumpe dem Kanal 5 zugeordnet, und der Controller lässt im sog. Mixbetrieb beim Betätigen einer Hydraulikfunktion (Lenken, Heben/Senken) den Kanal 5 mit hochlaufen, per negativer Mixangabe jeweils zu positiven Werten (die Hydraulikpunpe wird nie rückwärts betrieben).
Warum die beiden Spielzeuge dermaßen unterschiedlich (durch Verdrahtung und Controller-Programmierung) benutzt werden sollen ist mir unbegreiflich. Man vergleiche die beiden Bedienungsanleitungen. Naheliegend ist die Gleichschaltung, wobei der Radlader IMHO die naheliegendere Bedienphilosophie hat, also als Vorlage dient.
Gesucht und gefunden: Diskussion um die Hebelbelegung bei Flugmodellen (am besten Cookie-Nervrequester igorieren — nicht wegklicken — und zum Lesemodus wechseln)
Während der Bauma-Messe sind die Lenkservos beider Fahrzeuge
ausgefallen.
Sicherlich ist die Art der unveränderten „Regelung“ der Raspberry-Software
erheblich Schuld am Disaster, denn so liegt stets die volle Spannung
am Motor an, und es fließt meistens Kurzschlussstrom.
IMHO sollte der Programmierer von seiner Arbeit entbunden werden,
denn so haben wir allenfalls gegeneinander gearbeitet.
Denn es wäre allenfalls eine Zeile Kode zu entfernen gewesen,
die mit dem Math.sign()-Aufruf.
Und dafür hatte er einige Wochen (!) Zeit.
Andererseits kennt man Gleichstrommotoren normalerweise mit Kohlebürsten. Hier sind keine drin, nicht ein bisschen Kohle. Daher auch vergleichsweise sauber. Die Zuleitungsfedern sind bestimmt schlicht verglüht.
Da der (drahtlose) X-Box-Controller an häufigen Verbindungsabbrüchen leidet (selbst oder erst recht aus nächster Nähe) stellt sich die Frage, ob man den originalen FlySky-Controller irgendwie doch noch verwenden kann. Klar, das Abgreifen und Messen der bis zu 9 PWM-Signale geht immer, aber das ist die verdrahtungsintensive Holzhammer-Variante.
Zunächst wurde die Bedienungsanleitung zum Controller gefunden und durchgelesen. Da stand drin, dass man damit den Empfänger auf PPM-Betrieb umstellen kann: Statt 9 Drähten genügt 1 Draht, um an diesem Pulsabstände zu messen und den Kanälen zuzuordnen. Dazu muss man das Schloss-Symbol 2 s lang antippen (Touch-Screen!) und kann dann zu den Einstellungen, wo man vermutlich wer-weiß-was alles verstellen kann.
Zur Überprüfung der I-Bus-Daten habe ich ein kleines Wegwerfprogramm in C++ geschrieben.
Ausgelagert auf gesonderte Seite
Siehe auch Mathematik
Für die Erfassung „ob die Kuh vor'm Tor“ steht wurden die sattsam
bekannten Ultraschall-Entfernungsmesser
HC-SR04 oder so ähnlich
(nicht von mir!) ausgewählt und verbaut, und für deren Abfrage
ein Arduino Uno
(Schaltplan)
verschwendet.
(Eine vernünftige SPS könnte das auch,
müsste dazu „nur“ TTL-Ein- und Ausgänge aufweisen.
Aber TTL ist für Hutschieneneinklicker ein Fremdwort.)
Über die 3 m langen Leitungen mit nur TTL-Pegel und einer parallel
laufenden Motorsteuerleitung fängt sich das System alles mögliche ein.
Mit Widerständen habe ich eine Art Terminierung realisiert,
die sowohl Störungen unterdrückt als auch Arduino und die HC-SR04 schützen.
Im Arduino werkelt eine Gruselsoftware. Diese habe ich schon mal umgeschrieben und verkürzt. Dabei könnte der kaum ausgelastete Mikrocontroller ruhig noch etwas anderes machen! So zum Beispiel die gesamte SPS ersetzen und — wenn's denn unbedingt sein muss — OPC-UA „sprechen“. Hier wurde mal eben schnell ein 50 cm langes WS2812-Lichtband rangefrickelt, welches einfach Gleichlicht anzeigt. Dazu wurde kurzerhand die (übliche) Arduino-Bibliothek NeoPixel eingesetzt und das Projekt als .ino-Datei (aka Arduino-Projekt) belassen. Für ein ordentliches C++-Projekt müsste man NeoPixel selbst in die Hand nehmen. Dafür gibt es sogar deutsche Dokumentation.
Die „dicke Wurst“ zwischen Schaltschrank und Tor kann man IMHO niemandem verkaufen; das Kabel ist viel zu unhandlich und teuer. Richtiger wäre ein lokales Bussystem zwischen Steuerung und Tor. Dazu würde ich RS485 favorisieren, neben Profibus (ebenfalls RS485) und USB (mit RS485 verwandt). USB hätte den Vorteil, dass die Tore auch einzeln (am PC) angeschlossen und in Betrieb genommen werden können sowie dass es eine idiotensichere Steckverbinder-Norm gibt. Nachteil wäre dann, dass der Schaltschrank als USB-Host fungieren muss, ein entsprechend großer Mikrocontroller mit geeigneter Funktionalität wäre bspw. STM32F4xx. Daher plädiere ich für bimodale Tore, USB und RS485 auf den gleichen Leitungen.
Die Schaltschränke und Tore 🙈:
- Zusammengesetztes Kabel zwischen Siemens-Steuerung und den Toren zwecks Abschirmung zu den Sensorleitungen.
Rückgebaut, durch Terminierung obsolet- Auf der Arduino-Platine für Siemens waren die Ausgänge Sensor1 und Sensor5 vertauscht. Dadurch chaotische Zuordnungen.
Korrigiert in Hard- und Software- Die gemeinsame Triggerleitung wurde durch übersprechsichere getrennte Triggerleitungen ersetzt. Der Arduino-Bastler wusste offenbar nicht, dass die mit A0..A5 bezeichneten Anschlüsse auch digital sind.
- Die Arduino-Software wurde online entwickelt. Diese war mit diversen
delay()s gespickt und gähnend langsam.
Faktisch komplett neu geschrieben- Die mechanische Fertigung des Schaltschrankes lässt zu wünschen übrig. Unpassende Clip-Befestigungen zur Wandstärke, Netzstecker unisoliert. Schräg sitzende Stehbolzen, irrsinnig wenig Platz hinter dem Netzstecker. Der (Koffertransport-)Griff ist zu tief, unbequemer Transport.
Neukonstruktion s.u. am Netzstecker, weil sicherheitsrelevant. Leider musste einer der Netzstecker geklebt werden, weil Rastnasen abgefeilt(!!) waren. Lüftergitter durch Schrägfeilen des Schaltschrank-Ausbruchs fixiert. Der Rest bleibt so, merkt hoffentlich keiner.- Die Schaltschränke sind unterschiedlich, und in beiden Fällen stimmt der Schaltplan nicht. Alle 4 Tore sind unterschiedlich.
Korrigiert und gleichgezogen. Massive Arbeit- Beschriftungen fehlen oder sind unleserlich. Wacklige Not-Aus-Beschriftung. Not-Aus lässt sich drehen, Verdrehsicherung unwirksam.
TODO: Neuerstellung. Echtes, passendes Not-Aus-Schild (kaufen?)- Der Schaltplan wurde nur gedruckt und verschmiert ausgehändigt und enthält viele Dopplungen.
Mühselig verglichen und Dopplungen entfernt. Der Schaltplan existiert als vertrauenswürdiges Original nunmehr nur in Papierform mit PDF-Kopie:
- Schaltplan 60 cm breiter Schaltschrank (2×) 11 Seiten A4 quer
- Schaltplan 40 cm schmaler Schaltschrank (1×) 1 Seite A4 quer
- Schaltplan Tor (4×) 3 Seiten A4 quer
- Kein Zugang zur Schaltplan-Quelle.
TODO: Neuerstellung- Die Schaltschrank-Innenbeleuchtung wurde in einem (ach-so-tollen papiernen) Konzept vorgesehen und dann komplett vergessen.
Ist eingebaut. Über verdrehsichere dreipolige PSK-Stecker auf der Arduino-Platine angeschlossen und mit 5 Volt versorgt.- Es fehlt immer noch die dritte Steuerung, zwei Netzeinbaustecker-Sicherung-Schalter-Kombinationen sowie die Zierecken für den dritten Schaltschrank.
Erledigt. Fehlt noch die SPS sowie ein Teil des Harting-Steckers: Wird nachgeliefert.- Unnötige Löcher (2× USB-, 1× Ethernet-Durchführung, 2× M12-Buchse)
M22: Erledigt mit Blindstopfen als 3D-Druck, TODO bei M12-Buchse
Conrad Stück Bestellnummer EVP/€ Beschreibung 2 501638-VQ 4,89 Snap-In-Netzbuchse 1 1990799-VQ 13,99 19300061541 Steckergehäuse 1 749623-VQ 22,99 09160243001 Stecker - lieferbar in 4 Wochen 4 749296-VQ 0,99 09150006101 Steckstifte Crimp 1 1990309-VQ 18,99 09300060301 Buchsengehäuse 1 749637-VQ 21,99 09160243101 Buchse 4 749478-VQ 1,29 09150006201 Buchsenstifte Crimp 1 749469-VQ 0,42 09330009915 Kodierstift Item 8 0.0.627.60 a.A. https://www.item24.com/de-de/verbinder-abdeckkappe-8-r40-90-grau-aehnlich-ral-7042-62760/
Wie auch immer man so einen Arduino Uno tot bekommt: Vermutlich durch Speisung mit 24 V und Verpolung. In diesem Fall war der Mikrocontroller ATmega328P zwar nicht tot, fraß aber mit 200 mA viel zu viel Strom. Außerdem war der Längsregler tot: Wurde ersatzlos ausgelötet, weil das Board künftig mit gesonderten 5 V per USB gespeist wird. Als Ersatz wurde (natürlich ohne mich zu fragen) ein neuer Arduino Uno gekauft; diese Platine wurde schließlich mit getauschtem und mit Caterina-Urlader betankten Mikrocontroller in den dritten Schaltschrank nur zum Initialisieren der WS2812-Innenbeleuchtung verbaut: Verschwendung!
Ein Not-Aus-Taster für den Betrieb am Steuerungscomputer (Laptop) ...
Dass der im Schrott vorgefundene Eisenabschnitt nicht auf Anhieb in den reichlich dimensionierten Durchmesser des 3D-Druckteils passt liegt am Schrumpfungsprozess des 3D-Druckteils von 100 auf 99,5 mm: Nacharbeit an der Drehmaschine.
Die Firmware für ATtiny25 und V-USB. Der Schaltplan ist trivial und im Firmware-Quelltext angegeben. Inzwischen (November 2022) wurde die Schaltung wieder entfernt, der Quelltext ist historisch. Denn so kam die Grapefruit nie zum Einsatz, niemand sah sich imstande, die Steuersoftware mit dieser Not-Aus-Funktion zu ergänzen. Also nachträglich vielen Dank für die fruchtlose Zusammenarbeit.
Der mühsam erarbeitete Ansatz mit der Software-PLL musste verworfen werden.
Damit entfällt die Echtzeituhr und die Batteriestütze.
Der ATmega stürzt unvermittelt ab oder macht sonstwas,
wenn er in gestörter Umgebung mit RC-Oszillator läuft,
egal ob mit oder ohne PLL.
Der Jitter ist (vermutlich nicht nur für die serielle Schnittstelle)
einfach zu groß.
Was nicht dokumentiert ist, und womit nicht wirklich zu rechnen war!
Es war einfach zum Verzweifeln!
Immer wieder Abstürze mit irrsinnigen Fehlfunktionen.
Schließlich wurde ein Baudratenquarz eingesetzt, und alles läuft wunderbar.
Bis auf die Echtzeituhr, die ist erst mal totgelegt.
Und der Controller braucht etwas mehr Strom.
Zusätzlich wurde der MOSFET überbrückt und ein Elko spendiert.
Nun wackeln die A/D-Wandler nicht mehr so elend.
Am (fehlenden) Reset-Pullup hat's nicht gelegen.
Der Brownout-Detektor wurde aktiviert.
Ein Pin wird frei.
Konsequenz: Die störärmere Speisung der Potenziometer mit AUCC
wurde eingebaut. Dazu Tiefpasskondensatoren.
Und der „riesige“ Quarz.
Die Eingänge des AVR lassen sich nicht als Schmitt-Trigger gebrauchen.
Daher ist eine rein passive Impulsfilterschaltung unmöglich,
und es muss/sollte für den Tacho die „bewährte“ Schaltung
vorgesetzt werden.
Inzwischen gruselt's mir vor einer Software-Lösung, und ein paar
Einzelgatter habe ich noch 'rumliegen.
Konsequenz: Erfordert Platinentwurf, und da kommt gleich mal der
piepslige DCK-Typ mit 0,65 mm Pinabstand weg.
Die Servo-Stecker drängeln. Böser Verdacht:
Der Pinabstand am Fernbedienungs-Empfänger ist nicht 2,54 mm.
Tatsächlich!! Der Spezial-Pfostenstecker hat einen Pitch von 2,64 mm!
Gibt's nirgendwo zu kaufen.
Deshalb hat sich Adafruit (?) damit beholfen, die PWM-Ausgänge
im Viererblock anzuordnen, um weniger zu drängeln.
Sie wussten das also. Irgendwoher.
Konsequenz: Wurde im Platinentwurf beachtet.
Drängelt immer noch, aber es ist alles steckbar.
Dass der Löffel (Schaufel) des Radladers nicht unabhängig
von der Stellung des Hubarms steht ist anzunehmen und
vermutlich vorbildgerecht.
Aber das Viereckgelenk für den Löffel
hat eine Unstetigkeit (nennt man das so?):
Das Heben des Arms funktioniert nicht mit komplett heruntergeklapptem
Löffel, es klemmt bei 3/4 der Hubhöhe.
Na gut, kommt eher selten vor,
aber so ist die Kinematik nicht kollisionsfrei!
Ein Regler würde sich „zu Tode regeln“.
Konsequenz: Das ist vom Anwender (I²C-Master) zu beachten.
Aus dem Schneider bin ich mit der Wahl des ATmega48
in Durchsteck: So ließ sich bei mangelndem Flash-Speicher
(nur wegen Gleitkomma, später unnötig) schnell auf ATmega328 „aufkeulen“.
Konsequenz: Auch der Platinentwurf verwendet den Durchsteck-Typ.
Obwohl man mit SMD mehr Platz und 2 A/D-Wandler mehr hat,
mit ATmega328B sogar mehr Ein-/Ausgänge.
Mal schnell dem Raspberry das Zerstören der µ-SD-Karte austreiben
ist immer noch ungelöst!
Hier wird ein Raspberry mit angeschlossenem 7"-Touchscreen eingesetzt.
Mit vcgencmd otp_dump kann man den OTP-ROM auslesen,
und irgendwie kann man den auch setzen (von wegen One-Time).
An Adresse 17 ist (angeblich) folgendes DWORD:
Mit dem Standardwert 0x1020_000A und dem zu setzenden Wert
0x3020_000A
Schon geradezu zu erwarten ist, dass das Setzen von Bit 29
umständlich-verrückt ist:
Unter [all] ist in /boot/config.txt die Zeile
program_usb_boot_mode=1 einzubauen,
und (von SD-Karte) neu zu starten.
Das setzt das Bit 28.
Erst ein paar Tage später kam ich schließlich zur Funktion:
Oh, ein ATmega-Bug! Oder zumindest ganz schön unterdokumentiert:
Bei Slave-I²C-Ausgabe kam es sporadisch zu fälschlich gesetztem Bit 7
beim Raspberry als Empfänger.
Das brachte mich auf die Idee, dass:
Abhilfe schafft ein „verlängertes“ Clock-Stretch, ein Delay von
4 Mikrosekunden, zwischen dem Schreiben von TWDR
und TWCR
Weitere Probleme mit I²C bestehen weiterhin:
Oh, ein Raspberry-Bug!
Hier ist's beschrieben:
Auch wenn Broadcom beteuert, dass das I²C-Interface
I²C-kompatibel ist, das ist auch beim Raspberry Pi 4 nicht der Fall!
Mit dem Oszilloskop auf der Fehlersuche sah das Signal
1A wie aus dem Bilderbuch aus:
Keine verschliffenen Flanken, keine Überschwinger, Vor- und Nachhaltezeiten
korrekt wenn auch manchmal grenzwertig.
Aber wehe wenn der ATmega mit seinem Clock-Stretch kommt,
da gibt es Takt-Nadeln! Getestet mit Raspberry Pi 3B+.
Die angepriesene Lösung mit dem Pingpong-Treiber
ließe sich sicherlich verbessern, wenn man Einzelbytes
mit der Broadcom-I²C-Hardware senden/empfangen könnte,
also ohne Start- und Stoppsequenz.
So wie beim ATmega. Das ist aber (erst mal) nicht mein Bier.
Das klappt sogar mit …delay_us=1 und ergibt ca. 330 kHz SCL-Takt.
Mit dem 1 m langen Kabel sind die Flanken etwas abgerundet,
trotzdem ist die Kommunikation fehlerfrei. Nein!
Bis auf das Problem, dass beim ATmega manchmal SDA(!) auf Lo klemmt.
Muss noch geklärt werden; bis jetzt ()
tut's eine Watchdog-Routine (via OCR2B) in der Firmware auflösen.
Achtung: Die neue Testsoftware öffnet standardmäßig /dev/i2c-3!
Für die (immer schon vorhandenen aber nun massiv,
vor allem bei Mausbewegung) auftretenden Kommunikationsfehler
wurde die Raspberry-Software mit einem Debug-Ausgang versehen,
der derzeit nur manchmal funktioniert.
Aber wenn, dann gibt es tatsächlich auch ein Problem!
Lösung: i2c_gpio_delay_us=2
muss es sein!
=1 geht nicht!! (Hier: Raspberry Pi 3)
Wer auch immer solche Kernel-Module baut!
Dadurch sinkt die SCL-Frequenz von 330 kHz auf 200 kHz,
und die mittlere Gesamt-Abfragedauer des Testprogramms
(alle Schichten) beträgt 8 ms.
Drei Wochen später: Oh nein! Es geht immer noch nicht!
Der Fehler ist nur seltener geworden, ca. aller 5 Minuten einer.
Die Möglichkeit der Vollgrafikausgabe bewegte mich zunächst nach
X11.
Immerhin hatte ich dafür mal vor langer Zeit (um 1997) ein Programm erstellt:
Einen Videotext-Archiv-Betrachter.
Geht heute noch.
Auch damals bin ich über das Problem mit den mangelhaften Fonts gestolpert,
aber auch heutzutage gibt es keine funktionierende UTF-8-Unterstützung
und keine proportionale Schrift, die ansehnlich ist.
Weder auf dem Raspberry lokal, noch unter Xming für Windows,
der die Windows-Schriften verwenden könnte.
Wie ich (durch das Studium veröffentlichter WireShark-Protokolle) herausfand,
generieren moderne X11-Anwendungen (etwa Firefox) die Schrift selber
und übertragen das gesamte Bild per bitblt.
Na schönen Dank auch!
Das benötigt massiv Netzwerk-Bandbreite und ist für die Remote-Darstellung
schnell veränderlicher Werte so ziemlich ungeeignet.
Ein X11-Beispiel
für eine einfache, mehrsprachige MessageBox
funktioniert bei mir auf Teufel-komm-raus nicht.
(Jedenfalls nicht für andere Sprachen außer 7-Bit-Englisch.)
Schade auch dass weder Putty noch LXTerminal keine
ReGIS-Grafik unterstützt,
was wenigstens ein bisschen weiterhelfen würde.
Wäre brauchbar um Oszillogramme darstellen zu können.
Der Notbehelf Braille-Zeichen
ist zu grobpixlig und hat Farbprobleme wenn sich mehrere Grafen schneiden.
230504: Nun ist mir schon zum zweiten Mal ein ATmega328P
über den Weg gelaufen, der eine erhöhte Stromaufnahme zeigte!
(100 mA bei 4 V, 70 mA bei 3,3 V, normal 7 mA.)
Diesmal versagte auch der Pullup an ICP = PB0.
(Der erste war aus dem Arduino des Schaltschranks.)
Entweder war es derselbe (ich hatte den aber IMHO weggeworfen recycelt)
oder die ATmega328P sind empfindlicher (auf was?) als ich dachte.
Ein Glück dass genügend herumliegende Arduinos für schnellen Nachschub sorgen.
230509: Huch? Die zweite USV X728 hat einen anderen Mikrocontroller.
Dieser sieht wie ein umgelabelter ATtiny45-SO aus. Denn die
„überraschend breiten Flatschen“ gab's nur bei Atmel.
Und IMHO nur bei ATtinyX5,
nicht beim (hier sicherlich mehr als ausreichenden) ATtiny13.
Immerhin, der Bug mit dem prellenden Taster tritt hier nicht auf.
Da hat man wohl nachgebessert.
Huch? Eine dritte USV gleichen Typs sieht schon wieder etwas anders aus und hat als Chip wieder den (geratenen) PIC12F508. Also hatte man ein paar Cent Kosten gespart, und die Version mit dem (etwas teureren) ATtiny45 ist die alte Version.
230704: Der Raspberry-4-Compute ist endlich da. Ich hatte einen zerstört, als ich mit Tastspitzen am GPIO-Header der Trägerplatine abgerutscht bin. Zerforscht sozusagen. Für 120 €, nicht wie sonst 39 €. Obendrein eine Light-Version ohne WLAN. Der Unterschied als Foto. Findet keine SD-Karte! Ein Bug?
