TODOPIC

Lenguajes de programación para PC => Visual Basic => Mensaje iniciado por: fastyx en 04 de Agosto de 2006, 11:29:04

Título: Tutorial sobre comunicacion serie
Publicado por: fastyx en 04 de Agosto de 2006, 11:29:04

Amigos : en relacion a lo que estoy haciendo y las horas cul.. :D que estoy consumiendo para mi proyecto,es que estoy armando este tutorial para
0- que me corrijan si pifio
1- aprender
2- compartir el aprendizaje
3- ayudar a optimizar el foro

Ahi voy...arranco con recepcion

de acuerdo a lo leido, la comunicacion serie (en adelante CS) tiene, segun se configure , pero en general como lo uso yo  bytes de comunicacion
constituidos por:

un bit de start
8 bits de datos
un bit de parada
de manera que son 10 bits

en realidad (corrijanme) este byte de comunicacion deberia llamarse pirulo, porque tengo entendido que un byte son 8 bits

entonces la unidad de comunicacion para este caso es el pirulo
Ahora, como reconoce el sistema el bit de start?
la linea esta reposando en un 1 , o nivel alto o como lo quieran llamar. Cuando comienza la comunicacion,el bit de start es el primer bit que va a un nivel bajo,
comenzando el proceso.

me resta conocer cual es la instruccion que detecte el bit de start, creo que deberia ser el on_comm en modo receive pero lo debo chequear

como sabe el sistema cuanto dura 1 bit? pues con los seteos que hacemos del puerto, baudios por segundo, 8 bits de datos, bit de start y stop,
entonces el bit de stop es el ultimo bit del byte que tambien es un de un nivel bajo , que le indica al sistema que ahi termino Pirulo.

si no entra otro byte, despues del bit de stop la linea va a un alto y queda en reposo. esperando otro evento de recepcion.

dentro de pirulo, los bit de datos tambien toman los valores de 1 logico o cero logico, y el sistema seteado reconoce por ejemplo cuando el bit 3 y el bit 4 estan en un uno logico, porque sabe los tiempos que duran los bits en funcion del seteo que hicimos.

cuando entre el otro pirulo, ya el sistema sabe que el proximo bit a nivel bajo va a ser el bit de start del pirulo siguiente ,y a partir de ahi decodifica los unos y ceros presentes en el byte de datos del pirulo ,hasta encontrar el decimo bit que es el de stop.

como organizamos el envio para que la recepcion sea correcta?

en mi caso ,estoy enviando a la pca valores de posicion de un motor,pero es igual el concepto.

si yo quiero decirle al sistema que mando un valor por ejemplo de 47, este vlor usa un byte (ya que es menor que 255)

cuando termina 47, necesito decirle al sistema ahi terminó 47, para despues mandar el siguiente dato supongamos 38.

la tarea de separar 47 de 38 es nuestra ,y el sistema lo interpretara de acuerdo a lo que le digamos, ya que no sabe si nosotros queremos mandar el 47 y despues el 38 , o el 4738.

no confundir el bit se stop de un pirulo con el final de 47 .  para decirle al sistema que termino ese dato ( 47) yo estoy pensando en usar el retorno de carro
de manera tal que actua como separador de datos.

entonces la maniobra seria:

envio de dato
separador
envio de dato etc...

quiero comentarles que todavia no voy a entrar en los ok de recepcion de datos y esas cosas...voy despacio :lol:

Asigancion de lugares para los datos:

en esta parte entran en juego mas seteos del puerto , y aqui necesito la ayuda de ustedes para organizar la informacion

no es lo mismo mandar el valor 47 que el valor 368, ya que los pirulos que usan son distintos. esto es como en el cine: :shock:

el numero de butacas es el numero de lugares(buffer de recepcion) que debo reservar para la gente(datos)

si reservo 5 butacas y vienen 10 personas, tengo perdida de informacion(gente). si reservo mas butacas que gente que va venir ,gasto memoria (pierdo plata)
de manera que conceptualmente conviene conocer cuanta gente va a entrar , para designar las butacas

