HC12 : inDart-HCS12/D anyone ?

Hi all,

I'll develop an embedded system based on FreeScale
HC12, mainly using MC9S12NE64 and MC9S12DP256.
In short, MC9S12NE64 - based will be a card collecting
analog sensor's data, an ADC, an Ethernet port, while
the MC9S12DP256 - based will be a more versatile one
to develop prototype for some other future projects.

I am currently looking for a development kit :
SofTec inDart-HCS12/D debugger/programmer
which support more than 70 Freescale HC12 uC,
if you used it, can you tell about your experience
concerning the efficiency of those features :

- BDM
- Assembly level debugger
- Non-intrusive debug capabilities
- CodeWarrior seems limited to 32K ?
- ... and anything you find interesting.

Now, once the prototype runs under inDart-HCS12/D, we'll make
a printed circuit with the HC12 and its peripheral I/O components.
Then can I use the inDart-HCS12/D DBM capabilities directly on
"my own" card, to monitor/debug it ?

http://www.softecmicro.com/products....DART-HCS12%2FD

please reply via NG
TIA

On Apr 5, 9:07 am, 5...@free.fr wrote:
> can you tell about your experience
> concerning the efficiency of those features :
>
> - BDM
> - Assembly level debugger
> - Non-intrusive debug capabilities
> - CodeWarrior seems limited to 32K ?
> - ... and anything you find interesting.
>

Freescale's BDM is much better than the more common JTAG interface
used by other makers. At least, it's better when it comes to debugging
your programs because it can examine code as it runs, and it can
freeze the processor for more invasive debugging (but thankfully the
timer can also stop in this case). The BDM is also fully documented,
which is rare for internal debug modules in this business.

CodeWarrior is the #1 commercial tool for this platform by far, but
there's also a gcc for this platform. I make an IDE for it
(EmbeddedGNU), and I support the serial monitor on the NE64. The d-
bug12 monitor on the DP256 is also supported, but it generally less
suitable for real-world debugging. However, d-bug12 supports a "pod"
mode that lets one board as a BDM for the other board, thus providing
enhanced debugging at a cheap cost. In the end, you'll need
CodeWarrior for the best debugging experience. Open source tools
simply aren't there yet, but are moving in that direction.

Assembly coding on the hc12 platform is light-years better than
assembly coding on RISC chips, but it's still tedious and error prone.
So most people use C.

I'm personally not happy with Freescale's decision not to market the
hc12 platform to the General Purpose market any longer, and their
marketting literature has factored it out of everything except
automotive applications. This is partly due to the cost/benefit
breakdown of this family that is having a hard time competing with
stronger processors at lower prices. For this reason, I'd have to
sadly consider other MCUs that might have more staying power in the GP
market, such as the Arm, MSP430, etc. Arms are dirt-cheap now and
msp430's live on a very small amount of current. There are many other
viable families also, and this is partly why Freescale has changed
their marketting direction.

Freescale is pushing the Coldfire pretty hard now, but I see that as
mostly having an Ethernet application niche. Thus, it might be a good
fit for some of your work. But I don't see Coldfire making strong
progress into the general purpose market.

Eric

Eric wrote:
<snip>
> I'm personally not happy with Freescale's decision not to market the
> hc12 platform to the General Purpose market any longer, and their
> marketting literature has factored it out of everything except
> automotive applications. This is partly due to the cost/benefit
> breakdown of this family that is having a hard time competing with
> stronger processors at lower prices. For this reason, I'd have to
> sadly consider other MCUs that might have more staying power in the GP
> market, such as the Arm, MSP430, etc. Arms are dirt-cheap now and
> msp430's live on a very small amount of current. There are many other
> viable families also, and this is partly why Freescale has changed
> their marketting direction.
>
> Freescale is pushing the Coldfire pretty hard now, but I see that as
> mostly having an Ethernet application niche. Thus, it might be a good
> fit for some of your work. But I don't see Coldfire making strong
> progress into the general purpose market.

I guess they are hoping the newer, smaller Coldfire 1 will fill the gap,
but it does leave a vacuum there, while they get that organised.

Marketing might have run ahead of Engineering

-jg