Also ich bevorzuge für allgemeine Aufgaben Taktfrequenzen von 1 bis 4 MHz. Das ist ein Taktbereich, der für Ausgaben auf Text-LCD, I²C und zügige Interrupt- Abarbeitung ausreichend ist.
4MHz haben zudem den angenehmen Effekt, dass jeder Befehl 1us dauert und Zeitberechnungen mit Timeranwendungen übersichtlich macht.

Es muss manchmal auch schneller gehen:
- Viele umfangreiche Rechenoperationen (Winkelfunktionen, Wurzelziehen usw.): Meine CNC-Steuerung mit PIC18F6722 arbeitet z.B. mit 32MHz.
- Zeitkritische Anwendungen: Die Ansteuerung von WS2812 erfordert ein präzises Timing: Auch hier sind 32MHz (=125ns/Takt) sinnvoll, die exakte Ansteuerung musste dabei in Assembler geschrieben werden.

Es muss manchmal auch langsamer gehen:
- Batteriebetriebene Geräte erfordern bei Langzeitbetrieb eine möglichst geringe Leistungsaufnahme: Ich arbeite gerade an einer batteriebetriebenen Uhr, die per Induktion gebremst wird. Dazu werden 10Hz-Impulse einer Magnetscheibe mit einem 32768Hz- Takt verrechnet.
Hier benutze ich:
Warten bei 31kHz, bis die Magnetscheibe läuft
Danach: Impulse zählen 0,8s bei 125kHz
Umschalten auf 2MHz, 0,2s  Impulse auswerten bei 2MHz, zurückschalten auf 125kHz.

31kHz entsprechen 7750 Befehlen/sec (0,129ms Takt), das mag manchmal genügen, ist mir aber zu langsam, wenn nicht auf geringstmögliche Stromaufnahme geachtet werden muss. Vor Allem, wenn Interrupts möglich sind und der Programmablauf nicht zuuu lange unterbrochen werden darf.

Gruß
PICkel
   

Hallo Ottmar !
Deine Rechenübung kann ich nicht nachvollziehen.
Zunächst stimmt deine Zuordnung nicht: h'dbf0' sind d'56.304'

Dann ist völlig unklar, was genau du denn nun den PIC zählen lassen willst, um von seiner hohen Frequenz runter zu kommen auf 1 Hz. Takt soll 4 Mhz sein, ein Cyclus dann 1 Mhz, also jeder Cyclus belegt 1 µS. Dann soll nach deiner Rechnung der Counter1 gesamt 55.536 µS abzählen. Und wie kommt man nun auf eine Sekunde ?
Grüße, picass
 

Das Thema ist schon an verschiedenen Stellen in unseren Beiträgen aufgetaucht, aber nie vom Grundsatz aus beleuchet worden. Es scheint beim Schreiben der Programme "normal" zu sein, einen µC mit seiner maximal möglichen Frequenz zu betreiben. Darüber scheint niemand oder kaum jemand überhaupt zu reflektieren...., was mich persönlich verwundert. Selbst hatte ich mir schon vor langem angewöhnt - im Grunde seit meinen ersten Programmerstellungen überhaupt dunnemals für den berühmten PIC16F84 - , jedesmal über die sinnvolle Betriebsfrequenz zu grübeln und das auch umzusezten. So laufen fast alle PICs in meinen Steuerprogrammen nicht mit dem Maximum, sondern dem exakten Gegenteil, dem Minimum, und das liegt bei 31.250 Herz.
Meine Überlegung dabei: warum sollte der µC schneller laufen, als es für die Steuerung im Programm sinnvoll und notwendig ist? Es ist mir bewusst, dass dies statistisch eine Minderheitenmeinung ist. Aber gerade deswegen bin ich an einer Debatte interessiert und würde gerne hören, mit welchen Argumenten denn ein Betrieb am Maximum unterstützt wird.
Grüße, picass

Was können wir als PIC-Programmierer von James Bond lernen? Zum Beispiel die Aussage - enthalten in einem Film-Titel - , die da lautet: "Sag niemals nie"!
Da hatte ich mich doch vom Assembler-Programmieren abgewandt in der stillen Zuversicht, mit MicroPython (MP) auf eine Hochsprache wechseln zu können. Der erste Anfang - die Verdoppelung ist kein Versehen - war auch fix gemacht. Ein Sonderheft aus dem Heise-Verlag verschaffte erste, rasche Erfolge mit dem 32-Bitter Raspberry Pi Pico und ein nicht-preiswertes Buch versprach das Erlernen der Programmierung von MP.
Und dann kam die Ernüchterung: Einige ganz wenige Winzi-Prog-Schnippsel sind ja ganz nett, aber ein Einstieg in "echtes" Programmieren war das natürlich nicht. Und das Buch hielt auch im Ansatz sein Versprechen nicht ein. Es gab nur wenige sinnvolle Einstiegs-Beispiele und dann kam der Autor rasch auf seine Lieblingsthemen wie Internet-of-the-things! Das wäre ja noch harmlos, aber es war weit und breit keinerlei Darstellung, was denn nun ein Programm in MicroPhyton ausmacht, wie seine Struktur ist, es gabe keine Übersicht über Bibliotheken und noch weniger Erklärungen darüber. Kurz:  außer teils skurrilen Beispielen war da nix mit Programmieren-Lernen. Die Unterstützung durch Firmen war auch nicht das "Gelbe vom Ei", da broselte jeder so vor sich hin und nicht mal für einen gleichen Sensor gab es verwendbare Bibliotheken.

