Derart nüchtern hatte ich das bislang nicht betrachtet. Nutzt aber nichts... !
Meine technische Neugierde treibt mich an, ein erkanntes Problem zu lösen, wenn es sein muss auch durch Niederknüppeln.
Mein Hauptprob ist die viel zu geringe Übung im Programmieren, das ist quasi nur ein seltener Gelegenheitsjob. Und danach werden Basics leider wieder vergessen. Dann kommt bei mir persönlich dazu, dass ich Datenblätter zwar lesen kann, aber die vermitteln mir nur extremes Detailwissen und lassen den Zusammenhang und vor allem den Grund "warum" vermissen.
In der Pädagogik gibts den berühmten Satz: "Ein Bild sagt mehr als tausend Worte". Analog dazu geht es mir so, dass ich mit einem kurzen und grundsätzlichen Beispiel-Programm weitaus schneller Verständnis für die Notwendigkeiten erkennen kann als durch stundenlanges Blättern im Datenblatt-Dschungel. Und so'n Beispiel hatte ich zuletzt ausgebuddelt. Das stammt übrigens von Microchip himself und war eine Beigabe zum Musterboard mit dem ewig langen Namen "PICkit Low Pin Count Demo Board".
Dann stand ich mir auch noch selbst auf dem Fuß, indem es mir beim Hantieren mit den zahlreichen Strippen der Experimentierschaltung gelang, zwei Port-Pinne mit zu hoher Spannung zu versorgen. Das hatte der PIC wohl übel genommen und zeitweilig für Verwirrung gesorgt.
Ist jetzt aber alles Geschichte, seit gestern Nachmittag funktioniert die IRQ-Routine so, wie erwartet, übrigens auch bei dem mit Spannung teil-überversorgten PIC. Es kann nun also weiter gehen.

Auch wenn das IRQ-Prob nun gelöst ist, sehe ich allerdings dennoch Bedarf, rsp. Interesse an einer weitergehenden Betrachtung der IRQ-Thematik. Da gibt es noch Fragen, zurückhaltend formuliert. Z.B. die unterschiedliche Behandlung eines "high-priority"- IRQs gegenüber dem "low-priority". Dann noch, ob man nicht doch auf die ganze IRQ-Klamotte verzichten und lediglich einen Port-Pin-Wechsel auswerten kann, rsp., ob es für diesen Wechsel eine Einfach-IRQ-Variante gibt. Dann scheint der PortA3 Pin eine Sonderrolle zu spielen. Der ist bei diesem PIC-Typ ja als reiner Digital-Input-Pin zu nutzen. Und der scheint einfacher ansprechbar zu sein, z.B. auch bei beiden Flanken (pos. u. neg.).

Na ja, das war nun wieder ein Blut-Schweiß-und Tränen-Wiedereinstieg ins Programmieren. Hab' mich gestern mit einem guten Schluck Rotweines getröstet.
Grüße, picass

Nein, kein Problem, aber die Abwägung einer elektrotechnischen Frage nach dem Aufwand für das Steuern des elektr. Garagentor-Motors.
In der alten, leider unzuverlässigen Schaltung existierten zwei Relais. Je nachdem, welches angezogen war, wurde der Motor ,,be-polt":  entsprechend stellte sich beim Gleichstrommotor die Drehrichtung ein. Zusätzlich war noch ein MOSfet vorhanden und der war ja wohl irgendwie  wichtig. Jedenfalls nutzte das Relais-Schalten nichts, auch der Fet musste angesteuert werden, denn nur der schaltete den Motorstrom auf GND, erst dann konnte was laufen.

Dieses Konzept hatte ich stumpf übernommen, nur gibt es in meiner Schaltung ein zusätzliches Relais, welches einen DC-DC-Wandler einschaltet, der von den 12 Volt des Auto-Akkus auf den benötigten Pegel von 24 Volt für den Motor liftet.
Also könnte, rsp. müsste in meiner Steuerung zum Einschalten des Motors dieses passieren:
1. Relais fürs Hochfahren einschalten, dann
2. Relais für das Einschalten des DC-Wandlers einschalten, dann
3. dem MOSfet ein paar Elektronen zukommen lassen, damit der endgültig den Weg frei macht.

