Stelle das hier mal in einen Sammelfred für Detailfragen, wenn es sich nicht lohnt, einen eigenen Fred zu eröffnen. Die erste Frage:
Wielange dauert es, bis so ein PIC18F14Kxx aus dem Sleepmodus erwacht ist? Für den Fall, dass ein externer Oszillator betrieben wird, und für die Fälle laut Datenblatt wenn der im LP, XT oder HS-Mode configuriert ist, lautet die Antwort klar:"....when 1.024 oscillations on OSC1 have occured."

Aber meinen PIC betreibe ich mit dem internen Oszillator und dort mit dem LFINTOSC, einem extra Oszi für 31.250 Hz. Der ist an mehreren Stellen im Datenblatt vom Treiben der o.g. Familien ausgenommen. Über den habe ich nichts gefunden, obwohl ich das Datenblatt mehrfach ausgewrungen habe. Wäre aber schon gut zu wissen....
Grüße, picass

Zitat von: datasheet18.5.4 EXIT WITHOUT AN OSCILLATOR
START-UP DELAY
Certain exits from power-managed modes do not
invoke the OST at all. There are two cases:
• PRI_IDLE mode, where the primary clock source
is not stopped and
• the primary clock source is not any of the LP, XT,
HS or HSPLL modes.
In these instances, the primary clock source either
does not require an oscillator start-up delay since it is
already running (PRI_IDLE), or normally does not
require an oscillator start-up delay (RC, EC, INTOSC,
and INTOSCIO modes). However, a fixed delay of
interval TCSD following the wake event is still required
when leaving Sleep and Idle modes to allow the CPU
to prepare for execution. Instruction execution resumes
on the first clock cycle following this delay

-> FIGURE 18-4: TRANSITION TIMING FOR WAKE (from idle) TO RUN MODE
-> TCSD ~2/31kHz?

Das verstehe ich jetzt so: Zu diesen in Klammern gesetzten Beispielen für Oszillator-Modes, die (fast) keine Verzögerung brauchen, gehört dann wohl der Betrieb über den langsamen internen Oszi - sofern der Begriff INTOSC auch denjenigen des LFINTOSC umfasst. Also nix Verzögerung, bis auf irgendwas zwischen einem und zwei  Clocks. Ist ja prima, damit ist der Betrieb dieses PIC18F14K22 via LFINTOS-Oszillator ja was echt Fixes. Auch wenn man angesichts der maximalen Frequenzen, mit denen moderne CPUs befeuert werden, bei einer Frequenz von 31 KHz ja schon bald von Gleichstrom sprechen kann, ist der Bursche bei genauem Hinsehen ja echt schnell. Erst nach dem Einstellen meiner Frage hatte ich mich bequemt, den Taschenrechner aus der Ecke zu kramen und mal den reziproken Wert dieser Frequenz zu bilden. Und den dann mit dem mir bis dato noch vorschwebenden Faktor von 1.024 für externe Oszis zu multiplizieren. Selbst das würde nur 33 MilliSekunden beanspruchen. Hätte den TR mal früher raus kramen sollen, oder aber.... hätte ich in der Schule ein besseres Englisch gelernt, wäre Manches nicht so hakelig. Danke für die Nachhilfe, vloki.
Grüße, picass

Zitat von: picass in 19.04.2021, 14:39:04 CESTOszillator-Modes, die (fast) keine Verzögerung brauchen, gehört dann wohl der Betrieb über den langsamen internen Oszi

Also, ich habe mir darüber vorher natürlich auch noch nie Gedanken gemacht, würde es aber auch so sehen.
(und evtl. mal versuchen das mit dem Oszi nachzumessen, indem nach dem Sleep gleich ein Pin getoggelt wird oder so)

Hat ein wenig gedauert, die Causa ,,Dauer nach sleep", dafür gettz reichlich. Mein Versuchsaufbau ergibt das Ergebnis: nix Warten, sofort weiter. Aber ob das stimmt und nicht irgendwo ein Pferdefuß auskeilen will, bedarf sicher der Überprüfung. Der elektronische Schaltungsteil:
Ein Trafo mit 2 Sek-Wicklungen sorgt über eine davon für die übliche Power, die andere, galvanisch getrennte, sorgt für wilde Schwingungen. Von denen wird über eine schlichte Diode jede zweite Halbwelle weg radiert, und die verbleibende HW auf einen 74HCT14 – einen negierenden Schmitt-Trigger – geführt. Weil dessen Schaltschwelle so etwa bei 1,5 V liegt, schneidet der ,,vorne" und ,,hinten" von der positiven Halbwelle noch was weg. Übrig bleibt dann am negierenden Ausgang eine Rechteckschwingung, bei welcher die ,,Eins"-Periode 12 von 20 Anteilen hat und die ,,Null"-Periode 8 von 20. Die 20 steht dann für die 20 Milli-Sekunden, die so'n Haushalts-Wechselstrom für eine einzige Sinus-Schwingung heuer so anbietet.

Mit der ansteigenden Flanke der ,,1"-Periode wird ein schlichter NPN-Transistor durch geschaltet und an dessen Kollektor-Widerstand nach Plus hin fällt dann ebenfalls eine ,,1" ab. Dieselbe ,,1"-Flanke hinter dem HCT14 wird auch zum PIC18F14K22 weiter gereicht an seinen PortB-Pin RB5. Dieser Pin ist interrupt-mäßig frei gegeben für den IRQ on-Port-Change und soll den PIC aus dem Schlummer aufwecken. Sobald der geweckt und als Erstes alle IRQs gesperrt hat, setzt er am PortC den Pin RC7 auf ,,1". Diese ,,Eins" wird auf einen weiteren NPN-Transistor – gleich wie vor – geleitet, und wenn der daraufhin schaltet, zieht er seinem Kumpel den Basisstrom weg, rsp. legt dessen Basis auf ca. 0,2 Volt, was dazu führt, dass der Kumpel an seinem Kollektor-Widerstand die ,,1" aufgibt und dort eine ,,0" installiert.

