Hallo!
Stecke bei meinem jüngsten Programm fest. Das Entwanzen wird zur Zeitvernichtungs-Maschine. Der Simulator in der MPLAB-IDE entwickelt ein ungutes Eigenleben. Wenn ich mal den internen Befehl gebe: Step to Cursor, dann beginnt leider meistens der automatische Weiterlauf des Progs und alles wird unsinnig.

vlokiV Du hattest mal einen übrig, gibt es die Möglichkeit noch? Oder kennt jemand eine günstige Möglichkeit?
Grüße, picass

Zitat von: picass am 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

Ä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 

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

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

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

Hallo picass,

Der PIC zieht mit INTOSC @31kHz bei 25°C und 5V max.:
60uA im Betrieb, 48uA im Sleep.
Überlege mal, welche Selbstentladung Dein Auto-Akku hat und welchen Mindeststrom der Spannungsregler 12V->5V für den PIC ohnehin schon benötigt.
Da kannst Du doch getrost auf den Krampf mit SLEEP verzichten!? Das ist doch nur sinnvoll bei Sparbetrieb mit Knopfzellen.
Sieh lieber zu, dass die Peripherie im Ruhezustand wenig Strom verbraucht.

Und:
Stark vereinfachtes Rechenbeispiel für Garagentüröffner:
4A*1min = 0,06667Ah = 66667uAh entspricht >1000h PIC-Betriebszeit @60uA.
Da lohnt doch der Aufwand mit SLEEP nicht?

Gruß
PICkel

 

Es ist kalt geworden, dieser Tage. Nebst Schnee kann sich auch Eis ausbilden. Auf solchem bin ich gerade ausgeschleudert: nix is mit der herrlichen, heilen IRQ-Welt!
Das Prog schien den IRQ abzuarbeiten, der Simulator zeigte jedoch ein Fehlverhalten. Dem bin ich nachgegangen, zum 687. Male das Datenblatt strapaziert und glaubte dann, ein Kenner geworden zu sein. Im INTCON Register gibt es das RABIF-Flag, welches einen pin-change - zum Beispiel nach Tastendruck - vermeldet. Das Flag muss in der IRQ-Routine fix gelöscht werden, sonst rotiert so'n armer PIC ggf. immer wieder in diese IRQ-R rein. Und dieses verdammte Flag wollte sich einfach nicht löschen lassen.
Und da gabs im Kleingedruckten den Tip, diesen mismatch zu beseitigen, indem einfach mal unverdächtig PORTA ausgelesen würde, nur so, ohne das weiter zu verwerten. Tatsächlich ließ sich nach diesem Lesen endlich der Löschbefehl ausführen.
Der Simulator wies daraufhin einen völlig ungestörten und vor allem geplanten Ablauf des Progs auf. Ihr ahnt es: nur "in echt" wieder nicht. Nun will der PIC wieder nicht aus dem Schlummer raus. Darf man hier im Forum k...., also sich erbrechen, es wäre mir danach. Bin quasi keinen Millimeter weiter gekommen.
Grüße, picass

Das Grundgerüst für mein Programm "Garagentor-Steuerung".........!!! Soll ich jetzt fluchen..? Oder viel fluchen? Oder inflationär fluchen? Oder was?
Mehr als 2 Tage habe ich mit den vermaledeiten Interrupts gekämpft. Hatte ich vormals schon und nun wieder: in der Regel wollte der PIC einfach nicht aus dem Sleep-Modus via IRQ aufwachen. Das Perverse dabei, dass es im Simulator wunderbar klappte!! Nur "in echt" boshafter Weise nicht!

Gerade eben gelang es zum ersten Male, dem PIC im "PICkit Low Demo Board" ein Verhalten anzugewöhnen, das man - guter Wille vorausgesetzt - als in etwa berechenbar bezeichen könnte.
Das war voll der Horror und so recht traue ich diesem  komischen Braten nicht. Das Datenblatt ist mit teils nicht dokumentierten, rsp. "ungenauer" Schreibweise nicht immer eine Hilfe, gerne werden dort auch falsche Spuren gelegt.
Welche Flanke wann die PIC18 Interrupt Logic beeinflusst, rsp. bewirkt, ist auch ein wenig bebildertes Rätsel. Nach der Listung für "INTCON2" war ich der Auffassung, dass der IRQ bei fallender Flanke ausgelöst wird. Ja Schiete! Mal so, mal anders, im Moment aber doch wieder bei fallender Flanke.
Mist, das hat mich gaaaaaaanz viel Zeit und Nerven gekostet, und ob das nun wirklich zuverlässig so arbeitet, muss noch veritabel getestet werden.
Grüße, picass

Hallo PICkel!
Sehr herzlichen Dank für deine Arbeit und die Entwürfe! Habe alles gesichert und werde es abarbeiten. Erschrecke bitte nicht, wenn dies nicht sofort erfolgt. Bin ja gerade angefangen, das Prog für meine Garagentorsteuerung zu schreiben. Das Grundgerüst dafür muss erst stehen. Wenn das soweit gelaufen ist, dann kommen die "Features" dran. Bis dahin bitte ich um Geduld.
Aber wirklich sehr schöne Arbeit, sieht echt toll aus!
Grüße, picass