Die anfängliche Freude blieb mir rasch im Hals stecken. Dazu kam die ernüchternde Erkenntnis, dass inzwischen schon wieder gänzlich andere, neue Säue an Micro-Controllern durchs Programmier-Dorf getrieben wurden/werden. Noch härter: es werden immer neue Prog-Sprachen gepuscht und von MircoPhyton ist anscheinend nirgends mehr die Rede. Das hatte ich mir anders vorgestellt und gewünscht.

All das führte zunächst zu einer Prog-Pause und seit einiger Zeit tue ich das, wovon ich wenigstens etwas verstehe: vom Assembler-Programmieren. Da stolpere ich zwar immer wieder über irgendwelche Fallstricke, welche das Datenblatt bereit hält, aber immerhin kann ich mit Gestrampel und eurer Unterstützung zu Erfolgen kommen. Für die meisten Steuer-Anwendungen langt das ja auch. Im Moment also wieder alles beim Alten und das wird auch solange so bleiben, bis sich irgendwo oder irgendwie ein echter, rsp. überzeugender Einstieg in die Programmierung einer eher einfach zu erlernenden Hochsprache auftut.
Grüße, picass

A

Zitateinen Preset 2^16us - 20.000us = 45536 = 0xB1EO

richtig ist: 
2^16us - 10.000us = 55536us = 0xDBF0
denn die Periodendauer von 50Hz ist 20ms und dafür bedarf es 2 ISR-Intervalle zu je 10ms.

Hi picass,
langer Rede kurzer Sinn: Es geht einfacher, ohne Netzanbindung/Optokoppler und Halbwellenbildung, eine exakte 50Hz-Frequenz zu generieren.

Nimm das von mir anfänglich übermittelte ASM-File mit diesen Änderungen:
Internen Oszillator, Fosc = 4Mhz, das ergibt Fosc/4=1.000.000 wc (working cycles). 

Diese nimmst Du als clock für den TMR1, dazu den TMR1 overflow-Interrupt. In der ISR machst Du einen Preset 2^16us - 20.000us = 45536 = 0xB1EO.

Die "Denkpause" wird  vermieden, wenn man direkt vor Freigabe des Interrupts, (bsf INTCON,GIE) den TMR1 auf den Preset wie nachstehend setzt.

ZitatISR_H:
bcf        PIR1,TMR1IF
movlw   0xB1
movwf   TMR1H
movlw   0xE0
movwf   TMR1L
movlw   b'10000000' ;LED ist an bit 7
xorwf    PORTA,f        ;RA7 toggelt alle 200ms und LED blinkt mt 50Hz
RETFIE  FAST

Voila - das geht ganz ohne Vorteiler... fertig! Solls genauer sein, nimm einen 4MHz Quarz.

Auf diese Darstellung in der angehängten Skizze - ein Auszug aus dem Microchip-Datenblatt - bin ich rein gefallen, was meiner Art entspricht, zunächst alles wörtlich zu nehmen. Da gibt es die scheinbar direkte Verbindung vom Eingangsport PA5 zum internen Übergabepunkt für das Timer1-Signal. Auch jetzt nach Entdeckung des wahren Sachverhaltes ist mir nicht eingängig, warum das nicht direkt durch geht. U.a. geht es ja direkt durch, denn dieser Port kann ja sowohl für digitale wie auch analoge Signale als Eingangspin genutzt werden, ohne dass dieser vermaledeite Oszi in Betrieb gesetzt wird.
Die Synchronisations-Möglichkeit hat keinen Einfluss auf die Funktion meiner Schaltung, egal, ob on oder off, da ändert sich nichts Erkennbares.

Der Input über die Halbwelle ist schlicht erklärbar. Es sollte halt als einfache Taktquelle die 230-V-Netzfrequenz gewählt werden. Bei Vollgleichrichtung müsste dann durch 100 geteilt werden, um auf eine Sekunde zu kommen. Bei Halbwellen reicht ein 50-Teiler, der auch noch den Vorteil hat, dass die Null-Stelle weitaus ausgeprägter ist.

