Discussion :

[yvesrobert]

Bonjour à tous.

Voici en bref mon problème assez pointu:
Je boote sur une clé USB en DOS 6.22 et je fais tourner une application Turbo Pascal 7. Application "temps réel", ça veut dire que je me fais interrompre par un périphérique externe à des fréquences de plusieurs dizaines voire centaines de Khz. Quand l'interruption arrive, elle doit être désservie dans les quelques µs (oui micro-secondes!) qui suivent. Autant vous dire que ça doit "gazer". Pour ce faire je met toutes les autres interruptions à genou via les masques d'inhibition (port[$21] et port[$A1] des 2 contrôleurs d'Irq).

Cette application tournait à merveille depuis 15 ans sur HDD. Avec l'arrivée de ces fabuleuses clé USB, l'application peut prendre une allure beaucoup embarquée qu'avant... seulement voilà: j'ai mis en évidence que cette configuration m'interrompt tout de même pour des durées de +- 250µs, ce qui représente une éternité pour moi... Tout est relatif!

Selon la programmation de Papa, quand on inhibe à ce point toutes les Irq sauf la sienne, on ne craint rien ni personne. Et bien maintenant c'est foutu, et je cherche à comprendre pourquoi??? Je perd la main pendant 250µs, mon application ne tourne plus pendant tout ce temps et c'est catastrophique!!

J'ai fait un programme test qui va lire en boucle le Timer 0 du PC et qui me donne la statistique après 1 millions de lectures. Le timer fait plusieurs fois le tour évidemment mais j'ai l'habitude de gérer ces valeurs qui repassent de 0 à 65536. Pendant ce temps de test j'inhibe absolument toutes les interruptions via les masques et via Clear Interrupt. Je détourne l'Interruption Non Masquable NMI vers un vecteur nul pour qu'elle ne fasse rien, si jamais...

Et bien volià le résultat: sur HDD l'intervale de valeur entre 2 lectures est très constant et vaut +- 5µs. C'est le temps minimum nécessaire qu'il faut pour aller lire ce timer. Il varie très peu d'un PC à l'autre car il est essentiellement lié au temps d'accès à la puce. En bootant sur la clé USB j'ai 999.977 temps de 5µs et 23 temps "morts" de +-250µs. Donc l'USB m'interrompt pendant tout ce temps. Aucune autre condition n'est changée entre les 2 tests.
J'ai essayé sur plusieurs cartes-mères. A part des valeurs légèrement différentes les résultats sont identiques.

Ma question: comment donc mettre à genou cet USB pendant le temps qu'il me faut pour servir mon application temps réel???

Merci d'avance de toutes vos suggestions...

[denokan]

vu que ton prog est chargé en mémoire au lancement, je ne vois pas trop en quoi le fait de passer sur une clé USB change sa rapidité... je chercherai plutot dans deux sens :
- si tu écris régulièrement dans un fichier (un log par ex) effectivement ca peut ralentir, tu devrai peut-être envisager d'écrire ton fichier à la fin du traitement
- es-tu sûr d'avoir exactement les mêmes fichiers de config sur ta clé que sur ton disque dur ? les memes drivers mémoire, etc ?

[yvesrobert]

Merci de ta réponse.

Oui. Au niveau de la config, c'est effectivement essentiel d'avoir exactement la même chose pour les 2 tests. L'un (clé USB) est le clone intégral de l'autre (HDD). Le config.sys lance le Himem.sys et l' Emm386 avec quelques options, mais cette cause là a déjà été élimininée en désactivant tout ce qui pourrait interférer. Même avec config et autoexec tout nu (je me retrouve en qwerty..) c'est le même prob.

C'est vrai que l'application accède aux fichiers, mais en différé. A un certain moment donné, quand l'utilisateur appuie sur un bouton, le job temps réel se lance et alors là je ne fais plus rien d'autre que de servir les interruptions qui arrivent. Après quelques (dizaines de) secondes, quand le job est terminé, mon programme restaure tout ce qu'il a muselé et l'interface utilisateur, entre autre, reprend son cours normal. Ca redevient un programme hyper classique, respecteux de l'OS comme des milliers d'autres.

Il y a du hardware quelque part qui interrompt la vie du PC de temps en temps, pendant 250µs. Si le contrôleur USB envoyait une Irq classique elle serait muselée comme toutes les autres. Mais il y a autre chose... Mais quoi???
Je sais que le contrôleur USB peut faire de l'accès DMA, mais ça doit, à ma connaissance passer par une routine d'interruption, ou alors j'y perd mon latin et mon grec à la fois??
La gestion de cette clé USB est prise en charge par le Bios puisque je boote dessus. Le problème est de savoir quel hardware peut bien être géré par le Bios pour venir encore me reprendre la main en dessous de la table??
Je n'arrive pas à imaginer quelque chose de plus impérial que les 16 fameuses Irq et qui reprenne ainsi la main de force. Une super-hyper-ultra-interruption???
Il y a quelque chose que j'ignore ...

Merci de vos suggestions à venir.

[M.Dlb]

Peut-être cela vient-il d'un "problème matériel", ou plutôt d'une particularité du système sur lequel tu fais tourner ce programme. As-tu testé sur un autre ordi permettant de booter sur clé USB ? As-tu testé sur d'autres supports comme disquette ou CD ?

[yvesrobert]

Oui. Effectivement. Comme je le disais au début j'ai testé sur plusieurs cartes-mères (3 modèles de 2 fabriquants différents). C'est la même réaction. Sur disquette, c'est aussi bon que sur le HDD. Sur CD, c'est plus dur à réaliser et je ne l'ai pas encore testé.

Merci de votre aide...

[M.Dlb]

Puisque l'USB est effectivement géré par le BIOS, au niveau logiciel je ne pense pas qu'il y ait grand chose à faire, à moins de taper directement dans le BIOS et essaye de bidouiller sa zone mémoire. Comme je n'ai pas ma documentation sous les yeux, de mémoire, il me semble que c'est dans le segment 0040h... Il y a peut-être à changer, mais il ne faut pas se faire trop d'illusions à mon avis. Je vois pas trop d'autre solution sachant que tu as désactivé toutes les interruptions matérielles...

As-tu essayé en bootant puis en enlevant ta clé ? C'est du semi-embarqué comme ça

[yvesrobert]

Merci pour tes suggestions.

J'avais effectivement déjà essayé d'enlever la clé une fois le boot terminé.
En la remettant quelques temps plus tard, l'accès à C: devient impossible (et irrécupérable à moins de rebooter), comme en travaillant sur une disquette qu'on retire au mauvais moment.

Ta mémoire est excellente, la zone de données du Bios est effectivement bien en $40. Je pourrais comparer son contenu avec un boot exécuté sur HDD ou FDD. Mais, à priori, je ne vois pas très bien ce que je pourrais y faire.

Mon raisonnement part du fait qu'une fois les Irq neutralisées, rien ni personne ne peut plus avoir la main sur le µproc à part moi, pour faire ce que bon me semble et puis rendre la main au système au moment où je le décide. Mais mon raisonnement doit comporter une faille que je recherche...

Il y a quelque part une disposition plus importante qui garde la main malgré tout et me la reprend quand bon lui semble. Il faudrait que je la connaisse pour la détrôner et prendre sa place... L'important, je crois n'est pas tellement de savoir quelles données sont manipulées par ce process mais c'est plutôt de savoir comment ce process tourne et comment l'arrêter momentanément.

Je suis en train de préparer une version complètement dépouillée de mon programme de test pour le diffuser sur le forum pour avoir du feedback d'autres machines. Mais pour cela je prépare un pack complet avec le mode opératoire pour préparer une clé bootante pour faire le test.

Merci beaucoup...

[M.Dlb]

Ce ne sont que des suppositions, mais peut-être que le problème vient tout simplement de l'implémentation du contrôleur USB, qui a besoin d'effectuer des opérations à intervalles réguliers. Et comme le BIOS gère ça tout seul, je vois pas trop d'autre solution... A moins d'avoir directment l'accès au code du BIOS mais là ca devient trop pointu Le seul espoir qu'il reste serait qu'il existe un point d'entrée pour désactiver ce contrôlleur temporaireement mais là aussi, il faut avoir LA doc...

[yvesrobert]

Oui. Toute la discussion tourne autour de ça. Le controleur USB aurait-il la possibilité hardware d'arrêter le proc pour prendre la main sur le bus? A vrai dire je ne sais plus très bien comment fonctionne l'accès DMA, mais c'est peut-être comme cela. Ca revient à utiliser une espèce de ligne d'interruption au niveau du proc qui l'immobilise complètement, pendant le temps voulu.

Donc, je devrais trouver un accès au contrôleur USB qui me donne un contrôle sur ce mécansime et me permette à mon tour de le museler, le temps qu'il me faut...

Qui aurait en sa possession des informations hardwares sur les contrôleurs USB embarqués sur les cartes-mères de PC??

Je ne peux pas mettre mon pack complet en fichier attaché car il est trop volumineux (1.3MB). Je ne met donc que le source TP7 du programme test qui s'appelle TMPSMRTS.PAS. et un ReadMe.txt qui est censé expliquer comment utiliser mon pack...

Encore merci de votre aide.

[yvesrobert]

Bonjour à tous.

Voilà, je vous donne quelques nouvelles de mes recherches car elles ont avancé.

1) C'est bel et bien le contrôleur USB qui vole du temps au µproc en l'arrêtant purement et simplement, pendant quelques 100taines de µs, plusieurs fois par sec.

