Searching \ for 'RE(2): Microchip PIC Application Notes AN512 and A' 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=pic
Search entire site for: 'Microchip PIC Application Notes AN512 and A'.

Truncated match.
PICList Thread
'RE(2): Microchip PIC Application Notes AN512 and A'
1999\02\15@205846 by Myke Predko

flavicon
face
Hi Kelly,

You're asking some pretty good questions here and, again, I'm copying the
PICList in case other people are wondering about this.

> First thing that I did was to kind of "clutter" everything as far as
>re-writing the software, so that I could understand it better.  For
>instance, the variable known as "ACCA" at address location 0x08 became
>"ACCAHB" (HB for hi byte), and I gave address 0x09 the label of ACCALB (for
>low byte).

Just a word on this, I typically put my sixteen bit variables in what I call
"Intel" format which is low byte at low address and high byte at high
address.  What you have done here is put the data in what I call "Motorola"
format (High Byte/Low Byte).

When you use the Motorola format, you can read the information back directly
from the simulator/emulator without having to do a mental "flip" in your
mind.

I've been working so long with Intel parts that this format has really
become unfamiliar to me (so I stick with the "Intel" format).

>Additionally, I did some things that Mr. Cox from Microchip did
>not do, such as declare the TMR0 as TMR0 instead of as F, declare PORTA and
>PORTB and STATUS as specific named variables (he was just using addresses
>direct).  All this I did so that I could better understand the program.

TMR0 should not be possible to declare as "F".  "F" is normally reserved as
the Destination bit of file register instructions being the file register
itself.  In older 16C5x (low-end) code, the Timer was known as "RTCC", but
Microchip changed its designation to "TMR0" to fit in with the mid-range
parts.

Both you and the apnote's author should be using the "16C5X.INC" file that
is provided with MPASM/MPLAB.  This is much easier to include into your
source than creating your own file and uses all the standard Microchip
register names and conventions.

{Quote hidden}

This is normal.  When the low-end parts start up, they do so at the last
address in memory.  At last year's Microchip seminars; Microchip engineers
stated that in the low-end parts they recommended ignoring the last address
all together and just let the PC roll over to address 0 and start the
application from there.  This will make the 16C5x parts appear to be more
like the mid-range parts.

An unprogrammed EPROM location (all 1s) in the low-end PICMicros is "xorlw
0x0FF, which will change the contents of "w", but this doesn't matter
because "w" is indeterminate at this stage of the PICMicro's execution.

So, while the three lines above are valid, you really only need:

ORG 0

 :                        ;  Application start

>However, isn't 1FF an
>address for a different page of memory?  I thought that the 16C54 only had
>one page of memory.

For the low-end devices, a page of memory is 512 decimal (0x0200) bytes.
0x01FF is at the last address of the first page.

>Also, I don't see him using any BCF STATUS, RP0 or BSF
>STATUS, RP0 to change between a page of memory.  Additionally, I thought
>that ORG 0x000 is by default where a program is  supposed to start.

RP0 is only available in the mid-range (16F84) parts.  In the low-end you
can explicitly address all the registers except for the "OPTION" and "TRISx"
registers.

> Is there something that I am missing by him declaring 0x1FF as a start
>vector and having it go to OHMS?  I knew that it probably wasn't an
>interrupt, since it didn't start at 0x004.  I suppose also, if it tried to
>start at 0x000, all you would hit are the add and multiply subroutines,
>which at that point of the program don't make a hell of a lot of sense
>since nothing has called them yet.

Just to summarize what I said above: the 16C54 is a "low-end" device and as
such, starts at the last address in EPROM.  It does not have interrupts, or
any advanced I/O features.

> Finally, is this 16C54 readily portable to the 16F84?  I'm guessing that
>it is.

Uhhhmmm...  My first inclination is to say no, but I know other PICListers
will disagree with me.

If you follow the rules I set out above (ie no jump to address 0 from 0x01FF
and use the "P16C5X.INC" file), your code will be "Source Code" compatible
with the 16F84.  You can change the processor references from 16C54 to 16F84
and re-assemble and everything will be fine.

The "TRIS" and "OPTION" instructions do work in the 16F84, but their use is
not recommended (they may go away some day).

Good luck and please let me know how you make out,

myke

1999\02\20@191737 by Andy Kunz

flavicon
face
>Just a word on this, I typically put my sixteen bit variables in what I call
>"Intel" format which is low byte at low address and high byte at high
>address.  What you have done here is put the data in what I call "Motorola"
>format (High Byte/Low Byte).

Good, because that makes it easier to link into C programs when you move to
that environment.

>If you follow the rules I set out above (ie no jump to address 0 from 0x01FF
>and use the "P16C5X.INC" file), your code will be "Source Code" compatible
>with the 16F84.  You can change the processor references from 16C54 to 16F84
>and re-assemble and everything will be fine.

Except if you use MPASM.  Then all your EQU's to define variables will be
at invalid addresses.  Use a better assembler.

Andy

  \-----------------/
   \     /---\     /
    \    |   |    /          Andy Kunz
     \   /---\   /           Montana Design
/---------+   +---------\     http://www.montanadesign.com
| /  |----|___|----|  \ |
\/___|      *      |___\/     Go fast, turn right,
                              and keep the wet side down!

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