• Team Foundation Service: la version “in the cloud” de TFS
• TFS “Standard/Full” : la version la plus complète de TFS
• TFS Basic : version au fonctionnalité et déploiement simplifié
• TFS Express : le dernier arrivant

TFS Express, pour qui et pour quoi ?

TFS Express vient compléter la gamme “Express” des produits de développement tels que Visual Studio ou SQL Server. Comme ses compères , TFS Express est donc gratuit et destiné aux passionnés, débutants souhaitant démarrer l’ALM sur une équipe réduite.

Les fonctionnalités annoncées de TFS Express:

• Gestionnaire de configuration avec le Source Code Control
• Suivi des tâches avec le Work Item Tracking
• Compilation automatisé
• Tableau de tâches Agile

Cette gratuité apporte certaines limitations:

• TFS Express supporte 5 utilisateurs au maximum, il sera toujours possible de dépasser cette limite en achetant des CALs (Client Access Licenses).
• S’installe qu’avec SQL Server Express (ce qui peut se comprendre).
• Déploiement sur un unique serveur, pour 5 utilisateurs cela ne devrait pas poser de problème!

L’utilisation de TFS Express se fera via une nouvelle intégration dans la version Express de Visual Studio!

Et pour finir, Brian Harry promet une installation ultra simplifié à partir d’un EXE (qui a dit que l’installation de TFS aurait traumatisée des gens?)

Visual Studio 11, version Metro

La tendance se confirme: tout la gamme des produits Microsoft passe au style Metro, c’est sûr que le changement est radical! Pour ma part l’abandon de relief (“chrome” comme disent nos collègues Américains) au profit de la clarté et de la simplicité est une bonne chose.

Un petit screenshot veut mieux qu’un long discours:

Qu’attendre de cette version 11 de Visual Studio?

En vrac:

• Un Go Live le 29 Février, ce qui nous indique que cette beta est certainement très mature!
• Un Visual Studio plus rapide, plus réactif et moins buggé! Le passage à WPF pour Visual Studio 2010 aura laissé quelques traces et malgré les efforts de dernière minute pour optimiser au mieux il faut admettre que Visual Studio 2010 est assez lourd à l’utilisation (même si je ne reviendrais à la version 2008 pour rien au monde).
• Une expérience simplifier pour les développeurs. Microsoft nous avait promis qu’il corrigerait/simplifierait plein de scénarios utilisateur lié au développement de tous les jours.
• Développement pour Windows 8
• Et bien d’autres fonctionnalités!

On attend le 29 avec impatience!

Two ways to put under Source Control your NuGet package references

Let’s briefly describe these methods by starting with the first introduced in the tool

Full commit of packages

This method is kind of the “brute force” way to handle source control of the package: the whole content of the “packages” folder is put under source control.

Putting binaries under source control as a general practice is subject to many debates and I honestly couldn’t take a position. It’s supposed to be bad if your SCM tool can’t handle a big volume of data (for obvious reason) or if the bandwidth between your server and you is not great. Considering TFS capabilities (i.e. centralized model, compression of data exchange, storage on SQL Server) we’re pretty confident about storing a lot of binaries.

This method is the one used by default in Visual Studio, when you add a Package Reference to a project under source control, you get everything added to TFSC.

NuGet Package Restore

This method is the new one, supported from the version 1.6 of NuGet. It’s the answer to the many criticisms/remarks made to the NuGet team since the release of the tool. Where the “full commit” way could be harmless with SCM tools like TFS, it can’t be said so with tools like Git which apparently can’t handle without bad consequences the addition of so much binary data.

The Package Restore feature can be enabled by right clicking on the solution node in the Solution Explorer. When activating this feature, a new Solution Folder “.nuget” will be added to your solution and every project will be modified to use a new building target.

This new building target will check every time you start a build on a given project if the NuGet references specified by the packages.config file are present. If it’s not the case they will be downloaded and unpack.

This method is way lighter on the SCM side, the cost of NuGet is mainly the config files it adds to projects. The downside is the little extra time spent during compilation to check the existence of the packages.

Final word

Which way is better ? It’s a matter of taste, but personally I’ll use the Package Restore because even if TFS can handle the size of binaries, I prefer the light way. Considering the popularity of a distributed version of TFSC and the fact that TFS will be soon in the cloud you may not want to end up with a solution that doesn’t scale on the WAN.