2) Quel fait-il pendant ce temps? Je ne peux imaginer autre chose que du DMA. Quelqu'un a-t-il une autre idée??
Il s'agit vraisemblablement d'un mécanisme de "polling" qui va voir périodiquement si une demande de transaction n'a pas été présentée par le système.

3) Sans doc, il s'agissait maintenant de savoir quelle commande envoyer et à quelle adresse pour tenter de "museler" momentanément ce contrôleur USB, comme on fait avec les masques d'interruption.
J'ai trouvé les adresses en bootant un Win sur la machine, dans le gestionnaire de périphérique. Encore fallait-il que ce soit les mêmes adresses héritées du Bios et non réaffectées par le mécanisme PNP du Win. Pour le coup j'ai eu de la chance! Mais ce n'est pas évident, loin de là.

4) Après ça j'ai tiré au bazooka dans les 4 ranges d'adresses ainsi repérés pour voir si quelque chose bougeait dans le maquis. Et le loup est effectivement sorti du bois. En affinant mon tir, j'ai pû trouvé l'adresse exacte où, en mettant le bit 0 à 0, le contrôleur USB s'arrête d'arrêter le µproc quand bon lui semble...

5) La dernère question est de savoir maintenant quels sont les effets de bord éventuels d'une telle audace!! Hé, bien si on est à la bonne adresse et qu'on ne demande AUCUNE transaction au pseudo HDD émulé par la clé USB, le système ne s'écroule pas et continue à fonctionner normalement.
Ouf! Sinon, ça s'écroule. Fallait s'y attendre...

