IOCTL_SERIAL_GET_LINE_CONTROL - Request returns information about the line control set for a COM port
StopBits - 0
Parity - 0
WordLength - 8
#define STOP_BIT_1 0x00
En el terminal tenes que usar:
ÍÑ y no 0xCD 0xD1. Espero que no sea ese el error.
Tambien puede ser que al ingresarlo en el terminal no respondas tan rapido y el pic tenga su propio timer para detectar la "ausencia" de la PC. Pero aun asi deberia de responderte aunque sea los primeros bytes.
Lo que no entiendo mucho es como llega a 0xCD = Í
Usando una calculadora online me da el mismo resultado al pasarlo de hex a ASCII (es decir ÍÑ)
pero luego veo tablas ASCII extendidas y es otro caracter.
Pero deberia andar con ese valor ÍÑ xD
De todas formas lo que interesa es el valor en hexadecimal, la representacion es una ventaja que te da el software y esta representacion no siempre tiene que ver con la realidad, como cuando representa un caracter de control (bel, lf, cr, etc, etc).
Me parece que el que comienza la tranferencia es el PIC
El software solo le dice, configurate asi, mide y envia y cierrate.
CitarDe todas formas lo que interesa es el valor en hexadecimal, la representacion es una ventaja que te da el software y esta representacion no siempre tiene que ver con la realidad, como cuando representa un caracter de control (bel, lf, cr, etc, etc).
Es asi, pero si usas el hyperterminal imagino que poner CD D1 es mandar las letras "C","D"," ","D","1" y no su valor hexadecimal, por eso la importancia que le di. A no ser que use Alt+205 (═) y Alt+209 (Ð) cuando escriba en la terminal.
Lo que si no sabia era el unicode.
CitarMe parece que el que comienza la tranferencia es el PIC
SI yo tambien pense en eso al principio.. leyendo esta parte: Request transfers data from a client to a COM port , Creyendo que el cliente era el PIC, pero no es el PIC es el programa el cliente.
Las pruebas son las siguientes:
Si te fijas usa IRP_MJ_WRITE del driver de MS, el cliente ( programa ) pide al driver que trasfiera esos datos por el COM
Ademas tambien podes ver que pide un IOCTL_SERIAL_GET_COMMSTATU donde figura 2 bytes en cola de entrada
AmountInInQueue - 2
AmountInOutQueue - 0
Y procede con una lectura IRP_MJ_READ
Bueno como que ambos tenemos distintos puntos de vista de como es. Yo voy a dar varias razones por las cuales pienso que estas equivocado.
1- El programa en una computadora es quien debe de abrir la escucha de un puerto y cerrarlo, en PIC no hay forma de que sepa cuando se encuentra activo el programa o cuando tiene abierto el puerto, por lo tanto es el programa quien debe comenzar la "conversacion".
Por un ratito supongamos que es el PIC quien inicia la conversacion, cada unos 10 segundos (para que se note lo que quiero remarcaar) mando el mensaje para ver si se encuentra activa mi PC y rogando que sea el programa para ese PIC el que este usando el puerto serie, si no tengo abierto el programa no pasa nada, pero si yo quiero actualizar lo del programa puedo llegar a esperar 10 segundos desde que lo abri hasta que el PIC comienze a escribirme, ademas me estaria escribiendo muchas veces mientras yo no quiero actualizarlo. Por que hacer un programa para un PIC que mande cada X tiempo si puedo hacerlo mas simple y esperar una llegada de un dato.
Por otra parte si fuera la PC la primera no tendrias ningun complejo como el que nombre, abris el programa, el programa exige los datos, termino de usar el port, lo cierra y listo. Lo volvera a abrir solo y solo si cuando le sea necesario. El PIC esperara por una interrupcion en RX mientras sigue haciendo sus cosas, es lo mas logico y sencillo de hacer.