oui , c'est ça qui est bon

Tu me diras pour la forme des commandes passées sous le dummy_tracer

car j'ai noté un truc si on envoie une chaîne 01400 pas de soucis
mais 12-5 par exemple pour reprendre l'ancien protocole
ça va coincé, mais ça tu y avait déjà réfléchis je pense

Bon c'est l'heure d'aller

A demain

Bonjour,

Ci dessous dummy_12ax7_v03
C'est juste pour jouer avec cutecom.

On accède aux fonctionnalités du futur µtracer.
Les 19 commandes sont opérationnelles.

Régler cutecom sur "LF Line End" et un delai de 5 ou 10 ms



Chaque commande est suivie d'une valeur.

Pour activer une commande:

taper la commande puis "enter"
Le prog répond en répétant la commande reçue

taper la valeur puis "enter"
Le prog répond en répétant la valeur reçue puis indique
le code retour (0=OK 1 ou 2 --> pb de dépassement, voir le source)

Tant que la valeur n'a pas été saisie, le chenillard est stoppé.

Cas particulier de la demande de mesure (cmde 19)
A la suite de l'envoi de 19, la valeur attendue est le nombre de moyennes.
En retour, on a le code retour puis le vecteur des mesures.

Afin de bien fonctionner, il faut au préalable déclarer les bornes du domaine
(Vamax, Iamax, .....)
Comme c'est long, j'ai écrit ces valeurs dans le fichier "liste_cmde.txt".
Il suffit de l'envoyer avec cutecom.
Cela étant fait, on peut s'amuser à changer VA ou VG1 (cmde 15 et 17) + valeur
et relancer une mesure (cmde 19 + nb moyennes)

Bonjour Philbob

, je regarde cela ce soir

D'abord compilation sous C:B , je t'envoi le log au passage puis essai
sous Cutecom

Bonne journée

Bonsoir à tous

très très bonne nouvelle

La compilation c'est bien passée , le chenillard fonctionne

ci-joint capture du .log sous C:B

Ensuite Cutecom avec les réglages préconisés , fonctionne aussi
que du bonheur , le rajout de commande aussi
l'envoi du fichier texte "liste_cmde.txt" se fait sans soucis

Donc j'ai poussé le vice à mettre le char delay à 5ms , ça passe
puis 4,3,2 et puis finalement 1ms ça passe encore

ci-joint les 2 captures

retour rapide sous Gambas , l'envoi de la cde puis enter
suivi par la valeur puis enter , ça fonctionne aussi là
Sous Gambas je vais essayer d'envoyer "liste_cmde.txt"
grâce aux bouts de code que Yves a donné plus haut ,
ça devrait le faire
On tiens le bon bout

un peu de travail en perspective pour moi, mais que de bonnes nouvelles
vous trouvez pas

A+

Bonjour,

YES !

On vient de démontrer la faisabilité de la com.

Les étapes d'après:

Il faut que j'optimise le code pour ne garder que l'essentiel.
Réécrire certaines routines pour les simplifier, etc...
Commenter le code source, .....
Eventuellement basculer des fonctions en bibliothèque pour
alléger la lecture du source, .....

Faire une version dummy_12ax7 "attaquable" par un prog sous gambas....

Commencer à regarder la commande et la mesure avec les
nécessités du matériel (PWM pour les alims, amplis pilotés pour les mesures).

A ce propos, Totof, peux tu me fournir la ref des composants ou les datasheets
pour que je cogite sur l'interfaçage ....

Mettre au point la liste des ports utilisés.

Bref, du boulot en perspective.

J'ai fait ça pour saisir les paramètres et c'est fonctionnel.



Je donne un coup de balai et je l'envoie à Totof . . . demain.
Le reste avance aussi pas mal, je commence à penser "Gambas"

Yves.

Bonsoir Philbob

Oui je te prépare cela ce soir

pour la liste des composants je me suis basé sur ceux du µtracer
histoire de faire des essais après
je fait ça sous Kicad donc je te passerai les fichiers
je vais commencé par un booster HT comme déjà dit

