Symbolibre

Accélération graphique sur le Raspberry Pi Zero

2021-04-10T00:00:00+02:00

L'aspect minimaliste du Raspberry Pi Zero rend l'utilisation du GPU très attirante pour atteindre de bonnes performances à la fois sur le bureau et sur les applications. La documentation reste cependant assez discrète, et c'est dans les articles publiés au cours des années par les utilisateurs de Raspberry Pi que j'ai trouvé les plus d'informations sur la configuration et l'utilisation de l'accélération graphique sur cette plateforme.

Étant moi-même passé par là, je pense approprié de laisser quelques notes qui (j'espère) aideront d'autres utilisateurs dans le futur. 😀

L'article est très long (le plus long à date !) et assez technique, donc pour cette fois je n'ai pas rédigé de version française. Je vous invite à voir la version originale en anglais pour tous les détails. Voilà quand même les éléments principaux :

Le GPU VideoCore 4 du Raspberry Pi Zero est utilisé presque automatiquement une fois que Mesa et le module vc4 d'Eric Anholt sont installés et configurés.
Les applications qui utilisent le rendu accéléré avec X (DRI2) ou dessinent avec OpenGL (Wayland) n'ont pas de problème pour maintenir de bonnes performances.
Mais pour une raison qui m'échappe, l'accélération intégrée au serveur X (Glamor) a des gros problèmes, ce qui limite drastiquement les performances, qui sont même en-dessous de la version non-accélérée. Cela affecte les primitives de dessin et le déplacement/redimensionnement des fenêtres.
J'ai donc choisi de privilégier Wayland avec des applications natives, qui est exempt de ce problème et maintient des performances raisonnables même sur un écran HD comme le 1280x1024 que j'utilise pour tester.

La prochaine étape sera de voir tout ça en action sur un écran 320x240 ! 😁

Le rôle et l'importance du logiciel libre

2021-02-16T00:00:00+01:00

Symbolibre est un projet axé entièrement sur les calculatrices graphiques et le logiciel libre. Mais à quoi sert exactement le logiciel libre pour que nous lui dédiions une calculatrice entière ?

Une histoire de liberté

Fondamentalement l'idée du logiciel libre est de donner un maximum de liberté aux utilisateurs. Contrairement aux idées reçues, ça ne veut ps forcément dire qu'un logiciel libre doit être gratuit, même si c'est souvent le cas. (En anglais, la confusion est encore pire puisque « logiciel libre » se dit traditionnellement "free software"). C'est le sens du mot « libre » dans Symbolibre.

Tout logiciel libre vient avec quatre libertés fondamentales:

Utiliser le logiciel pour tout usage.
Étudier le logiciel, y compris faire de la rétro-ingénierie.
Redistribuer le logiciel et en créer de copies.
Modifier le logiciel et redistribuer les versions modifiées.

Cela peut paraître évident, mais ces libertés ne sont généralement pas acquises. Les calculatrices graphiques de votre constructeur préféré ne vous autorisent probablement pas à soumettre les binaires à rétro-ingénerie ou à redistribuer des copies du système d'exploitation.

Avec le temps, le modèle libre s'est imposé comme un philosophie de développement logiciel solide, et a produit de nombreux logiciels, des systèmes d'exploitation (par exemple GNU/Linux) aux bibliothèques cryptographiques (comme OpenSSL et LibreSSL) en passant par des systèmes de développement ultra-portables (comme Qt) et à peu près tout logiciel communément trouvé sur un ordinateur... ou une calculatrice.

L'objectif de Symbolibre est de montrer que ce modèle libre s'applique tout aussi bien aux calculatrices graphiques, un produit qui embarque souvent du code propriétaire et veillissant à cause d'un manque de concurrence et d'efforts de développement. Notre but est de concevoir une calculatrice que vous pouvez assembler, utiliser, améliorer et étudier à volonté : en d'autres yermes, un outil que vous possédez vraiment.

Le modèle de contribution open-source

Le logiciel libre est souvent distribué suivant le modèle open-source, qui consiste à publier le code source et (la plupart du temps) à interagir avec les utilisateurs pour identifier des problèmes et améliorations à apporter au logiciel.

Parenthèse: Le logiciel libre ne requiert l'accès aux sources que pour les utilisateurs (qui ne sont, pour un logiciel payant par exemple, que les personnes l'ayant acheté), et n'implique donc pas que le logiciel est open-source. De même, un logiciel open-source peut être distribué sous des conditions incompatibles avec les libertés fondamentales et donc ne pas être du logiciel libre. Les deux concepts sont différents : il se trouve seulement que beaucoup de logiciels publics (comme ceux qu'on trouve sur GitHub) sont les deux. C'est une confusion classique.

Quelques aspects courants des logiciels open-source sont la capacité pour les utilisateurs de signaler des problèmes et de soumettre des « pull requests », un terme sophistiqué pour désigner une proposition de modification du code. Les plateformes de développement se sont beaucoup adaptées à ces techniques avec le temps, ce qui fait de l'open-source un mode de développement tout à fait compétitif.

Bien sûr, rien n'est parfait, et les logiciels libre et open-source ont aussi des inconvénients. Les petits et moyens projets sont souvent gérés par une seule personne (une poignée au mieux), et peuvent cesser d'être maintenus si les auteurs ne peuvent plus assurer la charge de travail. Lorsque la vision des contributeurs diverge de celle des auteurs, il est aussi très tentant de créer une copie du projet pour travailler sur une version dérivée (un « fork »), ce qui divise l'effort de développement et augmente le risque qu'une version ne soit plus maintenue. Et comme autant de ressources sont publiques, il est plus difficile d'en tirer un modèle économique (peu de gens achèteront les binaires d'un logiciel qu'ils peuvent compiler eux-mêmes).

Dans l'ensemble, les logiciels libres et open-source encouragent les utilisateurs à s'approprier les programmes. Nous pensons que c'est on ne peut plus naturel pour un outil éducatif d'adhérer à ces philosophies, et d'inciter les étudiants à explorer le fonctionnement d'une combinaison somme toute complexe d'électronique et de logiciel.

La différence entre Symbolibre et Numworks

Cet article est une bonne occasion de répondre à une question commune. Durant le projet, beaucoup de personnes nous ont demandé : "Numworks ne le fait-il pas déjà ?"

