DSPiy Forum

Voici un sujet de réflexions pas en rapport direct avec le DSPiy, quoi que oui, mais d’une manière générale voir comment programmer « simplement » ces petites cartes que sont Raspberry PI et/ou BeagleBone.

La première (RPi) est bien plus courante, plus suivie et donc mieux documentée.
La seconde (BBB) semble mieux pour des applications audio au niveau hardware.

Ces cartes tournent nativement sous Linux avec toute une série d’applications existantes.

Mon but est de créer des applications, dans le cadre du DSPiy, mais aussi pour mon boulot.
Ces cartes peuvent s’apparenter à de petits PC tout en ayant le grand avantage d’avoir des GPIO et donc par exemple commander directement une simple LED, chose impossible avec un PC normal. (dans le passé on avait bien le port //, mais c’est du passé)
Mais aussi de contrôler de port I2C, I2S, série +- directement.

Le langage : j’ai découvert et utilisé le C# pour écrire DStudio.
Ce langage a pas mal d’atouts et basé sur un framework qui est censé rendre le code écrit utilisable sur d’autres processeur que ceux des PC.
Ça tombe bien pour nos petites cartes.

Gratuit : non pas que je ne veuille pas payer, mais les licences sont souvent lourdes à gérer.
Par exemple, j’ai un PC au bureau et un à la maison ; donc 2 souvent licences alors qu’il n’y qu’un seul utilisateur…

En C# pour Linux, il y a Mono qui fonctionne aussi sur RPi.

Là où tout se complique, c’est pour écrire le soft.
Soit directement sur le RPi avec un éditeur de texte et commandes en ligne, pas trop pratique.
Soit l’IDE de Mono qui semble tourner aussi sur le RPi, mais c’est tout de même beaucoup demander à ce petit processeur et d’une ergonomie pas optimale.

Il existe des solutions à partir de VisualStudio de Microsoft (ce que j’ai utilisé pour DStudio) sur un PC connecté au RPi via Ethernet.
Cette solution semble bien, mais un rapide tour sur internet montre que tout le monde à sa manière de faire et n’utilise pas la même distribution de Linux.

Une tout autre solution serait d’utiliser non plus Linux mais le tout nouveau Win 10 IoT fait pour ces processeurs et qui tourne sur la RPi.
D’une rapide lecture, Win10 IoT sur RPi semble bien incomplet, il ne semble pas gérer la partie audio par exemple.
Et aussi semble nécessiter Windows 10 sur le PC qui sert au développement et j’ai pas trop envie de changer de mon Windows 7 déjà que je préférais XP.

Pour en revenir au DSPiy, on pourrait donc presque faire tourner DStudio sur un RPi.
L’intérêt est moyen, par contre reprendre des parties de code de DStudio ouvrirait pas mal d’horizons.

J’ai tenté de faire bref , je ne me suis pas encore fort documenté d’où ce sujet.

je n'ai qu'un avis philosophique livresque car je n'ai pas pratiqué.
C# et .net sont ancrés dans le monde microsoft+intel et vraiment pas été prévus pour en sortir. raccorder avec de l'arm+linux c'est le grand écart et tu vas galérer. Win10 iot c'est tout nouveau et de toutes manière pas de .net complet la dessus.

Soit changer pour un langage+framework adaptés à ta cible soit regarder du coté des cartes a base d'intel atom.
Je ne connais pas MONO mais j'ai entendu parler de Visual Micro, extension de Visual Studio pour les cartes, dont par exemple les arduino et galileo (intel/windows).

Aussi, si tu veux rester dans le monde windows, les micro-pc a peine plus gros qu'une clé USB débarquent.
Pour les pcs, il existe des cartes E/S sur port usb.


ps:Je suis en train de passer de win7 à win10. Quelques repères a retrouver mais ça va. pas mal cet os pour les activités bureautique et ludiques. Pour ton usage, peut etre inutile mais faudra bien migrer dans les 12 mois. sinon en plus de devoir migre, tu devras payer !

Il y a quelques années, j’avais un peu testé du C# sur WinCE.
Et même sans maitriser le C# en moins d’une heure j’avais une mini application avec de beau boutons qui tournais sur une carte et sur un Smartphone.

Par contre jamais réussi sur cette carte à accéder au port I2C.

Et c’est là aussi que les mini-PC à base d’atom sont en général mal lotis, c’est comme un PC de bureau avec en plus, parfois, un RS-485.

Actuellement j’utilise des PC sous XP achetés d’occasion et de petits Netbook aussi sous XP pour des applications dédiées à une machine par exemple.
Pour les IO, ce sont des cartes maison. Ça fonctionne bien mais tout de même un peu lourd et parfois trop lent (pas assez temps réel) vu que l’on passe par USB -> RS485.

Je pense que par Visual Micro tu fais référence au microframework.
De mémoire il est passé en open tellement il était peu utilisé et un peu ridicule.

PS : Win10 m’énerve déjà, suis sous Win7 Pro bien mis à jour et tous les matins il me dit de passer à Win10.
Put..n, j’ai payé, je peux pas travailler tranquillement avec un produit que je connais et qui fait tourner mes applications ?

RPi commandé et reçu.
C’est petit, il n’y a pas grand-chose là-dessus, mais comparé à une BBB il a l’avantage des connecteurs standards et bien placés.

J’ai trouvé et tenté de suivre ce tuto :
http://j.tlns.be/2015/02/04/getting-sta ... evelopers/

Il explique tout, de l’image à l’installation de Mono.

Mono va permettre de faire tourner les programmes en C# et contient aussi un IDE pour les créer bien que l’étape suivante sera de les écrire avec VisualStudio.

L’univers Linux est déroutant, beaucoup de choses que l’on ne comprend pas forcément.
J’avais par exemple zappé la première ligne "Expand Filesystem" et donc ma carte lui paraissait full à 2.9G
Les mots de passe sont une plaie, apparemment les chiffres du pavé numérique ne sont pas pris en compte et le clavier est Querty de base.
Et bien évidemment il n’affiche strictement rien lorsque l’on tape un mot de passe.

Donc mon RPi est connecté à mon réseau et je prends ainsi la main directement sur mon PC ce qui est bien plus pratique que de travailler et clavier et écran connectés au RPi.

On peut par exemple faire du copié /collé du tuto. Le copié c’est Windows, le collé un clic droit dans l’espèce de fenêtre DOS du RPiy qui est la console.
Pour la partie «graphique », il y a VNC d’expliqué mais ne fonctionne pas encore chez moi.

Voici donc mon premier programme en C# sur RPi direct via l'écran et clavier du RPi et l’éditeur de Mono.

M'enfin...qu'est ce que tu vas encore faire avec ça!!!
Je vais me faire fournisseur de doliprane.

Plein de choses.
Les microcontrôleurs, c’est bien, disponible de suite, rapide dans leurs limites et stables pour un prix très faible.
Mais niveau prix, si c’est développer une carte pour produire quelques pièces ont est directement bien plus cher qu’un RPi.
Le PC c’est bien mais tout de même lourd et cher pour des applications d’automatisation par exemple.

super, ça promet !
mais pourquoi faire du C# et du visualstudio avec une carte RPi ??? là tu rentre sur des chemins peu fréquentés et peu documentés. Et nous on va devoir suivre si on veut faire du diy

allez, un petit lien rien que pour toi
http://mchobby.be/wiki/index.php?title=Rasp-Clavier-BE

Il va peut-être falloir que je réfléchisse à mon projet sur tu commences à développer sur le Rpi

Le C# est langage relativement puissant stable et simple, merci Microsoft.
Il est donc adapté à des applications telles que DStudio mais aussi pour faire vite une petite appli sur un coin de table.

De ce que j’ai lu, on peut simplement créer son appli sous VisualStudio, compiler et envoyer le .exe à Mono.

On a donc un système de développement puissant : VisualStudio qui est maintenant gratuit en version Community qui est 100% complète.

On a un langage simple et le RPi qui coute vraiment pas cher.

Là où je me pose des questions est pour le débugage, mais je verrais à l’usage.

Mais en // je verrais aussi pour C tout simple que j’utilise couramment sur les µC. mais ce sera plus pour applis sans interface et/ou gestion de données complexes.

Pour le clavier, merci mais je pense que le clavier n’est configuré qu’après avoir introduit loggin et mot de passe.
Mais en utilisant le système de terminal via Ethernet aucun soucis du genre heureusement.


Oui Louisr, je pense que si ton système est câblé il est tout à fait envisageable de troquer l’ATmega pour un Rpi.
Mais pas de précipitation et je pense que l’ATmega est bien dimensionné pour ce que tu veux faire.

je ne discute pas sur la simplicité de VS et de C#, msft est très fort pour ça, mais de l'adaptabilité au RPi.

quelles performances/consommation de ressources sur le RPi des programmes écrits en C# ?
comment réutiliser les nombreuses librairies existantes pour le RPi ?
Comment obtenir du support en cas de difficulté/bug ?

peut etre qu'il y a des réponses simples et positives a ces questions, je ne suis pas spécialiste et elles ne m'ont pas sauté aux yeux sur les forums Rpi.
je sais bien que DStudio est en C# et que ça parait naturel de continuer sur le même environnement pour des protos sur RPi. Mais bon, j'y réfléchirai a deux fois parce qu'une fois commencé, on reste avec pendant des années. Msft est très fort pour ça aussi

Tu as entièrement raison.
Disons que c’est aussi justement de la curiosité et voir de pas sois même toutes ces questions.
L’un des buts étant aussi de me familiariser avec Linux, ce qui n’est pas gagné.

Oui Louisr, je pense que si ton système est câblé il est tout à fait envisageable de troquer l’ATmega pour un Rpi.
Mais pas de précipitation et je pense que l’ATmega est bien dimensionné pour ce que tu veux faire.

En fait, le soucis de mon système, à mon avis, c'est que j'aurai 3 prises USB pour les 3 dspiy, plus éventuellement une pour l'atmega (via le port série ou direct). Je trouve ça gênant, et c'est pour ça que si tu développe des appli compatibles avec DSTUDIO sur le RPI, ça peut être très intéressant.

pas certain de faire DStudio sur RPi ni de son intérêt.

Il est possible de mettre un hub USB.
Fonctionnait bien avec DSPiy V1 mais pas en V2 vu que DSTudio ne fait de différentie pas ce qui est connecté.
Par contre le CP2114 a son RST sur le +5V USB.
Donc il suffit, a mon avis, de le gérer via ton ATmega pour activer un seul DSPiy en USB.
Ou un hub avec gestion d'énergie.

Par contre pas d'isolation galvanique, mais déjà (de mémoire une résistance sur le GND USB). A creuser pour qu'il n'y ais pas de courant perturbeur par ce chemin.

Ton idée est intéressante, faudra que je creuse ça, merci !
En fait je pensais à une "extension" de dstudio sur le dspiy. On a toujours DStudio sur le pc, l'extension sur le Rpi. On fait la config sur dstudio comme d'habitude, puis on l'envoi à l'extension via le réseau, qui le rentre dans la mémoire du dspiy. Je sais pas si c'est faisable ou pas, et si c'est vraiment utile, c'est juste une idée comme ça

Oui, c’est un peu à cela que je pense, aussi en passant par exemple par le réseau en Wifi pour ne plus devoir sortir de câbles.
Et utiliser le RPi pour stocker les fichiers de DStudio.

ça serait super

Voici ce que j’ai sur l’écran de mon PC.
L’écran du RPi (Linux) qui passe par une « Connexion Bureau à Distance » de mon Windows7, donc Microsoft.
VisualStudio qui est l’outil Microsoft pour créer des programmes un peu dans tous les langages.
Et comme pour un programme Windows j’ai créé une simple fenêtre WindowsForm avec un bouton.
Via un petit utilitaire, Bitvise xterm, je peux transférer les fichiers compilés par VisualStudio sur le bureau du RPi.
Un double clic et j’ai ma fenêtre , c’est beau comment détourner du Microsoft au service de Linux.


Par contre il existe un utilitaire pour VisualStudio qui permet d’envoyer directement le programme compilé, de le lancer et même de le débugger sous VisualStudio.
Mais je n’arrive pas à installer la partie pour le RPi.

Contrôler les GPIO du RPi en C# c'est facile et fonctionne.
Normalement devrait aussi fonctionner pour l'I2C et le SPI.

Étape suivante , brancher un DSPiy en USB.
Il est reconnu


Par contre pas moyen (pour le moment) de trouver une lib ou autre pour communiquer au travers de l'HDI -> Série.