Searching \ for '[PIC]: MPLAB-C porting' 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/ios.htm?key=port
Search entire site for: 'MPLAB-C porting'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: MPLAB-C porting'
2001\02\26@094805 by Mark Bishop

flavicon
face
On an old version of MPLAB-C (1.1) you could do something like this:

unsigned int flashadd = 0x8000;
unsigned long far *frdaddr;

frdaddr = flashadd;


Now with the latest version I get a type mis-match error.  Any clue as to
how to get
around this?

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@120825 by Mike Mansheim

flavicon
face
>On an old version of MPLAB-C (1.1) you could do something like this:

>unsigned int flashadd = 0x8000;
>unsigned long far *frdaddr;

>frdaddr = flashadd;

>Now with the latest version I get a type mis-match error.  Any clue as to
>how to get around this?

I use CCS C, not MPLAB C, but here are some observations:
-  In CCS, an int is 8 bits - which means 'flashadd' would not be able to
  hold 0x8000.
-  Without the "far", these statements do work in CCS, because the
  compiler automatically casts 'flashadd' to a long - this means that the
  low byte of 'frdaddr' is set to the value of 'flashadd', and the high
  byte of 'frdaddr' is set to 0.  Because of the first point (ints are
  8 bits), the result is 'frdaddr' = 0.  I suspect this is not the
  desired result.
-  Your compiler may not do the automatic casting, or a compiler directive
  may be required to make it happen.
-  If, as in CCS, ints are 8 bits and longs are 16 bits, you ARE mixing
  data types here.  Not a good idea, unless you are intentionally
  overlaying high and low bytes for some clever data manipulation.
-  As near as I can tell, making 'flashadd' a long would accomplish what
  you want.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@121305 by Richard Sloan

flavicon
face
frdaddr = flashadd;

should be

frdaddr = (unsigned long*)flashadd;

The compiler is now more strict on type checking.

