27 Oct
2011
27 Oct
'11
2:20 p.m.
On Oct 26, 2011, at 4:48 PM, Chuck Guzis wrote:
Absolutely agreed, I was just getting tetchy about the juxtaposition of the
talk about little RTOSes for PICs and then Unix on the PIC32. It's a
nervous tic I have from working with too many customers whose only
experience with micros is the PIC (because they're too lazy to try anything
else) and insist on upgrading to a PIC32 because they think it'll be
compatible with their existing software base.
Though I've overcome it now (mostly), I had a very strong bias against PIC
for many years mainly because of the technologically inbred nature of many
of their fans.
A few years back I started a new job to work on a project to replace an
aging PIC-based door access control module. The new platform had already
been selected by the time I started: ColdFire running an RTOS. This was
driven mainly by the fact that the new parent company had a commercial line
of HVAC controllers based on that processor. Not a bad choice but the
dreams of code re-use were mostly unfounded.
Interestingly, it turns out one of the reasons I was hired was to backfill
the fan-boy who resigned in a huff because a PIC-32 wasn't selected.
Amardeep
27 Oct
27 Oct
2:45 p.m.
On Oct 27, 2011, at 2:20 PM, Amardeep S Chana wrote:
Though I've overcome it now (mostly), I had a very
strong bias against PIC
for many years mainly because of the technologically inbred nature of many
of their fans.
Indeed. It was a great thing in the '90s, when it was pretty much the only one easily
available to hobbyists (partly because it was so damn easy to make a bit-banged programmer
that hooked to the serial port). I can't imagine why you'd seriously consider it
now when the AVR has come such a long way (especially with the XMEGA line, which is even
better on power than the MSP430).
A few years back I started a new job to work on a
project to replace an
aging PIC-based door access control module. The new platform had already
been selected by the time I started: ColdFire running an RTOS. This was
driven mainly by the fact that the new parent company had a commercial line
of HVAC controllers based on that processor. Not a bad choice but the
dreams of code re-use were mostly unfounded.
I love the Coldfire, but it's probably because of my 68k fetish. Really nice stuff,
but even the Coldfire+ isn't keeping up with ARM development so well these days.
Interestingly, it turns out one of the reasons I was
hired was to backfill
the fan-boy who resigned in a huff because a PIC-32 wasn't selected.
We actually did select a PIC32 for a project, but it had nothing to do with it being
related in any way to the PIC (which it's not). It just happened to be the only micro
available (at the time) which had six UARTs, two CAN interfaces and an SPI interface that
could all be used at the same time. It's actually a nice piece of hardware, but
people pick (or dismiss) it based on the name a lot more than the merits.
The punchline: the customer eventually shot the idea down because they wanted us to add
the functionality into the (already overcrowded) FPGA instead because they
"didn't want the hassle of maintaining the software". Clearly they've
been drinking amnesia potions, because we've done two arduous FPGA projects with them
so far, certainly enough for them to recognize the FPGA as more of a headache source than
software.
As it turned out, we ended up spending $100K in NRE to design in a newer, larger FPGA and
it cost about $5-10 more per board (in quantities of 10K+ units; this is the sort of
project where they argued us down from better switching regulators to save a few pennies
per board). Then the project was canned by the client before we even got to trying to
bang more UARTs into the FPGA because of money problems (imagine that).
- Dave
3:09 p.m.
New subject: ColdFire was Re: Performance-oriented development blah blah blah
I love the Coldfire, but it's probably because of
my 68k fetish. Really
nice stuff, but even the Coldfire+ isn't keeping up with ARM development so
well these days.
I've never worked with the ColdFire, but because of my interest in Alpha
Micros I've always been curious (near the end of the 68K Alpha Micro phase
there were ColdFire-based servers produced -- I presume with some sort of
emulation layer for those instructions not supported on ColdFire that were
on, say, the '040). How was it to work with compared to a "stock" 68020 or
'030?
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- No good deed goes unpunished. -- Clare Boothe Luce -------------------------
3:21 p.m.
New subject: ColdFire was Re: Performance-oriented development blah blah blah
On Thu, Oct 27, 2011 at 12:09:57PM -0700, Cameron Kaiser wrote:
I've worked with the ColdFire. We used a BGA package, which is not
so much fun for home brewers. It expanded the instructions in the
macro assembler and the compilers just had to DTRT.
It is/was fast.
- Diane
--
- db at FreeBSD.org db at db.net http://www.db.net/~db
Why leave money to our children if we don't leave them the Earth?
I love the
Coldfire, but it's probably because of my 68k fetish. Really
nice stuff, but even the Coldfire+ isn't keeping up with ARM development so
well these days.
I've never worked with the ColdFire, but because of my interest in Alpha
Micros I've always been curious (near the end of the 68K Alpha Micro phase
there were ColdFire-based servers produced -- I presume with some sort of
emulation layer for those instructions not supported on ColdFire that were
on, say, the '040). How was it to work with compared to a "stock" 68020 or
'030?
4:08 p.m.
New subject: ColdFire was Re: Performance-oriented development blah blah blah
On Oct 27, 2011, at 3:09 PM, Cameron Kaiser wrote:
Well, you're using the past tense; they're still very much alive and well, though
generally highly integrated as opposed to standalone processors. Some of the more modern
ones have some nice additional MAC (multiply-accumulate) instructions with an
extended-range accumulator for e.g. light DSP work. Unfortunately, those MAC instructions
are all A-line instructions, so you can't use A-line words to force a trap to the
illegal instruction handler (which is how the 68K Mac system did its toolbox calls).
It's an "assembly-compatible" 68K variant, which means the opcodes have been
shuffled around to optimize silicon area in the decoder, but all the mnemonics are still
there aside from a few bits of functionality they decided were unnecessary or extremely
seldom-used. Early Coldfires didn't have separate user and supervisor stack pointers
like the real 68K, but modern ones all do and I never had to work with any without.
It's not object-code compatible with the 68K, but reassembling generally does the
trick and most of the SPRs are pretty much the same.
It also certainly runs less power than the original parts. The newest Coldfire+ line is
designed for super-low power operation, so it runs a handful of ?A at sleep and just a few
mA (up to a few hundred, depending on how fast you run) in run mode. It's good for
"semi-pro" hobbyist work, i.e. if you have a project that you like enough to
make a proper PCB and get it professionally assembled (unless you're just that good at
putting on BGAs, which is at least possible with a heat gun), but I honestly think
it's a lot easier to get good mileage out of an ARM, especially with cheap open-source
dev tools.
- Dave
I love the
Coldfire, but it's probably because of my 68k fetish. Really
nice stuff, but even the Coldfire+ isn't keeping up with ARM development so
well these days.
I've never worked with the ColdFire, but because of my interest in Alpha
Micros I've always been curious (near the end of the 68K Alpha Micro phase
there were ColdFire-based servers produced -- I presume with some sort of
emulation layer for those instructions not supported on ColdFire that were
on, say, the '040). How was it to work with compared to a "stock" 68020 or
'030? 
4:40 p.m.
New subject: ColdFire was Re: Performance-oriented development blah blah blah
On 27 Oct 2011 at 16:08, David Riley wrote:
It's an "assembly-compatible" 68K
variant, which means the opcodes
have been shuffled around to optimize silicon area in the decoder, but
all the mnemonics are still there aside from a few bits of
functionality they decided were unnecessary or extremely seldom-used.
Early Coldfires didn't have separate user and supervisor stack
pointers like the real 68K, but modern ones all do and I never had to
work with any without. It's not object-code compatible with the 68K,
but reassembling generally does the trick and most of the SPRs are
pretty much the same.
Didn't Motorola start this idea with the 6809? I seem to remember
that they advertised it as being "assembly-compatible" with the 6800,
even though the instruction sets were very different.
--Chuck
3:13 p.m.
On 27 Oct 2011 at 14:20, Amardeep S Chana wrote:
Interestingly, it turns out one of the reasons I was
hired was to
backfill the fan-boy who resigned in a huff because a PIC-32 wasn't
selected.
Microchip is a very strange outfit when it comes to the PIC32. Like
the R4000, programming on the PIC32 is present as JTAG. However
Microchip incorporated a rather convoluted version of their SPI
protocol that's translated into JTAG on the chip. I'm sure it sells
a lot of PICKIT programmers, but otherwise, it's been a mystery to me
why this was done. Could it be that JTAG is more or less industry
standard for this sort of thing?
--Chuck
4616
days inactive
4616
days old
6 comments
5 participants
participants (5)
-
asc135＠gmail.com -
cclist＠sydex.com -
db＠db.net -
fraveydank＠gmail.com -
spectre＠floodgap.com