.NET Framework - Freescale Development Kit, and the cost of NET MF

Asked By Ala

06-May-07 05:37 PM

Greetings to all.

Has anyone tried the Development kit from Freescale? All the information
about the kit is on line, including the circuit schematics. Is it possible
for me to build a board myself, and flash the Framework (including necessary
native code) to my board and create a new product? Since the main goal of
Freescale is to sell CPUs, I would think they should make their port
available to all users at no/low cost.

In embedded/consumer market, cost is of utmost important. Every dollar
counts. A Freescale i.MXS MCU costs about $9 at small volume (a hundred), and
$7 at large volume (thousands). That is at the low end of similar MCUs and
that is good. However, third parties like Embedded Fusion sell them (with NET
MF pre-loaded) at like $39/each for 10000 (which is VERY large volume) and I
don't think that is going to fly. (I have tremendous respects to Embedded
Fusion and the folks there). This price may not be high in absolute terms but
if my competitors can get the MCU at $7 and I have to spend $39 then I can
see very little chance of success. The advantages of using the framework such
as ease of programming and a little fast to market doesn't mean much in this
embedded/consumer market. Moreover, those advantages come with tradeoffs such
as performance and flexibility compared to traditional C/C++ approach.

The Micro framework is way too cool and I love it! But from the business
prospective I would only consider using it in my products if it adds only a
dollar or two to the overall cost (I think somebody already mentioned this in
a previous post). So I would think the best strategy for Microsoft is to
partner with those big CPU vendors (Freescale/Intel/TI/Microship), port the
framework to a few well known CPUs and, most importantly, make the ports
available to developers at no/low cost.

Just my two cents.

--
Alan Xiao, Ph.D
Founder & CTO, Handheld Design, Inc.
http://handhelddesign.com

06-May-07 11:34 PM

Not generally, no. You'd still need to purchase the Porting Kit from MS
(under NDA) and then build and run it. There's a HUGE learning curve on the
porting kit as there are LOTS of subtleties involved and not a lot of
documentation just yet.

They do, but you need the porting kit first.

You get more than just the MCU for $39. You get the MCU + RAM + FLASH with
MF already ported and you get that on a surface mounted CPU that you can use
immediately. So your competitor starting with that $7 CPU has to do all that
work, and unless the volumes are HIGH the NRE cost amoratized across low
olumes will end up costing them more in price and time to market. This is
exactly why we created the Meridian CPU.

I'd have to disagree with that (and most of our customers would too! Those
are 2 VERY important reasons fro using the Micro framework and an existing
CPU/Module.



This is essentially the same sort of model used by Windows CE ad it hasn't
produced your theoretical results. There is more to any given system than
the port to a CPU core. And getting that code in place costs moey and time.
Thus the industry as awhole is shifting to pre-built modules and components.

07-May-07 02:04 AM

Steve, thanks for the comment.

I don't understand why one still needs the porting kit if Freescale already
ported the framework to their MCU. It is a matter of linking your application
with the runtime and flash the whole thing into the MCU, isn't it? Perhaps
the tools are not there just yet but I think that is doable, and should be
their goal eventually? Otherwise what is the use of the development kit for
product development? is Freescale going to sell MCUs with the Framework
preloaded just like Embedded Fusion? I doubt it.

You are correct that the $39 Meridian MCU includes a flash and a memory
chip. I am not sure the chips are needed simply because of the Framework. In
any case perhaps it is not $7 versus $39, instead it may be $10-$12 versus
$39. Still that is a huge advantage in low margin consumer products.

The market the Framework targets is different from other markets (such as
PDA) in that the end users will not see direct benefits of fancy underlying
technology. As long as two devices have the same functions they don't care at
all whether one runs a cool framework, or just plain old assembly. The
benefits of using new technology are only in development. As such the benefit
are pretty limited.

So how much value does the Framework add to a product? Let's do a simply
calculation. Suppose the development of a product of average complexity like
a MP3 player needs 12 man-months in traditional approach. Now with the
framework, it takes only 6 man-months, a 50 percent saving. (The efficiency
of C# over C/C++ is greater but we need to take into account of things like
the immaturity of the framework, lack of drivers, performance hit, etc).
Based on average U.S run rate of $120k per head per year, 6 man-months
translates to $60,000 saving. If the volume of the product is 10k, then we
are talking about only $6 saving each, and with volume of 60k, the saving is
only $1. That is why I said the acceptable add-on cost is around $1 - $2. And
we have not yet considered doing development in low-cost countries, which is
the norm nowadays.

