Frage

Eine Firma für die ich beraten sucht, auf mein Drängen auf Schalter auf Geräte von .NET Micro Framework basiert, so dass wir Geräte schneller auf den Markt bringen kann. Die Idee, in der Theorie zumindest, dass in C # Codierung anstatt C oder Assembler viel schneller und weniger Fehler anfällig sein wird. Wie ich schon sagte, das alles Theorie, da ich nie ein Embedded-Gerät programmiert haben.

Meine Fragen sind wie folgt:

  1. Ist die .NET Micro Framework zur Aufgabe?
  2. Was sind einige der Dinge sind die .NET Micro Framework nicht tun kann?
  3. Was sind einige der gotchas sind?
  4. Gibt es eine tragfähige 3rd-Party-Marktplatz Geräte für Plugin? Ich habe nicht viel auf der Microsoft-Website.
  5. Kann jemand Punkt zu einem kommerziellen Gerät, das mit dem MF-Framework entwickelt wurde.

Danke.

War es hilfreich?

Lösung

Ohne Ihre Anwendung und die aktuelle Leistungsfähigkeit des Embedded-Geräts zu wissen, wird es schwer für mich, eine endgültige Stellungnahme zu geben, wenn .NET MF ist bis zur Aufgabe. Wenn das eingebettete Gerät ein Low-Power-8-Bit-CPU mit 2 KB RAM und 32 KB ROM ist dann würde das .NET MF nicht für diesen Entwurf geeignet sein.

In einer Vielzahl von Fällen die Umstellung auf .NET MF Hardware-Änderungen mit einem Chipsatz von vielen Anbietern begünstigte beinhalten würde, die typischerweise ARM7 oder ARM9 Kern Ziel. Der Hauptgrund dafür ist die Arbeit, die bereits bei der Portierung des HAL und Cross-Kompilieren des PAL & TinyCLR zu dem nativen Code für den Prozessor in Frage getan zu nutzen. Dann, wenn Sie Anwendung des .NET MF Modell paßt, müssen Sie nur verwalteten Code entwickeln.

Ein Vergleich der Development Boards könnten Ihnen helfen, eine Plattform für ein neues Design auswählen . Der Vorteil der GHI Produkte ist, dass Sie die blanken Chipsätze mit der Firmware erwerben können, dass sie sich entwickelt haben mit Ihrem Hardware-Design zu integrieren.

Antwort zu Frage 1: Ist die .NET Micro Framework bis zur Aufgabe

  

Sorry, ich kann nicht ohne weitere Informationen diese über Ihre Anwendung beantworten.

Antwort auf Frage 2: Was sind einige der Dinge, die .NET Micro Framework nicht tun können,

?
  

Das Mikro-Framework ist nicht in Echtzeit, wie so viele der konkurrierenden Produkte. Der Scheduler ist ziemlich einfach und nicht für Systeme optimiert, die deterministische Timing erfordern.
  Die TinyCLR interpretiert die IL aus dem nächsten waiting „Faden“ für einen 20 ms. Themen können durch den Aufruf Thread.Sleep(0) ihnen zugewiesenen Zeitscheibe ergeben. NUR zwischen jeder Thread Zeitscheibe verwalteten Code der Runtime Interpreter Check-Flags von der Hardware-und Versand Event oder Threads aufwachen, wenn sie für die Hardware-blocked warten. Soweit ich verstehe, gibt es keine Möglichkeit für einen Thread von nativen Code Interrupt-Service-Routinen nicht blockiert zu sein (ISR) oder für einen Thread mit höherer Priorität präventiv eine niedrigere Priorität Thread unterbrochen wird.

Antwort zu Frage 3: Was sind einige der gotchas

?
  

Alles scheint zu funktionieren, haben Sie verstanden die, wie die Laufzeit interperter Schleife Arbeiten (die Planung von Threads und die Reaktion auf Hardware-Ereignisse), und Sie dann über GARBAGE COLLECTION vergessen !!
  Bestes, um die Menge an Dreschen des Speichers (Bewertung sorgfältig jedes Mal, wenn Sie ein Objekt new) zu minimieren. Statt der Schaffung und häufig verwendete Objekte zu zerstören, sollten Sie einen Pool von Objekten in der Regel GC'd und recycle halten sie, wenn wieder benötigt werden.

Antwort zu Frage 4: Gibt es eine tragfähige 3rd-Party-Marktplatz Geräte für Plugin

  

Die Beteiligung Dritter ist vor allem in den Entwicklungs-Boards und Referenzdesign auf der Hardware-Seite der Dinge. Aus Sicht der Software, dieser Code-Share-Link könnte von Interesse sein. Als Nebenaspekt, vergessen Sie nicht, dass die meisten der VS2008-Entwicklungs-Tool auch die Arbeit an .NET MF (zum Beispiel ReSharper und VisualSVN)

Leider hat keine Antwort auf Frage 5, wie ich diese Art der Sache nicht folgen. Die Zielseite für .NET MF auf Microsoft scheint ein Bild von kommerziellen Geräten zu haben, aber ich habe noch nie die Links gefolgt.

Andere Tipps

Das .NET Micro Framework ist sehr einfach zu Arbeit im Vergleich zu vielen der anderen Embedded-Plattformen ich mit gearbeitet haben. Aber es muss noch einige ziehen Rücken wie das Fehlen von Echtzeit-Unterstützung. Auch einige der SDK-Kits haben Probleme aufgrund von Hardware-Contention aller Zusatzgeräte die gleichen Busse verwenden. Wenn Sie Tonnen Geräte aus Ihrem Controller hängen brauchen würde ich stattdessen auf der Windows CE-Plattform aussehen. Die aktuelle Auswahl von Hardware für die Micro Framework ist nur sehr begrenzt.

Große Plattform und für kleine Projekte wäre es toll. Aber wenn Sie versuchen, um in nahezu Echtzeit-Anforderungen Sie können beginnen in Beulen zu laufen.

Wie so vieles andere in dieser Branche hängt es. Aber die Tatsache, Ihr kann eine Entwicklung erhalten Kit für die darunter $ 100 Dollar wert in sein könnte.


habe ich die Tahoe-II von DeviceSolutions.Net mit .NET Micro Framework 2.0 / 3.0 und C#. Threading war sehr einfach, aber das Gerüst zur Zeit sehr begrenzt. Ich musste meine eigenen HTTP-Parser erstellen und roh RESTful webservies erstellen. Es ist ein Gerät, Web-Service-Modell, aber ich wollte reinen HTTP. Ich hatte auch Schichten meiner eigenen SNTP und SMTP-Protokoll zu erstellen. Eine neue Version (4.0) sollte Release kurz sein, und es kann in einigen dieser Fehlbeträge füllen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top