blocage des interruptions

**Nebulix** · 20/08/2009, 15h57

Bonjour
J'ai longtemps utilisé des programmes d'acquisition de données de capteurs sous W98 car cet OS permet le blocage des interruptions et donc des "timings" précis. XP l'interdit et mes PC sous 98 commencent à défaillir. Est-il possible de contourner cette interdiction ?
Merci

**Médinoc** · 20/08/2009, 17h23

À ma connaissance, pas sans écrire un driver kernel-mode (les seuls programmes ayant le droit de faire ce genre de chose). W98 était tout simplement trop permissif.

**Melem** · 20/08/2009, 17h34

Ou bien compiler le programme en MS-DOS EXE (il ne devrait pas y avoir de problème si ça a réussi à compiler pour 98 sauf s'il comporte une interface graphique) et l'exécuter sous XP comme ça il sera exécuté sur une machine virtuelle DOS qui le permettra de faire des choses qui étaient possibles dans ce système comme utiliser les instructions INT, IN, OUT, etc.

**Médinoc** · 20/08/2009, 17h51

Je ne suis pas sûr que la VDM accepte de désactiver les interruptions.

**Mac LAK** · 21/08/2009, 07h51

Ou, si elle accepte, ce seront les IT de la VDM qui seront inhibées, mais pas celles d'XP.

Pareil que Médinoc : à part un driver spécifique en mode kernel, ou un patch RT équivalent qui évitera de mettre les mains dans le DDK, je ne crois pas qu'il y aie une solution sur un noyau NT.

**Nebulix** · 30/09/2009, 09h36

Envoyé par Melem

Ou bien compiler le programme en MS-DOS EXE (il ne devrait pas y avoir de problème si ça a réussi à compiler pour 98 sauf s'il comporte une interface graphique) et l'exécuter sous XP comme ça il sera exécuté sur une machine virtuelle DOS qui le permettra de faire des choses qui étaient possibles dans ce système comme utiliser les instructions INT, IN, OUT, etc.

Celà ne marche pas, XP bloque l'instruction.
POur l'instant je me débrouille comme ceci :
J'utilise un vieil ordinateur sous DOS pour interfacer avec le monde "réel".
Pour transférer les données, je les envoie via le port imprimante sur un module de conversion parallèle/USB (merci le fer à souder

). J'obtiens un débit de presque 100koctets par seconde, ce qui me suffit.

**Mac LAK** · 30/09/2009, 09h52

Envoyé par Nebulix

Celà ne marche pas, XP bloque l'instruction.

Logique... Agaçant, certes, mais logique.

Envoyé par Nebulix

J'utilise un vieil ordinateur sous DOS pour interfacer avec le monde "réel".

Pour le DOS, vu que sa seule base requise est le BIOS, tu peux même utiliser un ordinateur "récent", il sera piloté à l'identique.

Envoyé par Nebulix

Pour transférer les données, je les envoie via le port imprimante sur un module de conversion parallèle/USB (merci le fer à souder

). J'obtiens un débit de presque 100koctets par seconde, ce qui me suffit.

Faudrait peut-être voir si, par hasard, un microcontrôleur ne serait pas plus pratique / moins cher pour ton usage, éventuellement sur sa carte d'évaluation histoire d'avoir tous les câblages nécessaires... Ou passer par une carte d'acquisition, qui devrait normalement être fournie avec un driver adéquat résolvant ton souci.

**Nebulix** · 02/10/2009, 16h15

Envoyé par Mac LAK

Pour le DOS, vu que sa seule base requise est le BIOS, tu peux même utiliser un ordinateur "récent", il sera piloté à l'identique.

Oui, mais les anciens ont aussi des "ouvertures vers l'extérieur" faciles à utiliser(port parallèle,...) et je les ai déjà.

Faudrait peut-être voir si, par hasard, un microcontrôleur ne serait pas plus pratique / moins cher pour ton usage, éventuellement sur sa carte d'évaluation histoire d'avoir tous les câblages nécessaires... Ou passer par une carte d'acquisition, qui devrait normalement être fournie avec un driver adéquat résolvant ton souci.

Un système d'acquisition permet d'obtenir des données bien cadencées mais ne permet pas de synchroniser des actions avec des mesures ("software in the loop")
Jusque très récemment les cartes d'évaluation de microcontrôleurs étaient très chères, maintenant il en existe de très abordables. La barrière est le temps nécessaire à la prise en main d'un nouveau système, amplifiée par le doute sur la pérennité d'un système relativement peu répandu.

**Mac LAK** · 02/10/2009, 16h28

Dernière solution : un automate programmable industriel, qui est en général capable d'effectuer une acquisition / commande temps réel tout en ayant des boucles-réflexes logicielles plus ou moins évoluées (du simple paramétrage jusqu'au code C "libre", en passant par un moteur Grafcet)...

**Nebulix** · 12/10/2009, 17h50

Envoyé par Mac LAK

Dernière solution : un automate programmable industriel, qui est en général capable d'effectuer une acquisition / commande temps réel tout en ayant des boucles-réflexes logicielles plus ou moins évoluées (du simple paramétrage jusqu'au code C "libre", en passant par un moteur Grafcet)...

Bien sûr, mais les mêmes restrictions que pour les microcontrôleurs s'appliquent. Il est rageant de constater que la meilleure plateforme soit "verrouillée" ainsi.
Je vais essayer une carte-mère PC104 avec Freedos...
à suivre.