Lo que es importante entender es que .NET MicroFramework es un entorno de tiempo de ejecución administrado por memoria. Para simplificar la explicación, es básicamente un programa que implementa una máquina virtual . La ventaja de esto es que el código que usted escribe en el nivel de la aplicación se ejecuta en esta máquina virtual y utiliza todo tipo de objetos dinámicos que pueden aumentar y reducir su tamaño y desaparecer cuando no lo hace. Úsalos más, y todo esto sucede muy bien entre bastidores.
Estediagramarepresentatodosloscomponentesnecesariosparaqueestosuceda.ElcódigoC#queescribeestáenelniveldelaaplicaciónyestá"Administrado", que se ejecuta en la "máquina virtual". Todo lo que está debajo es "Nativo", que se ejecuta en el hardware real. En algún momento alguien tuvo que portar el marco a una pieza particular de hardware para usted, esto se hace en la HAL (capa de abstracción de hardware) que tuvieron que escribir.
Como puede ver, todos estos componentes pueden sumar un tamaño de código muy grande (Flash), una gran cantidad de RAM en tiempo de ejecución y un lote más ciclos de CPU de los que tendría tomar para ejecutar un programa C compilado de forma nativa.
Esta es la razón por la que los dispositivos .NET MF requieren una gran cantidad de recursos y por qué un ARM7 en realidad es no excesivo si desea un rendimiento decente y suficiente espacio para su aplicación C #.
Aquí hay un publicación en el foro de netduino hablando un poco más sobre esto.
Para responder a su pregunta de cuál podría ser la forma más económica de obtener una placa .NET MF con Ethernet, probablemente sería copiar el diseño de netduino +, excepto con los componentes que necesita y usar su puerto .NET MF - que han puesto mucho esfuerzo pero se ha hecho accesible desde lo que entiendo .