Zitat von: picass in 28.07.2025, 12:39:29 CESTDas INICON-Register !

Um das INTCON- Register kommt man halt nicht drumherum!
Und das 7. Bit im INTCON ist das GIE-Bit. GIE = Global Interrupt Enable, dieses Bit schaltet also alle Interrupts ein oder aus, egal welche Interrupts (TMR0IE, TMR1IE,...) aktiviert sind.
Das ist wichtig, um bspw. in der Interruptroutine das "dazwischenfunken" eines weiteren INT's bei mehreren möglichen Interruptquellen zu verhindern. Man setzt also am Anfang der INT-Routine
  bcf    INTCON,GIE
und am Ende
  bsf    INTCON,GIE   
  RETFIE

Außerdem müsste doch wohl in Deinem Prog. statt
blink:                   ;
     bsf    PIE1,TMR1IF  ;enable timer1 interrupt

stehen:

blink:
     bsf    PIE1,TMR1IE  ;enable timer1 interrupt

Gruß
PICkel
(der hoffentlich die paar ASM- Zeilen richtig geschrieben hat    )

Zitat von: pic18 in 27.07.2025, 20:05:34 CESTIch meine der Timer zählt rückwärts.

Über das "Zurück-beim PIC" schreibe ich an anderer Stelle.
Nix, der Timer/Counter zählt nach oben:"The TMR1 register pair (TMR1H:TMR1L) increments
from 0000h to FFFFh and rolls over to 0000h." So das Datenblatt.

Das INICON-Register ! Das beschäftigt mich auch, schon alleine, weil man bei Interrupts bislang an dem nicht vorbei kam. Aber......, da gibt es gleich mehrere "Aber": aber für den Time/Counter1 gibt es ein eigenes Register, über welchen der IRQ ein- u. ausgeschaltet wird. Und das Reg wird in jedem Fall benötigt. Käme nun das INTCON auch noch dazu, würde doppelt gemoppelt und welche Ein-oder-Ausschaltung würde denn dann greifen? Weiter: in dem Beispiel-Code für Timer1 im Datenblatt steht nix von INTCON, nur das Sonder-Reg..

Muss da mal 'ne gehörige Runde experimentieren, gleich heute Nachmittag gehts los.
Ach ja, wie schon beschrieben: das Taktsignal ist ausgesprochen sauber zwischen 0,6 Volt und 4,9 Volt. Der Port A Eingang hat eine Schmitt-Trigger-Funktion.
Grüße, picass

Ich habe im Archiv ein Beispiel gefunden, dies ist ein Zeitprogramm welches mit dem Systemtakt ich meine 40Mhz arbeitet. Ich hatte dies im meiner Anfangszeit programmiert, heute würde ich es etwas anders machen. Nicht den Timer direkt setzen, sondern die Zyklen abziehen. Dadurch gibt es keine Ungenauigkeiten. interr_b_txt.txt

Du bist wieder beim Pic zurück! 
Welches Signal hast Du denn? Ist es ein sauberes Rechtecksignal? Ansonsten würde ich es zuerst über einen Schmitt-Tricker aufbereiten. (z.B. 7414)

Ich würde folgender Maßen vorgehen.
Zuerst nach dem Start würde ich alle Parameter initialisieren. Ich habe jetzt im Überflug nicht gesehen, wo der Port als Eingang für den Timer initialisiert ist.

INTCON Byte setzen:
GIE/GIEH PEIE/GIEL TMR0IE INT0IE RABIE TMR0IF INT0IF RABIF
GIE muss gesetzt werden
PEIE
IPR1,TMR1IP (HI Prio)
PIE1,TMR1IE (1)
PIR1,TMR1IF (0)

T1CON Byte setzen, 
TMR1CS: Timer1 Clock Source Select bit
TMR1ON
T1CKPS<1:0>: Timer1 Input Clock Prescale Select bits
T1RUN: Timer1 System Clock Status bit

Nach der Initialisierung würde ich im Hauptprogramm (Main) eine Endlosschleife machen.
zb. 
main nop
bra main

