Bei den Config-Words des PIC18F14K22 taucht u.a. das ,,Primary Clock Enable bit"  auf unter der Abkürzung PCLKEN.  Bei diesem ,,Word" habe ich Info-Bedarf.

Mit ,,Primary Clock" müsste der primäre externe Oszillator (es gibt noch einen secundären solchen) gemeint sein. Richtig?
Aktuell benutze ich in allen meinen Schaltungen den ,,LFINTOSZ", also den internen Oszillator mit 31 kHz. So wie ich das im Moment sehe, hat die o.g. PCLKEN-Abfrage auf den internen Oszi keinerlei Bedeutung, will sagen, es ist egal, ob PCLKEN auf ,,1" oder ,,0" gesetzt wird.

Dann ist mir ein Widerspruch aufgefallen. Im Datenblatt steht:
- to enable software control of the Primary External Oscillator, the PCLKEN bit of the CONFIG1H Configuration register must be set.
Für mein ,,Garagentor"-Projekt hatte ich zuletzt für die Erstellung der Config-Wörter das in der MPLAB X IDE vorgesehene Tool benutzt. Danach lautet der entsprechende Ausschnitt:
- CONFIG PCLKEN = OFF    ; Primary Clock Enable bit (Primary clock ist under software control)

Also genau entgegen gesetzte Aussage. Was geht ab?
Grüße, picass

Das scheint in der Beschreibung im Kapitel 2 falsch zu sein.
In 22.1 Configuration Bits steht:

CONFIG1H Configuration register
bit 5 PCLKEN: Primary Clock Enable bit
      1 = Primary Clock enabled
      0 = Primary Clock is under software control

(In Figure 2-1 kann man es auch an der ODER-Verknüpfung erkennen)

So wirds sein. Im Databook stimmt nicht wirklich alles. So ist im Kapitel "Ports" beschrieben, dass mit einer "1" und dem Beschreiben von z.B. "TRISA" der entsprechende Port-Pin als Eingang bestimmt wird. Für das Initialisieren gibt es dann auch ein "nettes" Beispiel unter Example 8-1.
Dort sollen mit: movlw 30h und movwf TRISA angeblich die Pinne 4 und 5 als outputs gesetzt werden!   Was allerdings mit der generellen Beschreibung unter 8.1 nicht wirklich übereinstimmt!

Mit dem Gefummel um die Config-Words muss ich mich noch mal befassen, aktuell ist es nur ein optische Störung, aber das in jedem Ausdruck meiner Programmentwürfe eine DIN-A4-Seite nur mit diesem Gefummel befüllt wird, geht mir auf die Nerven.
Grüße, picass

Zitat von: picass in 15.03.2023, 10:11:48 CETaber das in jedem Ausdruck meiner Programmentwürfe eine DIN-A4-Seite nur mit diesem Gefummel befüllt wird, geht mir auf die Nerven.

Ich mache das "Gefummel" immer in eine eigene Datei,
die ich unter Umständen dann auch noch in mehreren Projekten verwende  ;-)

Gestern kam mir beim Rumschnüffeln im Datenblatt im Kapitel über die Config Words (CW) noch ein anderer Gedanke. Da fiel mir auf - erst gestern (!) - , dass es auch für diese CW's beim Start eines Progs Default-Werte gibt. Also könnte/müsste es reichen, wenn man nur für Abweichungen die geänderten Werte postet. Dazu wäre dann ggf. wieder die verkürzte Schreibweise geeignet, die ich bis dato mal in meinen Progs hatte.
Die aktuell nicht-verkürzte Schreibweise bedeutet halt, das schon angesprochene Hilfs-Tool in der MPLAB-IDE zum "geführten" Erstellen der CW's zu nutzen und dessen Ergebnis dann bequemerweise zu kopieren, rsp. komplett ins Prog zu übernehmen - was dann aber eben zur DIN-A-4-Füllung führt. Probiere das mit den Default-Werte mal aus.

Es ist doch - zumindest für mich - immer wieder aufs Neue eine Quelle von Neuem, dieses verdammt lange Datenblatt!
Nur als Randnotiz: Das Kapitel über die CW's steht bei meinem Datenblatt unter 23. Vielleicht nutzen wir verschiedene Versionen des DB's.
Grüße, picass

Würde gerne die letzte Ungewissheit ausräumen, wie lang die benötigte Zeit fürs Aufwachen aus dem Sleep-Modus ist. Dazu steht im Datenblatt für den PIC18F14K22, Auszug DB:

,,
2.8 Oscillator Start-up Timer

