Je partage ici un petit projet réalisé sur Arduino UNO Q avec Arduino App Lab, dont l’objectif est l’affichage de l’heure (HH:MM) sur la matrice LED 13×8 intégrée.
Le point principal du projet est le rendu direct sur la matrice LED, sans buffer ASCII ni représentation intermédiaire :
les chiffres sont décrits sous forme de glyphes binaires 3×5, puis traduits directement en bits dans un buffer de 4 mots de 32 bits, transmis via matrixWrite().
Le dépôt contient :
le code complet et minimal,
un README volontairement très détaillé, qui sert à la fois d’aide-mémoire personnel et de support pédagogique,
un exemple pas à pas (chiffre 0 en dizaine d’heures) permettant de dérouler tout le cheminement :
glyphe -> coordonnées (x,y) -> index linéaire -> bit du buffer.
Le projet n’a pas vocation à être “optimisé à l’extrême”, mais à être compréhensible, notamment pour ceux qui découvrent la UNO Q, App Lab, ou le mapping bas niveau de la matrice LED.
Lien vers le dépôt GitHub :
La UNO-Q est une petite révolution en soit, l’Arduino App Lab également.
le prix n’est pas excessif
Le concept est génial
L’application App Lab est conviviale
Bien sûr ce n’est que le début de l’aventure et les mises au point sont empiriques mais l’avenir du concept Arduino recommence ici avec en prime l’intelligence artificielle
Il faut attendre la version avec plus de mémoire, elle ne devrait pas tarder à sortir tant qu’à investir autant prendre ce qui se fait de mieux d’autant plus que le surplus financier n’est pas énorme
Je ne comprends pas trop en quoi c'est une révolution ?
Tu parles d'avoir deux CPU sur une carte qui peuvent communiquer entre elles?
j'avoue que je ne vois pas trop ce que cela apporte par rapport au divers raspberry ou Corps ARM avec des mini linux ?
Bonsoir,
avoir un micro qui fonctionne avec un OS pour faire de l' IHM et un micro qui fonctionne en temps réel pour les sondes (et plus) est au moins une sacré évolution et un plus par rapport à Raspberry.
si le prix reste voisin pour la carte avec plus de mémoire et que le système devient ouvert cela deviendra fort intéressant notamment pour la domotique.
Cordialement
Olivier
Oui pour ceux qui souhaitent centraliser les 2 fonctions sur la même carte physique. Dans mon approche d’un système domotisé, je suis plutôt pour un nano-ordinateur (SBC) sous Linux et un micro-controleur par capteur ou groupe de capteur qui communique avec le SBC par l’un des protocoles qu’ils on en commun.
J’ai lu ici que pour le moment sur la UNO-Q le micro-controleur communiquait avec la partie CPU en UART. Pour une installation domotique, avec des ESP32 par exemple, on a bien plus de protocoles de disponibles pour relier ces 2 mondes.
Au vu du peu d’information que j’ai sur cette carte UNO-Q (uniquement les sujets traités sur ce forum), je ne vois pas personnellement son intérêt.
Une évolution par rapport à qui Raspberry, mais STM pas vraiment.
Je ne suis pas un expert des cartes PRO, mais je suppose que des cartes avec deux microcontrôleur doit exister?
Pour l'Arduiniste amateur lambda, je ne suis pas persuadé qu'il y a un besoin de temps réel, pour gérer quelques capteurs de température et actionneur.
Peut être si l'Arduiniste veux gérer des moteurs avec une forte précision, mais comme l'indique @jelopo cela reste une communication UART entre deux µC.
@le_viking tu as un exemple de projet domotique ou par rapport à un bête Raspberry model 5 ou zéro qui a besoin d'une gestion temps reel, que Raspberry ne peux pas couvrir.
A la limite cela est une option plus compacte que deux µC connecté en serial et encore deux ESP32 sont plus compact qu'une UNO, mais je suppose que si ca marche on devrait voir des Namo.
Non, pas obligatoirement, c'est une question de confort entre autre. Il faut aussi considérer ce que veut dire temps réel pour en comprendre les avantages le terme étant un peu trompeur.
Ce ne peut pas être un problème en domotique qui ne demande pas une rapidité sortant du commun. Arduino a annoncé que ce point évoluerait.
Ce qui pose des problèmes liés à l'utilisation d'un OS, c'est à dire tout ce qui demande une gestion temps réel
deux ESP32
Oui RTOS mais pas d'OS
Qualcomm n'a pas sorti cette carte sans y avoir réfléchi préalablement et le tandem paraît judicieux pour un premier essai. Pas facile de trouver une place dans cette niche.
Je ne comprends pas bien on parle de révolution, voir évolution technique, maintenant tu change de terrain en parlant de prix, on pourrait aussi ajouté la performance d'ailleurs.
Donc pour toi c'est une évolution sur quoi, le prix ?
Pour ce que tu dis un STM32 dual core, reste dans une gamme de prix proche et permet de gérer l'IHM sur un core et le temps reelle sur un autre.
Je ne sais pas tu y mets quoi toi dans temps réel.
Moi par exemple de pouvoir cadencé de l'acquisition ou génération analogique (DAC-ADC) dans le temps impartit du bit rate voulu.
Encore oui et non, pour moi le temps réel est rarement nécessaire pour les Arduinistes.
Comme @jelopo je trouve même que pour de la domotique un debian Raspberry est nettement supérieur avec la quantité de package compatible et une mémoire très importante.
Je suis bien d'accord avec toi, mon point était surtout ce que @philippe86220 trouvais de révolutionnaire ou toi même comme une évolution("margeur"?).
Cela ne veut pas dire que cette carte soit pas au final un gros succès.
Oui tu as raison, je ne voulais pas dire que c'était réducteur, mais que c'est relativement assez facile à reproduire avec deux petites cartes de dev.
Le fait d'utiliser deux micros est une évolution dans le sens où il devient possible de l'acheter pour un amateur sinon c'est sur que Qualcomm n'est pas le seul à le faire.
Un double core partage sa mémoire donc temps réel sur les deux ou pas de temps réel. De plus le temps réel est un avantage sur un double core.
Je n'y met rien je l'utilise, c'est bien utile pour la gestion du WIFI entre autre.
Quand tu as formulé ton appli domotique (tout ce qu'elle va faire), que tu as fait un IHM test sous windows de la page d'accueil à des pages de menu, de configuration, d'affichage etc... Ton choix ne se portera pas vers une petite carte de dev.
Le choix d'une carte comme Raspberry avec OS devient évidente, mais dès que tu commences la programmation des sondes tu vois les problèmes liés à un OS. Alors oui on peut associer une petite carte externe avec un RTOS.
Il faut admettre que la carte Uno Q est au moins une évolution en regroupant en une seule carte ces deux cartes et toutes leurs connectiques à un prix équivalent sinon moindre.
Oui, c'est bien pour ça que sachant que il n'est ni le seul, ni le premier, ce n'est plus vraiment un évolution.
l'évolution de la pars de Qualcomm ou Arduino est donc plus sur le prix.
Un double core partage sa mémoire donc temps réel sur les deux ou pas de temps réel. De plus le temps réel est un avantage sur un double core.
J'ai du mal a comprendre ce que tu veux dire, tu peux très bien utiliser un core avec du RTOS sur l'un et du code temps reel sur l'autre, non ?
Encore une fois je ne comprends pas trop ce que tu veux dire, moi aussi je l'utilise et visiblement le besoin ne me semble pas le même, donc tu n'y mets pas forcément la même chose?
En gros en quoi tu as besoin de temps reel pour faire du WIFI?
Je suppose qu'il y a quelque chose de spéciale, car Raspberry gére aussi le WIFI.
Pourquoi, je ne sais plus qui est l'auteur de la carte de surveillance des jours Tempo, il n'a pas besoin d'un raspberry?
Il y a plusieurs autre exemple de membre qui utilise un ESP32 pour leur IHM.
Si ton propos est pour un IHM équivalent a home-assistant oui c'est clair.
Encore une fois oui et non, ton raspberry pourra très gérer une multitude de sonde "simple" température, humidté, ... en directe a partir de l'OS et facilement intégrer des sondes MQTT pour les distantes.
Et il me semble que c'est plus facile d'accès avec un raspberry, qu'avec une Uno Q?
du moins pour l'instant le nombre de projet Raspberry est plus conséquent, puisque plus vieux.
Encore une fois, mon propos n'est pas de dire que cette carte ne sert à rien, mais que pour un Arduiniste lambda, je ne sais pas si elle apporte vraiment grand chose.
Surtout si on plug sur un raspberry un STM32 ou un ESP32 en communiquant comme pour la uno-Q par le port série.
On en revient surtout sur le prix et effectivement avec la flambé des prix des nouvelles Raspberry, c'est indéniable.
Comme son nom l'indique RTOS c'est pour la gestion temps réel. Quand je parle de temps réel c'est toujours dans le cadre de RTOS
C'est quand même bien un peu la base que de gérer les événements pour la connexion externe que ce soit WIFI ou Bluetooth. Enfin moi c'est comme cela que j'opère dès les premières lignes de code
Quand on parle IHM c'est clairement pas afficher une température sur un écran.
Avec en exemple la simple gestion de la température d'une maison
Il va te falloir des consignes par pièce, par jour et heure avec un minimum de surveillance. Cela veut dire:
-Afficher l'heure et la température de chaque pièce
-Afficher les consignes en fonction des heures pour chaque pièces
-Puis faire un menu pour choisir l'affichage actuel ou l'affichage des paramètres pour pouvoir les modifier
Heure, Wifi, Affichage et stockage de masse pour faire des pages d'affichage sympa. Alors la Raspberry paraît largement justifiée.
Oui, pour l'instant, mais dès que le système sera ouvert pour mettre un programme C++ dans le Qualcomm la uno Q présentera un avantage indéniable avec son second micro et pour cela nul besoin de projet existant.
Oui tu as raison, c'est un OS dont je voulais parler.
La gestion d'évènement ce font aussi sur des OS non temps reels comme linux.
Je suis désolé, je n'arrive pas a comprendre de quoi tu parles.
Tu parles de gérer toi même la stack IP et le décodage des trames de donnée WIFI?
Si c'est au travers d'une puce spécialisé, j'ai du mal a voir ou le temps réel est une obligation pour toi ?
Dans l'exemple que je t'ai donné, par exemple par exemple, tu ne peux pas te permettre de passer trop de temps à attendre que la puce spécialisé te répondent ou même de passer trop de temps à gérer la trame reçu, mais le problème n'est pas la gestion des trames IP en WIFI.
Je ne sais pas si je suis claire sur mon blocage ?
Oui mais comme je te l'ai dis, il y a aussi des projets qui n'ont besoin que d'un ESP32.
Donc oui il y a un point de bascule ou il faudra forcément passer sur un "PC", que se soit en terme de mémoire ou temps CPU(ex home assistant).
C'est la ou nos visions diverge, non cela n'est pas un avantage pour moi, ca sera plus un équivalent à ce que permet déjà un Raspberry.
A la limite peut être avec leur cloud de gestion des deux architecture en un seul point, cela leur donne un avantage.
Tout ce que tu décris est déjà faisable avec un raspberry.
Pour avoir une évolution, il faudrait ne plus passer par une liaison protocolaire comme l'UART, mais partager la mémoire.
Je ne suis pas du tout un expert, donc surement que pour l'IA avec ses capacités la puce Qualcomm à par contre un gros avantage sur un raspberry?
Oui, mais le problème est là, ils ne sont pas temps réel.
Pour résumer très grossièrement il y a 3 façons de faire
J'utilise l'impératif en C: je fais un connect_wifi quand la connexion est faite je continue mon programme.
J'utilise un RTOS: j'associe une tâche à mon connect_wifi, tâche qui va être effectuée en temps réel c'est à dire quand je veux avec la priorité que je veux et avec la possibilité de refaire un appel à cette tâche en cas de déconnexion imprévue.
J'utilise un OS: la tâche est alors gérée par l'ordonnanceur de l'OS dont je ne peux que modifier la priorité et c'est quand même l'OS qui décide en finalité.
Oui, il faut juste acheter une carte ESP32 pas une Uno Q.
Acheter une Uno Q et ne pas pouvoir utiliser le micro qui à terme doit avoir 16 Go de RAM revient effectivement à acheter une carte ESP32.
Je ne parle ni de cloud, ni d'IA simplement de l'amateur qui veut se faire une appli d'automatisation, de domotique ou autres un peu costaud avec une certaine interactivité et convivialité, que celle ci existe déjà commercialement ou soit totalement personnelle.
Oui, mais ma question est quel est le besoin de temps réel pour gérer une connexion WIFI, l'OS le ferra aussi, même effectivement c'est quand même lui qui décide.
C'est pour ça que je te demande ce que tu mets dans le temps réel, si on prends mon exemple d'acquisition/restitution, il n'est pas possible de le garantir avec un OS, sans matériel pour gérer ce temps réel(carte son), car l'OS ne garantit pas la précision de l'intervalle de temps.
Que tu utilise un OS temps réel, c'est une chose, mais que tu en ais besoin pour le WIFI en est une autre.
Ok, mais du coup pour un tel projet, la uno-Q à par le coût, quel est son avantage sur une solution raspberry ?
comme ça je dirais un tout en un, simplicité de l'alimentation et communication entre les deux processeurs.
Je veux bien que cela lui donne un avantage, mais c'est quand même pas une évolution extraordinaire.
On peut poser la question dans l'autre sens mon ESP32 supporte FreeRTOS pourquoi je n'en ai pas besoin pour gérer le wifi? ou pourquoi je ne l'utilise pas?
La présence d'un second processeur qui supporte un RTOS et qu'il est nécessaire d'ajouter à une Pi pour obtenir le même service.
Parler d'évolution ou de révolution ne concerne que le cadre Arduino. Des cartes similaires existent (nxp par exemple) mais leur prix et leur accessibilité en terme de programmation en font des produits moins grand public.
