.Net Micro Framwork Confusion

Hi,

I'm C# developer and often find myself working on a lot of USB stuff from a
managed perspective. By USB from a managed perspective, I mean performing USB
IO by means of Pinvoking windows API calls.

Anyways, I'm confused about what the .net MF actually is. Can somebody
explain what it means to me, a C# developer who often does IO with hardware?
What's the point of it? Is it meant to be used by someone like me, from
windows, or is it only meant to be used by code on chips in the device?

.Net Micro Framwork Confusion

A good place to start is here:
http://msdn2.microsoft.com/en-us/embedded/bb278106.aspx

But in a nutshell, the MF is an OS that allows very small embedded
applications written purely in C# to run in a very small footprint CLR.
This could run directly on the hardware or under a host OS.

From C# you can directly set and read GPIOs as well as catch interrupts.
For more complex bus architecture stuff you'll likely need something in the
OAL. So your C# application could easily include hardware drivers to do what
you want, provided that the OAL provides you the hooks to the physical
hardware you need.


--
Chris Tacke - Embedded MVP
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com
--

.Net Micro Framwork Confusion

So I just read 3 chapters from a .net mf book comming out:

http://www.dotnetmicroframework.com/

SO, .net mf is essentially a replacement for writing embedded code (whatever
that may be) on devices with ARM processors?

This sounds like pretty revolutionary stuff, am I mistaken?

In theory it's not limited to ARM (the emulator is running on x86 for example).

In theory it's not limited to ARM (the emulator is running on x86 for
example).  And yes, I'd agree it's revolutionary.


--
Chris Tacke - Embedded MVP
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com
--

The .NET Micro Framework brings .NET to very small devices.

The .NET Micro Framework brings .NET to very small devices. It provides a CLR
and al that a CLR implies (managed code, automatic garbage collection, etc).
For someone like you who deals with a lot of I/O devices, the framework makes
your life a lot easier. The reason is that the framework supports standard
communication interfaces (USB, Serial, GPIO, SPI, etc). It uses a managed
driver model that enables you to communicate with peripheral hardware over
these interfaces. To do so, you write a managed driver in C#.

So, for instance, say you have a new type of sensor that can be connected to
a GPIO. It doesn't matter that the framework wasn't initially built to
support your sensor, and you don't have to wait for drivers from Microsoft or
the sensor manufacturer. You can write one yourself, and it's usually pretty
straightforward. Once you've written the driver, your application can
communicate easily with the device.

With standard interface support and managed drivers, you can connect most
types of peripheral device to your base hardware platform as long as the
device supports the types of connections that the framework recognizes.
--
Programmer/Writer
.NET Micro Framework
Microsoft Corporation

.Net Micro Framwork Confusion

as long as the

1-  if the device has type of connection as ADC/DAC which is not supported
on framework? (I did not see any reference to ADC/DAC),  the MF can't access
such connection?

2- the .net MF is like any C/Basic embedded SW platform used with MCU's,
however, as C# and VS platform it is more advanced and more refined API to
use for MCU work.   CAMERA (CAM) input is a very useful tool in embedded
application and for remote application.
does .net MF would be capable of havinf such capability in the future or
such is limited by the MCU?

thanks
elwolv

Many ADC/DAC devices use SPI, I2C or some propietary synchronous serial

Many ADC/DAC devices use SPI, I2C or some propietary synchronous serial
communication, so those would be accessible (though you'd have to write a
driver for the part).


Again, depends on how the camera data comes in.  If it's a mapped parallel
interface it would be a fair bit of work that only the OEM could do.


--
Chris Tacke - Embedded MVP
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com
--

thank you chris.

thank you chris.

1- is there is amy reference articles on how to use spi/i2c to implement
interface to ADC/DAC hardware?

2- USB is a client not a host (a posted answer) used for upload the program
to MF board.

this means USB is not implemented for general use application.
why it can not be used for general communication with peripheral devices?

For MS: does implementing a full usb capability is prohibitive on such
platform? what are the technical issues, does it require hardware
implementations?  some MCU comes with USB, however, they are MCU with
dedicated USB? or MF implementation?

a hardware/SW implementation of the full USB into MF would create a major
hardware river of peripherals for the use with MF hardware platform?

if all peripherals  comply with a generic usb human intefrace, would that
make the application for MF simpler what are the issue involved in
implementing generic USB?

--
elwolv

No, but I've written a few and it's pretty simple.

No, but I've written a few and it's pretty simple.  Just pull up the data
sheet, look at the timing diagrams and write code that matches it.


Because they didn't have time and manpower to implement and test the
required OAL pieces to implement USB hosting.  It's not a small or simple
task.

.Net Micro Framwork Confusion

Sounds like you are describing USB-to-go devices which can act as a client,
or host a limited subset of devices (support for hubs is optional, for
instance).

thank you gentelmen for the infoUSB desirability is that you can offload

thank you gentelmen for the info

USB desirability is that you can offload different hardware function to the
peripheral.
the user can select what he wants to use to augment the board/MF selected
with extra capability to use during development or as supplement to the board
function.

one feature useful for development purpose is the ability to have FS where
data is logged to an external USB Flash/HD

it is clear to me that this API with its .net presentation framework will be
a major MCU OS for ARM controllers, ovetaken C development emvironment.

the question is: are we going to be able to use the ARM/MF package as low
cost MCU to mate with other specialty controller chips, like stepper and
servo motor control specialty chips that require communication through system
data bus?


--
elwolv

Seems yes -- you can interface with many busses such as I2C or SPI using GPIO

Seems yes -- you can interface with many busses such as I2C or SPI using
GPIO which .NETMF apparently supports, and integrators should provide
additional drivers exposing builtin peripherals such as synchronous serial
ports, counter registers, pwm, etc.