LED blinking on PIC10F222, external MCLR

[Eur van Andel]

Hi

The LED is blinking. I did need some help from Wouter, you have to specifiy these chips to xwisp.py

Another thing:

-- Set all ports into digital mode (if any analog module present).

--

procedure enable_digital_io() is

  pragma inline

  adc_off()

end procedure

--

Rob, can you add:

OPTION_REG_T0CS = off

in here? Then all pins are truly digital I/O. See pictures. FOSC4 is default 0, so we don't need to mess with that. 

Also, I'd like to add:

-- This program assumes the internal oscillator

-- is used with a frequency of 4 MHz.

pragma target clock 4_000_000      -- oscillator frequency

pragma target WDT  disabled

pragma MCLR external

I had no problems programming with an internal MCLR, but that differs from programmer to programmer. I think it is wise to set this on for the newbies. See this post:

http://tech.groups.yahoo.com/group/jallist/message/25666

I had some nasty troubles with this as well. Wouter built the Wisp628 dongle for me to fix it. 

---

ir EE van Andel e...@fiwihex.nl  http://www.fiwihex.nl

Fiwihex B.V. Wierdensestraat 74, NL7604BK Almelo, Netherlands

tel+31-546-491106 fax+31-546-491107

[Rob Hamerling]

Eur van Andel wrote:

>> -- Set all ports into digital mode (if any analog module present).
>> --
>> procedure enable_digital_io() is

>> Â Â pragma inline
>> Â Â adc_off()

>> end procedure
>> --
>
> Rob, can you add:
>
> OPTION_REG_T0CS = off
>
> in here? Then all pins are truly digital I/O. See pictures. FOSC4 is default 0,
> so we don't need to mess with that.

- Is this needed for all PICS, or only for a specific group? T0CS seems
not to have exactly the same function in all PICs.
- T0CS is in the OPTION_REG for the midrange and baseline (as pseudo
register), but in the T0CON register for the 18Fs.
So it is not really straight forward.

> Also, I'd like to add:
>
>> -- This program assumes the internal oscillator
>> -- is used with a frequency of 4 MHz.

>> pragma target clock 4_000_000 Â Â Â -- oscillator frequency
>> pragma target WDT Â disabled
>
> pragma MCLR external

Similarly as above: for which PICs? Not all even have a 'pragma fuse_def
MCLR' option. And this is not about device files but the blink-an-led
samples.

Regards, Rob.

--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)

[Eur van Andel]

On 1 Sep 2008, at 09:43 , Rob Hamerling wrote:

Eur van Andel wrote:

-- Set all ports into digital mode (if any analog module present).

--

procedure enable_digital_io() is

  pragma inline

  adc_off()

end procedure

--

Rob, can you add:

OPTION_REG_T0CS = off

in here? Then all pins are truly digital I/O. See pictures. FOSC4 is default 0, 

so we don't need to mess with that.

- Is this needed for all PICS, or only for a specific group? T0CS seems 

not to have exactly the same function in all PICs.

Only for 10F's, but it should go into the device files, and into the enable_dig_io() procedure.

Also, I'd like to add:

-- This program assumes the internal oscillator

-- is used with a frequency of 4 MHz.

pragma target clock 4_000_000      -- oscillator frequency

pragma target WDT Â disabled

pragma MCLR external

Similarly as above: for which PICs? Not all even have a 'pragma fuse_def 

MCLR' option. And this is not about device files but the blink-an-led 

samples.

All that have, should declare MCLR external. Programming an internal MCLR PIC depends on a very specific power-up sequence which can baffle newbies. This should be in the BLINK files only, for now. 

Regards, Rob.

-- 

