Wir kommen vom Thema ab. Ich denke, ich habe mit dem zweiten Spannungsregler, welcher die LCD-Anzeigen, den TTL, und CMOS-IC versorgen das Problem mit den Abstürzen erschlagen, werde es aber noch beobachten.  Mit der Spannungsversorgung dachte ich, ob ich diese von der Schatung nehme, oder ein seperates Netzteil verwende. Ich muß mal sehen, was die Relaiskarte an Strom zieht und das ich keine Störinpulse auf die Schaltung übertrage. Mit dem Portbeistein sehe ich keine Probleme bei der Programmierung, da ich schon kompliziertere Sachen programmiert habe, außerdem benutze ich schon SPI auf der Karte, ich nuss nur die CS-Leitung am 74373 programmieren. 
Als Funkverbindung würde ich Wlan verwenden, das kann man gut mit einem ESP32 programmieren. Falls du kein Wlan, hast, kannst Du das mit einem alten Handy realisieren.

Zitat von: pic18 in 01.11.2024, 23:38:07 CETWahrscheinlich mehme ich den MCP23S17. Da muss ich mir noch überlegen wie ich das mit der Spannungsversorgung realisiere.

Zwecks des "Auf-Null-Setzens"...... In einem Programm habe ich gaaaanz furchtbar viele Werte in einer Tabelle. Das Reinschreiben dieser Werte erledigt bei allerersten Start des Progs eine entsprechende Schreib-Routine. Nach Abschluss des Schreibens beim ersten Male soll das nicht bei jedem späteren Neustart erfolgen. Deshalb wird bei jedem Start zuallererst ein gezielt ausgesuchter Speicherplatz in dieser Tabelle ausgelesen und mit dem erwarteten Wert verglichen. Stimmen die überein, wird davon ausgegangen, dass auch alle anderen Tabellenwerte schon geschrieben sind und stimmen. Folglich wird dann ein erneutes Erstellen und Schreiben der Tabellenwerte unterlassen. Funktioniert - soweit ersichtlich - ganz gut.

Danke erstmal für die ausführlichen Erläuterungen deines Progs. Da hattest du dir aber einen echten Brocken vorgenommen, Kompliment! Eine Fernsteuerung - wenn auch etwas anderen Zweckes - hätte ich auch gerne, war mir aber bislang aus diversen Gründen zu aufwendig, vor allem wegen der Unklarheit, ob die Signalübermittlung per Funk oder doch via Telefonleitung - die es im Moment eh nicht gibt - vorgenommen werden sollte. Anderes Thema.
Der von dir genannte Porterweiterungs-Baustein schafft zwei neue Ports und ist wohl nicht wirklich einfach zu steuern. Den Gedanken, für eine Aufgabe zwei PICs zu beauftragen, hatte ich auch schonmal. Wenn sich das programm-mäßig sauber trennen lässt..., warum nicht?!

Wo siehst du bei einer Spannungsversorgung ein Problem? Gibts da an einer kritischen Stelle keine 230 Volt Hausversorgung? Oder fehlt es am Platz im Gehäuse?
Grüße, picass

