Forum: Mikrocontroller und Digitale Elektronik ARM .Net Microframework portierung Empfehlungen?


von Christian (Gast)


Lesenswert?

Hallo Team,

ich überlege einen Umstieg von AVR zu ARM Prozessoren zu tätigen.
Wie ich schon in diverse Foren lesen konnte, unterstützen ARM 
Prozessoren .net Microframework zur Programmierung.
Ich habe dann aber erfahren, dass das mit der Portierung alles andere 
als einfach ist. Hat damit schon jemand von euch Erfahrungen gemacht?

Das nächste Problem was ich habe, ist die Tatsache, dass die Controller 
zum Löten eher ungeeignet sind? (zu klein, zu viele PINs usw...)
Ich kann für mich selbst natürlich keine Multilayerplatine anfertigen, 
die wahrscheinlich alleine schon notwendig ist, um die ganzen Kontakte 
unterbringen zu können. Kennt ihr vielleicht günstige Adapterplatinen, 
die man verwenden könnte?


Das einzige(!) was der Controller für meine Zwecke integriert haben 
sollte, ist Ethernet und LCD (ich möchte später ein Touchscreen 
anbringen können)


Von Atmel habe ich schon welche gefunden, allerdings bin ich auch hier 
gezwungen ein ganzes Board zu kaufen, was ich aber vermeiden möchte!



Hat jemand Informationsquellen für mich?

Liebe Grüße,
Christian

von Lutz (Gast)


Lesenswert?

http://de.wikipedia.org/wiki/.NET_Micro_Framework#Technische_Voraussetzungen

Das sollte die Controllerauswahl schon deutlich eingrenzen.

von Christian (Gast)


Lesenswert?

Hallo Lutz,

Danke für den Link! Ich wusste bereits, dass ARM Prozessoren mein 
Vorhaben unterstützen. Viel mehr bin ich aber auf der Suche nach einem 
Controller bzw. einer Adapterplatine, die es mir möglich macht, den 
Controller zu verwenden, ohne ein Multilayerboard anfertigen lassen zu 
müssen.

Zudem komme ich trotz lesen einiger Tutorials nicht wirklich auf den 
Punkt, was genau ich brauche.

.Net Microframework läuft ja als "Betriebssystem" auf dem Controller.
So wie ich das verstanden habe, muss .Net Microframework dafür auf den 
Controller Portiert werden, richtig?

Deshalb sind in dem Portingkit auch schon diverse Controller gelistet.
- Kann ich mit der Controllerauswahl und der Portierung den Controller 
schon uneingeschränkt nutzen? Oder müssen dabei noch spezielle Dinge 
gemacht werden?
- Wie kommt das Microframework auf den Controller? (genauso wie man 
einen AVR Controller Flasht)?


Wenn das Microframework auf dem Controller ist, wird das entwickelte 
.Net Programm ja wieder auf den Controller geflasht.... Wie wird dabei 
unterschieden, damit das .Net Microframework nicht überschrieben wird? 
Oder habe ich dabei etwas falsch verstanden?

Liebe Grüße,
Christian

von Lutz (Gast)


Lesenswert?

Ehrlich gesagt habe ich mich mit dem Microframework nicht wirklich 
befaßt. Vor ein paar Monaten hatte ich mal davon gelesen und etwas 
nachgegoogelt. Ich hatte da den Eindruck, daß es von der Theorie zwar 
sehr interessant ist (wenn mein Gehirn nur mit einer Programmiersprache 
bei µC und PC klarkommen muß), aber kaum verbreitet ist. Zudem ist es 
nicht echtzeitfähig (wobei man über die genaue Definition bzw. harte 
Notwendigkeit schon ziemlich gut diskutieren kann). Auch sind die 
Resourcen ziemlich heftig, wenn man bisher mit 8 kB Flash und 1 kB RAM 
fast immer sehr gut auskam.

