Reprise du message précédent :
ha je savais pas, merci
ca veut dire qu'il y a 2 puces ? Cela fonctionne comment au niveau matériel ?

J'ai découvert il y a pas longtemps qu'un de mes PCs portable recents pouvait le faire et je pensais que cela demandait un matos spécial

Oh alors là je ne sais pas comment ils ont fait.
 
 
J'aurais une question encore.
J'ai la fonction de mise à jour de firmware de painlessmesh qui est capricieuse.
https://gitlab.com/painlessMesh/pai [...] Sender.ino
 
Alors l'example en lien fonctionne parfaitement.
 
Le problème c'est quand j'essaye de l'intégrer à mon projet.
 
En gros, si j'enlève la boucle infini du setup:

 
Et met son contenu dans la fonction loop prédéfinie d'Arduino, comme c'est le cas pour les autres examples, et bien le MCU crash.
 
Bref elle est où la différence entre la boucle while infinie, et le loop arduino???
 
En commentaire de programmeur a écrit qu'il n'a pas besoin de se soucier du file scope.
Est-il là le problème justement???
 
edit:
Tiens je vais poser la question en section c++ plutôt.

J'ai souvenir être tombé sur le pourquoi du loop() en arduino, mais je ne retrouve plus la raison.
Je crois qu'il y a un simple while(true) loop(); quelque part lors de la compilation.

Hum, on a parlé des nouvelles "failles" de l'esp32 ?
https://www.cachem.fr/esp32-failles [...] couvertes/
J'avoue que je vois plutôt ça comme des features.
Le changement de MAC n'est pas nouveau j'ai un orangePI qui prend une mac aléatoire à chaque boot alors bon...
Modifier la ram et la flash je ne vois pas le soucis non plus...
Enfin bref pour moi tout ça ne dépend finalement que du code qui est exécuté, ça ne permet pas le hack d'un objet existant ?

 
 
J'ai cet article https://korben.info/wokwi-le-simula [...] types.html qui a pop dans mon fil d'actu
Vous connaissez ? Ca a l'air bien sur le papier.

Oui intéressant, à voir le debugger ce que cela donne.
 
A titre perso, je trouve ce point :

dommage, ce que je trouve rigolo avec arduino & co, c'est l'application concrete devant mes yeux ebahis.
 
-----------
 
Petite question, j'ai pas trouvé sur le forum. J'utilise feu l'extension arduino sur VSCode qui n'est plus maintenu pour du STM32. En soit cela fonctionne, sauf qu'il recompile tout à chaque fois (toutes les libs qui n'ont évidemment pas bougé) ce qui sur mon PC prend pas mal de temps.
Est-ce que platformIO a le même soucis ou c'est plus optimisé niveau compilation ?

J'ai déja utilisé Wokwi, certainement ici même pour montrer des schémas.
Je ne l'ai pas mis dans mes favoris, il devait y avoir un truc qui m'a chagriné ?
 
Where's the catch ?

Je m'auto réponds (l'installation a été un peu ...), effectivement c'est plus optimisé
Bon, je ne suis pas très fan des environnements qui ne sont pas totalement offline. J'ai l'impression que pour la création de projet, il faut systématiquement une connection internet.

J'ai retrouvé la réponse, cela se voit dans le cas d'un debuggage :

La compilation arduino rajoute dans la boucle le CoreCallback(); et SerialEventRun(); qui doivent être géré en interne par le program

Merci
 
Je ne comprends pas pourquoi ca plante alors

Hola,

J'ai une question STM32(L03) concernant le SPI. J'essaye de le faire en drivers LL mais cela ... marche po

Je test SCK à l'oscilloscope qui me renvoit rien du tout, j'ai PA5 & PB3 qui font SCK.
Si je regarde le registre SPI, j'ai bien les données qui sont envoyées, je suppute que c'est un probleme de port.
Par ailleurs, le code avec la librairie arduino fonctionne sans problème, mais sur le port PB3.

Au niveau du code, la fonction d'init (SPIx est hardcoded pour tester) :

Et le main :

Le pin PA5 est bien initialisé, je peux le faire changer d'état. Que je test avec SPI_pin = 1 ou 2, cela ne change rien.

Une idée ? J'ai cherché et je trouve le même code que moi, mais sans effet ...

