Searching \ for 'PIC16C64 decoder problem' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=16C
Search entire site for: 'PIC16C64 decoder problem'.

Truncated match.
PICList Thread
'PIC16C64 decoder problem'
1998\02\24@050650 by Ken Parkyn

flavicon
picon face
Hello all;

I have programmed a PIC16C64 to act as a binary to one of 24
decoder.
The unit worked OK for a while, then started to output
erratically.
I programmed a new PIC, but it does the same.
It worked once upon a time...anyone see what I've done wrong?

code:

       title   "chair"
p=16c64

PCL equ 02
STATUS equ 03
FSR equ 04
PORTA equ 05
PORTB equ 06
PORTC equ 07
PORTD equ 08
PCL equ 02
PCLATH equ 0A
INTCON equ 0B
OPTIONREG equ 81
TRISA equ 05
TRISB equ 06
TRISC equ 07
TRISD equ 08
;**************************************
w equ 00
f equ 01
ADRESS equ 20

;**************************************

       bsf     STATUS,5      ;go to bank 1
       movlw   0xFF
       movwf   TRISA   ;set port a as inputs
       clrf    TRISB   ;set ports,b,c & d as outputs
       clrf    TRISC
       clrf    TRISD
       bcf     STATUS,5      ;back to bank 0

main    movf    PORTA,W ;read select address into w
       movwf   ADRESS  ;store this in ADRESS
       call    tableb  ;call lookup table for port B
       movwf   PORTB   ;put result out to port B
       movwf   ADRESS  ;restore data from ADRESS
       call    tablec  ;call lookup table for port C
       movwf   PORTC   ;put result out to port C
       movwf   ADRESS  ;restore data from ADRESS
       call    tabled  ;call lookup table for port D
       movwf   PORTD   ;put result out to port D
       goto    main    ;repeat

tableb  addwf   PCL,f
       retlw   01
       retlw   02
       retlw   04
       retlw   08
       retlw   10
       retlw   20
       retlw   40
       retlw   80
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
tablec  addwf   PCL,f
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   01
       retlw   02
       retlw   04
       retlw   08
       retlw   10
       retlw   20
       retlw   40
       retlw   80
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
tabled  addwf   PCL,f
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   00
       retlw   01
       retlw   02
       retlw   04
       retlw   08
       retlw   10
       retlw   20
       retlw   40
       retlw   80
       end

TIA.

________________________________________
Ken Parkyn              email: spam_OUTK.ParkynTakeThisOuTspamsct.gu.edu.au
Office of Technical Services,  Electronics Workshop
GRIFFITH UNIVERSITY Nathan Qld.4111 Australia
P.O.Box 185  Ph:(07)3875 7289    Fax:(07)38757151
________________________________________

1998\02\24@142952 by Mike Keitz

picon face
On Tue, 24 Feb 1998 16:08:56 -0800 Ken Parkyn <.....k.parkynKILLspamspam@spam@SCT.GU.EDU.AU>
writes:
>Hello all;
>
>I have programmed a PIC16C64 to act as a binary to one of 24
>decoder.
>The unit worked OK for a while, then started to output
>erratically.
>I programmed a new PIC, but it does the same.

The program looks like it will work OK.

Be sure to program the PIC with WDT off, or put a CLRWDT instruction in
the loop.

Another thing it is counting on is that the high bits of PORTA will read
zero.  I'm not sure this is always the case with a 64.  Or maybe your
power supply or clock is flakey.  I would change a few things about the
program to make it more reliable:

* Put the setting of TRIS registers inside the loop.  Sometimes a glitch
will corrupt the settings in the TRIS registers.
* Be sure PCLATH is set properly (for a program of this size, zero)
before accessing the tables.
* Test to be sure the value in ADRES is less than 24 before calling the
tables.  Otherwise the PIC will crash.


_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

1998\02\24@153206 by Andrew Warren

face
flavicon
face
Ken Parkyn <PICLISTspamKILLspamMITVMA.MIT.EDU> wrote:

> anyone see what I've done wrong?
> ....
>
> main    movf    PORTA,W ;read select address into w
>         movwf   ADRESS  ;store this in ADRESS
>         call    tableb  ;call lookup table for port B
>         movwf   PORTB   ;put result out to port B
>         movwf   ADRESS  ;restore data from ADRESS
>         call    tablec  ;call lookup table for port C
>         movwf   PORTC   ;put result out to port C
>         movwf   ADRESS  ;restore data from ADRESS
>         call    tabled  ;call lookup table for port D
>         movwf   PORTD   ;put result out to port D
>         goto    main    ;repeat

   Ken:

   The second and third "movwf ADRESS" lines should read "movf
   ADRESS,W".

   -Andy

=== Andrew Warren - .....fastfwdKILLspamspam.....ix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1998\02\24@184155 by Morgan Olsson

picon face
At 12:25 1998-02-24 -0500, Mike Keitz wrote:

-snip-

>* Put the setting of TRIS registers inside the loop.  Sometimes a glitch
>will corrupt the settings in the TRIS registers.

:-O
?? What ?? How ?  Glitch where?  When?

/Morgan
/  Morgan Olsson, MORGANS REGLERTEKNIK, SE-277 35 KIVIK, Sweden \
\  EraseMEmrtspam_OUTspamTakeThisOuTiname.com, ph: +46 (0)414 70741; fax +46 (0)414 70331    /

1998\02\25@004654 by rlunn

flavicon
face
Morgan Olsson wrote:

