Expériences de programmation avec le .NET Micro Framework

Question

Une entreprise pour laquelle je consulte cherche, à ma demande, à passer à des appareils alimentés par le .NET Micro Framework, afin que nous puissions commercialiser plus rapidement les appareils.L'idée, du moins en théorie, est que le codage en C# plutôt qu'en C ou en assemblage sera beaucoup plus rapide et moins sujet aux bogues.Comme je l'ai dit, tout cela est théorique, car je n'ai jamais programmé de périphérique embarqué.

Mes questions sont les suivantes :

1. Le .NET Micro Framework est-il à la hauteur ?
2. Quelles sont certaines des choses que le .NET Micro Framework ne peut pas faire ?
3. Quels sont les pièges ?
4. Existe-t-il un marché tiers viable pour les appareils plug-in ?Je n'ai pas vu grand-chose sur le site de Microsoft.
5. Quelqu'un peut-il indiquer un appareil commercial développé avec le framework MF.

Merci.

Answer 1

Sans connaître votre application et les capacités actuelles du périphérique embarqué, il me sera difficile de donner un avis définitif si .NET MF est à la hauteur.Si le périphérique intégré est un processeur 8 bits à faible consommation avec 2 Ko de RAM et 32 ​​​​Ko de ROM, le .NET MF ne conviendra pas à cette conception.

Dans un grand nombre de cas, le passage à .NET MF impliquerait des modifications matérielles d'un chipset privilégié par de nombreux fournisseurs qui ciblent généralement les cœurs ARM7 ou ARM9.La raison principale en est de tirer parti du travail déjà effectué en matière de portage du HAL et de compilation croisée du PAL et du TinyCLR vers le code natif du processeur en question.Ensuite, si votre application correspond au modèle .NET MF, il vous suffit de développer du code managé.

Une comparaison de conseils de développement pourrait vous aider à sélectionner une plate-forme pour un nouveau design.L'avantage du Produits GHI est que vous pouvez acheter les chipsets nus avec le micrologiciel qu'ils ont développé pour s'intégrer à la conception de votre matériel.

Réponse à la question 1 :Le .NET Micro Framework est-il à la hauteur ?

Désolé, je ne peux pas répondre à cette question concernant votre candidature sans plus d'informations.

Réponse à la question 2 :Quelles sont certaines des choses que le .NET Micro Framework ne peut pas faire ?

Le micro-framework n’est pas en temps réel comme la plupart des produits concurrents.Le planificateur est assez simple et n'est pas optimisé pour les systèmes nécessitant un timing déterministe.
Le TinyCLR interprète l'IL du prochain "thread" en attente pendant 20 ms.Les threads peuvent céder la tranche de temps qui leur est impartie en appelant Thread.Sleep(0).SEULEMENT entre chaque tranche de temps de thread, l'interpréteur d'exécution vérifiera les indicateurs du matériel et distribuera les événements au code managé ou réveillera les threads s'ils sont bloqués en attente de matériel.Autant que je sache, il n'existe aucun moyen pour qu'un thread soit débloqué des routines de service d'interruption de code natif (ISR) ou pour qu'un thread de priorité supérieure interrompe de manière préventive un thread de priorité inférieure.

Réponse à la question 3 :Quels sont les pièges ?

Tout semble fonctionner, vous avez compris le fonctionnement de la boucle d'interpréteur d'exécution (la planification des threads et la réaction aux événements matériels) et vous oubliez ensuite GARBAGE COLLECTION !!
Il est préférable de minimiser la quantité de mémoire utilisée (vérifiez attentivement chaque fois que vous new un objet).Au lieu de créer et de détruire des objets couramment utilisés, envisagez de conserver un pool d'objets généralement GC et de les recycler lorsque vous en avez à nouveau besoin.

Réponse à la question 4 :Existe-t-il un marché tiers viable pour les appareils plug-in ?

L'implication de tiers concerne principalement les cartes de développement et les conceptions de référence du côté matériel.D'un point de vue logiciel, cela lien de partage de code pourrait être intéressant.En parallèle, n'oubliez pas que la plupart des outils de développement VS2008 fonctionnent également sur .NET MF (par ex.Resharper et VisualSVN)

Désolé, je n'ai pas de réponse à la question 5 car je ne suis pas ce genre de choses.Le page de destination pour .NET MF sur Microsoft semble avoir des images d'appareils commerciaux mais je n'ai jamais suivi les liens.

Answer 2

Le Framework .Net Micro est très simple à travailler avec par rapport à la plupart des autres plates-formes embarquées j'ai travaillé. Mais il ne actuellement plusieurs dossiers de tirage tels que le manque de soutien en temps réel. En outre, certains des kits SDK ont des problèmes liés à l'affirmation matérielle de tous les périphériques add-on en utilisant les mêmes bus. Si vous avez besoin de tonnes de dispositifs suspendus votre contrôleur, je regardais la plate-forme Windows CE à la place. La sélection actuelle du matériel pour le Micro Framework est juste très limité.

Grande plate-forme et pour les petits projets que ce serait formidable. Mais lorsque vous essayez d'entrer dans les exigences en temps quasi réel, vous pouvez commencer à courir dans les bosses.

Comme tant d'autres dans cette industrie, il dépend. Mais pour le fait que votre peut obtenir un développement kit pour moins de 100 $ dollars, il pourrait être utile de vérifier dans.

---

I utilisé le Tahoe-II de DeviceSolutions.Net avec .NET Micro Framework 2.0 / 3.0 et C#. Threading était très simple, mais le cadre est actuellement très limité. Je devais créer mon propre analyseur HTTP et créer brut webservies RESTful. Il existe un modèle de service Web Device, mais je voulais HTTP pur. Je devais aussi créer mes propres couches de protocole SNTP et SMTP. Une nouvelle version (4.0) devrait être communiqué sous peu et il peut remplir certaines de ces petites chutes.