Threads en raspi pico et micropython

[JBaill]

Bonjour,

Quelqu'un a t il déjà fait du Threading en micropython ??
J'ai trouvé très peu de documentation et surtout pas ou peu d'exemples .
et rien sur les partages de data entre les Treads et le programme principal
Les quelques essais que j'ai pu faire les datas ne passent pas .
J ai juste besoin d'un thread qui communique avec un inclinomètre et formate les datas pour le programme principal
merci de vos lumières
J. Baillargeat

[piper]

Jamais essayé en micro python
Et le micro python, je ne le pratique que sur ESP32 : jamais essayé sur le pico
Mais sinon la doc micropython sur le threading est dispo :
https://mpython.readthedocs.io/en/maste ... hread.html

[JBaill]

bonjour,

merci de votre prompte réponse
Je n avais pas cette mise à jour du micro python
ça fonctionne très bien dans mon appli
cordialement
Jacques Baillargeat

[JBaill]

bonjour,

J ai réussi a faire du threading avec le raspi pico le but était de lire un capteur de niveau et de décoder les angles sans perturber le reste de la procédure
avec des verrous pour éviter les mélanges de data


def LectureWT61_thread(): # lecture WT61 et conversion
global lock
global XX
global YY
while 1:
lock.acquire()
time.sleep(0.1) # pour limiter le débit sinon plantage on peut mettre plus
toto=uart.read(50)
toto= binascii.hexlify(toto) # décodage de la trame serie du WT61 ( il y a accélération magnétomètre et angles )
toto = str(toto) # par les chaines de caractère
pos1 =toto.find("5553") # recherche de 5553 qui est l info angulaire
resu=toto[pos1+4:pos1+16] # je ne sais pas si c est élégant mais ça fonctionne

XL=resu[0:2]
XH=resu[2:4]
YL=resu[4:6]
YH=resu[6:8]
ZL=resu[8:10]
ZH=resu[10:12]

XX=((int(XH,16)*256)+int(XL,16)) # il y a deux octets par axe le poids faible en premier il faut permuter
if XX>32768: # 16 bits donc de 0 a 65536
XX=XX-32768 # positionnement a +- 32768 ( c est mieux pour l asservissement de position )
else: # je n utilise pas le Z
XX=XX+32768

YY=((int(YH,16)*256)+int(YL,16))
if YY>32768:
YY=YY-32768
else:
YY=YY+32768

lock.release()

et dans le main

lock = _thread.allocate_lock()
second_thread = _thread.start_new_thread(LectureWT61_thread, ())

Et donc cette procédure s'exécute en tache de fond et me donne les angles XX et YY pour le reste de la procédure
je me suis basé sur des exemples on peut surement faire plus pertinent .....

sincères salutations

Jacques Baillargeat

[piper]

Bonjour
Très bien
Attention à ceci :
pos1 =toto.find("5553")

si toto vaut 01 53 35 02 10 00 00 00" pos1 vaudra 2 et c'est le comportement attendu var on trouve 0x53 suivit de 0x35 par la suite resu vaudra 02 10 00 00 00

mais toto vaut 05 33 50 21 02 10 00 00 00, pos1 vaudra 1 et ce n'est pas le comportement attendu car les datas ne contiennent pas 0x53 suivit de 0x35 mais 0x05 suivi de 0x33 suivit de 0x50 et resu vaudra 02 10 21 00 00 00 00

Pour résoudra ce soucis, la solution la plus simple est de demander à hexlify de séparer les octets par des séparateurs
voir binascii.hexlify(data[, sep[, bytes_per_sep=1]])
https://docs.python.org/3/library/binascii.html

et si toto ne contient pas du tout 0x5335 ex si toto vaut 0x01 02 03 04 05 06 07 08, pos1 vaudra -1
et alors resu=toto[pos1+4:pos1+16] donnera toto[3:15] soit resu=0x20 30 40 50 60 70 8 : pas du tout le résultat désiré.
pour résoudre ce problème un if pos1>=0: pourrait être le bienvenu
https://www.programiz.com/python-progra ... tring/find

A partir de là, si on veut fignoler, on peut se débarrasser des variables globales en utilisant des objets plutôt qu'un code procédurale , mais là, on fignole, cela n'améliorerait que la lisibilité et diminue le risque d'erreur humaine dans la programmation sans changer ni le comportement, ni la performance.

[JBaill]

Bonjour,

Merci de ces précieux conseils
je ne vous ai pas répondu rapidement car je suis dans la conception du circuit imprimé qui va supporter tout cela (Kicad bien sur)

je ne rencontre pas d'erreur avec le décodage mais par prudence je vais suivre vos conseils.

Et puis travailler avec des objets ne fait pas partie de mes spécialités je viens du Fortran 77 du macro 11 de Digital du Basic et de l'assembleur PIC
Le python est vraiment différent mais j avance .....
Merci en tout cas je vous tiens au courant de l avancement du projet en tout cas ça occupe bien ma retraite
prochaine étape faire discuter deux RP2040 zéro en serie en plus du WT61
belle journée a vous et encore merci

J Baillargeat

[piper]

je viens du Fortran 77 du macro 11 de Digital du Basic et de l'assembleur PIC

