Modules WVMicrocontroleur chipset et Opensource

djinn
Pommier
Pommier
Messages : 96
Enregistré le : sam. 1 nov. 2014, 13:20
Genre : Non spécifié
Âge : 43

Re: Microcontroleur chipset et Opensource

Messagepar djinn » jeu. 26 mars 2015, 12:12

gdb a écrit :Heu, je ne savait pas qu'elle s'étalonnaient :lol:. Bon il va falloir que je me penche sur cette question

En principe il y a un générateur de tension carrée intégrée à l'oscillo (sur le tien ça doit être la prise TEST?). Tu y appliques ta sonde et tu vérifies que les plateaux sont bien plats. Si ce n'est pas le cas, tu tournes le réglage (situé sur la sonde) jusqu'à ce que les plateaux soient bien plats.

gdb a écrit :Je vais aussi essayer de voir si je peux trouver un voltmètre RMS pour vérifier (et valider mon algo).

C'est pas évident: la plupart des multimètres font du RMS en mode AC seulement (moyenne du signal doit être à 0V) et ne supportent pas un décalage DC (moyenne du signal ≠0V). Or c'est le cas pour nous: le signal oscille entre 0V et Vmax (moyenne Vmax/2). Mon multimètre "true RMS" échoue lamentablement dans cet exercice, par exemple. :roll:
Idéalement tu cherches un multimètre qui peut faire du RMS dans un mode AC+DC.

gdb a écrit : il va falloir, je pense, utiliser la dernière pin autre que le reset pour détecter un changement des swicths pour sortir du mode veille !

Ah bon? On peut pas juste utiliser une interruption pin change sur l'entrée des switchs?

Avatar du membre
gdb
Hypérion
Hypérion
Messages : 2713
Enregistré le : mer. 11 janv. 2012, 22:28
Ecigarette (s) utilisée (s) : Evic VTC mini + Origen MKII (mesh avec chaussette en Fiber Freaks + fil Inox)
Genre : Homme
Âge : 49

Re: Microcontroleur chipset et Opensource

Messagepar gdb » ven. 27 mars 2015, 02:12

Merci pour les infos sur l'oscillo et les multimètres, j'approfondirai le sujet à l'occasion.

djinn a écrit :
gdb a écrit : il va falloir, je pense, utiliser la dernière pin autre que le reset pour détecter un changement des swicths pour sortir du mode veille !

Ah bon? On peut pas juste utiliser une interruption pin change sur l'entrée des switchs?


Si, je dis n'importe quoi, il suffit de choisir les bonnes résistances !
Image

Pour soutenir la vape LIBRE et RESPONSABLE : Adhérez à l'AIDUCE !

djinn
Pommier
Pommier
Messages : 96
Enregistré le : sam. 1 nov. 2014, 13:20
Genre : Non spécifié
Âge : 43

Re: Microcontroleur chipset et Opensource

Messagepar djinn » ven. 27 mars 2015, 02:17

djinn a écrit :Mais avec une seconde prise de tension (sans voltage divider) au niveau du drain, on doit pouvoir utiliser RDS(on) comme un shunt et donc calculer la résistance du coil. :D