R.


 >>  >On an old version of MPLAB-C (1.1) you could do something like this:

 >>  >unsigned int flashadd = 0x8000;
 >>  >unsigned long far *frdaddr;

 >>  >frdaddr = flashadd;

 >>  >Now with the latest version I get a type mis-match error.  Any clue as to
 >>  >how to get around this?

 >>  I use CCS C, not MPLAB C, but here are some observations:
 >>  -  In CCS, an int is 8 bits - which means 'flashadd' would not be able to
 >>     hold 0x8000.
 >>  -  Without the "far", these statements do work in CCS, because the
 >>     compiler automatically casts 'flashadd' to a long - this means that the
 >>     low byte of 'frdaddr' is set to the value of 'flashadd', and the high
 >>     byte of 'frdaddr' is set to 0.  Because of the first point (ints are
 >>     8 bits), the result is 'frdaddr' = 0.  I suspect this is not the
 >>     desired result.
 >>  -  Your compiler may not do the automatic casting, or a compiler directive
 >>     may be required to make it happen.
 >>  -  If, as in CCS, ints are 8 bits and longs are 16 bits, you ARE mixing
 >>     data types here.  Not a good idea, unless you are intentionally
 >>     overlaying high and low bytes for some clever data manipulation.
 >>  -  As near as I can tell, making 'flashadd' a long would accomplish what
 >>     you want.

 >>  --
 >>  http://www.piclist.com hint: PICList Posts must start with ONE topic:
 >>  [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@122125 by Mike Mansheim

flavicon
face
>>  On an old version of MPLAB-C (1.1) you could do something like this:

>>  unsigned int flashadd = 0x8000;
>>  unsigned long far *frdaddr;

>>  frdaddr = flashadd;

from Richard Sloan:
>frdaddr = flashadd;

> should be

>frdaddr = (unsigned long*)flashadd;

>The compiler is now more strict on type checking.

This will still result in frdaddr = 0.
Is that the intended result?

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@122457 by Richard Sloan

flavicon
face
Why would this be?

 >>  >>  On an old version of MPLAB-C (1.1) you could do something like this:

 >>  >>  unsigned int flashadd = 0x8000;
 >>  >>  unsigned long far *frdaddr;

 >>  >>  frdaddr = flashadd;

 >>  from Richard Sloan:
 >>  >frdaddr = flashadd;

 >>  > should be

 >>  >frdaddr = (unsigned long*)flashadd;

 >>  >The compiler is now more strict on type checking.

 >>  This will still result in frdaddr = 0.
 >>  Is that the intended result?

 >>  --
 >>  http://www.piclist.com hint: PICList Posts must start with ONE topic:
 >>  [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@151621 by Mike Mansheim

flavicon
face
from RS:
>> Why would this be?
orig:
>  unsigned int flashadd = 0x8000;
>  unsigned long far *frdaddr;
from RS:
>  frdaddr = (unsigned long*)flashadd;
from MM:
>  This will still result in frdaddr = 0.
>  Is that the intended result?

I'm getting lost in > symbols, so I've edited liberally!
I'm just saying that flashadd = 0, because it is defined as an int.  It
is actually incorrect to assign 0x8000 to an int, but the compiler will
accept this and assign the lower byte (0 in this case).
In the original post, the statement was:
           frdaddr = flashadd;
which will result in frdaddr = 0.
I incorrectly neglected the '*' in the RS modified frdaddr assignment
statement: I was reacting to:
           frdaddr = (unsigned long)flashadd;
which will still result in frdaddr = 0, since the original assignment of
0x8000 won't be "remembered" even if flashadd is later cast to a long.
The '*' changes things dramatically:
           frdaddr = (unsigned long*)flashadd;
This puts the value of what flashadd points to into frdaddr.  In this
case, flashadd = 0, so frdaddr will be assigned whatever is stored at
locations 0 & 1.  So, in that case, you are correct, frdaddr will not
necessarily be 0.
However, that doesn't look like the original intent, since the 0x8000 is
getting lost.  I can't be sure, because I don't understand how the
statements could have functioned properly before - this could be a good
sign that I'm not "getting it".
It looks to me as though he intended for frdaddr = 0x8000 ("addr" being
in the name is part of that reasoning).  Then, frdaddr would be used to
access the value at 0x8000:
            x = *frdaddr;
now x = whatever value is stored at 0x8000.  Perhaps then frdaddr is
decremented to step through memory; so flashadd was used to define the
starting point???

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@152658 by Mark Bishop

flavicon
face
Let me add - I didn't write this code.  I'm just the one who gets to port it
over :(  It looks like frdaddr is used as a starting point 0x8000 and then
stepped down each iteration when adding data to flash memory.  I'm still
figuring out the schematic and the processor but that's how it looks to me.

So flshaddr needs to be at address 0x8000 at least what I can make of this
mess.
                        ____
flshaddr -->    |8000|
                       |8001|
                       |8002|
                       |8003|
                       |----|

{Original Message removed}

2001\02\26@152703 by Richard Sloan

flavicon
face
It is defined as unsigned int! So 0x8000 is OK.

 >>  I'm getting lost in > symbols, so I've edited liberally!
 >>  I'm just saying that flashadd = 0, because it is defined as an int.  It
 >>  is actually incorrect to assign 0x8000 to an int, but the compiler will
 >>  accept this and assign the lower byte (0 in this case).
 >>  In the original post, the statement was:
 >>              frdaddr = flashadd;
 >>  which will result in frdaddr = 0.
 >>  I incorrectly neglected the '*' in the RS modified frdaddr assignment
 >>  statement: I was reacting to:
 >>              frdaddr = (unsigned long)flashadd;
 >>  which will still result in frdaddr = 0, since the original assignment of
 >>  0x8000 won't be "remembered" even if flashadd is later cast to a long.
 >>  The '*' changes things dramatically:
 >>              frdaddr = (unsigned long*)flashadd;
 >>  This puts the value of what flashadd points to into frdaddr.  In this
 >>  case, flashadd = 0, so frdaddr will be assigned whatever is stored at
 >>  locations 0 & 1.  So, in that case, you are correct, frdaddr will not
 >>  necessarily be 0.
 >>  However, that doesn't look like the original intent, since the 0x8000 is
 >>  getting lost.  I can't be sure, because I don't understand how the
 >>  statements could have functioned properly before - this could be a good
 >>  sign that I'm not "getting it".
 >>  It looks to me as though he intended for frdaddr = 0x8000 ("addr" being
 >>  in the name is part of that reasoning).  Then, frdaddr would be used to
 >>  access the value at 0x8000:
 >>               x = *frdaddr;
 >>  now x = whatever value is stored at 0x8000.  Perhaps then frdaddr is
 >>  decremented to step through memory; so flashadd was used to define the
 >>  starting point???

 >>  --
 >>  http://www.piclist.com hint: PICList Posts must start with ONE topic:
 >>  [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@154739 by Mike Mansheim

flavicon
face
> It is defined as unsigned int! So 0x8000 is OK.

All depends on the compiler!  In true ANSI C, ints are 16 bit, but C
compilers for the pic aren't necessarily 100% compliant.  As I mentioned
earlier, I use CCS C, where ints are 8 bit.  I looked at an old (1997)
manual for something called only "MPLAB C" (don't know a version; never
used it), and ints were 8 bit there also.
I kind of took off from that and have been assuming ints are 8 bits in
all subsequent posts (that is natural to me now anyway).  Sorry for any
confusion that may have caused.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@160255 by Richard Sloan

flavicon
face
Right its enough to make me crazy!

ints in my mind are 16 bits, NEVER 8!

I used the CCS C compiler and it drove me so crazy!

R.


 >>  > It is defined as unsigned int! So 0x8000 is OK.

 >>  All depends on the compiler!  In true ANSI C, ints are 16 bit, but C
 >>  compilers for the pic aren't necessarily 100% compliant.  As I mentioned
 >>  earlier, I use CCS C, where ints are 8 bit.  I looked at an old (1997)
 >>  manual for something called only "MPLAB C" (don't know a version; never
 >>  used it), and ints were 8 bit there also.
 >>  I kind of took off from that and have been assuming ints are 8 bits in
 >>  all subsequent posts (that is natural to me now anyway).  Sorry for any
 >>  confusion that may have caused.

 >>  --
 >>  http://www.piclist.com hint: PICList Posts must start with ONE topic:
 >>  [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@160507 by Mike Mansheim

flavicon
face
>Let me add - I didn't write this code.  I'm just the one who gets to port
it
>over :(  It looks like frdaddr is used as a starting point 0x8000 and then
>stepped down each iteration when adding data to flash memory.  I'm still
>figuring out the schematic and the processor but that's how it looks to
me.

>So flshaddr needs to be at address 0x8000 at least what I can make of this
>mess.

Then, this should work:

unsigned long flashadd = 0x8000;    // change this to a long
unsigned long far *frdaddr;         // don't know what "far" does here;
doesn't
                                   // compile on CCS
frdaddr = flashadd;

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@161557 by Mark Bishop

flavicon
face
Yeah, but not with the MPLAB-C17 (demo) compiler.  I add the mask (unsigned
long*) to the right side of the equality statment and then make sure to
enable the far pointers in the project and everything goes good.  Well, at
least as far as that is concerned.  I'm getting an assert error as well as
command line too long error (even though command line is whittled down to 76
characters).  I've talked to Microchip (Level 1) and they have no clue.  And
their message board is painfully slow.

<rant>
First we had problems going from the 16C77 to 18C452 series, changing
compilers, stuff just didn't work - real basic stuff like regular math
functions (add, subtract) to a stack leak in their interrupt routines.

Now I can't generate anything decent with this C17 compiler (regardless of
the pointer issue - that was not adding the type specific information).  I
can't get prompt help and I'm certainly not going to buy the non-demo
compiler with such problems as I've been having with this one.
</rant>

Sorry, I feel better now.

{Original Message removed}

2001\02\26@164243 by Douglas Wood

picon face
That's not quite true... ANSI only defines a type's "range", not its size.
From "ANSI C: A Lexical Guide" an "int" is defined thus:

"The type int holds an integer. it is usually the same size as a word (or
register) on the target machine. A int can encode any number between INT_MIN
and INT_MAX."

Douglas Wood
Software Enigneer
spam_OUTdbwoodTakeThisOuTspamkc.rr.com

Home of the EPICIS Development System for the PIC and SX
http://www.piclist.com/techref/member/DW--RA4
{Original Message removed}

2001\02\26@170350 by Mike Mansheim

flavicon
face
>Yeah, but not with the MPLAB-C17 (demo) compiler.  I add the mask
(unsigned
>long*) to the right side of the equality statment and then make sure to
>enable the far pointers in the project and everything goes good.

Hate to belabor the point (too late, I suppose), but I don't think

         fraddr = (unsigned long*)flashadd;

is what you are after, whether flashadd is a long or not.  This assigns the
value at flashadd to frdaddr.  e.g. if flashadd is a long, and = 0x8000,
then
frdaddr will be equal to whatever value is in location 0x8000.

...just to thoroughly confuse things, I found an MPLAB-C17 user's guide.
According to that:  ints are 16 bit, and longs are 32 bit and are not
supported (maybe later? this is v2.10).  char is the 8 bit data type.
"far" declares paged/banked data.  It does have a few pages on porting code
from MPLAB-C to C17 that might be useful for you.  One of of things
mentioned
was changing longs to ints.  Also talks about pointer lengths.
So this might be the correct setup:

            unsigned int flashadd = 0x8000;
            unsigned int far *frdaddr;            // "far" necessary?

            frdaddr = flashadd;

But these compilers are so different that I don't know...

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@203523 by Bob Ammerman

picon face
----- Original Message -----
From: Mike Mansheim <.....Michael_J_MansheimKILLspamspam@spam@GRACO.COM>
To: <PICLISTspamKILLspamMITVMA.MIT.EDU>
Sent: Monday, February 26, 2001 3:12 PM
Subject: Re: [PIC]: MPLAB-C porting


{Quote hidden}

No, I'm afraid it will not. The statement

   frdaddr = (unsigned long *) flashadd;

will interpret the bits of 'flashadd' as a pointer to an unsigned long;.

It will then attempt to assign that _pointer_ to frdaddr.

Such an assignment is _illegal_ in standard "C" (you cannot assign a pointer
to an integer type).

Typical behavior of prestandard compilers would assign the bit pattern of
the pointer.

So, if 'frdaddr' is an 8-bit variable (another non-standard thing) it will
get the value 0.

If it is a 16-bit variable it will get the value 0x8000.

By the way, the syntax:

 frdaddr = *(unsigned long *) flashadd;

(notice the extra *)

will store whatever unsigned long value 'flashadd' happens to point to into
frdaddr (with appropriate truncation). I do not know what a pointer value of
0x8000 might point to on a PIC.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@204129 by Bob Ammerman

picon face
> That's not quite true... ANSI only defines a type's "range", not its size.
> From "ANSI C: A Lexical Guide" an "int" is defined thus:
>
> "The type int holds an integer. it is usually the same size as a word (or
> register) on the target machine. A int can encode any number between
INT_MIN
> and INT_MAX."

The standard also defines minimum sizes:

A char - at least 8 bits

An int - at least 16 bits

A long - at least 16 bits (!!)

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@211244 by Douglas Wood

picon face
Granted. But you shouldn't make the blanket statement that an "int" is 16
bits. It's implementation dependent. Also, if you look at the _MIN and _MAX
macros in limits.h, you'll find that the "standard" sizes (8-bit, 16-bit,
etc.) are specified by the very fact that you cannot "fit" INT_MAX or
INT_MIN into an 8-bit data type.

Douglas Wood
Software Enigneer
.....dbwoodKILLspamspam.....kc.rr.com

Home of the EPICIS Development System for the PIC and SX
http://www.piclist.com/techref/member/DW--RA4
{Original Message removed}

2001\02\27@110003 by Mike Mansheim

flavicon
face
> No, I'm afraid it will not. The statement

>    frdaddr = (unsigned long *) flashadd;

> will interpret the bits of 'flashadd' as a pointer to an unsigned long;.

> It will then attempt to assign that _pointer_ to frdaddr.

Ah, didn't recognize that you can cast to a pointer.  Well, that's what
I get for jumping in where I'm not an expert just cuz I thought I knew
the answer.  I'll retreat now to wipe the egg off my face, and promise
not to post any more answers on this thread.

> Such an assignment is _illegal_ in standard "C" (you cannot assign a
pointer
> to an integer type).

Can you clarify this for me?  frdaddr was originally defined as a long
pointer - I'm not clear on what is illegal.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\02\27@160642 by Bob Ammerman

picon face
----- Original Message -----
From: Mike Mansheim <EraseMEMichael_J_Mansheimspam_OUTspamTakeThisOuTGRACO.COM>
To: <PICLISTspamspam_OUTMITVMA.MIT.EDU>
Sent: Tuesday, February 27, 2001 10:55 AM
Subject: Re: [PIC]: MPLAB-C porting


{Quote hidden}

Um, frdaddr was defined as int, wasn't it?

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\02\27@161526 by Mark Bishop

flavicon
face
no it was defined as unsigned long far *

-----Original Message-----
From: Bob Ammerman [@spam@RAMMERMANKILLspamspamPRODIGY.NET]
Sent: Tuesday, February 27, 2001 4:06 PM
To: KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU
Subject: Re: [PIC]: MPLAB-C porting



Um, frdaddr was defined as int, wasn't it?

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\02\27@162326 by Bob Ammerman

picon face
oops!

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

----- Original Message -----
From: Mark Bishop <RemoveMEMBishopTakeThisOuTspamBE-INC.COM>
To: <spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU>
Sent: Tuesday, February 27, 2001 4:13 PM
Subject: Re: [PIC]: MPLAB-C porting


> no it was defined as unsigned long far *
>
> {Original Message removed}

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