Par exemple lorsque Visual Studio 2010 est sortit, les fonctionnalités Modeling liées à l’architecture étaient réservées au monde de .net. On peut le comprendre car pour développer ce genre de fonctionnalités on pourra se reposer sur le mécanisme de réflexion qu’offre la plateforme .net.

Lorsqu’un langage ne permet pas de faire de la réflexion (comme le C++), seul le parsing des sources d’un projet permet d’extraire les données que l’on souhaite analyser. Ceux qui font du C++ savent que parser efficacement un fichier .cpp relève de l’exploit que seul le parseur de votre compilateur préféré sait réellement faire.

Voilà pourquoi logiquement (malheureusement) les développeurs natifs ont été privés de ce genre d’outil…jusqu’à ce que le Visualization & Modeling Feature Pack point le bout de son .vsix.

Cette extension de Visual Studio est disponible pour les abonnés de la MSDN qui utilisent Visual Studio Ultimate, celle-ci offre bon nombre de nouvelles fonctionnalités (qui auront été coupées de la RTM ou demandées massivement par les utilisateurs).

Ce billet est consacré, vous l’aurez deviné, aux fonctionnalités liées au C++.

Génération de graphe de dépendances

Cette fonctionnalité de la brique Architect est maintenant iso fonctionnelle avec .net, il est possible de générer des graphes de dépendances pour les binaires, namespace et classes en C++. C’est une excellente nouvelle car même si un projet n’est pas gros il devient vite difficile de s’y retrouver lorsqu’il s’agit de C++. Cerise sur le gâteau, Microsoft nous offre une nouvelle fonctionnalité spécifique au C++: la possibilité de générer un graphe de dépendance des fichiers d’include!

A noter qu’il faudra attendre que l’Intellisense construise sa base de données avant de pouvoir générer un graphe

Pour générer un graphe des includes:

Voilà un exemple sur un projet du SDK de Direct X:

Créer un diagramme de couche et valider l’architecture

Encore une fonctionnalité qui était disponible en .net et qui l’est maintenant en C++. Le principe ne change pas:

• Vous pouvez créer un diagramme de couches logiques.
• Créer des relations entre les couches
• Associer des namespaces ou classes à celles-ci
• Vérifier que le diagramme logique est respecté dans la pratique en analysant les éléments de la solution.

Conclusion

Ces deux fonctionnalités apportent vraiment un plus au développement C++, certains outils comme CppDepend le faisait déjà, mais voilà un geste envers les développeurs natifs que l’on apprécie, en espérant qu’il y en aura d’autres.

La page du produit chez GHI.
Le PDF de la carte.
La classe qui permet de la manipuler.

Le fonctionnement du IO40 est relativement simple: la carte repose sur une puce contrôleur I²C qui s’occupera de “dispatcher” les signaux que vous aurez configuré à l’aide de la classe fournit.

Câblage

Je ne vais pas m’étaler sur le fonctionnement du port I²C, mais sachez que c’est un bus de communication en série très répandu (et pas qu’en robotique) et qu’il nécessite 4 fils:

• GND : la masse
• +5V
• SCL (Serial Clock) : l’horloge, pour rythmer l’envoie des données
• SDA (Serial Data) : pour le transport des données

On utilisera les deux port JST en bas à gauche pour connecter la carte au bus I²C du micro-contrôleur (I2C IN : SDA & SCL). Les deux autres ports JST servent à connecter en cascade une autre carte étant basé sur le bus.

SDA se branche sur I2C_DAT SCL se branche sur I2C_CLK

Ceux qui on l’œil remarqueront qu’on a branché 5 fils en tout, l’explication est toute simple: chaque prise JST comprend son propre fil relié à la masse (en noir) et à la tension haute (en rouge).

L’API de la carte

Dans la classe IO40 on retrouve les méthodes suivantes:

• MakePinOutput(byte port, byte pin): Configure une prise en sortie.
• MakePinInput(byte port, byte pin): Configure une prise en entrée.
• SetPin(byte port, byte pin): Met une prise (configurée en sortie donc) à 1.
• ClearPin(byte port, byte pin): Met une prise (configurée en sortie) à 0.
• ReadPin(byte port, byte pin): Lit l’état d’une prise (configurée en entrée).
• SetPortInputs(byte port, byte mask): configure toutes les prises d’un port en entrée (bit correspondant à 1) ou sortie (bit correspondant à 0).
• GetPortInputState : Lit la configuration entrée/sortie d’un port (la réciproque de SetPortInputs)
• ReadPort : Lit les valeurs de chaque prise configurée en entrée d’un port
• WritePort : Ecrit les valeurs pour chaque prise configurée en sortie d’un port

Un petit test

J’ai effectué un montage simple:

Une LED est branché sur la prise qui sera pilotée par le programme, une résistance permet d’abaisser la tension pour que la LED puisse fonctionner.

Le schéma du circuit et le code associé:

	private static void TestIO40()
	{
		var io = new IO40(0);

		// Make the pin 0 of port 0 an output
		io.MakePinOutput(0, 0);

		// Blink the LED 10 times
		for (int i = 0; i < 10; i++)
		{
			io.SetPin(0, 0);
			Thread.Sleep(250);
 			io.ClearPin(0, 0);
			Thread.Sleep(250);
		}
	}

La prise 0 du port 0 fait office de tension haute et l’autre prise n’est autre que la masse et le tour est joué!

La fiche de description du produit par son constructeur.
Le PDF des specs.
Disponible chez RobotShop par exemple.

Une image veut mieux qu’un long discours:

J’ai posté une petite vidéo qui démontre une utilisation très basique:

Le programme est tout bête:

// Object controlling the Servo controller (IO74)
Servo16 servo16 = new Servo16(FEZ_Pin.Digital.IO74);
// Object controlling the button (IO12)
Button myButton = new Button(FEZ_Pin.Digital.IO12);

// Wait for the button to be pushed
while (myButton.GetState() != Button.ButtonState.Pressed)
{
	Thread.Sleep(10);
}
// Wait for the button to be released
while (myButton.GetState() == Button.ButtonState.Pressed)
{
	Thread.Sleep(10);
}

// Start the loop that will move the two servos
while (true)
{
	// Check for button pushed, exit if it's the case
	if (myButton.GetState() == Button.ButtonState.Pressed) break;

	// Set the servo at channel 0, with a ramp speed of 5, to the position 0°
	servo16.SetServoPosition(0, 5, 0);

	// Set the servo at channel 1, with a ramp speed of 5, to the position 0°
	servo16.SetServoPosition(1, 5, 0);

	// Wait for the operation to complete
	Thread.Sleep(1000);

	// Check for button pushed, exit if it's the case
	if (myButton.GetState() == Button.ButtonState.Pressed) break;

	// Set the servo at channel 0, with a ramp speed of 5, to the position 90°
	servo16.SetServoPosition(0, 5, 90);
	// Set the servo at channel 1, with a ramp speed of 5, to the position 30°
	servo16.SetServoPosition(1, 5, 30);
	Thread.Sleep(1000);

	// Now you can figure these lines out
	if (myButton.GetState() == Button.ButtonState.Pressed) break;
	servo16.SetServoPosition(0, 5, 180);
	servo16.SetServoPosition(1, 5, 120);
	Thread.Sleep(1000);

}

// Reset the position of bot
servo16.SetServoPosition(0, 5, 0);
servo16.SetServoPosition(1, 5, 0);

La classe Servo16 est développée par GHI, disponible ici: http://code.tinyclr.com/project/49/serial-servo-motor-controller/

Voilà, ce n’est pas sorcier et il y a de quoi faire avec 16 servos !

You must update your firmware.

Voilà, c’est clair! Pourquoi donc? Tout simplement parce qu’une version donnée du SDK délivrée par GHI ne peut fonctionner correctement qu’avec le firmware correspondant.
Donc si vous installez la version V 4.1.5.1 du SDK de GHI sur votre PC, il faudra mettre à jour le firmware de votre carte.

La procédure est digne…de la bidouille que l’on pouvait imaginer lorsque l’on débute dans le domaine (en tout cas de mon point de vue de développeur). Ce n’est pas insurmontable, mais les chances d’y arriver du premier coup sont minimes.

Mes recommandations

1) Installer les drivers USB spécifiques à la procédure de mise à jour du firmware. Disponible sur la page Downloads de GHI.

