Lecto-grabador de tarjetas MMC, SD, MicroSD con PIC

[nutriax]

te enumero las patas viendo los contactos apartir del lado que tiene el chaflan a 45 grados (la mas cerca al chaflan la llamamos pata 1)
pata 1 = dat2 esta esta de mas
pata 2 = cs
pata 3 = di
pata 4 = vss1
pata 5 = vcc
pata 6 = clk
pata 7 = vss2
pata 8 = do
pata 9 = dat1 esta tampoco va
esto seria lo que pude ver, despues tene cuidado al conectarla a la corriente por el voltaje...

 

[jaiser]

Saludos muchachos, tambien estoy en esto de la memoria SD y he avanzado bastante, pero quiero que todos estemos al mismo nivel porque asi avanzamos mas entre todos. Voy a comenzar por mostrar los pines de la memoria SD que tambien pueden reemplazar por una MMC como se llama la libreria en ccs, esto se ve en la imagen adjunta.

Jhonatan tienes mucha habilidad para soldar, pero como dice nutriax no son todos los pines. Fijate en la imagen son solo los pines 1, 2, 5 y 7, tal cual esta numerado en la figura.

Aclarado el punto de los pines y la conexion es importante la forma de comunicacion con la memoria. El protocolo es SPI, el cual puedes simular en el proteus sacando el modulo correspondiente que te muestra la información que estas enviando a la memoria mediante una consola que sale cuando arranca la simulacion, con ella ves tambien los datos cuando logras escribirla.

En cuanto a los comandos hay que explicar bien eso porque cuando uno esta empezando no entiende muy bien eso porque no hay ningun modulo de donde tomarlos.

Los comandos son cadenas de datos que deben enviarse en una secuencia y valores exactos para que logres comunicarte con la SD en su lenguaje. No es tan dificil si usas la libreria de CCS llamada mmc_spi, ella ya trae implementados los comandos en funciones que solo tienes que llamar desde tu programa para que se ejecuten.

Para ver como iniciar la SD descarguen el archivo SD iniciada.rar

Ahora yo ya logre enviar datos a la SD con exito, pero solo datos de 8 bits y necesito enviar datos de 10 bits, lo cual no he logrado aun. Al tratar de enviar los datos de 10 bits los guarda bien pero solo los 8 bits menos significativos, obviamente cuando intento recuperar los datos solo devuelve 8 bits, en un principio pense que era por la consola spi del simulador que solo muestra 8 bits asi que la modifique para 10 bits pero asi cambia completamente la forma de comunicacion y ya no inicializa la SD.

 

[Moyano Jonathan]

Tu información me es de mucha ayuda gracias jaiser y también gracias por el comentario de saber soldar , aunque me falte mucho para llegar a ser "bueno soldando".

 

[jaiser]

nutriax tengo la duda de si en realidad debo preocuparme por la longitud de los datos o cuando implemente el sistema de archivos fat podre resolver esto. Al final lo que espero es poder guardar las cadenas de datos que obtengo con un sistema de control y monitoreo de temperatura de donde obtengo la temperatura asociada una fecha y hora, por lo que los datos son bastante largos, que opinas? Sera que empezamos con el sistema de archivos fat?

Yo tengo una libreria para ccs que estoy comenzando a estudiar, si tienen información sobre eso o experiencia publiquenla.

 

[jaiser]

Una cosa mas en cuanto a la alimentacion de la SD los veo muy preocupados por encontrar un regulador adicional para la memoria, creo que con unas resistencias desde el pic podemos bajar la tension a 3.3v y aunque en la simulacion que publique no aparecen en la conexion real si van. Voy a probar y les aviso.

 

[nutriax]

hola jaiser, todo lo que publicaste excepto la foto ya esta y lo volvi a publicar yo en este foro.
el tema de los comandos esta muy bien explicado tambien en este foro.
y por ultimo el tema de que quieres escribir 10 bit o mas... eso no te preocupes que se soluciona con el fat, y aparte yo explique como maneja la memoria cadenas largas y es el mismo motivo por el cual con el 16f877 se pueden leer unicamente a los 192 byte primeros de cada direccion de memoria... como dije eso ya lo explique yo en unos mensajes anteriores.
ahora mi duda es, podes leer bien la memoria? porque yo puedo inicializarla pero no puedo leerla, me da siempre 00 sea cual sea la direccion que lea, esto no se por que es...
jaiser, aguarda un momento y ayudanos a correguir nuestros problemas asi es como decis vos, vamos a poder avanzar mas rapido todos juntos...

 

[Moyano Jonathan]

yo probé la memoría y al parecer la inicializa bien pero quiero que me indique con un led que lo ha hecho, ahora también me gustaría por ejemplo escribir todo una trama o estring de datos y luego que los lea cada 1 seg y me los mande al puerto d de un pic 16f887.

ya voy a hacer mi propio firmware de control de la sd por que he estado probando con ejemplos del foro pero quiero hacer algo concreto mio cuando tenga más tiempo.

también sigo experimentando con el tema del usb y el protocolo cdc

 

[nutriax]

primero te aconsejo que trates de leer antes de escribir... ami me inicializa pero no me lee ni escribe...

 

[Moyano Jonathan]

No tenés una idea de por que te puede llegar a dar ese problema la sd de no ecribir / leer ?

yo voy a probar el ejemplo de jaiser a ver como me va con la escritura y después veo como me va con la lectura.

cualquier cosa después te comento.

 

[nutriax]

El tema es que jaiser subio la inicializacion unicamente, pero ahi estoy viendo que el usa el el mmc_spi, voy a probar con eso y veo como me va...

 