im Interrupt:
hier würde ich zuerst einmal abfragen, ob der Interrupt vom Timer ausgelöst wurde. 
wenn ja, dann das TMR1IF löschen.
nicht das TMR1IE, das wird noch benötigt. 
nun kannst Du im Interrupt den Zählstand abfragen. Ich meine der Timer zählt rückwärts. Und bei erreichen den Zählerstand neu setzen, bzw den Zähler-Offset einfach Timerwert hinzuaddieren bzw abziehen
Den Interrupt beendest Du mit.
RETFIE (Return from Interrupt), kein Sprung nach Main oder sonst wohin!!

Hallo picass,

ich nutze ASM zwar nur, wenn es absolut nötig ist, aber ich sehe kein setzen des GIE- Bit!?

Gruß
PICkel

Kaum eingestellt und auf dem Weg zum Kaffee-Zubereiten. aber zu spät für eine sofortige Korrektur  fiel mir auf, wo im obigen Prog ein "NUR" zu finden ist: falsche Zuordnung beim Rücksprung nach einem Durchlauf der Dauerschleife. Da wurde etwas zu weit zurück gesprungen und dadurch das 16-bit-Counter-Register immer wieder neu befüllt. Das ist nun geändert. Aber der IRQ klemmt nach wie vor. Auch im Simulator wird der Überlauf zwar angezeigt, aber nix weiter passiert, also kein Einsprung in die IRQ-Routine. Hier das überarbeitete Prog:
Grüße, picass
stundenzaehler03.txt

Mal wieder meine Haß-Liebe mit und zu Interrupts: ein PIC18F14K22 soll in seiner Counter-Funktion genutzt werden, wozu ich zwecks der 16-bit den Timer1 ausgewählt hatte. Das Prog ist erfrischend kurz: der PIC bewegt sich gemütlich (31 kHz) in einer Nichts-Tun-Schleife und soll durch den Ablauf des Timers1 in die Irq-Routine springen, in welcher er eigentlich auch nur - zunächst aus Testgründen - eine LED toggeln soll. Das im Kreis-Laufen funktioniert, aber der Irq klemmt wieder, der PIC kommt nicht in seine Service-Routine. Der PIC zählt an seinem Port A5 einen externen Takt. Der wird abgeleitet aus der Netzfrequenz. Über einen Optokoppler wird je nur die positive Halbwelle genutzt, was zu sehr sauberem Rombus an a5 führt. Der Counter1 wird mit seinem Maximalwert minus 50 befüllt, will sagen, der müsste noch genau 50 positive Schwinger abzählen - was einer Sekunde entsprechen sollte  - und dann überlaufen. Und Interrupten. Aber da hat der andere Vorstellungen.

Der Umgang mit Timern ist mir nur rudimentär geläufig, bei einem Timer0 ohne Irq klappte das mal. Wenn ich das Datenblatt richtig verstehe, wird das sonst unvermeidbare INTCON-Register gar nicht benötigt. Das Prog ist von allem Unnötigen befreit und meiner Meinung nach gut lesbar. Das ASM-File ist hier als Text-File angefügt. Ach ja, das Prog läuft mit dem "mittleren" Assembler, also MPLAB X 5.20 (geht bis 5.35). Vielleicht schaut ja jemand mal rein. Is klar, da fehlt - wie so üblich - ein "nur........". Seufz, wenn nur das "nur" nicht wäre!
Grüße, picass
stundenzaehler03.txt

