Traceur de courbes basique en DIY

[bilbo_moria]

Je suis également ça avec attention (bien que je sois grave largué dès la 2ème ligne )

[Totof]

Hello

Pas besoin de se passer des libs Arduino, on peut modifier le prescaler directement dans l'IDE

Ce petit bout de code me sert souvent pour déterminer la vitesse de conversion de ma carte à base de Atmega32U4 Leonardo like

Code : Tout sélectionner

// Arrays to save our results in
unsigned long start_times[100];
unsigned long stop_times[100];
unsigned long values[100];

// Define various ADC prescaler
const unsigned char PS_16 = (1 << ADPS2);
const unsigned char PS_32 = (1 << ADPS2) | (1 << ADPS0);
const unsigned char PS_64 = (1 << ADPS2) | (1 << ADPS1);
const unsigned char PS_128 = (1 << ADPS2) | (1 << ADPS1) | (1 << ADPS0);

// Setup the serial port and pin 2
void setup() {
  Serial.begin(115200);
  pinMode(2, INPUT);
  
  // set up the ADC
  ADCSRA &= ~PS_128;  // remove bits set by Arduino library
  
  // you can choose a prescaler from above.
  // PS_16, PS_32, PS_64 or PS_128
  ADCSRA |= PS_16;    
  // set our own prescaler to 64 
  
}

void loop() {  
  unsigned int i;
  
  // capture the values to memory
  for(i=0;i<100;i++) {
    start_times[i] = micros();
    values[i] = analogRead(A3);
    stop_times[i] = micros();
  }

  // print out the results
  Serial.println("\n\n--- Results ---"); 
  for(i=0;i<100;i++) {
    Serial.print(values[i]);
    Serial.print(" elapse = ");
    Serial.print(stop_times[i] - start_times[i]);
    Serial.print(" us\n");
  }
  delay(6000);
}

En mettant au pus rapide j'obtiens une conversion au environ de 24µs

voire la capture du terminal

Voilà si ça peut t'aider

A +

[a-wai]

Pas besoin de se passer des libs Arduino, on peut modifier le prescaler directement dans l'IDE

Alors en fait il y a 2 choses :

1. Le prescaler peut effectivement être setté dans l'IDE, et d'ailleurs on peut tout y faire bien sur, puisque c'est du C/C++ de base qui utilise la libc standard. Ceci dit, l'IDE Arduino ne me plait pas franchement, sachant que toute la journée je bosse sur Eclipse, qui a quand même un peu plus de gueule (même si, du coup, ça rend fainéant ).
Mais surtout, le problème principal pour moi est que tout, dans Processing, est fait par polling :
- pour l'ADC, on lance la conversion, et on boucle tant qu'on n'a pas le flag "conversion terminée" pour lire le résultat
- pour le port série, on écrit dans le registre qui va bien et on boucle tant que l'envoi n'est pas terminé
Au final, ça fait un paquet de cycles CPU perdus pour rien, alors qu'en bossant avec les interruptions, on remplit les registres, on laisse les sous-systèmes tourner pendant qu'on fait autre chose, et on s'occupe du résultat quand l'interruption "j'ai fini" est levée. Bref, c'est plus "propre", mais un poil plus compliqué à mettre en place, donc Processing ne le permet pas

2. La valeur de prescaler à choisir : tu prends 16, ce qui te fait une fréquence de l'ADC à 1MHz (si tu as les 16MHz classiques en horloge globale), or le datasheet indique que pour que l'ADC fonctionne à pleine résolution (que les 10 bits soient significatifs), il faut que sa fréquence soit entre 50 et 200kHz.
Donc je préfère suivre le datasheet et utiliser un prescaler à 128, qui me donne une fréquence de 125kHz pour l'ADC, pile dans les clous

Bref, pas de panique, côté code, je sais ce que je fais

[Totof]

Bonjour

J'ai hâte de voir , malgré que je ne maîtrise pas trop Eclipse

Pour Arduino et les interruptions et le transfert vers Processing, ça devrait le faire pourtant
je finalise un projet en ce moment qui est basé sur des interruptions et qui envoi une trame de données
via le port USB et Processing gère la réception et l'affichage et ça fonctionne
ce que je n'ai pas encore tester c'est l'envoi de commande avec Processing
Peux tu un peu développer le problème que tu soulève SVP , ça m'intéresse
1° cette fréquence pour la pleine résolution du CAN
2° le soucis du polling

merci d'avance

Bonne journée

[a-wai]

Pour Arduino et les interruptions et le transfert vers Processing, ça devrait le faire pourtant

