a los que deseen mas velocidad de escritura en las eeprom!

[maunix]

Creo que fastyx se refiere a el tiempo total del grabado desde la PC hasta llegar a la memoria.De ahi salen los baudios que menciona. ¿O me equivoco?

Pero si tiene esa demora, de la PC hasta un PIC , el cual puede estar conectado a una memoria i2c o a una de estas super rápidas, la demora sería la misma en uno y otro caso.

Solo se diferenciarían en el t. de grabado pero el "cuello de botella" estaría en la comunicación y no en el tiempo de demora del grabado de la memoria i2c, ya que entre 'tramas de datos' habría más que 5 mseg que demoraría en grabar tandas de 5 mseg.

Saludos

[fastyx]

es verdad , pero la diferencia entre tener en el cartucho una memoria eeprom comun y una fm25256 marca la diferencia entre 200 segundos y 19 minutos

es correcto esto?

[maunix]

es verdad , pero la diferencia entre tener en el cartucho una memoria eeprom comun y una fm25256 marca la diferencia entre 200 segundos y 19 minutos

es correcto esto?

No, no lo es. 

Supongamos que transferis 128 bytes a 9600 desde la PC al PIC, luego el PIC graba o bien en la memoria i2c común o en la fm25256 a 15Mbps.

Te muestro la secuencia.

1) La PC transmite 128 bytes a 9600 bps .  Es lo mismo que decir que trasnmitirá 1280 bits a 9600bps , lo cual le demorará 133,33 mseg.

2) El PIC almacena los 128 bytes y los transmite a la memoria EEPROM o en la fm25256.

3) El pic comienza a recibir los segundos 128 bytes, los cuales demoran otros 133,33 mseg.  Durante ese tiempo la memoria I2C tuvo tiempo para grabar todos los 128 bytes!! (5mseg o 10mseg de acuerdo al tipo de memoria).   Por supuesto sigo hablando de una memoria de 32KBytes que tiene un buffer de 128.

Es por eso, que no notarías diferencia.

Saludos

[fastyx]

entendi.  o sea que usando el serial le trabo de alguna manera las bondades tanto del spi como del i2c , ralentizando todo el proceso en ese lugar.

Aprovecho para preguntarte donde puedo leer material que me explique la secuencia de recepcion y buffereado del pic con el puerto serie , y de que manera se comunica el pic con el puerto serie para decirle: "espera que tengo el buffer lleno, en cuanto lo vacio te aviso y seguimos"

desde ya gracias!

[maunix]

entendi.  o sea que usando el serial le trabo de alguna manera las bondades tanto del spi como del i2c , ralentizando todo el proceso en ese lugar.

Asi es, el sistema irá a la velocidad del elemento más lento.  En tu caso la comunicación serie.

Aprovecho para preguntarte donde puedo leer material que me explique la secuencia de recepcion y buffereado del pic con el puerto serie , y de que manera se comunica el pic con el puerto serie para decirle: "espera que tengo el buffer lleno, en cuanto lo vacio te aviso y seguimos"

desde ya gracias!

Lo del buffer del pic no tiene mayor misterio.  Si trabajas en C tenes que hacer un array y lo vas llenando a medida que vas recibiendo los bytes.

En cuanto a lo otro es lo que se llama "control de flujo", lo podes hacer por hardware o por software.

Por hardware sería usando la señalización CTS, RTS, DTR y DSR.  Por software sería por ejemplo, que el pic le responda a la PC recién cuando haya terminado de enviar los datos a la memoria.

[Chaly29]

Exacto fastyx, as anotado un punto, 

Un saludo.

[fastyx]

que comandos se usan para que el pic le diga a la pc espera que no vacie el buffer?

[maunix]

que comandos se usan para que el pic le diga a la pc espera que no vacie el buffer?

fastyx, te lo dije 2 posts más arriba.  Hay muchas formas de hacer esto, y te puse que leas un poco por internet para que "comprendas" como es el tema más allá que luego decidas una u otra forma de hacerlo.

Control de flujo por software: Puedes usar el sistema XON/XOFF o bien hacer tú mismo un "protocolo" donde la PC espere cierto comando que le indique "manda de nuevo".