Eh bien... plus ou moins. Numworks publie son code source (principalement son système d'exploitation Epsilon) sous une license assez permissive et échange avec sa communauté à son sujet, et c'est tout à son honneur. En tant que produit fini qui concurrence directement les modèles établis, la société prend le parti de la transparence et on apprécie cette position qui montre bien qu'un programme n'a pas besoin d'être privé pour être bon.

Cela étant dit, le code source d'Epsilon est publié sous la license CreativeCommons BY-NC-SA, qui autorise les modifications et la redistribution, mais pas les usages commerciaux — on ne peut donc pas construire de calculatrice avec. Le but de Numworks n'est pas de créer un logiciel libre ; la société prône la transparence mais Epsilon reste son produit. Ça se voit dans le contrat de license (CLA, en anglais) que les contributeurs doivent signer, où ils lèguent à Numworks leur propriété du code avant qu'il ne soit intégré au logiciel.

Ultimement, leur modèle de développement n'est pas vraiment open-source (et surtout pas libre). Bien que les développeurs acceptent régulièrement des corrections de bugs et quelques fois des nouvelles fonctionnalités, seul le code des versions majeures est public, et de nombreuses contributions communautaires sont déclinées. Même des corrections majeures restent parfois longtemps dans les sources privées (on pense aux crashs d'émulateurs Android et à des bugs Python). Cela a conduit les utilisateurs à créer leur fork d'Epsilon, Omega. C'est parfaitement raisonnable du point de vue technique, mais nécessite que la communauté maintienne ses fonctionnalités à jour à chaque nouvelle version d'Epsilon, avec peu ou pas d'aide de l'équipe Numworks (le code d'Epsilon n'ayant aucune garantie de stabilité et très peu de documentation).

Et puis il y a l'autre idée derrière Symbolibre : créer une calculatrice graphique qui soit moderne à la fois au niveau matériel et logiciel. Sur cet aspect-là, Numworks ne brille pas plus que ses prédécesseurs. Leurs caractéristiques techniques annoncent seulement 256 Kio de RAM, ce qui impose des limites très dures comme la mémoire de travail Python de 32 Kio. Je n'ai pas été surpris d'apprendre qu'ils ne pouvaient pas se permettre d'allouer les arbres d'expressions dans le tas.

Ce type d'environnement matériel et logiciel limité (systèmes d'exploitation personnalisés compris) a coûté à Casio et TI des mois de travail pour porter MicroPython lorsque Python est apparu dans les programmes de lycée (Numworks l'a toujours supporté mais est tout autant limité dans son ensemble de fonctionnalités et modules disponibles). Il ne faut pourtant que quelques minutes pour installer l'interpréteur standard python3 et tous ses modules sur notre système GNU/Linux.

Dans l'ensemble, même si nous reconnaissons à Numworks le mérite de publier leur code et d'interagir avec leur communauté, nous pensons qu'il y a encore beaucoup de progrès à faire en termes de liberté et de modernité dans les calculatrices graphiques.

Conclusion

Le logiciel libre est une philosophie unique qui donne à ses utilisateurs le plus de liberté possible. Elle est souvent combinée au modèle open-source qui permet aux utilisateurs de contribuer au logiciel des informations, des idées et du code.

Ces deux philosophies ont été historiquement inexistantes dans le monde des calculatrices graphiques. Depuis 2017, Numworks les a mises en valeur de façon ambiguë en n'adhérent à aucune tout en ressemblant aux deux. Symbolibre adhère sans équivoque aux deux, et nous nous attachons à montrer en quoi cela sert les utilisateurs et les outils éducatifs. 😀

Merci beaucoup aux membres de l'équipe Omega, RedGl0w and Quentin (ainsi que d'autres contributeurs Omega !) pour m'avoir expliqué les subtilités du modèle de développement de Numworks et s'être assurés que cet article soit aussi juste que possible.

Commentaires

De Ne0tux le 12 Février 2021

Merci pour cet article qu'on sent écrit avec passion.

Symbolibre n'a pas vocation à ma connaissance à produire puis distribuer en grande surface tout en rémunérant une équipe, comme le fait Numworks. Des choix de production ont été faits, dans le but de proposer un produit relativement stable (testé en tout cas) tout en prévenant a minima les copies hardwares/softwares. Le modèle économique n'étant pas le même, il me parait naturel que la philosophie soit différente. Les points communs sont déjà très positifs !

Le passage sur les capacités hardwares semble en décalage avec le sujet de l'article. Même s'il est intéressant, il montre une volonté d'opposer Symbolibre et Numworks. A titre d'illustration des paragraphes précédents, le face à face est pertinent, mais certains détails concernant l'écoute de la communauté, l'intégration des proposition et l’absence de bugs etc me semblent "de trop". Ou en tout cas pousseront à regarder ce qu'il en sera côté Symbolibre.

Du reste, lorsqu'il est simplement question de libre, on sent que le projet est fondamentalement encré dans cette philosophie. Ça fait plaisir !

De Sébastien Michelland le 12 Février 2021

Merci ! En effet, les méthodes de conception de Symbolibre et Numworks sont très différentes. Cet article n'a pas de vocation à attaquer Numworks, il s'agit plus de montrer aux lecteurs non familiers avec le logiciel libre ce qu'une communauté peut désirer que Numworks n'accomplit pas.

Plusieurs personnes qu'on a rencontrées contemplaient Numworks en se disant « tout y est du coup ? », et... cet article a pour du but d'expliquer que pas tout à fait. Cette « opposition », dans l'esprit où j'ai écrit l'article, est surtout pour donner à Symbolibre un caractère qui échappe à l'argument de « Numworks le fait déjà ».

Les points communs ne sont que des raisons de réjouir ; il me semble simplement important de s'attarder une fois sur le caractère unique de chaque projet pour éviter les ambiguïtés. Promis, ce ne sera pas un motif récurrent. 😀

Conception appliquée : les touches de fonction et le catalogue

2020-12-26T00:00:00+01:00

La conception de bonnes interfaces utilisateur est une science, et d'ailleurs également un domaine de recherche (article en anglais). Bien que personne dans le projet Symbolibre ne soit spécialiste de ce domaine, nous essayons constamment d'améliorer l'accessibilité de nos applications en rendant l'interface utilisateur plus intuitive. Dans cet article, j'aimerais explorer une situation concrète de conception d'interface : les touches de fonction et le catalogue.

Comprendre le chemin menant à chaque action

La première version du clavier Symbolibre ressemblait à peu près à ça : quatre lignes de saisie numérique en bas, puis deux lignes de saisie mathématique et une ligne de programmation. Enfin les touches de contrôle et de direction.

Disposition du clavier pour le premier prototype Symbolibre.

