Hallo in meinem größeren Programm habe ich in ab und zu Programmabstürze (1  mal im Monat). Damit das Programm neu startet, habe ich den Watchdog Timer aktiviert. Das funktioniert ganz gut. Nun meine Frage: Gibt es eine Möglichkeit den Programmcounter zu sichern um eine Fehlerdiagnose zu machen? Ober habt ihr eine andere Idee? Ich habe mir auch schon überlegt den 31-stufigen Stack Speicher zu sichern, bin mir aber nicht sicher ob das mir was bringt.
Mit der Watchdog   Zeit Umrechnung habe ich meine Probleme. Laut Datenblatt (Pic 18F4685, Dokument 39761b) soll ich eine Taktfrequenz von 31KHz haben, was eine Zeit von bis zu 131072s ergibt.

,,For PIC18F2682/2685/4682/4685 devices, the WDT is driven by the INTRC source. When the WDT is enabled, the clock source is also enabled. The nominal WDT period is 4 ms and has the same stability as the INTRC oscillator. The 4 ms period of the WDT is multiplied by a 16-bit postscaler. Any output of the WDT postscaler is selected by a multiplexer, controlled by bits in Configuration Register 2H. Available periods range from 4 ms to 131.072 seconds (2.18 minutes). The WDT and postscaler are cleared when any of the following events occur: a SLEEP or CLRWDT instruction is executed, the IRCF bits (OSCCON<_x0036_:_x0034_>) are changed or a clock failure has occurred. . 24.2.1 CONTROL REGISTER Register 24-14 shows the WDTCON register. This is a readable and writable register which contains a control bit that allows software to override the WDT enable Configuration bit, but only if the Configuration bit has disabled the WDT. FIGURE 24-1: WDT

Dies kann ich leider nicht nachvollziehen. Ich habe einen Vorteiler von 128 und einen programmierbaren Teiler von bis zu 32738 das ergibt bei 31Khz:
128*32768s/31000 = 135176,1s
Wenn ich das Ganze mit 32Khz rechne
128*32768s/32000 = 131072s was im Datenblatt steht.
Was stimmt nun?
Die 31Khz oder die 32Khz
Die 135176s oder die 131072s
Kann Microchip nicht rechnen, oder stimmt das Datenblatt nicht?

muss natürlich ms heißen

ich habe mal ein kleines Testprogramm eingefügt, da wird bis 131 gezählt, was eine errechnete Taktfrequenz von 32Khz entspricht.

        case ausg_watchdog:
            LED_or = LED_OFF;
            stdOut_mr =stdOut;
            stdOut = source_lcd;
            test_wdg=0;
            ClrWdt( );
            while(1){
                if(TimerFlag.IF1s){
                    TimerFlag.IF1s=0;
                    test_wdg++;
                    printOut("%bu\n",test_wdg);
                }
            }
            break;

Hier lese ich aber immer noch 31KHz!
The other clock source is the internal RC oscillator
(INTRC), which provides a nominal 31 kHz output.
INTRC is enabled if it is selected as the device clock
source; it is also enabled automatically when any of the
following are enabled:
• Power-up Timer
• Fail-Safe Clock Monitor
• Watchdog Timer
• Two-Speed Start-up

aber egal, ich bin noch am Überlegen ob ich den "Program-Counter" sichern kann.

Zitat von: pic18 in 07.02.2023, 10:33:26 CETWas stimmt nun? Die 31Khz oder die 32Khz

Das Datenblatt sagt aus meiner Sicht deutlich, dass für die Nutzung des WDT nur ein Oszillator in Frage kommt und der läuft mit "nahezu" 31 kHz.

The other clock source is the internal RC oscillator
(INTRC), which provides a nominal 31 kHz output.
INTRC is enabled if it is selected as the device clock
source; it is also enabled automatically when any of the
following are enabled:
• Power-up Timer
• Fail-Safe Clock Monitor
• Watchdog Timer
• Two-Speed Start-up

Setting this bit selects INTOSC as a
31.25 kHz clock source by enabling the divide-by-256
output of the INTOSC postscaler. Clearing INTSRC
selects INTRC (nominally 31 kHz) as the clock source.

Grüße, picass

es sind aber in der Praxis 32Khz. Das habe ich auch gemessen.
The 4 ms period of the WDT is multiplied by a 16-bit postscaler. Any output of the WDT postscaler is selected by a multiplexer, controlled by bits in Configuration Register 2H. Available periods range from 4 ms to 131.072 seconds (2.18 minutes)

Aber interessanter ist mir die ganzen Register zu retten. Ist da irgendwie möglich?

Register wie PC oder Stackpointer zu retten ist wohl nicht möglich.

Gedankenspiel:
Eine Möglichkeit wäre vielleicht, im Programm an sinnvoll definierten Stellen (Eintritt in eine Funktion) einen  Index zu setzen und diesen in ein Register zu schreiben, welches beim WDT-Reset nicht verändert wird, ein Port sollte wohl gehen, weil er nach dem RESET nicht automatisch zurückgesetzt wird. Der EEPROM ist dazu leider nicht geeignet wegen der begrenzten Schreibzyklen, ein FRAM würde aber funktionieren.
Oder hast Du mal getestet, ob der Inhalt eines Bytes im RAM erhalten bleibt? Schließlich hat es beim Ansprechen des WDT normalerweise keinen Spannungseinbruch gegeben.
Ist dann nach einem RESET das TO-Bit in RCON gelöscht, wurde der WDT aktiviert und man kann den Inhalt dieses Registers abfragen und ggf. speichern, um wenigstens den Ort des "Hängers" zu lokalisieren.
Ob's funktioniert? Wer weiß???

