El búfer de rs232 de un PIC18

[migsantiago]

Hola amigos

Mientras estaba diseñando una comunicación para un PIC18F452 mediante RS232 se me llegan a presentar unos que otros errores de comunicación, principalmente por un convertidor externo rs232-ethernet involucrado (tibbo).

Mi duda es la siguiente, ¿el PIC tiene un búfer de entrada RS232? ¿qué tamaño en bytes tiene el búfer? ¿cómo lo limpio usando CCS?

Para leer una letra de lo que hay en el búfer uso la instrucción getc(); pero si el búfer es de más bytes, ¿cómo lo limpio por completo?

Gracias 

[RedPic]

Ufff ... buena pregunta. Creo haber leído en algun sitio que tenían un buffer de 3 bytes solamente, no se si es cierto. De lo que estoy seguro es de que solo se vacia con un getc().

Mi interrupción RDA es ésta y está conectada a un EM202 a 115 baudios y funciona de maravilla:

Código: C++

1. void interrupt_service_rutine_rda(void) {
2.  
3.    if(rs232_errors & 0x04){  // get framing error bit from Rx status reg by Azicuetano
4.       cRxErrorFlag=1;
5.    }
6.    nTOF_for_USART_Timeout=nTimer1_for_max_rec_USART;
7.    USART_nextChar='\0';
8.    if(kbhit()){
9.       USART_nextChar=getc();
10.       USART_add_to_buffer(USART_nextChar);
11.    }
12. }
13.  
14.  
15. void USART_add_to_buffer(char c){
16.  
17.    switch(c){
18.       case 0x0D:
19.          flag_recUSARTComplete=1;
20.          break;
21.       default:
22.          if(USART_nextRec==bytes_for_USART_buffer){
23.             USART_nextRec=bytes_for_USART_buffer - 1;
24.          }
25.          USART_buffer[USART_nextRec++]=c;
26.    }
27. }

[migsantiago]

jeje estaba seguro que vendrías volando a ayudar RedPic

¿entonces cuando hago caracter=getc();... se borran los 3 bytes que hay en el búfer?

Yo estoy usando un DS100B de Tibbo que la verdad me ha dado dolores de cabeza, no con RS232, sino con RS485 y unos monitores de voltaje.

Con el DS100B lo que me pasa es que después de dos horas de comunicación constante por ethernet, mi software en visual basic se empieza a "tropezar" en la comunicación. Quería ver si limpiando el búfer del pic se corregía la situación, pero viendo que con el getc(); se borra todo, me quedo sin ideas 

Gracias Redpic

[RedPic]

Un par de ideas.

El getc() borra lo que lee, o sea un byte. Cada vez que kbhit() es True es que hay algo en el buffer y getc() lo lee y lo limpia. Es constante y mantiene siempre el buffer vacío. Si además tienes activada la int_rda entonces recibes el anuncio de que algo llega y simplemente tienes que leerlo.

Otra cosa, el DS100B falla. Tengo docenas de ellos montados y cuando le parece oportuno, sobre todo como tu dices, cuando lleva muchas horas parece que pierde o la sincronización o algo y pierde la comunicación. A mi me falla sobre todo la Ethernet que el Socket se queda como perdido. Yo en Delphi le tengo puesto que reconecte en el evento OnDisconnect del Socket, salvo que ponga en alto un flag de desconexión y así no intenta reconectar de nuevo.

Comprueba y actualizale el Firmware al DS100B si le hace falta, se le quitan muchas tonterías al cacharro.

[maunix]

¿entonces cuando hago caracter=getc();... se borran los 3 bytes que hay en el búfer?

Relacionadolo con el hardware,

. El pic tiene 2 bytes de buffer + el 3er byte que está entrando por la fifo.  Por ello son 3, pero el 3ro hay que tener cuidado ya que está a "punto" de sobreescribir al 2do... cuidado con eso.

. El getc() lo que hace es leer el RXREG.  Algo asi como a = RXREG;  Al leer el registro RXREG, la microelectrónica del módulo usart moverá el byte del buffer interno al RXREG y del buffer FIFO al buffer interno digamos. 
  RXREG <-- BufferRXreg <-- FIFO

. La función kbhit probablemente esté leyendo el flag RCIF el cual solo se borrará cuando esté vacío el buffer de usart.