D'une manière générale, comment se décide dans quel port va les periphériques ? Au reset, j'ai la fonction SCK sur PA5 & PB3, si je veux utiliser PB3 pour une led (ou autre), comment limité SCK à PA5 ?

Merki

Bon, je m'autoréponds comme un grand.
L'"alternate function" se definit sur GPIO_InitStruct.Mode J'avais c/c du code qui était comme cela et pas une bonne idée (je suppute qu'ensuite c'était du SPI soft)

Et comme on peut le voir, l'initialisation du SPI se fait lors de la création de l'objet, qui se passe avant le setup();
MAUVAISE IDEE !!!
Le systemclockconfig est initialisée après (non visible dans le code version arduino, mais appelé lors de la construction de l'exe)

Entre ça et le BOOT0 que j'avais pas soudé suite à une petite erreur de conception de PCB et qui forcément, entrainait un boot aléatoire. J'ai bien perdu mon temps.

Il y en a qui ont déjà joué avec des modules comme ceux là :
https://fr.aliexpress.com/item/1005006837715553.html

J'en ai pris et j'ai l'impression que cela capte que dalle. J'ai bien une modification de la tension sur l'entrée analog mais j'ai pas l'impression que ce soit exploitable.
En continu, j'ai la tension planchée et quand je fais du bruit (quasiment dessus) j'ai une montée mais c est pas ouf
Est-ce que cela pourrait du au faite qu'il y a un serial.print avec la valeure ce qui amenerait trop de latence dans l'analogique ? (arduino)
J'ai joué avec la résistance, cela augmente les valeurs, mais rien de transcendant.

En pratique j'aurais voulu reperer des harmoniques ou des ambiances. Je pensais remplir un tableau avec les valeurs sur x ms et faire des opérations dessus

A première vue je vois LM393, c'est un comparateur, le truc doit simplement sortir un signal numérique si le volume sonore est supérieur à un seuil non?
 
Toi il te faudrait un micro + préampli ou un truc I2S.

https://win.adrirobot.it/sensori/37 [...] ircuit.jpg
Sur A0 t'aurais le signal en sortie brute du micro, si c'est un authentique électret t'auras pas un signal de grande amplitude et pour en faire quelque chose faut passer par un filtre passe haut pour virer la composante continue et un ampli.
 
Après ça peut aussi être un de ces faux microphones avec une sorte de membrane dont la résistivité varie avec le son mais j'y crois pas trop.

mouais, pas ouf en gros
 
Je vais voir si je peux néanmoins en tirer quelque chose, il y a plein de tuto avec ce modele.
 
J'avoue que j'ai pas envie d'y investir trop de temps, c'est un projet un peu secondaire où je pensais finir rapido. Je pensais que ce serait PnP ^^
 
Merki

Y'a donc "qu"'à remplacer le potard par un DAC et faire un convertisseur à approximations successives avec le LM393.

Je viens de zieuter le schéma.
La sensibilité du réglage doit etre très élevée : A vue d'oeil 1/4 de tour du potar en plus ou moins et c'est trop ou pas assez sensible.
Sachant que c'est un multi-tour.
Essaye dans un environnement calme tu tourne jusqu'a trouver le point de bascule entre L1 et L2, attention les vibration que tu fait en tournant se transmettent au micro.
Une fois le point de bascule trouvé tu essaye 1/2 tour en plus ou moins pour voir comment ça réagit au bruit.

Nb : tu devrait avoir un signal 0 ou 5V en sortie de ce montage, le LM393 est monté en comparateur (= AOP avec gain infini/maxi)

J'ai bidouillé et fait comme tu dis, le problème c'est que l'amplification est pas ouf. Si je parle fort sur le micro, je peux voir une montée de la tension. Sinon, je vois pas grand chose.
Je récup les valeurs sur x mS dans un tableau et je cherche la valeure max pour déja avoir une idée. A 1mètre, j'ai pas vraiment de valeurs qui se dégagent du tableau.

Tu as branché quel signal sur ton Arduino?
 
Juste pour clarifier, le signal en sortie du 393 est numérique, 0 ou 5V, selon si le bruit ambiant est inférieur ou supérieur à un seuil (peut-être dans le sens inverse, pas revérifié le schéma).

L'analogique

A l'oscillo (j'ouble toujours que j'en ai de compet maintenant), avec le bruit ambiant, j'ai 150-158mV et si je joue une note a cote, j'ai une pointe à 164mV en sensibilité max.
A 1m, j'ai déjà plus grand chose quand je tape dans les mains, mais ce serait exploitable comme detecteur de bruit

C'est pourri comme signal, surtout pour un ADC.  
 
Prend un autre module avec un vrai pré-ampli micro et attention à la composante continue.

Je suis déception, pourtant ce module est reference partout dans les montages arduino + capteur son. Genre ça https://www.youtube.com/watch?v=2n_JiXvBwsw mais maintenant je comprends qu'il a mis le haut parleur à fond.
Sachant que le module du dessus est HS, je l'ai vu avec un autre module que j'ai testé par acquis de conscience. Mais le résultat est pas vraiment mieux.
 
Braif, https://fr.aliexpress.com/item/1005006468621971.html ca c'est mieux ?
C'est un MAX9814 qui semble est plus fait pour.

Je peux pas voir le lien ("êtes vous un robot" etc ), mais le CI (clone ) semble ok à première vue. Sinon on doit pouvoir bricoler un truc soi-même, si tu as un AOP en stock... Vu que tu ne cherches pas la qualité sonore ultime ça doit bien être possible.

Moi je vois plusieurs problèmes dans ta façon de procéder :
 
1) On est déja 2 à te dire que ce montage sort un signal numérique (0 ou 5V, 0 ou 1 en binaire) et tu dit l'avoir branché sur une entrée analogique
 