With hardware getting cheaper and more powerful, software development needs
to keep up, and I really think the Framework is in the right direction.
However, cost needs to come down and to be commensurable with the current
approach. Right now when we develop an embedded product, we write our own
application code, link it to a kernel such as VxWorks or even Linux (or more
often no OS at all), flash the binary into our device and we have a product
at the cost of no much more than the hardware itself. I don't see any reason
why we can't do that with the Framework. In that case we simply replace the
can't flash (not port) the Framework to a particular MCU (to which the
Framework was already ported) instead of buying pre-loaded MCUs at a premium.
I have high hope that this will happen soon.

Regards,
Alan

07-May-07 02:26 AM

For all the same reason's you can't do it for CE. There is more to the port
than the core CPU. In most cases the CPU does not include RAM or FLASH which
must have support in the native port. What if NAND flash was used instead of
NOR flash to improve the price? That's still more porting involved. And
porting the runtime to a new CPU is an expensive proposition. Silicon
vendors have limited software dev resources and are notorious for generating
quick and dirty "samples" that kind of sort of work but are not production
quality. They can't support ALL possible operating environments themselves
so they leave it to the market to sort out, somebody has to pay for the
development effort and supporting it.

If you are shipping millions of units, it's viable to take on that cost
internally. If you are shipping only a few thousand units then it makes no
sense to take that on from a time to market nor fully amorotized unit cost
perspective. THe exact cutoff point depends on a lot of factors but is
typically is near a hundred thousand.

--
Steve Maillet
EmbeddedFusion
smaillet@EmbeddedFusion.com

07-May-07 03:41 AM

I totally understand the position of the hardware-manufacturers. They invest
a lot of time and money to make the Net MF port on their platform; any change
in underlying hardware would mean a development-effort on their Net MF port,
someone has to pay for it.

However, what Alan says about flashing your own CPU should be an option that
hardware vendors must consider. I'm currently exploring with the Digi Net MF
board and within a few days i hope to start experimenting with the EF
Meridian, but so far i have not found a way of upgrading the firmware while
they're in the field, or am i wrong?

I need to have an option to re-deploy my .Net MF application, while the
device is already working at the customers site. Now in some cases, this
might even include a .Net MF update if a bnew version is out. If there is no
option to flash the .Net MF embedded runtime ourselves, than how are we ever
going to accomplish this task?

07-May-07 10:26 AM

That's entirely possible with the Meridian CPU. At this time, neither MS nor
EmbeddedFusion currently have a stand alone tool that would do that for the
deployment area of the flash without Visual Studio. However, it's not
something that would be all that difficult to create. So that you could
provide end user updates for your applications

We have tools for updating the runtime and core libraries stand alone in the
field already. We currently don't ship them in the SDK as they are not
needed until we do an update, but they will be provided along with any
updates.

--
Steve Maillet
EmbeddedFusion
smaillet@EmbeddedFusion.com

07-May-07 07:50 PM

Kevin,

The Digi Connect ME allows field updates of firmware using the MFDeploy
utility included in the kit and available for download from MS.  Updating
your application without Visual Studio attached is a common problem and
something Microsoft has designed into the platform.  That said, you also can
control whether you want to allow updates or whether you want the unit to be
locked / frozen.

Best regards,

John Leier
Digi International
john dot leier at digi dot com

07-May-07 08:03 PM

Hi Alan,

I don't have to agree with Steve here, but I will because he is absolutely
right  :-)

Here are some things you need to make sure to consider:

- Chip designs are typically 3-4x the length and effort of a module design.
I wish chip designs were faster, because Digi is also a chip/silicon SoC
supplier, and faster time-to-market for chip customers means Digi gets
production orders earlier -- but that's not the real world.
- Your cost analysis includes only the additional software costs of the
application, not the cost of the developement of the underlying BSP and
long-term maintenance of it.
- You may or may not have accounted for UL and FCC testing costs and
complexity.  This is all included in the price of a module.
- Your product complexity probably goes up dramatically.  When using a
module, it is fairly typical to have a simple 2-layer carrier board; when
designing a chip-based solution, you very easily could be looking at an 8 to
10-layer board.  This not only affects your development time, but your
manufacturing costs and EMI testing.
- What's the opportunity cost of your hardware and software engineers while
building your chip-based design?

