Jumping through hoops is how we got good at doing what we do.

 

I'm pulling my hair here ... I've set the RA3 pin as an input (the only way it can be set, by the way) and enabled its internal weak pull up. My intention is to use it as an ordinary input only pin. But when I pull the thing down, the device resets itself! ... Said pin is also the /MCLR pin, btw ... but that's not supposed to be relevant during normal operation.

 

Have you declared it an Input Pin?
MCLR = OFF

 

I'm pulling my hair here ... I've set the RA3 pin as an input (the only way it can be set, by the way) and enabled its internal weak pull up. My intention is to use it as an ordinary input only pin. But when I pull the thing down, the device resets itself! ... Said pin is also the /MCLR pin, btw ... but that's not supposed to be relevant during normal operation.

Multifunction pins usually have multiple control bits and unfortunately you have to track them all down individually. For the Bible they have a thing called a concordance, which has the following definition:

An alphabetical list of the words (especially the important ones) present in a text, usually with citations of the passages in which they are found.​

It would be cool if datasheets had such a thing with respect to multifunction pins so you could have all the information in front of you in a single place. It can be fun to dream.

 

Have you declared it an Input Pin?
MCLR = OFF

Well duh! ... I just made it work ... what happened is that one is supposed to set both the MCLRE and LVP bits off in the configuration words in order to set said pin as a normal I/O ... but I didn't know that because until now I've never used that pin for anything out of convenience ...

Is that what you were referring to?

 

Well duh! ... I just made it work ... what happened is that one is supposed to set both the MCLRE and LVP bits off in the configuration words in order to set said pin as a normal I/O ... but I didn't know that because until now I've never used that pin for anything out of convenience ...

Is that what you were referring to?

Yes

 

Yes

Which begs the question ... what's the point of leaving said pin as /MCLR when using this chip in a normal project? ... as a hard reset input?

 

Which begs the question ... what's the point of leaving said pin as /MCLR when using this chip in a normal project? ... as a hard reset input?

Yes. A default is a default unless otherwise noted.

 

In some case you may want to use a supervisor IC e.g. DS1233 that resets in case of brown-outs etc, and effects a rapid MCLR at power off in stead of power dieing slowly at power off which can cause issues.
Or you may need to do a manual reset at some point..

 

In addition, when used as the default MCLR, no external components are required so you don't really have to worry about the pin if it remains unused.

 

In addition, when used as the default MCLR, no external components are required so you don't really have to worry about the pin if it remains unused.

If set to MCLR even when the pin is unused, you should tie it high with a 10k.

 

If set to MCLR even when the pin is unused, you should tie it high with a 10k.

Just to be safe -- of course.

 

Well if you set MCLR ON and do not tie it high it can float around and do all kinds of weird stuff!

 

Well if you set MCLR ON and do not tie it high it can float around and do all kinds of weird stuff!

Not if you enable its internal pull up... it would behave just fine.

 

And here's my current peeve.

I'm trying to use a couple of inputs in the PIC16LF1825 so that they can keep track of an encoder such as this one:

​

The chip is currently working at 3.3V and running at 32 MHz. The inputs I've connected the two encoder channels to have their internal pull ups enabled. But every time I turn (however slowly) the encoder, the MCU reads many rising edge events (instead of just one) and the internal counter behaves erratically.

Thing is, I've gone through my algorithm many times already and I can't find anything wrong with it.

