Memorias---¿Cual me recomiendan?

[ariel25]

Hola a todos estoy en un poryecto de transmision de datos y tengo un pequeñisimo problema y cual es ese MEMORIAS!!!!
Les cuento:
                   Necesito transmitir un cierta cantidad de datos unos 100k por dia no todo de una ves sino mas o menos 4k por ves (unas 25 veces en el dia claro). El proyecto es el siguiente estoy conectando un pic (16F877a) a un puerto serie lo cual transmite los datos a 9600 bps, lo cual debo capturarlo almacenarlo y luego transmitirlo por SMS a una maquina-computadora cual es el problema...la cantidad de informacion que debo de porcesar antes de transmitir ya que necesito memoria para almacenar todo el dato recibido y he alli las preguntas que me invaden
1- ¿Que memoria usar? ya que estaria recibiendo mas de 1k a la vez es decir a 9600 no me daria tiempo de poder recibir y almacernar a la vez los datos que recepciono ya que para una memoria e2prom el tiempo de escritura es demasiado comparado con la velocidad que recibo (alrededor de 5-10 ms creo!!!! corrijanme si estoy equivocado)
Y una memoria RAM? la verdad es que el tiempo de de escritura de una RAM es mucho menor con la de una e2prom pero el problema es que no conozco ninguna memoria que pueda utilizar con el PIC 16f877a. Agradeceria que alguien me oriente sobre ellas, ya que necesito especificaciones tecnicas y donde conseguirlas
2-¿En transmision serie, que quiere decir control de flujo y como aplicarlo con el pic?...Tengo un muy vaga idea de lo que es......segun tengo entendido mientras se reciben los datos yo podria interrumpir temporalmente la transmision, es decir de un paquete de 100k recibir datos, recibir unos 100 bytes para la trasmision procesar esos 100 bytes y luego seguir recibiendo otro paquete de 100 bytes y asi hasta completar los 100K que es lo que se va a transmitir
(Que alguien me saque de la duda .....y disculpen si dije alguna BURRADA por aqui)
Desde ya muy agradecido por toda opinion y/o sugerencia vertida sobre este tema   
 

[elreypic2]

Que tal Ariel,

Efectivamente las dos opciones que porpones son buenas. Si decides usar una memoria, pudes usar las FRAM, le tiempo de escritura de estas es practicamente 0, pero con la ventaja de que no son volatiles.

La otra opcion como mencionas, es la mas interesante, ya que puedes usar un control de flujo por software en caso de que asi lo desees. Para ello se usan los caracteres XON y XOFF (en una tabla ASCII veras los valores correspondientes a cada uno). Si haces esto te sera mas facil procesar los datos y el flujo de datos. Yo he usado esta tecnica y es muy efectiva.

Saludos

Elreypic.

[ariel25]

Gracias elreypic2 y JCC40 por responder a mi consulta
Antes que nada quisiera saber alguna caracteristica mas especifica de la memoria FRAM, como el precio, donde las consigo porque pareciera ser la solucion a mi problema ya que no son volatiles y si el tiempo de escritura fuera cero es Genial!!!!!...

**********************************************************************************************************************
La otra opcion como mencionas, es la mas interesante, ya que puedes usar un control de flujo por software en caso de que asi lo desees. Para ello se usan los caracteres XON y XOFF (en una tabla ASCII veras los valores correspondientes a cada uno). Si haces esto te sera mas facil procesar los datos y el flujo de datos. Yo he usado esta tecnica y es muy efectiva.
**********************************************************************************************************************
Escrito originalmente por elreypic2

Tengo una pequeña duda con respecto a lo que escribiste!!!!. Como hago el control de flujo por software? Imagino que enviando XON por el TX del pic se detendria la transmision de datos por parte del puerto serial!!. Y asi darme tiempo para procesar los datos y descargarlo en la memoria. Y volviendo a enviar XOFF el puerto serie seguiria transmitiendo el restante de datos que falta!!. Corrijanme si estoy equivocado
Otra cosa que no me queda muy claro es que si esta memoria FRAM es paralela o serie? como es el sistema para comunicarse con ella?

***********************************************************************************************************************
Dependiendo de cómo estructures el programa aún con una memoria FRAM estarías desperdiciando tiempo precioso en la comunicación serial. Yo te recomiendo una memoria RAM paralela.
***********************************************************************************************************************
Escrito originalmente por JCC40


Yo tambien pense en eso JCC40 pero lo que pasa es que no conozco ninguna RAM paralela en especifco, que tenga mas o menos 8K ya que la unica que encontre fue una de 250B mas o menos que era de la Phillips (creo que asi se escribe  ) y era por el sistema de I2C, te agradeceria mucho si me decis alguna que tu conoces o alguien que lea este tema
Pero acaso con una RAM paralela no tendria que tambien invertir tiempo en enviar el dato que acabo de recibir por el RX del pic?