tengo que chequearlo,pero me parece que el tema de las butacas es el que realiza mscomm1. inbuffersize

contunuara....

Título: Re: Tutorial sobre comunicacion serie
Publicado por: BrunoF en 04 de Agosto de 2006, 19:33:58

Hola fastyx.

La propiedad inbuffersize del control mscomm es la que asigna el tamaño en bytes que serán reservados para el buffer de entrada de datos.
Si asignas un valor a esta propiedad menor al tamaño de los datos que recibes, tendrás una pérdida de datos.
Si asignas un valor mayor al tamaño de los datos que recibes, podrías decir, que efectivamente estas reservando más espacio del necesario sin sentido(o tal vez no, porque podrias optar por no interceptar el evento comEvReceive y dejar que el buffer se siga llenando).

La propiedad RThreshold es la que ocasionará que ocurra el evento comEvReceive. Si seteas esta propiedad a 0, el evento comEvReceive nunca ocurrirá. Si lo seteas a 5, entonces estarás diciendo que cuando se reciban 5 bytes, se producirá el evento comEvReceive.

La propiedad InputLen es la que establece cuántos bytes serán leídos del buffer de entrada.
Ejemplo:

Si estableces:

MsComm1.inbuffersize = 10
MsComm1.RThreshold = 5
MsComm1.InputLen = 2

y esperas a que ocurra el evento comEvReceive para trabajar con los datos recibidos:
El evento comEvReceive no ocurrirá hasta que se hayan recibido 5 bytes(porque RThreshold = 5).

Supongamos que recibes 5 bytes: "ABCDE". Se produce el evento comEvReceive.

En este punto por mas que el inbuffersize = 10 bytes, el buffer de entrada va a ser contener: "ABCDE". Los bytes restantes(5) no se rellenan con espacios.

Supongamos que quieres leer los datos obtenidos.Si haces: MiString = MSComm1.input va a leer sólo 2 bytes del buffer(porque InputLen = 2).Entonces sólo leeras "AB".

Entonces, para leer el contenido total de buffer de entrada, establece la propiedad InputLen a 0.

Adicionalmente al "pirulo" que acabas de bautizar, es posible configurar la comunicación para recibir/enviar un noveno bit. Este es el bit de paridad. Este bit es usado generalmente para comprobar que cada byte recibido es válido. Otras veces, este bit es aprovechado para enviar data adicional sin comprobar cada byte recibido.

Hay muchos eventos adicionales al comEvReceive:

Código: Visual Basic

1. Private Sub MSComm1_OnComm ()
2.    Select Case MSComm1.CommEvent
3.    ' Handle each event or error by placing
4.   ' code below each case statement
5.  
6.    ' Errors
7.      Case comEventBreak   ' A Break was received.
8.      Case comEventFrame   ' Framing Error
9.      Case comEventOverrun   ' Data Lost.
10.      Case comEventRxOver   ' Receive buffer overflow.
11.      Case comEventRxParity   ' Parity Error.
12.      Case comEventTxFull   ' Transmit buffer full.
13.      Case comEventDCB   ' Unexpected error retrieving DCB]
14.  
15.    ' Events
16.      Case comEvCD   ' Change in the CD line.
17.      Case comEvCTS   ' Change in the CTS line.
18.      Case comEvDSR   ' Change in the DSR line.
19.      Case comEvRing   ' Change in the Ring Indicator.
20.      Case comEvReceive   ' Received RThreshold # of
21.                        ' chars.
22.      Case comEvSend   ' There are SThreshold number of
23.                     ' characters in the transmit
24.                     ' buffer.
25.      Case comEvEof   ' An EOF charater was found in
26.                     ' the input stream
27.   End Select
28. End Sub