Und – is klar – beim Ausschalten die ganze Reihenfolge wieder anders rum. Nicht, dass dieser Vorgang halt ein Problem darstellt, aber die Frage nach dem Sinn des Gefummels würde ich schon gerne los werden. Selbst vermute ich, dass die Relaiskontakte geschont werden sollen, indem die Relais nur im unbestromten Zustand geschaltet werden und danach erst der Saft kommt.
Oder seht ihr einen anderen Grund für die Existenz von zwei Schaltern für einen Stromfluss? Gäbe es einen, müsste, könnte, sollte ggf. die Reihenfolge der Dreifach-Ein-u.-Aus-Schaltungen geändert werden.
Grüße, picass

Na, das ist wohl die klassische 2-Relais-Polwendeschaltung für Gleichstrommotoren.
Der MOSFET hat 2 Vorteile:
1. Lebensdauer: Die Relais müssen nicht im Umschaltmoment (Kontaktprellen) den mehrfach  höheren Anlaufstrom ggü. Normalbetrieb bewältigen.
2. Sicherheit: Wenn der MOSFET "die Hufe hebt" und durchlegiert, bleibt der Motor trotzdem bei nicht angesteuerten oder bei gleichzeitig angesteuerten Relais stromlos. Gleiches gilt bei Fehlfunktion des Controllers: Es müssen immer genau 2 Ausgänge aktiv sein, sonst läuft der Motor nicht.

Gruß
PICkel

Ähm...PICkel, ist das jetzt ein besonders raffiniertes Bilderrätsel oder hast du aus Versehen dasselbe Bild zweimal eingestellt?!
Also, es geht - wie vermutet - um die Sicherheit beim Schalten und überhaupt. Na gut, dann werde ich das Konzept so belassen.

Gettz bekommt ihr was aufs Auge!
Nämlich die Bilder von meiner schönen, neuen Testanlage. Um es gleich anzugehen: die ist diskussionsfähig, rsp. -bedürftig. Weil....man braucht sie nicht wirklich, die im letzten Bild unauffällig am Rande liegenden zwei kleinen Platinchen mit je zwei Schaltern, rsp. Tastern täten es auch. Aber.... aber bei der nun ausrangierten orig Steuerplatine hatte ich mich geärgert, dass es nicht gelang, die Einbausituation in der Garage in meinem Arbeitsraum nachzustellen. Irgendwie merkte der darin verbaute PIC immer, dass es nicht real war. Der konnte auch auf ein externes EEprom zugreifen und wer weiß, was der da so alles gespeichert hatte. Für meine Arbeiten - sowohl im Realen als auch dem Hantieren mit der MPLAB-IDE - ist das Simulieren aber nicht nur hilfreich, sondern häufig auch notwendig, und deshalb griff ich zu diesem Hilfskonstrukt. Und geholfen hat es tatsächlich schon, erinnert die Hilfe doch unversehens auch an die identischen Probleme des Kettenzuges in der Garage.
Zudem konnte ich mal wieder etwas schon seit Ewigkeiten tief hinten in den Elektronikregalen Verbuddeltes endlich einer Nutzung zuführen: den Neigeschaltern mit Quecksilberfüllung! Und man lernt auch was dabei, z.B., dass selbst die totsichere Schaltung in Gestalt der zwei voll von Quecksilber umtosten dicken Drähten nicht perfekt sein muss. Kaum zu glauben, aber bei einem Röhrchen müssen die Drähte innen drin korridiert sein, denn das schaltet unzuverlässig!

