Journal Premiers pas sur l'architecture RISC-V avec la carte HiFive1

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
39
3
juin
2020

Sommaire

Une révolution, tout simplement. Depuis que je travaille dans le domaine embarqué, j'ai connu quelques changements intéressants avec notamment l'arrivée de l'architecture Cortex-M, mais là, c'est un cran au-dessus. Une architecture de microcontrôleur Open Source, j'en ai rêvé, maintenant elle existe.

Rappel sur les microcontrôleurs

Petite piqûre de rappel : les microcontrôleurs sont de très petits processeurs équipés de périphériques pour contrôler le monde extérieur au composant : des actionneurs ou des capteurs. De plus, ces composants disposent de leur propre mémoire pour y stocker le logiciel (ROM/RAM), cela en font donc de véritables petits ordinateurs prête à l'emploi.

En pratique, on obtient un composant électronique avec plus ou moins de pattes qui sera l'élément central d'une carte électronique.

image

Exemple de micro

image

Exemple de carte de développement

Continuons par un panorama non exhaustif des architectures existantes. Il en existe plein, mais les plus populaires sont :

  • La gamme Microchip, PIC12, PIC16, PIC24 sont très populaires, notamment grâce à leur bonne intégration dans l'outil MPLAB du fondeur. Je les trouve régulièrement chez mes clients car les outils (sondes JTAG comprises) sont peu chers. Ces architectures ne sont pas licenciées à des tiers.
  • La grande famille Cortex-M3 : tous les fondeurs ont créé leur gamme à partir de cette IP appartenant à ARM qui vit grâce aux licences et royalties sur chaque composant vendu
  • Chez TI, on trouve des MSP430 et autres DSP intéressants ; là aussi, c'est du propriétaire
  • La gamme AVR, chez Atmel, maintenant Microchip, popularisée par l'Arduino
  • Les fondeurs japonais : Hitachi/Renesas/NEC/Mitsubishi ont créé des architectures plutôt intéressantes, j'ai eu l'occasion de travailler sur des NEC à la mémoire Flash incroyablement performante

Depuis 15 ans maintenant, ce petit monde se côtoyait ; l'architecture ARM est devenue populaire pour avoir rapidement misé sur la faible consommation sans détériorer les performances. C'est vraiment l'architecture qui a fait passer les architectures embarquées vers le tout 32-bits. Elle est devenue au fil des ans un standard de fait et en choisissant un microcontrôleur ARM on s'assurait d'une disponibilité très grande d'applications tierces compatibles (notamment les RTOS), d'un écosystème large et d'un savoir faire largement répandu (livres). Par exemple, on avait ENFIN le choix de ses outils de développements comme la sonde JTAG, le compilateur et l'éditeur/débogueur.

Historique RISC-V

Revenons au RISC-V.

C'est en l'an 2010 que l'architecture RISC-V est née au sein l'Université de Californie à Berkeley, aux États-Unis. Cette spécification décrit un jeu d'instructions 32, 64 ou 128 bits est libre et dénuée de tout royalties. Une fondation a été créée et a même récemment déménagée en Suisse ; tout est bon pour pérenniser le projet.

image

Le site de la fondation, bon point de départ

Écrire une spécification, c'est bien ; l'étape suivante, c'est d'avoir une implémentation réelle, un composant facilement accessible au commun des mortels. Paradoxalement, ce sont des nouveaux venus (pour moi) sur le marché qui ont sorti les premiers composants. Le site riscv.org liste les fondeurs et les fournisseurs de matériel (cartes électroniques). Dans un premier temps, ce sont surtout des implémentations non libres qui sont sorties (HiFive, Andes …) mais des projets libres sont montés (https://www.lowrisc.org/).

Voilà, allez voir la page Wikipedia pour en apprendre plus ainsi que le site de la Fondation : riscv.org.

Le SoC Freedom E310

Intéressons-nous au SoC (System on Chip) Freedom E310 créé par la société SiFive. Elle va nous permettre de tester facilement le composant en proposant une carte de forme compatible à Arduino, la HiFive version 1 qui existe en deux modèle : l'originale et la version B.

image

Première version

image

HiFive RevB

Lorsque j'ai regardé les spécifications du microcontrôleur, j'ai été un peu surpris : habitué à des composants modernes bourrées de périphériques, le E310 est … particulier ! Notez :

  • 320MHz, pour un micro, c'est énorme (je traite d'habitude avec des composants entre 8 MHz et 100 Mhz)
  • Pas de mémoire flash interne, mais un accès Quad SPI où le code est stocké ; ce n'est pas courant, probablement parce que concevoir de la mémoire Flash est un savoir faire assez spécial
  • 16kB de RAM, pas hyper impressionnant surtout si on veut utiliser un RTOS. Les applications seront limitées en taille
  • Coeur RV32 'I' (A load-store ISA with 32, 32-bit general-purpose integer registers) avec les options :
    • M : Integer Multiplication and Division
    • A : Atomics
    • C : 16-bit Compressed Instructions
  • Du JTAG, on en reparlera plus tard
  • PWM, UART, SPI … okay, mais pas d'I2C ! (corrigé dans la version B)