Le monde est petit , je viens aussi du Fortran 77, du RPN inversé , du Basic, du Pascal et du C (à l'époque de Borland).... langages qu'on apprenaient à l'université.
Passage important par le COBOL / DL1, DB2 / JCL / IMS avant de revenir à mes 1ères amours : Pascal, devenu depuis Delphi que je pratique toujours (au travers de Lazarus et du Pascal objet : merci Linux !)
Le tout avec de plus en plus de PL/SQL finissant par tourner vraiment backend pendant longtemps (modélisation, shell / C / Python et beaucoup, beaucoup mais alors beaucoup de PL/SQL ... que j'adore) avant d'y ajouter php / html /css, du python, du micropython et ... retour au C de temps à autre pour de l'embarqué.

Oui, en 30 ans, ça fait vraiment "grand écart" mais ça m'a permis de toucher à tout et d'avoir une vision globale des applicatifs.
Ce qu'il y a de bien dans le développement c'est qu'il y a toujours à apprendre : il est impossible de tarir la curiosité.

[JBaill]

re bonjour,

En effet quel panel de compétences chapeau ...
Je travaillais dans un labo de recherche du cnrs ce qui explique ces anciens langages
Mais j'était plus hard que soft enfin la combinaisons des deux pour le contrôle commande acquisition qui était mon cœur de métier
sur de l’expérimental embarqué mais aussi sur des instruments un peu spéciaux (laser solide haute énergie)
Je suis à la retraite depuis bientôt 3 ans mais toujours pas déconnecté car je n'ai pas été remplacé et que ces installations
ne fonctionnent pas seulement avec des dollars mais aussi avec des personnes compétentes.
J interviens donc encore au labo (pour des amis chercheurs) dans un cadre associatif.
Le CNRS est devenue un cloaque financier ou on arrache des verrues avec des pelleteuses avec des critères qui sont à l'inverse de l'esprit même de la recherche:
Rentabilité à court terme, financement conditionnels à des résultats rapides.
Autrement dit plus de sous pour le fondamental, seulement pour de la recherche de bas étages et des projets qui sont des gouffres financiers sans issues.
c'est désespérant.
Mais j occupe bien ma retraite c'est l'essentiel....
en attendant merci de ces précieux conseils.
bien amicalement
Jacques Baillargeat

[piper]

J'échangerai bien nos carrières :
Je viens du monde scientifique (Maths, Physiques et applications fondamentales), j'ai toujours voulu exploiter mon métier dans un contexte scientifique, mais dans ce domaine, je n'ai fait que quelques projets de fin d'études sur l'analyse de l'imagerie et des recherche de solutions aux équations différentielles (Algos de Runge Kutta), de visualisation 3D 'en 93, c'était quelque chose !)
Donc ma carrière a été constitué du méga classique : Banque (beuark), Assurances, (Re-beuark), VPC et Presses (beurk beurk beurk) avant de devenir libéral pour pouvoir choisir les missions que ME plaisent et depuis, c'est aéronautique et dès que je trouve : de l'embarqué.... je choisis mais c'est dur de trouver des missions, c'est quelques fois la vache maigre.
Mais mon rêve aurait été de bosser pour le CNRS, l'ONERA ou un labo de recherche, même payé au lance pierre, voir même de manière associative.
Alors chapeau à toi.

[Artemus24]

Et puis travailler avec des objets ne fait pas partie de mes spécialités je viens du Fortran 77 du macro 11 de Digital du Basic et de l'assembleur PIC
Le python est vraiment différent mais j avance .....

Ce n'est pas ma formation à la base, car je suis informaticien. J'ai fait un IUT puis une école d'ingénieur (grande école ESI) où j'ai appris des tas de langages comme les assembleurs 6502, 6800, 68000, z80, IBM 360, des langages comme Basic Applesoft (le premier ordinateur que j'ai manipulé à l'IUT était un ITT 2020, un clone de l'Apple II+), Cobol (surtout dans les banques), PL/1, APL, Fortran, puis Pascal, C, C++, HTML, CSS, javascript, PHP; des SGBDs comme DL/1, DB2, IDS2, IDMS, IMS, myql, mariadb, firebird, microsoft sql server; des langages d'exploitations comme JCL (IBM), GCL (BULL), bash, csh, ksh; sur des ordinateurs comme IBM/TSO/ISPF, BULL/GCOS7, BULL/GCOS8, UNIX/DEVON, UNIS/HPUX; et d'autres que j'ai oubliés.

J'ai fait toute ma carrière professionnelle dans les SSII en tant que développeur puis chef de projet dans le bancaire et assurance. J'aurais aimé plutôt travailler dans le domaine système, ou dans le DB (base de données DB2) en tant qu'administrateur, mais il n'y avait aucune demande en SSII. Depuis que je suis à la retraite, je m'éclate sur Linux avec la programmation système, un peu d'électronique et de l'embarqué (Raspberry PI), ainsi que la domotique avec les microcontrôleurs (ESP32), et maintenant sur les réseaux (fibre optique, ONT/ONU, routeurs, switchs, access point wifi ...).

J'ai, comme on dit, pisser de la ligne Cobol car c'est le langage le plus utilisé dans le monde bancaire. Je n'aime pas python, car je n'aime pas les langages interprétés, sauf quand je n'ai pas le choix. Je déteste Javascript qui est un merdier pas croyable. Actuellement, mes deux langages préférés de développements sont C & C++, ainsi que le langage de commandes Bash, bien sûr.

Et dire qu'à la base, j'aimais les mathématiques et je voulais faire carrière dans la chimie.