Searching \ for '[PIC] Migrating from 16F to 18F' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16F
Search entire site for: 'Migrating from 16F to 18F'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Migrating from 16F to 18F'
2005\10\18@202751 by Nino Benci

flavicon
picon face
part 1 705 bytes content-type:text/plain; charset=ISO-8859-1; format=flowed (decoded 7bit)

I have just received a project which originally used the 16F877A. The
bulk of the code is in assembler with the user interface written in
PBPro. The client wants to add extra features and functions to the
existing code base. In doing so I will exceeded the memory capacity of
the 877A. I am looking at the 18F4520 as a replacement. The portions
written in PBPro are easy to migrate but about 75% of the code is in
assembler (although well documented). Aside from jumping in head first
and going blind into the project are there any issues or pointers that
would make life a whole lot simpler that I should look at before I proceed.

Thanks all.

Antonio Benci.


part 2 373 bytes content-type:text/x-vcard; charset=utf-8; name=Nino.Benci.vcf
(decoded 7bit)

begin:vcard
fn:Antonio L. Benci
n:Benci;Antonio L.
org:Monash University;School of Physics
adr:;;;Monash University;VIC;3800;Australia
email;internet:spam_OUTelectronic.servicesTakeThisOuTspamspme.monash.edu.au
title:Professional Officer
tel;work:+613 9905 3649
tel;fax:+613 9905 3637
x-mozilla-html:FALSE
url:http://spme.monash.edu.au
version:2.1
end:vcard



part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\10\18@222243 by Jim Robertson

flavicon
face

>I have just received a project which originally used the 16F877A.
>The bulk of the code is in assembler with the user interface written
>in PBPro. The client wants to add extra features and functions to
>the existing code base. In doing so I will exceeded the memory
>capacity of the 877A. I am looking at the 18F4520 as a replacement.
>The portions written in PBPro are easy to migrate but about 75% of
>the code is in assembler (although well documented). Aside from
>jumping in head first and going blind into the project are there any
>issues or pointers that would make life a whole lot simpler that I
>should look at before I proceed.
>
>Thanks all.
>
>Antonio Benci.

Nino,

Read the migration document (AN716) I sent you in a PM. I think it
covers most issues.

Let me know if you get stuck on anything in particular. For a while
the WARP-13 firmware was written to compile for either a 16F or 18F
so I guess I should be able to help.

Regards,

Jim


2005\10\19@074441 by olin piclist

face picon face
Nino Benci wrote:
> I have just received a project which originally used the 16F877A. The
> bulk of the code is in assembler with the user interface written in
> PBPro. The client wants to add extra features and functions to the
> existing code base. In doing so I will exceeded the memory capacity of
> the 877A. I am looking at the 18F4520 as a replacement. The portions
> written in PBPro are easy to migrate but about 75% of the code is in
> assembler (although well documented). Aside from jumping in head first
> and going blind into the project are there any issues or pointers that
> would make life a whole lot simpler that I should look at before I
> proceed.

It's a bit late to ask this question.  You should have thought about this
when writing the code in the first place.  My PIC development environment
(http://www.embedinc.com/pic), for example, makes it easy to write code that
requires minimal work to move between PIC types.

Fortunately for you, going from native PIC 16 to PIC 18 is easier than the
other way around.  Here are a few issues I can think of even if just wanting
to make PIC 16 code run on a PIC 18 without making use of any of the new PIC
18 features.  There are probably others, this is off the top of my head:

1 - RLF and RRF become RLCF and RRCF.  Yes I think it's stupid too that
Microchip changed the name although the instructions do exactly the same
thing.  Two macros can take care of this.

2 - INCF and DECF now effect C.

3 - All FSR and INDF accesses need to be examined.  The PIC 18 has 3 FSRs,
and they are each the full 12 bits wide.  This means both bytes must be set,
but there are no longer indirect banks.  INDF is now called INDF0 since
there are two more (INDF1, INDF2).  A macro for INDF can take care of this,
but all manipulation of FSR must be examined manually.

4 - The interrupt vector is 8 instead of 4.  You should consider redoing
your interrupt routine by starting with my QQQ_INTR18.ASPIC template, then
copying only the meat of the old interrupt routine into the new one.

5 - Banks are now 256 bytes long instead of 128, and the method of setting
the current bank is totally different.  The bank is set in the BSR register,
no longer by setting RP0/RP1 in STATUS.  This will be your single biggest
hassle and possible source of creeping bugs if your code was written badly
and manually set banks by manipulating RP0 and RP1 directly.  Now would be a
good time to do it right and use something like my DBANKIF and related
macros.

The PIC 18 can do a lot of other cool things, but you can ignore them just
to get PIC 16 code minimally running.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\19@201004 by Mike Harrison

flavicon
face
On Wed, 19 Oct 2005 10:23:50 +1000, you wrote:

>I have just received a project which originally used the 16F877A. The
>bulk of the code is in assembler with the user interface written in
>PBPro. The client wants to add extra features and functions to the
>existing code base. In doing so I will exceeded the memory capacity of
>the 877A. I am looking at the 18F4520 as a replacement. The portions
>written in PBPro are easy to migrate but about 75% of the code is in
>assembler (although well documented). Aside from jumping in head first
>and going blind into the project are there any issues or pointers that
>would make life a whole lot simpler that I should look at before I proceed.
>
>Thanks all.
>
>Antonio Benci.

One potential issue  is that on the 18F you can't change the watchdog prescaler from software (apart
from self-progging the config bits..)

2005\10\20@003024 by Antonio L. Benci

flavicon
picon face
part 1 3587 bytes content-type:text/plain; charset=ISO-8859-1; format=flowed (decoded 7bit)

Unfortunately I did not write the original code (asm or PBPro). I have
not even started to write the new code. Memory requirements that I have
calculated come from the fact that there are some data tables which have
to be included within the PBPro code. The addition of these tables alone
will exceed the available memory.

Your additional notes will help. Thanks.

Nino.

Olin Lathrop wrote:

{Quote hidden}


part 2 407 bytes content-type:text/x-vcard; charset=utf-8; name=nino.benci.vcf
(decoded 7bit)

begin:vcard
fn:Antonio L. Benci
n:Benci;Antonio L.
org:Monash University;School of Physics
adr:;;Clayton Campus;Monash University;VIC;3800;Australia
email;internet:.....nino.benciKILLspamspam@spam@sci.monash.edu.au
title:Professional Officer
tel;work:+613 9905 3649
tel;fax:+613 9905 3637
tel;cell:+613414924833
x-mozilla-html:FALSE
url:http://www.physics.monash.edu.au
version:2.1
end:vcard



part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

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