Bibliothèque Arduboy sous Linux?

International Français
1

Bonjour à tous,

Je cherche a simuler une Arduboy sous GNU/Linux sans passer par la chaîne de compilation AVR classique (trop longue à mon goût).

Je crois que je cherche un portage sous POSIX (Linux) de la bibliothèque arduino et des bibliothèques Arduboy version 1 et 2.

car théoriquement compiler et exécuter un jeu arduboy (V1 ou V2) ne devrait pas prendre plus de 2 secondes avec la chaîne de compilation native du système et ce genre de bibliothèques (et .h associés).

Ma quête avec les mots clés posix, arduino, linux ,portages, ne donne pas grand chose (sans passer par la chaîne de compilation AVR).

Ce genre de portages existent ?

Merci d'avance :wink:

2

De toutes façons sous Linux (PC ou RPI) la compilation passera forcément par la chaîne GCC de la plateforme.
La chaîne AVR-GCC produit du code pour AVR, et rien d'autre.

La demande mérite d'être clarifiée.
S'agit-il de simuler un Arduboy :

  • sur PC ou RPI ?
  • quel clavier ? quels boutons ?
  • quel écran ? écran de PC ? écran RPI ? écran OLED ?

Le temps de compilation est un problème tout à fait mineur.

3

Il existe un émulateur d'Arduboy

4

Merci hbacheti pour ta réponse :wink:

je clarifie :

D'après ce que j'ai vu de l'arduboy : architecture de l'arduboy réelle : carte leonardo (micro contrôleur atmega32u4), 6 bouton poussoir (UP, DOWN, LEFT, RIGHT, A, B), une led RGB (je peux m'en passer), un (ou 2 ?!?) buzzer (je peux m'en passer) un écran OLD 128x64 pixels (pilote SSD1306) sur bus SPI. Certains jeux utilisent aussi l'EEPROM (scores).

En fait je découvre donc j'ai pu oublié des choses.

Il me faudrait donc la version posix de : delay(), millis(), ..., digitalRead(), digitalWrite, analogWrite, ...eeprom.read, ...la gestion du bus SPI (au moins pour cet écran ). Les entrées/sorties, l'eeprom et l'écran étant simulé en mémoire.

Exemple : réécriture de delay : void delay(unsigned long ms) { usleep(ms*1000); }

je n'ai pas la console, je cherche juste à trouver la solution la plus agréable pour développer dessus (expérience pédagogique). Lorsqu'on est débutant et que l'on veut développer on fait beaucoup de tests (notamment lors de la découverte d'une bibliothèque graphique aussi minimaliste soit-elle) et je trouve que se trimbaler la bibliothèque Arduino, Arduboy et la chaîne de compilation AVR est lourd alors que si quelqu'un a porté ces bibliothèques sous Posix, un simple (pour ceux qui pratique le C++ en ligne de commandes) :

gcc -Wall -o truc truc.ino bidule.cpp -larduino -lardubox # Plus sans doute des option -I pour les fichiers .h).

Plus simple, plus rapide, compatible avec les IDE classiques, ....

Ensuite pour la partie graphique (écran OLED, touches clavier associés au boutons je sais faire et sinon certaines utilisant la SDL2 (existent déjà)).

Je dis POSIX pour inclure tous les Linux (et donc Raspberry), Mac, ou même Windows avec Cygwin ou via WSL. Mais en effet, il faut une couche graphique pour l'écran mais or sujet ici je pense.

@fdufnews, déjà merci. En fait c'est cela que je veux mais en C/C++, pas en JavaScript ;-). En tout cas c'est très fort je trouve ce qu'ils ont fait (une machine virtuelle arduboy en javascript ;-)). Par contre il faut toujours utiliser la chaîne de compilation AVR :frowning:

C'est déjà pas mal mais, il doit bien y avoir ce que j'appellerai un portage Arduino (ou Arduboy ou les 2) vers POSIX quelque part non ?

Si je ne suis toujours pas clair n'hésitez pas.

Merci,

5

