FRAISE : FRAmework for Interfacing Software & Electronics

Posté par metalu.net le 04 avril 2020 à 17:21. Édité par Davy Defaud, Benoît Sibaud et Xavier Teyssier. Modéré par Ysabeau 🧶 🧦. Licence CC By‑SA.

Étiquettes :

avr.

2020

FRAISE : un projet open hardware pour simplifier la réalisation d’interfaces de contrôle.
C’est un environnement libre développé au sein de metalu.net, composé de cartes électroniques programmables à faible coût et d’un ensemble logiciel.
Cet outil vise à simplifier la réalisation d’installations robotiques, la construction d’interfaces de contrôle (pour la musique, la lumière, le Vjing…) ou tout autre assemblage de logiciels, de capteurs et d’actionneurs.
FRAISE trouve sa place dans de nombreuses créations d’artistes, dont certaines sont documentées sur le site metalu.net.

FRAISE possède de nombreux avantages, elle permet notamment :

une meilleure symbiose entre logiciel (l’application exécutée par l’ordinateur) et matériel (les cartes électroniques interfaçant capteurs et actionneurs) ;
de simplifier le câblage d’une machine complexe (éviter les « paquets de fils ») ;
de ne pas être limité par la longueur des câbles (libre dimension de l’installation) ;
de pouvoir facilement rajouter une fonction matérielle à n’importe quel endroit de l’installation ;
d’accélérer le prototypage et le développement.

FRAISE dispose de plusieurs caractéristiques qui lui sont propres :

la connexion de plusieurs dizaines de cartes (jusqu’à 126) sur le même port USB d’un ordinateur ;
une longueur de câbles d’interconnexion pouvant atteindre 400 mètres cumulés ;
un environnement de développement, de test et d’exécution entièrement intégré dans Pure Data ;
une bibliothèque de fonctions avancées, intégrant par exemple l’acquisition de mesures de capteurs, le contrôle de moteurs (asservissement en vitesse ou position, limitation de vitesse, d’accélération et de freinage), la gradation de lumière.

Pour aller plus loin dans la découverte de FRAISE, n’hésitez pas à consulter le dossier de présentation en ligne.

Pour plus d’infos et d’activités sur metalu.net ou par courriel.

logo metalu.net

Aller plus loin

FRAISE — metalu.net (437 clics)
Dossier de présentation de FRAISE (PDF) (160 clics)

# Avec ou sans Raspberry

Posté par Pierre Jarillon (site web personnel) le 05 avril 2020 à 01:00. Évalué à 3.
C'est fort intéressant et cela m'amène à me poser de nombreuses questions.

Je suis en train de faire un programme en C pour un Raspberry.
J'ai utilisé la library wiringPi, qui facilite l'accès aux E/S.
J'ai vu une ressemblance avec fraise. Est-ce un hasard ?

Avec wiringPi, j'ai utilisé les interruptions au lieu de faire de l'interrogation (polling). Je trouve que c'est plus élégant et fonctionnel. Par exemple pour le détecteur de 220V, j'ai :
```
  if ( wiringPiISR (DETECT_220, INT_EDGE_BOTH, &myInterrupt220) < 0 ) {
      printf ("Unable to setup ISR 220: %s\n", strerror (errno));
      return 1;
  }
```
Ainsi j'appelle la fonction myInterrupt220 qui va traiter le sujet quand il y a une coupure ou le retour du secteur. Le programme est ainsi très lisible et maintenable, et ma boucle d'attente peut être aussi simple que cela :
```
  while ( 1 ) {
    delay( 3000 );      // wait 3 secondes
  }
```
Est-ce que le pilotage avec un Raspberry est la solution préconisée ?

Autre question : Encore un bus de plus… N'y avait-il aucun autre bus ou autre topologie qui aurait pu convenir ?

Les circuits imprimés sont très chouettes. Conçus avec Kicad ? Qui les a réalisés ?
- [^] # Re: Avec ou sans Raspberry
  
  Posté par xavier philippon le 05 avril 2020 à 06:22. Évalué à 2.
  
  Oui, aucun doute, les CI sont réalisés avec Kicad.
  J'ai vu sur les site que pas mal de développement ont été réalisé sur des PIC18. S'il y a du monde chez Fraise qui maîtrise le sujet, je suis preneur.
  - [^] # Re: Avec ou sans Raspberry
    
    Posté par metalu.net le 07 avril 2020 à 13:42. Évalué à -1. Dernière modification le 07 avril 2020 à 13:42.
    
    Si tu as besoin d'infos sur les PIC18 n'hésite pas à m'écrire : antoine@metalu.net
    Je ne suis pas vraiment un expert mais j'ai une certaine expérience…