pour Gambas , dès que j'ai avancé là dessus , je te ferai passé par mail
ainsi qu'a Yves le bout de code
je partirai sur la proposition de Yves, soit un formulaire de saisie des paramètres initiaux
un peu comme celui que j'ai déjà posté ( exit la conversion hex ==> plus simple )
reste à créer la plage mesure Ia(Va vs Vg)
du pain sur la planche là encore

Bon je vais manger , bon appétit
a+ tard

Bonsoir Philbob

Voici la liste de ce que j'ai approvisionné pour faire un prototype

A+

C'est exactement ce que fait mon formulaire

Bonsoir Yves

Oui , j'avais remarqué aussi , que du bonheur en fait

Je viens de tester mon proto de liaison USB ==> RS232 , c'est une fausse bonne idée
car la vitesse maxi est de 57600 et c'était marqué sur le site de l'auteur du projet
donc faudra que je trouve un adaptateur du commerce avec une puce ftdi
Et j'ai pas abandonné l'idée de passer directement par l'USB de l'Atmega32

A +

Bonsoir

Ci joint 2 captures, la première c'est au lancement du prog sous Gambas
quand j'ouvre le port com le prog lit le fichier List_cmde.txt et envoie les chaîne vers l'Atmega32
l'Atmega répond par le courant d'anode
les communication sont listée dans une listbox
Tout semble fonctionné ci-joint un bout de code


la deuxième capture en rentrant les 3 dernières commandes séparément
on remarque de suite que 300 devient 30 et -12 devient -1

Voilà pour l'avancement

Re bonsoir

J'ai trouvé , une légère temporisation à l'envoi des commande et hop ça fonctionne

le code


et la capture sous Gambas

Yves avec ton code dont tu as parlé, une petite mise en forme cosmétique de l'IHM
et on a notre "onglet capture" déjà bien avancé

Bonne soirée

Bonjour,

Pour la capture n°2, tu dis
cmde 15 valeur 200 (commande de Va à 200 V) qui devient 20 V
cmde 17 valeur -12 (commande de Vg1 à -12 V) qui devient -1 V

D'après ce que je lis sur l'IHM, la commande 15 à bien été envoyée avec 200 V
et on la retrouve à 20 V dans le vecteur de mesure. Ce n'est pas normal.

En revanche, la commande 17 à été envoyée avec -1 (et non pas -12).
Il est donc normal que l'on retrouve -1 pour vg1 dans le vecteur retour.

Maintenant, j'ai vérifie le courant Ia (0.095 mA) contenu dans le vecteur
de mesure. Il correspond effectivement aux conditions Va=20 V et Vg1=-1 V.

Donc: Le problème se situe soit à l'émission de la valeur depuis gambas
soit à la réception de cette valeur dans le µC.

De mon coté, j'ai bataillé aujourd'hui avec un programme PC qui dialogue
avec dummy_12AX7. J'ai eu des soucis de valeurs mal transmises.
Finalement, j'ai débusqué le loup dans le prog PC et dans une fonction
C (sprintf) qui convertissait une valeur numérique en chaine et qui
dans certains cas rajoutait un espace devant le nombre converti.
(D'expérience, je me méfie toujours de ces satanées fonctions qui
traitent les chaines de caractère )

Ce n'est pas ce qui se passe ici mais ça y ressemble. Ce n'est pas évident
de traquer le bug.

Ce qui peut être pratique, c'est de créer un fichier mouchard dans lequel
copie systématiquement toutes les commandes envoyées à la liaison rs232.
Après, on épluche le truc pour voir ce qui a réellement été envoyé.

Mails croisés !

Ne pas tenir compte de mon mail précédent.

Re Phiilbob
problème résolu regarde la capture 3

peut tu m'envoyer ton adresse en mp , je t'envoi le prog sous gambas
ainsi tu pourras communiquer avec le µc tout en jouant

A +