Limites et dépannage¶
Limites de la version actuelle¶
Environnement
- Windows 64 bits uniquement, avec OpenModelica (Installation).
Microcontrôleur
MCU: 8 broches (GP0-GP7) et la LED embarquée, au lieu des 29 broches du Pico ; toutes peuvent servir d'entrée analogique. La carte complète estRPi_Pico.RPi_Pico: pas de redémarrage — après une perte d'alimentation (rail sous 1,6 V,RUNà la masse), le programme reste arrêté même quand l'alimentation revient ; régulateur en modèle moyen (ni ondulation, ni limitation de courant) ; un seulUARTet un seul maîtreI2Cà la fois (UART(0)ouUART(1)) ; pas de « slices » PWM (deux broches voisines ne partagent pas leur fréquence). Périphériques alimentés par leur brocheVCC: seuls leurs niveaux électriques suivent l'alimentation, leur comportement continue même à 0 V.- Pas de mode drain ouvert (
Pin.OPEN_DRAIN) : seul le bus I2C pilote ses lignes ainsi. Les tirages internes (Pin.PULL_UP,Pin.PULL_DOWN) sont, eux, réellement modélisés. - Pas de
SPI. UART: une seule liaison, 50 à 115 200 bauds, pas d'interruption en réception ; un octet reçu en erreur (parité, stop) est signalé au journal, pas au programme.I2C: un seul bus maître, 1 kHz à 1 MHz ;I2CTarget: une seule cible, adresse sur 7 bits, plus de gestionnaire une fois le programme terminé.Timer: 4 minuteurs au plus, période minimale 1 ms.- Les callbacks d'interruption (
Pin.irq(),Timer) s'exécutent au prochain point de synchronisation, jamais en préemption instantanée du programme. - Plusieurs
MCUdans un modèle : chacun a son programme, ses modules et sa flash. Deux cartes qui se répondraient sans jamais laisser passer de temps (gpioOpTime = 0et deux recopies croisées) bloquent la simulation au même instant. - Débogage (avec VS Code) : un seul
MCUdébogué par modèle ; seul le programme du microcontrôleur se débogue, pas les scripts des appareils série ou I2C.
Détail fonction par fonction : API, limitations.
Périphériques : voir la fin de chaque page (appareils série, I2C, pesée, radio).
Dépannage¶
La compilation échoue : 'PyRuntimeImpl.c' file not found
Le chemin du dossier de la bibliothèque contient un caractère accentué (par exemple un dossier Téléchargements). Déplacer le dossier dans un chemin sans accent, puis le recharger dans OMEdit (voir Installation).
Avec OpenModelica 1.26 ou antérieur, les broches restent à 0 V
La simulation se termine sans erreur, mais les sorties ne bougent pas, et le bus I2C s'arrête sur OSError: [Errno 110] ETIMEDOUT. C'est un défaut des versions de la bibliothèque antérieures à sa correction : prendre la version la plus récente (voir Installation).
La simulation s'arrête avec une erreur Python
Une exception non rattrapée dans le programme arrête la simulation. Le journal de simulation affiche la trace Python : chemin du fichier, numéro de ligne, ligne de code fautive, type d'erreur et message. Les résultats restent consultables jusqu'à l'instant de l'erreur.
La simulation semble figée, avec l'avertissement « the script has been running for more than 10 s of real time »
Le programme tourne dans une boucle qui ne rend jamais la main au circuit : ni sleep(), ni accès à une broche (attente sur time.ticks_ms(), calcul sans fin). Le temps simulé ne peut plus avancer. Ajouter un time.sleep_ms() dans la boucle, puis arrêter la simulation depuis OMEdit. La variante « acting for more than ... at the same simulated instant » désigne une boucle d'accès aux broches avec gpioOpTime = 0. Le délai se règle par hangWarningTime (Le bloc MCU) ; un calcul long mais légitime se termine normalement malgré l'avertissement.
La simulation reste à t = 0, le journal affiche « waiting for VS Code »
Le débogage est activé (debugEnabled, onglet Debugging du MCU) : le microcontrôleur attend que VS Code s'attache. S'attacher depuis VS Code (Déboguer avec VS Code), ou décocher debugEnabled pour simuler sans débogueur.
VS Code n'arrive pas à s'attacher au MCU
Vérifier que la simulation est lancée et que le journal affiche waiting for VS Code on port ..., puis que le port de launch.json est celui de debugPort. Si la simulation s'arrête au départ sur failed to start the debugger, le port est déjà pris (une autre simulation en cours, par exemple) : en choisir un autre dans debugPort et dans launch.json.
Mes points d'arrêt ne sont jamais atteints
Le fichier annoté dans VS Code doit être celui que le MCU exécute : scriptPath, ou pour la flash les fichiers de l'image fsSource. Les points d'arrêt posés dans machine et time (le shim de la bibliothèque) sont ignorés.
Mes print() n'apparaissent pas
Ils s'affichent dans la fenêtre de sortie de la simulation d'OMEdit (et dans son journal), pas dans une console Python, précédés du temps simulé ([t=0.250000 s] ...). Un print() d'appareil série ou I2C porte en plus le nom du composant.
OSError: [Errno 110] ETIMEDOUT sur le bus I2C
Aucune résistance de tirage externe sur le bus (les tirages internes de 50 kΩ ne suffisent pas) : cocher usePullUp sur au moins un périphérique (Périphériques I2C). Autre cause possible : une ligne tenue basse par un court-circuit dans le schéma.
OSError: [Errno 5] EIO sur le bus I2C
Aucun périphérique ne répond à l'adresse demandée. Vérifier le paramètre addresses du périphérique et lancer i2c.scan().
Les octets reçus sur la liaison série sont faux, ou le journal signale parity error / framing error
Le débit ou le format de trame de l'appareil (baudrate, dataBits, parity, stopBits) diffère de ce qui est passé à UART(...) dans le programme. Les deux doivent être identiques, comme sur un vrai montage (Format de trame).
Le programme ne voit pas les données reçues par la liaison série
La réception ne réveille pas le programme : il doit interroger la liaison (uart.any(), uart.read(), uart.readline()) et laisser le temps à la réponse d'arriver, par exemple avec un time.sleep_ms().
Relier deux broches du même MCU par un fil fait disparaître le signal
Un connect() direct entre deux broches du même microcontrôleur fusionne les deux nœuds, et la tension pilotée disparaît des résultats. Passer par une résistance de 1 kΩ, avec un condensateur de 1 nF vers la masse (Appareils série).
Message « Chattering detected » dans le journal
Information bénigne d'OpenModelica : beaucoup d'événements dans un seul pas de sortie, typiquement sur un bus I2C. Réduire l'intervalle de sortie (Interval) le fait disparaître ; les résultats sont justes dans les deux cas.
La simulation est lente
Chaque front sur une broche est un événement pour le solveur. Une liaison série rapide, un bus I2C, une attente active (while not bouton(): pass, un événement par accès à la broche) ou un sleep_ms(1) en boucle en produisent beaucoup. Préférer time.sleep() ou Pin.irq() à l'attente active, et ne simuler que la durée utile.
open() lève OSError: [Errno 19] ENODEV
Le système de fichiers n'est pas activé : cocher fsEnabled dans l'onglet File system du MCU (Le bloc MCU).
Où sont les fichiers écrits par mon programme ?
Dans la copie de la flash créée à chaque simulation, dans le dossier fsWorkspace (par défaut le dossier de simulation). Son chemin s'affiche dans le journal au début et à la fin de la simulation, et l'Explorateur Windows s'ouvre dessus en fin de simulation (fsOpenExplorer). Un fichier que le programme n'a pas fermé l'est en fin de simulation, son contenu complet écrit sur disque.
Deux lectures successives d'une broche donnent une valeur périmée
Seulement avec gpioOpTime = 0 : relire une broche juste après avoir écrit sur une autre peut renvoyer l'état d'avant l'écriture. Laisser gpioOpTime à sa valeur par défaut, ou intercaler un time.sleep_us(1).