I never look at that. Just follow the recommended load capacitance. If on Timer 1, you can test the accuracy and trim if necessary.

 

... I use a crystal for 32.768 kHz for TMR1. That gives a nice 2-second pace.

I'm trying to recall the math behind the 32.768 kHz number ...
Considering 4 cycles per instruction, the device would be really working at 8.192 kHz ... Also, that number is equal to 2^13 ...
Timer1 has a 16-bit register, so why do you mention a 2-second pace in particular? Why not a 1-second pace?

 

No, no, no... Use the INTOSC for the system clock. The LP TMR1 Oscillator with 32.768-kHz crystal drives the 16-bit TMR1 counter.

If you want 1-second interrupt intervals with the 32768-Hz LP TMR1 OSC simply set bit 7 of TMR1H register each time you enter the TMR1 interrupt routine. This forces TMR1 to overflow every 32768 counts (1-second) instead of every 65536 counts (2-seconds).

There's a C code example using a 16F1828 at Project: PIC 4-Digit Single-Chip 24 Hour Clock which may be helpful (?)...

Cheerful regards, Mike

 

No, no, no... Use the INTOSC for the system clock. The LP TMR1 Oscillator with 32.768-kHz crystal drives the 16-bit TMR1 counter.

If you want 1-second interrupt intervals with the 32768-Hz LP TMR1 OSC simply set bit 7 of TMR1H register each time you enter the TMR1 interrupt routine. This forces TMR1 to overflow every 32768 counts (1-second) instead of every 65536 counts (2-seconds).

There's a C code example using a 16F1828 at Project: PIC 4-Digit Single-Chip 24 Hour Clock which may be helpful (?)...

Cheerful regards, Mike

Many thanks for your help. Question, wouldn't having two clock sources drain more power from the mcu?

I ask because my in application that is critical.

 

If you need to save power the LP TMR1 OSC and counter can run while the processor is in 'sleep' mode. In this case you can setup the TMR1 overflow or interrupt to wake up the processor once every second and put the processor back to sleep after processing the overflow or interrupt.

 

I just figured it out... Timer1 can be made to use an external 32.768 kHz crystal. And after it's activated, it can also be used as the system clock. This results not only in accurate timekeeping, but also in reduced power drain. This is because the internal oscillator can be switched off after that.

With the adequate prescaler setting, an interrupt at every two seconds minimum can be generated. And with the CCPR1H:CCPR1L registers working in compare mode a special interrupt event can be triggered at even shorter time lapses.

 

Two seconds is fine and is what I actually use. But setting bit 7 of TMR1H is simple (an RMW instruction with BSF) , and if done reasonably soon after an interrupt, there is no worry about missing a rollover from TMR1L. That will give you a 1 sec pulse as suggested by MMcLaren. I just forgot to mention it in my post. An advantage to 8-bit registers?

As for the rest, TMR1 is powerful. That's what I use for my smart roast thermometer to capture and average readings, etc.

 

Two seconds is fine and is what I actually use. But setting bit 7 of TMR1H is simple (an RMW instruction with BSF) , and if done reasonably soon after an interrupt, there is no worry about missing a rollover from TMR1L. That will give you a 1 sec pulse as suggested by MMcLaren. I just forgot to mention it in my post. An advantage to 8-bit registers?

As for the rest, TMR1 is powerful. That's what I use for my smart roast thermometer to capture and average readings, etc.

But aren't the TMR1 registers the timekeepers themselves? Wouldn't altering their value in any way also affect timekeeping?
I'm guessing that as long as changing the value of TMR1H immediately so that TMR1L does not overflow and start affecting its value, things should be ok. Right?

 

By setting bit 7 of TMR1H (an "ordinary" R/W register where the count is kept), you halve the number of counts between rollovers. It needs to be re-set after each rollover. The only difference between TMR1H/L and a pair of registers you might set up is that the rollover from TMR1L to TMR1H is automatic. Thus, it acts like a 16-bit register, but is really two, 8-bit registers working as one.

My comment about "advantage" was based on the fact that if it were a single register, and you did a BSF on bit<15>, you would have to check whether a count occurred between reading it (the first step in a RMW instruction) and then writing the modified register. Since your system clock is probably much faster than the TMR1 clock, that won't happen very often, but it may happen several times in a month. With two separate registers (TMR1H and TMR1L) you can diddle with TMRH and not worry about counts being missed in TMR1L so long as your are reasonably close to the previous rollover. At 32768 Hz, 256 counts is 7.8 ms. With a system clock at 32 MHz, that is almost an eternity.

Edit: TMR1H/L are not quite the same as a 16-bit register. They only act that way when counting for TMR1. I tried to use them once as a 16-bit register without TMR1, and that didn't work.

 

But I do plan to use TMR1 as the system clock, my friend... either way, now I'm sure that as long as bit 7 in TMR1H is set by the very first instruction of the interrupt routine then things should be ok. In fact, I could set bit 6 instead and generate an interrupt every 1/2 second, or bit 5 for 1/4s and so on... right?

 

