Labornetzteile mit Arduino programmieren

[Holomino]

Hmm, meine letzten Displayanwendungen für Controller liefen immer nach dem gleichen Schema:

Eingänge (Peripheriewerte, Tastaturereignisse, Schnittstellentelegramme, Maskenwechsel und zeitgesteuerte Trigger für z.B. Animationen oder das Cursorblinken) festlegen und damit eine gemeinsame Schnittstelle für alle Bildschirmmasken definieren. Beispiel: Die Routine zur Abfrage der Tastatur ruft bei erkanntem Tastendruck die Funktion ActiveMask.KeyIn(int keyNum) auf.

Ausgänge (Displayinhalt, Peripherie-/EEPROM-Werte, LEDs, Buzzer, ...) in einzelnen Modulen abstrahieren und entsprechende Funktionen zur Verfügung stellen. Z.B. Display.WriteText(string s, int x, int y, bool reverse)

Zwischen Ein- und Ausgänge quetscht man nun die Bildschirmmasken. Objektorientiert würde man wohl zuerst eine Basisklasse mit abstrakten oder virtuellen Methoden für die Eingänge programmieren und anschließend die eigentlichen Bildschirmmasken jeweils davon ableiten. Mit Standard-C geht es über das Anmelden von Callbacks, also Funktionszeigern.
Letztlich aber leitet man so bei beiden Methoden über das Setzen der "ActiveMask" alle Eingänge auf die aktive Bildschirmmaske. Die Maske kann dann im Code selbst entscheiden, ob sie z.B. ein PeripherieValueChanged(pvData* data) überhaupt in der Ansicht hat und entsprechend reagieren muss.

Vom Programmablauf gesehen kannst Du Dir das dann so vorstellen:
Die Abfrage Deiner Eingänge per Loop oder Interrupt bilden das zeitliche Rückgrat Deiner Applikation (den Zyklus). Das Ergebnis der Abfrage eines Eingangs wird per entsprechender Funktion an die aktive Bildschirmmaske weitergeleitet, die ihrerseits Ausgänge manipuliert. Die Bildschirmmaske selber hat aber keine Loop und wartet auch nicht. Sie bremst also die Eingangsabfragen nicht aus. Einen Eingabewert aus mehreren Tastendrücken z.B. muss sie über eine Statemachine (max. Anzahl Eingabestellen + Eingabeüberprüfung) aus den einzelnen Aufrufen von KeyIn(int keyNum) zusammensetzen. Das ist zwar kompliziert, hat aber den Vorteil, dass man auf dem Display einen Sollwert editieren kann, während zusätzlich dargestellte Istwerte sich laufend aktualisieren.
Das gleiche gilt für die Ausgänge: Das Schalten einer LED verursacht sicherlich keine zeitlichen Verzögerungen. Beim Aktualisieren des gesamten Bildschirmes kann es Optimierungsbedarf geben (nur aktualisierte Bildschirminhalte ausgeben, ggf. das "Übersetzen" von Text in Pixel in die Loop der Eingänge übernehmen). Also auch diese Aufrufe kurz halten und nichts einbauen, was die Eingangsabfragen bremsen könnte.

[DerDieter]

Hallo Holomino, ich danke dir für deine Ausfühung.
Momentan ist das ganze bei mir so aufgebaut:
Das der Haupt-Sub den Ablauf ohne irgend ein Delaiy beständig durchläuft.
Der Encoder wird aber zusätzlich über Interrupt gesteuert und dient zur Feineinstellung von Strom und Spannung.
Dann wird die Tastatur abgefragt, falls Änderungen vorhanden sind wird ein Unterprogramm abgearbeitet.
Danach wird mit 16bit jeweils für Strom und Spannung der Wert ùber I2C der DAG (danach OP) eingestellt.
Dann ermittelt ùber I2C ein INA-Modul Strom und Spannung.
Die Aufrufe finden immer in Unterprogrammen statt.
Dann folgt das Unterprogramm für die OLED Ausgabe.
Was jetzt noch kommen muss wäre eine genaue Anpassung von der Spannung der sich ja bei verschiedenen Ampergrõßen ändert. Also ein Abgleich von Istvolt zu Sollvolt.
Der Kurzschluss und die Amperabweichungen werden analog vom Netzteil ùber OP und Shunt geregelt.
Auch habe ich CV CP und constant Wiederstand noch nicht berücksichtigt.
Was auf jeden Fall auch noch eingebunden werden soll ist ein 5" Nextion Display wo auch Vorgaben gemacht und die Ausgabe erfolgt.
Die OLED fallen dann weg die sind nur zum Testen