Recepción multiple por usart

[Picavid]

Hola, estoy trabajando con un 16F876 y necesito recibir mas de un byte a la vez en interrupción. Lo he probado de 1000 formas y no hay manera sin salir de la interrupción. Tampoco puedo definir el nº de bytes a recibir, ya que esto será variable.
  Existe algún flag para saber si RCREG se ha llenado con un nuevo byte?

Saludos,

[Picavid]

OK. Estaba siendo muy exigente con mi Pic.
Necesitaba un pequeño descanso de 5ms.

Usart_Int
   bsf   LedRojo
   call   i2c_start
   movf   RCREG,W
   movwf   a1   ;Para prueba
   call   i2c_write
   movf   RCREG,W
   movwf   a2   ;Para prueba
   call   i2c_write
   call   Retardo_5ms   ;***************sin este retardo sólo lee 1 byte
   btfsc   PIR1,RCIF
   goto   $-5
   call   i2c_stop
   movf   a1,W
   call   Usart_Tx
   movf   a2,W
   call   Usart_Tx
   bcf   LedRojo   
   goto   Fin_Interrupcion

Cuidado: A mi me funciona con 5ms pero tengo la comunicacion configurada a 19200

Saludos,

[elreypic2]

Que tal Picavid,

Bueno que resolviste el problema. Te comento que el USART de ese microcontrolador tiene una caracteristica que se llama FIFO el cual te permite recibir 2 bytes sin antes que exista un "sobreflujo". Esto significa que tu puedes recibir hasta dos datos antes de leer el registro RCREG y efectivamente si existe la manera de saber cuando el registro RCREG ya tiene datos (al menos uno) y tambien saber si ya existio la condicion de sobreflujo y los datos se han perdido.

Dentro del registro RCSTA en el bit 1, es una bandera que te indica que ha existido un sobreflujo y en el registro PIR1 bit 5 (RCIF) es una bandera que te indica que el USART ha recibido un nuevo dato y ete se encuentra en el RCREG. En el datasheet encontraras la mejor info.
Yo he visto y he usado rutinas en donde usando la caracteristica de interrupcion puedes crear un buffer de recepcion de datos de varios bytes dependiendo del micro, por ejemplo he visto rutinas en el que puedes crear un buffer de 64, 128 o hasta 256 bytes. Voy a buscarlas entre mis notas y las publicare tan pronto y me sea posible.

Saludos y espero haberte sido de ayuda.

Elreypic.

[Picavid]

Hola reypic, gracias por la info. Ya sabida y había probado lo de la FIFO, pero tampoco -la doble lectura era igual-. Por cierto el retardo no va con 50ms. Ahora, aún estoy haciendo pruebas, y de momento lo tengo a 500micros. Para unos 10-15 bytes va bien. Veremos cuando llegue a los 1000 bytes... Voy a configurarlo tambien para que me avise si hay sobreflujo. Ya lo tenía pero para hacer el programa mas sencillo, lo desactivé.

  Me pierdo con el tema de los tiempos y me temo que cuando meta una cadena larga, tendré pérdidas y errores. Alguine lo tiene claro y podría dar alguna referencia?

  P.D. El procesador es un 876 a 4MHz y la comunicación con el PC a 19200. El envio por i2c es a una memoria 24lc256. con una velocidad configurada de bus i2c de 100. ¿Alguien ya lo ha hecho?

[Manofwar]

Hola Picavid.

Vamos a ver si yo consigo explicar bien el tema del tiempo.

Tú tienes una comunicación de 19200 bits por segundo. Dependiendo de como realices dicha comunicación necesitarás más bits o menos para enviar un byte. Para una configuración de 8 bits de datos, sin bit de paridad y un bit de parada, los bits necesarios para enviar un byte son 10 bits (1 de inicio + 8 de datos + 1 de parada).

Veamos ahora cuanto tiempo necesitamos para enviar un byte.