Even if it is system clock during sleep, the same applies. An interrupt is about 4 or 5 TCY's (system clock/4), that leaves plenty of time to modify TMR1H. In my current project, I use the native 2-second pulse. I am just suggesting a way to use a 1-second pulse, if you need it. I have never cooked a roast when 1 second made a difference.

 

I have never cooked a roast when 1 second made a difference.

oh ... now I need to know about your roast project ... maybe you could post it at the Grill thread?

Anyway, my project needs accurate timekeeping because it needs to be able to register (rare) events in the lapse of up to 10 years. I just bought a ±5 ppm crystal for that purpose.

 

oh ... now I need to know about your roast project ... maybe you could post it at the Grill thread?

It will be. The PCB's came from Oshpark just as Spring broke. It will be my first reflow project with solder paste. It is on hold until until the ground hogs hibernate.

 

It will be. The PCB's came from Oshpark just as Spring broke. It will be my first reflow project with solder paste. It is on hold until until the ground hogs hibernate.

Are you going to make your own stencils? If so, may I offer my assistance?

 

Are you going to make your own stencils? If so, may I offer my assistance?

I got SS stencils from Oshstencil (https://www.oshstencils.com/# ). It is not officially related to Oshpark, but friendly with it and very fast production with free shipping in the US. Something like 2 days from order to receipt on a Saturday. By avoiding the cost of international shipping, the cost was less that of the Asian suppliers for SS.

I spent a week or so making my stencil printer. This should take you to a picture of the printer and stencil: https://forum.allaboutcircuits.com/...ts-with-eagle-before-8-0.168371/#post-1513781

My real mill is in storage. All parts were made using a HF mill-drill (a real PITA), except the tooling plate. The tooling plate was from eBay and is really a nice piece.

 

Question, in the PIC16LF1823 datasheet it is stated that:

I/O pins that are high-impedance inputs should be pulled to VDD or VSS externally to avoid switching currents caused by floating inputs.

That is understandable. But wouldn't it be the same to instead of externally pulling up an unused input to just activate its internal weak pull up?
Or wouldn't it be best to simply define any unused pin as an output and set it low while leaving it unconnected?

Which configuration for unused pins is best for minimizing power draw?

 

But wouldn't it be the same to instead of externally pulling up an unused input to just activate its internal weak pull up?

The data sheet isn't exactly clear on that; I should think the internal weak pullup would suffice, but I'm not 100% certain.

Or wouldn't it be best to simply define any unused pin as an output and set it low while leaving it unconnected?

That's what I've been doing.

Which configuration for unused pins is best for minimizing power draw?

Dunno.

 

In my experience, internal pull-up are sufficient, and yes, defining a pin as an output is also sufficient. One small point to remember is that internal pull-ups are not active on output pins; whereas, an external pull-up would be, i.e., it cannot be turned off.

That could be a factor if one is using TRIS to change the state of a pin. Some schools of thought, for example, will set TRIS =1 to turn off an LED. Bottom line for me is to use the internal pull-ups on floating inputs, unless for some reason you need a pull-down. The main reason is component count and simpler routing.

As for minimizing power, I suspect but am not sure external pull-downs are probably best on inputs; however, analog inputs all have leakage. Those currents are given in the electrical specifications (p.333) and are shown in Figures 16-4, 19-4. MCLR is particularly high and voltage dependent.

I have not seen any specification for leakage current of outputs So for low current, I would set to outputs.

 

From Microchip's "Compiled Tips ‘N Tricks Guide":

Unused Port Pins
If a port pin is unused, it may be left unconnected but configured as an output pin driving to either state (high or low), or it may be configured as an input with an external resistor (about 10 kΩ) pulling it to Vdd or Vss.
If configured as an input, only the pin input leakage current will be drawn through the pin (the same current would flow if the pin was connected directly to Vdd or Vss). Both options allow the pin to be used later for either input or output without significant hardware modifications.

Doesn't really answer my question. But further down in the same page, it's stated that:

Digital Outputs
There is no additional current consumed by a digital output pin other than the current going through the pin to power the external circuit. Pay close attention to the external circuits to minimize their current consumption.

So I guess that answers it. It's probably best to leave unused pins as outputs set low.

 

It's too bad that uCHIP has discontinued RealICE. It had a power monitor accessory that sniffed out those pesky leakages and graphed current vs. code execution as well as power consumption in sleep modes. I bought one for a battery powered gizmo development project and it was pretty danged cool. Maybe you can find them on the secondary market. Sometimes, I think that after the Atmel acquisition, they are moving away from 8 bit PIC.. MPASM is gone from X. Despite the wonderful peripherals in the 16F1xxx stuff, RealICE + -ME2 debuggers, which make a full-featured emulation environment, are now deprecated.