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

Eric Engler 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

With "the longer debug time and/or buy an emulator" I meant that I 
can either:
- spend more time debugging with ARM JTAG than with the superior BDM
- or spend (much) more money to buy a full emulator.

Hmm, neither Nohau nor iSYSTEM seem to offer LPC2* emulators.

Usually the cost of a dev board is negligible, IOW much less than the 
overall cost of introducing a new processor family.

Oliver
-- 
Oliver Betz, Muenchen
	

--- In 68HC12@68HC..., "Sam Saprunoff" <sams2@...> wrote:

Sam,

Thanks for the coldfire info. I'll post some more questions on the
WildRice forum when I get some time. I need to get up to speed on the
latest developments. I assumed it was dead a few years ago, so I
haven't been paying attention to it.

I need to find an inexpensive dev board and a cheap BDM device and get
going with it!

Eric
	

What worries me about making a commitment to Coldfire is the long-term
potential for this core. Low-cost ARM processors are springing up from
many vendors, probably initially to support the latest cell phones (and
PDAs and related devices) that have a GUI interface. Now they are getting
rolled out to general-purpose applications. GUI support for ARM is hard to
compete with, and the architectural choice for GUI systems is dominated by
software rather than hardware. Operating systems, special-purpose
application software, drivers for common peripherals. This implies to me
that ARM will get the bulk of the very high-volume design wins, which will
keep subsidizing ARM hardware development, and drive chip costs down.
Where there's an architectural choice, this kind of positive feedback
tends to reinforce volume leadership and drive out competition. As with
Pentium (and software-compatibles like Athlon) versus the PowerPC. Were
the Intel/AMD parts better than PowerPC? Not the point...the software
considerations/standard platform issues overruled which chip was better.
Maybe I'm completely off-base here but I can't help thinking about
that
history when I consider Coldfire...Now if Windows CE would run on
Coldfire, the outlook would be totally different, I think....

Best regards,

Kerry Berland
kerry.berland@kerr...
Silicon Engines
3550 W. Salt Creek Lane, Suite 105
Arlington Heights, IL 60005 USA
847-637-1180
Fax 847-637-1185
www.siliconengines.net
	>     --- In 68HC12@68HC..., "Sam Saprunoff"  wrote:
>
>  Sam,
>
>  Thanks for the coldfire info. I'll post some more questions on the
>  WildRice forum when I get some time. I need to get up to speed on the
>  latest developments. I assumed it was dead a few years ago, so I
>  haven't been paying attention to it.
>
>  I need to find an inexpensive dev board and a cheap BDM device and get
>  going with it!
>
>  Eric
>
>
>
>
>
>         SPONSORED LINKS
>    Fast track
> Microcontrollers                                       Technical
> support
>          Intel microprocessors
>   Pic microcontrollers
>          YAHOO! GROUPS LINKS
>      
>
	

--- In 68HC12@68HC..., "Kerry Berland" <kerry.berland@...>
wrote:

> GUI support for ARM is hard to compete with, and
the architectural
> choice for GUI systems is dominated by software rather than
> hardware.

You're correct that ARM has a serious lead, and not just on software.
The hardware is also cheaper on the ARM side. I doubt if the Coldfire
devices will be that cheap, given a similar mix of
USB/Ethernet/flash/RAM, etc.

I have to re-iterate that the ARM is just plain nasty at the assembler
level, so many apps that require low-level coding (perhaps routers and
multi-media, among others) will be better off with Coldfire. But if
you can get by with a good C compiler, then the issue comes down to
third-party software and hardware/software tool support, and chip
cost, of course.

There's another segment of embedded processors that has been growing
exponentially: very low power MSP430 devices. I don't use these right
now, but there's a lot of battery powered devices that SHOULD be using
these devices if they are not currently using them. If you have a
battery powered circuit that doesn't need a lot of MIPS, the MSP is
probably the best option. TI has a bunch of new improvements coming in
this line, and it's getting hard to ignore.

> the software considerations/standard platform
issues overruled which
chip was better.

That's right, unfortunately. I can understand that many engineers
don't want to learn completely different families of devices, and
there's a certain understandable resistance to change. A few years ago
the Arm was almost unchallenged in terms of MIPS per watt (I don't
know if the PowerPC was competitive - I never knew much about them),
and now that other chips are able to compete its almost too late
because people have already adjusted to using Arm chips in this
sector, and the cost of Arm chips has dropped to commodity levels (I
can imagine this at Starbucks: would you like a free Arm chip with
your cup of coffee?).