19200 bps / 10 bits por byte =  1920 bytes por segundo

1 segundo / 1920 bytes = 0,000520 segundos x byte = 520us x byte

La suma del delay de 500us más el tiempo que invierten las instrucciones anteriores a este es superior a los 520us. Así cuando compruebas si ha llegado otra byte (btfsc   PIR1,RCIF) la respuesta es afirmativa.

Si tienes la posibilidad de utilizar un timer, yo utilizaría este para saber si ha terminado la comunicación usart o no. Aunque utilizar el tiempo como indicador de que la comunicación ha terminado puede dar problemas si esta viene de un PC, ya que el PC dedica un tiempo determinado a cada tarea y si el tiempo dedicado a tu comunicación termina cuando has enviado, por ejemplo, 500 bytes de los 1000 para atender otra tarea, tu PIC entenderá que la comunicación ha finalizado.

Esto sólo es una especulación que quizas tendría que comprobarse o quizas ni tan siquiera afecte a tu firmware por la velocidad a la que trabajas.

[elreypic2]

Que tal Picavid,

Ahora ya me confundi con lo que intentas hacer. Podrias explicar un poquito cual es tu idea de recibir 1000 bytes. Hasta donde entiendo lo que quieres hacer es recibir datos desde una PC hacia el micro y grabarlos en la eeprom externa (24lc256). Pero mi pregunta es porque 1000 bytes o 500? o los que sean necesarios?

Cuando tu usas una memoria eeprom estas tienen un tiempo de borrado-escritura de 5 milisegundos es or eso que cuando realizas la escritura necesitas ese tiempo para que la memoria internamente ejecute la escitura. Ahora bien ese tipo de memoria si mal no recuerdo, tiene un buffer de escritura de hasta 64 bytes, esto hace que puedas escribir 64 bytes en solo 5 milisegundos y no asi usar 64 veces tu rutina de escritura.

Para mi es importante saber que pretendes hacer, te comento porque yo he grabado archivos de tipo texto a una memoria de ese tipo (usando picbasic). Lo que hice fue utilizar la hyperterminal, pregrabo un archivo con 32760 bytes y los transfiero a la memoria. Para ello, lo que hice fue enviar frames de 64 bytes y utilizar la cracteristica del handshaking asi cuando el micro recibe 64 bytes envia a la PC el caracter del XOFF para detener la transmision datos (solo durante 5 milisegundos) mientras realiza la escritura de esos datos. Una vez que se realiza la escritura envia el caracter de XON y la PC continua enviando los datos. Yo use una memoria SPI, pero la idea es la misma, lo unico que cambia es el protocolo, ya que tu usas I2C.

Despues tambien con algunos arreglos use una memoria conocida como DATAFLASH, la AT45DB041B de ATMEL, la cual tiene 4 Mbits y de igual manera genere un archivo de 512KB (524288 bytes) y funciona a la perfeccion. Esta memoria tiene la capacidad de 2048 paginas de 264 bytes cada pagina, pero yo solo uso 256. Su buffer es de 264 bytes tambien por lo que practicamente es lo mismo. La memoria tambien es SPI. Pero en fin, con mas datos de tu parte podremos ayudarte a encontrar la mejor solucion.

Saludos

Elreypic

[Picavid]

Hola y muchas gracias a los dos. Os cuento lo que estoy haciendo:

-Por un lado estoy haciendo un prgrama en VB para "digitalizar" imágenes + texto+ dibujo, etc, sacando el código para ser mandado a una GLCD. (Gracias a BrunoF por la gran ayuda. Hay un hilo en el subforo de visual). Este programa saca el código para cualquir GLCD o LCD y crea un archivo de bytes según funcione la pantalla. Éstas secuencias las quiero grabar en memorias y así, ser una herramienta de trabajo para un futuro. Para ello he hecho un simple circuito grabador: max232-pic-mem. Usé por ignorancia, un 16F876. El motivo: tiene los dos puertos Usart y SSP. La idea con el pic era que a medida que reciviera un byte lo fuera grabando en la memoria. Por eso necesitava tener claro el tema de los tiempos en usart y en i2c. Pero... como bien dices reypic, la memoria necesita un tiempo de escritura entre bytes de 5ms, con lo que, lo que era tan sencillo ya no lo es. Utilizaré tal como dices frames. Provaré el tema del handshaking como comentas.

  Muchas gracias a los dos y ala, ahí voy...

  Saludos,