Wenn du da wirklich praktisch mit loslegen willst, solltest du dir ein 
Dev-Board bzw. Kit kaufen (Auswahl z.B. unter 
http://msdn.microsoft.com/en-us/netframework/ff962539). Um wirklich 
praktisch und variabel spielen zu können, wäre wohl das FEZ Spider sehr 
interessant. Kostet aber auch gleich 250 US$.
Rein theoretisch kann man vieles wohl auch im VS simulieren. Macht aber 
wohl kaum Spaß.

Christian schrieb:
> Zudem komme ich trotz lesen einiger Tutorials nicht wirklich auf den
> Punkt, was genau ich brauche.

Genau das war auch mein Ergebnis. Ich hatte den Eindruck, daß das ganze 
eher eine Philosophie als eine reale, alltagstaugliche Geschichte ist. 
Zumindest derzeit. Je mehr Ressourcen die Chips bekommen, desto "höhere" 
Hochsprachen sind möglich. Aber genau da kommt es dann auch wieder: Es 
kommt darauf an, was man eigentlich damit machen will. Und für meine 
Ansprüche tun es die AVR's und langsam vortastend auch die CM3. Bei noch 
höheren Ansprüchen landet man dann wohl schnell (vor allem auch 
preislich) bei Pandaboard etc.

von Severino R. (severino)


Lesenswert?

Ich habe gerade begonnen, mich einzulesen und habe folgende Quellen 
gefunden:

http://www.netduino.com
http://www.gsiot.info

Natürlich ist der Ressourcenbedarf wesentlich höher als bei einem 8bit 
uC, aber dafür kann man in C# objektorientiert programmieren und auf 
viele .NET-Klassen zugreifen.

Ich denke, es macht dort Sinn, wo eine normaler PC für eine bestimmte 
Aufgabe einfach Overkill ist oder die nötigen I/O (analog, digital) 
nicht hat, andererseits ein gewisser Komfort gewünscht wird (also z.B. 
vertraute Programmiersprache, Ethernet-Anschluss inkl. Software dazu).

Natürlich kann jemand, der tiefe Kenntnisse eines Mikrocontrollers und 
dessen Peripherie hat, z.B. in C tolle Sachen machen.
Aber wer gelegentlich mal einen Sensor per SPI oder I2C oder gar analog 
auslesen will und den Messwert per RS232/RS485 oder per Ethernet, ev. 
gar als HTTP-PUT versenden will, der ist wohl mit NETMF schneller am 
Ziel.

Und wenn es nicht um grosse Stückzahlen geht, kann man ja ein kleines 
Board nehmen und braucht den Prozessor nicht selber aufzulöten. Dann 
überwiegt nämlich die gesparte Zeit die höheren Kosten für die Hardware.

von Karl H. (kbuchegg)


Lesenswert?

Christian schrieb:

> .Net Microframework läuft ja als "Betriebssystem" auf dem Controller.
> So wie ich das verstanden habe, muss .Net Microframework dafür auf den
> Controller Portiert werden, richtig?

Richtig.
Und wenn das kein Fass ohne Boden werden soll, dann ist es wichtig, dass 
du ein fertiges Controllboard einkaufst, bei dem die Herstellerfirma 
diesen Port bereits für dich gemacht hat.

> Wenn das Microframework auf dem Controller ist, wird das
> entwickelte .Net Programm ja wieder auf den Controller geflasht....

Du musst dir das eher wie einen Bootloader vorstellen. Das Framework ist 
bereits auf dem Controller. Das C# Programm (bzw. dessen Übersetzung) 
wird per "Datenkabel" eingespielt und dann vom Framework interpretativ 
abgearbeitet.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

Schaue mal hier vorbei:

http://www.fs-net.de/cms/index.php?id=home

Die bieten Boards mit WinCE, Linux und .NET und entsprechende Treiber.
(ARM9 / ARM11)

von Christian (Gast)


Lesenswert?

Hallo Markus,

der Link sieht sehr gut aus! Habe dort mal eine Anfrage hin geschickt! 
Danke!

Wenn ich trotzdem selbst portieren möchte, sollte das nicht mit dem 
Portingkit von Microsoft relativ "einfach" sein?

Die haben schon Prozessoren in der Liste, die man auswählen kann. Wenn 
ich einen dieser kaufe und es tatsächlich schaffe, das Ding einzulöten, 
wäre damit alles erledigt? (Soweit erledigt, dass ich loslegen kann mit 
dem eigentlichen Thema: der Controllerprogrammierung in .Net?)

Echtzeit ist für meine Anwendung kein Thema, natürlich war mir bewusst, 
dass dieses Framework mehr ressourcen frisst. Wenn ich es aber dem 
gegenüberstelle, wie schnell ich mit meiner Lösung zum Ziel komme, ist 
das wahrscheinlich für mich der viel einfachere Weg.

Wenn das Framework mal auf dem Controller ist, ist dann noch 
interessant, welches Display ich zum Beispiel an den Controller hänge? 
Oder welche andere Hardware ich daran nutzen möchte? Spielt das beim 
grundsätzlichen Portieren eine Rolle? Oder geht es bei der Portierung 
lediglich um die "Herstellung des Untergrunds" welcher vielleicht 
vergleichbar ist mit der Installation eines .Net Frameworks auf Windows?

Lg. Christian

von Karl H. (kbuchegg)


Lesenswert?

Christian schrieb:

> grundsätzlichen Portieren eine Rolle? Oder geht es bei der Portierung
> lediglich um die "Herstellung des Untergrunds" welcher vielleicht
> vergleichbar ist mit der Installation eines .Net Frameworks auf Windows?

Beim Portieren geht es zu 90% darum, die Teile zu schreiben, die du von 
deinem PC als Gerätetreiber kennst. Klar gibts da schon viel fertiges. 
Aber der Teufel steckt im Detail.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

Am besten Du nutzt die Boards von F&S und stöpselst die in Dein Board 
oben drauf.
- Funktioniert garantiert
- Eigenes Projekt braucht keine 8-Layer Platine
- ...

Kostet zwar etwas, dafür spart man die viele Mann-Monate 
Treiberprogrammierung und Anpassung an Deine Hardware.

von Daniel (Gast)


Lesenswert?

Vielleicht ist dieser Link auch noch interessant für Dich:

http://www.aug-elektronik.at/Produkte/NETMicroFrameworkBoard/tabid/105/language/de-DE/Default.aspx

SG Daniel

von Karsten B. (karstenbrandt)


Lesenswert?

Hallo,

habe auch das .net micro framework gefunden und alles hier gelesen.
Nur schlauer bin ich noch nicht wirklich.
Zur Zeit schreibe ich mir die Klassen für den Controller selber.
Was ich aber möchte ist das micro framework nutzen.
Die Praxis sieht so aus:
Ich habe ein selbst gebasteltet Board mit einen Controller drauf (z.B. 
NXP 2214 oder Cortex M3) und zunächst keinen externen Speicher.
Wie passe verwende ich nun das framework mit meinem selfmade board?

Über das porting tool lassen sich Anpassungen vornehmen. Nur Wie werden 
die Ports zugewiesen (z.B. bei mehreren UARTs oder USB)?

Gibt es vielleich ein Beispielprojekt? (Die zu erwerbenden Board 
sprengen über 100€ mein budget. Speicher wollte ich auch nicht unbeding 
extern verwenden)


Für ein paar Tip wäre ich dankbar

EDIT:

Habe mir das NETDUINO-Board aus dem oberen Link angeschaut. Das 
entspricht in etwa meiner Vorstellung von einem Minimalboard ohne viel 
Schnick Schnack. Aber Wie gesagt: Wie passe ich das framework an?

Gruß

Karsten

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.