Ça a l'air de pas trop mal marcher. À voir si la résistance du FET ne varie pas trop dans le temps (je pense notamment aux changements de température à l'usage). :P
Désolé, l'affichage c'est un peu le bordel (j'essaie d'afficher un max d'infos pour contrôler le plus de choses possibles):

Image

J'ai donc deux prises de tension: une à la batterie (Vbat/A4) et l'autre sur le drain du mosfet (Vmos/A5).
À partir de là je peux calculer la chute de tension à l'atomiseur: Vato=Vbat-Vmos, et donc sa résistance: Rato=Vato*Rmos/Vmos.
Je peux aussi calculer précisément le duty cycle nécessaire pour obtenir le voltage désiré (Vset), en voltage moyen: Duty=Vset/Vato, ou en RMS: Duty=Vset²/Vato².

Je ne peux pas vérifier au multimètre que le voltage PWM à l'atomiseur correspond bien à Vset en RMS pour les raisons mentionnées au post précédent. Par contre, je peux le vérifier en mode voltage moyen: on est bon à ±10mV.
En l'occurrence, l'erreur vient de Vmos qui est trop petit (~250mV) pour être mesuré correctement avec un ADC 10bits sur le range 0-5V: on retrouve les fameux 2 Least Significant Bits d'erreur, soit ~20mV (10% de Vmos) . Il faudrait utiliser un voltage de référence plus petit (et adapter le voltage divider de Vbat en conséquence).

Pour faire ce type de mesures sereinement j'ai dû laisser tomber provisoirement le PWM hardware et repartir sur du bit-banging en software, en m'inspirant de ton code. C'est la façon la plus simple de s'assurer que la mesure de Vmos se fait au bon moment: pendant une impulsion (autrement Vmos=Vbat), mais pas trop tôt (pour que le voltage se soit stabilisé) ni trop tard (pour que la mesure puisse se terminer avant la fin de l'impulsion).
Cette technique a donc un impact en terme de fréquence PWM max: si on compte 300µs de stabilisation, et 2x120µ=240µs de sampling ADC pour Vbat et Vmos, on tourne dans les 600µs. En prenant un peu de marge ça nous fait une impulsion de 800µs au minimum — prenons 1ms pour simplifier les calculs. Si on fixe un duty cycle mini de 10% (soit √.1=32% de Vato en RMS), ça nous fait une période complète de 10ms, autrement dit les 100Hz que tu as habilement choisi. :-)
On pourra probablement améliorer un peu ça, notamment en ne faisant pas les deux mesures ADC à chaque cycle, mais je doute qu'on puisse monter à beaucoup plus que 200Hz. Dommage, un PWM-diapason à 440Hz m'aurait bien fait triper. :mrgreen:

Cette implémentation a une limitation: il devient peu pratique de mettre à jour un affichage, par exemple, sachant qu'on ne dispose jamais de suffisamment de temps d'un seul trait — on a au mieux quelques ms avant le prochain digitalWrite(). Il faut donc le mettre à jour morceau par morceau, en s'assurant à chaque étape qu'on disposera de suffisamment de temps pour la conclure sans fausser le PWM. C'est laborieux et pas très élégant.
Une autre limitation de cette implémentation c'est qu'on dépense beaucoup d'énergie dans des while(micros()) histoire de rester précis.

Bien entendu, la solution à ces deux problèmes c'est une implémentation se reposant sur du PWM hardware + interruption. L'idée c'est de déléguer le PWM au hard et de récupérer une interruption du même timer quand c'est le moment de faire nos mesures ADC. De cette façon nos mesures sont toujours synchrones avec le PWM, on dispose ensuite de presque 10ms pour effectuer des taches lourdes en cas de besoin (mise à jour de l'affichage), et on passe le reste du temps en sommeil pour économiser l'énergie. CQFD. :D
Seul bémol de cette approche: comme ça dépasse les possibilités du "langage Arduino" il faut régler les registres correspondants à la main, et on perd la compatibilité avec d'autres MCUs…

djinn
Pommier
Pommier
Messages : 96
Enregistré le : sam. 1 nov. 2014, 13:20
Genre : Non spécifié
Âge : 43

Re: Microcontroleur chipset et Opensource

Messagepar djinn » ven. 27 mars 2015, 02:27

gdb a écrit :il suffit de choisir les bonnes résistances !

Tu en es où à ce sujet? :)

Avatar du membre
gdb
Hypérion
Hypérion
Messages : 2713
Enregistré le : mer. 11 janv. 2012, 22:28
Ecigarette (s) utilisée (s) : Evic VTC mini + Origen MKII (mesh avec chaussette en Fiber Freaks + fil Inox)
Genre : Homme
Âge : 49

Re: Microcontroleur chipset et Opensource

Messagepar gdb » ven. 27 mars 2015, 08:11

J'ai un quadruplet de résistance que fonctionne mais je multiplierai bien leur valeur par 10 (je suis assez limité en valeur de résistance avec mon kit mais ferai d'autres expérimentations). Tu trouveras le code de la gestion des switchs ici.

Sinon encore une super expérimentation de ta part ! Mais, si j'ai bien suivi, le passage au MOSFET IRLB3034PBF n'arrangera pas les choses pour le calcul de la résistance :?

J'arrive aux mêmes conclusions que toi sur la fréquence max qu'on peux espérer mais j'ai moins de scrupules à faire des acquisitions en continu pendant la taffe (détection des court-circuits le plus rapide possible pour éviter de griller le MOSFET que je ne souhaite pas voir jouer le rôle de fusible ;-)). Et puis comparativement au courant consommé pendant une taffe, celui dédié au CPU est vraiment petit. Alors même si un mA est un mA ;-) je ne vais pas chercher à faire dormir la carte pendant la taffe ;-)