2) Suivre la vidéo sur YouTube (Cobra, Panda/Domino/Mini/Rhino) qui décrit la procédure ou la version Wiki.

3) Bien suivre calmement toutes les étapes, si vous les brulez, la carte le deviendra peut être aussi!

La seule réelle difficulté quand on n’a jamais flashé sa carte est de savoir si on est bien en mode “TinyBooter”.
Par exemple la séquence pour entrer dans ce mode avec ma FEZ Cobra est:

To read TinyBooter version number, all you have to do is to access TinyBooter (Press and hold Up and Down buttons on system boot up then release the buttons when you see “TinyBooter Mode” on EMX’s display. The version number is right after that line.

Les premières fois j’ai bien eu “TinyBooter Mode” sur l’écran de ma Cobra, cependant pour une raison que j’ignore les drivers Windows spécifique au mode TinyBooter ne s’étaient pas initialisés, donc impossible de faire marcher l’étape avec le logiciel Tera Term.

Pour être bien sûr que les pilotes fonctionnent vous devez avoir un nouveau port COM de détecté lors que vous passez en mode TinyBooter. Si ca ne marche pas du premier coup, réessayez en changeant de port USB afin de forcer une détection totale du périphérique.

Bonne chance!

Le wiki de l’excellent site tinyclr.com référence sur cette page les différentes cartes disponibles sur le marché.
(autant le dire tout de suite, le site tinyclr.com est l’initiative de GHI Electronics, mais il n’en demeure pas moins généraliste)

Les constructeurs

• GHI Electronics
• Secret Labs
• Device Solutions

Device Solutions avec ses cartes Tahoe à l’air d’être un peu à la traine, d’ailleurs je n’arrive plus à trouver de site qui commercialise leurs cartes NetMF.

Secret Labs à sortie le pendant NetMF de l’Arduino, l’avantage est que la carte bénéficie du même “Package” que son pendant en simili C++ (mais nous verrons que ce n’est pas le seul), ce qui vous donne accès au fameux Shields de l’Arduino.

Et puis enfin, GHI electronics. Quand j’ai commencé à m’intéresser au NetMF j’ai vite découvert Device Solution et sa Tahoe II, je dois dire que j’étais déjà bluffé par la carte à l’époque. Par contre quand j’ai découvert GHI, là, ce fût une véritable claque!

Il est chez GHI, il a tout compris!

Bon, c’est surtout les gens de GHI qui ont tout compris:

• Bien qu’ayant une gamme hardware inégalée, ils sont loin de miser uniquement sur le matériel.
• Ils ont une approche très active sur la technologie NetMF: la surcouche qu’ils développent par le biais de leur SDK apporte de nombreuses fonctionnalités.
• Ils ont une approche très Open Source et active sur la communauté NetMF. Comme je le disais plus haut, ils sont à la base de www.tinyclr.com.
• Ils sont à l’origine du développement des drivers de pas mal de capteur/add-ons.

La gamme FEZ de GHI

Il y a globalement deux gammes chez GHI:

• .Net modules/chipset: c’est la première gamme de produit qu’ils ont développés, elle est orientée pro/oem.
• .Net FEZ: c’est la dernière gamme en date, basé sur les chipset de la première gamme, FEZ est destiné aux hobbyistes et pour l’éducation principalement.

Dans 99% des cas vous aurez tout intérêt à débuter avec la gamme FEZ, elle est clairement la plus fournit et la plus en avance. Si jamais vous souhaitez industrialiser votre solution, il sera toujours possible de se rabattre en production sur les chipset de la gamme pro (sans aucune adaptation logicielle).

Comparatif de la gamme FEZ

L’URL n’est pas facile à trouver, mais il existe une page sur le site de GHI qui compare les différentes cartes qu’ils vendent:
http://www.ghielectronics.com/catalog/compare/.

Parmi les distinctions entre les cartes, on notera:

Package: Spécifique pour Cobra et Rhino, compatible Arduino pour Domino et Panda II, compatible Parallax pour Mini.

CPU: Le même partout, un 72Mhz 32-bit ARM.

Mémoire vive: Pour la Cobra:12MB (12 000KB) de RAM disponible. Pour les autres 62K! Autant dire qu’il y a une sacré différence.

Mémoire Flash utilisateur: Pour la Cobra: 3MB (3 000KB). Pour les autres 148KB.

Couche Graphique: La Cobra dispose d’un vraie couche de représentation. Pour les autres on se contentera des fonctionnalités de base.

Consommation électrique: Pour la Cobra 220mA/180mA (active/idle). Pour les autres env 100mA/65mA.

Faire son choix

Si vous souhaitez développer des programmes embarqués qui nécessitent de la mémoire vive, manipuler une base de données et/ou disposer d’une interface graphique alors vous devrez vous orientez vers la FEZ Cobra (pour un prix de 140€ env).

Si vous restez dans le cadre de la robotique et que les contraintes de mémoire vives (62K, c’est quand même pas beaucoup de nos jours) ne vous pose pas de problème alors la FEZ Domino sera le bon choix: la différence de prix avec la Panda II ne mérite pas de s’en priver, son Package est compatible avec les Arduino et vous apprécierez la connectique présente (pour un prix de 55€ env)

Si l’encombrement est votre contrainte principale, alors la FEZ Mini sera certainement vous séduire.

Je vais cross-poster sur mon blog ainsi que sur le nouveau blog Solution Robotique .Net.

Vous l’aurez deviné, en tant que fan de .Net je me tourne sur une solution .Net Micro Framework, du .Net qui tourne sur une petit carte de quelques centimes carrés: c’est quand même tripant!

A plus pour de nouvelles aventures!

La release actuelle est le fruit de recherche, ce n’est peut être pas encore “production ready”, mais on peut tout de même s’en servir dès aujourd’hui.

Lorsque l’on débugge, ce qui nous intéresse c’est le flow d’exécution du programme, lorsque l’on fait du pas à pas et que l’on se retrouve sur un appel de méthode on peut choisir de faire un step-into pour débugger son implémentation, avec un débugger classique un nouveau fichier sera ouvert (celui qui contient la méthode en question).

L’approche du Debug Canvas est différente, comme son nom l’indique la session de débugge n’est plus constituée d’une liste de fichiers mais d’un unique canevas.

Lorsque l’on démarre une session de debug et qu’un breakpoint est activé, le canevas s’affiche, il est constitué d’un “code bubble” qui représente l’implémentation de la méthode qui contient le breakpoint en question.

Chaque “step-into” affichera un nouveau Code Bubble représentant l’implémentation de la nouvelle méthode en cours, une flèche relient les deux bubble pour indiquer la relation “appelant/implémentation”.

Si la session de débugge se prolonge, on aura évidemment beaucoup de bublle, mais les possibilités de zoom/pan, le focus automatique sur une bubble et l’agencement du layout sont bien implémentées. On aura bien sûr la possibilité de faire du ménage.

Le canevas servira de hôte à plusieurs composantes:

• Code Bubble: une petite fenêtre qui affiche l’implémentation d’un méthode faisant partie de la session de débug. C’est une version “miniature” de la fameuse Code Window de Visual Studio.
• Local values: les variables (et leur valeurs) associées à un Code Bubble. Nous aurons la possibilité de créer des snapshots des valeurs afin de pouvoir constater/comparer les évolutions dans le temps.
• Notes: des annotations que l’on peut faire pour apporter des compléments d’information (explication du comportement du code, indication sur la résolution, etc.).

Pour pourra l’exporter en XPS afin de partager sa session de débugge avec l’équipe (d’où l’utilité d’avoir des Notes).

Je vous conseille de regarder la vidéo disponible sur la page de l’add-in et de télécharger celui-ci.

A noter que celui-ci demande pour l’instant un Visual Studio 2010 Ultimate.

Pour ma part je trouve l’expérience très intéressante, je débugge avec depuis peu et j’attend de prendre un peu de recul (d’avoir plus de pratique) pour savoir exactement quand s’en servir car vous avez toujours la possibilité d’utiliser le débogage classique.

En tout cas je ne peux qu’être impressionné par la puissance de Visual Studio 2010 qui offre toutes les bases nécessaires à développer ce genre d’outil en se consacrant directement à l’essentiel. Les investissements pour faire une refonte de l’IDE en WPF ainsi que la nouvelle structure d’extensibilité portent leurs fruits!