Gruß
PICkel

vor Jahren hatte ich schon einmal ein Programm geschrieben, welches den 31 Stufigen Stack sichert. Irgendwie ist es aber in Vergessenheit geraten. Den Adresspointer von den Unterprogrammen zu sichern hatte ich mir auch schon überlegt. Man könnte die Daten in einen Ringpuffer schreiben und hoffen das die Daten beim Reset nicht gelöscht werden. Im Moment läuft das Programm einige Tage ohne WDT - Reset durch. Kann man den WDT irgendwie auslesen? Dann hätte ich eine Vorwarnung, wenn der Reset kommt.

Bei der letzten Programmänderung hatte ich auch einen Fehler gefunden den ich schon länger gesucht habe. Ich habe ja 2 LCD Anzeigen, diese habe ich so programmiert, das wenn ich in die letzte Spalte schreibe der Anzeigetext um jeweils eine Zeile nach oben scrollt, ich lese die Zeile von der Anzeige aus und schiebe sie um eine Zeile jeweils hoch. Wenn ich das Programm mit dem USB Bootloader aufspielte dann lief das Prog. jedes mal einwandfrei. Bei Stromausfall stimmte der Text plötzlich nicht mehr. Ich hatte immer einen Hardware Fehler gesucht, Lese und Schreibzeiten des Display geändert und nach Pullup Widerstände geschaut. Manchmal war mit der ganzen Messerei auch eine Leitung abgerissen. Dabei lag der Fehler wahrscheinlich an den abgeschalteten USB Baustein welcher auf den selben Datenbus liegt. Diesen hatte ich vor langer Zeit abgeschaltet, da das Programm beim Start auf die USB Schnittstelle wartete. Durch Benutzung des Bootloaders wurde die Schnittstelle initialisiert und das Prog lief anschließend einwandfrei. Bei Stromausfall war der Fehler da. Jetzt habe ich die Leseleitung initialisiert, somit sendet der USB-Baustein keine Daten auf den Bus. Der Fehler ist hoffentlich damit weg. Ich frage mich jetzt was so ein Port an Kurzschlüssen aushält, ob da eine Strombegrenzung ist?

@pic18
Anfangs schriebst du von "Programmabstürzen" und dass der WDT damit zusammenhängen könnte, zuletzt nun von "Stromausfällen" (SA). Letztere sind eine dicke Hausnummer, dazu später.

So richtig deutlich drückst du dich bei deinen Fehlerbeschreibungen nicht aus. Das klingt schon fast so, als ob da zwei voneinander unabhängige Probs vorhanden sind.
Zwei Vorschläge hätte ich, wobei ich eben bemerkt habe, dass PICkel einen davon bereits ausführte: Indexerstellung.
Selbst hatte ich vor Jahren mal in einem längeren Programm (Rollladensteuerung) einen sehr versteckten Fehler aufgespürt, indem ich im Programm eine Variable an reichlich vielen Stellen angebracht hatte, die sich je nach Programm-Position aktualisierte. So konnte die letzte, vom Prog noch "normal" verarbeitete Position erkannt werden, und danach von da aus mit Feintuning die Fehlerstelle eingegrenzt und ermittelt werden. Allerdings gab es keine Probs mit SA's.
Eigentlich müsste man das interne EEPROM schon nutzen können - soweit frei. Du müsstest ja nicht Hunderte oder gar Tausende an Bytes und das auch noch in einer einzigen Speicherstelle sichern. Bei Bedarf lässt sich das ja auch aufsummieren, also hinter einander weg abspeichern.

Vermutest du nur oder bist du sicher, dass es SA's gibt? Falls du unsicher bist, ließe sich das einfach überprüfen, indem externe Hardware dafür an die Uv angeknüpft wird, welche einen Spannungsausfall auch in Form eines kurzen Spikes notieren würde. Eine ebenfalls extra Versorgungsspannung für diese HW wäre auch kein Prob: 3 Batterien würde reichen.
Grüße, picass

Das mit den Systemabstürzen ist schon richtig geschrieben. Die der Fehler bei Neustart nach Spannungsabfall vom letzten Beitrag ist ein anderer. Diesen hatte ich erwähnt um zu zeigen wie verschiedene Fehler zusammen hängen können. Das die Fehler mit dem WDT zusammenhängen habe ich auch nicht geschrieben. Ich habe nur den WDT programmiert um bei Systemabstürzen das System neu hochzufahren, ich schalte dann auch eine LED nach dem Start durch den WDT.
Heute morgen wurde das System mit dem WDT nach über eine Woche neu gestartet. Die LED leuchtete, die alten Daten wurden neu initialisiert. Wo der Fehler zu suchen ist weis ich nicht. Evtl. wird auf irgend einen Eingang gewartet.

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

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.

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

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.

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.

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.

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 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.

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

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.