Après, pour la gestion en parallèle de l'écran, problème que je n'ai pas, j'irai peut-être essayer de voler des cycles au analogRead qui doit avoir je pense, mais sans certitude aucune, une boucle d'attente active sur la fin de de l'acquisition...
Image

Pour soutenir la vape LIBRE et RESPONSABLE : Adhérez à l'AIDUCE !

vierax
Sapin
Sapin
Messages : 260
Enregistré le : dim. 29 sept. 2013, 01:53
Ecigarette (s) utilisée (s) : ¤ Dany Extreme V2 (= Pipeline Pro 2)
Tayfun GSL
454 Big Block
¤ VAMO V5 Mukey double barrel en filaire avec un transfo 9V (matos de secours)
Igo-L

Fiber Freaks (première version) densité 1 ou 2 selon l'humeur + coton Bacon
base maison 90% PG végétal, 10% eau, nico 3.2 mg/mL
Arômes favoris : Hibiscus, Caramel Beurre Salé, Poire, Violette, Red Astair, Noisette, Châtaigne, Mandarine et Framboise
+ petits DIY allday : (Myrtille, Mûre, Kiwi) ou (Crêpe, Érable, Pécan)
Vape parfois sans arôme
Genre : Non spécifié
Âge : 33

Re: Microcontroleur chipset et Opensource

Messagepar vierax » ven. 27 mars 2015, 13:44

djinn a écrit :Sinon, vu le nombre d'alims ATX qui traînent au grenier, j'ai bien envie de me bidouiller un mod de salon surpuissant branché sur le 220. Mes batteries lui diraient merci!
En passant j'ai découvert qu'une ATX fournit du 5V sur un circuit standby toujours dispo, et que les gros convertisseurs (avec ventilos et tout le toutim) peuvent être démarrés à la demande en mettant un simple fil (vert) à la terre. Du coup je pourrais avoir une Arduino alimentée en permanence qui démarre l'alim quand on actionne la commande de chauffe et l'éteint le reste du temps. Énorme, non? :mrgreen:

Oui tu as souvent 1 ou 2A dédiés aux périphériques sur la ligne 5VSb, ça permet de lancer l'ordi d'une touche de clavier, d'un clic de souris ou via éthernet quand il est complètement éteint mais toujours sur secteur. Par contre ça te bouffe quelques W/h sur la facture EDF. J'ai jamais testé si c'est faisable mais niveau intensité ça permettrait largement de faire tourner une devboard ARM donc easy pour l'arduino :)

djinn a écrit :Dommage, un PWM-diapason à 440Hz m'aurait bien fait triper. :mrgreen:
On a bien des atos qui sifflent ou même qui font kazoo avec leur turbine donc pourquoi pas faire un mod musical qui lit un OGG avec un HP ou un Jack en parrallèle pour avoir le son :D Vapons en musique !

Avatar du membre
gdb
Hypérion
Hypérion
Messages : 2713
Enregistré le : mer. 11 janv. 2012, 22:28
Ecigarette (s) utilisée (s) : Evic VTC mini + Origen MKII (mesh avec chaussette en Fiber Freaks + fil Inox)
Genre : Homme
Âge : 49

Re: Microcontroleur chipset et Opensource

Messagepar gdb » dim. 29 mars 2015, 12:40

Bonjour à tous,

gros développement cette nuit : le prototype est fini à 99% et fonctionne pour l'instant très bien. La page de description est mise à jour (il y même une petite vidéo).

J'ai finalement intégré un algorithme de gestion du PWM qui à défaut d'être très rapide est assez généraliste. Il tient bien les 200 Hz avec une horloge du µC à 16 Mhz. Les boutons sont gérés "à la vamo" et l'affichage à base d"une unique led me conviendra (ancien utilisateur de twist ;-)).

Un plus au moins par rapport au vamo V2 que j'utilise est la sauvegarde dans la flash de la consigne et de l'état (dé)verrouiller du switch. Plus besoin de refaire les réglages à chaque changement d'accus ;-)

Prochaine étape l'intégration dans ma box (mais je n'ai pas encore reçu la petite carte à base d'attiny85).

En attendant rien n'empêche d'imaginer le contenu du futur menu accessible en pressant simultanément les boutons "up" et "down" proposant par exemple, sans électronique supplémentaire :

