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.
LPC21xx vs PIC24/dsPIC
Started by ●December 29, 2006
Reply by ●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?
Why invest in a proprietary arch when the ARM is cheaper and universally
supported?
Which one is going to survive in the market place over the next 5-10 years?
Those are the questions I would have. I used to use pics, not anymore. All
I use now is ARM.
Hope that helps.
Chris.
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?
Why invest in a proprietary arch when the ARM is cheaper and universally
supported?
Which one is going to survive in the market place over the next 5-10 years?
Those are the questions I would have. I used to use pics, not anymore. All
I use now is ARM.
Hope that helps.
Chris.
Reply by ●December 29, 20062006-12-29
Em Sex 29 Dez 2006 08:46, s...@hotmail.com escreveu:
> 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?
> Why invest in a proprietary arch when the ARM is cheaper and universally
> supported?
> Which one is going to survive in the market place over the next 5-10 years?
>
> Those are the questions I would have. I used to use pics, not anymore.
> All I use now is ARM.
>
> Hope that helps.
>
> Chris.
Good for you.
I still use PICs for small circuits, when I need a few IOs and small firmware.
The smaller ARM I know have 28 pins and is only available in SMD footprints.
I am right now designing a circuit with LPC2105 because of RAM needs and
speed.
I think PIC24 is a bad try from Microchip. Its natural to try to offer a
better product, but design a new core is costly for Microchip, for the
compilers developers, and for the end users. IMHO PIC24 is not competitive
and Microchip will not obtain success wit them. And to make everything worst,
the price of the PIC18 lne is growing month after month. I really dont see a
bright future for Microchip.
To make the nightmare even worst for Microchip, Freescale small uC have
cheaper prices, better debug options, and all the footprints that Microchip
offers, and Texas is launching DIP versions of small MSP430.
There was a lack when Microchip lauched PIC16 on the market, and Microchip did
it very well. But that windows is past, and Microchip lost the history train.
As in Hitchhicker book, "so long, and thank you for the fishs" :)
> 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?
> Why invest in a proprietary arch when the ARM is cheaper and universally
> supported?
> Which one is going to survive in the market place over the next 5-10 years?
>
> Those are the questions I would have. I used to use pics, not anymore.
> All I use now is ARM.
>
> Hope that helps.
>
> Chris.
Good for you.
I still use PICs for small circuits, when I need a few IOs and small firmware.
The smaller ARM I know have 28 pins and is only available in SMD footprints.
I am right now designing a circuit with LPC2105 because of RAM needs and
speed.
I think PIC24 is a bad try from Microchip. Its natural to try to offer a
better product, but design a new core is costly for Microchip, for the
compilers developers, and for the end users. IMHO PIC24 is not competitive
and Microchip will not obtain success wit them. And to make everything worst,
the price of the PIC18 lne is growing month after month. I really dont see a
bright future for Microchip.
To make the nightmare even worst for Microchip, Freescale small uC have
cheaper prices, better debug options, and all the footprints that Microchip
offers, and Texas is launching DIP versions of small MSP430.
There was a lack when Microchip lauched PIC16 on the market, and Microchip did
it very well. But that windows is past, and Microchip lost the history train.
As in Hitchhicker book, "so long, and thank you for the fishs" :)
Reply by ●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.
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
> 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.
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
Reply by ●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
>
> 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 ●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
>
> 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 ●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.
+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC
>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.
+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC
Reply by ●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.
>>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 ●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.
>
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 ●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.
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.
