Searching \ for '[PIC:] 16 to 18F migration' 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=18F
Search entire site for: '16 to 18F migration'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] 16 to 18F migration'
2005\02\22@160533 by Roland

flavicon
face

Hi All

I'm moving an assembly program from a 16F877 to a 18F452

Still editing the syntax at the moment, and wondered if I'm on the right
track. I'm simply building and editing until all the errors go away.

Basically;
- I'll need to attend to some new SFR's, and some name changes
- Interrupts can be split to high and low priority
- I intend to use Bank1 of ram, so;
 - my Cblock starts at 0x100
 - all my old FSR and INDF become FSR1 and INDF1
- many of the 'goto's become 'bra' (within branch limits)

What I'm unsure of is:
- in the old code I had; goto $ + 5
- in the new code do I have to use; bra  $ + 5
but I still get: "Warning 226: Destination address must be word aligned"
what do I do to alleviate this? The manual say's

"
226 UNKNOWN WARNING
A warning has occurred which the assembler cannot understand. It is not any
of the warnings described in this appendix. Contact your Microchip Field
Application Engineer (FAE) if you cannot debug this warning.
"

Any other common snags to watch for?


Regards
Roland Jollivet

2005\02\22@162522 by Herbert Graf

flavicon
face
On Tue, 2005-02-22 at 23:02 +0000, Roland wrote:
{Quote hidden}

The 18F series has a byte addressed PC. But each op code is 2 bytes.
Therefore EVERY op code MUST start on a word boundary.

People will correct me if I'm wrong but to get the same functionality
use bra $ + 0x0a

However, I personally don't like this type of jumping and would much
rather see the use of a label. TTYL


-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\02\22@163227 by Aaron

flavicon
face
Roland wrote:

>What I'm unsure of is:
>- in the old code I had; goto $ + 5
>- in the new code do I have to use; bra  $ + 5
>but I still get: "Warning 226: Destination address must be word aligned"
>what do I do to alleviate this?
>
>  
>
To quote a post from Jan-Erik in the "Linker Error" thread earlier this
month...

"One the 16-line of PIC's the program counter counts program
"words". That is, each single increment of the PC points to a
valid (14-bit) instruction.

On the 18-line of PIC's the program counter counts "bytes", and
two bytes makes up one 16-bit instruction. That is, when referencing
valid instructions, the LSB of the PC must be zero "0". The byte
adressing is used when reading/writing tables in program space
using the TBLxxx instructions.

Now, with that said, I can't tell how this relates to your code, since
you don't show enough of it to tell.

The most common case when porting "jump tables" from the 16
to the 18-line, is to multiply the "index" with two before adding
it to the PCL. Such as a simple shift left..."



2005\02\22@171100 by Jan-Erik Soderholm

face picon face
Roland wrote :

> Hi All
>
> I'm moving an assembly program from a 16F877 to a 18F452
>
> Still editing the syntax at the moment, and wondered if I'm
> on the right track. I'm simply building and editing until all
> the errors go away.

Might be OK, if you just need a "working" prog.
It will probably not be "18-optimized" though...

>
> Basically;
> - I'll need to attend to some new SFR's, and some name changes

Obviously, yes... :-)

> - Interrupts can be split to high and low priority

But just becuse you can, do you need that ? From what I
have understod, most just use the single level interrupt system.

> - I intend to use Bank1 of ram, so;

Why ? Are you not using (the lower half of) bank0 at all ?
If so, you miss the whole "access bank" thing. That is one
of the realy nice things with the 18-line.

>   - my Cblock starts at 0x100

I bet *someone* will add that you *should* look at RES and
use the linker instead... :-) You don't have to do that, but I would...

>   - all my old FSR and INDF become FSR1 and INDF1
> - many of the 'goto's become 'bra' (within branch limits)
>
> What I'm unsure of is:
> - in the old code I had; goto $ + 5

Do yourself a big favour and throw them out at once !
Add lables and goto (or branch) to them instead. If you
had done that in your PIC16 code in the first place, that
had been portable as-is.

> - in the new code do I have to use; bra  $ + 5
> but I still get: "Warning 226: Destination address must be
> word aligned"

Correct. As expected. Since each instruction is on an even
address, and you are adding an odd value, you will end up
on an odd address, right ?   "even" + "odd" = "odd"...

{Quote hidden}

Don't bother. Just get those goto/bra $-something out and
add lables instead.

> Any other common snags to watch for?

The rotate instructions, if I'm not wrong.
I think there are som changes how the carry bit is handled
in some arithmetic instruction, but I'm not sure...

Jan-Erik.



2005\02\22@174838 by Roland

flavicon
face

Hi All

>What I'm unsure of is:
>- in the old code I had; goto $ + 5
>- in the new code do I have to use; bra  $ + 5
>but I still get: "Warning 226: Destination address must be word aligned"

To answer my own question courtesy of Roy in a previous post;