Das Programm ist erschütternd kurz: es ist ein Teil des funktionierenden Progs, in welchem der ,,Kell-PIC" via Tasten geweckt wird und via Bus die ,,Roll-PICs" anpreit. Am Start des Progs werden die Ports intialisiert, dann die Interrupt-Angelegenheiten vorbereitet, und dann geht es unmittelbar ab zum Sleepen – wobei erst der IRQ für den Port-B-Wechsel freigegeben wird und unser hier interessierender Port C Pin RC7 auf ,,1" gesetzt wird. Nach dem Aufwachen werden die IRQs gesperrt und der RC7 auf ,,0" gesetzt. Dann springt das Prog sogleich wieder auf den Eingang der ,,Zum-Schlafen"-Routine. Die Sleep-Zeit wird in sehr kurzem Kreislauf immer wieder umrundet. Also: Unmittelbar vor dem Sleepen RC7 auf ,,1", unmittelbar nach dem Aufwachen RC7 auf ,,0".

     
schlaf
     clrf   INTCON          ;erst alte irq-anzeigen löschen
     bsf    INTCON,GIE      ;irq freigeben
     bsf    INTCON,RABIE    ;port a u b für irq-on-change freigeben
                            ;fetch noch ausführen!
     bsf    LATC,7        ;aufwachtest: auf Null
     sleep
                            ;nach aufwachen irq's sperren,um störungen
                            ; und wiederholungen zu vermeiden
     bcf    INTCON,GIE      ;irq disablen
     bcf    INTCON,RABIE    ;port a und b für irq-on-change sperren
     bcf    INTCON,INT0IF   ;irq-flag extern zurücksetzen
     bcf    INTCON,RABIF    ;irq-flags port a und b zurücksetzen
     bcf    LATC,7          ;aufwach-test: auf Eins
     goto   schlaf
                       


Am Oszi lässt sich ein Signal beobachten mit sehr kurzer ,,1"-Zeit. Diese ,,1"-Zeit beträgt laut Cursor-Messung 740 µS. Mithilfe eines anderen Progs hatte ich versucht, mich den Taktzeiten des PIC18F14K22 anzunähern. Der wird ja mit seinem internen LF-Ozsi ,,befeuert" und das soll offiziell 31.250 Hz bedeuten. Rein rechnerisch ist ein µC-Takt dann 32 µS lang. Der µC-Takt multipliziert mit der Zahl Vier ergibt dann die Zeit für einen Befehlstakt, den ich intern als ,,Cycle" getauft habe: 128 µS ! Um das zu verifizieren, hatte ich ein Programm mit 97  ,,NOPs" befüllt, nur zwei Cyclen gingen auf den Sprung-Befehl ,,zurück-zum-Anfang" und ein weiterer auf das Toggeln eines Port-Pinnes, also alles zusammen exakt 100 Befehle mit je einem Cycle. Der Oszi sagt dann laut Cursor-Messung dieser Hunderter-Routine anstelle der rechnerisch zu erwartenden 12,8 mS nun 12,06 mS. Das hieße, ein Cycle würde oszi-mäßig-real statt 128 µS nun 120,6 µS dauern.

Gettz wieder zu der ermittelten ,,Eins-Zeit" über der Sleep-Zeit mit 740 µS. Da passen entsprechend 6 Cyclen mit je 120,6 µS rein und es verbleibt noch ein Rest von 16,4 µS fürs Sleepen.6 Cyclen also und die kann man im Programm exakt wieder finden vom Setzen bis zum Löschen  des RC7. Gänzlich unwissenschaftlich habe ich das bislang nur dreimal so ausgeführt, rsp. so gemessen. Frage an die PIC-Gemeinde: Pferdefuß oder isses so gut? Was hieße: gar keine Aufwachzeit!
Grüße, picass

Hatte ein Bild in der Hektik vor dem angemahnten Sonntags-Spaziergang übersehen, hoch zu laden.
Grüße, picass

Habe die Testsituation noch etwas verändert: Der Aufweck-Impuls wurde syncronisiert, indem erst eine positive Flanke, danach eine negative gewartet wurde und dann bei der nächsten positiven der Start-Impuls ausgegeben wurde. Das brachte eine Veränderung, allerdings nur eine marginale. Anstelle der 740 µS waren es nun 990 µS. Nach einer weiteren Modifikation schienen es auch unter gewissen Bedingungen 1200 µS sein zu können. Das Wort "scheinen" wurde bewusst gewählt, denn die Testbedingungen wurden unerfreulich. Die vielen auf- rsp. angelöteten Draht-Verhaue wirkten wohl als Antennen und der ganze Aufbau wurde instabil, so auch die Ablesung am Oszi.
An der Stelle habe ich dann weitere Test abgebrochen. Das Ergebnis war bis dahin ja klar genug: der LF-Oszi mit seinen 31,25 kHz benötigt keinerlei lange Aufwachphase so wie die externen Oszillatoren mit ihren 1.024 Takten. Der LF-Oszi begnügt sich mit irgendwas im Micro-Sekunden-Bereich, und kann daher weitestgehend vernachlässigt werden.
Drei Befehls-Takte als Sicherheits-Puffer, und gut muss es sein.
Grüße, picass