- [^] # Re: Avec ou sans Raspberry
  
  Posté par Anonyme le 05 avril 2020 à 06:41. Évalué à 3.
  
  Autre question : Encore un bus de plus… N'y avait-il aucun autre bus ou autre topologie qui aurait pu convenir ?
  
  Le CAN aurait été un bon candidat. Il est d'ailleurs de plus en plus utilisé en dehors de son domaine initial. Par contre ton SOC Broadcomm ne le gère pas nativement, ni leur microcontrolleur. Le CAN est intégré nativement dans la plupart des STM32 ainsi que dans quelques SOC ARM (le Allwinner A20 est un bon candidat) sinon il existe des puces de conversion vers USB, SPI, RS232.
  
  Après, j'ai l'impression que le poids des années a quelque peu enlisé ce projet (débuté en 2007) dans une certaine inertie de développement.
  De nos jours, Les STM32 sont bien plus fournis pour le même coût unitaire tout en ayant une stack libre plus étoffée que les PIC18.
  Le format DIP est complètement dépassé, on trouve désormais pour une bouchée de pain des plaquettes pour breadboard avec du SOIC et souder ensuite ces puces CMS sur un circuit imprimé personnalisé reste tout de même à la portée de l'amateur pas équipé en station à air chaud (en plus c'est beaucoup moins pénible à déssouder que des grosses puces à broches traversantes).
  - [^] # Re: Avec ou sans Raspberry
    
    Posté par totof2000 le 05 avril 2020 à 13:36. Évalué à 2.
    
    Les STM32 sont bien plus fournis pour le même coût unitaire
    
    Moi ça me fait toujours une sensation bizarre d'utiliser un microcontrôleur avec beaucoup trop de ressources par rapport au projet que j'ai en tête: j'ai l'impression de gaspiller. JE vois souvent des projets à base d'arduino ou tout autre microcontrôleur (ayant plein de pins d'IO et plein de ressources internes) qui pourraient ce contenter d'un bête attiny15. Je suis sûr que ces montage y gagneraient probablement en consommation.
    - [^] # Re: Avec ou sans Raspberry
      
      Posté par Anonyme le 05 avril 2020 à 17:57. Évalué à 2.
      
      C'est justement un ensemble de cartes de pilotage générique pour du prototypage ou de la mise en scène donc le MCU doit être assez imposant pour soutenir le bus de données et distribuer les commandes aux appareils qui y sont connectés. On parle tout de même d'interface MIDI, de transferts à 1Mb/s, de chainer des éléments, donc au plus il y a de ressources disponibles au mieux c'est.
      
      Le point que je soulevais est que la famille PIC est souvent pas bon marché.
      Si tu te contentes d'un petit STM32 avec peu d'entrées et un cœur Cortex-M0, la solution sera moins onéreuse (même en l'achetant chez une source fiable comme Mouser, Farnell, Digikey, RS).
      
      Enfin dans ton calcul de consommation, il ne faut pas uniquement prendre en compte la taille mais aussi l'architecture et le process de fabrication (la finesse de gravure). Regarde les datasheets tu verras qu'un petit AVR 8bit qui a vingt ans comme le ATtiny15L ne consommera pas moins qu'un STM32L0 plus récent, sans compter qu'en pratique pour la même tâche le STM passera moins de temps à calculer donc davantage de temps à rester en état de veille ou à un niveau bas de fréquence.
      Mais surtout ici cette considération de conso ne se pose pas. Ce n'est pas un montage sur piles alcalines, il y a des pertes des cables, des LDO et toute la conso des appareils pilotés donc de toute façon on est pas à quelques mW près et la conso du MCU ne sera pas du tout critique.
      - [^] # Re: Avec ou sans Raspberry
        
        Posté par Nicolas Boulay (site web personnel) le 07 avril 2020 à 10:17. Évalué à 3.
        
        C'est dingue que rien n'a évolué dans la petite électronique numérique. Il y a toujours du RS232, de l'I2C ou du CAN.
        
        Pourtant, cela serait top d'avoir un bus série 2 bits bidirectionnel, avec une norme pour 2 bus par chip pour faire des anneaux, et que cela soit fiable tout en évitant les switches. Pour avoir de la vitesse, il faut uniquement des connections point à point.
        
        L'idéal serait des bus qui envoies des messages sans intervention du CPU, ce qui peut bouffer énormément de puissance surtout si le bus est rapide et surtout si le système est grand.
        
        Je vois que la mode est au RDMA, cela pourrait être un bon point de départ.
        
        http://www.rdmaconsortium.org/home/The_Case_for_RDMA020531.pdf
        
        Cela évite aussi les configurations d'adresse externes comme le demande l'I2C, ce qui limite aussi le nombre d'éléments connecté.
        
        On peut ainsi séparer complétement le lien physique (3.3v TTL, RS429, paire différentiel,…),le protocole sur le fils pour gérer le zéro perte (code correcteur ou SPI avec retry, établissement de vitesse de com,…), et un protocole de routage déterministe, ainsi c'est le bloc HW qui gère et non le petit cpu. En cas de besoin spécifique, cela peut s'adapter.
        
        C'est tellement casse pied comme problème. 4 fils + masse sur un arduino ou une raspberry-pi pourrait permettre de faire pleins de chose. Au lieu d'être limité par l'I2C ou le SPI.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Avec ou sans Raspberry
        
        Posté par totof2000 le 07 avril 2020 à 11:40. Évalué à 2.
        
        Moi j'aimerais bien un bus bidirectionnel qui puisse s'interfacer tant via un signal électrique classique ( niveau 5v, 3,3v, … ) que via un signal lumineux (IR, fibre) ou modulé sur un autre signal ( exemple : genre CPL ).
        
        [^] # Re: Avec ou sans Raspberry
        
        Posté par Nicolas Boulay (site web personnel) le 07 avril 2020 à 13:52. Évalué à 3.
        
        Je ne comprends pas bien. Mon exemple sort en niveau classique, il faut ajouter une connexion de plus pour aller plus loin. On pourrait imaginer des version LVDS pour des très hautes vitesses, mais bon le pci-express existe déjà.
        
        Le cas d'usage de mon bus serait la com entre IC, entre carte enfiché, voir à travers un câble court.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Avec ou sans Raspberry
        
        Posté par totof2000 le 08 avril 2020 à 12:57. Évalué à 2.
        
        Le cas d'usage de mon bus serait la com entre IC, entre carte enfiché, voir à travers un câble court.
        
        Ok je comprends mieux (c'est d'ailleurs ce qui m'avait semblé en lisant le lien que tu as fourni mais pas eu le temps de regarder en détail). Cependant les bus RS232, RS485, CAN, et I2C dans une certaine mesure ne sont pas des bus qui servent à ça, d'ou je pense notre incompréhension.
        
        [^] # Re: Avec ou sans Raspberry
        
        Posté par Nicolas Boulay (site web personnel) le 09 avril 2020 à 13:42. Évalué à 3.
        
        Un peu quand même. Il existe plein de puce d'extension I2C. Le CAN est plus dédié à du réseau.
        
        "La première sécurité est la liberté"
  - [^] # Re: Avec ou sans Raspberry
    
    Posté par metalu.net le 07 avril 2020 à 13:48. Évalué à 0.
    
    Les boitiers DIP, même totalement has-been, sont pratiques si on les monte sur des supports.
    
    Quand tu brûles une E/S (ce qui peut arriver quand on bricole avec de la vraie matière), tu peux facilement extraire le MC et le remplacer. Ca évite de jeter la carte. Et puis c'est quand même plus facile à souder à la main…
    
    Mais c'est sûr que dans le cadre d'une production en série, ça serait mieux de passer au CMS.
    - [^] # Re: Avec ou sans Raspberry
      
      Posté par Anonyme le 07 avril 2020 à 21:17. Évalué à 2.
      
      pratiques si on les monte sur des supports.
      
      Dans ce cas, tu fais une entorse à ton cahier des charges puisqu'un support (un bon, pas du bas de gamme avec de mauvais contacts) implique un surcoût non négligeable.
      
      Quand tu brûles une E/S (ce qui peut arriver quand on bricole avec de la vraie matière)
      
      Au concepteur de prévoir les protections adéquates pour éviter les surtensions et surintensités sur les I/O, et aux utilisateurs de vérifier ce qu'ils veulent brancher dessus en effectuant des mesures, des tests préalables et en se documentant.
      Ça évite la grande majorité des impairs.
      
      tu peux facilement extraire le MC et le remplacer.
      
      C'est un faux argument, comme je le disais on peut acheter ou se fabriquer des plaquettes d'adaptation de CMS vers trous traversants au pas de 1" pour bosser sur breadboard ou sur plaquette type veroboard. On trouve même des plaquettes prêtes à l'emploi avec les composants déjà soudés pour une bouchée de pain.
      
      Là tu t'es limité dans le choix du MCU à cause d'un package de puce et ça ajoute un surcoût important.
      
      Et puis c'est quand même plus facile à souder à la main
      
      C'est certes un peu plus facile à souder avec peu d'outils mais comme je l'ai dit c'est beaucoup moins évident à dessouder sans abimer le composant ou la carte en dessous.
- [^] # Re: Avec ou sans Raspberry
  
  Posté par metalu.net le 07 avril 2020 à 13:34. Évalué à 2.
  
  J'ai effectivement écrits les CI sur Kicad ; merci pour ton appréciation !
  
  Fraise est tout à fait adaptée au rPi. C'est une toute autre solution que d'utiliser les E/S du CPU cependant : dans Fraise ce sont des microcontrôleurs 8 bits ("MCU") qui se chargent du contact avec le hardware (comme avec un Arduino).
  
  Dans Fraise, le polling des E/S des différentes cartes "Fruits" est automatisé par le "Pied", donc au niveau du CPU cela simplifie les choses : l'info qui arrive par l'USB est déjà "digérée", seules les infos pertinentes sont à traiter par le CPU.
  
  A noter que la partie CPU (ordi) de Fraise est écrite dans Pure Data ; c'est un choix particulier, mais en fait Pd est un "central" parfait pour gérer du temps-réel.
  
  Le bus Fraise utilise une simple UART (port série asynchrone), donc il n'exige pas de MCU équipé de fonctions spéciales (genre CAN). Quand je me suis lancé dans ce projet (vers 2006…) je trouvais ça important. J'avais bien étudié différents protocoles de bus, moi aussi je trouvais ça bizarre de devoir en écrire moi-même, mais vraiment je n'ai rien trouvé qui me convienne !
  
  Antoine
  - [^] # Re: Avec ou sans Raspberry
    
    Posté par Nicolas Boulay (site web personnel) le 07 avril 2020 à 13:50. Évalué à 4.
    
    J'avais bien étudié différents protocoles de bus, moi aussi je trouvais ça bizarre de devoir en écrire moi-même, mais vraiment je n'ai rien trouvé qui me convienne !
    
    Je serais curieux de connaitre ton cahier des charges à l'époque.
    
    "La première sécurité est la liberté"
    - [^] # Re: Avec ou sans Raspberry
      
      Posté par metalu.net le 07 avril 2020 à 14:15. Évalué à 1.
      mon cahier des charges pour le bus :
      
      longue distance (ici 400m), bidirectionnel, 1 maître / quelques dizaines d'esclaves
      
      câblage simple et pas cher
      
      "n'importe quel" MCU, le moins de composants supplémentaires, stack firmware légère
      
      baudrate bien supérieur au MIDI (je parle du MIDI d'origine, DIN-5 31.25kb/s) ; ici 250kb/s.
      
      supportant des paquets pas trop petits, pour limiter la perte de débit et autoriser des messages de taille suffisante (ici 31 octets).
      
      Bon, c'est sûr que j'ai eu une approche plutôt pragmatique et expérimentale…
      Et j'avais déjà pratiqué le DMX512 à ce moment, et le RS485 m'avait bien plu, en terme de facilité et fiabilité.
      - [^] # Re: Avec ou sans Raspberry
        
        Posté par Nicolas Boulay (site web personnel) le 07 avril 2020 à 16:06. Évalué à 3.
        
        J'imagine que tous les machins type I2C, avec leur système multipoint, ne permettait pas de faire ça ?
        
        "La première sécurité est la liberté"
        
        [^] # Re: Avec ou sans Raspberry
        
        Posté par metalu.net le 07 avril 2020 à 16:35. Évalué à 1.
        
        L'i2c c'est un protocole 2 fils bidirectionnels. A symétriser (pour la longue distance) ça serait coton, et en plus ça ferait 6 fils, au lieu de 4 ici.
# Je n'ai pas encore regardé ce projet mais ...

Posté par totof2000 le 05 avril 2020 à 13:44. Évalué à 1.

pour ma part je suis un peu méfiant vis à vis de ces trucs "tout faits". Si je prends l'exemple d'arduino, on voit sortir beaucoup de cartes hardwares ne pouvant être utilisées qu'avec arduino (ou si on veut les utiliser avec autre chose, c'est la croix et la banière).

A mon avi, ce qu'il faut faire pour avoir un hardware le plus ouvert possible, c'est ce qui a été fait pour la BBC Micro:bit. La carte a été à l'origine prévue pour utiliser code bloks, mais elle peut être programmée en python, elle est compatible arduino, et permet même une programmation bare metal et l'utilisation d'un debugger (OpenOCD + GDB) . Alors oui, j'avoue, pendant un moment j'ai regardé cette carte un peu de haut, avec mépris parce que je pensais ne pas être le public visé par celle-ci, mais depuis que je m'y suis penché, je trouve cette carte formidable; Le seul inconvénient est à mon avis son connecteur d'extension au pas de 1.27 mm, mais au final je trouve que le concept mérite qu'on s'en inspire (j'ai ét par exemple déçu par la tensy 4.0 pour laquelle il n'y a pas moyen d'accéder pour débugger via openOCD par exemple).

JE regarderai quand même, si ça se trouve je serai aussi agréablement surpris que par la micro:bit.
- [^] # Re: Je n'ai pas encore regardé ce projet mais ...
  
  Posté par totof2000 le 05 avril 2020 à 16:11. Évalué à 1.
  
  J'ai regardé, ça me paraît intéressant. A approfondir. J pense que j'aides choses a apprendre de ce projet.
  
  En tout cas merci pour avoir mis ce projet a disposition de tous ;)