[maunix]

Un consejo Picavid, las rutinas de interrupción siempre deben ser lo más pequeñas posibles porque sirven para atender algo puntual y se debe devolver el control al bloque principal del programa antes de que sea "demasiado tarde".

No hay forma de recibir 2 bytes sin mediar que se encienda el flag RCIF (y por ende una interrupción si es que la tienes activada).  No es como los módulos usart 16550 de intel que permiten configurar a los cuantos bytes queremos que se encienda el flag (para evitar la tediosa y lenta tarea de vaciar el buffer por cada byte que llega). 

Es entonces que lo que parecía fácil como dices, no lo es tanto y te debes remitir, a mi entender, a recibir varios bytes (en esa dirección te apuntaron ya os colegas Manofway y elreypic2) con algun formato de trama que diseñes tú, que podría hasta contar con algo más complejo como un checksum.

Este buffer tampoco debiera ser muy grande proque el pic tampoco tiene tanta memoria, aunque con el direccionamiento indirecto podrías accesar a 2 páginas con un simple puntero usando el registro SFR. 

Por último te recomiendo que la grabación a la memoria i2c la hagas con el modo "page write" que te permite enviar n bytes (esto depende de cada memoria) seguidos y que se grabarán en el tiempo que te diga la datasheet que es típicamente 5mseg como te han asesorado.

Si todo esto que te hemos ido sugiriendo se te complica y tienes poco tiempo, como solución más veloz te sugiero busques en el foro sobre las memorias ferromagnéticas que salen unos u$s 5 o 6 y se graban sin retardos.  Las mismas son comercializadas por cika.

Saludos

[jel_75]

Hola llegue a este hilo por error, me intereso la tematica y lo lei sin saber nada se usart ni su programacion en ASM.

Pero se   me ocurrio que los conectores RS232 tienen un pin llamado DTR que segun lo actives o no estas avisando si estas listo o no para recibir datos es el pin 4 en un db9 o el pin 20 en un DB25.

Talvez puedas utilizar esto para recibir como decia el compañero 64 bytes en un buffer que crees en la ram del pic deasactivar el DTR grabar la memoria y desactivarlo.

Si tu programa esta hecho en visuual basic este hecho debe ser transparente ya que esto lo maneja la usart del motherboard y si  lo excede supongo que windows.

Ojala te sirva y si me equivoque sali con cualquiera disculpame solo quise ayudar.

[Picavid]

Hola y gracias de nuevo a todos. Ahora mismo tengo el tema un poco aparcado y hasta dentro de unos 10 días creo que no lo seguiré, pero explico: Todas las pruebas ya funcionan tanto de escritura (x bytes) como lectura . Efectivamente el retardo en escritura de la 24lc256 es de 5ms y segun entiendo del datasheet, el nº máx de bytes a escribir seguidos es de 64. En cuanto a la escritura creo que sí, usaré frames de 16 o 32 bytes con control del pin DTR (usando el canal libre del MAX232, como ilustró bruno para un conversor RS232-485. -Que por cierto, fuciona muy bien-).

  Aunque no lo comenté, tenía dudas si se podían usar el módulo usart y el SSP con i2c a la vez, y ya os confirmo que sí, con lo que también se podría trabajar de byte en byte y mandar confirmación por soft o bien creando una temporización paralela en visual basic.

  Creo que con esto funcionará perfectamante. Saludos, y que pasen unas felices fiestas.