Mi duda es que yo tendria que poder procesar el dato recibido por el RX del PIC es decir, enviar la orden de escritura y poner los datos en el registro correspondiente de la memoria y todo esto antes de que se aparezca el siguiente bytes de datos de lo contrario no estaria transmitiendo todos los datos recibidos ya que algunos datos no los veria!!!!!!!!.
Desde ya muy agradecido por toda opinion vertida sobre este tema

[maunix]

No se qué calculos han hecho pero me parece que una memoria serie es totalmente adecuada.

Creo que la confusión radica en que lees un dato por 1 mseg (9600bps) y el tiempo de grabación de la memoria (que suele estar en 5 y 10mseg)

Ahora la buena noticia es que las memorias i2c y las spi tienen un modo de escritura 'buffer'.  Cuanto más grande la memoria mayor su buffer

La mas modesta puede escribir de a 8 bytes por vez, pero tienes de 16, 32, 64, 128, 256 bytes por vez.  En cuanto? bueno, en el tiempo de grabación.

Osea que si el buffer supongamos es de 16bytes y el tiempo de grabación es de 10mseg (por poner el peor caso), estarías grabando datos a la velocidad de 0,6mseg.  Y por supuesto la comunicación con la memoria no es contínua sino por ráfagas.  Podrias recibir 16 bytes de la usart, y mandarlos a la memoria en un tiempo que sería un instante para tu aplicación. (una i2c con un hardware modesto puede trabajar trankilamente a 100kbps).

Si buscas precio, fijate las memorias de ST.

Saludos

[ariel25]

Bueno desde ya muchas gracias por tu aporte maunix

**********************************************************************************************************************
Osea que si el buffer supongamos es de 16bytes y el tiempo de grabación es de 10mseg (por poner el peor caso), estarías grabando datos a la velocidad de 0,6mseg.  Y por supuesto la comunicación con la memoria no es contínua sino por ráfagas.
**********************************************************************************************************************
Escrito originalmente por Maunix
Lo que pasa es que como tu dices esas rafagas son de 4K mas o menos por vez, si esas memorias  tienen suficiente buffer como para poder almacenar los 4K durante la recepcion en la memoria sin perder ningun dato recibido yo creo que mi problema esta solucionado.....
Agradeceria si alguien me recomienda alguna memoria en especial o que ya haya tenido alguna experiencia con alguna en particular me gustaria poder saber de su experiencia u opinion.
 mientras tanto voy a buscar en google alguna memoria RAM paralela, FRAM o alguna memoria i2c o spi.
Desde ya muy agradecido por todas las opiniones, ayudas, sugerencias, dadas respesto a este tema

[maunix]

A ver si me hago entender.   No hace falta que tengas un buffer de 4K ni en tu memoria , ni en tu pic.

Si el pic lee a 9600bps, 4K datos.  Y tu grabas a 100Kbps en la memoria i2c con 16bytes de buffer, no hace falta hacer nada.

Imaginate que recibes 16 bytes, los guardas en un buffer y lo mandas a la rutina de grabación i2c.  Enviar los datos a la memoria te puede llevar algunos useg, pero supongamos que te lleva 1 mseg.  Si durante ese mseg recibes otro dato, no hay problema porque el buffer de recepción te permite recibir 2 y hasta 3 (con tiempos muy ajustados) bytes antes de que se llene.  Leer esos bytes te demoraría algunos pocos useg y seguirias leyendo 16 bytes mas.  Durante esa recepción de 16bytes, la memoria va grabando los 16bytes anteriores.

Espero se haya entendido.

[RICHI777]

Hola Ariel, algunas cuestiones, lo que dice Maunix es lo mas factible, implementando un buen control de flujo lo resolves, la idea de esto es asi. Vos le decis a la PC cuando estas listo para recibir informacion, si usas control x soft usas el caracter XON, recibis los datos serie lo almacenas en un buffer, cuando el mismo "este" por llenarse mandas un caracter XOFF, el programa en la PC, si lo soporta, detiene la transmicion hasta recibir el caracter XON y asi sucesivamente. Lo mismo pasa cuando usas control x hardware, pero en vez de usar XON/XOFF usas lineas extras ( DTR/DSR o RTS/CTS ). En los momentos que llenas el buffer aprovechas para grabar en la EEPROM. Consulta al programa de la PC para ver si soporta estos controles de flujo.
Una de las cosas que me llamaron la atencion, es que si esto funciona ok y si queres transmitir 100.000 bytes por dia, teniendo en cuenta que la maxima cantidad de datos que podes enviar en un SMS es 160 bytes eso te da aproximadamente  625 mensajes por dia, a un costo de 15 centavos por mensaje aca en Argentina, la cosa te saldria casi 100 pesos por dia !!!!....Recomendacion usar GPRS y hablar con las prestatarias ( CTI, Personal o Movistar ) para contratar servicion de datos unicamente, que te baja bastante el precio para lo que queres hacer...Como último analiza bien la entropia de los datos y trata de meter compresión a los datos a transmitir.
Saludos !