So now I'm beginning to think that maybe what's happening is switch bounce (especially since the chip's running at such high frequency) and maybe I should be using a filter of sorts to mitigate said effect.

Also, I've discovered that the chip's inputs can be configured either as TTL's or Schmidt Trigger types. And I don't know which one is best for my application.

​

 

I agree. It’s probably due to switch bounce. I’ve had success sampling these on an interrupt driven timer to filter the bounce in firmware. You can also use an encoder with optical outputs that switch smoothly..In that case a Schmitt input would work fine and easily support interrupt on change for reading and decoding. Grayhill is one manufacturer.
https://www.grayhill.com/optical-and-hall-effect

Have fun!

 

Not if you enable its internal pull up... it would behave just fine.

I am just going by Microchip recommendations.
I have about 8 different Microchip origin development boards of different stripes, and all a suggest a 10k pull up with a 0.1μf to GND.

 

I am just going by Microchip recommendations.

Now that, I didn't know ... I'll keep it in mind. Thanks for sharing.

 

I've just solved a huge PITA that was giving me quite a headache and almost made me lose the last three strands of hair that I have left on my head... so I thought I might as well register it here for posterity's sake.

Ever since my code grew larger than 2K and had to use paging techniques, I've been using the following macro.

;Select appropriate program memory page before and after calling a rouinte
Fcall macro Routine
         pagesel Routine            ;select Routine's program memory page before calling
         call Routine               ;execute the routine
         pagesel $                  ;restore the current program memory page
       endm

Well, this macro had been working fine until my code started to mysteriously and unpredictably crash. To make a long story short, I remembered that the crashes began to happen when I added a couple of subroutine calls from within the interrupt routine. And after some digging around, here's what I found in a forum:

Also, if your program's interrupt service routine uses any 'call' or 'goto' instructions, the PCLATH register must be saved on entry to the ISR. It must then be cleared before executing a 'call' or 'goto' to a location within the ISR. Finally, before exiting the ISR, the saved value of PCLATH must be restored to the register.

So that's exactly what I did. I backed up the contents of PCLATH immediately at the start of the interrupt routine, then I cleared the file and proceeded with the rest of the code. And then I restored the original content of PCLATH immediately before executing the retfie instruction.

Voila... problem solved. I hope this at least spares a future poor devil the painful birthing labor that learning to code this architecture has proven to be.

Now I'm off to buy a wig ...

 

I've just solved a huge PITA that was giving me quite a headache and almost made me lose the last three strands of hair that I have left on my head... so I thought I might as well register it here for posterity's sake.

Ever since my code grew larger than 2K and had to use paging techniques, I've been using the following macro.

;Select appropriate program memory page before and after calling a rouinte
Fcall macro Routine
         pagesel Routine            ;select Routine's program memory page before calling
         call Routine               ;execute the routine
         pagesel $                  ;restore the current program memory page
       endm

Well, this macro had been working fine until my code started to mysteriously and unpredictably crash. To make a long story short, I remembered that the crashes began to happen when I added a couple of subroutine calls from within the interrupt routine. And after some digging around, here's what I found in a forum:

Also, if your program's interrupt service routine uses any 'call' or 'goto' instructions, the PCLATH register must be saved on entry to the ISR. It must then be cleared before executing a 'call' or 'goto' to a location within the ISR. Finally, before exiting the ISR, the saved value of PCLATH must be restored to the register.

So that's exactly what I did. I backed up the contents of PCLATH immediately at the start of the interrupt routine, then I cleared the file and proceeded with the rest of the code. And then I restored the original content of PCLATH immediately before executing the retfie instruction.

Voila... problem solved. I hope this at least spares a future poor devil the painful birthing labor that learning to code this architecture has proven to be.

Now I'm off to buy a wig ...

The pleasures of doing your own context switching. This is why most modern PIC's have shadow registers to help in that task. I'd be careful thinking manual saves and restores are the root cause solution.

https://ww1.microchip.com/downloads...PIC12LF1822-16LF1823-Data-Sheet-40001413F.pdf

8.5 Automatic Context Saving Upon entering an interrupt, the return PC address is saved on the stack. Additionally, the following registers are automatically saved in the shadow registers:
• W register
• STATUS register (except for TO and PD)
• BSR register
• FSR registers
• PCLATH register
Upon exiting the Interrupt Service Routine, these registers are automatically restored. Any modifications to these registers during the ISR will be lost. If modifications to any of these registers are desired, the corresponding shadow register should be modified and the value will be restored when exiting the ISR. The shadow registers are available in Bank 31 and are readable and writable. Depending on the user’s application, other registers may also need to be saved.

https://www.microchip.com/forums/m1199003.aspx