Ce clavier était inspiré des dispositions de CASIO (que je connais le mieux) et Numworks (qui est principalement une simplification de celle de CASIO). L'objectif était de faire simple et de ne pas surcharger l'utilisateur avec des fonctionnalités qui n'ont pas besoin d'être directement sur le clavier, donc le mode alphabétique (les labels gris activés en appuyant sur ALPHA) était limité aux lettres uniquement, et le tiers le plus bas du clavier avait un minimum de fonctions secondaires (dans certaines disposition récentes il n'en a aucune).

On peut comparer ça à la disposition plus dense de la Graph 75+E de CASIO, qui a beaucoup plus de fonctions secondaires. Elles sont toutes utiles, mais à mon avis pas au point de devoir être accessibles directement sur le clavier.

Cette disposition générale a été utilisée pour toute la série des CASIO Graph.

L'accès direct est une question importante en raison de la durée nécessaire pour saisir un certain caractère ou accéder à une certaine fonction. On souhaite naturellement que les fonctions utilisées souvent soit accessible par une courte séquence de pressions de touches, tandis que les fonctions plus complexes et utilisées moins souvent sont plus utiles si elles sont bien organisées dans une interface graphique.

J'aime bien voir la séquence de touches à presser ou de menus à parcourir pour atteindre une action comme un chemin menant à cette action. Certains aspects d'une bonne organisation des chemins d'actions sont assez intuitifs :

On apprécie les chemins qui sont courts car ça rend l'exécution des fonctions plus rapide. C'est encore plus important pour les fonctions utilisées souvent car le gain de temps est multiplié.
On apprécie les chemins qui sont clairs dans le sens où un utilisateur cherchant à exécuter une action choisie peut trouver son chemin à chaque étape sans avoir à explorer trop de possibilités.
Et ultimement l'organisation et l'usage des fonctions sont différents pour chaque utilisateur, donc on apprécie les chemins qui peuvent être personnalisés dans une certaine mesure.

Bien sûr le nombre important de fonctions mathématiques et de programmation disponibles sur une calculatrice formelle fait qu'une seule méthode ne peut pas couvrir toutes les fonctions, donc un bon système doit trouver un équilibre qui permet à différentes classes d'utilisateurs d'être efficaces.

Les problèmes de notre disposition initiale

Les deux régions en bas de notre clavier étaient (et sont toujours) dédiées aux saisies numérique, mathématique et de programmation avec un ensemble fixe de fonctions. Cela signifie que tout le reste doit passer par les touches de contrôle en haut.

La première disposition de clavier essayait d'attribuer une sémantique à chaque touche de contrôle pour s'assurer que leur rôle reste cohérent dans toutes les applications :

Catalog et Char pour la saisie de fonctions arbitraires et de caractères.
Back et Home pour naviguer dans les menus et les applications.
Help est une aide contextuelle.
Shortcut était une tentative de fournir des raccourcis à accès direct.
Config et Tools pour accéder aux fonctionnalités spécifiques de chaque application comme l'unité d'angles.

Le problème le plus direct avec cette disposition est que chaque symbole qui n'est pas sur le clavier (comme une intégrale définie) devait être saisi via Catalog et toute fonctionnalités des applications (comme une résolution graphique dans l'application de graphe) devrait être saisie via Tools.

Ça veut dire que chaque chemin commence avec une pression de touche qui n'apporte peu ou pas d'informations sur l'action que l'utilisateur essaie d'effectuer. Je vois ça comme un gaspillage d'efforts de l'utilisateur pour mettre en valeur l'idée qu'une bonne interface graphique exprime un maximum d'intention dans chaque interaction.

Mais de façon plus importante encore, l'utilisateur n'avait aucun indice visible décrivant les fonctionnalités interactives (comme zoomer sur un graphique, effectuer des résolutions graphiques, etc) avant d'ouvrir le menu correspondant. Généralement les menus ne différencient pas les fonctions simples et avancées, ce qui crée encore un peu plus de confusion.

J'ai tenté de sauver cette disposition en suggérant des labels plus spéciques comme Details, Options, Tools, Customize ou Actions, mais ils étaient encore pire parce qu'ils violaient le critère de clarté : il était presque impossible de trouver le bon menu parce que souvent une action choisie pouvait raisonnablement être dans tous.

La touche Shortcut était ironiquement cachée derrière un SHIFT (puisque c'était la fonction secondaire de Help), ce qui ajoutait une pression de touche gratuite aux actions supposées être rapides. 😅

La différence principale de conception entre cette disposition initiale et les nouvelles touches de fonction est d'autoriser les touches à avoir un rôle dépendant du contexte.

Touches de fonction

Les touches de fonction sont des touches numérotées (pour nous, F1...F5) avec un rôle dépendant du contexte. Le rôle est affiché sur une barre de fonctions en bas de l'écran, juste au-dessus des touches.

Labels labels sur la barre de fonction sont alignés avec les touches F1...F5 sur le clavier.

Cette idée n'est pas du tout nouvelle, CASIO l'a utilisé pendant des années. Mais la façon dont nous utilisons les touches de fonction pour construire notre interface diffère de plusieurs façons.

La série des CASIO Graph utilise les touches de fonctions à la fois pour la saisie et l'accès aux fonctionnalités interactives. Les touches forment un arbre de menus et d'actions, en partant soit de touches fixes comme VARS ou sa fonction secondaire PRGM, soit directement des touches F1...F6.

Par exemple, le chemin menant à la fonction Locate utilisée dans les programmes Basic pour afficher du texte à n'importe quelle position de l'écran est PRGM → I/O → Locate. PRGM est une fonction secondaire donc on doit appuyer sur SHIFT pour y accéder. Ce menu a par ailleurs plus de 6 catégories, donc il est séparé en pages qu'on l'on peut parcourir avec F6. I/O étant sur la deuxième page, on se trouve avec une séquence de 5 touches :

D'abord, SHIFT et VARS pour ouvrir le menu de programmation.
Ensuite, F6 pour naviguer jusqu'à la deuxième page et F4 pour ouvrir la catégorie I/O.
Enfin, F1 pour saisir la commande Locate dans le programme.

Ça peut sembler long, mais c'est assez efficace. Cette commande affiche 7 caractères donc elle est clairement plus rapide que de taper toutes les lettres, et les programmeurs avides ont souvent la mémoire musculaire pour la saisir en moins d'une seconde.

Le chemin menant à la commande Locate dans l'éditeur de programmes Basic de CASIO..

À mon avis, le problème de ce système n'est pas vraiment la longueur des chemins, mais leur (manque de) clarté. Il y a beaucoup de points d'entrée dans le système de menus, dont trois touches fixes (OPTN, VARS et PRGM) et beaucoup d'autres dépendant du contexte (comme la touche F4 MENU et les touches secondaires F2 ZOOM, F3 V-WIN et F4 SKTCH de l'éditeur de programmes, que l'on peut toutes voir brièvement sur l'animation précédente). Certains menus ont beaucoup de catégories (OPTN en a 16), et les menus sont assez profonds, avec souvent 3 ou 4 niveaux.

