Qu'entends tu par cette citation. Est ce que tu veux parler des essais sur la machines pour vérifier le fonctionnement du programmt complet?Citation:
La méthode pour tester l'intégrité des données reste à définir.
Version imprimable
Qu'entends tu par cette citation. Est ce que tu veux parler des essais sur la machines pour vérifier le fonctionnement du programmt complet?Citation:
La méthode pour tester l'intégrité des données reste à définir.
Non, ça, c'est l'intégration. On en a pas encore parlé.Citation:
Envoyé par 202UH
Je parle de ceci :
Il va falloir expliquer comment on fait ça.Citation:
Envoyé par conception
Ce genre de 'sous-entité fonctionnelle' (pour rester vague, en fait, on dit plutôt 'bloc fonctionnel' ou BF) fait l'objet elle même d'une définition (quoi) et d'une conception (comment). Je rappelle que le processus de définition/conception est récursif et aboutit à une sorte d'arbre dont les feuilles (éléments terminaux) sont les fonctions ou groupes de fonctions (unités fonctionnelles) qu'il ne reste plus qu'à coder (phase 3 : réalisation). Ceci apparait plus clairement lorsqu'on écrit l'algorithme formel.
Dans les grosses réalisations, il n'est pas rare qu'un bloc fonctionnel devienne une unité d'exécution plus au moins autonome, et qu'il faille donc recourir à la programmation concurrente. (interruptions, processus, threads).
3 - Réalisation
L'arbre résultant de la conception va permettre d'organiser le développement en une successions d'unités fonctionnelles (UF) hiérarchisées. Certaines pourront être des composants logiciels déjà codés et validés :
- bibliothèques standards,
- bibliothèques d'extension (à éviter, car souvent non portables)
- tierces (le plus souvent portables, par exemple conformes à POSIX.1)
- personnelles
3.1 Dépendances
Si la conception a été bien faite (arborescence) les dépendances entre les UF ne devraient être qu'à sens unique.
Par exemple (A, B et C sont des UF) :
soit un arbre de dépendancesCode:
2
Si une flèche remonte, c'est soit un problème de conception (UF de niveau bas), soit une réalité (UF de niveau haut, plus proche de l'applicatif) qui doit être traitée par callback ou par messagerie inter processus (ou tâche) selon les cas. Dans le dernier cas, cette UF est probablement un BF qui s'ignore...Ca peut révéler un problème de conceptionCode:
2
3
4
5
6
7
8A /\ v | B | | v | / v C
On commence donc par réaliser et tester les unités fonctionnelles les plus basses (celles qui ne dépendent pas des autres).
3.2 Réalisation d'une unité fonctionnelle
Comme il peut y avoir des dépendances entre les unités fonctionnelles, on commence évidemment par les fondations, c'est à dire par le niveau le plus bas.
En général, une unité fonctionnelle correspond à un fichier d'implémentation (xxx.c) et son interface (xxx.h). Ne pas oublier non plus le fichier de tests unitaire (txxx.c).
C'est là que commence véritablement le codage.
Il faut commencer par établir une liste des unités fonctionnelles et les nommer (en général un nom court de 1 à 4 lettres, car il va servir de préfixe aux fonctions). Rien que cette opération n'est pas évidente...
Par exemple :
- xxx : fait ceci
- yyy : fait cela
Ensuite, on crée les fichiers correspondants :
- xxx.h, xxx.c, txxx.c
- yyy.h, yyy.c, tyyy.c
Quelques conseils : http://emmanuel-delahaye.developpez.com/codage.htm
Quelques exemples : http://emmanuel-delahaye.developpez.com/clib.htm
Ensuite, si on utilise la (très recommandée) méthode dites de 'codage par les tests', on commence par réaliser le jeu de tests unitaire (en se basant sur la définition de l'UF) qui va servir à qualifier la ou les fonctions de l'unité fonctionnelle. C'est le rôle des fichiers txxx.c et tyyy.c. Ce sont des petits programmes complets et autonomes (main() etc.) qui utilisent exclusivement la ou les fonctions à tester et, si nécessaire, des composants externes réputés fiables.
Ensuite, en gros, on écrit le code des fonctions et des interfaces "jusqu'à qu'à ce que le test sorte 'PASSED'".
Evidemment, c'est une simplification réductrice, et ça ne veut pas dire qu'il faille écrire n'importe quoi, évidemment. Mais ça permet quand même d'écrire du code de qualité et dont le comportement est défini, si les contraintes du langages ont été respectées.
Autre avantage, à la moindre modif (amélioration, simplification de l'algo, optimisation etc.) on relance le test unitaire (TU) et on voit tout de suite si le comportement a été modifié ou non.
Un TU peut aussi comporter des tests de performances permettant de tester réellement l'optimisation. Bref, on travaille dans le sérieux. Fini la bidouille...
Les UF de la fondation étant qualifiées, on peut ensuite en bâtir d'autres 'par-dessus', à la manière d'un véritable bâtiment.
Lorsque toutes les 'briques' ont été bâties, testées et assemblées, on a terminé le codage.
Ne reste plus qu'à le tester de manière autonome, puis dans son environnement réel (ce qu'on appelle l'intégration : phase 4) en terme d'ergonomie, de comportement, de stabilité, tenue aux erreurs, dans les conditions normales, extrêmes, hors normes...
Puis à vérifier sa conformité au cahier des charges (5-validation) en reprenant et en vérifiant point par point les fonctionnalités exigées. C'est le fameux cahier de recette qui permet au fournisseur de se faire payer si le client le signe. (gros travail: gros cahier de manip, beaucoup de manips, certaines à faire devant le client, aspect juridique : le fournisseur signe le document de recette et engage donc sa responsabilité...).
Les dernières (et rares en principe) corrections faites, on a alors le produit final conforme aux exigences du client.
Pour le contrôle des caractères perdus, après avoir enregistré nos 4 caractères dans le tableau résultat:Citation:
- contrôle des caractères perdus et si caractères perdus, initialisation du tableau et écriture de « 0000 » dans le fichier txt
- contrôle si le tableau caractère contient 1 ou plusieurs éspaces à la place des caractères :
- si oui, écriture "0000" dans le fichier txt
- si non, écriture de la chaîne réceptionnée dans le fichier txt.
- écriture des caractères reçus dans le tableauCitation:
La méthode pour détecter l'absence de EOL reste à spécifier
- si indice tableau i>41, alors EOL perdu
- initialisation tableau
- ecriture "0000" dans fichier txt
Est ce que c'est bon?
A moins d'être très expérimenté dans ce domaine précis (en gros de l'avoir déjà traité), il est difficile de répondre honnêtement à cette question par oui ou par non.Citation:
Envoyé par 202UH
Premier réflexe un peu goret : "OK, on va faire comme ça. On verra bien en intégration". Genre, je refile le bébé, je botte en touche...
Outre que cette attitude est douteuse sur le plan éthique, si ça ne fonctionne pas bien (comportement instable, perte de données inacceptable), le cout de la correction risque d'être prohibitif en temps, notamment.
C'est là que les méthodes modernes de développement font intervenir une notion un peu nouvelle qui est le 'maquettage'.
On écrit vite fait bien fait (le contraire du quick'n dirty), un 'snippet' (petit bout de code) qui va chercher à vérifier le comportement suspect par simulation. (Je crois que tu l'avais plus ou moins fait déjà). C'est une démarche qui ressemble à un test unitaire, sauf que là, il ne sert (à priori) qu'à valider une solution.
On va donc imaginer un certain nombre de scénarios, c'est à dire des séquences de caractères normales, puis altérée , et tester si l'algorithme qu'on a imaginé résiste bien à toutes ces situations.
Ce travail 'non planifié' qui peut prendre une certain temps, voire un temps certain, peut s'avérer décisif quand à la qualité du produit. En effet, si un problème apparaissait à ce moment là, le cout de la modification resterais très faible. (quelques lignes à modifier ou à ajouter dans le document de conception)
D'autre part, le travail réalisé n'est pas 'jetable', car, si il a été bien fait, il pourra avantageusement être récupéré en phase de réalisation.
pour la petite histoire, je travaille comme ça naturellement, et longtemps après, tel Monsieur Jourdain qui ignorait qu'il faisait de la prose, j'ai appris que c'était une pratique conseillée par les méthodes de développement modernes dites 'agiles' (comme eXtrem Programming, par exemple).
Si tu a une solution meilleure pour les contrôles, explique comment tu vois ça. Je ne peut plus discuter longtemps. Il faut gagner du temps pour que je puisse faire mon rapport car :Citation:
Premier reflexe un peu goret : "OK, on va faire comme ça. On verra bien en integration". Genre, je refile le bébé, je botte en touche...
1. mon exam a été avancé au 11/12/06
2. mon tuteur voudrai absolument voir tourner quelque chose, même si ce n'est pas parfait
A moins de faire une étude sérieuse comme je te l'ai suggéré, non, je n'ai pas de meilleure solution pour le moment.Citation:
Envoyé par 202UH
Oui, je comprends, et c'est une bonne chose. Il faut montrer une version stable, en précisant bien, par exemple quel telle ou telle condition de fonctionnement particulière n'a pas été testée.Citation:
Je ne peut plus discuter longtemps. Il faut gagner du temps pour que je puisse faire mon rapport car :
1. mon exam a été avancé au 11/12/06
2. mon tuteur voudrai absolument voir tourner quelque chose, même si ce n'est pas parfait
Pour le moment, fait ce que tu as prévu.
eXtreme Programming. Le Xterm, c'est un type de console ;)Citation:
Envoyé par Emmanuel Delahaye
Déjà fatigué le matin, ça promet...Citation:
Envoyé par DaZumba
Merci, je corrige.
J'ai constaté que ce thread (quasiment un dialogue) avait l'air d'être très lu ! Si ça peut rendre service à d'autres, tant mieux...
J'ai calmé un peut mon tuteur de stage et ses collègues. Je leur ai redonné le sourire en leur fesant un éssais sur leur machine. J'ai juste fais une boucle do dans une boucle infinie while(1); pour lire le port comme et afficher la partie de la trame qui les interesse. Quand ils ont vu apparaître à l'écran 1672, puis1724, puis 1709, ils avaient le sourire jusqu'au oreilles. Je leur ai présisé qu'il n'y avait encore pas de contrôle des caractères reçus et du EOL, et l'écriture dans un fichier txt qui permettra la réception des données avec WinCC, mais que ça allais venir bientôt.
j'ai eu comme réponse :
Voilà le programme que j'ai éssayeé :Citation:
Très bien, mais vite!
Code:
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
- L'indentation est... améliorable...Citation:
Envoyé par 202UH
- Ne pas mettre d'accents dans le code souce c'est pas portable.
- _9600_BAUDS est très laid. Pour être coherent avec les autres identificateurs du même genre (DONNE_8 etc.), BAUDS_9600 ou BDS_9600 serait plus adéquate...
- INTR n'est pas utilisé
- L'organisation des constantes est, disons, erratique...
- La globale fin n'est pas utilisée
- main() retourne int. Toujours. Il faut donc un return 0; (le fait qu'on soit dans une boucle 'blanche' est provisoire. On devrait pouvoir sortir proprement par une touche clavier genre ESC).
- c n'est pas initialisé. Il peut être local à la boucle principale...
- la globale init_liaison n'est pas justifiée. Elle peut être locale. Le type char tout seul n'apporte pas de gain mémoire et ajoute du code pour rien. Préférer unsigned[ int]
- L'algorithme n'a pas été suivi à la lettre, ce qui rend le code inutilement
compliqué. CAY MAL ! Si l'algo est faux, il faut le dire.
Code:
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
Pourquoi toute ces déclaration? Peut tu m'expliquer!Citation:
#ifdef CODEBLOCKS
#define outportb(port, data) printf ("[%04X]<-%02X\n", (unsigned) (port), (unsigned) (data))
#define inportb(port) printf ("[%04X]==%02X\n", (unsigned) (port), (unsigned) 0)
#else
#include <dos.h>
#endif
Avant de lire entièrement ton dernier message, j'avais corrigé BAUDS_9600 et suprimé le INTR qui n'est pas utilisé. Pour donner un peut plus de clarté au programme, j'ai créé une routine init_com2, mais quand je l'appelle dans le main(), il me donne une err de syntaxe sur init_com2(void);
Or, j'ai appliquer les cours qu'on nous avait donnés sur la déclaration et l'appelle des routines. Pourquoi l'erreur?
Code:
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
Comme Emmanuel ne dispose pas de outportb() et intportb() sous Code::Blocks, il a fait des macros qui affichent sur la console les données envoyées avec outportb()...Citation:
Envoyé par 202UH
Quant à la macro pour inportb(), je pense qu'elle est moins pensée que l'autre, puisqu'elle affiche toujours "[(adresse)]==00" et retourne toujours 11 (valeur de retour de printf())...
Je suis sous Code::Blocks (un IDE gratuit et performant pour Windows et Linux), alors je n'ai pas <dos.h>, donc je n'ai pas outportb() et inportb(). Alors je simule... (en gros, je remplace par un printf())Citation:
Envoyé par 202UH
Quand on appelle une fonction, on ne met pas le type :Citation:
Pour donner un peut plus de clarté au programme, j'ai créé une routine init_com2, mais quand je l'appelle dans le main(), il me donne une err de syntaxe sur init_com2(void);
Or, j'ai appliquer les cours qu'on nous avait donnés sur la déclaration et l'appelle des routines. Pourquoi l'erreur?
Code:init_com2();
Oui, c'est provisoire. J'avais l'intention de simuler l'UART... Dans un premier temps, je voulais surtout que ça compile, ça m'a permis de simplifier le code...Citation:
Envoyé par Médinoc
J'ai encore 2 petites questions :
1. Pourquoi chez moi le programme fonctionne alors que je n'ai pas déclaré la bibliothèque dos?
2. Comment programmer le contrôle des caractères perdus?
Gné ? <dos.h> n'est pas une bibliothèque. C'est un fichier d'interface (ou d'en-tête). Il contient le prototype des fonctions. Les fonctions elle-mêmes (implémentations) sont dans un fichier exécutable appelé bibliothèque.Citation:
Envoyé par 202UH
http://emmanuel-delahaye.developpez.....htm#prototype
http://emmanuel-delahaye.developpez....m#bibliotheque
Essaye en mode méchant (de mémoire : settings/compiler/warnings/display all)
En vérifiant la position des caractères connus dans la chaine reçue. A part les 4 caractères indiquant la valeur, les autres devraient toujours être identiques. Avec 1 ou 2 strncmp(), on devrait pouvoir vérifier...Citation:
2. Comment programmer le contrôle des caractères perdus?
Si on reçoit autre chose, c'est qu'il y a un problème de transmission et qu'on est décalé... La valeur sera fausse.
J'ai suivi tes conseilles et j'ai bataillé toute la soirée pour reprendre mon programme. J'ai créé des routines que je rappelle quand il me les fauts et j'ai réussi à rajouter la routine qui s'occupe du contrôle des caractères. Pour essayer le progr. j'ai rempacé toute la partie com2 par de la saisie clavier avec la fonction getch(). Quand je saisi ma trame, le résultat s'écrit correctement dans fichier txt et quand je fais une erreur, il me met bien "0000" dans le fichier.Citation:
En vérifiant la position des caractères connus dans la chaine reçue. A part les 4 caractères indiquant la valeur, les autres devraient toujours être identiques. Avec 1 ou 2 strncmp(), on devrait pouvoir vérifier...
Je joints le programme complet pour que tu puisses me dire ce que tu penses de l'ergonomie du programme.
PS : pourrais tu me rajouter la sortie propre avec ESC, je ne vois pas comment faire. Merci...
Code:
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
Bonne idée, les fonctions.Citation:
Envoyé par 202UH
- L'indentation est améliorable. Régler son éditeur de texte pour qu'il remplace les tabulations par N espaces (2 à 4. Chez moi, c'est 3).
- la définition de ESC n'a rien à faire dans la liste des registres.
- /* Bites de registres */ Ahem... "bits"
- outportb (IER, 0x01); Ca fait quoi ça ? IER, c'est le Interrupt Enable Register. Ca fout la trouille !
- Je suis étonné que tu ais pu définir 'init_liaison' après une instruction. Tu ne serais pas en train de compiler en C++ ? L'extension de ton fichier source est bien .c et non .cpp ni .C ?
- La fonction de contrôle des caractères est un peu trop compliquée. On a pas besoin de toutes ces recopies. Si j'ai évoqué strncmp() au lieu de strcmp(), c'est précisément parce qu'elle permet de comparer directement avec une portion de la chaine reçue avec une chaine de référence. Je suis un peu effrayé par ta faible connaissance du langage C et de ses fonctions standards...
- L'algorithme est correct mais un peu redondant. Tu peux 'factoriser' la fin de chaque branche des if, puisqu'elle est identique.
- Il faut aussi apprendre à automatiser les calculs de taille avec sizeof.
- Il est bon que les objets invariants (par exemple, ici, les 2 tableaux de char contenant les chaines de référence) soient définis 'const'. Ca aide à l'optimisation du code et le compilateur peut vérifier si on tente de les modifier (ce qui serait une erreur).
- Lorsqu'une fonction n'a pas de paramètre (main() en l'occurrence), on le précise avec void : int main (void)
- /* Pres a recevoir une nouvelle trame */ Attention à l'orthographe... Pas d'accents, pour des problèmes de compatibilité, OK. Mais "pret".
- Pour le moment, on va passer sous silence l'usage abusif de globales, car on a pas le temps de faire un cours de C... Dommage. Il faudra revoir tout ça après ton examen...
Il faut lire le clavier avec getch(), et si la valeur lue est ESC, on quitte la boucle.Citation:
PS : pourrais tu me rajouter la sortie propre avec ESC, je ne vois pas comment faire. Merci...
getch() est bloquant. Si on le met dans la boucle, celle-ci s'arrête et le port com n'est plus surveillé.
L'idée, c'est donc de soumettre la lecture du clavier à la condition "y'a-t-il quelque chose à lire".
conio fournit précisément la fonction kbhit() permet de savoir si il y a quelque chose dans le clavier (un peu comme le test du flag de réception dans l'UART).
Je te laisse écrire le code.
J'ai constanté un problème avec l'enregistrement dans un fichier. fopen associé à "w" devrait écraser le contenu du fichier pour le remplacer par celui de fprintf. Chez moi il rajoute le nouveau contenu derrière l'ancien. Pourquoi?
C'est pas possible. Tu ne dois pas regarder le bon fichier. Tu es sûr du répertoire ?Citation:
Envoyé par 202UH
Je vérifie. Au fait, j'ai écrit un simulateur d'UART à coup de FIFOs, et le code a l'air de fonctionner correctement...
Avec
sim_puts ("<16>:(PB): 1234 l/m\n");
j'obtiens :
Quand au fichier, il est correct :Code:
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
Code:1234
Je ne comprends pas. La version precédente sans les routines fonctionne. Dans la dernière version, j'ai juste mis l'écriture dans le fichier dans la routine ecriture_fichier(void) et le fichier data.txt correspond. En mode pas à pas, je rentre bien dans la routine ecriture_fichier, je fais le fopen, puis le fprintf, puis le close et je sort dans la boucle. Mais quand je vais voir le contenu du fichier data.txt, les anciennes va leurs sont là. Resultat de trois mesures :
1548, 1875, 1622
contenu du fichier data.txt :
154818751622
Je ne vois pas le problème?
Je n'ai pas de problèmes avec ce code (ignore ce qui concerne CODEBLOCKS)Citation:
Envoyé par 202UH
Code:
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
Avant tout, je tiens à m'excuser auprès de toi. Dimanche après midi j'avais remplacé mon vieux Turbo C par le Turbo C++ à cause de l'aide qui est beaucoup mieux faite et qui est en Français. Encore une fois, excuses moi.
J'ai ressorti l'ecriture du fichier data.txt de la routine ecriture_fichier et je l'ai remis dans le programme main(). Maintenant l'ecriture dans le fichier fonctionne à nouveau.
Ouf !Citation:
Envoyé par 202UH
Je ne suis pas encore gâteux !
C'est fini alors ?
J'ai repris ton dernier programme en ignorant ce qui concerne CODEBLOCKS.Citation:
(ignore ce qui concerne CODEBLOCKS)
J'ai fais 5 mesures : 1687, 1714, 1693, 2008, 1719.
resultat affiché par printf :
Je suis DESESPERE :cry:Code:
2
3
4
5
6
Petite erreur de ma part :
correction :Citation:
'0000'
'17'
''
''
''
Code:
2
3
4
5
6
Oui, il y a un bug qui m'avait echappé, mais que j'ai pu détecter grâce à ma simulation :Citation:
Envoyé par 202UH
Citation:
sim_puts ("<16>:(PB): 1687 l/m\n");
sim_puts ("<16>:(PB): 1714 l/m\n");
sim_puts ("<16>:(PB): 2008 l/m\n");
sim_puts ("<16>:(PB): 1719 l/m\n");
Ce qui est un magnifique comportement indéterminé (débordement de tableau grave !)Code:
2
3
4
5
6
7
Comme je me plais à le rappeler "C is sharp tool !"
strncat() nécessite que la chaine de destination soit initialisée (ici, vide) avant utilisation.
Ca devrait aller !Code:
2
3
La simulation, c'est puissant. Je n'ai jamais mis du code sur cible embarquée avant qu'il n'ait été testé durement sur PC en simulation...Code:
2
3
4
5
6
P.S. Ce bug expliquait ce problème :
Citation:
mesures :
1548, 1875, 1622
contenu du fichier data.txt :
154818751622
j'ai fais un dernier éssai et ça y est, c'est bon. Demain matin, je remplacerai le 'm' pour les éssai par EOL pour faire les ésais sur la machine. Je te tiendrai au courant.
Merci beaucoup...
J'ai fais plusieurs éssais ce matin. :D le résultat est bon. Tout fonctionne, je vais attaquer mon rapport de stage car il ne me reste plus qu'une semaine 1/2.
Si je fini mon rapport plus vite que prévu et s'il me reste du temps libre, j'aimerai faire un teste supplémentaire.
Actuellement, à la fin du teste hélium, l'automate envoie en un signale à la supervision et WinCC va alors lire le fichier texte pour afficher la valeur.
J'aimerai modifier cette lecture pour qu'elle soit indépendante de l'automate. C'est à dire, je vais lancer une action de lecture cyclique du fichier qui s'executera toutes les 200 ms ou plus (à voir).
problème : peut on modifier la routine d'écriture du fichier de la façon suivante?
1. contrôle de la disponobilité du fichier
2. si oui : écriture du fichier
3. si non : - attente de la disponibilité du fichier
- dès que fichier disponible, écriture ddu fichier
En attendant, je tiens à te remercier Emmanuel pour toute l'aide que tu m'as apporté, même si ça n'a pas été facile de travailler avec un débutant de chez débutant.
A plus....:ccool:
Un polling de 200 ms, pour un évènement mis a jour au plus rapidement toutes les 30 s, c'est pas raisonnable. Je dirais 1 à 10 secondes, ça dépend du temps de réaction exigé.Citation:
Envoyé par 202UH
Selon le système, oui, il peut y avoir un dispositif de verrouillage (flock()). Ce n'est pas portable.Citation:
problème : peut on modifier la routine d'écriture du fichier de la façon suivante?
1. contrôle de la disponobilité du fichier
2. si oui : écriture du fichier
3. si non : - attente de la disponibilité du fichier
- dès que fichier disponible, écriture ddu fichier
http://man.developpez.com/man2/flock.2.php
Ok.
Je vais faire mon rapport de stage et s'il me reste du temps libre avant la fin de la période, je verrai la suite. Je pense que le programme peut être amélioré, mais en attendant, je considère le problème comme résolut. Rien ne m'empèche de réouvrir la discution plus tard.
Encore merci.