The Primary External Oscillator, when configured for LP, XT or HS modes, incorporates an Oscillator Start-up Timer (OST). The OST ensures that the oscillator starts and provides a stable clock to the oscillator module.
The OST times out when 1024 oscillations on OSC1 have occurred.
During the OST period, with the system clock set to the Primary External Oscillator, the program
counter does not increment suspending program execution. The OST period will occur following:
• Power-on Reset (POR)
• Brown-out Reset (BOR)
• Wake-up from Sleep
• Oscillator being enabled
• Expiration of Power-up Timer (PWRT) ,,

War bislang immer vom Befehlstakt ausgegangen, also µC-Takt geteilt durch vier. Aber richtig scheint zu sein, dass z.B. bei Verwendung eines externen Taktes mit Quarz just dessen Schwingungen am Takteingang zählen und nicht der intern durch vier geteilte. Habe ich das so richtig verstanden?
Grüße, picass

Zitat von: picass in 01.04.2023, 10:47:29 CESTAber richtig scheint zu sein, dass z.B. bei Verwendung eines externen Taktes mit Quarz just dessen Schwingungen am Takteingang zählen und nicht der intern durch vier geteilte. Habe ich das so richtig verstanden?

So sieht's wohl aus, das sehe ich genauso!

Das Dabla bezieht sich ja nur auf OSC1. Und der ist nur bei ext. Quarz bzw. Resonator aktiv. Zum OST steht da auch:
The Primary External Oscillator, when configured for LP, XT or HS modes, incorporates an Oscillator Start-up Timer (OST).

Bei HFINTOSC/LFINTOSC ist der OSC1-Pin ein normaler I/O-Anschluss.
Beim INTOSC kann zwar (je nach CONFIG-Word) der Befehlstakt an OSC2 ausgegeben werden, aber im Dabla ist beim Startup-Timer nur von OSC1 die Rede.

Gruß
PICkel

Nachtrag, da mir die Schnellbearbeitung kein Speichern anbot:

Wenn's ganz schnell gehen soll:
2-Sped-Startup aktivieren, siehe P18F14K22-Dabla Punkt 2.11. Dann startet der PIC sofort mit dem internen Takt und schaltet nach Ablauf des OST auf extern um.

MfG

Nein, besonders eilig ist da nichts. Die eintausendvierundzwanzig "Einschwinger" bedeuten bei dem 10,24 MHz-Quarz eine einzige Milli-Sekunde. Runtergebrochen auf genau den angedachten Einsatzzweck - zum Empfangen von IR-Signalen und letztlich dem Steuern eines Garagentores - stört das nicht.

Die Millisekunde spielt allerdings doch wieder eine Rolle, wenn es darum geht, das Protokoll anzufertigen. Da sind Sende - u. Empfangs-Signale schon zu koordinieren.
Grüße, picass

Zitat von: picass in 02.04.2023, 09:46:55 CESTDie eintausendvierundzwanzig "Einschwinger" bedeuten bei dem 10,24 MHz-Quarz eine einzige Milli-Sekunde.

Genaugenommen sogar nur 0,1ms, wenn ich mich nicht verrechnet habe.
Mach's doch wie viele Fernbedienungen: Erst ein "langes" Startsignal senden. Das ist bei vielen FB 4,5 oder 9ms lang. Das dient u.a. dem Anpassen der automatischen Verstärkungsregelung (AGC) im TSOP und der uC kann in aller Ruhe erwachen.
Nach der nachfolgenden Pause, bei vielen FB 4,5ms lang,  kommen die eigentlichen Datenbits.

MfG
PICkel 

Ich lese mir das durch und denke, kann ich (mal wieder) nicht rechnen?
Eine Schwingung ist doch bei 10,24mhz
1/10240000 =0,00000009765625s

Das in sind doch dann 0,00009765ms und somit 0,09765us.

Was habe ich übersehen, nicht verstanden? 

Passt schon:

Überschlagsrechnung mit glatt 10MHz (nicht mHz= Millihertz!):
1 MHz:  1us/Schwingung
10 MHz: 0,1us/Schwingung

OST zählt 1024 Schwingungen ab: 0,1 us*1024 = 102,4us = ca. 0,1ms

Gruß
PICkel

Ah da was mein Fehler Danke 

Wärme diesen Fred wieder auf, weil es themenmäßig hier so perfekt reinpasst.
Aktuell ging es "eigentlich" um das Entprellen eines Schalters, tatsächlich wichtig ist letztlich aber die Aufweckzeit aus dem Schlummer-Modus - im Datenblatt als "wake-up from sleep" genannt, wenn der fraglich PIC nicht im externem Oszillator befeuert wird, sondern mit internem Oszi. Da kommen dann wieder meine geliebten 31,5 kHz ins Spiel, welcher der LFINTOSC - also der Low-Frequency Internal Oszillator - ermöglicht.