Ich habe es nicht hinbekommen, dass die Variablen bleiben. Ich denke aber es liegt am C-Compiler. Der setzt alles beim Start auf Null. Das ist auch im Normalfall auch Ordnung nur bei einen Fehler halt nicht. Im Moment läuft mein Prog. wieder mal ohne Fehler. Es ist nur die Frage wie lange. Den Wdt brauche ich, da ich aus der Ferne (übers Internet) auf die Schaltung zugreife. Bei einem Absturz habe ich nach dem Neustart wieder Zugang. Es sind halt nur die ganzen Daten weg, die ich mitschreibe. Mir ist jetzt eingefallen, ich habe noch eine LED Anzeige die ich über SPI ansteueren kann. Die sollte eigentlich den Wert bei einen Neustart behalten. Ich muss mir noch ein Konzept überlegen was ich da anzeige und wie oft.
Was mache ich mit der Schaltung? Ich greife auf meiner Heizungsteuerung ein, kann das Gerät starten, Fehler auslesen, einstellen usw. Außerdem habe ich in jedem Vor und Rücklauf Temperaturfühler die ich abfrage und damit die Anlage steuern kann. Das Prog ist sehr komplext. Ich habe alles so programmiert, das ich keine Warteschleifen habe. Z.B. Temperaturfühler DS18B20, hier initialisiere ich erst die Fühler, in der Zwischenzeit springe ich ins Hauptprogr., rufe die nächste Funktion auf, wenn eine Zeit x, welche ich über Interrupt steuere, abgelaufen ist,  lese die die Fühlerwerte aus. Diese bringe ich auf die zwei LCD-Anzeigen und stelle es im Internet und über Telnet bereit. Außerdem habe ich noch USB Zugang den ich aber abgeschaltet habe. Der Schaltung habe ich jetzt zwei Spannungsregler gespendet, ein 74LS373 wo ich LCD-Beleuchtung und das EEProm ansteuere, ein CD4028, wo ich die Enable Leitungen und ein paar CS-Leitungen steuere.
Als nächstes will ich eine Relaiskarte mit 8 Relais und eine Optokoppler - Karte über den SPI Port ansteuern bzw abfragen. Hier bin ich noch am überlegen, wie ich die Hardware realisiere. Ich dachte schon an einen zweiten PIC-Prozessor. Ich habe aber auch einen Porterweiterung-IC MCP23S17 oder einen seriell-parallel Baustein 74HC595. Das mit den zweiten Pic scheint mir zu viel Aufwand zu sein. Da müßte ich zu viel umprogrammieren da ich viel auf den zweiten Pic auslageren würde. Wahrscheinlich mehme ich den MCP23S17. Da muss ich mir noch überlegen wie ich das mit der Spannungsversorgung realisiere.

Mist...., mein Beitrag von gestern ist im Nirgendwo verschollen...., also nochmal.

Es ist aus der Ferne etwas schwierig, das Prob in deinem Programm gedanklich zu bearbeiten. Zum Einen: PICkel hat mit seinem kurzen Testprog gezeigt, dass Variable erhalten bleiben, während das in deinem wohl nicht der Fall sein soll. Zum anderen: um welches Prog handelt es sich denn überhaupt ? Das hältst du geheim, sodass man nur raten kann, worum es überhaupt geht.
Mir drängt sich der Verdacht auf, dass das Einschalten/Nutzen eines WDTs das eigentliche Problem, welches ja vorher schon da war, nicht nur nicht löst, sondern ein ganz eigenes WDT-Prob zusätzlich oben drauf packt.
Mir hat in hatten Fällen das Prinzip der Reduktion geholfen, also das Konzentrieren auf nur jeweils einen einzelnen Programm-Aspekt, rsp. je ein Unterprogramm. Dazu hatte ich immer eine Art Testprog erstellt, indem ich aus einer Kopie des Ganzen nur die Initialisierung übrig ließ und halt ein einzelnes Unterprogramm. Das dann mit allen Eingängen und Ausgängen durchforstet, danach das Nächste und so fort..... Ist mühsam, aber irgendwann fängt man den Floh, sofern er im Prog steckt.

In einem anderen Fred schriebst du mal was von "mehreren Thermosensoren". Das erinnert mich an mein Prog für die Entfeuchtung eines Kellers und an dessen Vorgeschichte, als ich einen gleichnahmigen Artikel in der Zeitschrift "MAKE!" las. Dessen Autor berichtete, dass sein Erstlingswerk - ein Arduino - unter unerklärlichen Abstürzen litt, die sich mehrfach wöchentlich zeigten, aber keine direkte Ursache in dem Prog haben konnten, rsp. sollten. Irgendwann fand er raus, dass die Datenleitungen der Sensoren die Abstürze verursachten, weil die ungut ausgeführt waren: zu lang und zu einfache Kabel. Konsequenz des Autors: hochwertige Kabel verwenden (Cat 6) und die auch mit Abschirmung. Danach waren die Abstürze Geschichte. Zudem könnten auch Signal-Verstärker direkt am Sensor helfen.
Grüße, picass