At times like this, however, sometimes I remember the famous quote by
Jimmy Carter (and perhaps the only wise thing he's known for): "why
not the best?" I'm getting tired of making stupid comprimises to
please people who don't even know what they're talking about.
Sometimes I just want the freedom to study the spec sheets and pick
the best device for a given purpose!

Eric
	

Hi,

I am contemplating porting a application from a HCS12 to a ColdFire with 
embedded flash e.g. 256k/32k or 512k/64k  flash and SRAM.

I am interested in knowing whether the same code compiled for a ColdFire 
device will take up the same space due to 32 bit address allingment and the 
restrictions that even alligned addressing of certain processors pose. Lets 
say on a HCS12 the application might compile to a code space of 250k 
however, the same code (and I suppose it depends on the compiler) might span 
300k on a Coldfire device.

I also would like to know whether the ColdFire allow no- alligned data 
structures and variables, e.g. lets say a 8 bit variable - will it take up 
32bits.

Thanks
	----- Original Message ----- 
From: "Eric Engler" <englere.geo@engl...>
To: <68HC12@68HC...>
Sent: Saturday, March 18, 2006 4:20 PM
Subject: [68HC12] Re: Coldfire [was--Freescale's new roadmap - 9s12 not 
looking good?]
	> --- In 68HC12@68HC..., "Kerry Berland" <kerry.berland@...>
wrote:
>
>> GUI support for ARM is hard to compete with, and the architectural
>> choice for GUI systems is dominated by software rather than
>> hardware.
>
> You're correct that ARM has a serious lead, and not just on software.
> The hardware is also cheaper on the ARM side. I doubt if the Coldfire
> devices will be that cheap, given a similar mix of
> USB/Ethernet/flash/RAM, etc.
>
> I have to re-iterate that the ARM is just plain nasty at the assembler
> level, so many apps that require low-level coding (perhaps routers and
> multi-media, among others) will be better off with Coldfire. But if
> you can get by with a good C compiler, then the issue comes down to
> third-party software and hardware/software tool support, and chip
> cost, of course.
>
> There's another segment of embedded processors that has been growing
> exponentially: very low power MSP430 devices. I don't use these right
> now, but there's a lot of battery powered devices that SHOULD be using
> these devices if they are not currently using them. If you have a
> battery powered circuit that doesn't need a lot of MIPS, the MSP is
> probably the best option. TI has a bunch of new improvements coming in
> this line, and it's getting hard to ignore.
>
>> the software considerations/standard platform issues overruled which
> chip was better.
>
> That's right, unfortunately. I can understand that many engineers
> don't want to learn completely different families of devices, and
> there's a certain understandable resistance to change. A few years ago
> the Arm was almost unchallenged in terms of MIPS per watt (I don't
> know if the PowerPC was competitive - I never knew much about them),
> and now that other chips are able to compete its almost too late
> because people have already adjusted to using Arm chips in this
> sector, and the cost of Arm chips has dropped to commodity levels (I
> can imagine this at Starbucks: would you like a free Arm chip with
> your cup of coffee?).
>
> At times like this, however, sometimes I remember the famous quote by
> Jimmy Carter (and perhaps the only wise thing he's known for):
"why
> not the best?" I'm getting tired of making stupid comprimises to
> please people who don't even know what they're talking about.
> Sometimes I just want the freedom to study the spec sheets and pick
> the best device for a given purpose!
>
> Eric
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
	

In case anybody is interested in a very nice Coldfire development kit, take
a look at the WildFire board from www.steroidmicros.com  They also
provide a uCLinux development package (which is what I am playing
with).  I am not affiliated with them but I did write a CAN driver for
 the coldfire board for them but these comments come as a satisfied
customer.  I still prefer the HC12 whenever possible but the ability to run
uCLinux with all the built in ethernet support is pretty sweet.
Steve

Steven D. Letkeman BSc.
President - Zanthic Technologies Inc.
403-526-8318
www.zanthic.com Embedded micro-controllers and CAN interfaces
www.brightan.com Automated lighting systems

----- Original Message ----- 
From: "Frank" <linktek@link...>
To: <68HC12@68HC...>
Sent: Monday, March 20, 2006 12:20 PM
Subject: Re: [68HC12] Re: Coldfire [was--Freescale's new roadmap - 9s12 not

looking good?]
	> Hi,
>
> I am contemplating porting a application from a HCS12 to a ColdFire with
> embedded flash e.g. 256k/32k or 512k/64k  flash and SRAM.
>
> I am interested in knowing whether the same code compiled for a ColdFire
> device will take up the same space due to 32 bit address allingment and 
> the
> restrictions that even alligned addressing of certain processors pose. 
> Lets
> say on a HCS12 the application might compile to a code space of 250k
> however, the same code (and I suppose it depends on the compiler) might 
> span
> 300k on a Coldfire device.
>
> I also would like to know whether the ColdFire allow no- alligned data
> structures and variables, e.g. lets say a 8 bit variable - will it take up
> 32bits.
>
> Thanks
>
>
>
> ----- Original Message ----- 
> From: "Eric Engler" <englere.geo@engl...>
> To: <68HC12@68HC...>
> Sent: Saturday, March 18, 2006 4:20 PM
> Subject: [68HC12] Re: Coldfire [was--Freescale's new roadmap - 9s12
not
> looking good?]
>
>
>> --- In 68HC12@68HC..., "Kerry Berland"
<kerry.berland@...> wrote:
>>
>>> GUI support for ARM is hard to compete with, and the architectural
>>> choice for GUI systems is dominated by software rather than
>>> hardware.
>>
>> You're correct that ARM has a serious lead, and not just on
software.
>> The hardware is also cheaper on the ARM side. I doubt if the Coldfire
>> devices will be that cheap, given a similar mix of
>> USB/Ethernet/flash/RAM, etc.
>>
>> I have to re-iterate that the ARM is just plain nasty at the assembler
>> level, so many apps that require low-level coding (perhaps routers and
>> multi-media, among others) will be better off with Coldfire. But if
>> you can get by with a good C compiler, then the issue comes down to
>> third-party software and hardware/software tool support, and chip
>> cost, of course.
>>
>> There's another segment of embedded processors that has been
growing
>> exponentially: very low power MSP430 devices. I don't use these
right
>> now, but there's a lot of battery powered devices that SHOULD be
using
>> these devices if they are not currently using them. If you have a
>> battery powered circuit that doesn't need a lot of MIPS, the MSP
is
>> probably the best option. TI has a bunch of new improvements coming in
>> this line, and it's getting hard to ignore.
>>
>>> the software considerations/standard platform issues overruled
which
>> chip was better.
>>
>> That's right, unfortunately. I can understand that many engineers
>> don't want to learn completely different families of devices, and
>> there's a certain understandable resistance to change. A few years
ago
>> the Arm was almost unchallenged in terms of MIPS per watt (I don't
>> know if the PowerPC was competitive - I never knew much about them),
>> and now that other chips are able to compete its almost too late
>> because people have already adjusted to using Arm chips in this
>> sector, and the cost of Arm chips has dropped to commodity levels (I
>> can imagine this at Starbucks: would you like a free Arm chip with
>> your cup of coffee?).
>>
>> At times like this, however, sometimes I remember the famous quote by
>> Jimmy Carter (and perhaps the only wise thing he's known for):
"why
>> not the best?" I'm getting tired of making stupid comprimises
to
>> please people who don't even know what they're talking about.
>> Sometimes I just want the freedom to study the spec sheets and pick
>> the best device for a given purpose!
>>
>> Eric
>>
>>
>>
>>
>>
>>
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
	

Good day Frank,

> I am interested in knowing whether the same code
compiled for a ColdFire
> device will take up the same space due to 32 bit address allingment and 
> the

You are in luck...  I am working on a HC12 and a CF project that uses the 
same code.  Actually, I develop on a CF platform and then target to a 
9S12... which means that I can actually see the compiled code information on 
both platforms.  As background, I am using Codewarrior (CW) for both the 
HC12 and the CF (although they are both CW, they are in fact internally 
different products and so the compilers are effectively different).  Anyway, 
looking at the compiled (c) code sections, it appears the CF output code 
seems to be vary between 1.48 to 1.6 times that of the HC12.  This factor 
can vary, as small pieces of code can reach as high as 1.8 times.  This 
information may be slightly skewed, as I am looking at particular routines 
as opposed to an entire application, however, it is somewhat representative.

> I also would like to know whether the ColdFire
allow no- alligned data
> structures and variables, e.g. lets say a 8 bit variable - will it take up

On the CF data is aligned on 16-bit boundaries... so an 8 bit data value 
will occupy 16 bits.  In my case the data space difference between the CF 
and HC12 was not very significant, as my data/structures mostly aligned on 
16 boundaries... overall perhaps 5% larger data space on the CF.

I hope this helps.

Cheers,

Sam
	----- Original Message ----- 
From: "Frank" <linktek@link...>
To: <68HC12@68HC...>
Sent: Monday, March 20, 2006 12:20 PM
Subject: Re: [68HC12] Re: Coldfire [was--Freescale's new roadmap - 9s12 not

looking good?]
	> Hi,
>
> I am contemplating porting a application from a HCS12 to a ColdFire with
> embedded flash e.g. 256k/32k or 512k/64k  flash and SRAM.
>
> I am interested in knowing whether the same code compiled for a ColdFire
> device will take up the same space due to 32 bit address allingment and 
> the
> restrictions that even alligned addressing of certain processors pose. 
> Lets
> say on a HCS12 the application might compile to a code space of 250k
> however, the same code (and I suppose it depends on the compiler) might 
> span
> 300k on a Coldfire device.
>
> I also would like to know whether the ColdFire allow no- alligned data
> structures and variables, e.g. lets say a 8 bit variable - will it take up
> 32bits.
>
> Thanks
>
	

Hi Sam,

Extremely useful information - thanks very much. With a factor of 1.5 my 
256k code would require 128k of additional space so it seems that the 
MCF5282 might be the closest fit for this scenario.

Thanks
Frank

----- Original Message ----- 
From: "Sam Saprunoff" <sams2@sams...>
To: <68HC12@68HC...>
Sent: Tuesday, March 21, 2006 1:41 PM
Subject: Re: [68HC12] Re: Coldfire [was--Freescale's new roadmap - 9s12 not

looking good?]
	> Good day Frank,
>
>> I am interested in knowing whether the same code compiled for a
ColdFire
>> device will take up the same space due to 32 bit address allingment and
>> the
>
> You are in luck...  I am working on a HC12 and a CF project that uses the
> same code.  Actually, I develop on a CF platform and then target to a
> 9S12... which means that I can actually see the compiled code information 
> on
> both platforms.  As background, I am using Codewarrior (CW) for both the
> HC12 and the CF (although they are both CW, they are in fact internally
> different products and so the compilers are effectively different). 
> Anyway,
> looking at the compiled (c) code sections, it appears the CF output code
> seems to be vary between 1.48 to 1.6 times that of the HC12.  This factor
> can vary, as small pieces of code can reach as high as 1.8 times.  This
> information may be slightly skewed, as I am looking at particular routines
> as opposed to an entire application, however, it is somewhat 
> representative.
>
>> I also would like to know whether the ColdFire allow no- alligned data
>> structures and variables, e.g. lets say a 8 bit variable - will it take

>> up
>
> On the CF data is aligned on 16-bit boundaries... so an 8 bit data value
> will occupy 16 bits.  In my case the data space difference between the CF
> and HC12 was not very significant, as my data/structures mostly aligned on
> 16 boundaries... overall perhaps 5% larger data space on the CF.
>
> I hope this helps.
>
> Cheers,
>
> Sam
>
>
> ----- Original Message ----- 
> From: "Frank" <linktek@link...>
> To: <68HC12@68HC...>
> Sent: Monday, March 20, 2006 12:20 PM
> Subject: Re: [68HC12] Re: Coldfire [was--Freescale's new roadmap -
9s12 
> not
> looking good?]
>
>
>> Hi,
>>
>> I am contemplating porting a application from a HCS12 to a ColdFire
with
>> embedded flash e.g. 256k/32k or 512k/64k  flash and SRAM.
>>
>> I am interested in knowing whether the same code compiled for a
ColdFire
>> device will take up the same space due to 32 bit address allingment and
>> the
>> restrictions that even alligned addressing of certain processors pose.
>> Lets
>> say on a HCS12 the application might compile to a code space of 250k
>> however, the same code (and I suppose it depends on the compiler) might
>> span
>> 300k on a Coldfire device.
>>
>> I also would like to know whether the ColdFire allow no- alligned data
>> structures and variables, e.g. lets say a 8 bit variable - will it take

>> up
>> 32bits.
>>
>> Thanks
>>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
	

Sam Saprunoff wrote:

[very interesting stuff about S12 <-> CF comparison]

thanks for this comaprison!

> HC12 and the CF (although they are both CW, they
are in fact internally 
> different products and so the compilers are effectively different). 
Anyway, 

CW/S12 is Hiware. Do you know who made the CF compiler?

> looking at the compiled (c) code sections, it
appears the CF output code 
> seems to be vary between 1.48 to 1.6 times that of the HC12.  This factor 

very interesting. Do you have also a speed comparison?

Oliver
-- 
Oliver Betz, Muenchen
	

Oliver,

>CW/S12 is Hiware. Do you know who made the CF
compiler?

The S12 one comes from HIWARE, and the CF one comes from Metrowerks.
Both are now Freescale.

Regards,
Erich

-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf Of
Oliver Betz
Sent: Wednesday, March 22, 2006 8:30 AM
To: 68HC12@68HC...
Subject: Re: [68HC12] Re: Coldfire [was--Freescale's new roadmap - 9s12 not
looking good?]
	Sam Saprunoff wrote:

[very interesting stuff about S12 <-> CF comparison]

thanks for this comaprison!

> HC12 and the CF (although they are both CW, they
are in fact 
> internally
> different products and so the compilers are effectively different).
Anyway, 

CW/S12 is Hiware. Do you know who made the CF compiler?

> looking at the compiled (c) code sections, it
appears the CF output 
> code
> seems to be vary between 1.48 to 1.6 times that of the HC12.  This factor 

very interesting. Do you have also a speed comparison?

Oliver
-- 
Oliver Betz, Muenchen
	Yahoo! Groups Links