CMOS-Dezimal-Counter- bzw. -Teiler-Kaskade in Bascom umsetzen

An dem Code wird ja immer mehr rum-gefrickelt.
Sieht für mich auch ziemlich planlos aus.

Bei jedem Problem (z.B. Tasten sperren/freigeben usw., Heizung abschalten, wie) wird wieder was neues dazu gefrickelt.
Und das geht schon die ganze Zeit so.

Der arme @delatube ist bestimmt schon komplett verwirrt.

@ceperiga hat es auch schon anfangs erwähnt, mal einen Plan zu machen, was da wie nacheinander passieren soll.
Damit ihr nicht im Wald steht hab ich mal so ein Diagramm gezeichnet, wie das aussehen könnte.
Das ist natürlich jetzt nur meine Interpretation aus den Forums-Beiträgen.
E1T-Uhr-Ablaufplan.pdf

Ich persönlich bin ein Freund davon, den Ablauf tabellarisch zu machen, weil es doch einfacher zum Editieren und Erweitern ist.
Zudem kann man mehr Details reinbringen.

Hier meine Ablauf-Tabelle.
E1T-Uhr-State-Tabelle.pdf

Wie das jetzt programmtechnisch aussehen könnte, könnte ich jetzt auch zeigen.
Ich gehe aber davon aus, dass ihr noch weiter-frickeln wollt?

Freut mich, dass dich mein Ansatz interessiert.

Nun, mein Ansatz weicht von deinem schon deutlich ab.
Denn ich überlege erst mal, bevor ich anfange, was das Programm tun soll.
Die Tabelle hast du ja gesehen. In der Spalte links sind die Phasen, in der sich das Programm befinden kann.
Die muss man sich überlegen und sinnhaft benennen.

Im Fach-Chargon nennt man die Phasen aus Zustände bzw. States.
In der Hauptschleide werden die Zustände mittels Select Case auseinander gehalten.
So kann man ober eine Variable bestimmen, welcher Codeabschnitt (State) ausgeführt wird.

Um Zustände zu wechseln bedarf es ein Auslöser. Das kann eine Taste sein, ein Timeout oder ein Signal.
Und dann wird bestimmt, mit welchem zustand es weiter gehen soll.

Die ganzen Routinen, die man dazu noch braucht, sind thematisch in sogenannte Module ausgelagert, die man einfach einbindet.

Ich zeig dir mal die Hauptdatei (Main.bas).

Hier noch der Rest (Nachricht zu lang)

Ab Zeile 32 siehst du die Module, die ich einbinde.
Dort sind also die ganzen Routinen für den Betrieb untergebracht. Damit ist der Ballast aus dem Hauptprogramm weg und macht es übersichtlich nachzuvollziehen.

Z.B. findest du im Modul 'Tasten.inc" die Abfragen der Tasten. Diese liefert true, wenn sie gedrückt werden. Diese Tastenabfragen machen auch nur das, Taste abfragen, sonst nichts. Dadurch kann man die tasten auch in anderen Zuständen mit anderen Funktionen belegen, one Code zu ändern.

Im Modul "FSM.inc" sind die Hilfsroutinen, mit denen ich die Zustände umschalte und abfrage.

Im Modul Config ist die Konfiguration abgelegt.
Also Konstanten für z.B. Timeouts für Vorheizen, Abkühlen oder die Aliasnamen für die Pins.

Die Hauptschleife geht ab Zeile 61 los.
Dort ist der ganze Programmablauf kodiert.

Die Zustände findest du in der Tabelle wieder und auch die Trigger (Tasten, etc.), die die Zustände umschalten.
Das nennt sich Statemachine. Ich habe dazu ein Tutorial geschrieben. Du findest es im Lexikon.

Durch das Aufteilen des Programmablaufs in Zustände, kannst du in jedem Zustand genau bestimmen, welche Tasten abgefragt werden sollen, wie darauf reagiert werden soll, oder was ein oder auszuschalten ist. Im Grunde ganz easy.

Vergleiche mal die Tabelle mit der Main-Loop. Ich denke, dann wird klar was ich meine.

Eine Besonderheit gibt es noch zu den Routinen der Statemachine.
Wenn ein State mit 'SetState(neuerZustand)' gesetzt wird, wird auch ein Flag gesetzt, dass der Zustand geändert wurde.
Die Abfrage StateChanged() fragt dieses Flag ab und löscht es sogleich. Heißt, nach einem Zustandswechsel
wird die erste Abfrage StateChanged() True sein, weitere Abfragen sind Fals, solange der Zustand nicht wieder neu gesetzt wird.

Das nutze ich in der Hauptschleife aus, um einmalige Aktionen bei einem Zustandswechsel auszuführen.
Das ist ein nettes Feature, was oft nützlich ist.

Das wäre also mein Ansatz.
Wie gefällt er dir?

Hat jetzt nichts direkt mit dem Thema aber mir ist aufgefallen dass es auch ohne "Call" funktioniert. Ist das schlampig von mir?