Ich habe jetzt eine größere Umbaumaßnahme an meiner Schaltung vorgenommen. Das Problem mit der Speicherung, wo der Watchdog ausgelöst hat habe ich immer noch nicht gelöst. Im Moment läuft mein Programm stabil, das Prog. kann aber auch nach Tagen plötzlich abstürzen. Ich hatte schon versucht, bei Neustart die Uhrzeit zu speichern. Aber die Variablen sind alle gelöscht. Den Watchdog Timer kann man wahrscheinlich auch nicht auslesen, um noch schnell irgendwelche Daten in ein EEProm zu speichern. Was wahrscheinlich aber auch nicht funktioniert, wenn das Prog. abgestürzt ist. Im Moment bleibt mir nur die Möglichkeit die wichtigen Parameter ständig in ein EEProm zu speichern, und bei Neustart zu laden. Ich muß aber versuchen die Schreibzyklen gering zu halten wegen der Lebenszeit des EEProms.

Zitat von: pic18 in 16.02.2023, 11:39:52 CETdie Variablen werden alle auf Null gesetzt. Ich denke das macht der C18 Compiler.

Hallo pic18,
Du hast wahrscheinlich recht. Ich habe mal kurz einen Test mit einem 18F24K22 in mikroBASIC gemacht, da bleibt eine Variable im RAM erhalten.
Kurze Beschreibung:
Bei Neustart (Reset, Power_on) blinkt der komplette PortA kurz auf.
Die Testvariable wird auf 0 gesetzt.
Bei WDT-Reset blinkt PortA.0 kurz auf, die Testvariable wird inkrementiert und auf PORTB angezeigt. Es zeigt sich, dass der Wert in der Testvariablen erhalten bleibt.

Gruß
PICkel

program WDT_Variablentest
' getestet mit mikroBASIC V 7.6
' Test des WDT in Bezug auf RAM-Inhalte
' PIC18F24K22 @ 1MHz INTOSC (default)
' WDT ein, Postscaler auf 1:512 (ca. 2sec)

' bei jedem WDT-Reset wird testvar inkrementiert und an PORTB angezeigt,
' bei jedem Aktivwerden des WDT blinkt PORTA.0 kurz auf
' bei RESET erfolgt an PORTA einmalig die Anzeige von 0xFF

' Declarations section 

dim testvar as byte

main:

TRISA = 0
TRISB = 0
LATB = 0
if testbit(RCON,3) = 0 then    ' WDT hat zugeschlagen
  clrwdt
  inc(Testvar)
  LATA = 1
else                           ' normaler RESET
  LATA = 255
  Testvar = 0
  LATB = 2
end if

delay_ms(500)
LATA = 0
LATB = Testvar

while TRUE           ' warten auf WDT
wend

end.

der Pic startet ja nach WDT Auslösung neu. Ich möchte aber gerne die gewisse Parameter erhalten, die Variablen werden alle auf Null gesetzt. Ich denke das macht der C18 Compiler.

Deine Terminologie lässt es aus meiner Sicht an Klarheit zu wünschen übrig. Was genau verstehst du unter dem Begriff "Absturz eines µC's" ?
Die Analogie zum PC hatte ich ja schon gezogen, nochmal: wenn der, rsp. sein Betriebssystem "abstürzt", dann startet es anschließend von selbst neu. Sollte also dieser Art dein PIC "abstürzen", müsste er ja vom Anfang des Progs an normal wieder laufen. Es wären dann zwar diverse Variable mit ihren aktuellen Werten resettet, aber laufen müsste das. Ist das bei deinem µC so?