Honnêtement, je ne vois pas pourquoi quelqu'un aurait développé ça. La plateforme Arduino a été développée pour permettre aux débutants de pratiquer les microcontrôleurs sans prise de tête. Donc pour la faire courte Arduino c'est pour les noobs (ou les flemmards)
Donc typiquement des gens qui ont absolument aucune envie de faire du Posix (ils ne savent d'ailleurs surement pas, pour la plupart, ce que c'est).

C'est un émulateur qu'importe le langage dans lequel il a été développé. Il émule le comportement de la cible et il exécute le code natif de celle-ci.

6

Ces fonctions (non POSIX) sont à développer, ou à trouver.

En dehors de la RPI, il sera impossible de développer des interfaces d'entrée/sortie (entrées / sorties digitales, SPI) sur un PC sans carte additionnelle.
En se limitant à la RPI, c'est déjà plus envisageable.

WIRING-PI est un portage des fonctions ARDUINO sur RASPBERRY PI.
A toi d'explorer, d'essayer.
Quand au PC ou au MAC, sans hardware très particulier, no way ...

7

@fdufnews, dans mon cas je n'ai pas de vrai matériel (je simule l'écran et les touches) et le système Linux m'est imposé (par moi même il est vrai ;-)). je n'ai pas d'autre choix sauf à me trimbaler toute le chaîne de compilation AVR pour produire le .hex pour ensuite lancer un émulateur. Encore une fois c'est mieux que rien et je te remercie :wink: mais je cherche à compiler nativement. Actuellement, Arduino est déjà portée par exemple pour esp8266 et esp 32 fonctionnant sous système FreeRTOS. Il manque une "board" POSIX ;-).

@hbacheti

Merci, très intéressant. Du coup, peut-être qu'un utilisateur de Raspberry PI à fait un portage (redirigeant digitalRead arduino vers digitalRead WIRING PI + 2 ou 3 autres bricoles :wink: histoire de faire tourner ses programmes Arduino sous PI sans toucher le code ;-). Si c'était le cas je pourrai récupérer le gros du boulot, juste à shunter les appels à WIRING-PI dans ce portage. D'ailleurs je vois que delay est à la fois dans Arduino et Wiring-PI, c'est un bon début :wink:

En tout cas merci à tous les 2, je vais aller poser la question dans un forum Raspberry PI (un forum francophone à me conseiller pour la PI ?)

8

Ce que tu ne comprends pas est qu'aucun portage ne t'apportera une interface complète WIRING, à part sur RPI.
L'autre aspect que tu ne comprends pas est que la RPI est pourvue d'interfaces hardware entrées / sorties digitales, I2C, SPI (à condition de les maîtriser), ce qui n'est pas le cas d'un PC ou d'un MAC.

POSIX, par rapport à WIRING, ne gère que quelques aspects simples, le temps (sleep(), usleep(), clock()), l'interface série, mais en aucun cas les entrées / sorties digitales, I2C, SPI.

Tu fais fausse route ... et les motivations sont dérisoires : gagner en temps de compilation par rapport à une cross-compilation AVR. Rien ne me prouve que la compilation d'un source en natif sur PC prenne moins de temps que la compilation du même source pour produire du code AVR. De plus sur RPI elle prendra forcément plus de temps que sur PC.

Et tu n'as pas répondu à la question principale :

Quelle solution est-elle envisagée sur PC ou MAC ?
Une carte d'entrées / sorties USB ? avec SPI et I2C ?

Essaie plutôt un ESP32, ça change la vie, sans se donner toute cette peine.

9

Je veux bien que tu dises que je ne comprends pas mais là je n'ai pas d'entrées/sorties réelles (une fenêtre graphique X11 pour l'écran avec touches claviers pour les boutons). Pourquoi veux-tu que j'aille voir du coté d'un esp32 ?

Bon mais en effet si tu considères que vouloir compiler 500 lignes de C (code d'un petit jeu Arduboy) et les exécuter en moins de 2 secondes (temps d'une compilation classique de 500 lignes de C) est un luxe, l'intérêt de la manip n'a pas en effet de sens. Surtout qu'il y a la solution du projet ABE proposé par fdufnews qui est très bien mais qui nécessite de lui fournir un .hex (et donc de disposer de la chaine de compilation AVR complète).

Moi perso cela m'intéresse de court circuiter cette couche AVR inutile dans mon cas. Seule Arduino et Arduboy m'intéresse (dans ce cas) ;-)).