Naja, das Konstrukt ist halt hübsch anzusehen und nach den Schindereien zwecks der IRQ-Problematik brauchte ich mal Ablenkung und dringend einen positiven Aspekt bei diesem Projekt. Der nächste Programmpunkt ist auch geschafft, es geht um die Aktionen bei der Inbetriebnahme. Dabei weiß der µC ja nicht, in welcher Position sich der Kettenantrieb gerade befindet. Dafür habe ich eine Lösung entwickelt und ins Prog übernommen... und die wunderschöne Testanlage hat nach den üblichen Mucken dieser Form der Lösung auch zugestimmt.
Grüße, picass 

Zitat von: picass in 06.04.2022, 10:10:14 CESTÄhm...PICkel, ist das jetzt ein besonders raffiniertes Bilderrätsel oder hast du aus Versehen dasselbe Bild zweimal eingestellt?!

Ist natürlich 2x das selbe Bild. 1x hätte also gereicht, aber ich fand es sooo schön, dass ich es gleich nochmal hochgeladen habe. 

Gruß
PICkel

Hängen im Schacht! Wie man hier im Pott zu sagen pflegte. Kaum zu glauben bei einem auf den allerersten Blick einfachen und überschaubaren Programm. Da soll ja "nur" was von rechts nach links und umgekehrt, rsp. von oben nach unten, etc. laufen. Aber dauernd werden reichlich Schalter auf ihre Schaltstellungen und der Laufwagen auf seine Position abgefragt, und allein dieses Abfragen machen das Arbeiten mit dem Simulator in der MPLAB-X-IDE zu holprigem "Vergnügen".
Im Moment ärgere ich mit Unzuverlässigkeiten rum, vor allem dem Beeinflussen von Bits. An diversen Stellen im Sim gibts z.B. zwei aufeinander folgende Anweisungen wie bsf PORTA,3 und bsf PORTA,4. Na prima, aber nicht nur gelegentlich wird das großzügig übersehen und die Voreinstellungen nicht geändert. Oder: das Prog springt nach ersten, erfolgreichen Läufen in eine Unterroutine, in die es theoretisch gar nicht gelangen dürfte. Schwitz....! Das Einzige, was zuverlässig klappt ist "wast the time".
PortA,3 hat ja 'ne Sonderrolle, das wäre ein Hinweis, aber warum wird dann bei den Umkehrungen, also beide genannten bits mit bcf das Bit 4 nicht zurück gesetzt?
Vor einigen Tagen beobachtet: beide bits sollten nacheinander gesetzt werden, das erste wurde gesetzt, das zweite auch, aber gleichzeitig das erste bit wieder zurück auf null gesetzt. Voll der Horror. Muss gestehen, es fehlt mir im Moment der zündende Gedanke, mit welcher Systematik oder auch welchen Mitteln oder auch welcher zusätzlicher Hardware - z.B. Hardware-Debugger - der gordische Knoten zu zerschlagen wäre. Für den Simulator reicht die Konzentrationszeit zwei bis drei Stunden, wenn dann immer neue, andere Fehler auftauchen, wirds trüb, dann geht es erstmal nicht weiter.
Grüße, picass

Read-Modify-Write Effekt?

Wenn du einen PIC mit lesbaren LAT Registern hast,
solltest du niemals Bits im PORT modifizieren!

Auch wenn nur ein Bit geändert wird, dann muss
trotzdem der ganze Port eingelesen werden. Beim
lesen von PORT sind je nach Konfiguration manche Bits
immer 0, auch wenn im LATCH eine 1 steht.

Die werden dann "falsch" wieder zurück geschrieben!

Das betrifft dann eben immer die anderen Bits,
nicht das, welches verändert werden soll!

Bei PICs bei denen das LATCH nicht lesbar ist,
muss man ggf. selber ein schattenregister anlegen.

Das mit dem Lesen-Ändern-Schreiben-Effekt muss ich erst mal verarbeiten. Werde mich aber drum kümmern, also versuchen.... Es hatten sich - das sage ich jetzt ungern - aber auch wieder gänzlich banale Fehler eingeschlichen: an einigen Positionen hatte ich dem PIC aufgegeben, auf einen PORT zu schreiben, schwitz. Da herrscht nun aber Ordnung.
 