Chip-based designs can make sense, but usually only when the quantity gets
into the 10's of thousands.  That's why Digi advocates starting with a
module design to get to market quickly, then cost-reducing to a chip design
of your own or licensed when/if your quantities support it.

Best regards,

John Leier
Digi International
john dot leier at digi dot com

08-May-07 03:23 AM

John,

I think we are talking about the benefits of the MF Framework, not the
benefits of using modules in product design. Those are two different issues.
I agree that from time to time using a pre-built module like a power supply
module or even a CPU module will benefit product development. However, that
is besides the issue. The issue here is how much cost the Framework adds to a
product, whether we use a MCU module or just solder the MCU on our board.
Most of your points are related to just using modules. Please see below.




I don't see how chip designs are related to the Framework discussion.




Sorry for my ignorance but I don't know what BSP means. Using the Framework
does help long-term maintenance but for the market the Framework targets like
gadgets and consumer products I don't see a lot of needs for long term code
maintenance (because once you get the products out, there is little chance
for "bug fixes" :-)



Not specific to the Framework. Even using a module you still need to get
UL/FCC tests for the whole product, do you? In other words, using a module
doe not exempt you from those tests. The best we can say here is that modules
are usually well tested and proven work. That helps passing the tests of your
product.



You may have a point but I am not sure the benefit is significant in real
production. Handling fine pitch devices with large pin count and multi-layer
PCB should now be pretty common, otherwise the chip makers would still be
using DIP instead of BGA. Also the modules come with tradeoffs (mainly in
board size) because there are still the same number of pins in the module and
you merely rearrange them in a more convenient way. In any case this is
really not a Framework issue.



Again, I am not sure what you meant by chip-based design. I didn't mention
anywhere that we want to design a chip.

Cheers,
Alan

08-May-07 04:36 AM

Steve,

I understand there is always a cost associated with anything and that was
why I asked how much the NET MF costs. If it is $20 or $30 over a $7 MCU, so
be it. I don't think it will fly at that cost, but you never know.

But the thing I still don't understand is why building a module is the
preferred way to use the Framework, and why the good old approach of
building-your-own-binary-and flashing-it-to-MCU is no good anymore. The
Framework, cool and interesting, is not ground breaking or paradigm shifting
in terms of the way products are developed (correct me if I am wrong). It
merely uses a better programming language, and changes some terminology such
as calling the kernel "runtime" or "no OS". All the issues you mentioned,
such as dealing with different hardware, have existed and we know how to
handle them. They are not specific to the Framework. So I don't understand
why all of a sudden, we have to buy a module to just get a piece of software.
Perhaps that is a way to control license?

In fact, I would say the Framework actually facilitates the
flash-your-own-MCU approach. A MCU has all the (internal) peripherals such as
timers, UARTs, USB controller built-in. Those are handled by the native code.
They are all pretty much fixed so you won't have many different (internal)
hardware to deal with. That reduces the complexity of the Runtime (which is
hard to port). External peripherals such as keypads, GPS receivers, etc are
connected to the MCU by well defined interfaces such as GPIO and SPI. They
are handled by the application using C#. There are many different types of
external devices but because of the well-defined interface and C#, the
complexity is reduced. So we have the benefits of both worlds.

I am excited about the Framework because of the above reasons. But now I am
a little confused due to this module debate. I hope other people can chime in.

Regards,
Alan

08-May-07 08:22 AM

You *can* port it to an MCU by getting the porting kit.  One reason there's
a cost involved is because it takes a significant amount of training and
support to get someone to the point they can be effective with it.  While
the theory of all MCUs being the same and that a framework that could run
anywhere is a nice idea, the reality is not quite that way.  MCUs are
different.  They have different internal peripherals and different memory
maps.  And of course everyone wants to use something different.  There is
also the RAM and Flash issue that I believe Steve brought up (and yes, the
MF needs them).

The cost of design is what you're paying for with a module.  Many, many
customers would rather be companies that build solutions, not companies that
design PCBs.  I have no desire to do complex board layouts, manage part
obsolecense or any of the other tasks a hardware vendor has to do.  Like
many, I'd much rather use my company's time adding value and solving the
business problem at hand.  This is where a module approach makes good sense.