[Renatox_]

Hola RICHI777, la comunicación por software tiene un inconveniente que me ha pasado. Envié un archivo de texto por el hiperterminal con control de flujo por software, y para que funcione correctamente tuve que ponerle un retardo de transmisión entre caracteres, creo que de 10mseg, para que parase la transmisión.

Si no ponía retardo entre caracteres, y el pic le mandaba la orden XOFF para detenerse, el hiperterminal no se detenía en la posición deseada. Entonces esto hace más lento la transmisión.
Con el programa CIMCO también me sucede lo mismo.

Alguién conoce una memoria SRAM serial por SPI, de buena capacidad?

un saludo:

[RICHI777]

Hola es raro lo que te esta pasando, es importante instruir al HyperTerminal para que trabaje con esto, en control de flujo espcificar "XON/XOFF" ...
Salu2!

[ariel25]

Bueno ante que nada quisiera agradecer a todos los que aportaron sus ideas y opiniones
*****************************************************************************************************************
A ver si me hago entender.   No hace falta que tengas un buffer de 4K ni en tu memoria , ni en tu pic.

Si el pic lee a 9600bps, 4K datos.  Y tu grabas a 100Kbps en la memoria i2c con 16bytes de buffer, no hace falta hacer nada.
******************************************************************************************************************
Escrito originalmente por maunix
Disculpe si es que no fui muy claro con mis preguntas pero entendi muy bien el concepto de buffer de una memoria desde la primera vez que me explicaron. Mi duda en realidad era de si tendria tiempo de llenar el buffer ya de 16,32........256 bytes durante la recepcion de y sin perder ningun dato pero ya que me dijeren que transmite a 100kbs yo creo que que lo probare y veremos que ocurre
Desde ya muchas gracias cualquier novedad o duda sobre este tema lo hare saber

*********************************************************************************************************************
Una de las cosas que me llamaron la atencion, es que si esto funciona ok y si queres transmitir 100.000 bytes por dia, teniendo en cuenta que la maxima cantidad de datos que podes enviar en un SMS es 160 bytes eso te da aproximadamente  625 mensajes por dia, a un costo de 15 centavos por mensaje aca en Argentina, la cosa te saldria casi 100 pesos por dia !!!!....Recomendacion usar GPRS y hablar con las prestatarias ( CTI, Personal o Movistar ) para contratar servicion de datos unicamente, que te baja bastante el precio para lo que queres hacer...Como último analiza bien la entropia de los datos y trata de meter compresión a los datos a transmitir.
*********************************************************************************************************************
Escrito originalmente por RICHI777
Tienes toda la razon Richi en esto pero lo que por el momento me obliga a hacer de esta manera es mi ignorancia en GPRS o mi poco conocimiento del mismo...como quieres llamarlo...Esto es lo que me impide embarcarme en esa area por el momento. Pero mi idea es comenzar por lo menos con SMS y luego indudablemente pasarme a GPRS y en realidad la cantidad de Datos a TX lo redujimos solamente a 5K viendo como tu dices desde el punto de vista economico cuando pasemos a GPRS transmitiremos los 100KB

Y bueno sin mas que decir lo unico que me resta es decir ......Gracias a todossssssssss
 

[maunix]

Tienes toda la razon Richi en esto pero lo que por el momento me obliga a hacer de esta manera es mi ignorancia en GPRS o mi poco conocimiento del mismo...como quieres llamarlo...Esto es lo que me impide embarcarme en esa area por el momento. Pero mi idea es comenzar por lo menos con SMS y luego indudablemente pasarme a GPRS y en realidad la cantidad de Datos a TX lo redujimos solamente a 5K viendo como tu dices desde el punto de vista economico cuando pasemos a GPRS transmitiremos los 100KB

Uno de los inconvenientes ariel es que sms no te garantiza un orden de llegada de los mensajes.  Tienen en cuenta eso??

Saludos

[ingeniera_electronica]

hola todos necesito ayuda con un Protocolo por soft o XON-XOFF

Recibir por un puerto serial (RS-232) un archivo de datos utilizando el formato ASCII, a 2400 bps, con protocolo XON/XOFF para control de flujo.
 • Por cada uno de los datos recibidos, descartar los 4 bits más significativos y decodificar los 4 menos significativos como un digito hexadecimal para colocarlo sobre el display, a una frecuencia de 160 Hz (6.25 mseg. entre cada dìgito).

Utilizar un buffer de comunicaciones de 64 datos para no frenar muy seguido la transferencia. Enviar XOFF cuando el buffer esté 75% lleno y XON cuando esté 75% vacío.

me ayudan porfavor gracias