Ok, this is where I stand at this point, power-wise:

After quite a bit of tests and experimenting, I got these two results:

• 15.3 µA are drawn by my circuit when using the internal low power 31 kHz oscillator as the clock source
• 19.4 µA are drawn when using an external 32.768 kHz crystal as the MCU's clock source

I was expecting for lower, and not higher, power being drawn when using a crystal because the datasheet says that's the most efficient external oscillator mode. But I'm guessing that power is higher because the 31 kHz internal oscillator never stops, and with the external crystal there are two oscillators working simultaneously.

Since my program needs to check for an event only once every two seconds or so, what I did was use the crystal to asynchronously run Timer1 in counter mode and then put the device to sleep while that's happening. The device wakes up very briefly to check the status of said event, and then goes back to sleep until the next interrupt. That resulted in a power draw of only 11.2 µA average.
I consider that to be a significant improvement.

And btw, I have a new toy . I did those measurements using an australian µCurrent device bought directly from none other than EEVblog's Mr David Jones himself. It's a beautiful and quite useful little gadget.

​

 

I wonder how that compares with the uA setting on my UNI-T UT61E.

 

I'm about to start experimenting with reading/writing EEPROM and Flash Program Memory on the PIC16LF1823, and managing EEPROM seems pretty straightforward.

But reading the flash program memory it's a little more complicated than I expected. Which begs the question, Are there an equivalent DB and MOV A, @DPTR set of instructions in the PIC architecture as it is on the 8051?

My guess is that there is not, and that is exactly what the reading flash program memory feature is all about. Am I right?

Also, even though things are a bit more complicated to accomplish this task in a PIC, it is a truly remarkable advantage to be actually able to write to program memory is those devices. Which is a feature entirely absent in an 8051.

 

The answer is yes. The problem is that the program (code) memory is not the same width as the data memory so the actual interface might seem a bit "clunky". It should bear some resemblance to reading and writing EEPROM data memory in an 8051. Let me download the datasheet to confirm this.