Sure, not everyone's business fits into that model, but it does fit a large
majority.  And until the framework and it's tools are in a more mature state
that allows easier porting, it makes sense to have Microsoft focus on
continuing to deliver features that we want instead of burning all of their
time trying to support a lot of people doing thier own ports.  I'd rather
see a networking stack than another company with the capability of porting
to an MCU.

But as I said, if you really want it ported to an MCU, I believe you can
still get the porting kit by talking directly with Microsoft or you can
avail yourself of one of the companies that have been doing MF porting for a
while now that can be contrracted to help.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com

08-May-07 01:12 PM

Again, I am not talking about porting. I know porting takes tremendous
effort. Please see all previous posts. All I am wondering is for those big
companies like Freescale who already ported the Framework to their MCU, why
can't they make the port available so developers can flash it into the blank
MCU on their own board? If there is a cost involved like $10  per MCU, OK.
Let the market decide whether that price will work or not. And that is all I
am suggesting. I am not asking for anything new. That is the way the industry
has been working, isn't it?

Do get me wrong. I have great respects to companies like Embedded Fusion and
Digi. I am not coming out to argue their business model which definitely has
some market. I am just looking at the Framework as well as the schematic put
up by Freescale, and thinking that they will have much greater potentials, if
things go the way I think they should go. I hope Microsoft and Freescale are
listening.

Just 2 cents from a humble user.

Regards,
Alan

08-May-07 02:45 PM

The problem with that approach is twofold.

First, the OEM would have to lock it to a specific MCU (or go target a least
common denominator MCU, which would make people wonder why they don't have
support for all of the MCU features) or produce framework images for
multiple MCUs.  That's a support nightmare.

Second, the OEM is a silicon vendor.  They want to ship silicon and not
write (and especially not support) software/firmware.  That's the same
reason you can't get ready-made CE images from them either, (and the BSPs
from silicon vendors are rarely, if ever, close to something you'd want to
ship). There's just no business case for them to handle an OS, so they hand
it off.  Again, maybe when the toolchain is more mature they'll provide
I'm not sure I'd use it anyway.

Now it may well be a viable business for someone to become an "integrator"
that generates an image for a specific MCU and provides licensing,
maintenace and support for that image.  The market will surely play that
out, and it seems that EmbeddedFusion is already hybridizing that model (if
you had the volume for it, they'd probably be happy to develop and license a
MCU-specific framework for you).


I'm certain they are.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com

09-May-07 06:37 AM

So if i understand correctly, when my devices are out there, running, and i
want/need to make an update to my application, i am able to do that over the
network without the use of VS2005?

And this is also the case when the .Net MF runtime is updated, i can also
deploy that remotely?

I understand that as for now there is not such a tool yet. There is
MFDeploy, asking for a hex file, but that's nowhere to be found. Probably
because there simply isn't a update of the .Net MF port yet or is the enduser
never going to get this?

Sorry if this seems like asking the same question over and over again, but i
need to be sure if we will be able to update our firmware remotely.

09-May-07 06:48 AM

John,

So what you are saying is that i will be able to do a field update of the
Net MF runtime by using MFDeploy, but that i still need VS2005 to do a
application update ?

Or is MFDeploy used to do the update for the framework as well as for the
application? (In that case, how does one creates that Hex file?)

p.s. What is Digi's policy on framework-port updates? Are those updates
available to customers who already bought a NetMF Connect ME module or do i
need to purchase a net MF license again?
Regards, Kevin

12-May-07 12:41 AM

Because they don't know what else you have connected to the MCU, type and
size of flash, RAM settings, LCD  config, etc...

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

18-May-07 09:18 AM

Not without VS, no. (at least not at this point)
MFDeploy is an option for the actual core run-time, and theoretically could
do the deployed application as well but it would take some work to get that
right. Application updates independent of VS are a common reques. Hopefully
we'll see something for that in the future. If the demand is high enough,
which I'd expect it to be, MS is likely to respnd with a solution. That
being said, someone who knows what they are doing could create such a tool
independent of MS. Even if it means a custom app and communication protocol
with the device boot loader.

--
Steve Maillet
EmbeddedFusion
smaillet@EmbeddedFusion.com

13-Jun-07 01:41 PM

Board support package -- i.e. drivers for the OS of your choice for the
devices attached to the microprocessor.  For microcontrollers, a group of
these devices are well known, not varying with the board layout.


This isn't true.  For example, the pins to the on-module memory needn't
leave the module.


He meant designing around a bare chip, not designing your own chip.