Nicht alles aus der Welt, aber eine nüchterne Betrachtung veranlasst mich, bei dem überwiegenden Teil meiner Schaltungen die niedrige interne Taktfrequenz von 31 kHz zu wählen. Ist an diesem Beispiel wunderbar zu erklären. Die Erzeugung eines Sekunden-Taktes gelingt über diese Halbwellen und einem "speed" mit 20 mS-Taktzyklus. Das ist selbst für den gemütlichen 31-er-PIC noch ein Schnarchmodus, weil...... weil selbst diese Schnarch-Frequenz im Programm noch durch 50 geteilt werden muss. Selbstredend könnte man den PIC auch mit 4 MHz rasen lassen und dann...? Dann müsste man einen irren Teilungsfaktor erstellen, um wieder auf das Ein-Herz-Signal zu kommen. Aus meiner Sicht: was soll der Quatsch?!
Ein passender Vergleich: um mit einem Kfz auf eine Geschwindigkeit von 20 km/h zu kommen, könnte man einen leistungsschwachen und mit nur 1.800 U/min ruhig dahin nagelnden Diesel greifen und den sogar noch im dritten Gang fahren. Genauso könnte man einen Ferrari mit 700 Newtonmeter bei 5.000 U/min betreiben, bei dem dann allerdings vorher noch ein Spezialgetriebe eingeflanscht werden müsste, um die irre Drehzahl runter zu bekommen für den Antrieb.
Bei meiner PIC-Testplatine dauert nach dem Starten auch nichts. Die erste Dunkelpause nach dem Einschalten dauert exakt genau so lang, wie die späteren Dunkelpausen beim Blinken im 1-Herz-Rhytmus. Zudem: wie oft wird eine Schaltung, welche sich im Jahres-Dauer-Einsatz befindet überhaupt eingeschaltet?! Ne, lass ma, für mich und meine PICs passt das.
Grüße, picass

Den FI schlicht still zu legen, wäre auch eine Möglichkeit. Is klar, wer z.B. als Elektriker in Ausübung seines Berufes unterwegs ist, für den wäre das Teufelszeug. Im privaten Bereich sehe ich das für meine eigenen Anwendungen anders. Da würde ich auf zuverlässige Funktion einer elektrisch-betriebenen Analge wert legen, natürlich auch darauf, dass keinerlei Hochspannung (230 V) führende Teile frei liegen, aber damit wärs aber auch erschöpft.  Das strikte Einhalten irgendwelcher Normen wäre mit wurscht, wenn ich der Überzeugung wäre, dass niemand - und sei es auch nur per Zufall oder Unwissenheit - einen "verpasst" bekommt. Letzteres ist in meinem Leben derart oft passiert, dass ich da eine gewissen "Fehler-Tolranz" entwickelt habe. Solange man darauf achtet, dass keine extremen Verhältnisse vorliegen wie: in der Badewanne föhnen oder im feuchten Keller mit Socken auf dem nassen Betonboden stehend an einer freiliegenden 230-Volt-Verbindung rum kaspern....., dann vertrete ich das für mich. Das klappt auch sehr gut. Da habe ich meiner Frau schon recht häufig gesagt, dass sie bitte darauf verzichten sollte, im Waschmaschinenraum zu versuchen, den Deckel von dem kleinen, hellblauen Gehäuse abzunehmen und schon gar nicht mit dem Finger dann innendrin rum zu stochern. Das hat sie auf Anhieb verstanden und entwickelt keinerlei Ehrgeiz in dieser Richtung. Also: man kann Anforderungen an vermeintliche "Sicherheit" auf die Spitze treiben. Man muss aber nicht. Verstand einschalten kann auch reichen.
Grüße, picass

picass,
PIC18
ich habe es verstanden. Wenn der unten stehende Code über den bestehenden in dem von mitgeteilten ASM-File kopiert wird, klappt das so wie von picass beabsichtigt.Was er beabsichtigt hat, habe ich erst nach dem Upload meiner Datei bemerkt.
Bei mir wird RA5 mit 130 kHz Sinus 2,2Vss direkt beaufschlagt, bei dem der Sinus gerade noch über die interne Triggerschwelle rutscht damit die LED blinkt. 
fosc in   . 130kHz -> LEDfosc ca. 0,9Hz

Bei wechselnder Frequenz, folgt die Blinkfrequenz dieser Änderung. und die LED bei wechselnder frequenz, entsprechend langsamer/schneller analog blinken läßt.

;---T1CON: TIMER1 CONTROL REGISTER                             DS.94
; external TMR1 oscillator is enabled when T1OSCEN = 1 
; and TMR1CS is set to 1 external clock enabled
; the signal goes straight from pin RA5 throug a schmitt-trigger
; to the clock input of TMR1.  
;;   movlw    b'00000000'
   movlw    b'00001010'
   ;          ....1..   b3/T1OSCEN 0/1 external Tmr1-clock disabled/enabled
   ;          ......1.  b1/TMR1CS 0/1 = Internal(external clock (FOSC/4)
   ;          .......0  b0/TMR1ON 0/1 disable/enable TMR1
   movwf    T1CON
   clrf     TMR1H       ;clear Hi-Byt  ;TMR1 is set o 0x0000
   clrf     TMR1L       ;clear Lo-Byte