Arm7 or Freescale Coldfire?

Did he give any specific examples ?

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

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

------------------------------------------------------

Roberto wrote:

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 :-)

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.

Nearly all modern ARM cores include a VIC (Vectored Interrupt Controller) of some sort.

But it's better than having only one vendor.

There are things I miss in ARM that Coldfire has ... but always in the peripheral mix.

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

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

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

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

------------------------------------------------------

Isaac Bosompem wrote:

Obviously it is unusual indeed, how many houses are there which do not need any software from outside to do their development.

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.

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

------------------------------------------------------

David Brown wrote:

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

We have a broad range of Coldfire development tools.

See

NetWorked coldfire

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

I'm also biased!

Paul Breed

CTO Netburner.

the main difference is IMO that BDM allows memory access without CPU intervention, IOW "non-intrusive".

BDM can save you an emulator.

There should be also "cheap" BDM interfaces.

Oliver

Can you clarify what CPU32 is ?

-jg

Sure, Jim, perhaps I should have done so at the beginning. CPU32 is the processor core found in the 683xx products of Motorola (now Freescale); most basically, it is a 68020 minus the bitfield instructions and perhaps some other things (I think they never had the coprocessor interface implemented although the related instructions do trap properly for emulation etc., all that by memory - I wrote the FPU emulation stuff about 10 years ago...).

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

It certainly can, and probably does most of the time. The PPC products also have an equivalent of the BDM, but it is accessed through the JTAG port (that is, there are command registers which you can use via JTAG without activating the boundary scan facilities), which would be better than BDM since it uses a standard cable; however, those registers are kept secret... BDM was publically specified for at least some parts of the CPU32 line, but apparently for control purposes nowadays they do not publish the JTAG accessible debug port features (for the PPC, they call it COP - whatever this was supposed to mean, I know I knew it once :-).

Dimiter (also known as "der Didi" .... :-)

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

Oliver Betz wrote:

Thank you for all the replies.

Since my next designs will involve Ethernet and Can I think I will choose Freescale with its new MCF5223x (ethernet MAC+PHY, CAN, onboard 128Kb or 256Kb flash, 32Kb ram)

Roberto

The ColdFire BDM gives access to the memory even while the CPU is running code, if that's what you mean. Yes, that's a very nice feature, which the original CPU32 BDM did not have.

Undoubtedly. I don't know if there are any emulators for the ColdFire, but I'd hate to have to buy one!

There are cheap BDM interfaces, but only the expensive ones give you real-time tracing (i.e., they track the timing of every executed instruction). With the cheap ones, you can start and stop execution, set breakpoints (hardware or software, including a few hardware data breakpoints), read and write registers and memory, etc. But only a high-end device will be able to give you an instruction backtrace after a breakpoint (something you can't do at all with jtag debugging solutions).

JTAG debuggers do not, in practice, use standard cables. For some reason, known only to those making money from selling JTAG debuggers for sometimes huge sums of money, every different CPU target has its own incompatible JTAG debugger, often several depending on your choice of debugging software.

The BDM is a better interface for debugging than JTAG, because it is specifically made for debugging, and has additional signals that JTAG does not. Thus Freescale's MPC5xx line of PPC-based microcontrollers have a BDM interface for debugging, and a JTAG interface for boundary scanning. I don't know about any other Freescale PPC devices.

The BDM is, as far as I know, fully publicly specified. Sometimes it is not always easy to understand the details of the information, but certainly for the ColdFire and the CPU32 BDM interfaces, I have not seen any indication of information being hidden or kept back. I know jtag debugging information is restricted for some processors (like the msp430 and the AVR), but I have no idea about jtag debugging of PPC cores.

If my memory serves me right, what Freescale call "COP" is what everyone else calls a watchdog (it stands for "Computer Operating Properly"), and has nothing to do with debugging. But I could well be mixing that up with another manufacturer.

mvh.,

David

The CPU32 also has a couple of additions compared to the 68020, such as a fast loop mode, and a bit more optimised division (the 68020 has a large hardware division unit - the CPU32 uses a microcode software loop, which turns out to be faster!). But basically it's the core used in most of Freescale/Motorola's 68k microcontrollers.

The ColdFire core is basically a completely new implementation of the same CPU32 instruction set and programmer's model. They dropped a few of the more expensive (in terms of hardware) addressing modes and opcodes, and produced a new implementation that is very much more efficient (in terms of power, space, and work per clock cycle). Later ColdFire cores have added functionality (including some of the instructions originally dropped).

mvh.,

David

I haven't heard anything about the pricing and availability of these chips yet, but they look *very* nice.

None of the newer ones (8xxx, 5xxx etc.) have separate BDM, all has gone JTAG - which is good enough an interface, my sole issue with it is the data secrecy. They claim to keep it secret because it would be a great support effort, which is of course nonsense. Some people do get enough data to make debugging equipment.

This is correct, I believe they introduced the term with the HC11 back in the 80-s. Or perhaps even earlier than the HC11 - anyone remember?

Well for reasons I do not remember (I am pretty sure I knew once, but I may be wrong on that :-) they call COP also the JTAG debug port, which is exactly the interface they keep secret.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

David Brown wrote: