Freescale's new roadmap - 9s12 not looking good?

> The LPC2* have no non-intrusive debugging capability like BDM. For 
> me, that's a strong reason, because I have
some "hard realtime" 
> applications which I can't debug with interrupt driven methods. So I 
> needed an emulator...

What is "non-intrusive"? The LPC2103 definitely has JTAG based
in-circuit debugger interface, much like the OnCE on the Motorola 
MCORE chips or the BDM on the MPC8xx chips. So what's the
difference between the HC12 BDM and those?

Thanks,

Zoltan
	

it's called 9S12C32 and it's around $6 (1K)--  been out there
about 3
years now.  oh, and the bus speed is 25Mhz.  somebody even made a
"stamp-killer" with it:   read
http://www.seanet.com/%7Ekarllunt/binload.htm

--- In 68HC12@68HC..., BobGardner@... wrote:
>
> I've thought for years that an HC11F1 with 32K of flash on chip
would have  
> been a mega avr killer. There are a few things the
hc11 has that the
avrs  
> dont.... swi, rti, illegal opcode trap, von neuman
achetecture so
you dont need  
> extra const char print librbray functions. It
already ran at 20mhz
clock... 
> darn  avr only runs at 16mhz still.... they havent
pushed their
20mhz process 
> into  their mega cpus yet....  I bet all you guys
would design in a
new 32k flash 
>  hc11 next month if it came out wouldnt you?
> 
> 
> 
>
	

mculater12 wrote:

[HC11F1 successor]

> it's called 9S12C32 and it's around $6
(1K)--  been out there about 3

the C32 has no external memory interface and/or less I/O.

Oliver
-- 
Oliver Betz, Muenchen
	

Zoltan wrote:

[The LPC2* have no non-intrusive debugging capability like BDM]

> What is "non-intrusive"? The LPC2103
definitely has JTAG based
> in-circuit debugger interface, much like the OnCE on the Motorola 
> MCORE chips or the BDM on the MPC8xx chips. So what's the
> difference between the HC12 BDM and those?

Probably I'm not well informed. I heared that there should be some 
devices with extended debug possibilities, but AFAIK you can't read 
LPC2103 memory without interrupting the running application.

Can you tell me which ARM7 devices support real "background" memory 
access working without the help of a interrupt driven target monitor 
firmware?

And which debugger (hardware + software, pricing) supports this 
feature?

BTW: _much_ more pins are needed for the ARM7 debug interface!

Maybe the limitations I mentioned are no more valid, this could 
facilitate a switch to small ARM7. Yesterday I learned that the 
S12GC16 costs more than twice the amount of a LPC2102 (>3,6EUR@1000 
vs. 1,8EUR at even smaller quantities)! Annoying that they need two 
supply voltages and don't work at 5V.

Oliver
-- 
Oliver Betz, Muenchen
	

"Oliver Betz" <list_ob@list...> wrote:

> Zoltan wrote:
> 
> [The LPC2* have no non-intrusive debugging capability like BDM]
> 
> > What is "non-intrusive"? The LPC2103 definitely has JTAG
based
> > in-circuit debugger interface, much like the OnCE on the Motorola 
> > MCORE chips or the BDM on the MPC8xx chips. So what's the
> > difference between the HC12 BDM and those?
> 
> Probably I'm not well informed. I heared that there should be some 
> devices with extended debug possibilities, but AFAIK you can't read 
> LPC2103 memory without interrupting the running application.

I do not think you can - that's why I said it was like the MCORE and
the MPC8xx debug port. Like those chips, it works by allowing you to
issue arbitrary CPU instructions through the debug port and have a
special register to transfer data between the chip and the debug SW.
Actually you can't read the memory even with the 683xx and HC16 BDM
while the code is running, as far as I know. You have to halt the chip
for that, although you do not need to use the CPU core to access the
memory.

> Can you tell me which ARM7 devices support real
"background" memory 
> access working without the help of a interrupt driven target monitor 
> firmware?

I don't think any does. You can have 'watchpoints' where the
on-chip
debug HW checks all bus cycles against accessing an address but if you
want to actually read/write memory or registers, you have to halt the
core. You don't need any target resident SW for that, but it is not
real-time. I'll check if the watchpoint stuff can actually tell you
what the new value of the watched location is without halting the
core, but I doubt it.

> And which debugger (hardware + software, pricing)
supports this 
> feature?

Well, the devkits and tools vary in price, USB based debug pods
and (limited) compiler for Windows are around US $200 - $300. 
If you go to the Philips website and look up the 2103 they have 
a handful of links to devkit, debug pod and SW vendors. I have
no clue if there's gdb/Linux support for any of those pods, of
course gcc happily compiles for ARM.

> BTW: _much_ more pins are needed for the ARM7
debug interface!

No quastion about that - you can hardly beat a 1-wire interface :-)

