Which PIC18 C Compiler?

drwho wrote:
> 
> Recently I have started a new job where only the PIC18 and PIC16
> families are allowed.  I started with Microchip's C18 compiler and
> got frustrated with it when I could only have 256 bytes of global
> variables.  The compiler would give a message saying something
> along the lines that I have run out of RAM.  I guess the PICs have
> the RAM in banks of 256 bytes, so you need to manually assign the
> global variables into different banks.  I couldn't figure out how
> to do this, so I bought the CCS compiler hoping for a better
> experience.
> 
> CCS solved the banking issue, but the C18 appears to be more "ANSI
> C compliant".  for example:
> 
> GCC and the C18 will compile this code, but not the CCS
> 
> union hello {
>      struct {
>          unsigned char a;
>          unsigned char b;
>      };
>      unsigned char ppp[2];
> };
> 
> union hello test;
> 
> void main(void)
> {
>  test.a = 5;
>  test.ppp[0] = 50;
> 
>  /* ------ MAIN CONTROL LOOP ------ */
>  for (;;) {
     ...
>  }
> }
> The CCS compiler is saying that " test.a = 5;" is not a valid member :(

Try defining a properly with:

 union hello {
    struct foo {
       unsigned char a;
       unsigned char b;
    } foo;
    unsigned char ppp[2];
 };
 
 union hello test;
 
 void main(void)
 {
    test.foo.a = 5;
    test.ppp[0] = 50;  /* overwriting foo.a */

Note the use of foo.
 
-- 
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>



-- 
Posted via a free Usenet account from http://www.teranews.com

In message <k62dnd33WY0IDmzbnZ2dnUVZ_tuonZ2d@giganews.com>, drwho 
<drwho@mailinator.com> writes
>I have many years experience with AVR and WinAVR (GCC)
>Recently I have started a new job where only the PIC18 and PIC16 families
>are allowed.  I started with Microchip's C18 compiler and got frustrated
>with it when I could only have 256 bytes of global variables.  The
>compiler would give a message saying something along the lines that I have
>run out of RAM.  I guess the PICs have the RAM in banks of 256 bytes,

Then you need to STOP PROGRAMMING and look at the architecture of the 
parts. Understand the hardware environment. Programming embedded systems 
REQUIRES a knowledge of the hardware. Especially in the 8 and 16 bit 
areas.

>CCS solved the banking issue, but the C18 appears to be more "ANSI C
>compliant".  for example:

You will not get a fully  ISO C compliant compiler for the PIC. It's 
architecture will not permit it.  You need to write C for the PIC not 
portable C is you want to get any sort of efficiency out of it.

>GCC and the C18 will compile this code, but not the CCS

In which case READ THE COMPILER MANUAL not the ISO standard.

>Conclusion, If you have to use PICs and are on a budget, buy HiTec
>compiler, otherwise use IAR,

Sounds rerasonable

>otherwise use GCC

Not a chance.

>with a real processor like
>and AVR, MSP, or ARM7

The PIC is a real processor (not that I am keen on it)  Don't blame the 
processor because you cant read the manual.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills <chris@phaedsys.org> writes:

>
> You will not get a fully  ISO C compliant compiler for the PIC. It's architecture will not permit
> it.  You need to write C for the PIC not portable C is you want to get any sort of efficiency out of
> it.

Just out of interest, which bits of ISO C can't the PIC do?

cheers, Rich.


-- 
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   | skype: rich_at_shadow
need a Hand?           London  N1 1LX       | +44 20 7700 2487
http://www.shadowrobot.com/hand/

Rich Walker wrote:
> Chris Hills <chris@phaedsys.org> writes:
> 
>> You will not get a fully  ISO C compliant compiler for the PIC. It's architecture will not permit
>> it.  You need to write C for the PIC not portable C is you want to get any sort of efficiency out of
>> it.
> 
> Just out of interest, which bits of ISO C can't the PIC do?
> 

There are no bits of standard C that the PIC can't do, at least in 
theory - but there are plenty of things that it can't do efficiently, 
and which compilers might therefore not support.  Things like recursion 
would be a serious pain to implement.  General data pointers would be 
very inefficient (at least on the PIC16 - I don't know the PIC18) unless 
the compiler was particularly smart and the code amenable (so that the 
compiler could turn the pointers into segment-specific pointers on the 
fly).  That's just two examples - I'm sure there are more.

mvh.,

David

In message <m3lkb1y0t2.fsf@shadow.org.uk>, Rich Walker 
<rw@shadowrobot.com> writes
>Chris Hills <chris@phaedsys.org> writes:
>
>>
>> You will not get a fully  ISO C compliant compiler for the PIC. It's 
>>architecture will not permit
>> it.  You need to write C for the PIC not portable C is you want to 
>>get any sort of efficiency out of
>> it.
>
>Just out of interest, which bits of ISO C can't the PIC do?

Which ISO C?

This is not a trick question.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message <46f27251$0$3192$8404b019@news.wineasy.se>, David Brown 
<david@westcontrol.removethisbit.com> writes
>Rich Walker wrote:
>> Chris Hills <chris@phaedsys.org> writes:
>>
>>> You will not get a fully  ISO C compliant compiler for the PIC. It's 
>>>architecture will not permit
>>> it.  You need to write C for the PIC not portable C is you want to 
>>>get any sort of efficiency out of
>>> it.
>>  Just out of interest, which bits of ISO C can't the PIC do?
>>
>
>There are no bits of standard C that the PIC can't do, at least in 
>theory - but there are plenty of things that it can't do efficiently, 
>and which compilers might therefore not support.

Which is what I meant.

Though off the top of my head ISO C requires  levels of nesting and 
sizes of structures that the PIC is not physically capable of holding.

> Things like recursion would be a serious pain to implement.
Almost impossible and AFAIK more 8 bit compilers don't do recursion as 
standard. You usually need non-standard  keywords or declarations to do 
it.

> General data pointers would be very inefficient (at least on the PIC16 
>- I don't know the PIC18) unless the compiler was particularly smart 
>and the code amenable (so that the compiler could turn the pointers 
>into segment-specific pointers on the fly).  That's just two examples - 
>I'm sure there are more.

Exactly. So you need to understand the architecture and the compiler 
rather than the C standard.
-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills <chris@phaedsys.org> writes:

> In message <46f27251$0$3192$8404b019@news.wineasy.se>, David Brown
> <david@westcontrol.removethisbit.com> writes
>>Rich Walker wrote:
>>> Chris Hills <chris@phaedsys.org> writes:
>>>
>>>> You will not get a fully  ISO C compliant compiler for the PIC. It's architecture will not permit
>>>> it.  You need to write C for the PIC not portable C is you want to get any sort of efficiency
>>>> out of
>>>> it.
>>>  Just out of interest, which bits of ISO C can't the PIC do?
>>>
>>
>> There are no bits of standard C that the PIC can't do, at least in theory - but there are plenty
>> of things that it can't do efficiently, and which compilers might therefore not support.
>
> Which is what I meant.
>
> Though off the top of my head ISO C requires  levels of nesting and sizes of structures that the PIC
> is not physically capable of holding.

Right - yes, that's a good point.


>> Things like recursion would be a serious pain to implement.
> Almost impossible and AFAIK more 8 bit compilers don't do recursion as standard. You usually need
> non-standard  keywords or declarations to do it.

sdcc seems to support it pretty happily. This:

int recurse(int a) {
  if (a>1) 
  return 1+recurse(a-1); 
  else 
  return a;
}

gets compiled into 

;--------------------------------------------------------
; global & static initialisations
;--------------------------------------------------------
; I code from now on!
; ; Starting pCode block
S_recurse__recurse	code
_recurse:
;	.line	3; recurse.c	int recurse(int a) {
	MOVFF	FSR2L, POSTDEC1
	MOVFF	FSR1L, FSR2L
	MOVFF	r0x00, POSTDEC1
	MOVFF	r0x01, POSTDEC1
	MOVFF	r0x02, POSTDEC1
	MOVFF	r0x03, POSTDEC1
	MOVLW	0x02
	MOVFF	PLUSW2, r0x00
	MOVLW	0x03
	MOVFF	PLUSW2, r0x01
;	.line	4; recurse.c	if (a>1) 
	MOVF	r0x01, W
	ADDLW	0x80
	ADDLW	0x80
	BNZ	_00111_DS_
	MOVLW	0x02
	SUBWF	r0x00, W
_00111_DS_:
	BNC	_00106_DS_
;	.line	5; recurse.c	return 1+recurse(a-1); 
	MOVLW	0xff
	ADDWF	r0x00, W
	MOVWF	r0x02
	MOVLW	0xff
	ADDWFC	r0x01, W
	MOVWF	POSTDEC1
	MOVF	r0x02, W
	MOVWF	POSTDEC1
	CALL	_recurse
	MOVWF	r0x02
	MOVFF	PRODL, r0x03
	MOVLW	0x02
	ADDWF	FSR1L, F
	INCF	r0x02, F
	BTFSC	STATUS, 0
	INCF	r0x03, F
	MOVFF	r0x03, PRODL
	MOVF	r0x02, W
	BRA	_00108_DS_
_00106_DS_:
;	.line	7; recurse.c	return a;
	MOVFF	r0x01, PRODL
	MOVF	r0x00, W
_00108_DS_:
	MOVFF	PREINC1, r0x03
	MOVFF	PREINC1, r0x02
	MOVFF	PREINC1, r0x01
	MOVFF	PREINC1, r0x00
	MOVFF	PREINC1, FSR2L
	RETURN	


>
>> General data pointers would be very inefficient (at least on the PIC16 - I don't know the PIC18)
>> unless the compiler was particularly smart and the code amenable (so that the compiler could turn
>> the pointers into segment-specific pointers on the fly).  That's just two examples -
>>I'm sure there are more.

Yes; library calls for pointer dereferences suck...
>
> Exactly. So you need to understand the architecture and the compiler rather than the C standard.

That's a given in embedded programming :->

-- 
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   | skype: rich_at_shadow
need a Hand?           London  N1 1LX       | +44 20 7700 2487
http://www.shadowrobot.com/hand/

In message <m3hclpuzmh.fsf@shadow.org.uk>, Rich Walker 
<rw@shadowrobot.com> writes
>Chris Hills <chris@phaedsys.org> writes:
>
>> In message <46f27251$0$3192$8404b019@news.wineasy.se>, David Brown
>> <david@westcontrol.removethisbit.com> writes
>>>Rich Walker wrote:
>>>> Chris Hills <chris@phaedsys.org> writes:
>>>>
>>>>> You will not get a fully  ISO C compliant compiler for the PIC. 
>>>>>It's architecture will not permit
>>>>> it.  You need to write C for the PIC not portable C is you want to 
>>>>>get any sort of efficiency
>>>>> out of
>>>>> it.
>>>>  Just out of interest, which bits of ISO C can't the PIC do?
>>>>
>>>
>>> There are no bits of standard C that the PIC can't do, at least in 
>>>theory - but there are plenty
>>> of things that it can't do efficiently, and which compilers might 
>>>therefore not support.
>>
>> Which is what I meant.
>>
>> Though off the top of my head ISO C requires  levels of nesting and 
>>sizes of structures that the PIC
>> is not physically capable of holding.
>
>Right - yes, that's a good point.
>
>
>>> Things like recursion would be a serious pain to implement.
>> Almost impossible and AFAIK more 8 bit compilers don't do recursion 
>>as standard. You usually need
>> non-standard  keywords or declarations to do it.
>
>sdcc seems to support it pretty happily.

But the professional compilers don't .
There is probably a good reason for that
-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills <chris@phaedsys.org> writes:

> In message <m3hclpuzmh.fsf@shadow.org.uk>, Rich Walker <rw@shadowrobot.com> writes
>>Chris Hills <chris@phaedsys.org> writes:
>>
>>> In message <46f27251$0$3192$8404b019@news.wineasy.se>, David Brown
>>> <david@westcontrol.removethisbit.com> writes
>>>> Things like recursion would be a serious pain to implement.
>>> Almost impossible and AFAIK more 8 bit compilers don't do recursion as standard. You usually need
>>> non-standard  keywords or declarations to do it.
>>
>>sdcc seems to support it pretty happily.
>
> But the professional compilers don't .
> There is probably a good reason for that

Too hard for them? :-)

No, seriously, if there is, what would it be?



-- 
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   | skype: rich_at_shadow
need a Hand?           London  N1 1LX       | +44 20 7700 2487
http://www.shadowrobot.com/hand/

Rich,

The root reason is re-entrant code makes RAM space indeterminate.
The practical reason it is rarely needed in real embedded applications
after tail end recursion and all of the normal optimizations are applied.

There have been some very scary software faults reported over
the last 20 years traced to recursive code and stack creep.

The one I am most familiar with was the anti-lock brakes
on a well known German car in the early nineties. It detected
the fault and just turned the anti lock brakes off.

In our tools we handle re-entrant functions and non-reentrant
differently. We don't have special directives for re-entrant
code.

Regards


Walter Banks
Byte Craft Limited
Tel. (519) 888-6911
Fax (519) 746 6751
http://www.bytecraft.com
walter@bytecraft.com



Rich Walker wrote:

> Chris Hills <chris@phaedsys.org> writes:
>
> > In message <m3hclpuzmh.fsf@shadow.org.uk>, Rich Walker <rw@shadowrobot.com> writes
> >>Chris Hills <chris@phaedsys.org> writes:
> >>
> >>> In message <46f27251$0$3192$8404b019@news.wineasy.se>, David Brown
> >>> <david@westcontrol.removethisbit.com> writes
> >>>> Things like recursion would be a serious pain to implement.
> >>> Almost impossible and AFAIK more 8 bit compilers don't do recursion as standard. You usually need
> >>> non-standard  keywords or declarations to do it.
> >>
> >>sdcc seems to support it pretty happily.
> >
> > But the professional compilers don't .
> > There is probably a good reason for that
>
> Too hard for them? :-)
>
> No, seriously, if there is, what would it be?
>
> --
> rich walker         |  Shadow Robot Company | rw@shadow.org.uk
> technical director     251 Liverpool Road   | skype: rich_at_shadow
> need a Hand?           London  N1 1LX       | +44 20 7700 2487
> http://www.shadowrobot.com/hand/