Inzwischen läuft es rund...! Allerdings noch nicht ganz zuverlässig. Nach mehreren gelungenen Runden (hoch-, bzw runterziehen), ist ein Sprung in eine - gewollte - Fehlerroutine möglich. Und beim zwischenzeitlichen Aufstoppen, wenn also das noch virtuelle Garagentor auf halbem Wege gestoppt werden soll, dann stoppt es zwar, aber beim nächsten Startbefehl will es manchmal die Hufe nicht heben.
Habe das Gefühl, dass die Entprell-Routinen für die Taster da eine noch ungute Rolle spielen. Zudem sind die beiden Quecksilber-Schalter evtl. nicht zuverlässig, einen  musste ich ja schon aussondern. Werde mal nach anderen Neigungsschaltern suchen und bis dahin auf das Einfach-Brettboard mit den zwei mechanischen Schiebeschaltern zurück greifen.
Bin inzwischen wieder guten Mutes, das es noch was wird.
Grüße, picass

Zitat von: vloki in 10.04.2022, 10:18:49 CESTWenn du einen PIC mit lesbaren LAT Registern hast,
solltest du niemals Bits im PORT modifizieren!

Hab' gerade mal geschaut, genauer, gleich zwei mal. Zum einen führte die Guckst-du-Suche zu einer Seite mit guter Darstellung des read-memory-write-Effektes: https://download.mikroe.com/documents/compilers/mikroc/pic/help/rmw.htm
Zum anderen ist beim PIC18F14K22 laut Datenblatt das Latch lesbar. Werde die entsprechenden Routinen in meinem Prog einer gestrengen Prüfung unterziehen und ggf. pädagogische Maßnahmen einleiten. Hätte nicht gedacht, dass es selbst schon bei µC's eine Schraibschwäche geben kann!
Grüße, picass

Dreh' gerade wieder am Rad. Habe meiner Schaltung 3 "Verbesserungen" zukommen lassen, und nun geht wieder nichts mehr. Erste VB: die Neigungsschalter mit Quecksilberfüllung wurden ersetzt durch solche Schalter, die auch in der Garage verbaut sind, ein auf der Laufkette installierter Magnet und an den Endpositionen Schalter mit Reedkontakten. Das klappt nun wirklich zuverlässig. VB2: Die Ports werden nur mehr zum lesen benutzt, geschrieben wird nur noch auf LATs. VB3: die Folgen im Prog, an welchem mehrere Bitset-Funktionen aufeinander folgten, wurden komplett ersetzt durch das Setzen per MOV-Befehle auf die LAT-Register. Damit müssten die Read-write-Probs aus der Welt sein.

Leider ist der PIC in seinem Lauf auch aus der Welt. Zum Hardware-Debuggen hat es noch nicht gereicht - dazu später - , aber per LED-Kette an bislang nicht benutzten PORTs und entsprechenden Setzungen im Prog lässt sich nun per nacheinander Einschalten der LEDs verfolgen, ob die Kette auch abgearbeitet wird. Und das lässt nun - leider - ein ungutes Ereignis erkennen:
Wie schon vorher mal erwähnt springt der PIC unvermittelt in eine Programm-Routine, in die er "eigentlich" nur geraten könnte, wenn zwei Bedingungen erfüllt sind: Der PIC, rsp. die gesamte Schaltung wurde zum ersten Male mit Strom versorgt und zweitens: aufgrund der Endschalterstellungen wird erkannt, dass das G-Tor nicht wie beabsichtigt für den Erstlauf (der Motor könnte in die falsche Richtung loslaufen) in der Mitte des Laufweges steht.

