Used interrupts on both 68k & PIC, want 68k w/onboard memory & JTAG/BDM
2Penny
Gentlemen -
The subject line says it all. I've just started looking
around for a 68k-ish creature with some PIC-like features
that might have popped up recently. Has anyone here seen
this beast? Where?
2Penny (my 2 cents worth)
Didi
Well not sure what PIC-like features means, but if you are after
a tiny MCU with a reasonably powerful 68k (50 MHz), have a
look at the coldfire line, the MCF51QE (IIRC the name) is
available and there are another few similar ones promised.
Didi
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
larwe
> The subject line says it all. I've just started looking
> around for a 68k-ish creature with some PIC-like features
> that might have popped up recently. Has anyone here seen
It's called ColdFire now. Look at Freescale's website for all the data
you could hope to get - there are plenty of CF parts with on-chip
flash and RAM and all of them have embedded debug (JTAG).
I can give you gratis an EVB with a ColdFire micro on it, asking only
that you pay shipping. The particular part in question (MCF51JM128)
has I think 128K flash, 16K RAM and on-chip USB.
However, if the answer is 68k then the question may have been asked
wrong; 68K/CF is more or less an obsolescent architecture these days.
The impression I have from Freescale's literature is that CF exists
only to provide a somewhat source-leve upward migration path from
68HC09 8-bit apps, without the cost [to Freescale] of an ARM license.
Didi
> ....
> The impression I have from Freescale's literature is that CF exists
> only to provide a somewhat source-leve upward migration path from
> 68HC09 8-bit apps, without the cost [to Freescale] of an ARM license.
Hey, that 09 (apparently you meant 08) typo can bring memories
to some here (like myself, having grown up on a 6809 CPU, which
has been dead for 20 years now).
The CF line - especially the tiny ones you refer to - is good enough
on its own, I don't see it having anything to do with ARM. And the
parts - debug interface included - are 100% documented (don't know
how this is for ARM). Unlike ARM, programming CF in 68k assembly
is quite practical - which is a huge difference (for those who
can take advantage of it, admittedly not many).
Didi
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/d365366d1a7f3b49?dmode=source
2Penny
Ladies,Gentlemen -
I knew something about Coldfire, but didn't know it had
JTAG interface. Yes, I've done ASM programming and fully
intend to use it again.
Now about assemblers ...
OK, the part lines up nicely enough, but where's the
assembler from and at what cost?
2Penny
Didi
> ....
> I knew something about Coldfire, but didn't know it had
> JTAG interface. Yes, I've done ASM programming and fully
> intend to use it again.
Ouch, I think they have no JTAG - just a so called "1 wire debug
interface" or something. It is documented but I have not dealt
with it yet, including these parts in my toolchain is only on
my TBD list...
This pretty much means no boundary scan, I believe (again, not
sure what can be done over the debug interface).
> Now about assemblers ...
>
> OK, the part lines up nicely enough, but where's the
> assembler from and at what cost?
I can't help here since I use my own, DPS based toolchain
which is not available for any popular hardware platform.
Since you know 68k ASM I suppose you will either know you
have to stay away from the weird GNU 68k syntax or be used
to it and just use it... :-).
Didi
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/75d8be2275ea72aa?dmode=source
>
> 2Penny
>
> Didi wrote:
> > On Sep 5, 4:16 pm, larwe <zwsdot...@gmail.com> wrote:
> >> ....
> >> The impression I have from Freescale's literature is that CF exists
> >> only to provide a somewhat source-leve upward migration path from
> >> 68HC09 8-bit apps, without the cost [to Freescale] of an ARM license.
>
> > Hey, that 09 (apparently you meant 08) typo can bring memories
> > to some here (like myself, having grown up on a 6809 CPU, which
> > has been dead for 20 years now).
>
> > The CF line - especially the tiny ones you refer to - is good enough
> > on its own, I don't see it having anything to do with ARM. And the
> > parts - debug interface included - are 100% documented (don't know
> > how this is for ARM). Unlike ARM, programming CF in 68k assembly
> > is quite practical - which is a huge difference (for those who
> > can take advantage of it, admittedly not many).
>
> > Didi
>
> > ------------------------------------------------------
> > Dimiter Popoff Transgalactic Instruments
>
> >http://www.tgi-sci.com
> > ------------------------------------------------------
> >http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
>
> > Original message:http://groups.google.com/group/comp.arch.embedded/msg/d365366d1a7f3b4...
>
>
David Brown
>
> Ladies,Gentlemen -
>
You don't need to address the group so formally - but you *do* need to
learn to post correctly (quote properly without extra indents, and don't
top-post).
> I knew something about Coldfire, but didn't know it had
> JTAG interface. Yes, I've done ASM programming and fully
> intend to use it again.
>
The Coldfires do not have a JTAG interface (some do, but it's not for
debugging). They have a BDM interface which is a Freescale-specific
serial debugging interface. It does a similar job to JTAG debugger
interfaces, but is more efficient.
> Now about assemblers ...
>
> OK, the part lines up nicely enough, but where's the
> assembler from and at what cost?
>
Get the gcc toolchain from www.codesourcery.com. This includes the gnu
assembler and linker, gcc C and C++ compilers, a library, and other
tools. You can get the completely free version (free as in beer and
free as in speech), or pay for a supported version with integrated
Eclipse and some extra utilities.
An alternative would be Code Warrior from Freescale, which is free for a
limited code size.
David Brown
That may be the impression *you* have got of the ColdFire, but it is
totally at odds with reality. The ColdFire is very much a major 32-bit
processor architecture with devices ranging from tiny low-power with
integrated memories to superscaler devices at several hundred MHz.
Freescale have a couple of dozen devices available, with new ones coming
out all the time. The cores are also available for license - I read
somewhere (but haven't confirmed) that there are more ColdFire cores in
ASICs than in all of Freescale's MCF device range put together.
The ColdFire core bears no resemblance to the 8-bit Freescale cores -
perhaps you are thinking only of the ColdFire v1 cores that are
available in the same package and with the same peripherals as a range
of 68S08 devices (the idea being that you can easily move between
cheaper and lower power 8-bit cores and faster 32-bit cores).
I don't know that many people would describe the ColdFire as "PIC-like",
however. When you mention "PIC", experienced embedded developers tend
to think of nice peripherals and a horrendously ugly core, while people
who know the ColdFire core think of it as one of the most elegant
designs available (and with good peripherals too).
larwe
wrote:
> That may be the impression *you* have got of the ColdFire, but it is
> totally at odds with reality. The ColdFire is very much a major 32-bit
Mere availability of a wide range of devices is an orthogonal issue to
the matter of obsolescence. ColdFire is used, yes, but (if you buy the
reports) it's experiencing a shrinking number of design wins.
Freescale as a whole isn't doing amazingly well these days, FTM.
> processor architecture with devices ranging from tiny low-power with
> integrated memories to superscaler devices at several hundred MHz.
... exactly like the popular cores, viz. ARM and MIPS. ColdFire
occupies the same space for Freescale that AVR32 does for Atmel (and
most of the other silicon vendors have their own proprietary 32-bit
cores, too - NEC, ST, ...). They're generally available but not really
what one would call mainstream.
> The ColdFire core bears no resemblance to the 8-bit Freescale cores -
> perhaps you are thinking only of the ColdFire v1 cores that are
> available in the same package and with the same peripherals as a range
> of 68S08 devices (the idea being that you can easily move between
Yes, that's what I meant. Wasn't implying any architectural similarity
between the cores, I was talking about the migration path Freescale
touts.
Didi
> ...
> Mere availability of a wide range of devices is an orthogonal issue to
> the matter of obsolescence. ColdFire is used, yes, but (if you buy the
> reports) it's experiencing a shrinking number of design wins.
Coldfire appeared after Motorola had closed the 68k line at 68060;
to me it looks like extending the life of the 68k architecure which
was so much ahead of its time that it is still hard to scrap.
They wanted to replace it with the PPC - which is still by far the
most advanced architecture on the market today - but 15+ years on
this has yet to be 100% completed...
Much of the reason - perhaps not quite recognized - is the fact that
68k assembly is an extremely efficient language. Extending that
into VPA has made me even more efficient on PPC platforms, however
this is not (perhaps yet) available for a wider audience.
And using a 68k using C is more or less pointless, there is no
advantage to have with that - just use PPC or ARM or whatever.
> ColdFire
> occupies the same space for Freescale that AVR32 does for Atmel (and
> most of the other silicon vendors have their own proprietary 32-bit
> cores, too - NEC, ST, ...).
The tiny coldfires compete for the lowest power market segment, only
the 430 is in that category. And CF has that true 68K style IRQ
priority scheme, none of the rest have it (and very few poeople
know what to do with it, of course).
Didi
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/099e03964b6fab96?dmode=source
ChrisQ
> The tiny coldfires compete for the lowest power market segment, only
> the 430 is in that category. And CF has that true 68K style IRQ
> priority scheme, none of the rest have it (and very few poeople know
> what to do with it, of course).
>
> Didi
>
Have been a long term fan of 68k and considering that it's been around
since 1979'ish, has to be one of the longest lasting embedded 16 bit
architectures around. A clean, orthoganal design with (as you say) a
fully vectored prioritised interrupt subsystem that's hard to better 25+
years later. Renesas copied it almost verbatim in the M30870.. series
and probably many others as well.
Looked at coldfire and wanted an excuse to use it, but can't ignore the
logic of arm, which has dozens of vendors. Parts are cheap and powerfull
as well and you just have to live with stuff like the idiosyncratic
interrupt structure. Nothing like as clean as 68k, but I guess that's
progress and still haven't really forgiven Freescale for eol'ing
Dragonball 68k at pretty short notice...
Chris
----------------------
Greenfield Designs Ltd
Oxford England
44 1865 750 681
linnix
> Looked at coldfire and wanted an excuse to use it, but can't ignore the
> logic of arm, which has dozens of vendors. Parts are cheap and powerfull
> as well and you just have to live with stuff like the idiosyncratic
> interrupt structure. Nothing like as clean as 68k, but I guess that's
> progress and still haven't really forgiven Freescale for eol'ing
> Dragonball 68k at pretty short notice...
One good thing about Coldfire is that the V1 IP is relatively cheap.
I think it's 10K plus 1 penny each. So, if you are into ASIC, you can
keep it alive for ever.
Didi
> ...
> Looked at coldfire and wanted an excuse to use it, but can't ignore the
> logic of arm, which has dozens of vendors.
The "dozens of vendors" thing is largely overestimated in its
importance, not one ARM based part is really second sourced. The
common thing they have is the core which also varies widely,
like many others. Then the tiny CF (pretty new, some of them
still just "sample") addresses the lowest power market (while
you still have a 50 MHz 68k...), I don't know if ARMs do that.
Other than that, I also have looked at the CF line and rejected
it about 8 or 9 years ago. It was just emerging, and I had to move
on from the CPU32 (I used the 68340, still available, unlike your
Dragonball...); my judgment was that my (huge amount of) code,
written in CPU32 ASM would be better off using just source level
compatibility rather than binary, the CF would have been a lot
worse off emulating all the addressing modes it did not have than
the PPC doing it at the expense of somewhat longer binaries (which
turned out to become apr. 3.5 times larger than the original CPU32
ones, no optimization whatsoever - with much room for some).
But the tiny CF parts - which are all <$5, some are closer
to $2 - are really interesting and have what it takes to
become popular, I believe.
Didi
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/e4748a715d6e0ab8?dmode=source
larwe
> But the tiny CF parts - which are all <$5, some are closer
> to $2 - are really interesting and have what it takes to
How can they compare to a sub-$1 Cortex-M3 part with 64K flash, 16K
RAM, and loads of peripherals?
Didi
Perhaps someone familiar with both families could comment,
I am not that familiar with ARM and you don't seem to be
very familiar with CF. Actually I have yet to become very
familiar with it myself, but I have already done some work
in this direction.
How much does the part you refer to consume running full power
at 50 MHz core clock? The MCF51QE128 @3.3V, 50 MHz core/25 MHz bus
specifies 33.4 mA - everything on and running, obviously it
goes down through uA to nA range using different power saving
modes.
The prices I know of are for 1000+, are yours at 1000+ as well?
larwe
> Perhaps someone familiar with both families could comment,
> I am not that familiar with ARM and you don't seem to be
> very familiar with CF. Actually I have yet to become very
My point is that there needs to be a compelling reason to choose a
proprietary core. I remember having the same argument in this NG about
AVR32. The Atmel guys have given up on trying to sell it to us, when
they come round to talk about products they just say "oh, and of
course there's AVR32 as well". Microchip keeps trying to sell us the
32-bit PICs... which reminds me they were going to give me an EVB to
play with at home. I must ping them about that.
> How much does the part you refer to consume running full power
> at 50 MHz core clock? The MCF51QE128 @3.3V, 50 MHz core/25 MHz bus
The part isn't characterized at that precise frequency (it is
characterized from 8 to 72MHz in various steps), but at 48MHz core,
fbus=fcore (but 1WS, effectively 24MHz) it's 36.1mA with all
peripherals enabled, 24.4 with all peripherals disabled (running from
flash) or 31.5/20.5mA running from RAM. Definitely the same ballpark.
That's why I got puzzled when you or someone else in this thread
started talking about low power consumption; CF simply isn't amazingly
slender in this day and age. Low-power apps that don't require much
horsepower go with an 8-bitter or an MSP430; apps that do require
number-crunching horsepower often use a low-power DSP these days.
> The prices I know of are for 1000+, are yours at 1000+ as well?
We don't bother to get pricing for anything in quantities under
10000 :)
Didi
> proprietary core.
I do not see how ARM is more mainstream than 68k, other than
in marketeer talk. What do you get if your MCU is ARM based
and not CF or whatever? It is still single sourced. There is
likely more 68k code around than there is ARM - has been used
much longer in much larger applications than ARM goes into.
There must be some compelling reason nowadays with all that
C programming mess to prefer a part based on its core anyway;
access to an efficient assembly language for someone who can
take advantage of it looks like one to me.
> > How much does the part you refer to consume running full power
> > at 50 MHz core clock? The MCF51QE128 @3.3V, 50 MHz core/25 MHz bus
>
> The part isn't characterized at that precise frequency (it is
> characterized from 8 to 72MHz in various steps), but at 48MHz core,
> fbus=fcore (but 1WS, effectively 24MHz) it's 36.1mA with all
> peripherals enabled, 24.4 with all peripherals disabled (running from
> flash) or 31.5/20.5mA running from RAM. Definitely the same ballpark.
Same ballpark indeed, if the ARM based part has also the lowest power
saving modes - slower internal clock etc. - this becomes even more so.
> > The prices I know of are for 1000+, are yours at 1000+ as well?
>
> We don't bother to get pricing for anything in quantities under
> 10000 :)
So prices are the same. Well, I am sure I could pack a lot more code
into a CF part than anyone could pack using C in either ARM or CF
(factor of 10+) and I would be faster practically for any project
larger than something saying "hello world", so I know what my choice
would be.
Didi
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/e1a59d95f4de6143?dmode=source
David Brown
> On Sep 5, 10:41 am, David Brown <da...@westcontrol.removethisbit.com>
> wrote:
>
>> That may be the impression *you* have got of the ColdFire, but it is
>> totally at odds with reality. The ColdFire is very much a major 32-bit
>
> Mere availability of a wide range of devices is an orthogonal issue to
> the matter of obsolescence. ColdFire is used, yes, but (if you buy the
> reports) it's experiencing a shrinking number of design wins.
> Freescale as a whole isn't doing amazingly well these days, FTM.
>
Availability of *new* devices is a good indication that are architecture
is not obsolete (or going obsolete). I agree about *existing* devices,
whose availability is, as you say, orthogonal to obsolescence. But no
company will devote significant resources to making new products for a
dying range (look at Freescale's MCore range, for an example).
I don't have any numbers for where the ColdFire stands in either the
number of designs or number of parts, but I have seen nothing to
indicate that it is not a major architecture, and will continue to be one.
>> processor architecture with devices ranging from tiny low-power with
>> integrated memories to superscaler devices at several hundred MHz.
>
> ... exactly like the popular cores, viz. ARM and MIPS. ColdFire
> occupies the same space for Freescale that AVR32 does for Atmel (and
> most of the other silicon vendors have their own proprietary 32-bit
> cores, too - NEC, ST, ...). They're generally available but not really
> what one would call mainstream.
>
Like the AVR32, and unlike the ARM, MIPS, PPC, and x86, the ColdFire is
single-source. If by "mainstream" you mean "available from multiple
sources", then the ColdFire is not mainstream. But if by "mainstream"
you mean popular, easily available in small and large quantities, well
supported by its manufacturer, distributors, and third-party tool
developers (open source, small commercial, and big commercial vendors,
for compilers, debuggers, OS's, software libraries, hardware development
kits, etc.), then I think the ColdFire is mainstream.
>> The ColdFire core bears no resemblance to the 8-bit Freescale cores -
>> perhaps you are thinking only of the ColdFire v1 cores that are
>> available in the same package and with the same peripherals as a range
>> of 68S08 devices (the idea being that you can easily move between
>
> Yes, that's what I meant. Wasn't implying any architectural similarity
> between the cores, I was talking about the migration path Freescale
> touts.
>
Fair enough.
David Brown
> Didi wrote:
>
>> The tiny coldfires compete for the lowest power market segment, only
>> the 430 is in that category. And CF has that true 68K style IRQ
>> priority scheme, none of the rest have it (and very few poeople know
>> what to do with it, of course).
>>
>> Didi
>>
>
> Have been a long term fan of 68k and considering that it's been around
> since 1979'ish, has to be one of the longest lasting embedded 16 bit
> architectures around. A clean, orthoganal design with (as you say) a
> fully vectored prioritised interrupt subsystem that's hard to better 25+
> years later. Renesas copied it almost verbatim in the M30870.. series
> and probably many others as well.
>
From the very start, the 68k had a 32-bit programming architecture.
For cost reasons, the implementation used a 16-bit ALU and datapath, but
all the registers were 32-bit, and all instructions supported 8-bit,
16-bit and 32-bit widths (even though the 32-bit versions took twice as
many clock cycles). This meant that when 32-bit ALUs became
economically feasible, the 68k just got faster with the same software,
unlike the x86 architecture that got seriously ugly in the move to 32 bits.
> Looked at coldfire and wanted an excuse to use it, but can't ignore the
> logic of arm, which has dozens of vendors. Parts are cheap and powerfull
> as well and you just have to live with stuff like the idiosyncratic
> interrupt structure. Nothing like as clean as 68k, but I guess that's
> progress and still haven't really forgiven Freescale for eol'ing
> Dragonball 68k at pretty short notice...
>
There are lots of vendors of ARM devices, (almost) none of which are
compatible with each other in terms of peripherals, pin outs, or pretty
much anything except the core. For most developers, you don't choose to
use ARMs - you choose to use Atmel ARMs or NXP ARMs, or whatever. There
is not actually much of a difference between that and choosing the
FreeScale ColdFires - you base the choice on things like peripheral
mixes for particular devices, cost, distributors, tools, etc.
The Dragonball was always a special case for Freescale - it was a
one-off device, not part of a family (though the core was), and aimed at
a few specific large customers (such as Palm). When these customers
moved on, 99% of the sales dried up. It's a different matter for
devices like the 68332, which has a much wider range of customers. That
device must be nearly 20 years, and Freescale have still not managed to
EOL it despite trying for years to move customers to the MPC5xx line
(PPC based) and the later MCF523x (ColdFire base, and much more popular
among 68332 users).
linnix
> From the very start, the 68k had a 32-bit programming architecture.
> For cost reasons, the implementation used a 16-bit ALU and datapath, but
> all the registers were 32-bit, and all instructions supported 8-bit,
> 16-bit and 32-bit widths (even though the 32-bit versions took twice as
> many clock cycles). This meant that when 32-bit ALUs became
> economically feasible, the 68k just got faster with the same software,
> unlike the x86 architecture that got seriously ugly in the move to 32 bits.
In a way, we have to thank the x86 marketer for beating the 68k.
Otherwise, many programmers would stay with assemblers and C would not
be as popular. C masks out the ugly x86 architecture.
Didi
> ....
> In a way, we have to thank the x86 marketer for beating the 68k.
> Otherwise, many programmers would stay with assemblers and C would not
> be as popular. C masks out the ugly x86 architecture.
Indeed so. The world has to thank x86 for making C popular and
thus totally messing up programming for decades - so far.
This probably sounds weird to almost everyone; likely because
C has always been the only thing "everyone" has ever been good
at...
Didi
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/f724b65b3f8f4483?dmode=source
Paul Keinanen
>On Sep 7, 9:15 pm, linnix <m...@linnix.info-for.us> wrote:
>> ....
>> In a way, we have to thank the x86 marketer for beating the 68k.
>> Otherwise, many programmers would stay with assemblers and C would not
>> be as popular. C masks out the ugly x86 architecture.
>
>Indeed so. The world has to thank x86 for making C popular and
>thus totally messing up programming for decades - so far.
>This probably sounds weird to almost everyone; likely because
>C has always been the only thing "everyone" has ever been good
>at...
The strange thing is that C became so common and not PLM-86.
A few years earlier, most 8-bitters were programmed in assembler, but
Intel marketed the PLM-80 to mask the ugly 8080 architecture. PLM-80
was used quite a lot in those days.
Paul
David Brown
People have used C on the 68k for about as long as there has been C (68k
cpus were a popular choice for early unix workstations such as Sun's
first machines, unlike x86 which only gained serious *nix popularity
with Linux. It was also the original target for gcc). Writing a C
compiler for the 68k is peanuts compared to writing one for the x86,
since the 68k has a wide set of mostly orthogonal registers, plenty of
address registers, and addressing modes ideal for C. Getting the best
out of an x86 device is a black art, and it was a long time before C
compilers could compete with professional x86 assembler programmers. So
I expect most serious x86 development was still being done in assembly
long after C (and other high level languages) were standard on the 68k
(the Mac OS being a notable exception, written mostly in assembly for
some reason).
The legacy of assembly on the x86 is one of the reasons why the
instruction set is so hideous - it has had to keep 100% binary
compatibility because you can't just recompile your assembly code for a
new architecture. The 68k architecture, on the other hand, has seen
many binary incompatible changes (such as the removal of rarer
addressing modes) to improve efficiency.