Jipihorn's Blog

août 16, 2016

L’environnement de développement Microchip MPLAB-X

Filed under: Electronique, Informatique, Vidéo Blog — jipihorn @ 8:13

A la suite de multiples demandes, voici un long épisode sur l’environnement de développement de chez Microchip MPLAB-X et Harmony autour du microcontrôleur PIC32MZ2048EF.
C’est un peu fourre tout car il est très difficile de faire quelque chose de linéaire tellement tous les aspects dépendent les uns des autres. Je mets l’accent aussi sur les problèmes de cet environnement, surtout pour le debuggage.
Ça survole énormément d’aspects et même avec cette durée, la totalité est à peine abordée.
Éventuellement, je pourrais faire des épisodes sur un aspect particulier.

 

Jipi.

Publicités

8 commentaires »

  1. Bonjour,
    Je programme aussi sur PIC mais en langage d’assemblage, « appeler par abus de langage assembleur » ,
    pour ceux qui veulent s’initier. je conseille le site de Bigonoff les cours sont très bien fait.
    J’utilise encore MPLAB-IDE ver-8.92 , j’ai essayer MPLAB-X , mais trop lent avec mon PC.
    Merci JIpi

    Commentaire par Albert — août 16, 2016 @ 6:00

  2. Salut,

    Voici aussi un article très intéressant sur les choix stratégiques de microchip : http://gerrysweeney.com/microchip-pic-chips-could-have-been-the-power-behind-arduino/

    Pour avoir développé sur MPLab, MPLab X ; Atmel Studio 4 puis 5 , 6 et 7 ; et enfin Keil ARM ou IAR ARM ; je peux t’affirmer sans hésiter Atmel Studio depuis la version 5 est au dessus du lot. Et pour une raison simple, il est basé sur Visual Studio. Et on peut dire ce que l’on veut de Microsoft, mais leur IDE tient la route.
    Et cela m’a toujours étonné qu’un IDE (et son compilateur) de cette qualité soit fournit gratuitement.
    Après, tout n’est pas rose non plus chez les autres fabricants. Enfin c’est difficile de faire pire en IDE.

    De toute façon, Microchip n’a jamais été réputé pour la qualité de son IDE et compilateur. Mais plus pour son rapport fonctionnalité/prix de ces microcontrôleurs.

    Quand je pense que j’ai été obligé de faire les migrations de plusieurs vieux projets MPLab vers MPLab X juste pour pouvoir faire de la maintenance dessus ! Mon dieux quel horreur !

    Sinon ce qui est drôle, c’est que l’IDE de Microchip est passé multiplateforme (Windows, linux) contrairement à l’IDE d’atmel à perdu son côté multiplateforme (Visual studio oblige). Grâce à java. Et voilà le resultat !

    Pour conclure, je ne trouve pas normal qu’il soit presque plus difficile aujourd’hui d’utiliser les kit de dev (qui d’ailleurs coûte cher) plutôt qu’un simple arduino ou Raspbery. Il y a vraiment de plus en plus de problème de qualité et de finissions chez les fabricants.

    @+

    Commentaire par loupium — août 16, 2016 @ 11:17

    • Je suis issu du monde Visual Studio et, effectivement, je pense qu’il est au dessus d’Eclipse ou de Netbeans. Très au dessus. J’ai utilisé Eclipse pour du cross-developpment Cortex A9 sous Linux et Netbeans pour MPLABX et vraiment, ils ont 10 ans de retard. Ou pire, certains choix ergonomiques sont ridicules. Je ne parle même pas de la lenteur de réaction (j’en ai assez de cliquer deux fois sur les boutons pour qu’ils daignent répondre). Et surtout, je jamais critiquer ces plateformes open source, les fanboys vont vite sauter à la gorge de celui qui a le cerveau pourri par Microsoft !
      Le cynisme de l’histoire est que MPLAB était sur une base Visual Studio. Maintenant, en fait j’utilise Visual pour écrire le coeur algorithmique et une fois testé et stabilisé, je le reporte sous MPLABX. Je fais de telle sorte que le même code sois compilable des deux cotés et ça va beaucoup, beaucoup plus vite. Malheureusement, dès que cela touche au microcontrôleur lui-même, ça n’est plus possible.
      J.

      Commentaire par jipihorn — août 18, 2016 @ 7:39

      • Le pire, c’est que microchip pense vraiment être en possession d’un bon IDE.
        Car au moment du rachat d’atmel par microchip, voilà ce qu’ils osent dire et qui m’a fait beaucoup rire :
        “These are two pretty complete tool sets, and there is no way of saying one is better than the other,”
        (src : http://www.electronicsweekly.com/news/products/micros/microchip-to-boost-8bit-avr-range-following-acquisition-2016-07/ )
        Surement un discours marketing.

        Un rachat d’ailleurs qui peut être inquiétant pour Atmel quant on voit la prévision de réduction de R&D du groupe (voir page 5 du communiqué de presse de Microchip : http://www.microchip.com/pdf/Atmel_Acquisition_Investor_Presentation_FINAL.pdf )

        Dommage, car microchip ferait un carton s’il ne gardait que l’IDE d’atmel pour les 2 marques.

        Mais en électronique, l’espérance n’est jamais une solution à court et moyen terme pour les utilisateurs.

        Et personnellement j’en est marre d’essuyer les plâtres de leurs nouvelle puce et outils associé buggué. (tout fabricant confondu)
        Au point où je me méfie maintenant des composants âgés de moins de 4 ans et dont la datasheet n’a pas dépassé la révision H. Et les errata sont devenu pour moi aussi important que les caractéristique d’une puce.

        @+

        Commentaire par loupium — août 18, 2016 @ 12:56

        • C’est exactement ça. Et oui, les errata sont au moins aussi importants que le datasheet.

          Et je déteste cette nouvelle tendance de se baser sur la faune des utilisateurs pour faire le support technique via un forum. C’est de l’escroquerie déguisée sous l’aspect cool de « la communauté » tout en dédouanant de tout. Mais bien sur, on peut avoir un support digne de ce nom, mais il est sous traité et payant (genre Ismosys).

          J.

          Commentaire par jipihorn — août 18, 2016 @ 2:33

  3. Et pour les plus motivés à compiler X32 : http://www.jubatian.com/articles/turning-on-optimizations-in-microchips-xc32/

    Commentaire par loupium — août 20, 2016 @ 12:25

    • Bonjour,

      Comme toujours, une vidéo intéressante. La durée n’est pas du tout un handicap, il y a tant de choses à dire sur ce sujet. Au delà des habitudes et des préférences sur les environnements de développement ou sur les µC, il y a une question qui me taraude depuis un certain temps: Quid de la pérénité des composants programmables et surtout des outils de développement ?

      Dans 10 ou 15 ans, le compilateur qui a été utilisé pour une application existera t’il toujours ? La cible de compilation sera t’elle toujours dans la liste alors que le composant sera sans doute devenu obsolète ?
      J’ai eu l’exemple au boulot ou nous avons eu à faire une modif sur des FPGA vieux de 20 ans. Heureusement que nous avions gardé un vieux PC avec les outils de l’époque sinon c’était foutu!
      Les applications industrielles ont finalement une durée de vie longue, 15 ou 20 ans, bien souvent incompatible avec l’évolution des produits informatiques.

      Il y a 10 ans, je m’étais bricolé un programmateur de µC Atmel. Pour la programmation, j’avais utilisé le port parallele. Depuis, j’ai changé de PC. Bilan: plus de port parallele (ni série non plus), que de l’USB. Pour que mes applications perso tournent encore, j’ai dû équiper mon PC d’une carte d’extension (// + série). Pas bien sûr que demain ce genre de carte soit facilement disponible.

      En ce moment, je bricole une haute tension pour un ampli à tubes. La mise en marche est gérée par un µC. Comme je ne souhaite pas avoir de problème d’obsolescence, non seulement je fais un mini stock de µC déjà programmés, mais je fais également une configuration autonomme (à base de raspberry) avec tous les outils de programmation.
      Je fais cela par précaution mais je sais bien que si un jour je dois reprogrammer tout cela, j’aurai égaré la moité des composants…..

      Philbob

      Commentaire par philbob — août 20, 2016 @ 7:43

      • Bonsoir,

        En effet, l’obsolescence concerne :
        * le composant,
        * les outils de programmation :
        * le programmateur/débogueur,
        * l’IDE,
        * le compilateur,
        * les librairies,
        * l’OS
        * le PC

        Pour la pérénité au niveau composant est plutôt bonne. Rarement en dessous de 10 ans.
        Certains fabricants comme ST vont même jusqu’à la garantir. Microchip et atmel produisent encore les µC (ou équivalent ou compatible) de leur début, soit presque 20ans. Et même lorsqu’ils ne sont plus produits, il reste encore dispo, comme par exemple premier Motorola 68hc11 soit 30ans. Par contre, plus il deviennent rares, plus ils deviennent cher.
        Après, il faut relativiser. La concurrence n’était pas aussi rude il y a 20 ou 30ans. Surtout vu la pléthore de référence et les fusions entres les fabricants aujourd’hui.

        Au niveau outils de programmation, c’est plus compliqué. Car il faut faire une sauvegarde de l’ensemble des outils (et à des instants et versions précises). Et plus il y à d’outils dans la chaîne de programmation, plus le risque de perte est grand. Les programmateurs avec mémoire intégrée sont intéressant pour cela.

        Quoi qu’il en soit, plus tu sélectionnes des standards, plus tu réduits les risques. ARM plutôt que pic32 ou avr32. JTAG plutôt que protocol propriétaire. GCC libre plutôt que compilateur propriétaire.

        Commentaire par loupium — septembre 2, 2016 @ 10:57


RSS feed for comments on this post.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

Propulsé par WordPress.com.

%d blogueurs aiment cette page :