En fait j'ai l'impression que tous les simulateurs Arduino passe par une simulation AVR. C'est très bien (permet vraiment d'approcher au plus la réalité, les registres SFR, les périphériques... ) mais trop lourde je trouve pour mon cas (voir pour d'autres).

10

Tu annonces des chiffres tirés d'un chapeau. Tout dépend du PC.
Seul le chargement sur la cible prend du temps.

11

J'utilise arduino-cli, la chaine de compilation la plus rapide que je connaisse sous GNU/Linux, pour compiler le célèbre Blink.ino des exemples :

$ time arduino-cli compile -b arduino:avr:leonardo
Sketch uses 3962 bytes (13%) of program storage space. Maximum is 28672 bytes.
Global variables use 149 bytes (5%) of dynamic memory, leaving 2411 bytes for local variables. Maximum is 2560 bytes.

real 0m1,015s
user 0m1,029s
sys 0m0,116s

L'équivalent en natif :

$ time gcc -Wall -o blink blink.cpp

real 0m0,052s
user 0m0,027s
sys 0m0,025s

1 seconde contre 0.05 seconde, 20 fois plus rapide.

(blink.cpp) :


#include <stdio.h>
#include <unistd.h>

void loop() {
    puts("on");
    usleep(1000*1000);                       // wait for a second
    puts("off");
    usleep(1000*1000);                       // wait for a second
}


int main() {
    while(1) {
        loop();
    }
    return 0;
}
12

Correction, avec g++ on ne va que 10x plus vite :
$ time g++ -Wall -o blink blink.cpp

real 0m0,109s
user 0m0,090s
sys 0m0,019s

13

Pour ma part je pense que le gain en temps de compilation pour de petites applications est un problème mineur.
Le temps de chargement du code sur la cible par la ligne série est autrement plus important.
La proposition de fdufnews me semble correspondre au besoin, car elle permet de gagner le temps passé au chargement, qui est le plus gros morceau.

J'ai il y a quelques années porté sous Windows un framework embarqué tournant sur ARM7.

Le but :

  • éviter le chargement sur la cible (environ 1 minute)
  • avoir accès à un débogueur sans matériel particulier

Cela m'a pris quarante heures pour porter seulement l'OS.
Ensuite, il y avait tout un ensemble de drivers (boutons, écran alphanumérique, lecteurs de cartes à puces, monnayeur, etc).
J'ai simulé tout ceci sur PC, en mode graphique, avec des fenêtres, des zones à cliquer, des boîtes de dialogue, le tout plaqué sur une photo de la machine. Le résultat était très réaliste.

Par rapport à mon équipe où une dizaine de personnes utilisaient ce framework, la simulation était rentabilisable en quelques mois.

Le problème est dans le rapport temps de développement / gain en temps de compilation.
Si tu estimes que cela en vaut la peine, lance-toi.

14

Et bien merci pour ce retour constructif, c'est exactement ce que je veux.

Cela ne semble donc pas exister autrement que par cross compilation pour Arduino sous Linux.

Si tu élargis mon pb "arduboy" à des maquettes comme les tiennes, pédagogiquement cela serait intéressant non ?

Je me charge de la partie graphique et tu fais le reste ok ? :wink: Tu es entraîné !

Bon mais je suis bien conscient de la quantité de travail nécessaire j'espérai que cela soit déjà fait...

15

Bonjour, j'ai trouvé :wink: : GitHub - bxparks/EpoxyDuino: Compile and run Arduino programs natively on Linux, MacOS and FreeBSD.,

Bonne journée à tous !

16

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.