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.
"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é.
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.
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…
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 !
[^] # Re: Avec ou sans Raspberry
Posté par metalu.net . En réponse à la dépêche FRAISE : FRAmework for Interfacing Software & Electronics. É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.
[^] # Re: Avec ou sans Raspberry
Posté par metalu.net . En réponse à la dépêche FRAISE : FRAmework for Interfacing Software & Electronics. Évalué à 1.
mon cahier des charges pour le bus :
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: Petite remarque ..
Posté par metalu.net . En réponse à la dépêche FRAISE : FRAmework for Interfacing Software & Electronics. Évalué à 3.
Le protocole Fraise est documenté ici :
https://github.com/MetaluNet/Fraise/blob/master/doc/protocol.md
[^] # Re: Avec ou sans Raspberry
Posté par metalu.net . En réponse à la dépêche FRAISE : FRAmework for Interfacing Software & Electronics. É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 metalu.net . En réponse à la dépêche FRAISE : FRAmework for Interfacing Software & Electronics. É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 metalu.net . En réponse à la dépêche FRAISE : FRAmework for Interfacing Software & Electronics. É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