- le mode furtif (la led ne s'allume plus)
- le mode lampe de poche (led allumée jusqu'à l'appui sur un bouton)
- le mode morse : l'affichage de la tension des accus et de la consigne s'affiche en morse :mrgreen:
- ...

Si vous avez des idées ne vous gênez pas ;-)
Image

Pour soutenir la vape LIBRE et RESPONSABLE : Adhérez à l'AIDUCE !

djinn
Pommier
Pommier
Messages : 96
Enregistré le : sam. 1 nov. 2014, 13:20
Genre : Non spécifié
Âge : 43

Re: Microcontroleur chipset et Opensource

Messagepar djinn » dim. 29 mars 2015, 13:34

gdb a écrit :gros développement cette nuit : le prototype est fini à 99% et fonctionne pour l'instant très bien. La page de description est mise à jour (il y même une petite vidéo).

Énorme! :plus1:
Bravo!!! :respect:
Gros boulot en effet, plein de nouvelles fonctions… t'as pas dû beaucoup dormir… :mrgreen:
Et en plus elle a l'air d'envoyer vraiment fort. J'adore! :inlove:

djinn
Pommier
Pommier
Messages : 96
Enregistré le : sam. 1 nov. 2014, 13:20
Genre : Non spécifié
Âge : 43

Re: Microcontroleur chipset et Opensource

Messagepar djinn » dim. 29 mars 2015, 19:55

gdb a écrit :J'ai un quadruplet de résistance que fonctionne mais je multiplierai bien leur valeur par 10 (je suis assez limité en valeur de résistance avec mon kit mais ferai d'autres expérimentations). Tu trouveras le code de la gestion des switchs ici.

Bien vu le tableau indexé par un masque binaire des boutons pressés! 8-)

J'étudie tout ça et j'ai quelques questions sur ton montage:

Code : Tout sélectionner

+5V                             /        -----------   
 o                        +----/   o----| R2=220 Ω  |---+
 |                        | "Fire"/SW0   -----------    |
 |                        |                             |
 |    -----------         |     /        -----------    |
 o---| R1=10 KΩ  |----o---o----/   o----| R3=1.0 KΩ |---+
      -----------     |   |  "Up"/SW1    -----------    |
                      |   |                             |
                      |   |     /        -----------    |
                      |   +----/   o----| R4=2.2 KΩ |---+
                      |     "Down"/SW2   -----------    |
                      o                                 o
                   Analog (µC)                         GND
Si je comprends bien, en excluant le cas où aucun bouton n'est pressé (VADC=5V), les deux valeurs extrêmes mesurées à l'ADC sont:
  • résistance équivalente maxi: bouton "down" (SW2) seulement, REQ(max)=R4=2.2kΩ et VADC(max)=0.9V
  • résistance équivalente mini: tous les boutons pressés, REQ(min)=167Ω et VADC(min)=0.08V
Questions: :mrgreen:
  1. D'après ce calcul notre intervalle utile est donc de 0.82V (seulement). C'est pas un peu serré pour discriminer efficacement entre 7 états différents (i.e. combinaisons de boutons pressés)? Est-ce qu'on ne pourrait pas se contenter des 4 états qui nous intéressent (Fire, Up, Down, Up+Down)?
  2. Pourquoi un VADC(max) si bas (0.9V)? J'imagine que l'objectif c'est de déclencher à coup sûr l'interruption en passant de l'état HIGH à LOW, mais d'après les specs de l'ATmega328P (figure 35-26, page 601) on a de la marge: le seuil descendant est de 2.1V (pour VCC=5V). N'y a-t-il pas là un moyen d'augmenter par le haut notre intervalle utile (et peut-être de ne plus avoir à éteindre la LED pendant la conversion)?
  3. Pourquoi ne pas enlever complètement R2 de manière à avoir VADC(max)=0V pour le bouton "fire" (SW0)? Ça permettrait d'économiser un composant et d'augmenter par le bas notre intervalle utile.
  4. Pourquoi ne pas enlever également R1 et la connection à VCC, en réglant le pin à INPUT_PULLUP de manière à utiliser sa résistance intégrée (~30kΩ) à la place de R1? L'idée étant d'économiser un autre composant. ;)
    Dans ce cas on pourrait prendre par exemple R3=4.7kΩ et R4=10kΩ, ce qui nous donnerait des VADC(max) d'environ 1.25V, 0.7V et 0.5V (respectivement pour les cas Down, Up et Down+Up). Voire R3=10kΩ et R4=22kΩ, pour des VADC(max) de 2.1V, 1.25V et 0.9V. On pourrait faire mieux mais je me restreins aux résistances présentes dans nos kits. :P