______________
"
Found this at a microchip forum -

It sounds like you have a 'goto $-1' or similar instruction somewhere in
the module. While that's legal in the 16-series devices, it's not for
the 18-series. In the 18-series devices, all PC-relative branches have
to be made to a location that's an even number of bytes from the current
PC value.

Rewriting the GOTO instruction fixed the linker error.

Posted this for any other PIC list members who may be converting PIC16
code to PIC18
_______________________________________
Roy
Tauranga
New Zealand
____________________________________

"
_____________

so, looking at the code snippet;

 btfss  stata,3
 bra    $ + 5         <<<<<<<<<<<<< error line
 bsf    Port_A,HAZ
 incf   haz1,1
 btfsc  haz1,0
 bra    $ + 2
 bcf    Port_A,HAZ
 movf   Port_A,0
 movwf  PORTA        ;update the relays

is the solution to write? ;

 btfss  stata,3
 bra    $ + 6        <<<< now an even step
 nop                 <<<< add a nop to align ?          
 bsf    Port_A,HAZ
 incf   haz1,1
 btfsc  haz1,0
 bra    $ + 2
 bcf    Port_A,HAZ
 movf   Port_A,0
 movwf  PORTA        ;update the relays

OK, it works, but is this the correct modus operandi?


Regards
Roland Jollivet

2005\02\22@175302 by Harold Hallikainen

face picon face


> What I'm unsure of is:
> - in the old code I had; goto $ + 5
> - in the new code do I have to use; bra  $ + 5
> but I still get: "Warning 226: Destination address must be word aligned"
> what do I do to alleviate this? The manual say's


Well, it'd be nicest to use labels...  The shortest instruction is 2 bytes
long, so you'd have to do something like $ + 2*5. Some instructions are
longer, though, so this can be dangerous. Nicest to just let the assembler
handle it through labels.

In computed gotos, I often have a variable holding the state. This needs
to be shifted left one bit (multiplied by 2) before adding to the pcl if
the table is branch instructions. A goto is longer, so a larger multipier
is needed.

I recall there also being a difference in the way flags are handled on
incf and decf instructions that causes some code to break. Look at those
carefully.

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com

2005\02\22@180444 by Roland

flavicon
face
At 04:25 PM 22/02/2005 -0500, you wrote:
>However, I personally don't like this type of jumping and would much
>rather see the use of a label. TTYL
>
>-----------------------------
>Herbert's PIC Stuff:

Yes, I appreciate that, but it's obvioulsy most oft used with a btfsc type
instruction to move usually no more than 6 instructions away. Labels in
these instances get messy and look superflous.

Regards
Roland Jollivet

2005\02\22@182826 by Jan-Erik Soderholm

face picon face
Roland wrote :

> >However, I personally don't like this type of jumping and would much
> >rather see the use of a label. TTYL
> >Herbert's PIC Stuff
>
> Yes, I appreciate that, but it's obvioulsy most oft used with
> a btfsc type instruction to move usually no more than 6
> instructions away. Labels in these instances get messy
> and look superflous.

The use of lables instead of the $+/- thing just
tells me that the code was written by someone
who cares about future management of the code and
that maybe someone else will be reading it also.

*AND*, it makes the code less portable, which actualy
was your problem here, right ?

Jan-Erik.



2005\02\22@182842 by Roland

flavicon
face
At 11:10 PM 22/02/2005 +0100, you wrote:
>Roland wrote :
>
>> Hi All
>>
>> I'm moving an assembly program from a 16F877 to a 18F452
>>
>> Still editing the syntax at the moment, and wondered if I'm
>> on the right track. I'm simply building and editing until all
>> the errors go away.
>
>Might be OK, if you just need a "working" prog.
>It will probably not be "18-optimized" though...
>

Thanks Jan-Erik
I'll look into your pointers.
Yes, basically I've been absolute coding on the 877, and reached the first
page and bank limit.
Now I have to add to the program and was faced with further bank switching,
or going to re-locatable code, or going to the 18F. For a few cents more I
get linear address and 32K!! (Hah!, the foundation of all bloat code)

So right now I'm just aiming at workability to finish it off. I'll take the
18F manual to bed next month.


Regards
Roland Jollivet

2005\02\22@192252 by Harold Hallikainen

