MMC en modo SPI

[dopoulo]

Mi cuestión es la siguiente:
estoy accediendo a una tarjeta MMC en modo SPI con un pic16f452 pero no controlo mucho todo esto del SPI. Ya he conseguido comunicarme con la tarjeta para leer cosas basicas sobre la FAT. La funcion para enviar un byte a la tarjeta es:


unsigned char SPI(unsigned char d) {
SSPBUF=d;      //Envia un byte a la tarjeta
while (!BF);//Espera hasta que el registro termine la recepcion del dato que viene
return SSPBUF;//Devuelve el dato recibido
}

Segun la libreria que uso cada vez que se quiere leer un byte se usa SPI(0xFF) y ahi surge mi duda. En dicha libreria especifica que son "dummy bytes" (tambien mencionados en el datasheet del pic)

Mi pregunta es por qué tiene que enviarse el valor 0xFF y no otro, si según lo que yo entiendo al enviar un byte se va recibiendo a la vez el que envia el esclavo, es decir no puede influir el byte enviado con el recibido. De entrada tengo bastante comprobado que solo enviando 0xff se obtienen las respuestas deseadas.

¿Que es exactamente un "dummy data" y por qué son usados también para crear retardos?

Eso es todo. Saludos y gracias de antemano.

[kuauhtemok]

Hola yo he trabajado en SPI mucho

Jamas he usado eso de 0XFF y siempre me han jalado bien los circuitos.

Lo malo es que  yo siempre uso ensamblador.... y segun tengo entendido las librerias de C a veces no son compatibles con los modos de SPI q hay.

La RX y TX por ser Full duplex siempre se reciben bytes erroneos. de seguro es ahi donde dices que usas el dummy para recibir el dato correcto. Eso es normal, simpre recibiras bytes erroneos.

Por ejemplo en mi propia experiencia te peudo decir q de tres bytes recibidos dos son incorrectos y el tercero es correcto. yo extraigo este dato con una subrutina... porq siempre pasan dos datos malos y el tercero es el bueno... pero supongo q varia dependiendo del CI q estes usando.

Saludos

[maunix]

Escrito originalmente por kuauhtemok
Hola yo he trabajado en SPI mucho

Jamas he usado eso de 0XFF y siempre me han jalado bien los circuitos.

Lo malo es que  yo siempre uso ensamblador.... y segun tengo entendido las librerias de C a veces no son compatibles con los modos de SPI q hay.

La RX y TX por ser Full duplex siempre se reciben bytes erroneos. de seguro es ahi donde dices que usas el dummy para recibir el dato correcto. Eso es normal, simpre recibiras bytes erroneos.

Por ejemplo en mi propia experiencia te peudo decir q de tres bytes recibidos dos son incorrectos y el tercero es correcto. yo extraigo este dato con una subrutina... porq siempre pasan dos datos malos y el tercero es el bueno... pero supongo q varia dependiendo del CI q estes usando.

Saludos

Si bien no he usado las memorias MMC creo que eso de que recibas 2 datos malo de cada 3... creo que se debe a una mala programación o a un hardware pobremente diseñado!  Si fuera así , nadie usaría el SPI.

Tal vez el inconveniente esté en la interpretación exacta y completa de como funciona el SPI que es una "cadenita" de datos.  Entonces hay que "empujar" los datos para que salga el siguiente y asi.  Si se quiere leer todo de continuo se debe enviar la información correcta en el orden correcto, lo cual puede no tener mucho que ver con lo que se recibe.  El punto es que como se comparte el mismo registro SSPBUF muchos se confunden y mandan un comando para obtener el dato 1... para que salga el dato 1, hay que seguir enviando datos! por ejemplo el comando para sacar el dato 2... mientras se envía el comando del dato 2 se recibe el del dato 1!!  Esta forma de trabajar es muuuuy diferente a la utilizada en la USART y he ahí el mayor inconveniente de muchos programadores a la hora de trabajar con periféricos SPI.