Entweder mit Call und immer mit Klammer, auch wenn keine Parameter übergeben werden,
oder ohne Call und dann auch die Klammern weg lassen.

Beides ist in Bascom zulässig lt. Hilfe.

Nicht so schön ist, wenn man das in einem Projekt vermischt, also mal so dann anders.
Man sollte sich für eine Variante entscheiden und diese dann konsequent einhalten.

Ganz schlecht ist, wenn man Call verwendet und die Klammern weg lässt, weil man keine Parameter zu übergeben hat.
Syntax-Technisch ist das falsch und könnte irgendwann mal mit Fehler quittiert werden, wenn der Compiler genauer drauf schaut.

Ich kann der Frage nicht so recht folgen.
Was genau kannst du nicht nachvollziehen?
Was genau willst du jetzt sehen?

Im Grunde liest sich das Hauptmodul (Hauptschleife) wie ein Buch (für mich zumindest).

Wenn da steht Key_Power() oder Key_Hour(), dann wird da eine Taste abgefragt. Im ersten Fall die Taste zum an/aus Schalten, im 2. Fall die Stunden-Taste.

SetState(..) setzt eunen neuen Zustand, GetState() fragt den ab.

TO_Timeout() setzt einen Timeout und TO_Elapsed() liefert True, wenn abgelaufen.
Im Grunde stehen die Kommentare daneben.

Kannst du deine Frage konkretisieren?

Die Taster-Abfrage ist in dem Modul Taster.inc untergebracht. Dort ist auch das Debounce in den Routinen verbaut.
Im Hauptprogramm ruft man also nur das Ergebnis der Entsprechenden Tasten-Abfrage ab.

Wie gesagt, das ist in den Modulen untergebracht.

Oft sind Variablen für einen bestimmten Zweck angelegt.
Das sind z.B. die Variablen für Sekunden, Minuten und Stunden. Sowas lege ich im Modul mit ab. In dem Fall das Modul Time.inc.
Dort ist auch die ISR für die Zeitbasus zu finden und die Timer-Deklaration.
Im Grunde ist alles ausgelagert in Subs oder Funktionen, die thematisch zusammen gehören in ein Modul.
Damit wird die Hauptdatei nicht so überladen mit Code.

Schließlich muss man ja nicht ständig den Code von einer Routine sehen. Es reicht zu wissen, dass es sie gibt und welche Parameter sie braucht und evtl. was sie zurück gibt. So ist es ja z.B. bei den Tasten.

In der Hauptschleife werden dann nur die Routinen in den Modulen aufgerufen und das Ergebnis verarbeitet.

Hast du mal in das Tutorial reingeschaut?
Dort ist das Prinzip erklärt.

Mir ist klar, dass du Anfänger bist und hier vielleicht nicht gleich durchsteigst.
Das verlangt auch keiner.

Ich bin lediglich deiner Bitte nachgekommen, meinen Ansatz aufzuzeigen. Und das habe ich ja versucht.
Wenn du konkret fragst, kann ich auch konkret antworten.

Mit der Auskunft Anfänger zu sein gibt es ziemlich viel Spielraum für Spekulation. Man kann gar nichts können oder man kennt Bascom, aber weis es nicht anzuwenden. Es gibt mehrere Formen, wie man Anfänger definiert. Kurzum, ich weiß nicht, was du weist, auf was ich aufbauen kann, und was du nicht weist.

Ich stehe da auch im Wald.

Deswegen gibts ja ein Forum.

Was der Befehl $Include macht, und was eine INC-Datei ist, weist du aber, oder?
Select Case kennste auch und weist wie es anzuwenden ist?

Wo hakt es?

Na ja mit Übersichtlich hat das nun gar nichts mehr zu tun. Eine aufgeblähte Main in der man vor lauter 100buchstabenvariablen/Aliase/Subs kaum noch durchblickt. Dazu sehr viele unnötige Sprünge in noch unnötigere incs, so das man drei Monitore braucht um das zu erkennen was in Deinem ersten Code auf einer Seite sofort zu sehen war. Nun ist ja genug Zeit und Flash da, da kann man auch aasen.

Ps weiß jemand was das weiße Kästchen da macht? bzw wie das gelöscht werden kann?

Das sind keine unnötigen Incs. Alle Routinen darin werden von dem Programm benötigt.
Aber alles in die Main zu packen macht es nur unübersichtlicher.

Zudem benennt man Routinen so, dass man daraus die Funktion erahnen kann. Wenn eine Routine geschrieben ist und funktioniert, braucht man nicht mehr reinschauen. Im Grunde ist es dann egal wie sie ihre Arbeit macht. Wie bei Libs.

Oder hast du den Code von der mcs.lib auch parallel auf wenn du Routinen daraus verwendest? - Sicher nicht, vielleicht in Ausnahmen.
Und genau so kann man die Module auch sehen. Wie eine Lib, die eben noch als Quellcode vorliegt.
Sie hat notwendige Routinen, die eben gerade wichtig sind.