2) le réglage du potentiomètre est très important, ils ont mis des LED sur le montage autant en profiter.

Tiens le rat voici la version compatible avec tes aspirations à plus de liberté

 
A0 sur A0 et D0 sur D0
Mais moi je veux faire comme le M, dans la vidéo qui détecte des notes    
Si c'est juste la detection d'un bruit en fonction d'un seuil plancher, cela m'interesse pas trop. Et même après reglage, cela change po grand chose, c'est pas ouf. (sur la detection)

Euh, ça me semble difficile de détecter des notes avec ce truc  
Tu aurais la vidéo ?
 
Les trucs qui détectent des notes c'est les appli d'accord d'instrument sur smartphone ou alors de spectrogramme par ex spectroid https://play.google.com/store/apps/ [...] trum&hl=fr

C'est ce que j'ai mis au dessus :
https://www.youtube.com/watch?v=2n_JiXvBwsw

En faite il met le HP à fond juste devant et j'avais pas percuté.
Mon envie, c'était de mettre en lien des leds RGB avec les notes détectées. Il n'y a pas besoin d'une grosse précision non plus. Mais là, je me suis fait eu

Comme dit rdc, je peux faire le montage moi même avec AOP, j'ai tout le matos en plus, mais j'aurais voulu un truc clé en main.

Il a clairement bidouillé pour que ca marche, ce genre de module est juste concu pour détecter un seuil de niveau sonore et basculer une sortie. En gros c'est une détecteur de clap.
 
Toujours se méfier des projets de ce genre et bien comprendre comment cela fonctionne avant de se lancer.

Cela me fait un truc en plus à stocker. En pratique, j'ai cherché sur le net et beaucoup semble penser comme moi. J'avoue, j'ai pas regardé le schéma avant (<sifflote> ), je me suis basé sur les différents projets.
D'ailleurs, même dans le kit eleegoo, cela affiche la valeur analogique du signal comme quoi il y a une mauvaise information assez générale.

Merci , mais Natopsi avait déjà posté un lien vers le schéma. Concernant les libertés, c'est surtout limiter (à défaut de pouvoir éviter) le pistage sur internet...

C'est assez récurrent avec les modules "Ali" ça... Faut toujours bien regarder/lire/chercher.

Sinon pour détecter des notes il te faudra du FFT ou sa version "simplifiée" Algo de Goertzel. Je te souhaite bien du courage si tu veux faire ça à la main (ce dont je doute vu le sujet ).

cela tourne sur un arduino ?

Ca dépend. Sur un ESP certainement sans trop de soucis, sur un AVR 8 bit faudra trouver une lib très optimisée et pas trop pousser. Perso j'ai fait du Goertzel sur AVR 8 bits, mais sans surcouche Arduino et pour quelque fréquences uniquement.

j'imagine que ca doit tourner, il y a des vumetre 8 ou 12 canaux à base d'Arduino.

