pues es un thread muy interesante ese.... de momento me estoy haciendo con el serial monitor a ver si consigo echar un poco mas de luz en el tema.
De todas formas, y aparte de esto, a ver si me puedes confirmar esto: creo que podría estar teniendo problemas derivados que el famoso dispositivo (a la sazón, actua como DCE, vamos, es un modem) tiene un puerto serie "como dios manda", con sus pines RTS/CTS y DCD/DTR. Sin meterse en mayores complicaciones, el PIC como sabes es capaz de darle la RX, TX y la GND.
Independientemente del tema del eco, me he dado cuenta de otra cosa. Cuando tengo "pinchada" la conexion con el DB9 para espiarla, los caracteres llegan al dispositivo y este responde sin problemas. Pero cuando no pincho con el db9, el dispositivo es capaz de RECIBIR, pero no de RESPONDER al PIC.
Y esto sospecho que es por que las señales RTS/CTS y DCD/DTR del dispositivo quedan "flotando". Y esto creo que me podría estar dando problemas en la comunicacion.
Según he leido de RS232, bastaría - en principio - con conectar en el DCE los pines DTR-RTS , y conectar ambos a un "1" logico permanente... es esto así, o no es el null-modem que necesito en esta ocasion?
De hecho, mi teoria - de momento - para explicar que el dispositivo responde cuando el DB9 está pinchado, es que el puerto serie del PC sí que está proporcionando las señales que el dispositivo espera encontrar ( RTS/CTS, etc. ) y que por lo tanto el dispositivo puede iniciar la respuesta.
Cuando sólo está conectado el pic, como sólo le proporciona gnd, tx y rx, pues parece que no inicia la respuesta ( eso sí, he comprobado que el dispositivo recibe perfectametne el comando a traves de su RX, es solo que no es capaz de respnoder con el "OK" que debe salir a traves de su TX).
Como crees que debería cortocircuitar los pines que no uso del DCE para emular un control de flujo adecuado por hardware, sin tener que meterme a programar un control de flujo en el propio codigo del pic?
gracias y un saludo,
pollastre
