>The underlying (hardware) architecture may well be simpler (and
>simple is always good) on the PICs, but that seen by the user when
>coding isn't.

> On an ARM7 or similar 32-bit MCU you can code
>in "pure" ANSI 'C', without having to worry about special keywords,
>attributes, special memory locations, etc. etc. To my mind, it's
>simpler if you can write code without being exposed to
>idiosyncrasies of the underlying hardware (and that's even before
>considering portability).

? I'm curious now, but AFAIK from the users point of view its just a C
program. I ported FreeRTOS.org to the PIC24 and dsPIC using only one C
extension, and that is GCC specific not PIC specific:

void __attribute__((__interrupt__)) _T1Interrupt( void )

I think many of the maths functions are just a matter of calling
pre-optimised library routines. I have not used it in anger however so am
happy to be corrected.

The PIC24 has a 'standard' architecture (not knowing how else to describe
it), unlike the PIC18 which is somewhat unique (putting it diplomatically).

Granted it is 16 bits rather than 32 bits, but again in a C program this
makes little difference to the C code although quite a difference to the
generated asm.

>the disadvantages of the rest of the
>architecture more than balance it out.

What disadvantages (other than those I have already stated)?

It makes me smile to think I'm defending the humble PIC, but the PIC24 and
dsPIC are PIC by name only, which is a shame - they should have been called
something that disassociates them from the PIC18.

I tend to use ARM7 myself mostly, but still think the PIC24 is a decent
processor.

Regards,
Richard.

+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC Start a New Thread

--- In l..., "FreeRTOS.org Info"
wrote:
>
> >The underlying (hardware) architecture may well be simpler (and
> >simple is always good) on the PICs, but that seen by the user when
> >coding isn't.
>
> > On an ARM7 or similar 32-bit MCU you can code
> >in "pure" ANSI 'C', without having to worry about special
keywords,
> >attributes, special memory locations, etc. etc. To my mind, it's
> >simpler if you can write code without being exposed to
> >idiosyncrasies of the underlying hardware (and that's even before
> >considering portability).
>
> ? I'm curious now, but AFAIK from the users point of view its
just a C
> program. I ported FreeRTOS.org to the PIC24 and dsPIC using only
one C
> extension, and that is GCC specific not PIC specific:
>
> void __attribute__((__interrupt__)) _T1Interrupt( void )
>
> I think many of the maths functions are just a matter of calling
> pre-optimised library routines. I have not used it in anger
however so am
> happy to be corrected.
>
> The PIC24 has a 'standard' architecture (not knowing how else to
describe
> it), unlike the PIC18 which is somewhat unique (putting it
diplomatically).
>
> Granted it is 16 bits rather than 32 bits, but again in a C
program this
> makes little difference to the C code although quite a difference
to the
> generated asm.
>
> >the disadvantages of the rest of the
> >architecture more than balance it out.
>
> What disadvantages (other than those I have already stated)?
>
> It makes me smile to think I'm defending the humble PIC, but the
PIC24 and
> dsPIC are PIC by name only, which is a shame - they should have
been called
> something that disassociates them from the PIC18.
>
> I tend to use ARM7 myself mostly, but still think the PIC24 is a
decent
> processor.

OK hands up: I haven't actually used the larger PICs and dsPIC for
anything more than a quick evaluation. I was going by the C30 User's
Guide, in particular the sections on differences from ANSI 'C' (more
special keywords than I think is healthy), and the run-time
environment, with its "near" and "far" memory, "psv windows" etc.
etc. Maybe you can write (non-trivial) 100% ANSI 'C' programs
without having to worry about such things, but it didn't look like
it at an initial look. If it is, then apologies for the rush to
judgment. Just shows you what a market education task Microchip is
up against...

Brendan. Start a New Thread

Hello Friends

For a heavy math project don't use DSPIC nor ARM go and use a DSP like the
TI TMS28xxx,TMS320C5,6xxx or Analog Blackfin

Whether you need only fast transfer and simple math data ARM7 is a very good
choice

For the DSPIC - please give me a brake, this chip will died sooner then you
think search Google for "DSPIC & PROJECT" and you will know the answer

All the best

J_I Start a New Thread