D'ailleurs la version B est plus intéressante pour une utilisation réelle dans une application IoT (je quote le site) :

  • Hardware I2C to read from digital sensors
  • Additional UART to communicate with other peripherals
  • Low-power sleep mode, keeping only the minimal amount of logic in the Always-On domain powered
  • On board wireless networking

La deuxième révision est donc la plus intéressante.

Sur la carte, on retrouve un composant de type USB-UART (puce FTDI) qui nous servira à injecter du code dans la mémoire flash externe et à déboguer notre application.

Voici les principaux périphériques :

image

Et voici le diagramme bloc de l'intérieur du composant :

image

Bon, après ce rapide tour d'horizon, quelques remarques peuvent être dégagées :
1. La carte Rev B semble plus intéressante, au moins pour l'I2C
2. Pas de mémoire flash interne au micro ce qui impose d'ajouter un composant supplémentaire : dommage pour les petits designs.
3. Des périphériques un peu limités, c'est brut de décoffrage, le minimum syndical

Premier branchement

Branchez la carte à votre ordinateur via le port USB. Une liaison série apparaît, genre un /dev/ttyUSBx. Lancez votre terminal série préféré, GtkTerm de mon côté, et appuyez sur le bouton reset pour redémarrer pour observer le petit message suivant (les paramètres de la liaison série sont affichés en bas) :

image

Vous noterez le petit effet d'arc-en-ciel généré par la LED RGB. C'est bon, le programme embarqué livré de base. Le microcontrôleur dispose d'un chargeur de démarrage embarqué dans la mémoire flash, un truc du genre Arduino, qui ne sera pas effacé par votre programme utilisateur.

Essai de logiciels

Maintenant que l'on a le hardware, il nous faut du logiciel, notamment le compilateur mais aussi le débogueur. Pour cela, SiFive a préparé un bundle autour d'une version d'Eclipse modifiée, FreedomStudio.

Téléchargez-le à partir du site du fabricant, dézippez et lancez-le. Au premier démarrage, plusieurs écrans vont apparaître vous proposant de choisir les différentes cibles supportées et vos outils de développement.

Choisissez les paramètres suivants :

image

Normalement le projet devrait compiler automatiquement et avec succès puis la fenêtre de lancement du débogage apparaît :

image

Laissez les paramètres par défaut et programmez la cible. Le log OpenOCD s'affiche en rouge, ça fait peur mais tout se passe (normalement) bien. Sur votre terminal série devrait s'afficher le message suivant (touche reset sinon pour relancer).

image

Vous pouvez tenter de modifier le programme en ajoutant par exemple une petite boucle infinie et un peu de code. Tentez de placer un point d'arrêt sur une ligne de code (Maj+Ctrl+B) ; magique, ça fonctionne, le code s'arrête.

SiFive n'est pas le seul à fournir des outils de développement. Outre GCC et LLVM, l'éditeur propriétaire IAR fournit aussi son compilateur (et probablement bien intégré à son IDE). Au niveau des débogueurs professionnels, les sondes Segger et Lauterbach sont compatibles.

Nous voyons donc que l'industrie s'intéresse à cette plateforme et les grands éditeurs sont au rendez-vous. On attend maintenant les fondeurs !

Conclusion

La carte HiFive est vraiment sympa ; compatible Arduino, elle vous permettra d'utiliser bon nombre de cartes d'extensions existante. Tout a fonctionné du premier coup, cette première approche de l'architecture RISC-V est un succès.