Un poco más para aprender de RS-232: En el Wiki-PIC (http://elrebujito.es/modules.php?name=Guiki) de Nocturno (http://www.todopic.com.ar/foros/index.php?action=profile;u=2197): RS-232 (http://elrebujito.es/modules.php?name=Guiki&MODE=SHOW&PAGE=RS-232)


Saludos.

Título: Re: Tutorial sobre comunicacion serie
Publicado por: fastyx en 04 de Agosto de 2006, 20:38:36

pregunta: el que "dispara" el commevent es el bit de start del "pirulo"?

de ser asi el rtrheshlold cuando se setea a un valor N le esta diciendo al commevent: disparate en el bit de start del "pirulo" numero N ?

te hago esta pregunta porque en ese caso necesitaria hacer una funcion que vaya seteando el puerto en forma dinamica para datos de longitud variable

Título: Re: Tutorial sobre comunicacion serie
Publicado por: BrunoF en 04 de Agosto de 2006, 21:15:47

Hola fastyx.

Citar

pregunta: el que "dispara" el commevent es el bit de start del "pirulo"?

El bit start de dato creo que genera el evento: comEvDSR.
Te puede servir cuando necesites detectar que "alguien" te esta a punto de enviar algo.

Proba activando la propiedad DTREnable del control MSComm.

Citar

de ser asi el rtrheshlold cuando se setea a un valor N le esta diciendo al commevent: disparate en el bit de start del "pirulo" numero N ?

No te compliques. La propiedad RTrheshold provoca el evento comEvReceive cuando la cantidad de bytes recibidos coincide con el valor numerico que le seteaste al RTrheshold.

Si seguis pensando, como me comentaste, utilizar cadenas de longitud variable, creo que te va a servir mas detectar el fin del mensaje mas que el flag de start del mismo.

Activa la propiedad EOFEnable del control MSComm y envia un caracter ASCII = 26 al final de cada cadena.
Esto va a producir que ocurra el evento comEvEOF.Intercepta ese evento(arriba puse el codigo de todos los eventos posibles) y lee el Mscomm1.input. Fijate si sirve para detectar lo que necesitas y poder asi trabajar con cadenas de longitud variable.

Otra forma es poner el RThresHold a 1, e ir acumulando byte por byte recibido en una variable interceptando el evento comEvReceive. Alli tu decidiar e interpretaras el formato y la accion a tomar dependiendo de la cadena recibida.

Saludos.

Título: Re: Tutorial sobre comunicacion serie
Publicado por: fastyx en 05 de Agosto de 2006, 00:20:24

bruno:podrias decirme como crear esta funcion?

quiero detectar cuantos bytes tiene una variable o cuantos bits cuenta hastaque encuentra el caracter

es como si fuera que posicion ocupa

no se me ocurre como hacerla :lol:

quiero hacer algo analogo a lo de la D de entrada pero con el retorno de carro al final del dato

Título: Re: Tutorial sobre comunicacion serie
Publicado por: BrunoF en 05 de Agosto de 2006, 12:51:40

Hola.

¿Cual de las formas de hacerlo que te comente pensas probar?

Para la primer forma podes probar algo asi:

Cambia el archivo C del PIC, y hace que envie un ASCII = 26("→") al final de la cadena a enviar.

despues, activan la propiedad EOFEnable del control MSComm.

despues fijate si se produce el evento comEvEOF:

Código: Visual Basic

1. Private Sub MSComm1_OnComm ()
2.    Select Case MSComm1.CommEvent
3.    ' Handle each event or error by placing
4.   ' code below each case statement
5.  
6.    ' Errors
7.      Case comEventBreak   ' A Break was received.
8.      Case comEventFrame   ' Framing Error
9.      Case comEventOverrun   ' Data Lost.
10.      Case comEventRxOver   ' Receive buffer overflow.
11.      Case comEventRxParity   ' Parity Error.
12.      Case comEventTxFull   ' Transmit buffer full.
13.      Case comEventDCB   ' Unexpected error retrieving DCB]
14.  
15.    ' Events
16.      Case comEvCD   ' Change in the CD line.
17.      Case comEvCTS   ' Change in the CTS line.
18.      Case comEvDSR   ' Change in the DSR line.
19.      Case comEvRing   ' Change in the Ring Indicator.
20.      Case comEvReceive   ' Received RThreshold # of
21.                        ' chars.
22.      Case comEvSend   ' There are SThreshold number of
23.                     ' characters in the transmit
24.                     ' buffer.
25.      Case comEvEof   ' An EOF charater was found in
26.             Msgbox "La cadena recibida es: " & MSComm1.Input
27.                      ' the input stream
28.   End Select
29. End Sub

para el segundo caso, tenes que hacer lo siguiente:

Setear la propiedad RThreshold a 1 en interceptar el evento comEvReceive.Crea una variable global de tipo string  llamada por ej: TempBuffer

Código: Visual Basic

1. Private Sub MSComm1_OnComm ()
2.    Select Case MSComm1.CommEvent
3.    ' Handle each event or error by placing
4.   ' code below each case statement
5.  
6.    ' Errors
7.      Case comEventBreak   ' A Break was received.
8.      Case comEventFrame   ' Framing Error
9.      Case comEventOverrun   ' Data Lost.
10.      Case comEventRxOver   ' Receive buffer overflow.
11.      Case comEventRxParity   ' Parity Error.
12.      Case comEventTxFull   ' Transmit buffer full.
13.      Case comEventDCB   ' Unexpected error retrieving DCB]
14.  
15.    ' Events
16.      Case comEvCD   ' Change in the CD line.
17.      Case comEvCTS   ' Change in the CTS line.
18.      Case comEvDSR   ' Change in the DSR line.
19.      Case comEvRing   ' Change in the Ring Indicator.
20.      Case comEvReceive   ' Received RThreshold # of
21.                        ' chars.
22.          'Guardar byte recibido en buffer temporal
23.          TempBuffer = TempBuffer & MSComm1.Input
24.           'Buscar si el byte recibido coincide es el retorno de carro que decidiste poner.
25.          'Si lo es, eliminarlo del buffer temporal
26.          if right(TempBuffer,1) = chr(26) then tempbuffer = left(tempbuffer,len(tempbuffer)-1) : Msgbox "Cadena Recibida: " & tempbuffer
27.  
28.       Case comEvSend   ' There are SThreshold number of
29.                     ' characters in the transmit
30.                     ' buffer.
31.      Case comEvEof   ' An EOF charater was found in
32.                               ' the input stream
33.   End Select
34. End Sub

Saludos.

Título: Re: Tutorial sobre comunicacion serie
Publicado por: fastyx en 05 de Agosto de 2006, 14:41:26

La verdad Bruno no tengo ni idea de lo que esta pasando...

si trabajo con variables de 1byte,tengo que poner el rtreshold a 3 para que ande bien,pero si trabajo con posiciones de motor que involucran a variables de 16 bits tengo que poner el rtresdhold en 5, el tema es que no puedo andar cambiando el rtreshold porque necesito leer variables de distinta longitud en la misma grafica.

lo que no se es que si para que entre un dato al puerto este debe tener un valor inicial de rtreshlod o se lo puedo setear variable por variable,mirando que longitud tine primero y luego darle el valor??

desde ya gracias!!!!

Título: Re: Tutorial sobre comunicacion serie
Publicado por: BrunoF en 05 de Agosto de 2006, 15:47:22

Hola.

Tengamos en cuenta que el RThresHold lo unico que hace es generar el evento OnComm-->comEvReceive.
Si estas seguro que el PIC esta enviando sólo 1 byte cuando trabajas con variables de 1 byte tene en cuenta esto:

Si el valor que seteas a RThreshold es distinto a 0, entonces tarde o temprando el evento OnComm-->comEvReceive se va a producir.

Supongamos que cada 2 segundos recibis(envias desde el PIC) 1 byte por el puerto serie.
Si seteas el RThresHold = 3, entonces el evento OnComm-->comEvReceive se va a producir pasados los 6 segundos.
¿Por que? Porque se acumularon 3 bytes en el buffer de entrada y como esta cantidad es igual al valor que le asignaste al RThresHold, se produce el evento.

Por lo tanto, siempre y cuando pongas un valor distinto a 0 en el RThreshold, el evento OnComm-->comEvReceive se va a producir, lo que no quiere decir que vayas a interpretar correctamente la cadena, por ejemplo:
Envias:
1
2
3

cada dos segundos.

Si seteaste RThreshold = 3, recien despues de recibido el "3" se va a producir el OnComm-->comEvReceive.
Vos vas a pensar que en realidad el dato obtenido es 123 cuando en realidad son : 1,2,3 por separado.

Entonces, para salir de toda duda de que el PIC este enviando las cadenas bien, comenza haciendo esto:

Trabaja en el PIC con variables de 1 byte.
Envia 1 byte por puerto serie seguido de un caracter que vos quieras decidir como final del mensaje(si es que no decidis utilizar el ASCII= 26 que es el que usan algunos modems)

Ejemplo: enviá: 1D

En VB setea la propiedad RThresHold= 2
Se tiene que producir el evento OnComm-->comEvReceive en cuanto recibas el "paquete".
Dentro del evento OnComm-->comEvReceive pone:
Msgbox "Recibido: " & MSComm1.Input & ", " & len(MSComm1.Input) & " bytes recibidos"

y asegurate que el cuadro de mensaje que aparece diga:
"1D, 2 bytes recibidos"

Y que no aparezca ningun cuadro de texto hasta el próximo envio.

Una vez que logres esto, estaras seguro que el PIC esta enviando las cadenas bien. Si no recibis lo enviado algo esta mal.

Una vez logrado esto, tenes que setear el máximo común divisor para todos los distintos tamaños de variables que vayas a utilizar.

Por ejemplo: Si pensas trabajar con algunas variables de 1 byte y otras de 4 bytes + la letra "D" cada una, deberas setear el RThresHold = 1.

¿Por que?

Vayamos a los ejemplos para verlo mejor:

El PIC envia una variable de 1byte seguida de la letra D(el Identificador).
Entonces envia: 1D (2 bytes)

Suponiendo que haces como te dije y seteaste RThresHold= 1, el evento OnComm-->comEvReceive se producirá 2 veces.
Lo que tenes que hacer, como ya te comenté, es ir almacenando todo lo que va llegando en una variable temporal. Cuando detectes que te llego el Identificador(caracter D) sabes que es el fin de mensaje y podes procesar la variable recibida.

En el caso de que envies una variable de 4 bytes, haces lo mismo.En este caso el evento OnComm-->comEvReceive se producira 5 veces si tenes un RThresHold = 1.

¿Que pasa si el RThresHold no es un máximo común divisor de las longitudes de las variables a utilizar?
Desastres(errores durante el programa) si el código no contempla muchas cosas que pueden ocurrir.

Supongamos el mismo caso anterior, pero seteando RThresHold = 2.

El PIC envia una variable de 1byte seguida de la letra D(el Identificador).
Entonces envia: 1D (2 bytes)

Ahora, el evento OnComm-->comEvReceive se producirá 1 sola vez.
Esto va perfecto. Pero...

En el caso de que envies una variable de 4 bytes, ocurre el error.
La variable es de 4 bytes + la letra D = 5 bytes. 5 no es divisible por dos. 5/2 no es un número entero.

Entonces el evento OnComm-->comEvReceive se producirá 2 veces en este caso, pero quedará 1 byte(la letra D) almacenada en el buffer, pero el evento OnComm-->comEvReceive no se producirá por  3era vez hasta que...

llegue el próximo dato.

Supongamos que envías ahora una variable de 1 byte+ el ID: envias por ejemplo 2D

En este punto la variable temporal que creaste contiene 4 bytes. La letra D sigue en el buffer pero como no ocurrio el evento, nadie te aviso que esta alli.

En cuanto llegue el "2". Se produce el evento OnComm-->comEvReceive.
Lees y tienes: la variable de 4 bytes + D + 2.
La letra D no ha quedado en la ultima posicion de la cadena como seria lo mas facil. Esto puede traer muchos errores al graficar, y probablemente el programa te tire un : Error 13: Type mismatch.

Ademas, ahora tienes otro byte dando vuelta en el buffer pero que no has captado. La letra D del nuevo mensaje.

Este es el problema de no usar un máximo común divisor para setear el valor del RThreshold.

Saludos.

Título: Re: Tutorial sobre comunicacion serie
Publicado por: fastyx en 05 de Agosto de 2006, 17:49:18

tu explicacion es espectacular!!!!

entonces el rtreshold es una especie de flag, al que tengo que asociar como condicion para el proceso el final de dato(D)

el problema por el cual yo no queria usar el rtreshold de 1 es que no sabia(todavia no lo hice :lol:) como asociarle la deteccion del dato especial de fin de cadena.

una ultima preguntita: ya que en la mayoria de los programas de c se usa el retorno de carro + nueva linea , me gustaria trabajar con ese dato.

tenes idea como lee el visual ese dato enviado por el c?

Título: Re: Tutorial sobre comunicacion serie
Publicado por: fastyx en 05 de Agosto de 2006, 18:36:54

una duda: cuando me haces leer en msgbox el valor 1D, me parece que la sentencia de len.mscomm1.input debe ir primero que la de lectura ,ya que una vez que lo lee se vacia y  la cantidad de bytes me da cero.

si lo pongo al reves ,es decir primero que lea la cantidad de bytes y despues el contenido,ahi lo toma

Título: Re: Tutorial sobre comunicacion serie
Publicado por: BrunoF en 05 de Agosto de 2006, 19:26:58

Hola fastyx.

El retorno de carro en vb es: vbcrlf, pero creo que solo es para escribir, no para leer.

Para detectar si ha llegado el final de carro, suponiendo que vas almacenando byte a byte recibido en una variable temporal(es decir, con un RThresHold = 1) podes hacer:

Case comEvReceive
     Tempbuffer= tempbuffer & MSComm1.Input
     if len(TempBuffer) > 1 then if right(Tempbuffer,2) = Chr(13) & Chr(10) then msgbox "Retorno de carro recibido!"

Explicacion:
     Tempbuffer= tempbuffer & MSComm1.Input

Almacenar el nuevo byte recibido y adjuntarlo a lo recogido anteriormente en una variable GLOBAL que yo he definido como TempBuffer.

if len(TempBuffer) > 1 then....
Esta parte se asegura que la longitud del contenido de TempBuffer sea al menos 2 caracteres, para que no se produzca un error en:

right(Tempbuffer,2) ya que si es menor a dos, tiraria un error.

if right(Tempbuffer,2) = Chr(13) & Chr(10) then msgbox "Retorno de carro recibido!"

Aqui es donde nos fijamos si los dos ultimos bytes recibidos son un retorno de carro.El retorno de carro no es mas que un caracter ASCII 13 y otro 10. Si has recibido un retorno de carro, Se mostrara un cuadro de mensaje.

Destaco que el retorno de carro no es visible en un cuadro de texto, ya que los caracteres ASCII 13 y 10 no tienen representacion grafica(lo que no quita que esten).

Saludos.

Título: Re: Tutorial sobre comunicacion serie
Publicado por: BrunoF en 05 de Agosto de 2006, 19:30:02

Si, es altamente probable que el buffer de entrada se vacie, ya que te habia mencionado que el MSComm1.Input se vacia con simplemente leerlo.
En realidad te conviene siempre descargar el MSComm1.Input a una variable String y despues trabajar con la variable.

Saludos.

Título: Re: Tutorial sobre comunicacion serie
Publicado por: nacha4 en 16 de Agosto de 2006, 20:05:53

hola mi pregunta es si yo quierorecibir 6 bytes y almacenarlos en 6 registros (por ej byte1, byte2, byte3........byte6) para luego compararlos con otros como hago?
no se como continuar el programa

Case comEvReceive
     byte1= byte1 & MSComm1.Input

y me quede ahi no se como sigue por favor ayuda
Nacha4