Reply by Brendan Murphy●December 29, 20062006-12-29
--- 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.
Reply by "FreeRTOS.org Info"●December 29, 20062006-12-29
>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:
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.
Reply by Brendan Murphy●December 29, 20062006-12-29
--- In l..., "FreeRTOS.org Info"
wrote: >
> >- IMO the big, big difference between them is the architecture
> >presented to the software: ARM7 with its simple address space and
> >easy support for full ANSI 'C' compilers (and there's a
choice
> >between them) wins out every time over the proprietary, limited PIC > >architecture.
>
> IMHO the architecture of the PIC24 and dsPIC is simpler than the ARM7. The > PIC18 on the other hand is a dog.
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).
Once the basic startup and interrupt dispatch has been set up when
you start working with ARM (and there's no doubt it is a steep
learning curve), you rarely have to look at it again, and can focus
on the problem you're trying to solve rather than having constantly
to worry about the CPU and memory architecture restrictions.
>
> Two points in the PIC24 and dsPIC that are not so friendly - 40bit
> accumulators and 24bit pointers. If you want a DSP thought these are the > type of things you come across, general
peculiarities. Pointer length are > transparent when using GCC (ie you don't have to
think about it). I suspect > (guess) the Microchip maths libraries also make the
40bit accumulator > transparent unless you really want to had tune a
routine.
>
There's no question the "DSP-lite" features of the dsPIC are good
for DSP work. However, IMO the disadvantages of the rest of the
architecture more than balance it out. You can do a reasonable
amount of DSP on an ARM7 without too much effort, and without having
to descend to assembler. If you need to do more, you're probably
better off with a real DSP.
Reply by Jason Morgan●December 29, 20062006-12-29
Hi,
You don't say if your application is cost sensitive. The LPC's use
floating point emulation, so compared to a floating point DSP or
even math co-processor are very slow indeed at floating point.
Really its down to the compiler optimisation. I have heard of
500kFLOPS at 50MHz for single precision using optimised (i.e. hand
coded assembler). Nothing to get excited about.
The main selling point of the LPC its its external flexible IO pin
architecture, not its maths performance. If you don't need IO pins,
perhaps you should consider an ARM with a math co-processor. Take a
look at the Intel PXA series.
If you want Philips/NXP, the LPC3100 would offer hardware floating
point as well as easy access to the the other interfaces you mention
and it is very fast indeed - 200MHz+
You could consider some of the TI DSPs, these have an ARM7 stitched
to a fixed point DSP.
Oh, BTW: I hate PICs. Ok, for an alarm system but useless as a
serious processor. For a simple micro I prefer the TI MSP430, now
that is much better - fast too, but still not floating point :(
Regards,
Jason.
--- In l..., "allsoft01a" wrote: >
> I am new to ARM cores and I need some help.
>
> I am working on a design for a new product and I am researching
> different micro-controllers. I am on the fence between the a
> PIC24/dsPIC or an LPC21xx.
>
> The application is heavy in math and communications:
> - 3 serial ports running MODBUS Slave.
> - 4ch 24bit ADC @ 2Khz on SPI
> - Floating Point math
> - upgrade option to Ethernet
>
> I have more experience with PIC products but I don't want that to
> cloud my judgment when looking at other products.
>
> Is there any benchmarks available for the math performance of the
> LPC21xx products?
>
> Does anyone have any experience with both products that could offer > some insight?
>
> Are there any better implementations of the ARM7 core besides the
> LPC family? AVR perhaps?
>
> Thanks for the help.
>
Reply by Michael Scott●December 29, 20062006-12-29
>>- IMO the big, big difference between them is the
architecture
>>presented to the software: ARM7 with its simple address space and
>>easy support for full ANSI 'C' compilers (and there's a
choice
>>between them) wins out every time over the proprietary, limited PIC
>>architecture.
>IMHO the architecture of the PIC24 and dsPIC is
simpler than the ARM7. The >PIC18 on the other hand is a dog.
>Two points in the PIC24 and dsPIC that are not so
friendly - 40bit
>accumulators and 24bit pointers. If you want a DSP thought these are the >type of things you come across, general peculiarities.
Pointer length are >transparent when using GCC (ie you don't have to
think about it). I suspect >(guess) the Microchip maths libraries also make the
40bit accumulator
>transparent unless you really want to had tune a routine.
>Regards,
>Richard.
Since I have used all of the above (and more), I'd add this... One of
the biggest differences, HUGH in my estimation, is that everything is 32
bit in the ARM7. That just makes things (math, timing, etc) so much
simpler now a days. The other big difference is using the VIC and its
inherent features, makes RTOS, (either free, purchased or hand built) a
breeze.
Like most things in life, each one has its benefits and drawbacks, ever
time I think we can settle on just one family, I find a compelling
design reason to use something from another vendor, evolution at work I
guess.
Reply by "FreeRTOS.org Info"●December 29, 20062006-12-29
>- IMO the big, big difference between them is the
architecture
>presented to the software: ARM7 with its simple address space and
>easy support for full ANSI 'C' compilers (and there's a
choice
>between them) wins out every time over the proprietary, limited PIC
>architecture.
IMHO the architecture of the PIC24 and dsPIC is simpler than the ARM7. The
PIC18 on the other hand is a dog.
Two points in the PIC24 and dsPIC that are not so friendly - 40bit
accumulators and 24bit pointers. If you want a DSP thought these are the
type of things you come across, general peculiarities. Pointer length are
transparent when using GCC (ie you don't have to think about it). I
suspect
(guess) the Microchip maths libraries also make the 40bit accumulator
transparent unless you really want to had tune a routine.
Reply by Brendan Murphy●December 29, 20062006-12-29
--- In l..., "allsoft01a" wrote: >
> I am new to ARM cores and I need some help.
>
> I am working on a design for a new product and I am researching
> different micro-controllers. I am on the fence between the a
> PIC24/dsPIC or an LPC21xx.
>
> The application is heavy in math and communications:
> - 3 serial ports running MODBUS Slave.
> - 4ch 24bit ADC @ 2Khz on SPI
> - Floating Point math
> - upgrade option to Ethernet
>
> I have more experience with PIC products but I don't want that to
> cloud my judgment when looking at other products.
>
> Is there any benchmarks available for the math performance of the
> LPC21xx products?
>
> Does anyone have any experience with both products that could offer > some insight?
>
> Are there any better implementations of the ARM7 core besides the
> LPC family? AVR perhaps?
>
> Thanks for the help.
>
A few general points:
- PICs are great for systems that need simple control functions;
where low-pin counts are needed and for their minimal requirement
for support ICs/components; for the easy availability of low cost
tools, plenty of examples etc.
- It's easy enough to do comparisons between the two families in
terms of peripherals etc. PICs have a big head start in terms of the
diversity of options available, but the NXP parts are rapidly
catching up
- IMO the big, big difference between them is the architecture
presented to the software: ARM7 with its simple address space and
easy support for full ANSI 'C' compilers (and there's a choice
between them) wins out every time over the proprietary, limited PIC
architecture. That's before you consider the much higher clock rates
available (though this can be a negative due to the increased
current consumption as the speed goes up). As the complexity of the
control requirements go up, this advantage will become more and more
important over time.
- As for other general purpose ARM7 parts, there are other families,
but none that I've seen that have any compelling advantage over the
LPC parts, which has a particularly high performance when it runs
from internal flash
- If performance is an issue for you, I'd highly recommend getting a
couple of starter dev kits (one for each architecture) and doing
some of your own benchmarks. This topic has come up a few times, and
invariably generates more heat than light (you can get the numbers
to prove anything), but if you do your own benchmarks geared towards
your own application you'll get the most valid results. I think it's
a safe bet that the ARM will win out, though.
- One final (minor) point: why do you need floating point? if
performance is a real issue, I'd look at using fixed point, as
neither architecture has a built-in floating point unit. It's a bit
more work, but you can do a huge amount in fixed point, and it'll
always be much faster on parts that don't have h/w support for
floating point.
Brendan
Reply by kravnus●December 29, 20062006-12-29
--- In l..., "allsoft01a" wrote: >
> I am new to ARM cores and I need some help.
>
> I am working on a design for a new product and I am researching
> different micro-controllers. I am on the fence between the a
> PIC24/dsPIC or an LPC21xx.
>
> The application is heavy in math and communications:
> - 3 serial ports running MODBUS Slave.
> - 4ch 24bit ADC @ 2Khz on SPI
> - Floating Point math
> - upgrade option to Ethernet
All of these options should be referred to the product selector for
the given manufacturer. Btw, how much fp are you going to do in your
application? If it is a lot you should move to an ARM CPU.
>
> I have more experience with PIC products but I don't want that to
> cloud my judgment when looking at other products.
> Try to repost this on the piclist.
> Is there any benchmarks available for the math
performance of the
> LPC21xx products?
>
Unfortunately there is NO hard evidence until you do it. Use a C
compiler to compare between chips. MOST maths performance tend to fall
into ARM favour due to the clock speed.
> Does anyone have any experience with both products
that could offer
> some insight?
>
> Are there any better implementations of the ARM7 core besides the
> LPC family? AVR perhaps?
> AVR has better support for C compilers but the floating point
subroutine is big since the compiler embeds the subroutine for the
given operation.
John
Reply by "FreeRTOS.org Info"●December 29, 20062006-12-29
>I designed with a lot of PICs over the years. They
were good 8 bit MCUs.
> But the speed of an ARM7 is completely in a different league than the
> PICs.
> Why buy a 16 bit MCU when you can have a faster 32 bit for the price of an
> 8
> bit?
I don't think a forum dedicated to people that are using ARM is the best
place for the OP to ask this question.
I don't know about the relative performance between dsPIC and ARM7, but the
dsPIC is a much more specialised device and I would not be surprised if it
stood its ground in *some* tight specialised applications.
Having been put off all things Microchip by the PIC18 it took me a long time
to come around to look at the PIC24 and dsPIC. When I eventually did so I
was very pleasantly surprised. They are nice devices.
> Why invest in a proprietary arch when the ARM is
cheaper and universally
> supported?
In the interest of balance:
I used GCC for PIC24 and dsPIC. MPLAB provides a full simulator (not just a
core simulator) and does not cost anything. Example code, application
notes, drivers, etc, galore are available for download. Their are offices
in many countries. Their parts are easy to come by. Etc. > Which one is going to survive in the market place
over the next 5-10
> years?
Neither - the Cortex-M3 will beat both (being deliberately mischievous ;-)
> I use now is ARM.
I use the best processor for the application in hand. More often than not
this is an ARM.
