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!
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é (V
ADC=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:
- 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)?
- 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)?
- 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.
- 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. 
À 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 à V
CC, 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, R
DS(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…
En revanche, pour cette même raison l'IRLB3034 va également moins chauffer, donc on aura un R
DS(on) plus stable: typiquement, R
DS(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 V
DS (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 R
DS(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…
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…
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!
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
Vapons en musique !
Menu
Rechercher