Arm7 or Freescale Coldfire?

Started by Roberto April 3, 2006
I want to upgrade from 8 bit to 32 bit microcontrollers.
Which is the best platform to invest on?
(I mean in terms of code portability/devices offer/tool reuse/long term
device availability)

ARM7 seems to be a good platform...
Many company are proposing low cost ARM7 microcontrollers:
*) they (obviously) share the same instruction set and core specific
behaviours (i.e. cpu states...)
*) you only need to buy a compiler and a jtag interface (or without paying
anything: gcc/gdb + homemade parallel port jtag interface)

BUT:
Arm7 core seems to have serious limitations:
*) slow on pin i/o manipulation (there are proprietaty solutions to reduce
this limit)
*) interrupts handling is poor and vectorisation should be done in software
(there are proprietaty solutions to reduce this limit)
*) every manufacturer integrates its own peripherals so NO code portability
among different vendors.
*) current mass produced devices have few peripherals (i.e. Atmel is
delaying AT91SAM7X with Ethernet, CAN and USB, Philips will present new
devices this year...)
*) many devices are quite new products so they have many errata

Do you agree with my analysis?

Recently I was visited by a Freescale guy.
He told me:
*) Freescale offers a really BROAD range of devices from 10MIPS to over
400MIPS.
*) Core (V2) is more powerful than Arm7 at the same clock speed.
*) Vectored interrupts for all sources
*) Rich set of peripherals, from years. (I mean Can, ethernet, usb..)
*) Best debug capabilities than ARM7 core (recent V2 devices have 4 hw
breakpoints and trace module is always present, ARM7 have 2 hw breakpoints,
trace module isn't always implemented)
*) the prices are quite the same than Arm7 devices (for high end devices)
*) in the market there are more low end ARM-based devices. Freescale is
planning for low cost 32bit integrated devices to cover this lack

Do you agree with his analisys?
If someone of you is using ColdFire devices, what do you think about them?

Thank You,
Roberto


Roberto wrote:

> I want to upgrade from 8 bit to 32 bit microcontrollers. > Which is the best platform to invest on? > (I mean in terms of code portability/devices offer/tool reuse/long term > device availability) > > ARM7 seems to be a good platform... > Many company are proposing low cost ARM7 microcontrollers: > *) they (obviously) share the same instruction set and core specific > behaviours (i.e. cpu states...) > *) you only need to buy a compiler and a jtag interface (or without paying > anything: gcc/gdb + homemade parallel port jtag interface) > > BUT: > Arm7 core seems to have serious limitations: > *) slow on pin i/o manipulation (there are proprietaty solutions to reduce > this limit) > *) interrupts handling is poor and vectorisation should be done in software > (there are proprietaty solutions to reduce this limit) > *) every manufacturer integrates its own peripherals so NO code portability > among different vendors. > *) current mass produced devices have few peripherals (i.e. Atmel is > delaying AT91SAM7X with Ethernet, CAN and USB, Philips will present new > devices this year...) > *) many devices are quite new products so they have many errata > > Do you agree with my analysis? > > Recently I was visited by a Freescale guy. > He told me: > *) Freescale offers a really BROAD range of devices from 10MIPS to over > 400MIPS. > *) Core (V2) is more powerful than Arm7 at the same clock speed. > *) Vectored interrupts for all sources > *) Rich set of peripherals, from years. (I mean Can, ethernet, usb..) > *) Best debug capabilities than ARM7 core (recent V2 devices have 4 hw > breakpoints and trace module is always present, ARM7 have 2 hw breakpoints, > trace module isn't always implemented) > *) the prices are quite the same than Arm7 devices (for high end devices) > *) in the market there are more low end ARM-based devices. Freescale is > planning for low cost 32bit integrated devices to cover this lack
Did he give any specific examples ?
> Do you agree with his analisys? > If someone of you is using ColdFire devices, what do you think about them?
It's a bit like asking 'What car should I buy ?" Why restrict yourself to these two ? : Infineon have Tricore, XC166, Atmel have the new AVR32, there is even the Rabbit 4000, and the PowerPC..... ARM9 with FLASH will be here soon too... Also, a design does not HAVE to use one processor. Two, or more is not uncommon. Or a Processor and a CPLD ? The best chip(s) is(are) the one(s) that fits your application, and budget! Start with the peripherals (including memory) and work backwards, and they tend to self-select. -jg
Roberto wrote:
> I want to upgrade from 8 bit to 32 bit microcontrollers. > Which is the best platform to invest on? > (I mean in terms of code portability/devices offer/tool reuse/long term > device availability) > > ARM7 seems to be a good platform... > Many company are proposing low cost ARM7 microcontrollers: > *) they (obviously) share the same instruction set and core specific > behaviours (i.e. cpu states...) > *) you only need to buy a compiler and a jtag interface (or without paying > anything: gcc/gdb + homemade parallel port jtag interface) > > BUT: > Arm7 core seems to have serious limitations: > *) slow on pin i/o manipulation (there are proprietaty solutions to reduce > this limit) > *) interrupts handling is poor and vectorisation should be done in software > (there are proprietaty solutions to reduce this limit) > *) every manufacturer integrates its own peripherals so NO code portability > among different vendors. > *) current mass produced devices have few peripherals (i.e. Atmel is > delaying AT91SAM7X with Ethernet, CAN and USB, Philips will present new > devices this year...) > *) many devices are quite new products so they have many errata > > Do you agree with my analysis? > > Recently I was visited by a Freescale guy. > He told me: > *) Freescale offers a really BROAD range of devices from 10MIPS to over > 400MIPS. > *) Core (V2) is more powerful than Arm7 at the same clock speed. > *) Vectored interrupts for all sources > *) Rich set of peripherals, from years. (I mean Can, ethernet, usb..) > *) Best debug capabilities than ARM7 core (recent V2 devices have 4 hw > breakpoints and trace module is always present, ARM7 have 2 hw breakpoints, > trace module isn't always implemented) > *) the prices are quite the same than Arm7 devices (for high end devices) > *) in the market there are more low end ARM-based devices. Freescale is > planning for low cost 32bit integrated devices to cover this lack > > Do you agree with his analisys? > If someone of you is using ColdFire devices, what do you think about them? > > Thank You, > Roberto >
ColdFires are also supported by a range of compilers and debuggers, ranging from high-end commercial toolkits to gcc/gdb/parallel port debugger setups. In fact, they tools are directly comparable to the ARM tools - few of the big names make tools for one but not for the other. Debugging is normally done using the BDM interface rather than JTAG (some ColdFires have a JTAG interface, but that's mainly for board connectivity testing rather than debugging). BDM is similar to JTAG in many ways, but a bit more efficient since it is designed specifically for debugging. If your budget stretches to high-end tools, the BDM interface can be used for real-time debugging. ColdFires are available in a range of speeds, depending on the core used. Small devices use the V2 core, which (AFAIK) is directly comparable to the ARM7. I don't know how it compares at the same clock speed (I'd get an independent opinion from someone who has used both - I've just used ColdFires), but I don't think ARM7 cores can match the clock speeds of some of the V2 ColdFires (150 MHz for the 523x family). Moving up in speed and power, the V3 and V4 cores add things like superscaling and MMU, and the devices typically have DDR interfaces and the like. I'd guess that's similar to moving up to Arm9 and Arm11. Freescale have for some time been missing small, cheap ColdFire devices to compete with the small Arm7 devices - that has now changed (or is being changed - you'll have to check with the Freescale website or your Freescale guy for details). Overall, the ColdFire is a very, very nice architecture (where the Arm is merely "nice"), and these are good devices. Much of your choice boils down to whether you prefer a single, solid supplier (Freescale is not known for dropping existing parts unexpectedly, for example), or the possibility of multiple suppliers (though no two Arm suppliers provide identical chips, so only the core itself has multiple sources). We chose ColdFires after a history of using Motorola 68332, and I've seen no reason as yet to jump to Arm. However, I'd have a hard time arguing that developers with lots of Arm experience should jump to ColdFire. So look at both :-)
> I want to upgrade from 8 bit to 32 bit microcontrollers. > Which is the best platform to invest on?
The real choice you should be considering is Power PC vs. the rest. Years ago I had to switch from CPU32 to something newer and I considered the Coldfire, V4 was on its way to become soon available. All my code (between 10 and 15 megabytes of source text at that time, IIRC) was written in CPU32 assembly (with many environmental extensions) and it looked like the Coldfire would have been the closest option - but after a closer look it became obvious that I would have to do a lot of emulation because of the unsupported address modes etc. So I bit the bullet and switched to the Power PC - and I have not regretted that for a minute. I wrote an assembler (or is it a compiler?) which produced PPC object code out of my CPU32 sources, added some new features (now I call it VPA... Virtual Processor Assembler), and it is a really powerful tool along with the entire DPS environment. The emulated CPU32 code - with no optimisation at all, that is, maintaining all the CCR modifications wherever necessary and wherever not necessary - is 3.5 times longer than the original CPU32 code - a negligible price to pay for all that. Several years later, with much more code written no longer backwards CPU32 compatible, dps.syst is about 100 kilobytes - this is the kernel, with VM/MMU, file system, scheduler etc. - the OS, basically speaking - then there is the graphics interface support which is another 130 k or so, with al the window, off-screen buffer, drawing primitives etc. support. Hey, I got a bit carried away - sorry, I'll leave it unedited though, someone might be curious enough to read that. My advice would be in favour of the PPC - more than a single manufacturer, by far the best architecture from a technical point of view I know of (not that ARM or Coldfire are bad, PPC is just ages ahead), a clear migration path 32 -> 64 bit which is already being exploited, lots of peripherals and devices (just check the Freescale site; then the AMCC site; then IBM; and then even Xilinx have FPGAs with PPC cores inside). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ Roberto wrote:
> I want to upgrade from 8 bit to 32 bit microcontrollers. > Which is the best platform to invest on? > (I mean in terms of code portability/devices offer/tool reuse/long term > device availability) > > ARM7 seems to be a good platform... > Many company are proposing low cost ARM7 microcontrollers: > *) they (obviously) share the same instruction set and core specific > behaviours (i.e. cpu states...) > *) you only need to buy a compiler and a jtag interface (or without paying > anything: gcc/gdb + homemade parallel port jtag interface) > > BUT: > Arm7 core seems to have serious limitations: > *) slow on pin i/o manipulation (there are proprietaty solutions to reduce > this limit) > *) interrupts handling is poor and vectorisation should be done in software > (there are proprietaty solutions to reduce this limit) > *) every manufacturer integrates its own peripherals so NO code portability > among different vendors. > *) current mass produced devices have few peripherals (i.e. Atmel is > delaying AT91SAM7X with Ethernet, CAN and USB, Philips will present new > devices this year...) > *) many devices are quite new products so they have many errata > > Do you agree with my analysis? > > Recently I was visited by a Freescale guy. > He told me: > *) Freescale offers a really BROAD range of devices from 10MIPS to over > 400MIPS. > *) Core (V2) is more powerful than Arm7 at the same clock speed. > *) Vectored interrupts for all sources > *) Rich set of peripherals, from years. (I mean Can, ethernet, usb..) > *) Best debug capabilities than ARM7 core (recent V2 devices have 4 hw > breakpoints and trace module is always present, ARM7 have 2 hw breakpoints, > trace module isn't always implemented) > *) the prices are quite the same than Arm7 devices (for high end devices) > *) in the market there are more low end ARM-based devices. Freescale is > planning for low cost 32bit integrated devices to cover this lack > > Do you agree with his analisys? > If someone of you is using ColdFire devices, what do you think about them? > > Thank You, > Roberto
On Mon, 3 Apr 2006 10:43:37 +0200, "Roberto"
<roberto.darioREM0VETH1S@yahoo.it> wrote:

>BUT: >Arm7 core seems to have serious limitations: >*) slow on pin i/o manipulation (there are proprietaty solutions to reduce >this limit)
This is an implementation issue. It was a problem on early Philips LPC2xxx devices, but is fixed on later ones. A pin change can be as fast as a write to zero wait-state RAM.
>*) interrupts handling is poor and vectorisation should be done in software >(there are proprietaty solutions to reduce this limit)
Nearly all modern ARM cores include a VIC (Vectored Interrupt Controller) of some sort.
>*) every manufacturer integrates its own peripherals so NO code portability >among different vendors.
But it's better than having only one vendor.
>*) current mass produced devices have few peripherals (i.e. Atmel is >delaying AT91SAM7X with Ethernet, CAN and USB, Philips will present new >devices this year...)
There are things I miss in ARM that Coldfire has ... but always in the peripheral mix.
>*) many devices are quite new products so they have many errata > >Do you agree with my analysis?
We wen ARM rather than Coldfire for our own hardware for a variety of reasons, and single source was one of them, but the Coldfire 5282 is *very* attractive device. If you have a lot of existing 68xxx/CPU32 code, the transition will probably be easier. Otherwise, it depends on the peripheral mix you need. If you need CAN and Ethernet, Coldfire may be the answer, especially if you do not need extensive hardware filtering. Since most internal Ethernet solutions need an external PHY, the distinction and cost difference in using an external single-chip MAC/PHY is not significant except in very high volumes. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
Didi wrote:
<..snip..>
> So I bit the bullet and switched to the Power PC - and I have not > regretted that for a minute. I wrote an assembler (or is it a > compiler?) > which produced PPC object code out of my CPU32 sources, added > some new features (now I call it VPA... Virtual Processor Assembler), > and it is a really powerful tool along with the entire DPS environment.
<..snip..>
> Dimiter > > ------------------------------------------------------ > Dimiter Popoff Transgalactic Instruments > > http://www.tgi-sci.com > ------------------------------------------------------
Do you have the source to that assembler and are you willing to share it? I am looking into writing an assembler as well, I have got a good source and would like a multitude of sources to look at. -Isaac
Didi wrote:
>> I want to upgrade from 8 bit to 32 bit microcontrollers. >> Which is the best platform to invest on? > > The real choice you should be considering is Power PC vs. the > rest. > Years ago I had to switch from CPU32 to something newer and > I considered the Coldfire, V4 was on its way to become soon > available. > All my code (between 10 and 15 megabytes of source text at that time, > IIRC) was written in CPU32 assembly (with many environmental > extensions) and it looked like the Coldfire would have been > the closest option - but after a closer look it became obvious > that I would have to do a lot of emulation because of the unsupported > address modes etc. > So I bit the bullet and switched to the Power PC - and I have not > regretted that for a minute. I wrote an assembler (or is it a > compiler?) > which produced PPC object code out of my CPU32 sources, added > some new features (now I call it VPA... Virtual Processor Assembler), > and it is a really powerful tool along with the entire DPS environment. > The emulated CPU32 code - with no optimisation at all, that is, > maintaining all the CCR modifications wherever necessary and > wherever not necessary - is 3.5 times longer than the original > CPU32 code - a negligible price to pay for all that. Several years > later, > with much more code written no longer backwards CPU32 > compatible, dps.syst is about 100 kilobytes - this is the kernel, with > VM/MMU, file system, scheduler etc. - the OS, basically speaking - then > there is the graphics interface support which is another 130 k or so, > with al the window, off-screen buffer, drawing primitives etc. support. > Hey, I got a bit carried away - sorry, I'll leave it unedited though, > someone might be curious enough to read that. > My advice would be in favour of the PPC - more than a single > manufacturer, by far the best architecture from a technical point of > view I know of (not that ARM or Coldfire are bad, PPC is just > ages ahead), a clear migration path 32 -> 64 bit which is already > being exploited, lots of peripherals and devices (just check the > Freescale site; then the AMCC site; then IBM; and then even > Xilinx have FPGAs with PPC cores inside). > > Dimiter > > ------------------------------------------------------ > Dimiter Popoff Transgalactic Instruments > > http://www.tgi-sci.com > ------------------------------------------------------ >
I think your particular example is pretty unusual, and could hardly be used as a recommendation for others. Sometimes a tool that converts from one assembly to another, your "virtual processor assembler", can make sense - but it's very rare, and only suitable in the case when you have very large quantities of assembly software that you must use without change on a new platform, and even then it is only a stop-gap until a real maintainable solution is found. Hopefully the OP is not in this situation! As for your choice of going to the PPC instead of the ColdFire, I find it hard to understand. The ColdFire has something like 80-90% match at the assembly level with the 68k devices, and Motorola/Freescale have tools to convert the rest (combined with an emulation library for really obscure stuff). All your VPA work would be unnecessary using the ready-made tools. There may have been some mismatch in the operating modes (ColdFires have slightly different user/supervisor models from 68k devices), but I'd expect it to be closer than any corresponding PPC modes. The PPC architecture has it's strong points - being easy to understand, easy to use, and suitable for a small device as a step up from 8-bit are not among them. If the OP is used to the simplicity of devices such as the AVR or the 8051, but needs a bit more processing power, then a PPC-based micro would come as a very big shock. In itself, the PPC architecture is nice if you are thinking big - for example, the condition code system is much more scalable than in the ColdFire ISA. If you are thinking small to medium, however, the PPC is overly complex, especially at an assembly level. Migration to 64 bits is possible, but hardly "clear" - an address bus that runs from A31 "up" to A-8 is not exactly pretty, and it's hardly in the OP's sights as a step up from 8-bit. Finally, there's the question of suitable microcontrollers based on the PPC core. About the simplest and cheapest are the Freescale MPC5xx line. These are powerful devices, and well suited to some applications, but they in terms of ease-of-learning they are not in the same class as a small ColdFire or Arm. David
> > > Roberto wrote: >> I want to upgrade from 8 bit to 32 bit microcontrollers. >> Which is the best platform to invest on? >> (I mean in terms of code portability/devices offer/tool reuse/long term >> device availability) >> >> ARM7 seems to be a good platform... >> Many company are proposing low cost ARM7 microcontrollers: >> *) they (obviously) share the same instruction set and core specific >> behaviours (i.e. cpu states...) >> *) you only need to buy a compiler and a jtag interface (or without paying >> anything: gcc/gdb + homemade parallel port jtag interface) >> >> BUT: >> Arm7 core seems to have serious limitations: >> *) slow on pin i/o manipulation (there are proprietaty solutions to reduce >> this limit) >> *) interrupts handling is poor and vectorisation should be done in software >> (there are proprietaty solutions to reduce this limit) >> *) every manufacturer integrates its own peripherals so NO code portability >> among different vendors. >> *) current mass produced devices have few peripherals (i.e. Atmel is >> delaying AT91SAM7X with Ethernet, CAN and USB, Philips will present new >> devices this year...) >> *) many devices are quite new products so they have many errata >> >> Do you agree with my analysis? >> >> Recently I was visited by a Freescale guy. >> He told me: >> *) Freescale offers a really BROAD range of devices from 10MIPS to over >> 400MIPS. >> *) Core (V2) is more powerful than Arm7 at the same clock speed. >> *) Vectored interrupts for all sources >> *) Rich set of peripherals, from years. (I mean Can, ethernet, usb..) >> *) Best debug capabilities than ARM7 core (recent V2 devices have 4 hw >> breakpoints and trace module is always present, ARM7 have 2 hw breakpoints, >> trace module isn't always implemented) >> *) the prices are quite the same than Arm7 devices (for high end devices) >> *) in the market there are more low end ARM-based devices. Freescale is >> planning for low cost 32bit integrated devices to cover this lack >> >> Do you agree with his analisys? >> If someone of you is using ColdFire devices, what do you think about them? >> >> Thank You, >> Roberto >
> Do you have the source to that assembler and are you willing to share > it?
The sources are - just looked at it - 861536 bytes in 46 files. This is the version which assembles(compiles) itself, I also have a CPU32 version which was the starting point. It is a pretty complex piece of software, relies on the linker for some LSW/MSW knowledge etc. It is very little dependent on the OS - just for file I/O. I have yet to consider how and when to make all that DPS stuff available, which part to give for free and which to make a living on, so perhaps it is worth to hold your breath for a while until later this year, when I plan to make a complete MPC5200 based version available, where you will be able to run everyting, provided you have a HDD attached to the 5200 and a memory-mapped display controller in PCI space. I am contemplating making the whole stuff available for free for beginners and at some cost after some sales have been realized by the user, it is all still TBD. :-) Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ Isaac Bosompem wrote:
> Didi wrote: > <..snip..> > > So I bit the bullet and switched to the Power PC - and I have not > > regretted that for a minute. I wrote an assembler (or is it a > > compiler?) > > which produced PPC object code out of my CPU32 sources, added > > some new features (now I call it VPA... Virtual Processor Assembler), > > and it is a really powerful tool along with the entire DPS environment. > <..snip..> > > Dimiter > > > > ------------------------------------------------------ > > Dimiter Popoff Transgalactic Instruments > > > > http://www.tgi-sci.com > > ------------------------------------------------------ > > > Do you have the source to that assembler and are you willing to share > it? > > I am looking into writing an assembler as well, I have got a good > source and would like a multitude of sources to look at. > > -Isaac
> I think your particular example is pretty unusual, and could hardly be > used as a recommendation for others.
Obviously it is unusual indeed, how many houses are there which do not need any software from outside to do their development.
> Sometimes a tool that converts > from one assembly to another, your "virtual processor assembler", can > make sense - but it's very rare, and only suitable in the case when you > have very large quantities of assembly software that you must use > without change on a new platform, and even then it is only a stop-gap > until a real maintainable solution is found.
It is very rare indeed, and it is quite maintainable. It is by far not just an assembler, it is an entire environment you live in. Times more efficient than existing C based alternatives.
> The PPC architecture has it's strong points - being easy to understand, > easy to use, and suitable for a small device as a step up from 8-bit are > not among them. > ....
Having written many megabytes of sources for both CPU32 and PPC, I can say that PPC is beyond reach for competing architectures nowadays. Using its native assembly makes no sense at all, if you don't have VPA you are stuck with C or other HLL. And I agree it may be overkill for many applications, and will likely be for another while until power consumption drops by another factor of 10 or so - perhaps not so far in the future. After all, the OP can make his own judgement, we can help only by sharing our experiences. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ David Brown wrote:
> Didi wrote: > >> I want to upgrade from 8 bit to 32 bit microcontrollers. > >> Which is the best platform to invest on? > > > > The real choice you should be considering is Power PC vs. the > > rest. > > Years ago I had to switch from CPU32 to something newer and > > I considered the Coldfire, V4 was on its way to become soon > > available. > > All my code (between 10 and 15 megabytes of source text at that time, > > IIRC) was written in CPU32 assembly (with many environmental > > extensions) and it looked like the Coldfire would have been > > the closest option - but after a closer look it became obvious > > that I would have to do a lot of emulation because of the unsupported > > address modes etc. > > So I bit the bullet and switched to the Power PC - and I have not > > regretted that for a minute. I wrote an assembler (or is it a > > compiler?) > > which produced PPC object code out of my CPU32 sources, added > > some new features (now I call it VPA... Virtual Processor Assembler), > > and it is a really powerful tool along with the entire DPS environment. > > The emulated CPU32 code - with no optimisation at all, that is, > > maintaining all the CCR modifications wherever necessary and > > wherever not necessary - is 3.5 times longer than the original > > CPU32 code - a negligible price to pay for all that. Several years > > later, > > with much more code written no longer backwards CPU32 > > compatible, dps.syst is about 100 kilobytes - this is the kernel, with > > VM/MMU, file system, scheduler etc. - the OS, basically speaking - then > > there is the graphics interface support which is another 130 k or so, > > with al the window, off-screen buffer, drawing primitives etc. support. > > Hey, I got a bit carried away - sorry, I'll leave it unedited though, > > someone might be curious enough to read that. > > My advice would be in favour of the PPC - more than a single > > manufacturer, by far the best architecture from a technical point of > > view I know of (not that ARM or Coldfire are bad, PPC is just > > ages ahead), a clear migration path 32 -> 64 bit which is already > > being exploited, lots of peripherals and devices (just check the > > Freescale site; then the AMCC site; then IBM; and then even > > Xilinx have FPGAs with PPC cores inside). > > > > Dimiter > > > > ------------------------------------------------------ > > Dimiter Popoff Transgalactic Instruments > > > > http://www.tgi-sci.com > > ------------------------------------------------------ > > > > > I think your particular example is pretty unusual, and could hardly be > used as a recommendation for others. Sometimes a tool that converts > from one assembly to another, your "virtual processor assembler", can > make sense - but it's very rare, and only suitable in the case when you > have very large quantities of assembly software that you must use > without change on a new platform, and even then it is only a stop-gap > until a real maintainable solution is found. Hopefully the OP is not in > this situation! > > As for your choice of going to the PPC instead of the ColdFire, I find > it hard to understand. The ColdFire has something like 80-90% match at > the assembly level with the 68k devices, and Motorola/Freescale have > tools to convert the rest (combined with an emulation library for really > obscure stuff). All your VPA work would be unnecessary using the > ready-made tools. There may have been some mismatch in the operating > modes (ColdFires have slightly different user/supervisor models from 68k > devices), but I'd expect it to be closer than any corresponding PPC modes. > > The PPC architecture has it's strong points - being easy to understand, > easy to use, and suitable for a small device as a step up from 8-bit are > not among them. If the OP is used to the simplicity of devices such as > the AVR or the 8051, but needs a bit more processing power, then a > PPC-based micro would come as a very big shock. In itself, the PPC > architecture is nice if you are thinking big - for example, the > condition code system is much more scalable than in the ColdFire ISA. > If you are thinking small to medium, however, the PPC is overly complex, > especially at an assembly level. Migration to 64 bits is possible, but > hardly "clear" - an address bus that runs from A31 "up" to A-8 is not > exactly pretty, and it's hardly in the OP's sights as a step up from 8-bit. > > Finally, there's the question of suitable microcontrollers based on the > PPC core. About the simplest and cheapest are the Freescale MPC5xx > line. These are powerful devices, and well suited to some applications, > but they in terms of ease-of-learning they are not in the same class as > a small ColdFire or Arm. > > David > > > > > > > > > Roberto wrote: > >> I want to upgrade from 8 bit to 32 bit microcontrollers. > >> Which is the best platform to invest on? > >> (I mean in terms of code portability/devices offer/tool reuse/long term > >> device availability) > >> > >> ARM7 seems to be a good platform... > >> Many company are proposing low cost ARM7 microcontrollers: > >> *) they (obviously) share the same instruction set and core specific > >> behaviours (i.e. cpu states...) > >> *) you only need to buy a compiler and a jtag interface (or without paying > >> anything: gcc/gdb + homemade parallel port jtag interface) > >> > >> BUT: > >> Arm7 core seems to have serious limitations: > >> *) slow on pin i/o manipulation (there are proprietaty solutions to reduce > >> this limit) > >> *) interrupts handling is poor and vectorisation should be done in software > >> (there are proprietaty solutions to reduce this limit) > >> *) every manufacturer integrates its own peripherals so NO code portability > >> among different vendors. > >> *) current mass produced devices have few peripherals (i.e. Atmel is > >> delaying AT91SAM7X with Ethernet, CAN and USB, Philips will present new > >> devices this year...) > >> *) many devices are quite new products so they have many errata > >> > >> Do you agree with my analysis? > >> > >> Recently I was visited by a Freescale guy. > >> He told me: > >> *) Freescale offers a really BROAD range of devices from 10MIPS to over > >> 400MIPS. > >> *) Core (V2) is more powerful than Arm7 at the same clock speed. > >> *) Vectored interrupts for all sources > >> *) Rich set of peripherals, from years. (I mean Can, ethernet, usb..) > >> *) Best debug capabilities than ARM7 core (recent V2 devices have 4 hw > >> breakpoints and trace module is always present, ARM7 have 2 hw breakpoints, > >> trace module isn't always implemented) > >> *) the prices are quite the same than Arm7 devices (for high end devices) > >> *) in the market there are more low end ARM-based devices. Freescale is > >> planning for low cost 32bit integrated devices to cover this lack > >> > >> Do you agree with his analisys? > >> If someone of you is using ColdFire devices, what do you think about them? > >> > >> Thank You, > >> Roberto > >
We have a broad range of Coldfire development tools.

See

www.netburner.com
specifically:
Non Network coldfire:
http://www.netburner.com/products/core_modules/mod5213.html

NetWorked coldfire

http://www.netburner.com/products/core_modules/mod5270.html

I've been using the Coldfire sin 1998 and I love it.

I'm also biased!

Paul Breed

CTO Netburner.