outportb & inportb - Page 1

Salut à tous,

j'essai en ce moment de faire un petit prog pour communiquer avec ma TI, mais ces deux fonctions d'ecriture sur un port ne semblent plus être valide. J'ai fait qq recherches google, mais ca n'a rien donné de productif, d'apres ce que j'ai compris, ces fonctions étaient utilisées avec <dos.h> sous windows et ne sont plus supportées par l'API actuelle, il faut passer par ReadFile etc..., bref reloo.
Sous unix, j'ai rien trouvé du tout, au moins c'est plus rapide.

Donc si qqun sait comment les utiliser, qu'il me vienne en aide ;D
Sous windows ou Unix, ca pose pas de probleme, les deux serait top. ( à choisir, donnez moi la solution pour unix )

thx!

Bien sûr, il suffit que je poste sur yaronet pour trouvre dans la minute qui suit la solution pour unix:
inb et outb avec <asm/io.h>

Mais la question tient toujours pour windows.

Ces instructions sont des instructions privilégiées et ne sont pas utilisables par les programmes utilisateurs.
Jeu, set et match.

Tu es obligé de passer par les fonctions de gestion des périphériques qui vont bien, quel que soit le système, dès lors qu'il y a un OS multiprocessus dessus.

Ouaip je viens de m'en rendre compte que c'est + compliqué que ca, erreur de segmentation inside.
y'a moyen d'avoir qq explications ? Ou au moins un site qui pourrait m'aider. J'ai recuperé la doc TiLP pour le protocole de communication avec la TI.

Edited_3623

Les fonctions pour le port série de Win32 n'ont rien de bien méchant!

Tu n'as que 5 fonctions à connaître:
- CreateFile pour obtenir un handle sur le port com
- SetCommConfig pour assigner les paramêtre de com (bauds, parités etc.)
- ReadFile pour lire ce qui arrive sur le port
- WriteFile pour écrire sur le port
- CloseFile pour fermer le port
Recherche "Serial communications Win32" dans le MSDN library.

Si tu connais C++, je te conseille de faire un classe qui gère les handles, le paramétrage du port et la lecture/écriture.

Sous .NET 2.0 c'est encore plus simple, tout est dans la classe Serial de l'espace de nom System.IO.Ports. Toujours .NET tu pourras t'offrir le luxe de savoir exactement quels sont les ports disponibles pour la com en interrogeant le WMI via une petite requête SQL basique.

Note: les accès directs au hardware sous Windows ne sont plus possibles depuis Windows NT 3... Ce qui est paradoxal, c'est que tu parles d'unix et sous unix, on ne peut également pas accéder au hardware directement. Que tu utilises Windows ou Unix, tu passeras toujours par une HAL et c'est elle qui se chargera de l'accès au hardware quel qu'il soit.

Je ne vois pas l'intérêt de refaire un système de com pour ti sur PC. TI-Connect est tout à fait correct. c'est ré-inventer l'eau chaude...

TI utilise toujours encore port COM???


Cordialement.

Merci, je vais regarder ca.
Le but final n'est pas de refaire un TI-Connect, mais de pouvoir échanger des données avec la calto: j'aimerai utiliser le LCD de la calto pour monitorer mon serveur qui n'a pas d'ecran. ( débit, socket ouvert, uptime, etc...)

Pourquoi ne pas faire un montage tout bete sur le port // ? (un lcd 2/4 lignes en // et quelques boutons, ça coute pas cher, ça se fait en moins de 2 et ça se programme facilement )

Pourquoi tu n'utilises pas les libs de romain lievin ? libticables.

(oui et ça permet d'avoir acces directement (ou presque) a tout les types de cables ^^)

dans ./7 tu parles de monitorer des "sockets" ouverts ou non. Là, tu mélanges les choux et les carottes. Un socket ne peut communiquer avec un port com!!! Les sockets utilisant une adresse IPv4 ou IPv6, je doute fort que la TI utilise aussi le protocole TCP/IP, surtout via le port com.

Un petit rappel pour mesurer le débit: V=D/T et après n'oublie pas de remettre à l'échelle. Le port com utilise des octets comme unité de mesure.

Bonne chance pour ton moniteur.

Ben en parlant de choux et de carottes..... un socket est un concept abstrait représentant l'un des bouts d'un media duplex.
Il peut y avoir n'importe quoi derrière. Du TCP/IP évidemment, mais également :
- de l'UDP/IP
- de l'IPX
- du X25 pourquoi pas ?
- un point de nommage (les sockets de la classe AF_UNIX)
- n'importe quoi d'autre tant que c'est utilisable pour communiquer....pourquoi pas une implémentation RS232 justement ?

ben oui, il peut y avoir n'importe quoi qui passe sur un socket tout comme sur du port com. le tout est de savoir ce qu'on y fait passer.
Comme tu disais, de l'udp, de l'ipx, ou encore des protocoles d'application comme kermit ou xmodem (je l'ai bien fait )

sauf que la, les sockets en question, c'est pas pour dialoguer avec la TI, mais il veux afficher des infos sur les sockets de sa machine SUR sa TI, bref utiliser sa TI comme ecran LCD (un peu cher )

Godzil :
sauf que la, les sockets en question, c'est pas pour dialoguer avec la TI, mais il veux afficher des infos sur les sockets de sa machine SUR sa TI, bref utiliser sa TI comme ecran LCD (un peu cher )

Tout à fait. C'est plus pour le fun que pou autre chose, je n'avais pas allumé ma TI depuis 2-3ans, j'ai eu un coups de nostalgie