Das nächste Projekt ist im Entwicklungsstadium. Es handelt sich um die Steuerung eines elektrischen Garagentor-Antriebes (eGA), besonderes Merkmal: die Power kommt aus einem 12-Volt-Autoakku und der hat sie wiederum von einem Solarpanel auf dem Garagendach. Das bislang existierende Fertigprodukt will nicht mehr! Während der Entwicklung eines Neuen wird es immer wieder Detailfragen geben, die ich gerne in diesem Fred unterbringen würde, egal, ob es um Hardware oder Softwareprobs geht, um nicht gleich die unendliche Fred-Vermehrung zu betreiben. Es würde mich freuen, wenn ihr hier zwischendurch immer mal reinschauen würdet.

Erste Frage: Ist für das erwünscht störungsfreie Arbeiten des PICs eine metallische Abschirmung nötig?
Dagegen:
- in der Anlage des Fertigproduktes des eGA gab es keine. Der darin auch werkelnde PIC war einfach in einem Kunststoffgehäuse untergebracht.
- ,,mein" PIC, ein PIC18F14K22  - is klar, was sonst ? - wird mit Handbremse betrieben, also über den internen LFINTOSC-Oszi mit nur 32 Khz.
- das Ganze wird halt in einer Garage montiert, die nicht mal einen 230-V-Anschluss hat. Direkte Störungen würde ich da nicht erwarten.

Dafür:
-jetzt ihr!
Grüße, picass

Also ich würde alle nicht benötigten Eingänge niederohmig, aber kuzschlußfest (330 Ohm?) auf GND legen, die benötigten Input-Pins, wenn möglich, mit R/C-Kombination entstören.
Besser, wenn der geringfügige Mehrverbrauch keine Rolle spielt: freie Pins als OUT deklarieren und unbeschaltet lassen.
Auf jeden Fall, um "Hängen" des PIC zu vermeiden: Watchdog-Timer nutzen!

Gruß
PICkel

Danke für den Ratschlag "niederohmig", aber vergebene Liebesmühe! Aisler war diesmal zu schnell. Gestern gegen 19 Uhr den Entwurf übermittelt, heute morgen um 6 Uhr kam die Nachricht: bereits in Produktion. Knurr......., hätte gerne noch den Durchmesser einiger Vias vergrößert... nix geht mehr. Ist aber Beides kein Prob und damit zum Stichwort"Stromverbrauch keine Rolle".
Wenn der Leerlaufstrom eines Autoakkus nicht über 25 mA, in Grenze auch 50 mA rüber klettert, kann der Akku das in der Regel ab. Ist unwahrscheinlich, dass ein PIC im Schlummer mit seinen als OUT geschalteten Ausgängen diese Hürden reißt!

Zwecks meiner Frage nach Abschirmung: hat sich wohl auch erledigt. Habe eben beim Wühlen in meinen Regalen ein exakt passendes kleines Alugehäuse gefunden. Das werde ich nehmen. Aber weniger wegen der Abschirmung, als vielmehr deswegen, weil man da so praktisch diverse Buchse anmontieren kann.

"Hängen" vermeiden mit Watch-Dog-Timer? Ähm, hatte ich noch nicht, da brauche ich noch ein Kurzinfo zu.

Wer mal einnen Blick auf die Schaltung werfen möchte, bitte sehr: siehe Bilder.
Grüße, picass

Wie wäre es noch mit einer ISCP Schnittstelle.
Oder nimmst du den Controller immer raus wenn du ihn programmierst ?

Zum Thema Watchdog-Timer:
Durch äußere Einflüsse (Spannungseinbruch, elektrostatische Entladung, ...), oder Bedienfehler, Programmfehler u.ä. kann es passieren, dass der PIC in eine Dauerschleife gerät.
Und wenn der PIC nicht mehr reagiert, geht vielleicht auch die Garage nicht mehr auf???

Deshalb gibt es den Watchdog-Timer: Ein Oszillator (LFINTOSC) mit ca. 31kHz arbeitet auf einen Zähler mit Pre- und Postscaler. Läuft der Zähler über, wird der PIC neu gestartet. Das geschieht je nach Einstellung nach spätestens 2,18 Minuten.
Deshalb wird im Programm an geeigneter Stelle zyklisch der Watchdog-Timer vor Ablauf der eingestellten Zeit mit CLRWDT zurückgesetzt und somit ein Neustart vermieden.
Arbeitet das Programm nicht mehr korrekt, erfolgt das Rücksetzen mit CLRWDT nicht mehr und es gibt den Neustart.

Ich habe z.B. eine Gewächshausbelüftung mit PIC12F683 gebaut, die nur mit Solarzellen und Pufferkondensatoren ohne Batterie arbeitet. Bricht die Spannung ein, könnte der PIC "nervös" werden. Die Brown-Out-Detektion wurde aktiviert, und der WDT bietet zusätzlichen Schutz.

Gruß
PICkel

@Peter :Du hast es erahnt. Bei diesem Entwurf hatte ich - anders als bei meinen letzten Platinen - keine Vorsorge fürs Programmieren des eingebauten µC's getroffen. Und konsequenterweise auch die "große" Bauform gewählt. Sollte ein Umprogrammieren fällig werden, ist die Entnahme des µC's die vielfach einfachere Methode - in diesem Fall. Zudem habe ich bei Versuch, die alte Schaltung wieder zu beleben, es schätzen gelernt, an der DIL-Version fix mal 'ne Messspitze ranhalten zu können. Und Platz spielt da auch keine Rolle.