Rein theoretisch betrachtet scheint das Entfeuchten über das Kriterium des Vergleichs der Taupunkttemperaturen ja ein echt gutes zu sein. Aber es müssen irgendwo gleich mehrere Hasen im Pfeffer liegen, so wie es aktuell läuft, kann das nicht richtig sein. Da wäre z.B. die Anzeige der Luftfeuchtigkeit im Keller, die mit 96 % angegeben wurde. Wäre dem so, dann müsste das Wasser aus den Wänden quillen oder sich diese mindestens total feucht anfühlen. Is aber nicht. Die verwendeten Sensoren sollen angeblich "faktor-calibriert" sein. Vielleicht wird das missverstanden in dem Sinne, dass man (ich) davon ausgeht, dass die in der Fertigung schon geeicht sind. Also wäre ein möglicher Ansatzpunkt, erst mal für eine taugliche Eichung zu sorgen. Ein eher einfaches solches Verfahren hatte ich auch ausgeführt mit den jetzt verbauten Sensoren, aber nun vertraue ich dem nicht mehr.

Dein Ansatz, auf das komplizierte Berechnen der Formel zu verzichten und stattdessen benötigte Werte aus einer Tabelle zu holen, ist sicher ein interessanter. So hatte ich das ja schon bei meiner Öltemp-Messung und auch derjenigen für die Anzeige der Diesel-Partikelfilter-Regeneration ausgeführt. Das würde sicherlich hier nun auch klappen. Mich hatte vor einem Jahr, als ich die fertige µC-Steuerung kaufte, das ewig lange Rumdoktern mit Versuchen, die Formel-Berechnung irgendwie doch noch zu schaffen, vom Versuch über diese Formel-Nutzung abgehalten. Zudem war ich zu dieser Zeit noch nicht in der Lage, ein LCD-Display selbst anzusteuern.

Vielleicht wäre es ein Kompromiss, über einen PIC ein sehr schlichtes Prog aufzusetzen, welches bei niedrigen Außentemperaturen - wie z.B. nachts - und dem Überprüfen des Status "Regen oder nicht" eine Lüftung in Intervallen ausführt, wenn die vermeintliche super-dupa-Taupunktschaltung sich dieser Lüftung verweigert.
Es nähert sich der Jahresurlaub in Italien. Danach "habe ich Hüfte", will sagen, es läuft auf ein neues Hüftgelenk raus, was einen längeren Reha-Aufenthalt bedeuten würde. Der Erste dieser Art war als sehr erfolgreich anzusehen, räusper....., bezogen auf Programmier-Erfolge. Aber ich werde auch jetzt schon vorsichtig beginnen. Mal sehen....... zunächst schaue ich mich nach Möglichkeit fürs Eichen um.
Grüße und danke für Hinweise, picass

Korrektur:
falsch: "wobei Temperatur und Luftdruck nebenbei anfallen und für das vorstehende Verfahren nicht erforderlich ist."
richtig: "wobei der Luftdruck nebenbei anfällt und für das vorstehende Verfahren nicht erforderlich ist."
Ottmar

Eine Idee:
Wenn der Taupunkt so entscheidend ist, dann bietet sich doch dieses Verfahren an:

1. Außentemperatur messen
2. in Taupunkttabelle (*) nachsehen welcher Taupunkt.
3. Innentemperatur messen
4. in Taupunkttabelle nachsehen welcher Taupunkt
5. Taupunkt Differenz berechnen  innen -außen
6. Entscheidung:
⦁ wenn Differenz positiv (Hysterese einbauen)
⦁ Gebläse EIN - Außenluft rein, Innenluft raus
⦁ Differenz zu gering oder negativ:
⦁ Gebläse AUS

(*) z.B.
Taupunkttabelle
Diese Aufgabe erledigen z.B. ein Arduino NANO und zwei BME280 (Luftfeuchte, Temperatur und Luftdruck), wobei Temperatur und Luftdruck nebenbei anfallen und für das vorstehende Verfahren nicht erforderlich ist.

P.S.
Ich hatte mal mit Arduino, DHT11/22 und BME für eine Wetterstation exerimentiert und der DHT war recht groß und erschien mir ungenauer zu sein als der BME280.
Mit einem PIC ist der Aufwand beim Programmieren natürlich deutlich erhöht, dabei kann man aber an der Aufgabe wachsen.
Wenn gewollt könnten die Daten in einem EEPROM gespeichert werden, dies ergäbe mit den Einschaltzeiten eine fast perfekte Dokumentation.

mfG Ottmar