> At 12:25 1998-02-24 -0500, Mike Keitz wrote:
>
>>* Put the setting of TRIS registers inside the loop.  Sometimes
>>  a glitch will corrupt the settings in the TRIS registers.
>
> :-O
> ?? What ?? How ?  Glitch where?  When?

   Morgan, consider the proverbial stray cosmic ray, some RF
   noise coupling to MCLR, mains interference causing a tran-
   sient dip on the power rails, back EMF from a relay being
   switched...

   There are many ways in which the operation of an embedded
   microcontroller can be disrupted.  When it happens, it is
   often the I/O pin control registers that are effected.

   For these reasons, it is standard practice with embedded
   controllers to place as much of the initialization code as
   possible in the program's outermost loop.  Then, if someone
   starts the arc-welder (or that kiln controller switches on
   a 5kW heating coil ;) ) and a spike gets through to the pic
   (just enough to glitch TRISA but not kill the micro) then
   next time around the loop it should be put right.

___Bob

1998\02\25@014147 by Mike Keitz

picon face
On Tue, 24 Feb 1998 23:43:41 +0100 Morgan Olsson <mrtspamspam_OUTINAME.COM> writes:
>At 12:25 1998-02-24 -0500, Mike Keitz wrote:
>
>-snip-
>
>>* Put the setting of TRIS registers inside the loop.  Sometimes a
>glitch
>>will corrupt the settings in the TRIS registers.
>
>:-O
>?? What ?? How ?  Glitch where?  When?

The same sort of glitch that will upset the data in RAM, i.e. a rather
major one such as from static discharges, nearby lightning, turning the
power off then immediately back on, etc.  The TRIS registers are after
all just registers like SRAM.  It's good to write programs so that an
unexpected change of the contents of a chip register or RAM will
eventually "heal" after a period of temporary malfunction, rather than
requiring a complete reset.

_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

1998\02\25@064553 by Morgan Olsson

picon face
At 12:01 1998-02-25 +0000, Bob wrote:
>Morgan Olsson wrote:
>
>> At 12:25 1998-02-24 -0500, Mike Keitz wrote:
>>
>>>* Put the setting of TRIS registers inside the loop.  Sometimes
>>>  a glitch will corrupt the settings in the TRIS registers.
>>
>> :-O
>> ?? What ?? How ?  Glitch where?  When?
>
>    Morgan, consider the proverbial stray cosmic ray, some RF
>    noise coupling to MCLR, mains interference causing a tran-
>    sient dip on the power rails, back EMF from a relay being
>    switched...

Yes, but TRIS register is not more sensitive than other SFR:s or even RAM
Right?

>    There are many ways in which the operation of an embedded
>    microcontroller can be disrupted.  When it happens, it is
>    often the I/O pin control registers that are effected.

The port registers, but hardly the TRIS as they only control enable signals
to the output drivers.

>    For these reasons, it is standard practice with embedded
>    controllers to place as much of the initialization code as
>    possible in the program's outermost loop.  Then, if someone
>    starts the arc-welder (or that kiln controller switches on
>    a 5kW heating coil ;) ) and a spike gets through to the pic
>    (just enough to glitch TRISA but not kill the micro) then
>    next time around the loop it should be put right.

Right.
As many registers as possibly, including RAM should be often rewritten to
help against EMI, ESD cosmic, bad chip, etc  (or sometimes better if
possible monitored to warn when something is out of order) But if a
register is rewritten with value from RAM nothing is gained as RAM is as
sensitive as the (RAM mapped) registers.

BTW, anyone know a method for the PIC to check the validity of it«s own ROM?
 Some way to activate the ISP programming functions for read, then read
all ROM and calculate checksum.

One way would be to use a 12C508 just for checking the main PIC by
exersising standard ISP methods, or in systems with more than one micro
they can check each other.
Expensive, but maybe only way to do this?

I believe the high end PIC:s can use the 16-bit table read, but want a
method for 14-bit PIC:s

/Morgan


>___Bob
>
>
/  Morgan Olsson, MORGANS REGLERTEKNIK, SE-277 35 KIVIK, Sweden \
\  @spam@mrtKILLspamspaminame.com, ph: +46 (0)414 70741; fax +46 (0)414 70331    /

1998\02\25@082726 by rlunn

flavicon
face
Morgan Olsson wrote:

>>    Morgan, consider the proverbial stray cosmic ray, some RF
>>    noise coupling to MCLR, mains interference causing a tran-
>>    sient dip on the power rails, back EMF from a relay being
>>    switched...
>
> Yes, but TRIS register is not more sensitive than other SFR's or
> even RAM. Right?

   This depends upon the topology of the chip.  In general I
   would expect the TRIS registers to be noticeably more sensitive
   to glitches than other SFR's and RAM.

   The direction control latch would normally be part of the
   I/O 'macrocell' of each pin.  Note that there is no TRIS
   _register_ as such; there are a collection of latches dis-
   tributed around the perimeter of the chip which happen to
   be collectively addressable.

   These latches are adjacent to, and part of, the I/O pin
   circuit.  It is these circuits that carry the largest
   current flows in most systems, and which are the first
   port of call for any interference entering the chip.

>>    There are many ways in which the operation of an embedded
>>    microcontroller can be disrupted.  When it happens, it is
>>    often the I/O pin control registers that are effected.
>
> The port registers, but hardly the TRIS as they only control enable
> signals to the output drivers.

   As above, I think this distinction between the port latch
   and the direction control latch is misplaced.  Both latches
   are usually co-located on the chip and subject to very similar
   operating conditions.

___Bob

1998\02\27@182500 by JPMANDON

flavicon
face
Ken Parkyn wrote:
{Quote hidden}

The value stored in ADRESS at the beginning of the programm must be
restored in W with the mnemonic 'movf ADRESS,W' and you wrote 'movwf
adresse' wich make an overmemory branch when the result of the table is
80 for example .
Nice work

JEAN-PIERRE

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...