Un étrange bug de contraste - Page 1

Bonjour !

Voilà je suis actuellement en train de programmer un logiciel de dessin qui marche plutôt bien, et en voulant améliorer la vitesse de mon affichage, je suis tombé sur un bug que je ne comprends pas.

Les symptômes

Lorsque mon programme tourne, un appui sur la touche ON met automatiquement le contraste à 0.
Lorsque je quitte mon programme sans appuyer sur la touche ON, et ensuite appuie sur la touche ON (alors que je navigue sur l'interface basique de ma TI), le contraste est mis à 0. Le bug de contraste est plus fort que la commande OFF : si j'essaie d'éteindre ma calculette, il ne l'éteindra pas, mais mettra le contraste à 0.

Le bug ne frappe qu'une fois; un deuxième appui sur la touche ON ne modifiera pas le contraste et je peux l'éteindre normalement.

EDIT : De plus, la mémoire Flash ROM Free affichée dans le menu mem de la calculette affiche la quantité 2 une fois le programme quitté.


Le code foireux

J'ai évidemment recherché dans mon programme la/les lignes de code à la source du mystérieux problème, et suis finalement tombé avec surprise sur cet innocent bout de code :

for (x=0;x<160;x++) memcpy(LCD_MEM+30*x, virtual+20*x, 20);

où virtual est un buffer de 2000 octets (soit un plein écran de ti89). Cette ligne (qui marche parfaitement à l'exécution) affiche à l'écran l'image enregistrée dans virtual.

Or lorsque je la mets en commentaire, je ne retrouve plus le bug de contraste ! Et je ne vois pas le rapport entre la touche ON, un contraste mis à zéro, et ce bout de code...


Je précise également que je désactive (plus exactement redirige vers rien) les auto-int 1 et 5 au début de mon programme, et les réactive à la fin.



Comment et surtout pourquoi ma calculette réagit-elle de la sorte ? Si quelqu'un a une idée, cela m'aiderait beaucoup.

Si je me souviens bien la touche ON déclenche l'auto-int 6, donc, je dirais que tu dois avoir modifié cet auto-int par erreur, ce qui expliquerait également pourquoi le problème persiste une fois le programme terminé.

Par contre, j'ai du mal a voir un éventuel rapport avec la ligne que tu as posté.

Tu peux installer PreOS et regarder sir le big persiste ?

Bon, il y a du nouveau !

J'ai vérifié, je n'ai pas touché à l'auto-int 6 à cause d'une quelconque faute de frappe. Cependant je le modifie peut-être d'une manière plus sournoise et involontaire. C'est une piste...

J'ai installé PreOS v1.0.7 et le bug persiste.

J'ai découvert un nouveau symptôme ! Une fois le programme quitté, la quantité de mémoire flash ROM free affichée dans le menu mem de la calc devient égale à 2 ! (premier message édité)
(ce bug est de plus en plus mystérieux... ah, le C ! )

Peut-être un buffer overflow ? Ce serait en rapport avec la ligne de code qui fait bugger, mais elle me semble parfaite.

En fait, ce qui m'embête vraiment, c'est que c'est FORCEMENT le memcpy qui fait bugger, puisque tout marche quand je le mets en commentaire, et pourtant c'est impossible puisque c'est une boucle on ne peut plus simple et qui a de surcroît le culot de marcher...

Il faudrait trouver les causes possibles des symptômes observés, et voir lesquels sont susceptibles d'être présent dans mon programme.

J'utilise PortSet pour des images 159x99 (et non 239x127), les auto-int 1 et 5, et j'écris parfois directement sur la mémoire vidéo. Y a-t-il dans ces manipulations quelque piste?

Es-tu sûr de ne pas dépasser ? Il me semble qu'il y a des variables systèmes derrière la mémoire vidéo.

OUIIIIIII !!!

Merci Pen^2 !!!

J'étais fatigué, et finalement tout est bien qui finit bien : c'est bien le memcpy qui faisait bugger !

J'avais juste inversé les lignes et les colonnes. Le bon code est :

for (x=0;x<100
;x++) memcpy(LCD_MEM+30*x, virtual+20*x, 20);

Et dire que personne n'avait remarqué la petite erreur dans cette petite ligne de code

Je vous remercie tous et vous souhaite une bonne journée

edit: crosspost

rah le bug qui tue, on aurait pu y passer des jours

le buffer d'écran n'est pas contigu? t'avais pas moyen de faire l'opération en un seul memcpy de la bonne taille?

J'avais pas vu non plus ^^
En fait quand tu suspectes un buffer overflow, le mieux à faire est de réduire la zone de mémoire affectée et observer le changement. Par exemple, tu aurais remplacé 160 par 80 et tu te serais aperçu que ce n'est pas la moitié de l'écran qui s'efface alors mais plus du trois quart.

squalyl> Le buffer fait 240 de large

Comme quoi parfois on a beau avoir la solution devant le nez, on se refuse à voir l'erreur

J'ai choisi un buffer virtuel de 160x100, celui de la mémoire vidéo étant de 240x128, tous les 20 octets suivent 10 octets totalement inutiles pour la ti-89.

Brunni > C'est ce que j'avais fait, mais avec un nombre encore trop grand...

Lepzulnag (./4) :
J'ai vérifié, je n'ai pas touché à l'auto-int 6 à cause d'une quelconque faute de frappe. Cependant je le modifie peut-être d'une manière plus sournoise et involontaire. C'est une piste...

Pour info, il y a une protection matérielle pour empêcher d'écrire dans la zone des vecteurs (les 100 ou $100 premiers octets, je sais plus). Et le handler de l'AI6 est en flash, donc il y a un risque ultra minime que ça puisse arriver.

Lepzulnag (./4) :
J'ai installé PreOS v1.0.7 et le bug persiste.

Ca voulait dire que le handler de l'AI6 n'était pas en cause, ce qui est bien le cas.

Lepzulnag (./4) :
et pourtant c'est impossible

Pour ta gouverne : fous-toi à grand coup de massue dans le crâne qu'un bug, c'est TOUJOURS !!! de ta faute. Si tu pars avec une autre mentalité, tu seras frustré. J'en ai fait l'expérience avant de l'admettre, ou d'avoir un niveau assez bon pour trouver les bugs des autres.

Pen^2 (./5) :
Il me semble qu'il y a des variables systèmes derrière la mémoire vidéo.

Yep, et la pile superviseur avant. Mieux vaut bien viser ^^
Et pour info, PreOS sauvegarde/restaure 3 lignes sous l'écran pour éviter une partie des désagréments.

Quel coquin ce PreOS

Si tu as recours à un buffer virtuel de 20 octets de large, c'est que tu utilises les fonctions d'AMS et que tu n'as pas besoin de vitesse
Les librairies graphiques rapides utilisent des buffers pleine taille et de la copie rapide.

(Tu devrais lui dire quelle est la bibliothèque graphique la plus efficace ; perso je ne suis plus très au courant)

C'était pas extrgraph?

Il n'est pas obligé d'utiliser une librairie graphique s'il n'en a pas besoin

En 2011, il n'y a que deux librairies graphiques (quelque peu) maintenues: ExtGraph et Genlib. Elles ne sont pas vraiment en concurrence (librairie statique vs. librairie dynamique), et Genlib a été une source d'inspiration pour ExtGraph à plusieurs reprises

En effet je n'utilise pas de librairie graphique. Ayant commencé à programmer en TI-basic, et ne programmant rien nécessitant une grande vitesse d'exécution, je m'extasiais régulièrement sur la rapidité des fonctions de l'AMS

Mais à présent que je m'attaque à des outils graphiques plus complexes, je commence à utiliser extgraph (et là l'extase atteint son paroxysme ).

Et bien, qu'est-ce que ça sera devant Genlib.

Je meurs?

Genlib, la librairie qui tue.

(c'est une bibliothèque )

Eh Bovido, on t'as pas sonné !

(bibliothèque c'est plus joli )

Pen^2 (./15) :
(Tu devrais lui dire quelle est la bibliothèque graphique la plus efficace ; perso je ne suis plus très au courant)

Penpen, t'es quand même un chacal de merde

La vache Nil, tu tombes bas, même moi j'avais réussi à ne pas relever. Au prix d'une crise de nerf, ok, mais j'avais tenu bon.

Bah quoi, c'est vrai que je ne suis plus très au courant : j'essaie d'informer les nouveaux au mieux, voilà tout
Et sinon Lepzulnag, as-tu déjà entendu parler des Kernels ?

C'est con, t'avais presque retrouvé ta crédibilité avec la première phrase

Tu peux faire l'innocent

Folco (./12) :
Et pour info, PreOS sauvegarde/restaure 3 lignes sous l'écran pour éviter une partie des désagréments.