Discussion :

[Transgarp]

Hello,

J'ai un petit programme en BP7 de contrôle d'éclairage de la maison qui écrit et lit direct en mémoire sur l'ancienne plage de carte prototype hex300 à hex302

Tout fonctionne à merveille depuis que j'ai concu cet interface sur mon IBM-PC 8088 sous IBM DOS 5.0 en 1988 qui avait comme langage Basica que j'ai traduit en BP7 en 1990

Cette carte prototype est monté présentement sur un slot ISA d'un P3-800Mhz Asus CUV4X sous W98

Le problème est survenu lorsque j'ai installé XP sur le P3, je n'ai plus accès à la plage de carte prototype. Alors je n'ai pas eu le choix de revenir à W98

Petit exemple de code que j'utilise:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
Procedure Port_Prise(J,X : Byte);
Var I : Byte;
Begin
  Repeat
    Port[$301]:=J+56+X*64; Delay(1); Port[$301]:=J+X*64; Delay(1);
    Port[$301]:=J+48; Delay(1); Port_C_8;
    If Port[$300]=1-X then I:=1 else I:=0;
  Until I=1;
End;

Selon le code, vous voyez bien que ca boucle sans arrêt vu que je ne peu changer les données de l'adresse mémoire.

J'ai su qu'il y a moyen de créer un driver pour faire tourner ce programme sous XP, mais je ne sais pas comment.

Ah oui, depuis que je roule ce programme avec des ordis plus performants que mon IBM-PC, je n'ai pas eu le choix d'insérer des Delay() pour laisser le temps de lire les états de la carte de puissance qui se trouve à 100 pieds de la carte interface de l'ordi.

Pour mes Xeon, c'est une autre histoire, je devrai refaire la carte prototype pour slot PCI

[M.Dlb]

Intéressant

Concernant la programmation sous XP, comme celui verrouille tout (accès direct à la mémoire et au hardware), tu as la possibilité d'écrire un driver pour accéder à ton matériel. D'après ce que j'en sais, c'est assez compliqué et il faut avoir de très bonnes bases concernant la programmation win32 sous XP en général. Mais avec un peu de persévérance ce n'est pas insurmontable

Ah oui, depuis que je roule ce programme avec des ordis plus performants que mon IBM-PC, je n'ai pas eu le choix d'insérer des Delay() pour laisser le temps de lire les états de la carte de puissance qui se trouve à 100 pieds de la carte interface de l'ordi.

Qu'entends-tu par là ? Comme l'ordinateur que tu utilises est plus puissant et plus rapide que ton précédent, les accès au port et à la mémoire sont plus rapides également (tu peux comparer les valeurs des fréquences des bus de données de tes ordinateurs, la différence doit être assez conséquente). Cependant la carte te met autant de temps pour te répondre, si on considère en plus le temps de transfert vers le module contrôlé (ce qui ajoute de la latence supplémentaire). Tu peux utiliser des delays pour temporiser ton programme, le temps que tu reçoives la réponse, comme tu as fait dans ton exemple.

[Alcatîz]

Bonjour !

Voici un lien vers une discussion qui devrait te donner des pistes :
http://www.developpez.net/forums/sho...ighlight=ports

[Transgarp]

j'utilise la commande Delay(1) seulement après avoir écrit dans la mémoire du timer 82C255 qui se trouve à 20 mètres de l'ordi de contrôle pour ensuite lire l'état de réponse.

Du temps de mon IBM-PC8088, nul besoin d'insérer un delay avant de faire une lecture de mémoire après avoir fait une écriture.

Mais sous un ordi puissant, le signal a tout de même 40 mètres aller-retour à franchir et Delay(1) donne une pause de 1 milliseconde, le temps que les TTL-CMOS de la carte de puissance ont eu le temps de faire les modifs et de donner la bonne réponse de lecture.

Dans l'exemple que j'ai donné, si j'écris à Port[$301]:=J+56+X*64; sans donner le temps aux TTL-CMOS de faire leur opérations sur la carte de puissance, la lecture à Port[$301]:=J+X*64; risque d'être erronée

[droggo]

Die,

Le système des délais pour lire un port n'est pas top.

Normalement, on peut vérifier qu'un port a une nouvelle donnée prête à être lue. Il vaudrait mieux boucler là-dessus, d'autant que les délais sont loin d'être garantis côté précisison, ce qui va probablement amener des disfonctionnements aléatoires.

[Transgarp]

droggo,

Regarde le petit code que j'ai placé en début de message.
Il y a un Repeat...Until, on appelle ca une boucle et mon programme contient 5000 lignes de code Pascal du même style

Le big problème est bien simple, avec les nouveaux ordis quand je ne place pas de Delay(1), ca ne sort simplement pas de la boucle en tournant en rond

Anywhay, le truc de ma conception fonctionne sans problème depuis maintenant 20 ans et aucun TTL-CMOS n'a grillé.

Tout roule maintenant sur P3-800Mhz sous W98 depuis 5 ans

Mon interface domotique a passé à travers tous les changements informatique, de Basica à BP7 et C++, de DOS à W98, de IBM-PC à Asus CUV4X-800Mhz, de 1988 à 2008

J'ai résolu tous les petits détails électronique et tout va bien.

En jonglant avec Bureau à distance et UltraVNC j'arrive même à gérer mon système sur n'importe quel ordi de la planète.

J'aurais une balle de moins à jongler si je pouvais rouler l'interface domotique sous XP, vu que 3 ordis de mon réseau sont déjà sous XP et 2003 Server.

J'aime pas utiliser UltraVNC pour gérer à distance l'ordi domotique.

Je souhaite Bureau à distance partout et jeter UltraVNC.

[Transgarp]

@Alcatiz

Un simple exemple de code pour écrire et lire à l'adresse mémoire du port jeu $300 la valeur 45 me serait utile.

Que l'application programmé et compilé en BP7 puisse tourner sous XP

Et surtout comment construire un driver pour cette application.

Pour le reste je saurai me débrouiller.

En attendant, mon système domotique de la maison roule très bien sous W98