Und du sagst weiterhin nichts über die "Spannungs-Einbrüche". Gäbe es die tastsächlich, müsste das natürlich beseitigt werden, rsp. die Ursache gesucht werden.
Grüße, picass

das Programm läuft seit dem letzten Start immer noch durch. Der Fehler taucht selten auf, debuggen und im Simulator testen bringt meiner Meinung nichts. Außerdem habe ich auch keinerlei Ports mehr frei.
Leider werden die Variablen nach einen Neustart durch den Watchdog gelöscht, obwohl ich sie nicht initialisiert habe. Ich weis nicht, ob das der C18 Compiler automatisch macht. Ich probiere mal auf einer ganz gewissen Speicherzelle was zu schreiben und schaue, ob der Inhalt noch da ist.

Das Wort ,,Systemabsturz" bei µC's halte ich für erklärungsbedürftig. Bei einem PC unter Windows würde das bedeuten, der PC ist mit einem ,,Knacks" raus aus Windows und der PC startet neu, sofern das W-System nicht komplett durch den Wind ist. Bei deinem Prog muss aber wohl anderes passieren, sonst bräuchtest du keinen WDT, um das Prog neu zu starten.
Würde der in einer Schleife festhängen, wie von dir erwähnt, rsp. auf eine Porteingabe warten, oder könnte der ans Ende des Progs gesprungen sein, und wenn der nicht ,,sauber" abgestürzt und entsprechend sauber und korrekt wieder von Neuem gestartet wäre, dann muss sich die Position des Hängers mit der angesprochenen Indizierung, also dem Setzen von nachvollziehbaren Markern erkennen lassen.

Was macht denn das Prog im Simulator? Nicht jeder schätzt den so, aber ich lasse jedes Prog erst mehrfach dadurch laufen. Erst dann, wenn der Simulator einwandfreie Läufe zulässt, lasse ich das Prog auf einen PIC los. Danach gibts ja noch die Möglichkeit, das Prog im PIC zu debuggen. Das dauert – je nach Länge und Komplexität des Progs, aber die Teile, welche in Ordnung sind, müssen ja nur einmal durchlaufen werden - geschicktes Setzen von Stopppunkten hilft sehr. Mit Geduld kann man mit diesem Debuggen so Etliches erreichen, zumal sich ja auch Port-Eingaben simulieren lassen.

Manchmal helfen auch sehr frugale Methoden weiter. Bei meinem jüngsten Prog, dem Maulwuf-Verscheucher – also dem versuchten  - , lief anfangs wenig zusammen. Weil ich da auch drohte, den Überblick zu  verlieren, hatte ich eine der viel geschätzten Platinen des ,,PICkit Low Pin Count Demo" – Boards mit  viel Lametta geschmückt, will sagen, an fast alle Ports LEDs ran gehängt, siehe Bild. Und dann ging es auf einmal schnell. Deren Leuchtmuster entlarvte die Schwachstellen äußerst fix und wo mir beim Starren auf den Bildschirm-Inhalt mit dem Prog der Überblick verloren zu gehen drohte, ergab sich mithilfe der LEDs die Richtung für die Fehlerbeseitigung wie von selbst.

A pro po Spannungs-Einbrüche, da hattest du dich noch nicht zu geäußert. Was geht denn da ab....., taugt das NT nichts, ist das einer Spitzenstrombelastung nicht gewachsen? Oder sitzen da – nur als Beispiel – Relais in der Schaltung, welche keine anti-parallele Dioden an der Spule haben, oder sind die direkt an der 5-Volt-Versorgung des PICs?

Ich hatte auch schon mal einen "winzigen" Steuer-PIC zusätzlich eingesetzt, welcher mit einem Minimal-Prog nichts anderes zu tun hatte, als den unzuverlässigen Kumpel auf der Hauptschaltung zu überwachen, rsp. dessen Fehlverhalten zu markern.
Grüße, picass