acquérir des données par un istream suffisemment vite

Bonjour,

Je suis en C++ (bien qu'on me conseille le C pour ce genre d'opération) et je reçois des données sur un port série. Je lis les données char par char avec get(). je stocke tout ça dans une queue que j'étaye à une certaine longueur et si elle vérifie les prémisses d'un message recherchée, je la duplique, la passe dans une string, fait qq traitement dessus et extrait les infos utiles que je cherche. Le problème c'est que mes données ont bien 10secondes de retard sur les faits... c'est embêtant. Ma méthode est-t-elle simplement trop couteuse en ressource? Si oui, comment faire simple? (si possible en évitant le multithreading)
... RQ, je n'ai que 25 msg de 16 bits par seconde envoyé... le pc devrait suivre!

Tu fais peut-être des copies en trop lors de la duplication...

Sans voir le code... Pas facile à deviner... Tu es sur que tu ne passe pas ton temps à attendre d'avoir eu assez de données sur ton port ? Ton processeur tourne-t-il à fond ?

ben après lecture des flag en lecture... ya que ios::in. Donc on perd des options du C apriori. On est donc forcément bloquant (on attend des données) mais le PC est sensé tourné vite.

En fait, j'ai résolu une partie du problème : j'ai viré l'acquisition char par char avec une acquisition ligne par ligne (retour charriot) et du coup... ça va plus vite si on envoi pas char\n char\n...Du coup le getline me permet d'enlever aussi la queue ... et je gère les strings directement.

...bon par contre si mes infos arrivaient plus vite... j'suis pas sûr de pouvoir suivre! ;)
Est-ce que vous connaissez donc des modes différents que ios::in?

Citation:

---

Envoyé par DEVfan

ben après lecture des flag en lecture... ya que ios::in. Donc on perd des options du C apriori. On est donc forcément bloquant (on attend des données) mais le PC est sensé tourné vite.

En fait, j'ai résolu une partie du problème : j'ai viré l'acquisition char par char avec une acquisition ligne par ligne (retour charriot) et du coup... ça va plus vite si on envoi pas char\n char\n...Du coup le getline me permet d'enlever aussi la queue ... et je gère les strings directement.

...bon par contre si mes infos arrivaient plus vite... j'suis pas sûr de pouvoir suivre! ;)
Est-ce que vous connaissez donc des modes différents que ios::in?

---

En utilisant une thread pour récupérer les données peut etre

ouioui... mais c'est la solution de dernier recours. Je reçois des données sur un port série à 25msg/sec ... le pc devrait pouvoir faire des opérations suffisamment vite tout de même!

Citation:

---

Envoyé par DEVfan

ouioui... mais c'est la solution de dernier recours. Je reçois des données sur un port série à 25msg/sec ... le pc devrait pouvoir faire des opérations suffisamment vite tout de même!

---

Si tu attend de recevoir avant de faire quelque chose,
ton appli est bloqué pendant l'attente, alors que tu aurait pu faire plein chose entre temps

Au risque de me répéter...
- Ton processeur tourne-t-il à fond pendant ce temps ?
- Du code, du code, du code, il n'y a qu'à partir de là qu'on pourra éventuellement t'aider.

DSL... WE :lol:

avec sD, sM et sF, des strings définies.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

bool nostop=true; int compteur=0; while(nostop) { if(compteur>=200000) nostop=false; else compteur++;   if (INPUT.good()) { for(int h=0; h<3; h++) //ça c'est pas obligé, c'est pour écumer un peu...j'ai tenté une solution....ingrate. {getline (INPUT,str,'\n');} //vérifier que c'est une chaine attendue if(str.compare(0,4,sD)==0 && str.compare(8,2,sM)==0 && str.compare(14,4,sF)==0) {//extraire les infos CANALss<<str.substr(4,4)<<endl; CANALss>>hex>>X_od; CANALss<<str.substr(10,4)<<endl; CANALss>>hex>>Y_od; cout<<"détection : "<<str<<endl<<"X:"<<X_od<<endl<<"Y:"<<Y_od<<endl;     //TOUTES les commandes qu'on veut faire à partir de ces infos.   } } /*else   cout<<compteur<<" : bad connexion"<<endl;*/ }

---

voilà du code ... et le processeur... il tourne sans doute à fond

Citation:

---

Envoyé par DEVfan

[code]
for(int h=0; h<3; h++) //ça c'est pas obligé, c'est pour écumer un peu...j'ai tenté une solution....ingrate.
{getline (INPUT,str,'\n');}

---

Cette boucle va attendre qu'il y ait eu 3 retour chariot avant de vraiment prendre en compte la dernière. Si tu manques de réactivité, je ne pense pas que ce soit très bon.

Enfin, on ne connais pas dans ton programme le code derrière INPUT, ni CANALss. On ne connaît pas non plus le profil des données reçues (quantité, taille, fréquence...).

Citation:

---

Envoyé par DEVfan

voilà du code ... et le processeur... il tourne sans doute à fond

---

Pourquoi "sans doutes" ? Tu as mesuré ? Mon hypothèque, vu les délais énormes par rapport au travail à effectuer que tu annonces, est que ton programme passe son temps à attendre on ne sait trop quoi plutôt qu'à travailler. Regarder comment se comporte le processeur permettrait de valider ou pas cette hypothèse.

ok, j'ai pas donné toutes les infos utiles:?

Bon par contre, j'ai une bonne nouvelle : j'ai entièrement résolu le pb posé ->j'étais floodé par les paquets à traiter et ça venait pas de mon pc pas puissant... en fait quand je fermais brutalement mon application, le port par lequel arrivait les données continuaient à être stocker dans le tampon. Du coup au redémarrage suivant... ça prenait un certain temps à vider... d'autant que le rapport débit entrant, débit sortant est très proche (mais seuleemnt de 50Hz)

Par contre, un truc qui m'intéresse toujours, c'est peut-on éviter la lecture bloquante en C++ (en C on peut)?

RQ : INPUT était un istream et CANALss, un stringsstream pour faire des conversions implicites hex, dec. Le débit de 50Hz avec qq dizaines d'octets