Rob Hamerling, Vianen, NL (http://www.robh.nl/)

[Eur van Andel]

On 1 Sep 2008, at 09:43 , Rob Hamerling wrote:

Also, I'd like to add:

-- This program assumes the internal oscillator

-- is used with a frequency of 4 MHz.

pragma target clock 4_000_000      -- oscillator frequency

pragma target WDT Â disabled

Another thing: if we use 4 MHZ as clock, we should set IOSCS as well!

-- This program assumes the internal oscillator

-- is used with a frequency of 4 MHz.

pragma target clock 4_000_000      -- oscillator frequency

pragma target WDT       disabled

pragma target IOFSCS    _4_MHz

--

Since 8 MHz is the default value. This is only for PIC10F22X:

G5-fiwihex:~/jalv2/jallib/unvalidated/include/device eur$ grep IOFSCS *.jal

10f220.jal:pragma fuse_def IOFSCS 0x1 {

10f222.jal:pragma fuse_def IOFSCS 0x1 {

I noticed the LED blinking twice as fast.

There is also the matter of the OSSCAL trim value, programmed at the last memory location, but this is too complicated for a blink-a-LED program. 

[Rob Hamerling]

Eur van Andel wrote:

>>> OPTION_REG_T0CS = off

> Only for 10F's, but it should go into the device files, and into the
> enable_dig_io() procedure.

OK! I'll do that
But in the meantime I've done some datasheet scanning and think it is
also useful for the 12F508,509 and 16F505 (maybe even more). Please check.

>>> pragma MCLR external

> All that have, should declare MCLR external. Programming an internal
> MCLR PIC depends on a very specific power-up sequence which can
> baffle newbies. This should be in the BLINK files only, for now.

I assume you are referring to the Vpp-before-Vdd sequence when MCLR is
configured 'internal'. That applies to only a minority of chips, I
think. But OK, I'll put it in the blink programs, it won't harm.
However I think in the 18Fs the MCLR EXTERNAL has a different meaning.
So it should not appear in the blink programs for the 18Fs.

[Rob Hamerling]

Eur van Andel wrote:

> Another thing: if we use 4 MHZ as clock, we should set IOSCS as well!
>
>> -- This program assumes the internal oscillator
>> -- is used with a frequency of 4 MHz.
>> pragma target clock 4_000_000 -- oscillator frequency
>> pragma target WDT disabled
>> pragma target IOFSCS _4_MHz
>> --
>
> Since 8 MHz is the default value. This is only for PIC10F22X:
>
>> G5-fiwihex:~/jalv2/jallib/unvalidated/include/device eur$ grep
>> IOFSCS *.jal
>> 10f220.jal:pragma fuse_def IOFSCS 0x1 {
>> 10f222.jal:pragma fuse_def IOFSCS 0x1 {
>
>
> I noticed the LED blinking twice as fast.

You openened another can or Microchip worms.....
In the 10F220/222 _datasheet_ this bit is called IOSCFS, but in the .dev
files it is called IOFSCS. The latter will be a typo, because the bit is
called Interternal OSCillator Frequency Select bit.
When you grep for IOSCFS you'll find a couple of other PICS with this
bit, and with the same meaning.
I think I'll 'repair' the .dev file for the 10F220/222 and add the bit
to the blink program for all chips with the IOSCFS bit.
I need also to 'harmonize' the IOSCFS parameter values to F4MHZ and
F8MHZ (these must start with a non-numeric char).

> There is also the matter of the OSSCAL trim value, programmed at the
> last memory location, but this is too complicated for a blink-a-LED
> program.

OSCCAL, another PITA...
PICs with OSCCAL in the last word of program memory have that address as
reset vector. The instruction there is movlw and the next program
instruction is at address 0x0000. The program is supposed to store W in
OSCCAL as first instruction (at address 0). Well, that seems a task for
the compiler! I don't see how an application programmer could handle
this with the current JalV2 compiler.

[Eur van Andel]

On 2 Sep 2008, at 10:03 , Rob Hamerling wrote:

Eur van Andel wrote:

OPTION_REG_T0CS = off

Only for 10F's, but it should go into the device files, and into the  

enable_dig_io() procedure.

OK! I'll do that

But in the meantime I've done some datasheet scanning and think it is 

also useful for the 12F508,509 and 16F505 (maybe even more). Please check.

Confirmed. Also for PIC12F510, PIC16F506, PIC16F526. 

Not for the 12F609, 12F615, 12F629, 12F635, 12F636, 12F639 or 12F675. 

Also not for the PIC16F5X. 

pragma MCLR external

All that have, should declare MCLR external. Programming an internal  

MCLR PIC depends on a very specific power-up sequence which can  

baffle newbies. This should be in the BLINK files only, for now.

I assume you are referring to the Vpp-before-Vdd sequence when MCLR is 

configured 'internal'. 

I do. 

That applies to only a minority of chips, I 

think.

72 have internal MCLR, of the 10F, 12F and 16F:

G5-fiwihex:~/jalv2/jallib/unvalidated/include/device eur$ grep MCLR *.jal | grep -v 18f | grep -v 18lf | wc

      72     360    2935

But not all require the Vpp-before-Vdd. 

http://www.electro-tech-online.com/micro-controllers/17354-pic-programmer-winpicprog-my-findings.html#post103132

I don't fully understand this table, but it seems these PICs have the problem:

[edited]

ID6TBL  dt   0x00,0x00, "508 ", 0x0000 ;12F508

        dt 0x0F,0x80, "629 ", 0x0000 ;12F629 (*) 8.5-13.5 VPP

        dt 0x0F,0xA0, "635 ", 0x0000 ;12F635    10.0-13.0 VPP

        dt 0x0F,0xC0, "675 ", 0x0000 ;12F675 (*) 8.5-13.5 VPP

        dt 0x04,0x60, "683 ", 0x0000 ;12F683    10.0-13.0 VPP

;

        dt 0x10,0x40, "627A", 0x0000 ;16F627A   10.0-13.5 VPP

        dt 0x10,0x60, "628A", 0x0000 ;16F628A   10.0-13.5 VPP

        dt 0x10,0xC0, "630 ", 0x0000 ;16F630     8.5-13.5 VPP

        dt 0x10,0xA0, "636 ", 0x0000 ;16F636    10.0-13.0 VPP

;       dt 0x10,0xA0, "639 ", 0x0000 ;16F639    10.0-13.0 VPP

        dt 0x11,0x00, "648A", 0x0000 ;16F648A   10.0-13.5 VPP

        dt 0x10,0xE0, "676 ", 0x0000 ;16F676     8.5-13.5 VPP

        dt 0x10,0x80, "684 ", 0x0000 ;16F684    10.0-13.0 VPP

;       dt 0x04,0xA0, "685 ", 0x0000 ;16F685    10.0-13.0 VPP

;       dt 0x13,0x20, "687 ", 0x0000 ;16F687    10.0-13.0 VPP

        dt 0x11,0x80, "688 ", 0x0000 ;16F688    10.0-13.0 VPP

;       dt 0x13,0x40, "689 ", 0x0000 ;16F689    10.0-13.0 VPP

;       dt 0x14,0x00, "690 ", 0x0000 ;16F690    10.0-13.0 VPP

;       dt 0x12,0x00, "785 ", 0x0000 ;16F785    10.0-12.0 VDD/VPP

;       dt 0x13,0xE0, "913 ", 0x0000 ;16F913    10.0-12.0 VDD/VPP

;       dt 0x13,0xC0, "914 ", 0x0000 ;16F914    10.0-12.0 VDD/VPP

;       dt 0x13,0xA0, "916 ", 0x0000 ;16F916    10.0-12.0 VDD/VPP

;       dt 0x13,0x80, "917 ", 0x0000 ;16F917    10.0-12.0 VDD/VPP

But OK, I'll put it in the blink programs, it won't harm.

OK.

However I think in the 18Fs the MCLR EXTERNAL has a different meaning. 

So it should not appear in the blink programs for the 18Fs.

Well, I hope it works. 

[Eur van Andel]

On 2 Sep 2008, at 10:53 , Rob Hamerling wrote:

Eur van Andel wrote:

Another thing: if we use 4 MHZ as clock, we should set IOSCS as well!

pragma target IOFSCS    _4_MHz

You openened another can or Microchip worms.....

In the 10F220/222 _datasheet_ this bit is called IOSCFS, but in the .dev 

files it is called IOFSCS. The latter will be a typo, because the bit is 

called Interternal OSCillator Frequency Select bit.

I didn't even notice :-(

When you grep for IOSCFS you'll find a couple of other PICS with this 

bit, and with the same meaning.

I think I'll 'repair' the .dev file for the 10F220/222 and add the bit 

to the blink program for all chips with the IOSCFS bit.

Please do.

I need also to 'harmonize' the IOSCFS parameter values to F4MHZ and 

F8MHZ (these must start with a non-numeric char).

Better than the leading zero. 

There is also the matter of the OSSCAL trim value, programmed at the  

last memory location, but this is too complicated for a blink-a-LED  

program.

OSCCAL, another PITA...

PICs with OSCCAL in the last word of program memory have that address as 

reset vector. The instruction there is movlw and the next program 

instruction is at address 0x0000. The program is supposed to store W in 

OSCCAL as first instruction (at address 0).  Well, that seems a task for 

the compiler!  I don't see how an application programmer could handle 

this with the current JalV2 compiler.

The first instruction in these PICs needs to be:

asm MOVWF OSSCAL @ 0x0000

And yes, this is a compiler issue. 

[Eur van Andel]

On 2 Sep 2008, at 12:02 , Eur van Andel wrote:

The program is supposed to store W in 

OSCCAL as first instruction (at address 0).  Well, that seems a task for 

the compiler!  I don't see how an application programmer could handle 

this with the current JalV2 compiler.

Well, I tried something. It worked. 

The first instruction in these PICs needs to be:

asm MOVWF OSSCAL @ 0x0000

So I just added:

-- ------------------------------------------------

var volatile byte  OSCCAL               at { 0x5 }

var volatile bit*7 OSCCAL_CAL           at OSCCAL : 1

var volatile bit   OSCCAL_FOSC4         at OSCCAL : 0

-- ------------------------------------------------

var volatile byte  GPIO                 at { 0x6 }

var volatile byte  PORTA                at GPIO

asm movwf OSCCAL

--

var          byte  _PORTA_shadow        = PORTA

--

procedure _PORTA_flush() is

  pragma inline

  PORTA = _PORTA_shadow

end procedure

--

To the device file. 

G5-fiwihex:~/jalv2/jallib/unvalidated/sample/blink eur$ /usr/local/bin/gpdasm  -p 10f222 b10f222.hex 

000000:  0025  movwf    0x5

000001:  0206  movf     0x6, w

000002:  002b  movwf    0xb

000003:  0cff  movlw    0xff

000004:  002c  movwf    0xc

000005:  0067  clrf     0x7

It's not pretty, but hey, it works. It might need some comment :-)

Let's do this, independent of the programmer supports it, because it's the Right Thing to Do. 

So, now I'm getting back to do some Real Work. 

[Rob Hamerling]

This solution maybe too simple and not worth the pain:

The datasheets says setting of the OSCCAL is optional. So it should not
give too much trouble to implement it.

Only a limited set of PICs have this construction with the calibration
value in high memory, AFAIK: 10Fs, a few 12F5xx, 12F6xx, 16F5xx and
16F6xx (but not all).

The movfw OSCCAL instruction must be the very first, at location 0x0000,
which may not always be possible. I'm not sure about these, but I'm
thinking of:
- when using a bootloader
- when using the compiler option -clear
- when using interrupt routines

So I suggest to let it go for the moment, there are more urgent things.

[Rob Hamerling]

Hi Eur,

Eur van Andel wrote:
>>>>> OPTION_REG_T0CS = off
>>> Only for 10F's, but it should go into the device files, and into the
>>> enable_dig_io() procedure.

[RobH

>> But in the meantime I've done some datasheet scanning and think it is
>> also useful for the 12F508,509 and 16F505 (maybe even more). Please
>> check.

[Eur]

> Confirmed. Also for PIC12F510, PIC16F506, PIC16F526.
>
> Not for the 12F609, 12F615, 12F629, 12F635, 12F636, 12F639 or 12F675.
> Also not for the PIC16F5X.
>

I have updated the device files according to this discussion. But I'm
not convinced it is all OK. What confuses me:
The reason for resetting T0CS is to make sure the pin is available for
digital output. When the T0CS bit is set (which is the default) Timer0
is in counter mode and one of the pins is the input for the counter. But
we have the reset of T0CS limited to chips for which this bit overrides
the TRIS bit for this pin. Is for the other chips that pin still output
and has the corresponding TRIS bit to be reset as well to make it really
input? In other words is for the Timer0 to work in counter-mode both
setting T0CS bit and reset of the corresponding TRIS bit required? The
datasheets (e.g. for the 12F675) don't mention this TRIS requirement.

Please explain why the chips in the list above do _not_ need T0CS to be
reset.

[Eur van Andel]

On 3 Sep 2008, at 09:43 , Rob Hamerling wrote:

But in the meantime I've done some datasheet scanning and think it is

also useful for the 12F508,509 and 16F505 (maybe even more). Please  

check.

[Eur]

Confirmed. Also for PIC12F510, PIC16F506, PIC16F526.

Not for the 12F609, 12F615, 12F629, 12F635, 12F636, 12F639 or 12F675.

Also not for the PIC16F5X.

[Rob]

 Is for the other chips that pin still output 

and has the corresponding TRIS bit to be reset as well to make it really 

input?

Yes, I think. 

In other words is for the Timer0 to work in counter-mode both 

setting T0CS bit and reset of the corresponding TRIS bit required? The 

datasheets (e.g. for the 12F675) don't mention this TRIS requirement.

Yes. 

Please explain why the chips in the list above do _not_ need T0CS to be 

reset.

Because the output doesn't interfere with TRIS. See pic below. In theory, you could increase TMR0 by wiggling GP2 as output. I'd have to test that to make sure. 

---

ir EE van Andel e...@fiwihex.nl  http://www.fiwihex.nl

Fiwihex B.V. Wierdensestraat 74, NL7604BK Almelo, Netherlands

tel+31-546-491106 fax+31-546-491107