Re

Avec ton explication je viens de comprendre bien mieux comment fonctionne tes séries
On empile les données reçue du hardware dans un fichier et tes séries sont une copie des données
manipulées et arrangées

oui du coup on peut aussi , si on possède une entrée ADC sur le µc , rajouter la mesure de Ig , a regarder

on peut aussi sur ce principe afficher Ia fonction de Va et Ig2 fonction de Va séparément
ou encore traiter Ia fonction de Vg

Après c'est juste une question d'arrangement des données et leur mode d'affichage à gérer

Du pain sur la planche encore

Bon je continue l'étude du Hardware , tellement de chose à comprendre

Bon appétit

Ici:

http://www.diyaudio.com/forums/tubes-valves/227013-utracer.html

Suivre les liens, on y apprend que le GUI (IHM) est écrit en VB6 est qu'il est public.

Beaucoup d'infos intéressantes là:

http://www.dos4ever.com/uTracerlog/tubetester2.html#insideGUI

Bonne lecture ! ! ! !

Yves.

Bonjour Yves

Oui mais tourne sous wine under Linux
Vg1 max à -45 Volts

D'ou l'idée de réinventer l'eau chaude mais en adaptant a nos besoins

Perso j'aimerai bien atteindre -120 à 140 volts histoire de tester des 6S19P par exemple

toujours pas reçu ma carte chinoise pour tester la communication sous Gambas

A+

Bonjour à tous

j'ai reçu ma carte chinoise ce midi , je vais pouvoir commencer a regarder cette platine

A+

Bonsoir à tous

Après avoir réussi à trouver un connecteur pour brancher sur la carte en mode isp et l'autre bout
branché sur mon "USBasp" , j'ai commencé à regarder cette petite carte
Philbob tu avait bien raison l'USB est là pour charger le code (.hex) dans l'atmega
avec BootloadHID par exemple
Mais on peut peut être trouver une solution voir fichier joint (AVR309)

En branchant la carte sur l'USB il faut appuyer sur le bouton S4 pour activer le
bootloader et activer ainsi la connexion USB , une led clignotte ,
charger le code .hex et appuyer sur reset pour sortir du bootloader
la led s'éteint et on peut se servir du code

Donc demain je regarderai le "dummy-tracer" sous code-blocks pour l'implanter dans le µc
Ah au fait il s'agit d'un ATMEGA32L-8AU pas un 32U4

Voilà pour les news
Bonne nuit

Bonjour à tous

Ce matin entre les obligations dominicale et quelques cafés
j'ai eu le temps de zieuter le nain ternet à la recherche d'informations diverses et variées

ce petit mot s'adresse plus à Philbob et Seb

Yves aussi bien sûr

Donc avant de rentrer en profondeur dans les usages de ma carte et pour éviter de faire des bétises
et bloquer celle-ci , j'ai lu un peu les liens
avec l'idée derrière la tête d'utiliser cette carte comme;
-coillecte de données analogiques ( ADC )
-sortie de signaux PWM
-communication via RS232 ou mieux encore USB

En fait ce dont on a besoin pour le lampemètre

les liens http://www.obdev.at/products/vusb/prjdata.html

Particulièrement le "USBTenki", le "EasyLogger" et le "XXXX-HID"

Puis je suis tombé là dessus http://pjradcliffe.wordpress.com/open-usb-io/
un Atmega32 et le reste
Firmware et Hardware compris , une mine d'or je pense

Voilà

Bonne lecture, c'est l'heure de la sieste

Bonjour,

1) ATMega 32 (L)

Je dispose d'un ATMega32 et la doc est commune avec celle du 32L.

2) Les différentes cartes

Totof indique différents liens dans son dernier post.
On y retrouve des applications "classiques" à base de µC, à savoir:
Proposer des entées/sorties TTL
Proposer des enregistrements logiques et/ou analogiques
Proposer des conversions de format pour des flux de données

Ces applications peuvent se faire par le biais d'une carte
toute faite ou bien par une création maison...

3) Les µC

Il existe une multitude de µC dans le commerce.
Certains sont dédiés à des domaines industriels,
d'autre sont plutôt généralistes.
Il y a de 8, 16 et 32 bits
Les cadences CPU vont de quelques centaines de kHz à quelques
centaines de MHz.
Les capacités mémoires vont de rien à quelques MO.
Bref, il y a le choix.

4) l'ATMega32