Alors il faut bien distinguer 2 choses : ce qu'il est possible de faire (tout), et ce que peut gérer Processing (dans ce domaine, pas grand chose).
La lib permet, via attachInterrupt(), de réagir à un événement externe (changement d'état sur un pin), et là je pense ne rien t'apprendre... Ces interruptions sont au nombre de 2 sur un Uno, sur les I/Os 2 et 3 (ce sont les interruptions INT0 et INT1).
Sauf que des interruptions, il y en a 26 en tout, y compris pour des événements internes du genre "réception de données série terminée" ou "conversion A/D terminée" par exemple (pour l'ATmega328, la liste complète est en p. 65 du datasheet).
Il y a donc 24 interruptions qui ne sont pas gérées par Processing, et pour lesquelles on doit donc tout se taper à la main, via une déclaration du type :

Code : Tout sélectionner

ISR(USART_TX_vect)
{
  // Traitement de la réception d'un caractère
}

Et bien sur, les configurations de registre qui s'imposent, en positionnant les flags "Interrupt Enable" correspondants, ici le bit RXCIE0 de UCSR0B.
Donc oui, c'est possible, mais ce n'est pas géré par Processing.

Peux tu un peu développer le problème que tu soulève SVP , ça m'intéresse
1° cette fréquence pour la pleine résolution du CAN
2° le soucis du polling

Alors pour le 1, je ne fais que me référer au datasheet, p. 240 pour l'ATmega328 :

the successive approximation circuitry requires an input clock frequency between 50kHz and 200kHz to get maximum resolution. If a lower resolution than 10 bits is needed, the input clock frequency to the ADC can be higher than 200kHz to get a higher sample rate.

Par contre aucun moyen de savoir quelle est la résolution réelle en fonction de la fréquence, il faut donc considérer que le (les ?) LSB n'est pas significatif au-dessus de 200kHz, ce qui équivaut à une résolution de 9 bits (ou moins).

Pour le polling, c'est assez simple. Par exemple, si tu veux faire une lecture sur une entrée analogique, voici le code correspondant de la lib Arduino :

Code : Tout sélectionner

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

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

Si une conversion met 112µs, le while() bloquera donc ton processeur pendant cette durée, soit exactement 1792 cycles. Si ton application a des calculs à faire, ou un affichage à mettre à jour, il serait donc bien de s'en occuper pendant ces 1792 cycles, qui permettent déjà de faire pas mal de trucs intéressants

Dans le cas de mon traceur, si je faisais tout par polling, je ne ferais rien d'autre que des conversions A/D pendant 5ms, puis tous mes traitements pendant les 5ms suivantes, et rebelote.
Si au contraire je me base sur des interruptions, je peux lancer ma conversion, et mettre en forme mes données en faisant les calculs qui vont avec (par exemple pour déterminer le courant de cathode à partir de la valeur lue) en temps masqué. Ca permet un "multi-taches" basique, et donc de faire plus en autant de temps. On risque donc moins de rater une échéance, et l'exécution du programme est plus fluide.

EDIT : Pour que les choses soient bien claires, quand je parle de "Processing", pour moi ce sont les libs et l'IDE Arduino (je fais ptet un raccourci un peu rapide, là), pas ce qui tourne sur le PC... En relisant ton dernier post, il me semble qu'il y a confusion et qu'on ne parle pas tout à fait de la même chose

[McColson]

Je regarde le sujet ce matin... j'ai eu trop peur que le site soit encore hacké !!! lol
Bon courage les gars !

[Totof]

Bonsoir

En effet pour moi Processing était juste le programme de création d'interface graphique qui va bien en complément de
l'IDE Arduino

Pour ton histoire d'interruption, ok donc tu compte partir en C , j'avais commencé par ça il y a quelques temps avec Philbob
je sais pas si il traîne par ici , on avait mis au point un dummy-tracer qui permettait d'évaluer la communication entre le pc
et le µc justement , avec un squelette qui simulait une 12AX7

Pour les ADC et mon prescaler de 16 , j'ai bien une valeur retournée de 0 à 1023 , je relirais les pages du datasheet, mais j'ai du mal
à voir ou est le soucis , le seul truc que j'ai remarqué en analysant les mesures retournée c'est que les premières conversion à
l'allumage ne sont pas fiable et souvent erronées , mais ça c'est marqué dans le datasheet aussi

Je te joint nos fichiers du dummy, ça pourrais être utile pour la trame et les réflexion qui nous ont amené là

dummy_tracer_V04.tar.bz2

(180.43 Kio) Téléchargé 140 fois

A bientôt

[a-wai]

En effet pour moi Processing était juste le programme de création d'interface graphique qui va bien en complément de l'IDE Arduino

Non, c'est moi qui
En fait j'ai confondu Wiring (la base de la lib Arduino) et Processing.Les 2 sont apparentés, mais effectivement Processing ne concerne que la partie PC, et je ne l'ai jamais utilisé, je parlais en fait des limitations de Wiring.
Mea maxima culpa, donc !

Pour les ADC et mon prescaler de 16 , j'ai bien une valeur retournée de 0 à 1023 , je relirais les pages du datasheet, mais j'ai du mal à voir ou est le soucis , le seul truc que j'ai remarqué en analysant les mesures retournée c'est que les premières conversion à l'allumage ne sont pas fiable et souvent erronées , mais ça c'est marqué dans le datasheet aussi

De ce que j'en comprend, c'est que le ou les bits de poids faible peuvent être "faux" à une fréquence élevée. Ainsi, si tu as exactement 2.5V sur l'ADC, tu pourras lire 511, ou 512, ou peut-être même 510 ou 513... Bref, il y a une erreur possible sur la valeur mesurée qui peut faire passer ta résolution effective de 5mV (10 bits significatifs) à 10mV (9 bits significatifs) ou même 20mV (8 bits significatifs).
Ce n'est pas forcément systématique, et ça peut dépendre de paramètres extérieurs comme la température ambiante, mais au final le constructeur ne garantit l'exactitude de la mesure que si la fréquence de l'ADC est comprise entre 50 et 200kHz. Au-delà, les possibilités d'erreur sont plus importantes.
Ca mériterait de faire quelques tests...

Et merci pour les fichiers, je vais checker ça !

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

EDIT : Bon, j'ai un peu avancé aujourd'hui :
- cablage de l'alim
- cablage et débuggage du générateur de tension de grille
- tests

Voici ce que ça donne pour l'instant (scène réalisée par des professionnels, n'essayez pas de reproduire ça chez vous)



Au niveau des galères, on notera que mettre un TL081 à la place du 82 ne donne pas de très bons résultats

Sinon, la tension négative n'est pas régulée finalement, j'ai simplement ajouté une cellule RC (180R/220µ) derrière le 1000µ, ça semble pas mal pour l'instant : pas d'ondulation résiduelle visible à l'oscillo au niveau de la grille, on doit être sous le mV.

Par contre, et je m'y attendais un peu, la tension négative reste limitée par l'alim des AOP : en négatif j'ai quasiment -8V donc ça va, par contre en positif je n'ai que le +5V de l'Arduino. Comme la tension négative est simplement l'image inversée de la tension positive, c'est de ce côté que je suis limité, et j'arrive dans le meilleur des cas à -4.1V (avec un LM833 ou un MC1458 ; pour info j'ai testé tous les doubles AOP que j'avais sous la main et ce sont ceux qui font le mieux de ce point de vue, devant les OPA2134 et JRC4560 à -4V, ou encore le TL062 à -3.8V ; le TL082 prévu initialement ne dépasse pas les 3.3V)

Du coup j'ai changé un peu de stratégie : je génèrerai une tension entre 0 et 3V via le PWM de l'Arduino, et l'étage inverseur aura un gain de 2 pour passer à -6V au max. Et d'ailleurs (je fais les tests en tapant ce post) on a un max de quasiment -7V dans cette config, donc effectivement ça roule !

Suite demain j'espère, il me reste à cabler l'amplificateur de tension de cathode, ce qui devrait être plus simple, et ensuite j'attaquerai le codage.

[Totof]

Bonjour a-wai

Perfect ton avancée

Bosse bien dessus alors

Bon dimanche

[thiet]

joli job, j'ai hâte de voir le prochain épisode !!

[a-wai]

Bon, suite des événements !

Au menu, cablage de l'amplificateur de tension de cathode et... debuggage, bien sur !

Pas de grosses conneries cette fois, j'ai juste cablé selon le schéma prévu, et dans l'ensemble ça fonctionnait... J'ai donc testé à l'oscillo en mode XY, en générant le PWM avec mon GBF (qui peut générer un signal carré avec un rapport cyclique réglable entre 20 et 80%), voici le résultat pour une ECC81 :



Pas terrible hein ? En y regardant de plus près, il y a un déphasage entre la tension d'anode et la tension de cathode amplifiée. Dans un premier temps je me dis que c'est ptet parce qu'il y a un AOP sur l'une et pas sur l'autre, donc je vire le TL081 pour y mettre un LM833, et ainsi bufferiser la mesure de la tension d'anode...
Evidemment, ça n'a rien changé, j'ai donc viré C5 (qui servait de passe-bas dans la contre-réaction de U4), et bingo ! Maintenant j'ai quelque chose de potable :



La partie analogique est donc quasiment terminée ! Seul petit soucis qui me reste à régler, j'ai un léger offset sur la tension de cathode amplifiée (le 0 sort à -60mV), je vais donc surement remettre un TL081 à cet endroit avec un petit potar pour annuler cet offset, mais pour l'instant je vais laisser en l'état et commencer à coder dans les jours qui viennent.

Voici la bestiole dans son état actuel, vous noterez que l'accent n'a pas vraiment été mis sur la sécurité pour l'instant



Je vous laisse le schéma actuel en PJ, la suite au prochain épisode, une fois que j'aurai bien avancé sur le code

Tester.pdf

(26.79 Kio) Téléchargé 144 fois

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

EDIT 21/02 : Bon, j'ai bien avancé sur le code... Pour l'instant on est sur du proto bien sale, il reste encore quelques trucs à automatiser (en particulier le changement de Vg pendant la mesure), mais dans l'ensemble ça fonctionne pas mal !

Le dispositif de test :


Pour l'instant je séquence tout à la main : sélection de Vg via le "duty cycle" du PWM (entre 0 et 90% par pas de 10%), lancement de la mesure, et à la fin retour au cut-off en abaissant au max Vg.

Voici un fichier de mesures faites sur 2 ECC81 et 2 ECC83 différentes (l'Arduino sort les colonnes au format CSV, du coup y'a qu'à copier-coller pour avoir les courbes

Mesures tubes.ods

(69.13 Kio) Téléchargé 152 fois

Quelques problèmes qu'il faudra résoudre bien sur : la tension de grille n'est pas fabuleusement propre, j'ai des pics d'environ 200mV à chaque front (montant ou descendant) du PWM, va falloir analyser ça...
Au passage, l'Arduino montre ses limites en termes de résolution, notamment sur les ECC83 pour lesquelles les courbes sont loin d'être bien lisses. Je vais continuer avec pour l'instant, mais si je veux augmenter la précision du bouzin et le rendre réellement utilisable, faudra penser à un autre µC.

Prochaine étape quand j'aurai terminé et nettoyé le code de cette version

[Totof]

Hello good job

Pour la résolution et vu le nombre de PMW que tu utilise à vue de nez essaye peut être avec la lib timerone
ou du moins décortiquer le C+ derrière car cette libe possède une pwm(pin, duty, period) avec duty de 0 à 1023
voir ici

Quel duty pour ta PMW

Pour le µc la Nucleo F4** semble pas mal non

Amuse toi bien et a +

[a-wai]

Mon "problème" de résolution est au niveau des ADC en fait, le PWM ne me pose aucun soucis : sa fréquence est de 62.5kHz, et le duty je peux le régler entre 0 et 255, ce qui me suffit largement, c'est juste mon "interface" qui me limite volontairement aux multiples de 10%
Ceci dit, je pourrais aussi faire un test en remplaçant le PWM avec un petit DAC Microchip qui traine dans mes boites à cafards

Pour le µC, j'ai un STM32F4 Discovery en stock, faut que je vérifie les specs mais ça devrait le faire... Mais bon, ceci est une autre histoire, pour l'instant je vais terminer la mise au point "low cost" avec l'Arduino et le petit transfo Tube-Town.
Pour une éventuelle v2, j'ai le STM32 et un transfo ESO qui pourraient servir, je verrai en temps utile

[Lemontheo]

Salut Arnaud,

je n'y connais rien en programmation (mais je viens de commander une carte Arduino Uno), et je ne comprends pas bien ce qu'y se dit sur ce sujet, mais je suis très intéressé par ce projet.

Cependant, je me pose la question de l'utilisation d'une alimentation "type nixie" avec mosfet, diode rapide,... plutˆot que d'une à transfo?
ça permettrait d'alimenter à partir de 12V, ce qui donne le chauffage, et on pourrait plus facilement faire un shield pour l'arduino?

Théophile

PS : il y a un shield Nixie (open source Eagle CAD) ici > http://arduinix.com/

[Totof]

Bonjour Lemontheo

Pour faire court, et si j'ai bien compris les propos de a-waï , ta platine Arduino n'est pas assez performante pour ce projet
elle est à la ramasse face aux nouvelles cartes dispo de taille aussi réduite et avec beaucoup plus de ressources
et une vitesse bien accrue ( 5 x ) , ta carte est donc trop limite pour être efficace

A +