Bei externem Oszi werden 1.024 Schwingungen z.B. des Quarzes nötig zum Aufwachen. Wie isses nun bei dem LFINTOSC ? Ist der etwa beim Wechsel des digitalen Signals eines Portpins von jetzt auf gleich zur Aufnahme seiner weiteren Programm-Abarbeitung in der Lage? Im Datenblatt kann ich da nichts finden.
Hauptgrund für die Anfrage ist tatsächlich nicht die Entprell-Übung eines Schalters, sondern die im Moment vorliegende Nicht-Übernahme des Portzustandes, welcher geweckt hatte. Anders gesagt: wenn mehrere Weckereignisse möglich sind wie z.B. Wecken an mehreren Portpinnen, dann muss der Port abgefragt werden (z.B. movf PORTA,0 und movwf WECKER). Dieses Abspeichern des Port-Status in eine Variable klappt nicht, obwohl es der Sprut z.B. genauso auch getan hatte. Aber bitte erst die Frage der Aufweckzeit für den LFINTOSC beantworten.
Grüße, picass

Hi picass
habe im Datenblatt des 18F1XK22 das gefunden: (Seite 21)

Sleep/POR LFINTOSC
HFINTOSC
Oscillator Warm-up Delay (TWARM )

und dann gaaaaaaanz unten auf seite 342

Wake-up from Sleep Start-up Time 5us typisch  8us max bei  VDD = 2.0V, -40°C to +85°C

gilt aber auch so bei VDD 5V
musst also mit 8 us gerechnen. 
Wobei dann noch die Frage ist ob du ein PowerON reset usw. aktiv hast. 
übrigens steht da auch sowas nettet:

* These parameters are characterized but not tested.

Hoffe hilft dir bisschen weiter.

Ach, Cobra, ach..... du wirst weiter hoffen müssen!

So wie ich das interpretiere, gibt das wieder nur einen eindeutigen Hinweis auf die Start-up-time des externen Oszis.

Vielleicht gibt es ja die Möglichkeit, eine kleine Testroutine zu erstellen, welche das Aufwachen aus Schlummer in einer Schleife und in definierten Abständen immer erneut auslöst, sodass man mit einem Oszi die Chance hätte, aus dem "0" / "1" - Gewimmel was raus zu lesen. Vielleicht einen Timer-Interrupt auslösen. Räusper...., hatte ich noch nicht. Naja, danke fürs Erste.
Grüße, picass

@Cobra
Hatte gerade schon ein feine Skizze erstellt, welche die Einbettung einer Sleep- und deren Aufwachzeit in den Takt eines externen Taktgenerators anzeigte. Mithilfe von einer LED, die am Anfang und nach dem Ende des Schlummmerns gesetzt, bzw. gelöscht würde, könnte auf einem Oszi dann die Zeit für das Aufwachen heraus gefiltert werden. Das würde auch funktionieren. Aber..... dann kam mal wieder ein Blick ins Datenblatt und nu' schätze ich die Situation anders ein.
Deine abgebildeten ersten 3 Zeilen gehören zu den Ausführungen über das "Clock-Switching". Dazu gehört auch eine Abhandlung über "Two-Speed Start-up-Mode". Letzteres beschreibt diese Situation: Ein PIC wird mit externem Oszi (z.B. Quarz) betrieben und es soll aus Stromspargründen gelegentlich der Sleepmodus benutzt werden. Andererseits ist Zeit kostbar und die 1.024 Takte, welche nach dem Aufwecksignal fällig werden, um wieder auf full-speed zu kommen, sind zu kostbar, um ungenutzt zu bleiben. Also wurde der "2-Geschwindigkeiten Startmodus" erfunden. Und das geht nach dessen Konfigurierung so: nach dem Schlummer versucht sich der High-Speed-Takt mit dem Warmlaufen über 1.024 Takte, aber trotzdem wird sofort nach dem Ende des Schlummers die reguläre Programmausführung begonnen, indem auf den Takt des internen Oszis, des LFINTOSC, umgeschaltet wird, also der mit seinen 31.250 Hz. Mit diesem "Handbremsen-Takt" wird also vollwertig das Programm wieder aufgenommen und sobald diese 1.024-Takt-Zeit rum ist, wird umgewitscht auf den rasenden, externen Takt. Tolle Technik.