Notez que l'architecture RISC-V est large : la société SiFive fournit également une carte disposant d'un processeur plus puissant capable de faire fonctionner Linux dessus. Le futur s'annonce captivant.

  • # Coquille

    Posté par  . Évalué à 1.

    qui vie grêces -> qui vit grâce

  • # Question IO ?

    Posté par  (site web personnel) . Évalué à 3.

    Quand tu veux faire discuter plusieurs µp ensemble, tu utilises quoi ?

    "La première sécurité est la liberté"

    • [^] # Re: Question IO ?

      Posté par  (site web personnel) . Évalué à 5.

      Ça dépend de plusieurs paramètres, de ton application, de ton budget, du nombre de cartes, de la taille des données à transférer.

      Jai déjà fait plusieurs versions :

      • Des micro reliés par un bus I2C, avec un maître
      • du bus CAN (c'est fait pour)
      • du RS485 quand ce sont des liaisons inter-cartes par exemple avec du Modbus

      Si tu as deux micros, un UART suffit, avec des lignes de contrôle pour reseter l'un ou l'autre et bien gérer la dépendance maître/esclave (et les upgrade firmware).

      Difficile d'aller plus loin sans autres informations.

      • [^] # Re: Question IO ?

        Posté par  (site web personnel) . Évalué à 4.

        J'ai toujours l'impression que c'est du bricolage. Le CAN est fait pour, mais tu es toujours en maitre-esclave, et l'interface n'est pas si courante que ça, non ?

        Sur des systèmes plus gros(raspberry pi), on m'avait convaincu que l'ethernet était la meilleur solution et que le switch ne coutait pas si chère que ça. Mais il faut un OS.

        "La première sécurité est la liberté"

        • [^] # Re: Question IO ?

          Posté par  (site web personnel) . Évalué à 6.

          Cela dépend de l'architecture de ta carte.

          Combien de microcontrôleurs, topologie (maître / esclave, multi maîtres ou autres ?), ce que permettent tes microcontrôleurs, etc..

          J'ai fait de l'I2C pour des échanges basiques avec un protocole par dessus pour définir des commandes génériques entre un micro maître et plusieurs esclaves. Mais dans d'autres situations j'aurais sans doute choisi autre chose type Modbus, SPI ou CAN.

          l'interface n'est pas si courante que ça, non ?

          Je trouve que c'est assez répandu quand même, après tout dépend du micro que tu as choisi selon ton besoin…

          Sur des systèmes plus gros(raspberry pi), on m'avait convaincu que l'ethernet était la meilleur solution et que le switch ne coutait pas si chère que ça. Mais il faut un OS.

          Ethernet pour le coup c'est bien plus complexe et peu de microcontrôleurs devraient être capables de le gérer. Même si effectivement ça a son intérêt mais je dirais plutôt entre plusieurs processeurs qu'entre microcontrôleur.

        • [^] # Re: Question IO ?

          Posté par  (site web personnel, Mastodon) . Évalué à 8.

          Le CAN est fait pour, mais tu es toujours en maitre-esclave, et l'interface n'est pas si courante que ça, non ?

          Heu, non. Le CAN n'est pas vraiment maître-esclave. Il y a un système de priorité avec l'adresse et la vitesse du nœud pour savoir qui peut parler.
          Mais tout le monde peut-être maître à un moment ou un autre. Le CAN est assez courant maintenant dans les micro. Le chinois Gigadevice qui fait aussi des micros RISCV intègre le CAN dans sa gamme de GD32. En théorie il y est sur la longan nano, mais j'ai pas testé.

          Sur des systèmes plus gros(raspberry pi), on m'avait convaincu que l'ethernet était la meilleur solution et que le switch ne coutait pas si chère que ça. Mais il faut un OS.

          Il existe tout un tas de bus industriels basés sur l'ethernet. Tout dépend de la définition d'un OS, mais oui il faut au minimum un «framework» pour les utiliser. Et on parle tout de suite de «gros» microcontrôleurs.

          J'ai plus qu'une balle

  • # Un chip RISC-V abordable qui tourne Linux?

    Posté par  (site web personnel) . Évalué à 3.

    "Notez que l'architecture RISC-V est large : la société SiFive fournit également une carte disposant d'un processeur plus puissant capable de faire fonctionner Linux dessus. Le futur s'annonce captivant."

    On attends toujours un SoC RISC-V abordable qui tourne Linux.

    Je pense que le futur proche un design FPGA pourra être fondu via les belges de Chip4makers.io:

    https://chips4makers.io/

    • [^] # Re: Un chip RISC-V abordable qui tourne Linux?

      Posté par  (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 04 juin 2020 à 13:58.

      On attends toujours un SoC RISC-V abordable qui tourne Linux.

      Pourquoi attendre quand ça existe déjà ?

      Je n'ai pas testé avec mon kit perso, mais c'est pas non plus du desktop-ready hein ;)

      SiFive est une société sans fabrication qui fonctionne sur le même modèle que ARM. Ils ont sorti le E310 pour augmenter leur crédibilité et montrer leurs savoir faire. Mais si vous voulez vraiment faire un produit industriel avec le E310 il faudra aller les voir pour paramétrer (customiser) votre propre chip.

      En matière de chip RISC-V industriel pour l'instant ce sont surtout les chinois qui ont commencé à se positionner. Sinon il y a le GAP8 qui semble intéressant mais l'architecture est beaucoup moins «orthodoxe».

      En tout cas pour ceux que j'ai repéré.

      Je pense que le futur proche un design FPGA pourra être fondu via les belges de Chip4makers.io:

      Il me semble qu'il«s» ne soit pas beaucoup plus que un (Staf Verhaegen).

      J'ai plus qu'une balle

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.