Bonjour,

Pour ma part il pourrait y avoir deux méthodes pour apprendre la programmation sur microcontrolleur, dépendant du profil du programmeur.

Il parait intéressant de bien comprendre le fonctionnement de l'architecture interne d'un MCU et de ses périphériques, et en ça, l'asm permet de vraiment coller au plus proche du matériel. C'est l'approche qui était enseignée dans les sections électronique au lycée (tout du moins quand j'étais encore à l'école). On y apprenait encore le décodage d'adresse puisque les MCU n'étaient pas courant à l'époque.
Je trouve cette approche rébarbative mais elle permet d'aller au fond des choses et selon moi cela facilité la compréhension du langage C appliqué aux MCU. C'est évidemment celle que je préfère

L'autre approche, on programme directement en C et à vrai dire, 99% du code voir 100% dans certaines applications peuvent être écrites sans une ligne d'ASM. C'est l'approche moins électronicienne qui permet à quiconque de démarrer vite sur une plateforme. L’inconvénient est que lorsque l'on se rapproche du hard, il manque des briques à la compréhension et le second inconvénient est le risque pour celui qui n'a pas la sensibilité de ce qu'il se passe dans le matériel de coder sans optimiser convenablement son code (utilisations de variables surdimensionnées, de librairies lorsque ce n'est pas indispensable, mauvaise gestion et allocation de la mémoire, etc... Cette approche pose de moins en moins de problème à mesure que les MCU deviennent puissants, mais sur les petits MCU, cela peut être génant...

Cette deuxième approche a permis par exemple aux utilisateurs d'arduino de créer des applications sans pour autant avoir la connaissance des MCU. Mais cela suppose une première couche d'abstraction d'une part et quand même de se rendre compte que l'on a pas nécessairement un pentium quad core sous le coude...

J'ai vu dans l'industrie des informaticiens produire du code pour des applications embarquées sans avoir la moindre connaissance du MCU sur lequel ils travaillaient. Ils étaient bons en algorithmie, mais nuls pour produire du code optimisé pour la plateforme... Cependant le MCU pouvait absorber grâce à ses ressources ce code non optimisé donc au final, l'application fonctionnait... Généralement leur code était soumis ensuite à un électronicien qui l'optimisait (remplacement des float par des integer, interfaces avec le hard, etc...)


Stéphane

Citation :Je ne vois toujours pas trop en quoi l'asm permet de mieux coller au hardware.

Citation :On commence à pouvoir optimiser au fur et à mesure que l'on acquiert de l'expérience. Un mauvais programmeur en asm n'optimisera pas forcément plus qu'un bon programmeur C. Ce dernier connait les contraintes de la gestion et de l'optimisation de la mémoire: on ne manipule par les pointeurs et l'allocation dynamique de la mémoire sans une bonne vision des mécanismes internes.

Je manque peut-être de recul puisque moi aussi j'ai commencé par l'asm et que j'ai maintenant tendance à n'utiliser que les langages de haut niveau vu que je suis passé du côté obscur de la force (de l'électronique à l'informatique). Mais je reste évidemment ouvert (enfin j'espère) à une argumentation qui me montre que j'ai tort dans mon approche.

Jacques

re,

ben je pense que l'asm permet de coller mieux au hardware dans la mesure où l'on peut accéder aux registres internes du CPU (accumulateurs) ce que l'on ne sait pas faire en C d'une part et d'autre part il est difficile d'utiliser l'asm sans connaitre le fonctionnement du CPU ce qui est tout à fait faisable en langage plus évolué.
Pour ma part je n'utilise quasiment plus l'ASM. Désormais j'utilise des CPU plus puissants que nécessaire pour mes applications la plupart du temps et je code tout en C. Sur le V1 d'ailleurs je ne crois pas avoir fait une seule routine en asm !
Concernant l'optimisation je suis d'accord avec toi un mauvais programmeur n'optimisera ni en ASM ni en C, mais le C ouvre des portes que l'on ne peut pas aisément franchir en C.
Par exemple, j'ai vu des programmateurs réaliser des routines qu'avec des float, même pour faire un petit compteur 8-bits. C'est en ce sens que je disais qu'il ait moins facile de se faire pieger en ASM...

Actuellement j'essaie de me mettre au c++... enfin je démarre juste. Ce sera un vrai plus pour moi (sans jeu de mot) car je commence à voir les limites du C...

Attention Stéphane, tout ce que tu peux faire en C++, tu peux le faire en C... Le concept change c'est tout (introduction de l'objet)

A+
Joël