face picon face
The nop is not needed (you just occupied another word or 2 bytes, which
probably messed up your branch calculations.  Labels are nice, even for
short branches!

Harold


>   btfss  stata,3
>   bra    $ + 6        <<<< now an even step
>   nop                 <<<< add a nop to align ?



--
FCC Rules Updated Daily at http://www.hallikainen.com

--

2005\02\22@192340 by Jinx
face picon face
> or going to re-locatable code, or going to the 18F. For a few cents more
> I get linear address and 32K!! (Hah!, the foundation of all bloat code)

It only bloats if you let it, of course. The extra instructions available
could actually make the code smaller. LFSR, MOVFF, MUL and
the TBL and POST/PRE INC commands for example

As for the GOTO $, the 18F is 16-bit, arranged as pairs of bytes, the
16F is 14-bit in one byte, so any GOTO or BRA references will be
even. Where possible use labels, particularly with macros

> So right now I'm just aiming at workability to finish it off. I'll take
the
> 18F manual to bed next month.

You buy it dinner first, m'kay ?

2005\02\22@193609 by Herbert Graf

flavicon
face
On Wed, 2005-02-23 at 01:04 +0000, Roland wrote:
> At 04:25 PM 22/02/2005 -0500, you wrote:
> >However, I personally don't like this type of jumping and would much
> >rather see the use of a label. TTYL
> >
> >-----------------------------
> >Herbert's PIC Stuff:
>
> Yes, I appreciate that, but it's obvioulsy most oft used with a btfsc type
> instruction to move usually no more than 6 instructions away. Labels in
> these instances get messy and look superflous.

Until of course another person comes to your code (or you many years
later), adds a single line, and BOOM, the whole things stops working.
Then weeks are spent trying to figure out why the UART isn't working.
After all, the addition of one line in the printf routine certainly
can't effect the UART spiting out weird stuff, right??

Sorry, I don't care how "superfluous" it might look, labels are
ESSENTIAL in my mind. TTYL



-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\02\22@200011 by olin_piclist

face picon face
Roland wrote:
> - in the old code I had; goto $ + 5

Very bad idea.  Don't use the GOTO $+n construct to jump further than an
adjacent instruction.  Go and fix all of them by putting in labels before
you do the conversion.


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

2005\02\22@211156 by olin_piclist

face picon face
Jan-Erik Soderholm wrote:
> The rotate instructions, if I'm not wrong.
> I think there are som changes how the carry bit is handled
> in some arithmetic instruction, but I'm not sure...

The PIC 16 always rotates thru the carry bit.  On the PIC 18 there are two
rotate instructions for each direction, one that rotates thru C and one that
doesn't.  The dumb thing is that they changed the mnemonic for the one that
does, even though the instruction does the same thing.  At least the
assembler will find all the rotates so you can manuall change them.

The nasiest difference is that the DECF and INCF instruction now have
different effect on the status bits.  I think the PIC 18 way is better, but
the same mnemonics have different effects on the 16 adn 18.

I don't understand why they needed to make a new mnemonic for the rotate
instruction that does the same thing, but keep the same mnemonic for the
DECF and INCF instruction that do something different.


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

2005\02\22@212041 by olin_piclist

face picon face
Roland wrote:
> Yes, I appreciate that, but it's obvioulsy most oft used with a btfsc
> type instruction to move usually no more than 6 instructions away.

That's about 5 instructions too far.  It is very easy to slip some extra
instructions between the GOTO and the target in later without noticing the
jump around them.  There is also no label at the target to warn you that
execution could be coming from multiple directions.  This is irreresponsible
programming at its worst.

> Labels in these instances get messy and look superflous.

They won't after you've wasted a day chasing an obscure bug a year from now
after a minor modification.


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

2005\02\23@041301 by Alan B. Pearce

face picon face
>I'll take the 18F manual to bed next month.
>
>You buy it dinner first, m'kay ?

I was thinking more along the lines of it guaranteeing you'll go to sleep
quick.

2005\02\24@090207 by Jim Robertson

flavicon
face


{Quote hidden}

Well, how about "You are wrong?"

The fact is you can CAN have local labels in absolute 18F code and it has
nothing
to do with the linker.

Branch relatives with offsets of  $+4, $-2 or in some cases $-4 are more
readable than
trying to spot matching labels that could be anywhere.

Any person who wants to tell me I cannot instantly recognize this snippets
of code is
wasting their time.

    clrwdt
    btfss  BusyFlag
    bra   $-4

Anyone else who cannot reconize it has no business looking at my code. ;-)

Regards,

Jim



>        best regards,   John





2005\02\24@151930 by jsand

flavicon
face
Hello Jim & PIC.ers,

----- Original Message -----
From: "Jim Robertson" <spam_OUTjimplTakeThisOuTspamnewfoundelectronics.com>
To: <.....piclistKILLspamspam@spam@mit.edu>
Sent: Thursday, February 24, 2005 4:02 PM
Subject: [PIC:] 16 to 18F migration


{Quote hidden}

Fair enough, I've only used the 18Fs with the linker & hadn't checked
whether Locals could be used within absolute mode.

I'm still forever avoiding $ tho'.....
For the general un-maintainability & fragility reasons given by several others.


   best regards,   John

email from the desk of John Sanderson.
JS Controls, PO Box 1887, Boksburg 1460, Rep. of S. Africa.
Tel/Fax 011 893 4154,
Cell 082 741 6275,
web    http://www.jscontrols.co.za
Manufacturer & purveyor of laboratory force testing apparatus &
related products & services.


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