Problème Windows 16 bits.
 
On utilise une carte A/D ISA dans un PC 486/33 sous Win3.11. Cette carte comporte un circuit Timer programmable Intel (mm circuit que celui du PC). Je le programme pour faire 20 000 mesures par seconde (# oscillo numérique).
 
Le problème vient du fait que si on enregistre une sinusoïde, ça fonctionne très bien, sauf que, par moments, il en manque un bout comme si Windows reprenait la main (pour faire des trucs inutiles à mon goût ).
On est en "Exclusivité à l'avant plan".
 
Y a-t-il une API pour "bloquer" (tuer ) Windows pendant la mesure ? Le problème doit exister en 32 bits aussi ?
 
Mon programme est une boucle qui lit le décompteur du timer pour savoir si le temps est écoulé, si oui, il lit les données quand dispo (mesure faite). J'ai renoncé à voir si une touche était frappée pour interrompre, afin d'avoir une vitesse maximale (en roue libre, elle tourne à 25 000 mesures/s).
 
Y a bien un mode DMA sur cette carte, mais ça m'inspire pas trop pour l'instant . Serait-ce la solution ? Ca peut durer qq minutes.
 
Sinon, je transpose sous DOS avec la mémoire EMS/XMS . Vu que c'est un programme d'acquisition "aveugle", ça gène pas.
 
Si vous avez des idées...

je pense que passer sous DOS c le plus facile, surtout pour ce que tu veux faire.
 
Sous windows y a peut être moyen de jouer avec la priorité du prog mais je connais pas bien l'API 16 bit.

Dans des moments d'égarement , j'ai des fois réussi à bloquer Windows avec un de mes prog en faisant des boucles infinies (erreur sur test final, ...). J'avais jamais la main.
 
L'accès inp() et outp() doit donner de l'air à Win_truc...
 
Y a quoi comme moyen de gérer la priorité du programme sous Win32 ? S'il y avait une API dans la liste qui existât déja en 16 bits .... Quand on défragmente, je sais plus si on peut "basculer vers", ou si on est "bloqué".
 
Mon collègue se contente de ce que je lui ai écrit, mais ça n'est pas très satisfaisant .

on défragmentait pas sous Windows à l'époque c'était sous DOS
enfin y avait des défragmenteurs sous Windows mais la seule fois où j'ai testé ça a planté le PC et flingué une partie de la FAT
Et sous Win32 quand ça défragmente on n'est pas du tout bloqué
 
Pour des trucs "temps réel" je pense pas que Windows/DOS ce soit le mieux Y a QNX qu'est fait pour ça

Je vérifie ce soir que je radote pas (ça commence(/continue), malheureusement). Il me semble que PC TOOLS Windows 2.0 savait défragmenter, mais par rapport à la version DOS, il ne savait plus COMPARER des fichiers : il fallait lancer FC sous DOS .
 
Il me semblait que c'était un défaut de Windows 16 bits : de pouvoir écrire des programmes non "coopératifs" car ils accaparaient tout le temps CPU pour eux s'ils le voulaient. En 32 bits, c'était (pouvait être) plus "convivial", comme sous OS/2 (je collectionne les "vieilleries" )

ouais c'est bien avec le défragmenteur de PC Tools Windows (1.0) que j'avais flingué mon système

Condoléances.  
 
Un de mes cobayes a réussi à perdre C: sous Win95 avec une de mes oeuvres . Pas totalement certain que ça vienne de là . La version 16 bits fonctionne pourtant très bien. Bizarre.
 
EDIT : Je pensais à un moment que de bouger la souris pourrait gêner, je ne sais plus si on avait essayé pr voir effet. Sinon, y a API
BOOL EnableHardwareInput(fEnableInput)
 
BOOL fEnableInput; /* for enabling or disabling queuing */
The EnableHardwareInput function enables or disables queuing of mouse and keyboard input.
 
Je continue à Googler .

 
Tu es sous Win 3.11... Donc, multi-tâche coopératif... Donc, si tu ne coopères pas, personne ne te prendra la main, sauf éventuellement des interruptions... Même pas Windows, c'était d'ailleurs le gros problème de Win 3.1...
Le seul (? je sais plus si les entrées/sorties sous Win3.1 ne rendent pas la main non plus) moyen de coopérer étant de toucher à la file de message, ce que tu ne fais probablement pas, à priori tu n'as pas de problème de ce coté la...
Donc, les seuls explications :
* Tu pompes quand même trop lentement sur ta carte, ou tu n'es pas assez réactif, il y a un buffer qui débordent qques part et tu perds une donnée. ISA, c'est quand même un gros veau   Ca dépend de comment le driver de la carte est fait... S'il faut lire toutes les données une par une sans buffer, c'est un peu violent...
* Tu as un conflit d'IRQ, ou une carte un peu bavarde avec une IRQ plus prioritaire... Comme tu as de l'ISA, et que tu utilises un vieux PC avec un vieil OS, il est probable que plusieurs cartes sur la même IRQ ne soit pas géré... Est-ce que tu as tjs le même problème si tu vides le PC au maximum?

si tu passes sous windows, prends un compilo 32 bits come djgpp (gratuit) ou watcomc, passke sinon le mode réel c'est rapidement caca...

Faudra que j'utilise l'API qui empêche le queuing of mouse and keyboard input, et voir si y a une "fréquence" d'altération.
 
Y a pas de driver pour celle là, c'est une carte ancienne. On lance conversion, teste l'adresse idoine pour savoir si mesure finie, et lit le résultat sur deux octets.
 
Il pourrait y avoir un délai en écriture mémoire (faut que je relise mon code pour voir comment je faisais, huge int ?). Fichiers jusqu'à 120000 points.
 
Pour les IRQ, faut que j'explore. J'ai enlevé la carte réseau depuis assez longtemps (on n'a plus de prises BNC et y a pas encore de RJ45 à cet endroit là).
 
J'utilise Borland C 3.x, ou 5.02.
 
Faut aussi que je vérifie mon code de contrôle du 8254, comme on suit le décomptage (pour passer en négatif quand comptage fini), je rate peut-être une étape de temps en temps. Si y a un micro-délai qui dépasse l'intervalle de mesure, je refais un tour pour rien. Si je fixe fréquence plus basse, si ça passe bien, c'est un excès de vitesse qui cause le pb.
 
Je compte m'y replonger car je ne trouve pas ça satisfaisant. Si je trouve solution (quand manip ne tourne pas), je donne des news. Je vais tâter le DMA, des fois que...
 
EDIT : je vais voir aussi si c'est l'accès à la mémoire qui flanche (en réservant des segments physiques de 64k, et non de la mémoire huge (si c'est ce que je faisais)).