Avantages:
format DIP donc facile à mettre en oeuvre contrairement au CMS.
Alim sous 5V (plus pratique que le 3.3V s'accordant mal au TTL)
8 entrées ADC
Cout raisonnable (<10€)

Faiblesses:
CPU 8 bits
mémoire pour les données de 2k
Cadence max 16MHz (mais avec archi RISC soit une instruction par cycle)

En pratique:

On peut en faire des choses avec un truc aussi petit!

J'ai employé ce µC dans un lecteur CD bricolé avec sortie à tubes pour gérer quelques fonctions:

- gestion d'un afficheur 7 segments (piste lues, temps de lecture, etc...)
- gestion du séquencement marche/arrêt avec tempo sur la haute tension
- gestion des commutations NOS/OS, AOP/TUBE (sortie du convertisseur TDA1541A)
- gestion de l'afficheur LCD (IHM)
- mesure de la HT
- décompte des temps d'utilisation
- décompte du nombre de cycles marche/arrêt

Au total, pas loin de 1500 lignes de code, le tout fonctionnant en temps réel (cadence 30 ms)
(pour les curieux, j'ai joint le code)

Conclusion, l'ATMega32 doit sans problème pouvoir être le coeur du futur µtracer.

Bonjour

Merci pour le résumé Philbob
ça résume bien les capacitées de cette petite puce

Hier soir j'ai jouer un peu avec la carte via un makefile
pour rentrer un bootloader cf ici http://dqsoft.blogspot.fr/2012/12/jy-mcu-minimum-avr-system-board-criando.html

Par contre se servir de "BootloadHID sous Linux j'ai pas réussi encore
sous Win ça marche avec l'exe fourni , mais sous Ubuntu ça coince pour le moment

Dès cette étape franchie je pourrais regarder ton Dummy tracer , sans précipitations

@ Philbob entre le site du P Radcliffe et celui de V-Bus , j'ai lu pas mal de code qui traite
de la gestion USB , as tu pu jeter un oeil

reprise du TAF , aujourd'hui

Re

Je crois que cette archive est la clé

Bonsoir

Bingo pour la carte , quelques news

J'ai repris le prog bootloadHID et la manip sous Linux (make)
manquait juste la dépendance "libusb-dev" pour que sa fonctionne
J'ai rentré ( copie du bin) bootloadHID dans /usr/bin à côté des bin avr (toolchain)

Maintenant je peut charger les .hex via USB dans l'ATMEGA
un coup de bouton poussoir S4 et le bootloader s'active
une led fixe indique indique la connexion USB
une autre led clignotante indique le mode "bootload"

Sous linux l'accès au port USB nécéssite d'être root , utilisation de sudo
donc modif du makefile avec sudo bootloadHID -r nomduprogramme.hex
l'option -r pour forcer le reset en fin d'upload

Ci-joint une archive avec le makefile modifié et qui fonctionne très bien sous Ubuntu 12.10
inside 2 fichiers exemples basique
de quoi se faire la main en ligne de commande

Je voulais pas en rester là j'ai donc transposé la programmation par bootload sous code-blocks
histoire de profiter de cet IDE pour debuger le code au niveau syntaxique

j'ai créer un "tools" voir capture jointe
le main.c avec l'appui sur un bouton qui allume une led est fonctionnel

Que du bonheur Linux je vous dit

Maintenant je vais me plonger dans la page du Pf Radcliffe et ousb
histoire de trouver le chaînon manquant , vous savez cette histoire d'envoyer
une chaîne de caractère via le bus USB et son retour "additionné" par le µc

Pour commencer je vais essayer de décrypter la version RS232 de Philbob

Si vous avez des questions, ne pas hésiter

Bon appétit

Bonsoir à tous

@ Philbob

J'ai rentré le code du Dummy-tracer sous code-blocks et programmé le µc

ci-joint la réponse envoyé par le µc suite à l'envoi 501111222233334444

voilà ou j'en suis

Demain je continue par le traitement de cette trame de réception

C'est pas gagné, les quelques essais ce soir sous Gambas me donne des signes illisibles
problème de format pour le décryptage

Mais on verra ça demain ou après

Bonne nuit

Salut le couche tard qui se lève tôt !

Ce que tu envoies et ce que tu reçois ne sont pas de caractères "imprimable" (ASCII) il est normal que ça affiche du garbage.

Sait on ce que signifie la réponse ? Si oui on pourrait comprendre comment elle est codée.
Envoie moi le fichier binaire "cutecom.log", peut être . . .

Yves.

bonjour Yves

oui regarde page 10 de ce post , premier message en haut de page de Philbob

en gros ça donne ceci

Si tout se passe bien, le µC répond à une commande du PC en renvoyant:

1*2 octets le code retour 10
4*4 octets les valeurs reçues
4*4 octets encore une fois les valeurs reçues
1*2 octets la commande recue
1*2 octets le compteur d'appel (de 00 à 99 en décimal)

soit

emission: 50 1111 2222 3333 4444
reception: 10 1111 2222 3333 4444 1111 2222 3333 4444 50 46
emission: 50 1111 2222 3333 4444
reception: 10 1111 2222 3333 4444 1111 2222 3333 4444 50 47
emission: 50 1111 2222 3333 4444
reception: 10 1111 2222 3333 4444 1111 2222 3333 4444 50 48
emission: 50 1111 2222 3333 4444
reception: 10 1111 2222 3333 4444 1111 2222 3333 4444 50 49
emission: 50 1111 2222 3333 4444
reception: 10 1111 2222 3333 4444 1111 2222 3333 4444 50 50
emission: 50 1111 2222 3333 4444
reception: 10 1111 2222 3333 4444 1111 2222 3333 4444 50 51
emission: 50 1111 2222 3333 4444
reception: 10 1111 2222 3333 4444 1111 2222 3333 4444 50 52

Voilà , reste à voir si le µc fait le boulot
et que la carte fonctionne en transfert RS232

A ce soir

Bonsoir Yves

Voici le fichier Cutecom.log , pas sûr que ce sois exploitable

Là un peu de sport et je reviens

A+

Bonjour,

Je viens de vérifier la transmission dummy_tracer <--> PC.

Chez moi ça fonctionne.

Ci dessous des copies d'écran de cutecom et l'interprétation
du fichier log que j'ai obtenu.

En regardant de plus près la config de la com chez Totof, je vois
que nous n'avons pas les mêmes réglages. Le problème vient peu être de là.