Using one of the demo programs on pullups, I found this line:
Set Not_WPUEN = 0 'Enable pullups in general.
On at least two devices I use (18F15Q40 and 16F18345) calling this raises an error during compilation of:
Error: Variable NOT_WPUEN was not explicitly declared
In this case I have been commenting out this line and all seems to be well.
Does this line need to be included at all? Do I need to call something else on those devices where 'Not_WPUEN' is not declared?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looking up the register bits for the 18F15Q40, there is no NOT_WPUEN bit (no surprise there).
Searching for WPU... gives me:
WPUA0,WPUA,0
WPUA1,WPUA,1
WPUA2,WPUA,2
WPUA3,WPUA,3
WPUA4,WPUA,4
WPUA5,WPUA,5
WPUB4,WPUB,4
WPUB5,WPUB,5
WPUB6,WPUB,6
WPUB7,WPUB,7
WPUC0,WPUC,0
WPUC1,WPUC,1
WPUC2,WPUC,2
WPUC3,WPUC,3
WPUC4,WPUC,4
WPUC5,WPUC,5
WPUC6,WPUC,6
WPUC7,WPUC,7
I can't find an equivalent for enabling the pull ups in general, and so am guessing it isn't needed. It works without it too.
I'm confused as to why one device requires general enabling, while others appear to rely on direct addressing, with no pre-enabling required.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
#IfnDefUse18F15Q40SetNot_WPUEN=0'Enable pullups in general.#EndIfSetWPUA0=0SetWPUA1=0SetWPUA2=0SetWPUA3=1SetWPUA4=1SetWPUA5=1SetWPUB4=0SetWPUB5=1SetWPUB6=0SetWPUB7=1SetWPUC0=0SetWPUC1=0SetWPUC2=0SetWPUC3=1SetWPUC4=1SetWPUC5=1SetWPUC6=1SetWPUC7=1
To answer your question, WPUA0, if set to '1' activates the weak pullup on PortA.0, set to '0' and the pull up is disabled on PortA.0.
The example for pullups showed that I needed to set the 'NOT_WPUEN' bit to enable the pullups in general, in the 16F1829 that worked, compiled, pullups worked, I was happy as Larry. For the same code but compiled for the 18F16Q40 the code wouldn't compile as the 'NOT_WPUEN' bit didn't (and doesn't still) exist. As the pullups worked without that line of code, I simply shrugged and moved on. Due to the chip shortage continuing, I'm evaluating using the 16F18345. That too has no 'NOT_WPUEN' bit and I wondered what the ramifications might be of ignoring the setting of it again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The demo/example is likely very old (and is only an example.) It does not consider that MCHIP eliminated the OPTION_REG in newer 16Fchips and best I can tell in ALL 18FChips. You must take this into consideration.
For more portable code (PIC) I might suggest the following
Thanks for that suggestion. It seems to work for the 16F1829, 16F18345 and 18F15Q40.
Really elegant. Far better than my use of the declared constants I have been using.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had not been aware of the capabilities of testing for existence (or otherwise) of system variables or bits using #IFDEF before, that will be really useful.
Last edit: mkstevo 2022-08-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good you have that sorted. The following are supported in the compiler
1) Where RegName is the name of a register as defined in the [Registers] section of the relevant chip.dat file.
2) Where BitName is the name of a bit as defined in the [Bits] section of the relevant chip.dat file.
Using one of the demo programs on pullups, I found this line:
Set Not_WPUEN = 0 'Enable pullups in general.
On at least two devices I use (18F15Q40 and 16F18345) calling this raises an error during compilation of:
Error: Variable NOT_WPUEN was not explicitly declared
In this case I have been commenting out this line and all seems to be well.
Does this line need to be included at all? Do I need to call something else on those devices where 'Not_WPUEN' is not declared?
That is a register.bit and the name of the bit is specifc to the chip. For a specific chip look in PICINFO or the datasheet.
Thanks.
I'm still confused.
Looking up the register bits for the 18F15Q40, there is no NOT_WPUEN bit (no surprise there).
Searching for WPU... gives me:
WPUA0,WPUA,0
WPUA1,WPUA,1
WPUA2,WPUA,2
WPUA3,WPUA,3
WPUA4,WPUA,4
WPUA5,WPUA,5
WPUB4,WPUB,4
WPUB5,WPUB,5
WPUB6,WPUB,6
WPUB7,WPUB,7
WPUC0,WPUC,0
WPUC1,WPUC,1
WPUC2,WPUC,2
WPUC3,WPUC,3
WPUC4,WPUC,4
WPUC5,WPUC,5
WPUC6,WPUC,6
WPUC7,WPUC,7
I can't find an equivalent for enabling the pull ups in general, and so am guessing it isn't needed. It works without it too.
I'm confused as to why one device requires general enabling, while others appear to rely on direct addressing, with no pre-enabling required.
There are over 1000 PICs.. they are inconsistent across the range.
For this specific chip what does WPUA0 do? in the context that the other chip was a NOT bit.
Here's the code relevant to my question:
To answer your question, WPUA0, if set to '1' activates the weak pullup on PortA.0, set to '0' and the pull up is disabled on PortA.0.
The example for pullups showed that I needed to set the 'NOT_WPUEN' bit to enable the pullups in general, in the 16F1829 that worked, compiled, pullups worked, I was happy as Larry. For the same code but compiled for the 18F16Q40 the code wouldn't compile as the 'NOT_WPUEN' bit didn't (and doesn't still) exist. As the pullups worked without that line of code, I simply shrugged and moved on. Due to the chip shortage continuing, I'm evaluating using the 16F18345. That too has no 'NOT_WPUEN' bit and I wondered what the ramifications might be of ignoring the setting of it again.
The demo/example is likely very old (and is only an example.) It does not consider that MCHIP eliminated the OPTION_REG in newer 16Fchips and best I can tell in ALL 18FChips. You must take this into consideration.
For more portable code (PIC) I might suggest the following
Last edit: William Roth 2022-08-09
Thanks for that suggestion. It seems to work for the 16F1829, 16F18345 and 18F15Q40.
Really elegant. Far better than my use of the declared constants I have been using.
To finish this off.
I have adjusted the code so that it now checks for the existence of the "Not_WPUEN" bit before attempting to set it.
I had not been aware of the capabilities of testing for existence (or otherwise) of system variables or bits using #IFDEF before, that will be really useful.
Last edit: mkstevo 2022-08-09
Good you have that sorted. The following are supported in the compiler
1) Where RegName is the name of a register as defined in the [Registers] section of the relevant chip.dat file.
2) Where BitName is the name of a bit as defined in the [Bits] section of the relevant chip.dat file.
And oddly enough ...
Last edit: William Roth 2022-08-09
Thanks again. I've emailed myself a copy of that, both at work and at home. Next time I'm trying something similar, hopefully I'll remember.