Zudem können Module, je nachdem wie man sie auslegt, auch in anderen Projekten verwendet werden.
Nach Deiner vorherrschenden Methode, frickelst du jedes mal aufs neue.

Ich denke ich muss mich nicht rechtfertigen. Meine Projekte funktionieren nach der Methode sehr gut. Man hat volle Kontrolle über das Programm und sein Verhalten und muss nicht mit irgendwelchen Effekten rechnen, weil man zu einem ungünstige Zeitpunkt eine Taste gedrückt hat. Im Vergleich zu der Methode, wie du sie anwendest, habe ich heute viel weniger Probleme. Zugegeben, es ist etwas langsamer, was dich vermutlich furchtbar stört, aber hier ist alles unkritisch.

Aber es muss jeder selber wissen und die Erfahrung machen. Ich habe meine gemacht. Daraus sind auch diese Methoden entstanden.
Im übrigen ist Statemachine, falls dich das auch stört, Pflichtfach bei Informatik-Studenten. Und das nicht ohne Grund!
Auch das modulare Programmieren und das erstellen von Zweck-bezogenen Routinen/Algorithmen, die jede ihre Aufgabe in dem Projekt hat, gehört dazu.

Muss jeder selber wissen. Ich frickel jedenfalls nicht gerne. Mir ist wichtig, dass der Code sauber läuft und nicht zickt. Und das erreicht man mit dieser Methode.

Das erklärt so einiges.
Ich bin davon ausgegangen, dass du die meisten Bascom-Anweisungen kennst.
Das ist zum effektiven Programmieren natürlich essenziell.

An dieser Stelle macht es vermutlich wenig Sinn für dich das Tutorial anzusehen. Kannst aber trotzdem rein schauen.

Ich empfehle dir mal die Befehle, die es in Bascom gibt anzuschauen. (Bascom-Hilfe)
Dabei meine ich die Sprachbestandteile von Basic selbst und nicht unbedingt UART I2C und ähnliche Features.

Sondern was macht/wie funktioniert $Include <Datei> oder die Anweisung Select Case ...
Das sind Sprachbestandteile die man immer wieder braucht.

Genauso wie For Next, While Wend , Do Loop usw.
Aber auch Berechnungen (Grundrechenarten), Vergleiche und binäre Verknüpfungen (Und Oder Not Xor).

Wenn man ein Problem (Projekt) in Code formulieren soll. Ist es ganz schlecht, die Sprachbestandteile nicht zu kennen.
Das wird das kaum was (gescheites) werden.

Später kommen dann bei Bedarf andere Features dazu wie Timer und Interfaces vom Controller.

Wenn du in deinem Projekt ein RTC-Modul anbauen willst, musst du wissen, welche Schnittstelle dafür benötigt wird. Meist I2C, aber es könnte auch SPI-Interface oder Uart denkbar sein. Ich will jetzt nix verkomplizieren, aber sowas muss sitzen, oder man muss wissen, wo es steht und es dann verstehen.

Gerade für Anfänger / Einsteiger in Bascom gibt es einige Bücher. Die Hilfe finde ich da nicht so die 1. Wahl. Eher als Referenz.
Ich hatte mir damals das Buch "Programmieren der AVR Risc Mikrocontroller" von Claus Kühnel gegönnt. Es gibt aber auch andere.

Um meinen Ansatz zu verstehen musst du auch wissen, wie man Funktionen Schreibt, die einen Rückgabewert liefern und wie das mit Sub-Routinen geht.
Denn ich verwende diese Technik fast ausschließlich. Labels sind bei mir nur in Ausnahmen zu finden.

Eine Ausnahme findest du z.B. in den Key_Routinen, weil ich da Debounce verwende und das verlangt ein Label.

Als ich damals mit Bascom angefangen habe, habe ich mir nicht gleich ein Projekt vorgeknöpft. Das wäre kläglich gescheitert.
Vielmehr habe ich als erstes mal eine LED an einem Pin blinken lassen. Dann mit Taster kombiniert, um die LED zu schalten.
Und so kam eins zum anderen. Ich habe also erst mal gelernt mit den Befehlen und auch mit der IDE umzugehen.
Erst dann als ich mir mehr zugetraut habe, ging ich an kleine Projekte, die sich steigerten.
Darunter war so als Highlight auch ein Ambilight für TV, welches das Bild analysiert und in Echtzeit die Farbe hinter dem Fernseher per LED an die Wand strahlt.
Als 2. Highlight brauchte ich dazu ein Bildgenerator, der mir ein dauerhaftes Testbild lieferte, um die Justierung des Ambilight durchzuführen. Der Testgenerator schafft heute so an die 20 Testbilder, zuschaltbaren 1kHz Ton (sinusähnlich), Umschaltung BAS und RGB über Scart und auch eine 16:9 Umschaltung. Alles mit einem einigen Controller 16MHz getakteten. Inkl. Display und Menüsteuerung.

Das Ambilight bestand aus 5 Controller, die per I2C-Bus verbunden waren.

Aber was red ich da rum.
Aller Anfang ist bekanntlich schwer.