De plus, la petite taille de l'écran (128×64) rend difficile la tâche d'écrire des labels clairs. Les développeurs s'en sortent bien, mais les formes abrégées de mots anglais ne sont pas vraiment lisibles pour les étudiants étrangers et rendent l'accès à presque toutes les fonctions difficile pour les débutants.

Symbolibre n'utilise les touches de fonction que pour fournir des rôles dépendant du contexte, de sorte qu'appuyer sur une touche F1...F5 communique plus d'information qu'appuyer sur une touche générique comme Tools. Par exemple dans l'application de graphes, la touche F4 donne accès aux paramètres de la fenêtre en une seule pression.

La popup de paramétrage de la fenêtre est affectée à la touche F4 dans l'application de graphes.

Cela évite une pression de touche supplémentaire, tout en présentant visuellement à l'utilisateur les fonctions les plus importantes, pour aider les nouveaux utilisateurs à trouver les mécanismes les plus courants. Cet avantage serait perdu si tout était groupé dans Tools.

Nous n'utilisons pas de menus imbriqués sous cette forme à cause des problèmes mentionnés avec le système de CASIO. À la place, nous utilisons des popups en plein écran comme le catalogue, qui affichent des noms complets et des descriptions sans éliminer l'usage de la mémoire musculaire (j'y reviendrai).

Une conséquence de ces choix de conception pour le catalogue est qu'il serait bizarre d'ouvrir directement sur un sous-menu, donc on groupe quand même toutes les saisies indirectes derrière une pression de la touche Catalogue (qui est toujours assignée à F1). Au moins le catalogue est dépendant du contexte de l'application. L'animation ci-dessous montre le catalogue Python en action durant l'édition d'un script Python.

Utilisation du catalogue Python dans l'IDE.

Naviguer avec les touches de fonction

Écrire des formules, du code, et utiliser des fonctionnalités interactives ne sont pas les seules séquences de touches communes dans une interface graphique. Il y a aussi la navigation, que ce soit entre des applications, entre différents écrans d'une même application, ou même à l'intérieur d'une boîte de dialogue ou d'un menu.

Je pense qu'il y a une différence importante entre la navigation et la saisie des fonctions, qui est la connaissance de la structure globale. Lorsqu'on parcoure un menu pour trouver la fonction Locate, on n'a pas besoin d'avoir de notion générale de ce qui existe dans les menus et d'où est quoi ; il suffit de déterminer pas-à-pas où se trouve Locate tout en ignorant le reste.

À l'inverse, il est important pour les applications d'avoir des noms d'écrans et des méthodes de navigation dénués d'ambiguïté, pour que l'utilisateur sache à tout instant où il est et où l'écran actuel se situe dans l'application entière. Numworks atteint cet objectif d'une façon très intuitive en utilisant des onglets qui affichent les noms de tous les écrans en même temps.

Les onglets utilisés par Numworks pour organiser leurs interfaces graphiques.

L'inconvénient des onglets est que l'utilisateur doit déplacer le curseur pour sélectionner la barre d'onglets afin de pouvoir changer d'écran, ce qui nécessite une séquence variable et parfois longue de pressions de touches.

Nous avons testé différentes méthodes de navigation utilisant la barre de fonctions, comme on peut le voir dans l'application de graphes où le passage de la liste des fonctions au graphe se fait avec la touche F5.

Cela présente cependant un risque, celui de faire trop de choses avec le modèle générique des touches de fonctions, avec pour résultat une interface qui manque de structure et de cohérence. Nous n'avons pas encore fixé de modèle strict sur l'organisation de ces touches. Nous avons prévu, mais pas encore implémenté, différents styles de touches pour différents types d'actions, par exemple une couleur différente pour les touches de navigation ou un suffixe « ... » pour les touches qui ouvrent des boîtes de dialogue. Ces progrès se verront à la prochaine version !

Conception des menus

Avant de conclure cet article, je voudrais mentionner l'agencement des menus et catalogues, puisqu'il y a beaucoup d'options. La méthode minimaliste pour organiser un menu est simplement une liste alphabétique de toutes les options, comme le catalogue original de CASIO.

La catalogue alphabétique de CASIO avec un filtre par catégorie.

Ce système est difficile à utiliser, avec beaucoup de fonctions inconnues et quasiment jamais utilisées mélangées avec les plus communes. Les versions successives ont ajouté un filtre par catégorie et plus récemment un filtre textuel interactif, qui est la méthode la plus efficace pour trouver une fonction choisie à l'avance. Les modèles TI à base de z80 ont aussi un catalogue alphabétique, mais il y a plusieurs points d'entrée avec des touches spécialisées comme MATH, LIST ou PRGM.

Les menus contextuels de la HP Prime présentent une autre approche hiérarchisée, avec des fonctions catégorisées et des raccourcis clavier liés aux touches numériques.

Menus contextuels avec des raccourcis numériques sur la HP Prime.

Ce système est l'inspiration pour notre catalogue, où les chiffres peuvent être utilisés pour sélectionner rapidement des entrées. Par exemple, l'instruction from math import * peut être insérée via le catalogue en sélectionnant la catégorie Import (via la touche 0) puis math (via la touche 3).

Le chemin menant à from math import * est F1, 0, 3.

L'espoir est de répliquer à la fois l'efficacité de la saisie de CASIO et l'organisation des menus contextuels de la HP Prime, sans sacrifier la capacité à présenter des informations détaillées sur les fonctions et leur usage durant la recherche.

Conclusion

Les touches de fonctions sont utilisées dans les applications Symbolibre pour présenter à l'utilisateur des actions dépendant du contexte, qui communiquent à l'interface graphique plus d'informations que des labels fixes, et pour organiser les fonctions d'un façon qui met en avant les plus communes.

Cela se retrouve dans la forme des menus hiérarchiques et en particulier du catalogue de saisie, qui a besoin d'être à la fois détaillé pour les nouveaux utilisateurs et efficace pour les plus expérimentés.

La conception d'interface graphiques accessible à une large classe d'utilisateurs est certainement une tâche difficile, mais nous espérons que ces analyses et choix rapprochent nos applications Symbolibre de cet objectif.

Commentaires

De Ne0tux le 12 Février 2021

Bon article, qui se réfère aux méthodes présentes sur le marché. Concernant les onglets Numworks, c'est vrai que déplacer le curseur n'est pas pratique. Sur TI nspire, il y a des touches dédiées (forcément, vu leur nombre), pour switcher d'onglet ou d'appli. C'est une autre solution. Mais je parle de navigation, c'est peut-être hors sujet par rapport à la saisie.

De Sébastien Michelland le 12 Février 2021

Merci ! La navigation rentre tout à fait dans ce cadre. Je pense aussi qu'avoir des touches sensiblement fixes pour naviguer entre les écrans et applications est plus important que de minimiser à tout prix le nombre de pressions. Peut-être que la touche F5 remplira ce rôle avec le temps !

Publication de la version 0.2 de Symbolibre

2020-12-05T00:00:00+01:00

Plus d'un an après la fin de notre projet de master, nous sommes heureux de publier la version 0.2 de Symbolibre sous la licence libre GNU GPLv3. Vous pouvez consulter le code source sur github.com/symbolibre — les contributions sont bienvenues ! Notez que nous ne proposons pas de binaires prêts-à-lancer pour l'instant.

Le logiciel

Symbolibre a commencé dans le cadre d’un projet de Master 1 à l’ENS de Lyon. À la fin de l’année universitaire, l’équipe a été dissoute mais le développement ne s’est pas arrêté pour autant ! Sébastien Michelland et moi avons continué à développer Symbolibre, avec des contributions occasionnelles d’autres membres du projet. Nous nous sommes principalement concentrés sur le développement et la maintenance des applications.

Par rapport aux applications présentées à la démonstration publique et dans le test réalisé par TI-Planet en avril 2019, cette version 0.2 propose principalement des améliorations des interfaces des applications essentielles à une calculatrice de niveau lycée : calcul, tracé de fonctions, et éditeur de code Python. Ainsi ces applications bénéficient maintenant d’un style unifié avec une barre de fonctions, et un catalogue avec catégories et aide intégrée permet d’insérer plus aisément des expressions mathématiques et des fragments de code Python. Un gros travail a aussi été effectué sur la robustesse et la modularité du code, notamment à travers l’utilisation d’un build system fondé sur CMake. Une liste plus complète des nouveautés est proposée en fin d’article.

Le développement de l’application de paramètres, du langage Basic, et de l’application de communication pour PC est suspendu pour le moment. Certaines de ces sources ne sont pas incluses dans cette version 0.2, leurs dépôts seront publiés sur GitHub prochainement.

Le système et le matériel

Nous avons pris soin de tester nos applications sur un Raspberry Pi Zero, et nous expérimentons actuellement avec Raspbian en remplacement de Gentoo comme base pour le système d’exploitation. Le choix de Gentoo était avantageux pour nos expérimentations avec SageMath, que nous n’utilisons plus aujourd’hui. Un guide est en cours d’écriture sur la réalisation d’une image système Raspbian.

Nous n'avons pas encore construit de nouveau prototype ; nous prévoyons de le faire dans les mois qui viennent. Les principaux défis sont dans la disposition des composants dans le boîter et la technologie du clavier, pour laquelle il faut concilier confort de saisie et facilité d’assemblage.

L’avenir du projet

Maintenant que nous avons pris le temps d'organiser cette publication, nous avons beaucoup à partager. Une série d'articles suivra celui-ci pour détailler l'activité depuis la démonstration publique, qui représente plus de 400 nouveaux commits. Quant au futur du projet, je contribue toujours au code et Sébastien est en césure cette année pour progresser sur Symbolibre, vous pouvez donc vous attendre à plus de développements dans les prochains mois !

Liste des nouveautés

Applications mathématiques

L’application de calcul peut maintenant afficher des sommes et des intégrales.
L’application de calcul permet de remonter dans l’historique et de copier les expressions dans le champ d’édition.
Jusqu’à 10 fonctions peuvent être tracées simultanément.
Un catalogue d’expressions mathématiques avec une aide intégrée est accessible depuis les applications de calcul et de fonctions.

Éditeur de code

Pour simplifier la programmation Python, l’éditeur de texte auto-indente les nouvelles lignes.
Un catalogue de fonctionnalités Python est accessible depuis l’éditeur.

Divers

Les interfaces ont été revues, avec une barre de fonctions et un style global.
Un nouveau clavier virtuel est accessible par Alt+K pour une meilleure expérience sur ordinateur.
Les applications sont entièrement traduites en français et en anglais.
Le code est plus modulaire grâce au passage à un build system fondé sur CMake.
De la documentation est disponible en ligne.
De nombreuses corrections et ajustements.

Vous pouvez consulter le code et le compiler sur github.com/symbolibre.

Rapport de la première année de Symbolibre

2019-06-02T00:00:00+02:00

Le projet Symbolibre a été lancé dans le cadre de notre unité d’enseignement Projet du M1 d’Informatique Fondamentale à l’ENS de Lyon.

Notre second semestre étant maintenant terminé, nous avons rendu notre rapport final, d’une trentaine de pages (en anglais). Nous y parlons de nos motivations, de ce que nous avons accompli cette année, et de l’avenir du projet.

Car la fin de l’unité d’enseignement ne marque pas la fin du projet ! Nous avançons moins vite ces dernières semaines, mais nous continuons notre travail sur le code et nous préparons à publier les sources sous licence libre.

Vous pouvez suivre nos articles sur notre flux Atom. À bientôt pour la suite de l’aventure !

Télécharger le rapport (PDF, 9.4 Mo)

La démonstration publique

2019-04-07T00:00:00+02:00

La démonstration publique du projet a eu lieu Jeudi dernier à l’ENS de Lyon. Nous avons assisté à la présentation du projet Avatar ENSignes sur la représentation et le traitement du langage des signes avant de présenter l’utilisation du premier prototype de calculatrice Symbolibre. Nos visuels sont disponibles en ligne et incluent un certain nombre de captures d’écran illustrant les manipulations réalisées.

Nous y avons rencontré Bisam de TI-Planet, Yatis de Planète Casio, ainsi que nos deux contacts à l’Institut Français de l’Éducation et quatre élèves du lycée Albert Camus à Lyon. Auxquels s’ajoutent d’autres élèves de l’ENS, des membres du département d’informatique de l’ENS et divers amateurs de calculatrices HP. Merci d’être venus aussi nombreux !

Après la présentation, nous avons pu discuter de notre travail avec les personnes présentes et de tests à réaliser auprès de l’IFÉ. Nous planifions de construire des calculatrices et de les faire tester par des élèves de lycée en conditions réelles pour obtenir des retours à chaud sur l’utilisation de la machine et des applications. Nous avons déjà pu avoir un aperçu grâce aux élèves présents. Nous vous tiendrons au courant des avancées sur ce plan-là !

Ne manquez pas la démonstration publique du projet !

2019-04-02T00:00:00+02:00

Dans le cadre de notre projet de Master, nous sommes heureux de vous convier à la présentation publique de la calculatrice Symbolibre, où vous pourrez découvrir dans le détail l’avancement de notre projet !

La démonstration se déroulera ce jeudi 4 avril sur le site Monod de l’ENS Lyon, en amphi B, et débutera à 9h30. Notre présentation étant précédée par celle de l’autre projet de notre promotion, Avatar-ENSignes, pensez à venir dès 9h00 ! Par ailleurs, pour des raisons logistiques, prévenez-nous s’il vous plaît à l’avance de votre présence, en nous envoyant par exemple un e-mail à l’adresse symbolibre@symbolibre.org contenant vos nom et prénom (une pièce d’identité pourra sinon vous être demandée à l’entrée).

Nous espérons avoir le plaisir de vous trouver nombreux jeudi matin pour la démonstration publique de Symbolibre !

Résumé de l’enquête réalisée auprès des lycéens

2019-03-30T00:00:00+01:00

Dans le cadre du développement de notre calculatrice, un questionnaire a été élaboré à l’intention des lycéens et diffusé auprès d’eux, afin de cerner au mieux les différents problèmes rencontrés par les élèves dans l’utilisation de leur calculatrice au quotidien. Plus d’une centaine de réponses nous sont parvenues, ce qui nous permet de dresser des conclusions fiables sur les défis que doit surmonter Symbolibre dans son usage. Sans plus attendre, découvrons ensemble les résultats !

Que peut-on en conclure ?

Commençons par un constat général : rares sont les qualités véritablement plébiscitées par les utilisateurs. Hormis la clarté de l’affichage des calculatrices actuelles, tous les points sur lesquels nous avons interrogés les lycéens font l’objet d’une insatisfaction non négligeable, et parfois même majoritaire. Revenons plus en détail sur ce que nous espérons corriger avec la Symbolibre :

Des paramétrages et une navigation générale malaisée, des modes à l’utilité peu claire, il semble que des progrès restent à faire en matière d’organisation générale de la calculatrice. Nous espérons par notre projet pouvoir vous présenter un produit de prise en main plus facile, au fonctionnement compréhensible.
Toute une moitié des élèves semble avoir des problèmes avec l’utilisation du mode graphique, pourtant un incontournable des usages au lycée. La programmation, elle aussi indispensable, ne s’en tire pas mieux. Il ne paraît pas normal que des fonctionnalités si essentielles soient problématiques dans leur utilisation, y compris lorsqu’il ne s’agit que de recopier des exemples trouvés dans les manuels de lycée.
Notons enfin que trouver des réponses à ses problèmes semble souvent être problématique : une écrasante majorité des sondés ne se reporte pas au manuel d’utilisation pour y trouver les réponses qu’il recherche. La raison principalement mentionnée dans les différentes remarques à ce sujet est sans conteste l’épaisseur pour le moins intimidante du dit manuel, dans lequel il est souvent malaisé de savoir où trouver l’information voulue. Il apparaît donc nécessaire de changer de méthode, en se contentant de proposer de simples guides généraux d’utilisation dans un manuel plus allégé, accompagné de liens directs vers un manuel en ligne, dans lequel la navigation sera plus aisée.
Parmi les remarques générales que les élèves ont eu la possibilité d’apporter en plus des réponses directes à nos questions, il est fait particulièrement mention de la difficulté à tout simplement trouver l’emplacement de l’opérateur que l’on souhaite afficher dans une formule, qu’il soit présent sur le clavier ou caché au cœur de menus de navigation. Nous proposons donc un clavier aéré, sans surcharge de fonctionnalités, accompagné de la possibilité d’enregistrer des raccourcis personnalisés pour accéder rapidement aux opérateurs de son choix.
Enfin, point noir partagé par bon nombre de calculatrices, la majorité des lycéens trouvent le prix de leur matériel déraisonnable. Avec Symbolibre, nous vous proposons pour un prix similaire de tenter de régler le plus de problèmes possibles parmi ceux rencontrés couramment avec les calculatrices actuelles.

Comme vous pouvez le constater, les défis sont nombreux. Mais toute l’équipe travaille de son mieux afin de vous offrir avec Symbolibre une calculatrice la plus satisfaisante possible !

Nouvelles des applications mathématiques

2019-03-25T00:00:00+01:00

Le groupe de développement des applications mathématiques est fier de vous présenter ses progrès. L’éditeur interactif de formules mathématiques fonctionne bien et interagit avec le moteur de calcul formel, comme on peut le voir sur cette capture à l’ordinateur.

L’application de tracé de courbes, fondée sur la bibliothèque polyvalente QCustomPlot, est elle aussi opérationnelle.

Comme tous les logiciels développés dans le cadre du projet Symbolibre, les applications mathématiques de la calculatrices sont des logiciels libres. Nous espérons pouvoir bientôt vous présenter ces applications directement sur la calculatrice !

Les logiciels de calcul formel

2019-03-22T00:00:00+01:00

Quand nous avons lancé le projet Symbolibre, il était clair d’entrée de jeu que la calculatrice devait être formelle. Mais cela laisse un (grand) nombre de possibilités en termes de choix de moteur : PARI/GP, Xcas, SageMath, SymPy, Scilab se font concurrence, et je suis loin de les citer tous.

Plusieurs critères contraignent bien sûr ce choix. Même si le Raspberry Pi Zero que nous avons choisi comme base est largement plus puissant que les calculatrices de lycée, faire le calcul formel en Python reste inenvisageable en termes de performance. Nous pouvons donc d’emblée éliminer SymPy. Nous n’utiliserons pas non plus les diverses interfaces graphiques car nos applications auront les leurs, il nous faut donc un programme accessible en ligne de commande, et dans l’idéal une bibliothèque. Première approche sur SageMath

Notre première approche, et clairement la plus ambitieuse, a été de tester SageMath. La raison était double. D’une part nous voulions tester les limites du Pi Zero, et comme SageMath est essentiellement un ensemble d’interfaces vers d’autres moteurs natifs, les performances du calcul pur ne sont pas tant un problème. D’autre part nous voulions que le projet Symbolibre participe au monde libre, en contribuant à compléter le module de simulation d’automates de SageMath par des machines de Turing (dans le même esprit que l’équipe du Librem 5 contribue à Wayland, si je peux me permettre la comparaison grandiose). Un de nos groupes a travaillé sur cette contribution pendant l’année.

SageMath est écrit en Python, mais il délègue souvent le calcul à d’autres programmes de calcul formel typiquement implémentés dans des langages natifs ; notamment PARI/GP (C) et Giac, le moteur de calcul derrière Xcas (C++). Notre intuition était de réduire le nombre d’interfaces externes que SageMath expose pour l’alléger en taille et en performance.

Mais bien sûr la théorie et la pratique se rejoignent bien mieux en théorie qu’en pratique. En principe, les modules de SageMath sont désactivés avant la configuration par un mécanisme simple : il suffit d’écrire disabled dans le fichier SAGE_ROOT/build/pkgs/<module>/type pour chaque module à désactiver. Cela indique une préférence qui sera ignorée lors de la construction des dépendances si le module désigné est une dépendance d’un autre module actif.

Et il y en a, des modules ! La compilation de SageMath sur mon ordinateur portable (4 coeurs, 8 Gio de RAM, disque SSD) prend autour de 2 heures. À titre indicatif, voici les modules qui ont occupé le plus de temps de compilation (pour une cible native – la cross-compilation ajoute quelques technicités mais pas de délais fondamentaux) :

Module	Temps de compilation
Singular 4.1	27 minutes
Sagelib 8.3	20 minutes
gfortran 7.2.0	19 minutes
Pynac 0.7.22	15 minutes
Giac 1.4.9	13 minutes
scipy 0.19.1	10 minutes

C’est ensuite que le problème principal se pose : SageMath est un rassemblement modulaire d’outils variés, mais le code de SageLib n’est pas vraiment modulaire ; il y a par exemple plusieurs milliers d’appels à Singular répartis sur plus de 200 fichiers. Ce genre de dépendance ne peut pas être contourné, et en parcourant l’arbre on se retrouve très vite avec seulement deux modules désactivables : le langage r et son interface Python rpy2. Améliorer la modularité du code est l’un des objectifs futurs de SageMath, de pair avec la transition vers Python 3, mais ça va certainement prendre encore un moment.

Pour l’instant, impossible de désactiver les modules cruciaux, et les performances s’en ressentent largement : 1 minute 55 secondes et 175 Mio de RAM pour lancer le shell SageMath. La RAM n’est pas le problème critique car le Pi Zero dispose de 512 Mio. Cela impose d’avoir une seule instance de SageMath et de communiquer par IPC, ce qui n’est pas idéal mais toujours faisable. En revanche, le temps de démarrage est rédhibitoire. Même en lançant SageMath au boot, il faut compter au moins deux minutes avant de pouvoir faire des calculs.

Seconde approche avec Giac

Notre attention s’est ensuite tournée vers Giac, le moteur de calcul formel de Bernard Parisse, qui équipe la HP Prime. Il y a là plusieurs raisons. Giac fait d’abord partie de SageMath, ce qui nous a permis de le tester immédiatement puisqu’il était déjà compilé. C’est aussi depuis longtemps le moteur de calcul formel de la HP Prime, ce qui nous donne une garantie par l’expérience de ses fonctionnalités et performances.

Et de fait, Giac s’utilise comme une bibliothèque C++ avec une charge bien plus raisonnables pour notre Pi Zero : les programmes triviaux s’exécutent en moins d’une seconde et sur 15 Mio de RAM. Ce genre de coût au démarrage est déjà bien plus raisonnable, y compris si chaque application a sa propre instance de la bibliothèque.

Nous développons maintenant la calculatrice Symbolibre avec Giac. L’interface C++ simplifie la vie des applications natives, et le module giacpy permettra de faire du calcul formel en Python dans l’application de programmation. Dans cette histoire, il est intéressant de voir que les ordinateurs modernes nous cachent bien la complexité des logiciels. Le temps de chargement d’un shell SageMath par rapport à un shell Giac se joue à une poignée de secondes ; mais dès qu’on change de plateforme, la différence se creuse soudainement. D’où notre attention particulière sur le choix des logiciels, pour garder le système efficace.

Choix des technologies logicielles

2019-03-12T00:00:00+01:00

Le seul outil logiciel fixé par le matériel est le choix de Linux pour le Raspberry Pi. Le reste de la pile système est entièrement libre, et les applications mathématiques sont à écrire pour la plupart. Voici un tour d’horizon des choix que nous avons faits pour développer notre calculatrice.

Système d’exploitation

Plusieurs possibilités se présentent pour le choix de la distribution Linux, parmi lesquelles Arch Linux et Gentoo, que l’on considère légères et personnalisables. Après discussions, c’est Gentoo qui l’emporte, ce qu’il doit à un niveau de personnalisation supérieur et au fait que Arch soit difficile à dissocier de systemd. Notre co-chef de projet Nicolas est également un utilisateur adepte de la distribution, ce qui a joué en sa faveur.

Le système Gentoo affichant les détails du pilote graphique.

Environnement graphique

On trouve ici le fameux dilemme X contre Wayland que nous avons rapidement tranché en faveur de Wayland, qui offre les compositeurs les plus légers. Cela inclut notamment sway voire rootston, le compositeur d’exemple de la bibliothèque wlroots.

Nos besoins en termes de composition graphique sont bas voire très bas pusique dans l’immédiat, nous n’envisageons qu’une barre d’état et une fenêtre en plein écran. Il existe des situations où avoir deux applications affichées en parallèle peut être intéressant (par exemple avoir des données statistiques sur la gauche et un graphe sur la droite), mais elles nous semblent toutes réductibles à l’utilisation de deux widgets partagés dans la même application.

Notre premier compositeur graphique sera certainement sway, que nous savons déjà utiliser et configurer ; mais il sera possible de l’alléger en jouant avec, quitte à monter un compositeur trivial si des besoins particuliers de performance ou mémoire se présentent.

Le plus dur restera de faire coopérer la carte graphique. Nous y reviendrons !

Interfaces graphiques

Les GUIs que nous allons construire ne sont pas très complexes comparées à ce que nos ordinateurs habituels supportent, mais elles sont quand même structurées. Il n’est pas question de dessiner directement sur une surface comme on pourrait le faire avec la SDL, par exemple.

Il faut donc choisir une bibliothèque permettant de mettre en page des widgets et capables de gérer les événements à un bon niveau d’abstraction. Les choix parmis les bibliothèques communes sont assez réduits : parmi ce que nous maîtrisons, on trouve essentiellement GTK Qt Qt. Pour esquiver la lourdeur de la programmation avec GLib et profiter des abstractions du C++, nous avons conclu sur Qt. Son IDE, Qt Creator, est également un bon point d’entrée pour toutes les personnes du groupe qui n’ont jamais programmé avec le framework.

Applications mathématiques

Notre idée initiale était de compiler pour la calculatrice SymboLibre une version réduite de SageMath pour lui laisser toute la partie calcul et résolution mathématique, qu’il n’est bien sûr pas question d’implémenter à partir de zéro. SageMath consitute un bon symbole de technologie libre et collaborative, et nous proposions de contribuer à son utilisation.

Seulement, la conception logicielle de SageMath se prête mal aux plans que nous avions pour lui. Le plus gros problème, et de loin, est que sa structure très monolithique nous empêche de le réduire à un noyau raisonnable. La bibliothèque n’étant pas pensée pour ce type de découpages, impossible de compiler sans les modules de théorie de groupes et d’algèbre linéaire avancée… de plus, il tourne encore en Python 2, ce qui nous obligerait à maintenir à la fois Python 2 et Python 3 sur le système.

Nous avons tout de même poussé le test à bout. Comme attendu, la quantité de modules complémentaires réduisent les performances à 1 minute 50 de démarrage et 170 Mo de mémoire consommés à blanc. C’est difficilement négociable, surtout qu’une seule instance peut tourner sur la calculatrice à chaque instant.

Nous étudions donc une alternative moins immédiate mais plus viable : Giac. La bibliothèque de calcul formel de Bernard Parisse fait partie des nombreux composants de SageMath, mais peut tenir seule les fonctions de la calculatrice puisque c’est le moteur utilisé par la HP Prime.

Voilà qui fait le tour de notre pile logicielle. Les GUIs ne sont pas encore assez peaufinées pour vous les présenter dès maintenant, mais nous y reviendrons !

Sélection du matériel des prototypes

2019-03-08T00:00:00+01:00

Pour construire les premiers prototypes, l’objectif était de sélectionner du matériel facile à trouver et techniquement accessible. N’étant pas des experts électroniciens, il nous fallait obtenir une machine fonctionnelle rapidement pour développer les aspects logiciels.

Le coeur de la machine a rapidement été décidé en faveur du Raspberry Pi Zero. À 5 € la pièce, cet ordinateur facile à trouver offre un excellent rapport prix/performance puisque ses spécifications rivalisent avec celles de la toute-puissante HP Prime G2 :

Processeur ARM à 1 GHz
512 Mio de RAM (!)
Stockage sur carte SD, au bas mot 8 Go pour l’OS et les données personnelles
Interface DPI pour la rapide gestion de l’écran
L’indispensable port USB pour les communications à l’ordinateur.

Notre Raspberry Pi Zero, connecté à son écran SPI.

Notez que c’est également le seul Raspberry Pi éligible pour ce projet puisque le mode examen en France (ici le bulletin officiel introductif de 2015) interdit aux calculatrices de posséder des capacités de communication sans-fil. Cela étant dit, même un port Ethernet en façade ne ferait pas très sérieux !

Bien sûr, contrairement aux modèles qui utilisent des OS spécialisés (Casio Graph, TI-8*, Numworks), le choix de Linux va ajouter une surcharge sur les performances de notre calculatrice. L’objectif de l’équipe d’Administration Système est donc en même temps de garder le système léger pour limiter cet impact. Il faut veiller au temps de démarrage, au bon fonctionnement de la pile graphique, à la réactivité des applications…

Paradoxalement nous n’allons pas utiliser l’interface DPI dans le premier prototype, ce qui serait un choix naturel pour garantir une bonne fluidité sur le rendu. Le DPI consiste à envoyer plus de données en parallèle à l’écran pour accélérer le transfert des données graphiques. À la place, nous allons commencer avec une interface SPI (série), qui envoie tout dans un ordre séquentiel.

La raison derrière ce choix est la répartition des GPIOs du Raspberry Pi Zero. Ces GPIOs (General-Purpose Input/Output) sont les broches logiques sur lesquelles on peut voir branchés des fils sur la photo plus haut. Elles permettent de connecter du matériel, et nous en avons besoin pour l’écran et le clavier. Cela représente un certain nombre de connexions selon le type d’écran et de clavier choisi :

6 GPIOs pour brancher l’écran en SPI 4-fils (voire 5 en tirant un peu) ;
Au moins 18 GPIOs pour brancher l’écran en DPI ;
Un GPIO par ligne et par colonne du clavier, soit probablement entre 14 et 16, pour un clavier simple ;
4 ou 5 GPIOs pour brancher le clavier sur une connexion série, si un contrôleur est présent pour gérer la communication.

Le Raspberry Pi Zero, comme la plupart des ordinateurs de la gamme, n’a que 28 GPIOs en tout. La combinaison réalisable la plus accessible pour nous est de garder un clavier simple et de brancher l’écran en SPI. Cela aura un impact léger sur la performance de l’affichage graphique ; à terme nous pourrons passer au DPI en ajoutant un contrôleur au clavier.

Côté écran, notre attention s’est tournée vers un écran 320×240 d’EastRising muni d’un ILI9341. Il supporte un très grand nombre d’interfaces, notamment SPI et DPI. L’interface choisie est sélectionnée lors de la commande, puis quelques soudures sont réalisées sur des jumpers. Lorsque l’écran est livré, une seule interface est disponible : pour nous, l’interface SPI 4-fils.

Connexion temporaire de l’écran SPI sur une breadboard.

Pour l’alimentation, nous envisagions initialement d’utiliser un battery pack naïf branché sur le port mini-USB du Raspberry Pi, mais c’était pousser la simplicité trop loin. Ces battery packs sont trop volumineux à utiliser et ont parfois des interfaces d’acquisition du niveau de batterie assez compliquées.

Nous avons donc rapidement revu nos plans en faveur d’une batterie Li-ion de 2200 mAh similaire à celle utilisée par Numworks, avec une interface PowerBoost d’Adafruit pour remonter la tension et assurer le rechargement. Cette interface est chère et, on l’espère, non définitive. Mais elle nous mettra sur les rails en termes d’alimentation rapidement.

Batterie et interface Power Boost en action.

Il reste à ajouter à cette liste la coque, que l’on pourra imprimer en 3D à partir d’un modèle sur mesure. Ce n’est pas la partie la plus technique de l’assemblage, uniquement la dernière. Une fois tous les éléments à portée de main, on s’intéressera plus précisément au volume nécessaire pour les agencer proprement.

Le seul point encore mystérieux est le clavier, pour lequel il nous faudra concevoir un PCB à la main. Ce sera traité dans un autre article !