On pages 101-111 of the datasheet ( http://ww1.microchip.com/downloads/en/DeviceDoc/40001413E.pdf ) it turns out you will be using the same file registers to read and write program memory as you would the EEPROM data memory. One of the configuration bits in a control register controls which meory space is used. Piece of cake.

 

The answer is yes. The problem is that the program (code) memory is not the same width as the data memory so the actual interface might seem a bit "clunky". It should bear some resemblance to reading and writing EEPROM data memory in an 8051. Let me download the datasheet to confirm this.

On pages 101-111 of the datasheet ( http://ww1.microchip.com/downloads/en/DeviceDoc/40001413E.pdf ) it turns out you will be using the same file registers to read and write program memory as you would the EEPROM data memory. One of the configuration bits in a control register controls which meory space is used. Piece of cake.

Right... piece of (a bit more laborious) cake...

Thanks for your help, @Papabravo. It's always thoroughly appreciated...

Back to coding, then...

 

But reading the flash program memory it's a little more complicated than I expected. Which begs the question, Are there an equivalent DB and MOV A, @DPTR set of instructions in the PIC architecture as it is on the 8051?

Are you looking for a way to define 14-bit data in program memory? If so, here's an excerpt from an XC8 program for 16F1823 of a font table used for driving an OLED display.

/************************************************************************
 *   Packed 96 character 5x7 Font, 2.5-words-per-character, 240 words   *
 ************************************************************************/
   #asm
   PSECT myFonts, class=CODE, abs, ovrld, space=0, delta=2
     ORG 700h
   Font5x7:
     dw 0x0000, 0x0000, 0x0000, 0x005F, 0x0000     ;  32 ' '  '!'
     dw 0x0007, 0x0007, 0x0014, 0x3F94, 0x3F94     ;  34 '"'  '#'
     dw 0x122A, 0x3FAA, 0x0923, 0x0988, 0x3262     ;  36 '$'  '%'
     dw 0x1B49, 0x2AA2, 0x2800, 0x0283, 0x0000     ;  38 '&'  '''
     dw 0x001C, 0x1141, 0x0000, 0x20A2, 0x0E00     ;  40 '('  ')'
     dw 0x0A08, 0x1F08, 0x0A08, 0x043E, 0x0408     ;  42 '*'  '+'
     dw 0x0050, 0x1800, 0x0008, 0x0408, 0x0408     ;  44 ','  '-'
     dw 0x0060, 0x3000, 0x0020, 0x0808, 0x0202     ;  46 '.'  '/'
     dw 0x1F51, 0x24C5, 0x1F00, 0x217F, 0x2000     ;  48 '0'  '1'
     dw 0x2161, 0x28C9, 0x2321, 0x20C5, 0x25B1     ;  50 '2'  '3'
     dw 0x0C14, 0x097F, 0x0827, 0x22C5, 0x22B9     ;  52 '4'  '5'
     dw 0x1E4A, 0x24C9, 0x1801, 0x3889, 0x0283     ;  54 '6'  '7'
     dw 0x1B49, 0x24C9, 0x1B06, 0x24C9, 0x149E     ;  56 '8'  '9'
     dw 0x0036, 0x1B00, 0x0000, 0x2B36, 0x0000     ;  58 ':'  ';'
     dw 0x0414, 0x1141, 0x0014, 0x0A14, 0x0A14     ;  60 '<'  '='
     dw 0x0041, 0x1114, 0x0402, 0x00D1, 0x0486     ;  62 '>'  '?'
     dw 0x1949, 0x3CC1, 0x1F7E, 0x0891, 0x08FE     ;  64 '@'  'A'
     dw 0x3FC9, 0x24C9, 0x1B3E, 0x20C1, 0x20A2     ;  66 'B'  'C'
     dw 0x3FC1, 0x20A2, 0x0E7F, 0x24C9, 0x24C1     ;  68 'D'  'E'
     dw 0x3F89, 0x0489, 0x00BE, 0x20C9, 0x24FA     ;  70 'F'  'G'
     dw 0x3F88, 0x0408, 0x3F80, 0x20FF, 0x2080     ;  72 'H'  'I'
     dw 0x1040, 0x20BF, 0x00FF, 0x0414, 0x1141     ;  74 'J'  'K'
     dw 0x3FC0, 0x2040, 0x207F, 0x010C, 0x017F     ;  76 'L'  'M'
     dw 0x3F84, 0x0410, 0x3FBE, 0x20C1, 0x20BE     ;  78 'N'  'O'
     dw 0x3F89, 0x0489, 0x033E, 0x20D1, 0x10DE     ;  80 'P'  'Q'
     dw 0x3F89, 0x0CA9, 0x2346, 0x24C9, 0x24B1     ;  82 'R'  'S'
     dw 0x0081, 0x3F81, 0x00BF, 0x2040, 0x203F     ;  84 'T'  'U'
     dw 0x0FA0, 0x2020, 0x0FBF, 0x2038, 0x203F     ;  86 'V'  'W'
     dw 0x3194, 0x0414, 0x3187, 0x0470, 0x0407     ;  88 'X'  'Y'
     dw 0x30D1, 0x24C5, 0x2180, 0x3FC1, 0x2080     ;  90 'Z'  '['
     dw 0x0104, 0x0410, 0x1000, 0x20C1, 0x3F80     ;  92 '\'  ']'
     dw 0x0202, 0x0082, 0x0240, 0x2040, 0x2040     ;  94 '^'  '_'
     dw 0x0001, 0x0104, 0x0020, 0x2A54, 0x2A78     ;  96 '`'  'a'
     dw 0x3FC8, 0x2244, 0x1C38, 0x2244, 0x2220     ;  98 'b'  'c'
     dw 0x1C44, 0x2248, 0x3FB8, 0x2A54, 0x2A18     ; 100 'd'  'e'
     dw 0x047E, 0x0481, 0x010C, 0x2952, 0x293E     ; 102 'f'  'g'
     dw 0x3F88, 0x0204, 0x3C00, 0x227D, 0x2000     ; 104 'h'  'i'
     dw 0x1040, 0x223D, 0x007F, 0x0828, 0x2200     ; 106 'j'  'k'
     dw 0x0041, 0x3FC0, 0x007C, 0x0218, 0x0278     ; 108 'l'  'm'
     dw 0x3E08, 0x0204, 0x3C38, 0x2244, 0x2238     ; 110 'n'  'o'
     dw 0x3E14, 0x0A14, 0x0408, 0x0A14, 0x0C7C     ; 112 'p'  'q'
     dw 0x3E08, 0x0204, 0x0448, 0x2A54, 0x2A20     ; 114 'r'  's'
     dw 0x023F, 0x2240, 0x103C, 0x2040, 0x107C     ; 116 't'  'u'
     dw 0x0E20, 0x2020, 0x0E3C, 0x2030, 0x203C     ; 118 'v'  'w'
     dw 0x2228, 0x0828, 0x220C, 0x2850, 0x283C     ; 120 'x'  'y'
     dw 0x2264, 0x2A4C, 0x2200, 0x0436, 0x2080     ; 122 'z'  '{'
     dw 0x0000, 0x3F80, 0x0000, 0x20B6, 0x0400     ; 124 '|'  '}'
     dw 0x0808, 0x0410, 0x0478, 0x2341, 0x2378     ; 126 '~'  ''
   #endasm
/************************************************************************/

 

Are you looking for a way to define 14-bit data in program memory? If so, here's an excerpt from an XC8 program for 16F1823 of a font table used for driving an OLED display.

/************************************************************************
*   Packed 96 character 5x7 Font, 2.5-words-per-character, 240 words   *
************************************************************************/
   #asm
   PSECT myFonts, class=CODE, abs, ovrld, space=0, delta=2
     ORG 700h
   Font5x7:
     dw 0x0000, 0x0000, 0x0000, 0x005F, 0x0000     ;  32 ' '  '!'
     dw 0x0007, 0x0007, 0x0014, 0x3F94, 0x3F94     ;  34 '"'  '#'
     dw 0x122A, 0x3FAA, 0x0923, 0x0988, 0x3262     ;  36 '$'  '%'
     dw 0x1B49, 0x2AA2, 0x2800, 0x0283, 0x0000     ;  38 '&'  '''
     dw 0x001C, 0x1141, 0x0000, 0x20A2, 0x0E00     ;  40 '('  ')'
     dw 0x0A08, 0x1F08, 0x0A08, 0x043E, 0x0408     ;  42 '*'  '+'
     dw 0x0050, 0x1800, 0x0008, 0x0408, 0x0408     ;  44 ','  '-'
     dw 0x0060, 0x3000, 0x0020, 0x0808, 0x0202     ;  46 '.'  '/'
     dw 0x1F51, 0x24C5, 0x1F00, 0x217F, 0x2000     ;  48 '0'  '1'
     dw 0x2161, 0x28C9, 0x2321, 0x20C5, 0x25B1     ;  50 '2'  '3'
     dw 0x0C14, 0x097F, 0x0827, 0x22C5, 0x22B9     ;  52 '4'  '5'
     dw 0x1E4A, 0x24C9, 0x1801, 0x3889, 0x0283     ;  54 '6'  '7'
     dw 0x1B49, 0x24C9, 0x1B06, 0x24C9, 0x149E     ;  56 '8'  '9'
     dw 0x0036, 0x1B00, 0x0000, 0x2B36, 0x0000     ;  58 ':'  ';'
     dw 0x0414, 0x1141, 0x0014, 0x0A14, 0x0A14     ;  60 '<'  '='
     dw 0x0041, 0x1114, 0x0402, 0x00D1, 0x0486     ;  62 '>'  '?'
     dw 0x1949, 0x3CC1, 0x1F7E, 0x0891, 0x08FE     ;  64 '@'  'A'
     dw 0x3FC9, 0x24C9, 0x1B3E, 0x20C1, 0x20A2     ;  66 'B'  'C'
     dw 0x3FC1, 0x20A2, 0x0E7F, 0x24C9, 0x24C1     ;  68 'D'  'E'
     dw 0x3F89, 0x0489, 0x00BE, 0x20C9, 0x24FA     ;  70 'F'  'G'
     dw 0x3F88, 0x0408, 0x3F80, 0x20FF, 0x2080     ;  72 'H'  'I'
     dw 0x1040, 0x20BF, 0x00FF, 0x0414, 0x1141     ;  74 'J'  'K'
     dw 0x3FC0, 0x2040, 0x207F, 0x010C, 0x017F     ;  76 'L'  'M'
     dw 0x3F84, 0x0410, 0x3FBE, 0x20C1, 0x20BE     ;  78 'N'  'O'
     dw 0x3F89, 0x0489, 0x033E, 0x20D1, 0x10DE     ;  80 'P'  'Q'
     dw 0x3F89, 0x0CA9, 0x2346, 0x24C9, 0x24B1     ;  82 'R'  'S'
     dw 0x0081, 0x3F81, 0x00BF, 0x2040, 0x203F     ;  84 'T'  'U'
     dw 0x0FA0, 0x2020, 0x0FBF, 0x2038, 0x203F     ;  86 'V'  'W'
     dw 0x3194, 0x0414, 0x3187, 0x0470, 0x0407     ;  88 'X'  'Y'
     dw 0x30D1, 0x24C5, 0x2180, 0x3FC1, 0x2080     ;  90 'Z'  '['
     dw 0x0104, 0x0410, 0x1000, 0x20C1, 0x3F80     ;  92 '\'  ']'
     dw 0x0202, 0x0082, 0x0240, 0x2040, 0x2040     ;  94 '^'  '_'
     dw 0x0001, 0x0104, 0x0020, 0x2A54, 0x2A78     ;  96 '`'  'a'
     dw 0x3FC8, 0x2244, 0x1C38, 0x2244, 0x2220     ;  98 'b'  'c'
     dw 0x1C44, 0x2248, 0x3FB8, 0x2A54, 0x2A18     ; 100 'd'  'e'
     dw 0x047E, 0x0481, 0x010C, 0x2952, 0x293E     ; 102 'f'  'g'
     dw 0x3F88, 0x0204, 0x3C00, 0x227D, 0x2000     ; 104 'h'  'i'
     dw 0x1040, 0x223D, 0x007F, 0x0828, 0x2200     ; 106 'j'  'k'
     dw 0x0041, 0x3FC0, 0x007C, 0x0218, 0x0278     ; 108 'l'  'm'
     dw 0x3E08, 0x0204, 0x3C38, 0x2244, 0x2238     ; 110 'n'  'o'
     dw 0x3E14, 0x0A14, 0x0408, 0x0A14, 0x0C7C     ; 112 'p'  'q'
     dw 0x3E08, 0x0204, 0x0448, 0x2A54, 0x2A20     ; 114 'r'  's'
     dw 0x023F, 0x2240, 0x103C, 0x2040, 0x107C     ; 116 't'  'u'
     dw 0x0E20, 0x2020, 0x0E3C, 0x2030, 0x203C     ; 118 'v'  'w'
     dw 0x2228, 0x0828, 0x220C, 0x2850, 0x283C     ; 120 'x'  'y'
     dw 0x2264, 0x2A4C, 0x2200, 0x0436, 0x2080     ; 122 'z'  '{'
     dw 0x0000, 0x3F80, 0x0000, 0x20B6, 0x0400     ; 124 '|'  '}'
     dw 0x0808, 0x0410, 0x0478, 0x2341, 0x2378     ; 126 '~'  ''
   #endasm
/************************************************************************/

Thanks for sharing that example. It'll make things much easier for me to implement later on.

 

Are you looking for a way to define 14-bit data in program memory? If so, here's an excerpt from an XC8 program for 16F1823 of a font table used for driving an OLED display.

/************************************************************************
*   Packed 96 character 5x7 Font, 2.5-words-per-character, 240 words   *
************************************************************************/
   #asm
   PSECT myFonts, class=CODE, abs, ovrld, space=0, delta=2
     ORG 700h
   Font5x7:
     dw 0x0000, 0x0000, 0x0000, 0x005F, 0x0000     ;  32 ' '  '!'
     dw 0x0007, 0x0007, 0x0014, 0x3F94, 0x3F94     ;  34 '"'  '#'
     dw 0x122A, 0x3FAA, 0x0923, 0x0988, 0x3262     ;  36 '$'  '%'
     dw 0x1B49, 0x2AA2, 0x2800, 0x0283, 0x0000     ;  38 '&'  '''
     dw 0x001C, 0x1141, 0x0000, 0x20A2, 0x0E00     ;  40 '('  ')'
     dw 0x0A08, 0x1F08, 0x0A08, 0x043E, 0x0408     ;  42 '*'  '+'
     dw 0x0050, 0x1800, 0x0008, 0x0408, 0x0408     ;  44 ','  '-'
     dw 0x0060, 0x3000, 0x0020, 0x0808, 0x0202     ;  46 '.'  '/'
     dw 0x1F51, 0x24C5, 0x1F00, 0x217F, 0x2000     ;  48 '0'  '1'
     dw 0x2161, 0x28C9, 0x2321, 0x20C5, 0x25B1     ;  50 '2'  '3'
     dw 0x0C14, 0x097F, 0x0827, 0x22C5, 0x22B9     ;  52 '4'  '5'
     dw 0x1E4A, 0x24C9, 0x1801, 0x3889, 0x0283     ;  54 '6'  '7'
     dw 0x1B49, 0x24C9, 0x1B06, 0x24C9, 0x149E     ;  56 '8'  '9'
     dw 0x0036, 0x1B00, 0x0000, 0x2B36, 0x0000     ;  58 ':'  ';'
     dw 0x0414, 0x1141, 0x0014, 0x0A14, 0x0A14     ;  60 '<'  '='
     dw 0x0041, 0x1114, 0x0402, 0x00D1, 0x0486     ;  62 '>'  '?'
     dw 0x1949, 0x3CC1, 0x1F7E, 0x0891, 0x08FE     ;  64 '@'  'A'
     dw 0x3FC9, 0x24C9, 0x1B3E, 0x20C1, 0x20A2     ;  66 'B'  'C'
     dw 0x3FC1, 0x20A2, 0x0E7F, 0x24C9, 0x24C1     ;  68 'D'  'E'
     dw 0x3F89, 0x0489, 0x00BE, 0x20C9, 0x24FA     ;  70 'F'  'G'
     dw 0x3F88, 0x0408, 0x3F80, 0x20FF, 0x2080     ;  72 'H'  'I'
     dw 0x1040, 0x20BF, 0x00FF, 0x0414, 0x1141     ;  74 'J'  'K'
     dw 0x3FC0, 0x2040, 0x207F, 0x010C, 0x017F     ;  76 'L'  'M'
     dw 0x3F84, 0x0410, 0x3FBE, 0x20C1, 0x20BE     ;  78 'N'  'O'
     dw 0x3F89, 0x0489, 0x033E, 0x20D1, 0x10DE     ;  80 'P'  'Q'
     dw 0x3F89, 0x0CA9, 0x2346, 0x24C9, 0x24B1     ;  82 'R'  'S'
     dw 0x0081, 0x3F81, 0x00BF, 0x2040, 0x203F     ;  84 'T'  'U'
     dw 0x0FA0, 0x2020, 0x0FBF, 0x2038, 0x203F     ;  86 'V'  'W'
     dw 0x3194, 0x0414, 0x3187, 0x0470, 0x0407     ;  88 'X'  'Y'
     dw 0x30D1, 0x24C5, 0x2180, 0x3FC1, 0x2080     ;  90 'Z'  '['
     dw 0x0104, 0x0410, 0x1000, 0x20C1, 0x3F80     ;  92 '\'  ']'
     dw 0x0202, 0x0082, 0x0240, 0x2040, 0x2040     ;  94 '^'  '_'
     dw 0x0001, 0x0104, 0x0020, 0x2A54, 0x2A78     ;  96 '`'  'a'
     dw 0x3FC8, 0x2244, 0x1C38, 0x2244, 0x2220     ;  98 'b'  'c'
     dw 0x1C44, 0x2248, 0x3FB8, 0x2A54, 0x2A18     ; 100 'd'  'e'
     dw 0x047E, 0x0481, 0x010C, 0x2952, 0x293E     ; 102 'f'  'g'
     dw 0x3F88, 0x0204, 0x3C00, 0x227D, 0x2000     ; 104 'h'  'i'
     dw 0x1040, 0x223D, 0x007F, 0x0828, 0x2200     ; 106 'j'  'k'
     dw 0x0041, 0x3FC0, 0x007C, 0x0218, 0x0278     ; 108 'l'  'm'
     dw 0x3E08, 0x0204, 0x3C38, 0x2244, 0x2238     ; 110 'n'  'o'
     dw 0x3E14, 0x0A14, 0x0408, 0x0A14, 0x0C7C     ; 112 'p'  'q'
     dw 0x3E08, 0x0204, 0x0448, 0x2A54, 0x2A20     ; 114 'r'  's'
     dw 0x023F, 0x2240, 0x103C, 0x2040, 0x107C     ; 116 't'  'u'
     dw 0x0E20, 0x2020, 0x0E3C, 0x2030, 0x203C     ; 118 'v'  'w'
     dw 0x2228, 0x0828, 0x220C, 0x2850, 0x283C     ; 120 'x'  'y'
     dw 0x2264, 0x2A4C, 0x2200, 0x0436, 0x2080     ; 122 'z'  '{'
     dw 0x0000, 0x3F80, 0x0000, 0x20B6, 0x0400     ; 124 '|'  '}'
     dw 0x0808, 0x0410, 0x0478, 0x2341, 0x2378     ; 126 '~'  ''
   #endasm
/************************************************************************/

I'm gonna need a little help here. I've already studied the retlw k instruction and I think I understand it. However, I would like to know what specific routine one has to use in order to read a table such as the one you've presented.

 

What I'm currently considering is using the FSR registers to access the Program Flash Memory and then do an indirect read. But I'm not sure if that would work.

 

Ok, I think I understand. It's quite explicit in the datasheet:


My question now is, how do I set the values of PROG_ADDR_LO and PROG_ADDR_HI?, and how does one properly define the data to be read within the code?

 

My question now is, how do I set the values of PROG_ADDR_LO and PROG_ADDR_HI?, and how does one properly define the data to be read within the code?

You beat me to it. It took awhile to find some code Mike helped me with years ago. Yes, that is how I did it. As for those addresses. use:

     movlw     low(TABLE_LABEL)
    <add offset e.g., addwf>
     etc.
     movlw     high(TABLE_LABEL)
     <add offset e.g., addwfc>
     etc.

EDIT: I had to make a run to the hardware store. I wanted to add that I think it will work using FSRxH/L the same way, but I haven't tried it.. That avoids switching banks for the eeprom registers. Just be sure not to increment the offset. You also need to have bit 7 of FSRxH set so it goes to program memory. Usually, at this instruction, "movlw high(FSRxH)", the assembler will automatically do that. You do need to clear it in code later, if you don't want it set. John

 

Using 2.5 memory words to store a character's graphic appearance is a bit crazy, but it does save on ROM usage. If it's a 5x7 character, then that's 35 bits to store, and the processor's word size is 14 bits, so two and a half words gives you the 35 bits. I see that the '!" character is stored as 0x005F, so it seems that the data is encoded in columns, with the lowest order bit representing the highest pixel. Could be a little awkward if the display device wants the data in rows and not columns.

 

Sorry, I missed the message. How much space does your character set for a GLCD take? Isn't there almost always a trade off between code/memory space and speed?

 

There seems to be two options for storing data strings in program memory. The first one is da (define ascii) and the second one is data. data uses a 16-bit word to store each character, while da packs the string into 14-bit words.





da is more code efficient, but data is easier to use and translate.

I think I'll try to use da for my purposes. The device's memory is quite limited and I had better work using an efficiency approach from the very start.

 

Here's an interesting anecdote that some of you might find rather curious but also useful.

I've been working on a project for the last few months in which current draw is extremely important because the device I'm designing works on battery power. So every time I change my code to make it grow towards the main goal, I always make sure that the new routines not only work but that power draw remains in check and does not increase. The normal procedure being connecting the PICit 3 device to the PCB, burn the program, disconnect the PICit 3, and then measure the current being drawn.

Well, I after adding a couple of routines to the code (which were not yet being called anywhere from within the program), suddenly my device jumped from drawing 14.5µA to 100µA !!!!... (WTH?). So I reverted and reprogrammed the device with the most recent version of stable code, and it still was drawing about 100µA !!! ... and then I went back and reprogramed the device with a very old version that I just knew drew less than 15µA and it was still drawing 100µA after switching it on... very frustrating to say the least... I reset all the connections by disconnecting the PICit 3 and the battery pack and then reconnecting the battery pack after a few seconds and still the current draw remained at 100µA ... Had I somehow damaged the chip while handling it? Was there some sort of impurity bridging the PCB's traces and making it draw almost 7 times more power than was originally measured?

Anyway, after almost 1/2 hour of searching and inspecting I discovered that the PICit 3 device had the option of powering up the device with 3.25V enabled. This while the PCB was also being powered by 3V sourced from a battery pack.

So I switched off said PICit 3 power option, burned the original program again while the circuit was being powered by the battery pack, and then disconnected the PICit 3 programmer .... and VOILÁ! ... current draw went back to being 14.5µA only!

Very, very strange. Somehow programming the device while it was being simultaneously powered by the battery pack and the PICit 3 activates some sort of internal fuse or circuitry in the PIC16LF1823 and makes it draw far more power than it would normally consume.

... rather quirky behavior from the chip, I should say... but fortunately the source of the problem was quickly found and diligently solved.

 

Interesting observation.

Unless I'm just checking a subroutine ( I have three large "sandbox" projects for doing that), I almost always clear the box to power the target by the programmer (PK3 or ICD3 in my case).

I simply do not trust the programmers for power when doing anything but simple logic tests. If a display is involved, it's not even a question.

 

Here's a question that should be easy to answer with those acquainted with the chip I'm working with. In the following code:

       btfss OSCSTAT, HFIOFS ;stay here until the high frequency internal oscillator 
        goto $-2             ;is ready and accurate within 0.5%

How come the wait-loop instruction is goto $-2 and not goto $-1 ?

 

Here's a thought about my previous question. From the datasheet:




And since the btfss instruction takes two cycles, two program words need to be subtracted for the goto instruction to correctly point to the location of the btfss instruction?

 

Here's a question that should be easy to answer with those acquainted with the chip I'm working with. In the following code:

       btfss OSCSTAT, HFIOFS ;stay here until the high frequency internal oscillator
        goto $-2             ;is ready and accurate within 0.5%

How come the wait-loop instruction is goto $-2 and not goto $-1 ?

The addresses in program memory are byte addresses despite the fact that the actual width might be 12 bits or 14 bits. This is done for the convenience of programming the code memory in the PIC's Harvard Architecture.

 

Here's a thought about my previous question. From the datasheet:

View attachment 221719
View attachment 221720

And since the btfss instruction takes two cycles, two program words need to be subtracted for the goto instruction to correctly point to the location of the btfss instruction?

No. Cycles and the number of bits required for an instruction are different. The instruction word size is 14 bits, but the chunks are addressed as bytes.