Kurz gesagt: Der PIC beginnt das Programm prima, lässt wie vorgesehen den Motor so laufen, dass ein G-Tor hochgezogen würde in die Endposition und dann dort natürlich stoppt. Das klappt prima, nur sollte der PIC dann in eine spätere Sleep-Routine rein, die im Moment noch aus einer reinen Schleife besteht, in welcher der PIC solange rum läuft, bis durch einen Schaltbefehl via Handschalter oder per Funkfernbedienung das G-Tor wieder loslaufen soll.
In diese Sleep-/Schleifen-Routine kommt er aber gar nicht, sondern landet wieder in der Fehlerroutine, die via Aufruf nur ganz am Anfang des Progs angesteuert werden kann, nirgends sonst im weiteren Prog-Verlauf gibt es einen Aufruf für diese Fehler-Routine.
Einzige Erklärung: der PIC wird nach vollbrachtem ersten Hochziehen komplett aus seinem Programm geworfen und startet wieder von vorne!
Per Oszi habe ich die Versorgungsspannung geprüft, da kann ich aber keinen Überschwinger oder einen heftigen Spannungseinbruch feststellen - es zuckt mal kurz was, aber - soweit erkennbar - nur was im Bereich von ca. 100 mV. Der MCLR-Pin ist per Initialsierung still gelegt und als reiner I/O-Pin genutzt. Und der liegt knallhart über einen Schalter und Vorwiderstand auf +5 Volt, da kann sich auf keinen Fall was rühren.

Der Aussprung erfolgt direkt, nachdem die zwei benötigten Relais ausgeschaltet wurden. Das sind zwei recht gute ZETTLER-Relais, die extra auf sehr geringen Strombedarf ausgesucht wurden. Die Spulen haben 720 Ohm und "verbrauchen" nur 20 mA. Sie werden nicht von der 5 V-Versorgung des PICs aus bedient, sondern ziehen ihren Saft vorher über eine Entkopplungs-Diode direkt von den 12 Volt des (späteren) Akkus. Natürlich ist an jede Spule eine gegen Plus gerichtete Entkopplungsdiode angebracht.
Zufall oder nicht.... im Programm gibt es an dieser Stelle nichts Geeignetes für einen Aussprung, da ist nur noch der call-Aufruf einer Entprell-Schleife mit 0,1 sec Länge. Die liegt aber auch im Block Null, ein Fehlsprung müsste ausgeschlossen sein. Und - ach ja - im Simulator läuft zum zwanzigsten Male in Folge alles prima.

Zum Hardwaredebuggen bin ich noch nicht gekommen, wofür es Gründe gibt. Soviel bislang ersichtlich müssen dafür diejenigen PORTA-Pins, welche auch zum Incircuit-Programmieren benötigt werden, frei sein. Sind sie aber nicht, die fraglichen 3 sind alle für Schalter genutzt. Also müsste das Alles erst sowohl im Programm als auch an der Platine - schon wieder mit Kratzen und Fädeldraht - geändert werden. Und auf Änderungen radikaler Art stehe ich im Moment nicht, nachdem vor wenigen Tagen alles zu laufen schien und die drei "Verbesserungen" nun alles zum Stillstand brachten.

Ich bitte um Anregungen, wie aus dem Schlamassel heraus-zu-picken wäre.
Grüße, picass

Brown-out-Reset und Watchdog in den Config Bits abgeschaltet?

Zitat von: vloki in 12.04.2022, 13:27:44 CESTBrown-out-Reset und Watchdog in den Config Bits abgeschaltet?

Ob BOR oder WDT angesprochen haben, kann man beim 18F14K22 im RCON- Register feststellen.
Z.B.: RCON.3 (das TO-Bit) = 1 nach Neustart oder CLRWDT, es wird gelöscht, wenn der WDT aktiv wurde und den PIC resettet hat. Auch für Brown-Out gibt es im RCON entsprechende Bits.

Gruß
PICkel