El SPI anda muy bien, yo no he tenido problemas con eso de 2 bytes érroneos de cada 3! jamas!  Eso sí, cuando quiero recibir el último dato de un dispositivo SPI, por supuesto debo enviar "basura" para que el SPI del dispositivo esclavo siga sacando los datos que tiene pendiente! pero ese es otro tema  y además a la próxima vez que quiera enviar un comando, los primeros datos serán también basura (excepto que le haya cargado algo entendible por el IC).

Espero haber sido claro.

[kuauhtemok]

Si tienes razon....

Es q yo usaba el SPI por software y el esclavo me mandaba siempre el dato correcto.

Despues cambie al SPI por el hardware del PIC y ahi es donde tuve problemas... por lo mismo q dices de las caracteristicas del SPI. y aparte el SPI por sofware q hice estaba exactamente diseñado a como dice el fabricante del esclavo (un AD7709)

Mas q nada depende del esclavo q estes usando, en este caso mi esclavo manda dos bytes  erroneos por uno bueno, por eso tiene una señal de dato correcto en uno de sus pines...

pero si depende mucho del esclavo q uses.

[dopoulo]

maunix, precisamente a eso me referia a esos bytes basura. Creo que he dado con la respuesta, buscando por ahí en otros foros en inglés.

me quedaba claro que ese es el byte basura, pero ¿por que ese y no otro?
pues bien, siempre que tenemos que mandar algo a la mmc (comando) el primer bit de un comando debe ser un "0" y yo pensaba que valia con mandar un byte cuyo primer bit fuera un "1", pero no es así, xq la tarjeta está en espera de recibir un "0" en cualquier momento, así es que si cualquier bit del byte enviado es un "0", lo interpreta como el inicio de la rececpción de un comando por parte del pic.

Por eso el byte debe ser 11111111, y ademas es un "byte basura" valido para la aplicacion con la mmc, ya que en otro aplicación dependerá de la forma de los que reciba el dispositivo.
Por lo menos ya he conseguido que funcione ligeramente, la puedo inicializar en modo spi y leo bloques de 512 bytes de la tarjeta.

Gracias.

[maunix]

Escrito originalmente por dopoulomaunix, precisamente a eso me referia a esos bytes basura. Creo que he dado con la respuesta, buscando por ahí en otros foros en inglés.

me quedaba claro que ese es el byte basura, pero ¿por que ese y no otro?
pues bien, siempre que tenemos que mandar algo a la mmc (comando) el primer bit de un comando debe ser un "0" y yo pensaba que valia con mandar un byte cuyo primer bit fuera un "1", pero no es así, xq la tarjeta está en espera de recibir un "0" en cualquier momento, así es que si cualquier bit del byte enviado es un "0", lo interpreta como el inicio de la rececpción de un comando por parte del pic.

Por eso el byte debe ser 11111111, y ademas es un "byte basura" valido para la aplicacion con la mmc, ya que en otro aplicación dependerá de la forma de los que reciba el dispositivo.
Por lo menos ya he conseguido que funcione ligeramente, la puedo inicializar en modo spi y leo bloques de 512 bytes de la tarjeta.

Gracias.

Me alegro que te haya funcionado.  

Realmente es un tema interesante y con mucho futuro esto de memorias de gran capacidad de almacenamiento con un microcontrolador.

Hace unos meses quise encarar un proyecto con estas memorias pero se me complicaba conseguir el socket.  Ahora sé donde conseguirlo pero no tengo tiempo para hacer el proyecto, jajajaa.

[elguitre]

Dopoulo, como estas, mira estoy interesado en aqrmar algo con un 877 vy una memoria MMC, en realidad arme algo pero no logre hacerla iniciar en modo SPI, serias tan amable de pasarme algo de info de tu proyecto? Gracias y saludos

[Ducky]

Hola, la vdd soy un novato en esto de programacion en pic, es por eso que quisiera ver si alguien me podria ayudar en un proyecto con MMC y el pic 16f876A,  quisiera que la MMC guarde lo que yo mande por el puerto serie de la computadora, por ejemplo si mando un "HOLA MUNDO" me guarde la palabra y posteriormente pueda ser leido, se puede hacer eso ???.
Ojala alguien me pueda hechar una manita eh stado checando algunosotroscoments pero no los logro hacer funcionar.