On Fri, 16 Dec 2005 21:03:55 +1300, darkknight
<darkknight.21@gmail.com> wrote:
>
>
>Hi
>
>A colleague of mine is using MPLAB C compiler and is struggling with the
>saving of registers in ISRs. Apparently the compiler manual says you
>have to manually scan the assembler code generated by the compiler to
>work out what registers to save/restore in interrupt routines. His
>software is crashing and he appears to be struggling to solve the
>problem.
>
>Does anyone have any experience with this C compiler?
>
>Is there an easy way to determine what registers to save?
>
>Are there any more reliable C compilers for the PIC micro than MPLAB?
>
>Is the PIC micro tricky to use with lots of gotchas?
>
>TIA
You could also look at Knudsen Data's compiler http://www.bknd.com/
for the PIC. I've just come across this one, does anyone have any
experience of it?
Vic
Reply by Sergio Masci●December 18, 20052005-12-18
On Sun, 18 Dec 2005, Pete Fenelon wrote:
> John Temples <usenet@xargs-spam.com> wrote:
> > On 2005-12-17, Pete Fenelon <pete@fenelon.com> wrote:
> >> darkknight <darkknight.21@gmail.com> wrote:
> >>>
> >>> Do you have any idea which of IAR, HI-tech or CCS would be the most
> >>> reliable - trouble-free?
> >>
> >> IAR, by orders of magnitude. It's the only C compiler on PIC that is
> >> even *remotely* like using C on a more conventional micro. Expensive,
> >> but you get what you pay for. The code density isn't bad too these days.
> >
> > In what ways is IAR "orders of magnitude" better than Hi-Tech?
>
>
> ANSIness. Reentrancy (if you want it). Ability to declare "generic"
> pointers that can address data or code space. (OK, this leads to hideously
> inefficient code, but it means *you can construct platform-independent
> code and expect it to run on a PIC*.
Yes all ten lines of it - if you're lucky.
>Yes, it's inefficient relative
> to something designed specifically for a PIC's architecture,
That's such an understatement, it's like saying "a rocket is a little
beefed up compared to a kite".
>but in
> a world where systems are increasingly constructed from the output of
> code-generation tools, this is often very important.
It's a bit pointless if the generated code wont fit in a PIC or executes
too slowly.
Good code generation tools for embedded targets do exist. Relying on
tools "hacked" together by programmers (and I use the term VERY losely
here) that know nothing about embedded or realtime systems is a big
mistake. If you are using a tool that cannot take advatage of the
properties of a particular target, either get a new tool or hire someome
that can do the job properly.
>
> Hi-Tech is OK if you want something for developing "PIC applications"
> with; if you want to do "real programming"
So what anything else is not "real programming" ?
> that just happens to target
> the PIC, IAR is the only choice. CCS is... something that looks a bit
> like C.
On 2005-12-18, Pete Fenelon <pete@fenelon.com> wrote:
> John Temples <usenet@xargs-spam.com> wrote:
>> On 2005-12-17, Pete Fenelon <pete@fenelon.com> wrote:
>> In what ways is IAR "orders of magnitude" better than Hi-Tech?
>
> ANSIness. Reentrancy (if you want it). Ability to declare "generic"
> pointers that can address data or code space.
Hi-Tech has all of that except reentrancy (which I don't want). It
also has a reasonable code generator, which IAR did not in my last
evaluation. An application that generated 24K of code with Hi-Tech
generated 36K of code with IAR, and didn't even fit in the target's
32K of flash.
> *you can construct platform-independent
> code and expect it to run on a PIC*.
Do you feel that's not possible with Hi-Tech? I have no problems
doing it.
--
John W. Temples, III
Reply by Pete Fenelon●December 18, 20052005-12-18
John Temples <usenet@xargs-spam.com> wrote:
> On 2005-12-17, Pete Fenelon <pete@fenelon.com> wrote:
>> darkknight <darkknight.21@gmail.com> wrote:
>>>
>>> Do you have any idea which of IAR, HI-tech or CCS would be the most
>>> reliable - trouble-free?
>>
>> IAR, by orders of magnitude. It's the only C compiler on PIC that is
>> even *remotely* like using C on a more conventional micro. Expensive,
>> but you get what you pay for. The code density isn't bad too these days.
>
> In what ways is IAR "orders of magnitude" better than Hi-Tech?
ANSIness. Reentrancy (if you want it). Ability to declare "generic"
pointers that can address data or code space. (OK, this leads to hideously
inefficient code, but it means *you can construct platform-independent
code and expect it to run on a PIC*. Yes, it's inefficient relative
to something designed specifically for a PIC's architecture, but in
a world where systems are increasingly constructed from the output of
code-generation tools, this is often very important.
Hi-Tech is OK if you want something for developing "PIC applications"
with; if you want to do "real programming" that just happens to target
the PIC, IAR is the only choice. CCS is... something that looks a bit
like C.
pete
--
pete@fenelon.com "there's no room for enigmas in built-up areas"
Reply by jyaron●December 18, 20052005-12-18
stack based with re-entrancy
dyn mem alloc
Reply by John Temples●December 17, 20052005-12-17
On 2005-12-17, Pete Fenelon <pete@fenelon.com> wrote:
> darkknight <darkknight.21@gmail.com> wrote:
>>
>> Do you have any idea which of IAR, HI-tech or CCS would be the most
>> reliable - trouble-free?
>
> IAR, by orders of magnitude. It's the only C compiler on PIC that is
> even *remotely* like using C on a more conventional micro. Expensive,
> but you get what you pay for. The code density isn't bad too these days.
In what ways is IAR "orders of magnitude" better than Hi-Tech?
--
John W. Temples, III
Reply by Chris Hills●December 17, 20052005-12-17
In article <m0p0od.4cq.ln@fenelon.com>, Pete Fenelon <pete@fenelon.com>
writes
>darkknight <darkknight.21@gmail.com> wrote:
>>
>> Do you have any idea which of IAR, HI-tech or CCS would be the most
>> reliable - trouble-free?
>
>IAR, by orders of magnitude. It's the only C compiler on PIC that is
>even *remotely* like using C on a more conventional micro. Expensive,
>but you get what you pay for. The code density isn't bad too these days.
>
>pete
Also they support the 12/16/17 18 and dsPIC
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by Pete Fenelon●December 17, 20052005-12-17
darkknight <darkknight.21@gmail.com> wrote:
>
> Do you have any idea which of IAR, HI-tech or CCS would be the most
> reliable - trouble-free?
IAR, by orders of magnitude. It's the only C compiler on PIC that is
even *remotely* like using C on a more conventional micro. Expensive,
but you get what you pay for. The code density isn't bad too these days.
pete
--
pete@fenelon.com "there's no room for enigmas in built-up areas"
Reply by Leon●December 17, 20052005-12-17
where I worked some years ago we got the Microchip C compiler. It was
unusable because of all the bugs so we got the Hi-tech compiler. It was
very good, apart from one or two problems that we had to get round.
Leon
Reply by darkknight●December 17, 20052005-12-17
On Sat, 17 Dec 2005 02:59:20 GMT, Robert Scott wrote:
>On Fri, 16 Dec 2005 21:03:55 +1300, darkknight
><darkknight.21@gmail.com> wrote:
>
>>A colleague of mine is using MPLAB C compiler and is struggling with the
>>saving of registers in ISRs. Apparently the compiler manual says you
>>have to manually scan the assembler code generated by the compiler to
>>work out what registers to save/restore in interrupt routines...
>
[snip]
>
>The CCS compiler enforces the division of automatic variables in ISRs
>and the main program only if you use the "managed" version of the
>ISRs. That's where you let the CCS library routines handle the
>interrupt, save the registers, and check the various interrupt flags
>for any interrupts that are currently enabled. But if you choose to
>bypass the "managed" version of ISR handling and do your own saving,
>restoring, and interrupt case handling, then you better not use any
>automatic variables in your ISR. I don't know if this protection
>extends to subroutines called from within the ISR. To be safe, keep
>your ISRs so simple that you don't call subroutines and you don't use
>automatic variables.
Thanks everyone. Unfortunately the interrupt routines are a little
complex by necessity.
I get the feeling that for reliability, the IAR, Hi-tech or CCS
compilers would be a better choice than microchip mplab compiler because
the microchip compiler still has a long list of outstanding issues and
the version that supports automatic saving of context was released only
a couple of months ago (it seems my colleague is not using it so we
will at least upgrade to that).
Do you have any idea which of IAR, HI-tech or CCS would be the most
reliable - trouble-free?
Graeme