Chris Hills wrote:> 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.Yes it is. Try just section 5.2.4.1 of the C99 standard. For a starter. -- 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
Which PIC18 C Compiler?
Started by ●July 8, 2004
Reply by ●September 20, 20072007-09-20
Reply by ●September 20, 20072007-09-20
[heavily snipped] ---8<--- Chris Hills wrote:> In message <k62dnd33WY0IDmzbnZ2dnUVZ_tuonZ2d@giganews.com>, drwho > <drwho@mailinator.com> writes >> otherwise use GCC > > Not a chance. >---8<--- One of my maxims is "If you can't handle the answer - don't ask the question". So, with some trepidation I ask... Why not? What is the problem with GCC? There, I have done it now. Pete
Reply by ●September 20, 20072007-09-20
"Peter Harrison" <peter_harrison@ntlworld.com> wrote in message news:TnzIi.52037$rr5.17561@newsfe1-win.ntli.net...> [heavily snipped] > ---8<--- > Chris Hills wrote: >> In message <k62dnd33WY0IDmzbnZ2dnUVZ_tuonZ2d@giganews.com>, drwho >> <drwho@mailinator.com> writes >>> otherwise use GCC >> >> Not a chance. >> > ---8<--- > One of my maxims is "If you can't handle the answer - don't ask the > question". So, with some trepidation I ask... > > Why not? What is the problem with GCC? > > There, I have done it now. > > PeteFor a start - there is no GCC implementation for the PIC18 that I am aware of - although there is a good one for the PIC24 and dsPIC. You can search this group for posts by Chris to see his opinion on GCC. -- Regards, Richard. + http://www.FreeRTOS.org 13 official architecture ports, 1000 downloads per week. + http://www.SafeRTOS.com Certified by T�V as meeting the requirements for safety related systems.
Reply by ●September 20, 20072007-09-20
CBFalconer <cbfalconer@yahoo.com> writes:> Chris Hills wrote: >> 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. > > Yes it is. Try just section 5.2.4.1 of the C99 standard. For a > starter.Isn't this the "we're assuming you've got 512KB of ram on the target" section? -- 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/
Reply by ●September 20, 20072007-09-20
On Wed, 19 Sep 2007 16:24:37 -0500, "drwho" <drwho@mailinator.com> wrote:>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.Microchip is an excellent company, on some fronts. They treat smaller companies generally quite well, have had in the past well informed technical support staff with genuine personal software development experience as well as a good hardware understanding (and I mean this in comparison to other micro manufacturers' technical support staff, which have been consistently inferior to those at Microchip), they track problems in a consistent fashion you can understand, and they support their professional tools almost forever. Old chip production tools are supported far longer than I've found elsewhere. As in, I've never had them tell me "we don't support that anymore and cannot get you a replacement." I'm sure they have their problems, as well.>I started with Microchip's C18 compilerWhich version?>and got frustrated >with it when I could only have 256 bytes of global variables.The PICs have an instruction set and/or a page control register (depends on which PIC how much of what is what) that makes it "easy" to access variables on a "base page" that is 256 bytes in size. This means that you will want to place variables there, those which need faster access and/or where you think it may help in terms of code size because of the number of places that reference them. You don't have to do that. But if you want that advantage, you need to let the compiler know what you consider a high priority for that, so it can do it. I suppose they could have written something to take a more general clue from you (size vs speed, for example) and "figure some things out" on its own. But instead they just let you wrap the definitions so that the compiler is directed what to do about that.>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,Roughly speaking. The 18-series is better about this than some of the 16F-series, themselves better than some of the old 16C-series, if memory serves. But having programmed PICs since 1989, I might be mixing in a few experiences. Things vary a little. And the PIC18's are definitely nicer, in this regard.>so >you need to manually assign the global variables into different banks.I don't recall that requirement. I believe in some code I wrote for the 18-series (it's been a few years, so forgive my memory), I could just declare the variables and the compiler/linker placed them 'satisfactorily.' I wrapped definitions that I cared to place on the base page (0), that's all.>I >couldn't figure out how to do this, so I bought the CCS compiler hoping >for a better experience. ><snip>The C18 compiler uses #pragma's. Use something like: #pragma udata access myarea // definitions go here #pragma udata to wrap your variable definitions. The C18 compiler (I don't think it works on PIC16's) uses the term 'access' to mean the faster access ram in bank 0. Read the C18 compiler manual and look for those terms. Jon
Reply by ●September 20, 20072007-09-20
On 2007-09-20, Rich Walker <rw@shadowrobot.com> wrote:> CBFalconer <cbfalconer@yahoo.com> writes: > >> Chris Hills wrote: >>> 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. >> >> Yes it is. Try just section 5.2.4.1 of the C99 standard. For a >> starter. > > Isn't this the "we're assuming you've got 512KB of ram on the target" > section?Yes, thought it's not quite that severe. But the fact that a device isn't large enough to hold a 4095 character string literal doesn't mean it can't run conforming C programs. It just means that it can't run *all* conforming C programs. -- John W. Temples, III
Reply by ●September 20, 20072007-09-20
John Temples wrote:> Rich Walker <rw@shadowrobot.com> wrote: >> CBFalconer <cbfalconer@yahoo.com> writes: >>> Chris Hills wrote: >>>> 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. >>> >>> Yes it is. Try just section 5.2.4.1 of the C99 standard. For a >>> starter. >> >> Isn't this the "we're assuming you've got 512KB of ram on the >> target" section? > > Yes, thought it's not quite that severe. > > But the fact that a device isn't large enough to hold a 4095 > character string literal doesn't mean it can't run conforming C > programs. It just means that it can't run *all* conforming C > programs.No, but it does mean that you lose (at least some of) the primary advantage of standard C; knowing it will execute on all systems meeting the ISO standard. This is obviously not fatal, but the designer needs to be aware. -- 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
Reply by ●September 20, 20072007-09-20
On 2007-09-20, John Temples <usenet@xargs-spam.com> wrote:> But the fact that a device isn't large enough to hold a 4095 > character string literal doesn't mean it can't run conforming > C programs. It just means that it can't run *all* conforming > C programs.No platform can. -- Grant Edwards grante Yow! We have DIFFERENT at amounts of HAIR -- visi.com
Reply by ●September 21, 20072007-09-21
Walter Banks wrote:> 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. >Handling re-entrant and non-reentrant functions differently is what I'd expect of any 8051 (or other similar 8-bit cpu) compiler. Some compilers may need help from a keyword to identify re-entrant code - others can figure it out automatically. What I think Rich found strange was Chris' claim that "professional" compilers would not support recursive code at all. As you say, recursion is not much used in 8-bit systems - and if it is, it's probably a bad idea. But it's still part of the C standards, and I would expect any decent C compiler to support recursive functions if that's what the programmer gives them (as long as it does not mean all other code is hobbled with software stacks just in case they are called recursively). mvh., David> 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/ >
Reply by ●September 21, 20072007-09-21
FreeRTOS.org wrote:> "Peter Harrison" <peter_harrison@ntlworld.com> wrote in message > news:TnzIi.52037$rr5.17561@newsfe1-win.ntli.net... >> [heavily snipped] >> ---8<--- >> Chris Hills wrote: >>> In message <k62dnd33WY0IDmzbnZ2dnUVZ_tuonZ2d@giganews.com>, drwho >>> <drwho@mailinator.com> writes >>>> otherwise use GCC >>> Not a chance. >>> >> ---8<--- >> One of my maxims is "If you can't handle the answer - don't ask the >> question". So, with some trepidation I ask... >> >> Why not? What is the problem with GCC? >> >> There, I have done it now. >> >> Pete > > > For a start - there is no GCC implementation for the PIC18 that I am aware > of - although there is a good one for the PIC24 and dsPIC. >The original suggestion was to "use GCC with a real processor like and (sic) AVR, MSP, or ARM7".> You can search this group for posts by Chris to see his opinion on GCC. >Chris has been known to post on reflex whenever he sees the three letters "g", "c", and "c" together, at least in the context of small microcontrollers. Hence the reply apparently came *before* he'd read to the end of the sentence.