# Petite remarque ..

Posté par totof2000 le 05 avril 2020 à 13:51. Évalué à 2.

Dans la présentation je lis (page 4) :

Deux niveau du bus sont définis, un niveau de courte distance utilisant du câble «nappe», et un niveau longue distance (protocole RS485) qui utilise du câble téléphonique associé aux connecteurs RJ11 (appelés aussi 6P4C).

Or d'après mes souvenirs, RS485 n'est pas un protocole mais (je cite wikipédia qui confirme) une norme qui définit les caractéristiques électriques de la couche physique d'une interface numérique sérielle.
- [^] # Re: Petite remarque ..
  
  Posté par totof2000 le 05 avril 2020 à 13:58. Évalué à 2.
  
  Ce serait bien aussi d'avoir une description (même succinte, quitte à mettre un lien vers une doc plus détaillée) des protocoles d'échange.
  - [^] # Re: Petite remarque ..
    
    Posté par metalu.net le 07 avril 2020 à 13:54. Évalué à 3.
    
    Le protocole Fraise est documenté ici :
    https://github.com/MetaluNet/Fraise/blob/master/doc/protocol.md
    - [^] # Re: Petite remarque ..
      
      Posté par totof2000 le 08 avril 2020 à 11:19. Évalué à 2.
      
      Merci, c'est exactement ce que je cherchais.
# Libre ou pas libre ?

Posté par totof2000 le 05 avril 2020 à 14:02. Évalué à 1.

J'ai vu sur le site : CC-BY-ND. Est-ce le projet fraise qui est sous cette licence, ou juste le site du projet ?

Parce que si j'ai bien compris, le CC-BY-ND ne permet pas de diffuser un travail dérivé, donc pas libre … Ca casse tout :(
- [^] # Re: Libre ou pas libre ?
  
  Posté par totof2000 le 05 avril 2020 à 14:12. Évalué à 2.
  
  Bon: je me réponds à moi-même et à tout le monde à l'occasion: le projet est sous licence GPL:
  
  (voir https://github.com/MetaluNet/Fraise, tout en bas du readme.md):
  
  license : GNU GPL (see LICENSE.txt )
  
  J'ai eu "peur" un instant …

Suivre le flux des commentaires

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