[Moyano Jonathan]

OK, despúes contame como te fue así vemos que avanze con respecto al tema tenemos cada uno

 

[jaiser]

Saludos, me alegra ver que el tema esta bien animado como dice meta.

La simulacion que publique no solo inicia la memoria SD sino que tambien envia una secuencia de 100 datos que se almacenan en la memoria. Esto puede verse en el modulo SPI_Debug, si observan bien los datos de esa consola veran lo siguiente:

Comando 0:
40 00 00 00 95 Que se envia 50 veces para iniciar la SD
comando 1:
41 00 00 00 00
Comando 16:
50 00 00 00 00
Comando 17:
51 00 00 00 00
Comando 24:
58 00 00 00 00

Cada comando tiene su funcion especifica.

luego se envian una serie de datos del 1 al 100 que son grabados en hexadecimal, fijense en el ultimo valor de la consola es 64h que es igual a 100d.

Creo que con eso estamos listos para el sistema FAT. Que dices nutriax?

 

[jaiser]

Tambien he probado la simulacion cambiando la cadena de datos de 100 a 200 y he comprobado que funciona correctamente. Es importante comentar que solo pueden enviarse datos validos hasta 8 bits, es decir hasta 255 en decimal.

 

[nutriax]

jajaja si eso lo vi despues de que publique mi respuesta... me habia puesto a ver el codigo...
y jaiser.... no te preocupes por los 8 bit.... ya te dije que eso el sistema fat lo soluciona porque maneja bloques de 512byte y si no te alcanza el largo te lo enlaza con una lista enlazada (mas o menos asi funciona el sistema fat, es una burda explicacion porque en realidad es muchisimo mas complejo...).
para ver mira mi post que pongo a continuacion (post 191)
https://www.forosdeelectronica.com/about13868.html
ahora jaiser, esta es mi duda, vos lo probaste con alguna tarjeta para ver si anda?
se puede probar con una tarjeta y despues analizar los datos grabados con el winhex... eso es lo que yo uso...

 

[jaiser]

Ok nutriax yo lo he probado con la tarjeta, no al menos para recuperar los datos, no conocia el programa, explicame un poco como funciona el programa. Como obtengo los datos de la memoria luego de grabarla? Que tipo de interfaz puedo usar?

Acabo de descargar el programa y un tutorial, pero si me das algo de información seguro lo hago mas rapido.

 

[Moyano Jonathan]

lo que no entiendo del todo es que si tenemos un sector de 512 bytes/8 bits (por cada dato), esto querrá decir que podemos guardar 512 datos de 8 bits cada uno en cada sector? si me equivoco diganmen porfavor. Lo que pasa es que he podido inicializarla, pero no se como verificar la escritura y la lectura de la targeta

 

[nutriax]

ok aguanta 2 segundos que ahora en el proximo post te explico, (espera el tiempo que tarde en armar el post aprox 2 minutos) asi te explico bien y de paso le queda a jonathan...

 

[nutriax]

jonathan, si es asi pero el fat utiliza un protocolo muchisimo mas complejo que lo que decis... pero lo que vos decis es valido si no implementas fat y te creas tu propio protocolo como explique en el mensaje 119.
despues podes probar la grabacion como ehora explico...
JAISER y JONATHAN asi se usa el winhex...
primero pueden leer la memoria para saber que datos tiene y despues compararla con los datos que tendra despues de grabarla...
por lo que tendrian algo asi...
primero abrimos el programa y luego vamos a la opcion "tools" -> "open disk"
imagen1 (winhex1.jpg)
con lo que obtenemos la pantalla de imagen 2 (en donde seleccionamos la memoria en mi caso es el disco f
y le damos al boton ok.
y ahora procesa y obtenemos todos los datos de la memoria en hexa y ascii con las direcciones... imagen 3
por lo que por ejemplo en el programa del pic grabamos datos en la direccion desde la 0 a la 100 con el valor de 0 a 100 por lo que tendria que aparecer la secuencia de datos en la direccion de 0 a 100... como en la imagen 4.
logicamente yo en la imagen no lo tengo grabado los datos del 0 al 100 porque no probe el codigo de jaiser, en estos dias veo si lo puedo probar...
espero que se entienda...

 

[nutriax]

me ha durado poco esto... jajajajajajaj yo puedo grabar y leer perfecto...
tengo que pegar unas rebiciones para el tema de la comversion de las divisiones pero es lo de menos...
el problema que tengo es que grabo datos en el sector 300 pero me aparece en el offset 5a00....
segun mi cuenta:
sector 300 *512 Bytes que tiene cada bloque son 153600 bytes.
el winhex me muestra el dato en el offset 5a00 en hexa (en decimal es 23040) y por cada offset tiene 16 byte, lo que seria 368640 bytes. por lo que no me cierran los numeros...
alguien ve el calculo mal hecho?

 

[nutriax]

hoy estoy con todas las pilas.... Empese regularizando la tesis y ahora en dos patadas saque para que lea y escriba...
y ahora recien me doy cuenta cual es el problema de las direcciones... jajajja
el calculo esta mal porque el offset no es una matriz sino una enumeracion es decir que es el dato 5a00
pero eso no queda ahi porque realize el calculo nuevamente y tampoco da...
pero me puse a analizarlo y el tema es que el ccs cuando le paso la direccion me toma 45 en lugar de 300 esto es por el tipo de dato que ocupa 2 byte la direccion (300-255=45).
asi que ya esta solucionado...
ahora me gua a dormir porque estoy fusilado y tuve un dia muy pesado...
asique otro dia sigo con fat...
posteen los resultados que tuvieron ustedes...