À moins que j'ai raté quelque chose (corrige-moi je t'en prie), et si tout fonctionne comme en théorie, cumuler tout cela nous permettrait d'économiser deux composants, une connexion à VCC, et de simplifier un chouïa le code (en ôtant la "bizarrerie" TURN_OFF de getAnalog()).
Auquel cas on aurait un schéma comme celui-là:

Code : Tout sélectionner

                     /           
Analog (µC)    +----/   o---------------------+
   o           | "Fire"/SW0                   |
   |           |                              |
   |           |     /       +-----------+    |
   +-----------o----/   o----| R3=10 kΩ  |----o
               |  "Up"/SW1   +-----------+    |
               |                              |
               |     /       +-----------+    |
               +----/   o----| R4=22 kΩ  |----o
                 "Down"/SW2  +-----------+    |
                                              o
                                             GND

La motivation ici c'est vraiment de pousser le minimalisme du design le plus loin possible: c'est dans ce contexte me semble-t-il que le hack du voltage divider avec la résistance pull-up trouve toute son élégance. :)

gdb a écrit :si j'ai bien suivi, le passage au MOSFET IRLB3034PBF n'arrangera pas les choses pour le calcul de la résistance :?

En effet, RDS(on) devrait être environ 10x plus petit sur l'IRLB3034, idem donc pour la chute de tension aux bornes du MOSFET. Mais bon, j'ai quelques idées pour tenter de contrer ça… :P
En revanche, pour cette même raison l'IRLB3034 va également moins chauffer, donc on aura un RDS(on) plus stable: typiquement, RDS(on) augmente significativement avec la température, et quand on s'en sert comme shunt c'est une source d'erreur bien supérieure à la résolution de l'ADC, d'après mon expérience.