Das kann aber selbstredend nur dann funktionieren, wenn der interne Oszi nach dem Sleepen nicht auch 1.024 Takte oder ähnlich benötigt. Aber der ist nach dem Sleepen offenkundig komplett da und voll einsetzbar. Langer Rede, kurzer Sinn: der LFTINTOSC hat demnach mit einer Aufweckzeit nichts am Hut, der muss entsprechend immer durchlaufen oder aber ist nach einem eigenen Stopp sofort wieder am Werk - aus einem Diagramm könnte man, wenn man so will, exakt 4 Takte, also einen Cyclus raus lesen an Verzögerung, rsp. Syncronisation.
Ob ich das mit dem oben angesprochen Test noch ausführe, hängt davon ab, ob sich einfach und schnell ein Rechteckgenerator mit 32 µS Taktzeit bauen lässt. Aber erst mal gehe ich davon aus, dass diese Aufweckzeit für den LFINTOSC nicht gilt.
Grüße, picass

Der Rechteckgenerator ließ sich echt einfach erstellen: es gibt ja den guten, alten LM555. Der kann auch im Micro-Sekunden-Bereich!
Und nu' isses amtlich: Der PIC18F14K22 in seiner Einstellung auf den LFINTOSC, also den laaaangsamen internen Oszi, kommt extrem jählings aus dem Schlummermodus ans Laufen. Er braucht dafür keine 1.024 Takte, er braucht auch keine 20 Takte, er braucht nix Takte: auf die Plätze und schon ist er ein gutes Dutzend Cyclen weiter!

Die Testanordnung: Der PIC "rennt" mit 31.250 Herz! Der LM555 erzeugt eine astabile 1:1 Rechteck-Impulsfolge. Eine positive Flanke triggert den INT2 des PIC, also den Interrupt an Port A,2 . Im Prog wird dann der IRQ wie üblich ausgeschaltet, eine LED eingeschaltet, ein paar NOPs folgen, um auf 6 Cyclen zu kommen und dann gehts im Programm ab nach vorne und direkt vor die Schlummer-Routine. Erst die LED aus, dann - is klar - den IRQ enablen und in der "0"-Flanke des LM555 hebt das Schlummern an....., bis zu dessen positiver Flanke. Und das ist dann die Schleife.
Hat super geklappt. Auch Grundlagen-Forschung - hüstel, wenn der Ausdruck erlaubt ist - kann Spass bereiten.
Grüße, picass
wakeup.txt
Die LED-"1"-Zeit ergibt genau 6 Cyclen.

Kleiner Nachtrag, rsp. kleine Korrekturen zu obigen Darstellungen.
Nach Beginn der ersten "1"-Phase und dem Sprung im Prog nach vorne vor die Sleep-Routine beginnt das Schlummern nicht erst in der nächsten "0"-Flanke des Timers, sondern natürlich schon in der noch anliegenden "1"-Flanke. Und dann: die Bezeichnung "ca. 26 Cycles" steht sinnbildlich nur für die dafür notwendige Zeit. Tatsächlich wird in der Schlummerphase ja gerade nichts "gecycled", jedenfalls nichts Programm-Mäßiges.
Jetzt könnte man noch drüber grübeln, ob während der Schlummerphase tatsächlich auch der interne Oszi gestoppt wird und sich quasi per Schalter-Umlegen von jetzt auf gleich wieder in Betrieb nehmen lässt, oder ob der Interne immer durch läuft. Vom Ergebnis nach außen hin ist es egal, aber falls jemand da was weiß....?
Grüße, picass

ich denke der LFINTOSC wird im Sleep-Modus abgeschaltet, wenn kein Watchdog eingeschaltet ist.

18.3 Sleep Mode
The Power-Managed Sleep mode in the
PIC18(L)F1XK22 devices is identical to the legacy
Sleep mode offered in all other PIC microcontroller
devices. It is entered by clearing the IDLEN bit of the
OSCCON register and executing the SLEEP instruction.
This shuts down the selected oscillator (Figure 18-1)
and all clock source status bits are cleared.
Entering the Sleep mode from either Run or Idle mode
does not require a clock switch. This is because no
clocks are needed once the controller has entered
Sleep. If the WDT is selected, the LFINTOSC source
will continue to operate. If the Timer1 oscillator is
enabled, it will also continue to run.
When a wake event occurs in Sleep mode (by interrupt,
Reset or WDT time-out), the device will not be clocked
until the clock source selected by the SCS<1:0> bits
becomes ready (see Figure 18-2), or it will be clocked
from the internal oscillator block if either the Two-Speed
Start-up or the Fail-Safe Clock Monitor are enabled
(see Section 23.0 "Special Features of the CPU"). In
either case, the OSTS bit is set when the primary clock
is providing the device clocks. The IDLEN and SCS bits
are not affected by the wake-up