@PICkel :Danke für die Ausführung. Das Datenblatt ist komischerweise nicht sehr auskunftsfreudig. Da wird jedes Bit der notwendigen Register erläutert, aber wozu das Ganze, das habe ich dem Blatt nicht entnehmen können.
Du bist aber schon irgendwie sorglos! Kaum ist ein Begriff geklärt, wirfst du einen anderen in den Ring, alles so Sachen, die ich bislang praktisch nie genutzt hatte.

Die Aisler-Jungs&Mädels nerven mich gerade! Erst haben sie in Rekordzeit mit der Produktion der Platine begonnen und damit verhindert, dass ein (leichte) Nacharbeit möglich war, und nun kommen sie nicht aus dem Quark, nicht mal die übliche Meldung der Fertigstellung und dem Absenden ist bislang gekommen. Da habe ich den Aufpreis - also quasi das Doppelte - bezahlt, um diesmal fix ans Löten zu kommen, und nu' is nichts mit dem Versprechen der wenigen Arbeitstage.

Grüße, picass

Zitat von: picass in 27.03.2022, 10:06:36 CESTSollte ein Umprogrammieren fällig werden, ist die Entnahme des µC's die vielfach einfachere Methode

Ein Tipp dazu:
Die Beine der ICs verbiegen sich gern beim Einstecken oder Herausziehen aus der Fassung:
Stecke während der Testphase den PIC in eine normale IC-Fassung und benutze diese Kombination anstelle des einzelnen PIC. Verbogene/abgebrochene Pins kosten Dich dann nur noch eine neue Fassung und keinen neuen IC.

Zum Thema Watchdog:

https://www.youtube.com/watch?v=EdG2QtoUE9w
Bis etwa zur 4.Minute gibt es eine kompakte Übersicht über die Konfiguration.
(Danach geht's mit C weiter, was ich mir als normaler Mitteleuropäer nicht {mehr} antue.)
Wenn Du Dich damit befassen willst, eine Testplatine und einen Oszillographen hast, kann ich Dir mal ein Demoprogramm senden.

Gruß
PICkel

Zitat von: PICkel in 27.03.2022, 14:01:02 CESTWenn Du Dich damit befassen willst, eine Testplatine und einen Oszillographen hast, kann ich Dir mal ein Demoprogramm senden.

Ja..., ja..., ja..., ja....!

Kuck an! Da ist ja noch einer, welcher einen Bogen um das große "C" schlägt!
Aber dennoch müssen wir längst keine gemeinsame Sache machen, also zumindest beim Programmieren. Hoffe, dein Demo-Prog lesen zu können.

Verdammich, bei Aisler klemmt es. Zwei Tage fürs Blitzboard bezahlt, aber nach 5 Arbeitstagen herrscht dort tiefe Ruhe.
Grüße, picass

OK,
derzeit habe ich wegen des guten Wetters mit Brennholz zu tun. Der Heizölpreis lässt grüßen...
Im Laufe der Woche dürfte es dann aber klappen.

Gruß
PICkel

Auch bei mir fordert das schöne Wetter Tribut und deshalb auch jetzt nur ganz kurz und dann auch schon wieder weg:
Die Aisler-Jungs&Mädels haben geliefert und - is klar - innerhalb eines Tages war die Platine auch bestückt, siehe Bild. Das Programmieren hebt dann ab morgen an. Fix wech...
grüße, picass

Hallo picass,

hier ist mal ein kleines Prog. (80 Byte) zum Test des Watchdog- Timers (WDT).
Der WDT wird vom LFINTOSC (ca. 31kHz) abgeleitet und hat einen festen Vorteiler von 1:128.
Das ergibt einen Takt von ca. 4ms, der bis max. 1:32768 (ca. 2min) geteilt werden kann.
Im Demo- Beispiel wird 1:16 geteilt, das sind ca. 64ms.
Getestet wurde mit einem PIC18F24K22, der sehr ähnlich zum 18F14K22 ist.
Voreinstellungen: INTOSC mit CLKOUT, WDT Enabled, WDT Postscaler: 1:16.

An CLKOUT (PortA.4 beim P18F14K22) sollte sich das Taktsignal von ca. 7,5kHz messen lassen.
An PORTB.7 wurde das Oszilloskop angeschlossen.

Ablauf anhand des Oszillogramms WDT_Timing.jpg:
1: PORTB.7 = 0   
2: 5ms gewartet, dann PORTB.7 auf 1 zum Triggern des Oszi
3: 10ms geartet, dann zurück auf PORTB.7=0
4: 10ms gewartet, PORTB.7 = 1, WDT zurückgesetzt, warten auf Ansprechen des WDT
5: nach ca. 67ms "schlägt der WDT zu", der PIC wird resettet -> goto 1:
Das Ganze wird also zyklisch wiederholt.

Zur Konfiguration:
Die entsprechenden Config-words habe ich im Compiler voreingestellt:
- INTOSC mit CLKOUT
- WDT ein, Postscaler 1:16
Ich nehme an, Deine Programmierumgebung bietet ebenfalls diese Optionen.

Im ZIP-File findest Du: Programm, Assemblercode und ein HEX-File zum direkten Brennen.

Gruß
PICkel

WDT.zip   

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

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

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

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

 

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