6) En conséquence, dans mon soft, quand je dois faire tourner ma routine de "vrai temps réel", je fais taire le contrôleur USB, puis après je le libère (bit0 à 1) , question de pouvoir accéder à ma clé USB...

En final, mon problème est résolu PONCTUELLEMENT, mais ceci ne prétend pas du tout être une solution générique. La question de la recherche d'adresse a pû être un peu automatisée sous DOS en faisant tourner un petit soft qui scanne les dispositifs PCI de la machine. Mais parmi les 4 ranges de 32 bytes d'I/O qui sont proposés, il faut encore connaître celui qui corrrespond au connecteur (ou à la paire de connecteurs) USB où est enfichée la clé! Quand on connait le range, il s'agit de l'offset 0.
De plus mon scénario est reproductible sur 3 cartes-mères testées, avec à chaque fois des adresses différentes, fallait s'y attendre...

Pour ne pas trop travailler à l'aveuglette, j'ai déjà cherché sur Internet évidemment, mais je ne trouve pas de doc sur les contrôleurs USB embarqués sur les cartes-mères. De plus je voudrais connaître une adresse mémoire où le range d'adresse du connecteur de la clè est stocké. Ca doit bien se trouver quelque part. Mais en balayant toute la mémoire (1ier méga évidemment) je n'ai rien trouvé. Snif. Il faut encore savoir sous quelle forme peuvent être stockées les data que l'on recherche. Hum. Pas simple.

Quelqu'un aurait-il donc une suggestion?

Merci d'avance de votre aide passée, présente et à venir.