Sur le fond tu as raison, mais ce n'est pas tout à fait exact. On peut faire du C++ sans programmer objet. C++ introduit de nouvelles fonctionnalités intéressantes qui n'ont pas leur équivalent en C, comme les références, les fonctions inline, les exceptions, les booléens, etc.

De plus, le compilateur C++ étant plus strict que le compilateur C, le premier est sensé générer du code plus sûr.

Jacques

Bien sur, les outils ne sont pas les memes, mais je sous entendais "fonctionnelement".

Joël

Je ne parlais pas des outils non plus, juste du langage.

Concernant le choix entre C et C++, j'ai déjà assisté à quelques débat de "puristes". Il s'avère que quoique C et C++ soient considérés comme 2 langages différents (et pas un qui descend de l'autre), beaucoup de programmeurs font un mix des 2, ne serait-ce que parce que pour réutiliser des librairies qui ont fait leurs preuves.

Jacques

A priori C++ descend bien du C puisqu'il a été créé dans les années 90 par un gars qui souhaitait justement ajouter des fonctions au C qu'il considérait comme limitant.

Sur le principe Joel, je suis d'accord, quelque soit le langage ont doit arriver à faire la même chose. Et dans l'absolu pourquoi pas même en assembleur puisqu'au final c'est ainsi qu'il sera compilé !
La limitation que je trouve au C est justement dans la création d'objets que l'on peut aisément transporter. Depuis que je code en C, je pense que je code en suivant les préceptes de l'objet. C'est à dire que mes fonctions sont systématiquement des modules que j'essaie de faire transportables, multiplateforme, etc... mais le C++ apporte a priori certaines facilités d'écriture que je n'ai pas en C. C'est aussi la raison pour laquelle je pense que l'apprentissage du C++ ne devrait pas être trop compliqué... encore qu'on verra ça bientôt !
Je vais me commande un bouquin sur le sujet... J'en ai vu deux types : certains qui traitent du C++ pour des utilisateurs du C et d'autres qui abordent le c++ à partir de 0.
Je pense tenter avec l'un de la première catégorie mais si vous avez un ouvrage à me recommander !

++
Steph

Citation :Je ne vois pas ça comme un ajout de fonctionnalité. La programmation objet est une façon différente de voir les choses. Mais bon, au fond ça ne me dérange pas que l'on parle de C/C++ ou que l'on considère que ce sont 2 langages différents.

Si je peux donner un avis pratique sur l'enseignement du C++, je trouve qu'il est difficile de justifier ce langage sans travailler sur de gros projets. Et travailler sur de gros projets noie l'enseignement du langage sous la problématique du projet lui-même.

Finalement j'ai trouvé un bon compromis je trouve: la programmation d'interfaces graphiques. Celle-ci se prête vraiment bien à la programmation objet car on peut facilement faire comprendre la notion d'objet au travers des paramètres de la fenêtre et de son comportement interne ou en réaction à des signaux émis par d'autres objets. Je peux même justifier l'intérêt de notions telles que l'héritage en montrant les points communs entre plusieurs objet graphiques.
Si tu te lances dans Qt, n’hésite pas à te créer de petites appli graphiques avec plusieurs fenêtres qui, même si elles peuvent faire gadget dans un premier temps, sont très enrichissantes du point de vue apprentissage.
Tu y découvriras notamment la richesse incroyable des classes de Qt.

Question littérature, je ne sais pas trop quoi te conseiller, mais si tu as trouvé un ouvrage axé sur la transition du C au C++, c'est probablement un bon choix. On trouve quantité de bons cours également en ligne.

Jacques

J'ai installé QT et visual c/c++ express. Mais pour l'instant je n'ai pas eu le temps de me pencher sur le sujet car je dois finir deux projets en cours avant de démarrer autre chose.
Je ne sais pas ce que tu entends par "gros projet". Mes applications tournent actuellement autour de 20-30k sans les libs donc des exécutanbles qui font 50k environ. Ce ne sont pas de grosses applications je pense.
J'ai la chance d'avoir des collègues programmeurs qui me donnent parfois des tuyaux intéressants.
Typiquement je viens de réécrire mon driver d'afficheur graphique et ils me l'ont démonté en 2mn en m'indiquant une méthode bien plus élégante et efficace d'un point de vue affichage mais plus gourmandes en RAM. Bref, il est bon d'avoir ce type de retour de la part de personnes qui l'utilisent à outrance car au delà des aspect syntaxe et structure de code, cela apporte aussi beaucoup sur les méthodes de programmation au niveau applicatif