Notons aussi qu'à l'origine on cherche à mesurer VDS (la chute de tension aux bornes du MOSFET, aussi appelée Vmos dans l'illustration ci-dessus) surtout pour corriger la mesure du voltage envoyé à l'ato, de manière à pouvoir assurer une vape consistante dans le temps. Avec un RDS(on) d'environ 2mΩ l'erreur de mesure devient inférieure à 1% pour les coils supérieurs à 0.2Ω. Autrement dit, on peut raisonnablement considérer que Vbat=Vato.
Bien entendu le top de ce point de vue serait de monter le MOSFET en high-side (avant l'ato) plutôt qu'en low-side (après l'ato): de cette façon on pourrait transférer cette petite erreur de mesure de Vato à Vbat, pour lequel ça n'a aucune espèce d'importance. Mais comme tu as pu en faire l'expérience, nos MOSFET ne sont pas adaptés à ce type de montage… :P

gdb a écrit :J'arrive aux mêmes conclusions que toi sur la fréquence max qu'on peux espérer mais j'ai moins de scrupules à faire des acquisitions en continu pendant la taffe (détection des court-circuits le plus rapide possible pour éviter de griller le MOSFET que je ne souhaite pas voir jouer le rôle de fusible ;-)). Et puis comparativement au courant consommé pendant une taffe, celui dédié au CPU est vraiment petit. Alors même si un mA est un mA ;-) je ne vais pas chercher à faire dormir la carte pendant la taffe ;-)

Je te suis à 100%: pour la détection d'une chute de tension trop importante due à un court-circuit il n'y a aucune raison d'attendre.
Pour ce qui est de l'implémentation basée sur PWM hardware + interruption, la sauvegarde d'énergie est un plus tout relatif et en effet secondaire. L'idée serait surtout d'être plus précis et régulier dans la gestion de la PWM, de mieux utiliser les ressources disponibles, et d'avoir un code à la fois plus petit et plus flexible. Mais c'est vrai que, dans la mesure où tu fais des mesures de tension en continu pendant toute l'impulsion, ça perd une partie de son intérêt. Il faut que je regarde cette partie de ton code de plus près… :P

gdb a écrit :Après, pour la gestion en parallèle de l'écran, problème que je n'ai pas, j'irai peut-être essayer de voler des cycles au analogRead qui doit avoir je pense, mais sans certitude aucune, une boucle d'attente active sur la fin de de l'acquisition...

Idéalement, si tu n'y vois pas d'inconvénient, j'aimerais que ce projet permette d'utiliser en option un affichage I²C. Ça impliquerait de laisser libres les pins 0 (SDA/PWM) et 2 (SCK/ADC), ou plutôt d'éventuellement utiliser le pin 0 pour la LED (en l'absence d'affichage I²C). Si on parvient à utiliser avec succès les pins USB pour des core-functions, ça devrait être possible, non?

Pour ce qui est d'analogRead(), tu as raison (wiring_analog.c:76):

Code : Tout sélectionner

    // start the conversion
    sbi(ADCSRA, ADSC);

    // ADSC is cleared when the conversion finishes
    while (bit_is_set(ADCSRA, ADSC));

    // we have to read ADCL first; doing so locks both ADCL
    // and ADCH until ADCH is read.  reading ADCL second would
    // cause the results of each conversion to be discarded,
    // as ADCL and ADCH would be locked when it completed.
    low  = ADCL;
    high = ADCH;

    // combine the two bytes
    return (high << 8) | low;

Note que cette boucle active est source de bruit pour la conversion de l'ADC: de ce point vue également il vaudrait mieux se mettre en sommeil et attendre l'interruption de fin de conversion. ;)

vierax a écrit :J'ai jamais testé si c'est faisable mais niveau intensité ça permettrait largement de faire tourner une devboard ARM donc easy pour l'arduino :)

1.5-2A ça permet même d'en faire tourner une bonne centaine! :mrgreen:

vierax a écrit :On a bien des atos qui sifflent ou même qui font kazoo avec leur turbine donc pourquoi pas faire un mod musical qui lit un OGG avec un HP ou un Jack en parrallèle pour avoir le son :D Vapons en musique !

:lol:

Avatar du membre
gdb
Hypérion
Hypérion
Messages : 2713
Enregistré le : mer. 11 janv. 2012, 22:28
Ecigarette (s) utilisée (s) : Evic VTC mini + Origen MKII (mesh avec chaussette en Fiber Freaks + fil Inox)
Genre : Homme
Âge : 49

Re: Microcontroleur chipset et Opensource

Messagepar gdb » lun. 30 mars 2015, 18:37

djinn a écrit :La motivation ici c'est vraiment de pousser le minimalisme du design le plus loin possible: c'est dans ce contexte me semble-t-il que le hack du voltage divider avec la résistance pull-up trouve toute son élégance. :)


Super, tu viens de réduire significativement le nombre de composants et de soudures :inlove: . Je teste bientôt mais suis confiant ;-). Ok pour la résistance pullup mais en enlevant R2 en cas de mise à la masse par erreur (boite métallique, ...) de l'entrée analogique cela déclenchera un "faux" appuis sur fire. Perso, parce que "fire" est limité à 10 s. max, cela ne me pose pas trop de problème de conscience mais est-ce que cela vaut vraiment le coup a ton avis ?

djinn a écrit :En effet, RDS(on) devrait être environ 10x plus petit sur l'IRLB3034, idem donc pour la chute de tension aux bornes du MOSFET. Mais bon, j'ai quelques idées pour tenter de contrer ça… :P


J'espère que tu nous les fera partager (même si je crains que la "circuiterie" soit assez complexe).

djinn a écrit :Idéalement, si tu n'y vois pas d'inconvénient, j'aimerais que ce projet permette d'utiliser en option un affichage I²C. Ça impliquerait de laisser libres les pins 0 (SDA/PWM) et 2 (SCK/ADC), ou plutôt d'éventuellement utiliser le pin 0 pour la LED (en l'absence d'affichage I²C). Si on parvient à utiliser avec succès les pins USB pour des core-functions, ça devrait être possible, non?


On va tout faire pour ;-)

djinn a écrit :Note que cette boucle active est source de bruit pour la conversion de l'ADC: de ce point vue également il vaudrait mieux se mettre en sommeil et attendre l'interruption de fin de conversion. ;)


Ok, ce n'est donc pas là que tu pourras faire du calcul en parallèle. Bon maintenant je n'ai pas trop d'expérience sur les mod sophistiqués mais à moins d'avoir des yeux sur le menton, quel intérêt d'afficher des infos pendant la taffe ?
Je dis cela car cela risque de ne pas être simple et au détriment des contrôles.
Image

Pour soutenir la vape LIBRE et RESPONSABLE : Adhérez à l'AIDUCE !


Retourner vers « Modules WV »