Don't get me wrong, I don't want to convert you from HC12 to ARM,
I just didn't know what you meant by non-intrusive, that's all.
On the other hand, those ARM chips are really cheap.
 
> Maybe the limitations I mentioned are no more
valid, this could 
> facilitate a switch to small ARM7. Yesterday I learned that the 
> S12GC16 costs more than twice the amount of a LPC2102 (>3,6EUR@1000 
> vs. 1,8EUR at even smaller quantities)! Annoying that they need two 
> supply voltages and don't work at 5V.

Yes, that's a drawback. The MCORE is quite nice in that sense, it runs
from 3.3V but it's 5V tolerant and the A/D section actually runs from
5V and of course converts between 0 and 5V. A tad more expensive than
the HC12, though, around $15 in quantities for a 33MHz 256K FLASH 32K
RAM part (MMC2114). Comes with or without external bus, too. An other
cool but orphaned Motorola part :-(

Zoltan

Zoltan wrote:

[LPC2* non-intrusive debugging capability?]

> I do not think you can - that's why I said it
was like the MCORE and
> the MPC8xx debug port. Like those chips, it works by allowing you to

I see.

[...]

> Don't get me wrong, I don't want to
convert you from HC12 to ARM,

I didn't think you want to convince me. I only wanted to be sure that 
my knowledge about LPC2* debug capabilities is still correct, as I'm 
considering to use them, but still had no application justifying the 
switch.

Working with the HC12 since several years now, I have to say that the 
background memory access is priceless. Especially in small and/or 
"hard realtime" devices it's extremly useful that you simply
attach 
four wires and get reasonable access to the CPU. If I understand 
correctly, the coldfire BDM is even better.

Well, if I save enough money buying ARM7, I can pay the longer debug 
time and/or buy an emulator.

Oliver
-- 
Oliver Betz, Muenchen
	

--- In 68HC12@68HC..., "hc08jb8" <hc08jb8@...> wrote:

> If given a choice between ColdFire and the ARM9s 
> which would be a safe bet?

In my mind it depends on your application. I've used ARM7's from both
Atmel and Philips and they are terrific. But I seriously HATE
programming in ARM assembly language. The ARM chips have a lot of
modes, and many modes have differing sets of shadow registers. And the
pipeline makes it hard to work out memory offsets. I find myself
getting frustrated any time I write a small asm routine for Arm.

The 68K/Coldfire devices have a very sweet assembler programming
model. Motorola studied the PDP-11, which was loved by everyone back
then, and made some improvements to come up with the basics. I really
think this is an ideal model: as close as I'm likely to see in my
lifetime. The key word they had in mind during its design is
"orthogonal". Everything is consistant and the opcodes work the same
on all the registers and there's not many special cases in the form of
limits. You never hear someone say: "that looks like it should work,
but it doesn't". With the 68K, if it looks like it should work, it
almost always DOES.

My only concern is about which family Freescale will move towards in
the 32 bit space for the future. I have never used Arm9's, but I might
someday. I'm also impressed by the very new Arm Cortex M-8 core
(Freescale is using the A-8 in some future designs, I think, but I
could be wrong). The Cortex has the Thumb-2 instuction set, which is a
much nicer 16 bit instruction set for Arm devices than the original
Thumb instructions.

If you're going to code in C (which I guess is the case), then the
issue of ugly vs sweet internal programming models isn't relevant for
you. ARMs give you a lot of horsepower for a given number of
electrons, which is why they are so popular. I don't know if I'd use a
Freescale Arm device, though - I am more than a little disappointed in
their marketing of Arm devices. I get the feeling that the people in
charge don't personally like Arm, and they're only using it because of
strong demand by some specific big customers. The Arm core is
something you license from the Arm company, and Freescale/Motorola
historically always prefers to roll their own designs.

I also have no experience with PowerPC, so I don't want to leave you
with the impression that this is not a good option. I really don't
know if this is a good contenter for the future.

Eric
	

not quite true--  the 68HC11F1 has 68 pins, 1K RAM, and
non-multiplexed memory interface, vs. the 9S12C32 available in 80-pin
QFP, with 2K RAM and multiplexed memory interface

--- In 68HC12@68HC..., "Oliver Betz" <list_ob@...> wrote:
>
> mculater12 wrote:
> 
> [HC11F1 successor]
> 
> > it's called 9S12C32 and it's around $6 (1K)--  been out
there about 3
> 
> the C32 has no external memory interface and/or less I/O.
> 
> Oliver
> -- 
> Oliver Betz, Muenchen
>
	

--- In 68HC12@68HC..., "Oliver Betz" <list_ob@...> wrote:

> Well, if I save enough money buying ARM7, I can
pay the longer debug 
> time and/or buy an emulator.

You guys are right about JTAG debugging on the ARM being less good
than BDM. But the overall costs of ARM dev boards has been dropping a
lot, and they're now quite cheap. Perhaps cheaper than a Coldfire
board/BDM combo.

$300 can get you a nice dev board that uses the lpc2148 USB-enabled
ARM chip, along with a USB JTAG debug device. And it comes with a 32K
limited version of the IAR Embedded Workshop, which is good enough for
many purposes.

I got a cool little lpc2103 dev board disguised as a Christmas tree
with a set of blinking LEDs under program control, and a 2 line LCD
screen. The cost was about $20, including postage from Sweden to the
US. This kind of power in a fully assembled board is incredible at
this price. I guess some Europeans would have needed to pay a high tax
on it, but it's still a great deal. These devices were connected to a
PC serial port, and a Java program on the PC connected them to the
Internet, thereby creating a large Christmas tree network where people
could exchange greetings over the holidays. This was made by
EmbeddedArtists.

To use gcc/gdb you'll need a JTAG device with an open API. Amontec
makes a USB device with an open API, but most gcc uses use a Wiggler
clone by Olimex, which is a cheap PC parallel port device.

But I am not recommending that people flock away from the hc12. I
still like it best, especially if I have to write assembler routines
(everyone hates Arm assembly code - even the company reps I've talked
to). And I'll look into the new Coldfire devices - that might be a
great way to do 32 bits.

Eric
	

Good day Eric,

> 6812 came from the 6811, which came from the 6801,
which came from the
> 6800. So if you want to take this approach the 6800 comes from the

Indeed, I do not wish to belabor this issue.  My only point was that the
HC12 was a migratory path taken by the users of the HC11 et all and
therefore had a lot more people familiar with the overall architecture.  The
CF had its origins with the 68000, but this too came much later than the
6800/6801 et all, hence the familiarity would not be as large.

>(a guy in my micros class in college built one of
these in a
> shoebox - it was the coolest thing to play with back then).
>

I hate to say it, but I used to "play" a lot with the 6800 derivatives
when
I was in school.  In fact, I still have my old 6809 lab project somewhere...
Given the limited amount of memory (EPROM/RAM) we still were able to make
some cool devices (rudimentary voice recognition, HVAC controllers, printer
muxes, etc)
	>This is good news, but my point is that FREESCALE does not have such a
>forum because they think there isn't much
interest in 68K/Colfire.

I think that you should talk to other Freescale employees and disti FAEs.
The CF family has a tremendous following with an amazing feature set and
architecture.  We have several products based on the CF family and are
starting to migrate a lot of the lower 8 (and 16) bit designs to the CF
family.

As I said in my earlier post, you should really check out the variety of CF
derivatives... All sorts of speeds and features.
	> You might be too young to remember the famous Motorola BBS that was
> popular before the Internet became popular. This
was largely

Sadly, I do remember... I guess I am not too young...In fact, I used those 
BBSes often.
	> Ditto for this forum, but Freescale set up their own hc12 forum, anyway.

I wish I could answer this, but I cannot.  Perhaps someone from Freescale 
can answer.

> How many of these have Coldfire boards that were
introduced within the
> past 12 months? I'm sure some of them do, but my google searching
> showed that most 68K/Coldfire hardware and software in the marketplace
> tends to be several years old. I'd love to be wrong on this!

Check out my previous post's links... There are a variety of designs that 
have been released within the last year.  The two CF parts that has me most 
excited are:

    1. MCF5213... which to me is a HC12 eater
    Price and Performance kicks!

    2. MCF5329... Ethernet, LCD interface, DDR interface, QSPI, etc
    This part rocks!

Also, I think that there is a lot of vendors that do not sell their CF 
designs openly...i.e. they sell end-products as opposed to being embedded 
solution vendors.
I know that this is true for both my client's and my firm's designs. 
In 
fact, given the 9S12's future rumblings, my client is most likely migrating

to the MCF5213.
	> What happened to the cool 68332 chip? It was the best thing going a
> few years ago (maybe 5 or 6 - the older I get the
faster the calendar
> moves for some reason).

Yes, the '332 was (is) awesome.  This chip actually dates back to the early

90's ( I know we did a design around 1992/93 with the 332).  Consequently, 
Freescale considers this to be a mature part and is not high on the priority 
scale with adding new features, etc.  In fact, as an indicator to the 
68332's interest, its Yahoo list (  http://groups.yahoo.com/group/68300/) 
shows very little activity...perhaps a few posts every few months.

Anyway, I think that if you really look at the CF family and implement a 
design with it, you will find it to be a very rich and rewarding experience 
from both a hardware and software perspective.  In my opinion after having 
designed both hardware and software (firmware) for the old 6800's,
HC11's, 
HC08's, HC16s, 68332s, and CFs (5272, 5282, 5213, 5329, etc), I find that 
the CF family the best to work with....I know that statement sounds corny, 
but it is true... and for those that may be wondering...No, I do not work 
for Freescale!

Enough said!

Have a great evening!

Cheers,

Sam