/Edit -> corregí el quote jiji.

[RedPic]

¿Lo vés Santiago? Lo que yo te he dicho. Ja, ja, ja 

El Docto Maunix nos lo ha explicado de forma tecnológicamente impecable. Muchas gracias Mauricio. 

[maunix]

¿Lo vés Santiago? Lo que yo te he dicho. Ja, ja, ja 

El Docto Maunix nos lo ha explicado de forma tecnológicamente impecable. Muchas gracias Mauricio. 

Oh, no es para tanto.  Reconozco que me es más fácil responder una pregunta puntual que largarme solo a exponer un tema. 

[migsantiago]

Oh OK! 

Entonces por ahora mi PIC se está portando bien, además si no uso el DS100B, el monitoreo funciona por horas.

El firmware del DS100B lo tengo al día, incluso como en la empresa lo compramos como demo kit, la gente de Tibbo (Jennifer Kuo) ya nos mandó un ticket para ver si el problema tiene solución.

Diego, recordarás que me vendiste un EM202... no he podido probarlo en mi casa, ese lo compré para uso personal; ¿crees que el EM202 tenga un mejor firmware que el DS100B? Hasta donde yo sé, funcionan bajo el mismo engine, pero uno trae estuche y el otro no.

Ah y además estoy usando el DS100B con puerto COM virtual, entonces no puedo hacer mucho con lo de los sockets que mencionas (no sé cómo funcionan).

[maunix]

Una pregunta, qué precio tienen esos Tibbo, tengo entendido que son unos buenos dólares... ¿es así?

Saludos

[migsantiago]

El DS100B nos lo vendieron desde Taiwán en 99 USD en forma de demo kit, con todos los cables y un terminal block para RS485.

http://www.tibbo.com/ds100.php

El EM202 cuesta como 36USD.

[RedPic]

No, amigo Santiago, el EM202 no es el "corazón" del DS100B, el del DS100B es el antiguo módulo EM100 que es bastante mas corto y antiguo que el EM202.

(Y ninguno de ellos tiene nada que ver con el novísimo EM1000 con cuatro USART y 40 pines I/O programables  )

[migsantiago]

Ohhhh

Estoy haciendo un monitoreo de voltajes de baterías en forma remota. Esto es con un PIC18 y RS232, y en la PC Visual Basic y un COM virtual.

Diego, sabiendo de tu amistad con los equipos Tibbo... ¿qué me recomiendas?

- Quedarme con el DS100B y esperar solución del Support Team de Tibbo.
- Pedir un DS202 que tenga como corazón EM202
- Irme con la competencia y buscar otro convertidor que cuente también con COM virtual (Hay muchísimos)

¿Qué tan bueno te ha resultado a través de tantas pruebas que has hecho trabajar con el EM202?

[RedPic]

A mi hasta ahora el EM202 no me ha fallado. 

Y el DS100B sí, no mucho pero me falla.

La combinación incluida en el DS202 no la he probado.

Los equipos que he visto de la competencia, unos italianos, ... los desarmé y ¡¡¡ tenían el EM100 dentro !!!

[migsantiago]

Ah bueno

Entonces voy a ver qué me dicen los taiwaneses y a ver si mi jefe aprueba la compra de un DS202. 

Gracias RedPic y Maunix 

[migsantiago]

Hola

Ya me respondieron los taiwaneses.

Me recomendaron bajar el software beta 5.00.03 de Tibbo. Uno de los problemas que tuve con RS485 fue que el un programa se quedaba trabado cuando intentaba cerrar el puerto virtual de Tibbo. Afortunadamente en la beta 5 se soluciona el problema:

The new Device Server Toolkit (v. 5.00.00-beta) contains the following improvements:

    * Important bug fixes.
          o Under certain conditions (rarely), after the user application software closed, the vsp remain open.
          o Some other virtual serial port software (such as drivers for some blue-tooth devices) interfering with Tibbo VSP, causes TDST unable to create new VSP.
          o Data lost when using Winsock option in VSP Manager.
    * New Tibbo VSP monitor console.
    * New COM object used for manipulating VSPs from user program. There is a VB sample project under \TDST\Samples\VspManVB folder.

Ahí indican tu problema Redpic, que el winsock se hace el que la virgen le habla, pero con la 5 ya no. 

El link:

http://www.tibbo.com/get_dst.php