Control de flujo por hardware: usando la señalización CTS, RTS, DTR y DSR. 

Es un tema extenso y en internet está lleno de explicaciones del tema.

[fastyx]

Mauricio: desde ya te pido disculpas por la poca experiencia que tengo para buscar sites calificados en Internet,  te aseguro que lo que mas hago es leer y leer y leer .  El tema es cuando encuentro una pagina que habla sobre handshake , no da informacion ( o yo no la encontre) sobre que hace especificamente un dtr o cts , es decir si pone un pin del db9 en un estado determinado , por otra parte en el manual del pic18f452 no existe informacion ( o me la pase por alto) acerca de com maneja el pic la "conversacion " con dichas señales.

Si tenes algun sitio en particular que hable sobre esto , te voy a agradecer que me lo comentes.

muchas gracias y mil disculpas de nuevo por la ignorancia

[maunix]

Mauricio: desde ya te pido disculpas por la poca experiencia que tengo para buscar sites calificados en Internet,  te aseguro que lo que mas hago es leer y leer y leer .  El tema es cuando encuentro una pagina que habla sobre handshake , no da informacion ( o yo no la encontre) sobre que hace especificamente un dtr o cts , es decir si pone un pin del db9 en un estado determinado , por otra parte en el manual del pic18f452 no existe informacion ( o me la pase por alto) acerca de com maneja el pic la "conversacion " con dichas señales.

Si tenes algun sitio en particular que hable sobre esto , te voy a agradecer que me lo comentes.

muchas gracias y mil disculpas de nuevo por la ignorancia

Te cuento brevemente porque ando bastante atareado últimamente.

El 18F452 es un microcontrolador que implementa una USART.  Un módulo de comunicación serie síncrono/asíncrono por 2 pines. 

El RS232 es estándar que define la capa física (niveles de tensión) de una comunicación serial (uart) entre un equipo de envía y otro que recibe.  Cuando usas un PIC con un MAX232 y solo usas TX/RX simplemente estas usando la capacidad UART del RS232 y el control de la comunicación "quien origina y quien recibe" se hace por software. 

Por ej, por software le envías algo al pic y este te responde diciendo un caracter o trama que signifique "ya lo recibí".  Si no te responde en un cierto tiempo (denominado "timeout"), la PC lo vuelve a enviar.

En cuanto al control por hardware esa indicación de "ya estoy listo para recibir" o "estoy listo para enviar" lo hacen las señales CTS, RTS, DTR, DSR.  Con esas señales se indican mutuamente si se debe enviar o no un dato o si se está listo o no.

Tal vez debas buscar información sobre RS232 más que sobre control de flujo.

Te dejo un link que te servirá como punto de partida

http://www.camiresearch.com/Data_Com_Basics/RS232_standard.html

[fastyx]

Gracias por el link , clarificó mucho sobre el manejo de handshake. Lo que finalmente queria saber era que poner un uno o un cero logico en esos comandos paraba la transmision o la restituia. Ahora si estoy en condiciones de fabricar el transito ente puerto serie---pic---memoria.

[maunix]

Gracias por el link , clarificó mucho sobre el manejo de handshake. Lo que finalmente queria saber era que poner un uno o un cero logico en esos comandos paraba la transmision o la restituia. Ahora si estoy en condiciones de fabricar el transito ente puerto serie---pic---memoria.

Me alegro que hayas entendido con mi breve descripción pero sobre todo con el link!

Cuando veas en el PC, verás que si pones un BAJO en el PIC por ahi la señal se pone en ALTO LOGICO y viceversa. 

Trata de conseguirte algún software que te muestre en la pantalla el estado de cada línea, así sabrás bien si estas generando correctamente las señales.

Un soft es el SIOW que viene con el CCS y es muy práctico y fácil de usar.

Saludos

[fastyx]

Gracias por contestar. Valoro qu a pesar de estar ocupado , te hagas tiempo para ayudar.

efectivamente , el siow me ayudó cuando descubri  las lucecitas de abajo que representaban los estados de las maniobras de handshake, si es que estas se elegian en las opciones.