Bonjour,

Ci joint une première mouture de ping_pong_chaine_µC.
On en est au stade Beta.

Que fait ping_pong_chaine_µC ?

Pour l'instant ping_pong_chaine_µC est un stupide répondeur. J'ai
retiré la notion de numéro de commande. Cela ne sert qu'à valider
la transmission de valeurs numériques.
Si tout se passe bien, Gambas envoie une chaine de caractères
vers le µC et reçoit une chaine de caractères du µC.


Comment ça marche:

Par la rs232, ping_pong_chaine_µC prend une valeur numérique
flottante exprimée sous la forme d'une chaine de caractères.
(voir restrictions plus loin)
Il l'interprète et si il comprend la chaine, il la transforme en "float"
Puis, il prend ce "float" et le transforme en chaine de caractères qu'il
émet par la rs232.

C'est tout.

Restrictions et conditions d'usage:

La chaine de caractère qui représente la valeur numérique doit
se terminer par un Line Feed (LF).
La valeur ne doit pas dépasser (en valeur absolue) 32768.
Le symbole du signe moins est "-"
Le symbole de la virgule est "."

ping_pong_chaine_µC retourne (au choix) entre 0 et 4 décimales.
Pour le moment, j'ai fixé le retour à 3 décimales.

Un exemple sous cutecom: (bien observer les paramètres)
A noter que lors de l'envoi d'un fichier, il faut régler
le débit à 10ms sinon le µC n'a pas le temps de tout
traiter et il perd des infos (la rs232 est en asynchrone)

Le mot du programmeur:

J'ai programmé "à l'arrache". Il y a sans doute des bugs.
C'est pourquoi je livre cette version qui doit être testée
par d'autres que moi.

Au début, j'ai essayé d'utiliser les fonctions "sprintf" du C.
Mais celles ci ne sont pas intégralement transposées dans les
librairies AVR. J'ai donc dû faire un interpréteur à ma sauce.
Ca à l'air de fonctionner mais ce n'est pas forcément optimal.
Le temps d'interprétation n'est pas nul.

Merci Philbob

Je te zieute ça et te tiens au courant

Bonne journée

Bonsoir Philbob

J'ai essayé ton Ping_Pong_V02 , et il beug
je l'ai rentré sous C:B je compile et j'ai une liste de bug , je te la joint au post

Le prog chargé fait défiler le chenillard mais ne réponds pas ce qui est attendu
j'ai bien fait gaffe au setup de CuteCom

Là je bosse sous Kicad sur mon USB=>RS232 converter , un petit PCB qui sera soit
entrée USB soit entrée RS232 , la partie RS232 converter à base d'un AT90s2313
Comme cela je pourrais continuer avec le port /dev/ttyS0 sur ma tour
et un port com virtuel (/dev/ttyUSB0 )sur mon laptop

Si le proto est fonctionnel, je posterai les fichiers

A+

Bonjour,

Dans la routine suivante:

//reception d'une valeur quelconque
uint8_t rs232_rx_valeur(void)
{
uint8_t i;
uint8_t n;
uint8_t nc;
uint8_t suite;
unsigned char c[30];
char mess[50]; <------------ c'est là !
uint8_t valid;
uint8_t cpt;
int8_t signe;
int8_t posv;
float v;
float mul;
...
...
...


Déclarer char mess[50]; et non unsigned char mess[50];

C'est la cause des warnings
pointer targets in passing argument 1 of 'strcpy' differ in signedness [-Wpointer-sign]....

Pour le reste, ce ne sont que des variables non utilisées.

Cela étant, je ne suis pas sûr que cela arrange les affaires.

Re

je fait l'essai de suite

Sinon jette un oeil là , http://www.gambasforge.org/sujet-4395-dialogue-via-rs232-entre-une-ihm-en-gambas3-et-un-controleur-page-2.html#m19

Peut être une piste à exploiter

j'y retourne

Bonjour,

Oui, La réponse de Flashy Joe sur le forum Gambas est intéressante.

Il indique que tu peux déclarer une variable en "single" et sa méthode
exposée au post #17 doit fonctionner pour dummy_12AX7.
Seul inconvénient, on ne peut pas vérifier sous cutecom.

Reste bien sûr à vérifier si la définition de "single" sous Gambas
et sur un PC 64 bits est conforme à l'IEEE754. Si c'est le cas alors
Bingo!

Sinon on poursuit avec la version chaine de caractères.

Re

Pas mieux au niveau répondeur mais la liste des beug diminue

Je pense que c'est la ligne 471 qui pose souci
je l'ai lue mais quoi faire
j'ai ajouter le n° de ligne dans le log pour pas chercher

A+

Messages croisés

J'ai essayé sa méthode mais pour afficher la bonne led ( elle affiche la bonne led d'aiulleurs c'est
déjà ça ) il me faut appuyer 5 fois sur envois, donc on but sur un détail , mais lequel

Je retourne au dummy_tracer pour d'autres essais

A+

Bonjour,

Chez moi la ligne 471 c'est:

c[i]=ct;

Comme c est un tableau d'unsigned char et ct est un uint8_t (ce qui est identique),
il se peut que le compilo couine.

Dans ce cas, il faut "caster" le ct en unsigned char comme ci dessous.


c[i]=(unsigned char)ct;

Re

Pas mieux avec unsigned

par contre si je déclare i = 30 par exemple
le 5ème message d'erreur disparait , le unibitialized

To be continued

Hep , une petite news

avec le dummy_tracer , j'ai ajouté un bouton avec un petit bout de code
et j'allume les led des séquences correctement , reste à voir si la valeur de cmde est reçue
et si le µc renvoie la mesure , bref du grain à moudre

le hic car il y a toujours un hic , à l'ouverture du prog
pour la première commande un seul click est nécessaire et suffisant
pour afficher la bonne led

la bricole qui m'allume les bonnes leds ensuite



La nuit portera conseil

A+

Bonsoir Philbob

Après quelques essais infructueux sous Gambas avec le code à base d'alloc()

J'ai refait un essai de ton ping_pong_chaîne

on progresse avec tes modif de hier soir
voici ce que me répond Cutecom

On progresse

Bonne nuit

Bonjour,

Ouaip!

Le même progr µC (ping_pong_chaine), le même prog PC (cutecom)
Ca marche chez moi, pas chez toi ! C'est louche.

Quelles sont les différences:

Chez moi: PC 32 bits sous linux, liaison par port ttyS1 ou ttysUSB0
Chez toi: PC 64 bits sous linux, liaison par port ttyS0
A priori la nature du port com n'est pas en cause.
(Ca fonctionne même avec un convertisseur usb/rs232)

Il y a bien le PC, mais j'ai des doutes. Comme je dispose d'un 64 bits,
je vais faire l'essai.

Reste les librairies AVR.

As tu essayé de télécharger directement mon code hex sans le recompiler ?
Ca permet de voir si le code machine généré chez moi est différent du tien.

A ce propos, je joints mon code hex, de ton coté, passe moi le tien pour que je
le teste directement....

Bonjour,

Je viens de faire le test en compilant ping_pong_chaine sous code blocks.
Le compilo couine avec l'include

#include </usr/avr/include/stdint.h>

Je l'ai donc viré et là ça compile.

J'ai téléchargé le code et.....
ça fonctionne pas!

On a donc un problème de librairies.

Je creuse le truc.

Bonjour,

Contradictoire !!!

Je viens de re refaire l'essai code blocks et ça marche !

Je pense que cutecom nous fout dedans de temps en temps.
c'est à n'y rien comprendre.