Merci j'avais pas vu le lien.
J'ai regardé et le gars se branche effectivement sur A0 avec A0 donc il utilise la partie analogique du montage.
Ca a une chance de marcher si le potard est réglé comme il faut...

J'ai regardé son code, ligne 60 tu peut dé-commenter ça pour essayer de voir si tu tourne autour de 512 pendant la calibration.

   //Serial.println(offSet[i]); //use this to adjust the sound detection module to approximately half or 512 when no sound is played.

Nb : si j'ai bien lu il fait du sampling à 2Khz, donc faut pas espérer mesurer quelque chose plus haut que 1Khz.

Le code pour ceux qui ne veulent pas faire un compte
https://pastebin.com/qJuqCnCA

C'est des rigolos chez ST.

Ce qui est encore plus drole c'est :

Il y a pas un truc chelou ?

Et puis il y a aussi :

Qui en faite fait un START + adresse du slave.

Comment perdre x jours sur une connerie

Je vois qu'il n'y a plus grand monde

La réponse était que la fonction est sensée définir l'adresse I2C (mettons 0x12), sauf que cela copie SlaveAddr dans le registre I2C_CR2_SADD.
Et que le registre I2C_CR2_SADD, le bit0 correspond à rien, ce qui est un peu con. La fonction devrait faire automatiquement un décalage de bit.

--------

Sinon, pour STM32, j'ai pris le STLINKV3 PWR que j'ai un peu utilisé. Avant j'avais du stlink(c) aliexpress qui deconne et une STM32F0DISCOVERY comme programmateur. Sauf que ce modèle n'a pas assez de mémoire pour l'USART. Cela fait que pour tester d'autres uC STM32, cela nécessitait d'un côté le discovery comme programmateur et de l'autre un USB<-> USART.
L'avantage du STLINKV3 PWR c'est également d'avoir un suivi de conso tout en un (au ~prix du NRF-PPK2) sur une plage de mesure équivalente (A few nA to 500 mA current pour le stlink) contre (Accurate measurement down to approximately 200 nA pour le NRF-PPK2).
Niveau logiciel, c'est du ST, donc lourd (fait en java ?), mais fonctionnel. Principale inconvenient, le format 1.25" via un bus qui oblige à voir un PCB de transfert.
Il y a également un système de trigger, qui n'existe pas sur le PPK2, plutôt pratique pour ne pas avoir à chercher où se trouve la séquence à debugger. Du ON/OFF du circuit et des ports I2C & co en rab.

Bref, malgré le prix, je recommande (et je pense revendre le PPK2)

---------------

Question annexe, mais je crois qu'il n'y a pas foule en STM. Si l'arrêt des clocks GPIO permet d'économiser de la batterie, dans le cas du mode OUTPUT est-ce que cela n'a pas un interêt de modifier la clock "on the fly" :
- enableclock(GPIOA)
- modification de l'état du port
- disableclock(GPIOA)

En macro de digitalWrite() (si on prend la lib arduino)

Pour donner une idée, actuellement à 4Mhz, cela consomme environ 400uA (sans utilisation des ports) en modifiant quelques fonctions arduino par des fonctions "low drivers". Delay() augmente la conso de 200uA par rapport à la version low drivers par exemple. Donc je me dis qu'il y a moyen de gratter encore un peu sans pour autant ralentir le program en automatisant la gestion on the fly de la modification des ports en mode output.
En plus on peut modifier toutes les fréquences à la volée. Donc par exemple, accélérer la communication avec un capteur allumé pour diminuer son temps allumé.

Globalement, c'est très long, mais c'est ultra fun

Désolé, j'ai (toujours pas ) eu l'occasion de toucher aux STM32 et autres ARM, du coup je peux rien dire sur ton histoire. Je suis juste étonné que tu aies besoin de t'embêter avec ce genre de choses si tu utilises Arduino, mais j'imagine que soit y'a pas de lib' toute faite ou alors tu cherches vraiment à minimiser la conso électrique?

Il y a compatiblité entre les deux, sauf que c'est pas la même taille.
Me souvient plus comment j'ai fait mon bouzin, mais lib SPI+I2C+Serial = cela rentrait pas dedans > 30Ko.
C'est un peu comme l'arduino, tu as les librairies passe partout et si tu veux optimiser, tu es obligé de faire toi même (ou de recupérer une lib si elle existe) et là pour le coup, les optimisations me semblent assez impressionnantes