Ja, war alles abgeschaltet.
Hatte gerade einen Bericht erstellt mit all den vielen weiteren Maßnahmen, dem Übel auf die Spur zu kommen, und las den B. vor dem Einstellen Korrektur, um die Schraibfehler möglichst zu entdecken, und blieb beim allerletzten Satz hängen, in welchem ich beschrieb, dass auch die Pegel der Schalterabfragen sauberst bis zu den zutreffenden Ports zugestellt würden. Und schon wieder Zweifel!
Also die Pikse des heiß gelaufenen Multimeters an die beiden Portpinne, die Signale kamen in der Tat sauberst mit den zu erwartenden Pegeln je nach Endschalter-Lage an, aber am falschen Port. Beim Umtauschen der Quecksilber-Röhrchen gegen die Magnetschalter waren im Gestrüpp der überall grünen Käbelchen die Ports vertauscht. Und so gesehen lief alles nicht etwa gestört, sondern perfekt ab: der PIC merkte beim Einschalten, dass die Grundfiguration der Schalter so nicht sein sollte, und vermeldete das in seiner Fehlerroutine. Für die gab es - das ist jetzt neu - doch noch einen zweiten, bislang sehr unbeobachteten Einsprung über eine "eigentlich" überflüssige 4-zeilige Routine, die nur zur Sicherheit der Sicherheit eingefügt war. Und die war diejenige, welche ich nicht mehr beachtet hatte, und genau die war es, welche den Fehler bemerkte.
Ach....., wenn so'n MicroController für was wirklich Spitze ist, dann dafür, jede winzigste Kleinigkeit der Fehlstellung eines einzigen Bits zu bemerken und dann verschnupft zu reagieren. Is klar, aus dieser Nummer konnte ich nur mit einer weiteren Blessur rauskommen, ein Ruhmesblatt ist in weiter Ferne, also quasi hinter dem Horizont.
Aber nu' läuft alles so, wie es soll. Also fast ! Die Kette wird zuverlässig komplett abwechselnd zu den Endpositionen gefahren, und auch das zwischen zeitliche Stoppen und Retournieren klappt. Da gibt es bei jedem ca. sechsten Male einen Holperer, der aber nicht wirklich die Funktion beeinträchtigt. Da ist vermutlich noch eine Entprell-Routine zu kurz. Oder so....
Danke für eure freundlich zugedachten Hilfen, sowas trägt immer weiter!
Heute Abend müsste ich mich erst mal bes....., also einen guten Schluck des viel geliebten Rotweins zu Gemüte führen. Aber ach, auch da will was nicht klappen: habe mich gerade vor ein paar Tagen trocken gelegt, muss mal wieder sein.
Deswegen nun trockene, aber dem Horror entronnene Grüße, picass

Zitat von: PICkel in 12.04.2022, 14:38:52 CESTOb BOR oder WDT angesprochen haben, kann man beim 18F14K22 im RCON- Register feststellen.

Im Debug-Mode schon ;-)

-> Nie eine Platine designen ohne entsprechenden Anschluss!

Stichwort Debuggen!
Warum hat - wie berichtet - in den letzten Tagen das Debuggen im MPLAB X IDE-Simulator geklappt, aber der reale PIC hatte immer andere Vorstellungen? Wir wissen ja jetzt, dass mir die beiden grünen Käbelchen an zwei Ports verrutscht waren. Im Sim hatte ich die vielen Schalterabfragen ja künstlich erzeugen müssen durch Toggeln. Und da hatte ich eine an den Monitor-Unterrand geklebte Skizze mit der "richtigen" Portbelegung vor Augen und natürlich das eingeben.

In der Zwischenzeit, rsp. der zeitweiligen Verzweiflung kam wieder der Wunsch nach einem Hardware-Debugger auf, welcher Einzelschrittmodus kann. Das wäre dann das ausgelaufene Modell "Real ICE", das es neu nicht mehr zu kaufen gibt oder das aktuelle Modell "ICE4". Hab' heute mal geschaut und für einen Schock gesorgt:
Eintausenneunhundert Euro, ach ja, ohne Porto!
Grüße, picass