Visual Basic.net 2008 y puerto serie

[Ediolot]

Buenas, estoy haciendo un pequeño proyecto con un amigo y hemos encontrado un problema que no logramos resolver. Cuando su programa (Hecho en vb.net 2008) envía datos al pic a través de un puerto serie, puede enviar cualquier valor del 0 al 255 (como resulta obvio). Sin embargo, no resulta tan útil cuando es el pic quien envía la información. Para hacer pruebas y simplificar los posibles errores, he conectado el pickit 2 a modo de UART (viene con esa opción) directamente al com11 (puerto que estamos usando). En consecuencia, es como si tuviera 2 puertos serie funcionando, uno de ellos es el que usa su programa y el otro, el que usa el pickit 2 y puedo controlar y ver todo lo que envió o recibo en hexadecimal. En este caso, la transmición vuelve a funcionar perfectamente, pudiendo enviar cualquier valor desde su programa hasta el pickit 2, por el contrario cuando el pickit envía algún valor, él lo interpreta como un código ascii, limitando mucho el numero de valores que podemos enviar 0-128. Su programa utiliza el componente SerialPort y no una dll aparte.

Por lo tanto la recepción del ordenador no es nada efectiva y molesta mucho, limitando las capacidades de las que disponemos. ¿Conocéis alguna forma de solucionarlo?

Gracias

 

[cargamsoft]

Estimado que instrucciones utilizas para la comunicacion? Cuando tú envias un dato del PIC hacia el VB.net lo que estas enviando es un caracter, no un numero, el compilador se encarga de tx su respectivo codigo ascci. En ningun momento se envia un numero como tal (int, float, etc) se envian caracteres por lo tanto tu codigo en VB debe estar preparado para devolver ese valor en ascii al valor original.

Ayudaria mucho si pusieras tus codigos...

saludos

 

[Ediolot]

lo que estas enviando es un caracter, no un numero

Que yo sepa lo que se transmiten son 1 y 0. Envias el/los bits de "Start", despues el byte de la información y por ultimo el bit de parada o "Stop" bit, entonces en el PIC puedo decirle envia un 31 y el lo que va ha enviar es: (sin bit de paridad)

(START bits) 00011111 (STOP bit), entonces lo que pasa por el cable y llega al buffer si es un 31, el problema es que cuando lees el buffer puedes interpretarlo como un codigo ascii, en ese caso aparecerá el numero 1 en pantalla, y si lo interpretas como un entero de un byte aparecerá un 31 en la pantalla. Por lo tanto no puedo enviar un caracter, envias un NUMERO que es interpretado como un caracter, y al escribir en pantalla una variable de tipo char en vez de de tipo int, pues busca la equivalencia entre el valor y su símbolo. (Wikipedia: "el ASCII es un método para una correspondencia entre cadenas de bits y una serie de símbolos (alfanuméricos y otros)").

De hecho, despues de seguir buscando toda la tarde y noche, hemos encontrado una funcion ( Serie.ReadByte() ) que lee el byte en la memoria sin interpretarlo como un carácter.


Ahora mismo no estoy utilizando el PIC, lo que estoy haciendo es el UART del pickit 2 como puerto COM, en el cual puedo ver todo lo que envio y recibo, no en ascii, sino en hexadecimal (no esta en decimal porque ocupa más espacio y queda mas sucio) y este programa que controla el pickit 2 de Microchip esta programado en vb, lo denota su icono.

El nuevo problema es que es muy lento recibiendo, tanto que pierde datos en medio. Y comparando velocidades, me parece muy extraño que reciba mucho más lento un ordenador que el PIC con solo espacio para dos datos en el buffer y un reloj a 4Mhz

 

[cargamsoft]

Estimado, no has entendido la idea o parece que te ofende lo escrito anteriormente. Esta demas tu "clase" sobre tx RS-232 porque eso es algo que se asume de comun conocimiento. Has malinterpretado mi mensaje.

Efectivamente, existe la instruccion que mencionas en VB. Trabajo con esa instruccion hace mucho. Solo que lo que tu crees que estas recibiendo como numero, es en realidad un caracter es asi de simple. aunque lo veas como un numero, no deja de ser recepcionado como un caracter.

 

[Ediolot]

Gracias por explicarme mejor que trataste de decirme en el primer mensaje, y te agradezco tu ayuda. Al parecer, no interpreté bien la respuesta. Ahora entiendo lo que dices y espero que entinadas lo que dije, porque estábamos defendiendo la misma idea :S . De todas formas mi compañero ya ha encontrado l solución al problema entero. Gracias