✖ desktop

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

Hola a todos. Estuve leyendo cuidadosamente todos los post, y note que no todos coinciden en cuanto al tamaño de la respuesta R1 que se tiene que esperar por parte de la SD en el proceso de inicializacion y demas.
Algunos dicen que es UN SOLO BYTE; mientras que otros dicen que son TRES BYTES. donde el segundo son los 8 bits del formato R1 y los otros son FFH.
Asi: FF01FFH
Esto dependerá de la marca de la tarjeta?... no creo poque SD es un estandar no?
Por favor quisiera que alguien me saque de esa duda.
Muchas gracias!
 
Hola h22, es un poco lioso segun la documentacion la respuesta es un byte,pero si miras los diagramas de tiempos puede tardar hasta 8 bytes en darte la respuesta y como la salida DO de la tarjeta esta en alto pues cada vez que les un byte lees FF hasta que te llega el 01 y despues de un comando/respuesta hay que enviar un byte extra con lo que lees otro FF, esto se traduce en la practica a que lees FF01FF, pero la verdad es que no hace falta leerlos con que hagas un bucle hasta que te llegue el 01 te da igual que mande 1 que 5 y cuando salgas de el mandas el byte extra pero ya no te hace falta leerlo.espero haberme explicado bien.

Y lo del standar no se, yo estoy haciendo pruebas de lectura y escritura, y con las rutinas que tengo puedo leer y escribir en una kingston pero en una sandisk no.

La diferencia que he notado por ahora es que la kingston en la respuesta a la lectura manda
FF 00 FF FE y la sandisk FF FF 00 FF FE.

Alguna idea de porque puedo escribir en la kingston y en la sandisk no.

Gracias
 
hola
Monly, seguramente debes resetear el pic, por que tu haces la inicializacion directamente desde el pic, y como puedes ver un poco mas arriba, (no se a que se debe) debes mandar dos veces el CMD1, pues la primera vez, la tarjeta envia que se encuentra en IDLE. Intenta enviar el comando 1 una vez, esperar la respuesta, y enviarlo otra vez, seguramente ahi va a funcionar bien.

h22, tal como dicen en todos lados, en realidad la respuesta es una sola R1, los 3 Bytes de los que todos hablan, es por que R1 viene despues de un byte o dos, ya no recuerdo bien. De todos modos se soluciona con un lazo que lea la respuesta de la tarjeta y salte, cuando obtenga la respuesta correcta.

Espero que les haya servido...

Si alguien me puede ayudar con el tema de escritura de la tarjeta estaré agradecido.
 
Hola serchy, ya me inicia sin problemas.

no se que problema tienes escribiendo,te digo lo que hago yo:

activo chip select
mando el comando, por ahora las direccion del sector la pongo directamente
espero en un bucle que me conteste 00, una vez solo, he leido en algun sitio que esperan 3
mando FF
mando FF
mando FE
mando 512 bytes
mando 2 bytes de crc por ejemplo FF
espero en un bucle la respuesta 05, al byte recibido le hago un and con 1f y lo comparo que sea 05
desactivo cs

Como comente en un post anterior con esta funcion escribo en una microsd de kingston,pero no me va en una sandisk.
 
Bueno sigo investigando haber que me pasa con la escritura de la sandisk, he añadido el comando 13 para leer el status de la tarjeta y leo la respuesta r2 y me da dos bytes de 00 00 como que no hay error pero en la tarjeta no escribe nada a alguien le pasa.

He revisado las respuestas de la kingston y es la misma que la sandisk pero no me escribe.

Un saludo.
 
Bueno, al parecer este tema se ha complicado mas de lo debido (sobre todo para los que queremos hacerlo en Assembler), les cuento que despues de leer MUCHO, decidi simular con el Proteus 7.2, aparentemento todo esta bien, el gran detalle es cuando lo pongo en practica.
Lamentablemente no cuento con osciloscopio que seria lo ideal para seguir las señales..Sin embargo AL PARECER inicializa bien mi SD
Pero nunca logro leer datos de la tarjeta

Aqui les dejo mi codigo, espero que sirva de algo para poder asi llegar al resultado deseado...

Nota: disculpenme los comentarios en el programa pero la verdad no soy muy bueno en eso, ademas me parece que es muy sencillo de comprender
 

Adjuntos

  • sd_foro_554.txt
    11.1 KB · Visitas: 304
Última edición por un moderador:
Hola Ettneciv, yo tambien lo estoy haciendo en ensamblador te ayudare en lo que pueda.

He mirado tu codigo asi por encima y he visto algunas cosas, cs lo tienes en bajo antes de mandar los 80 ciclos de reloj y debe estar en alto, las patas de la tarjeta DO y DI deben estar en alto yo tengo DO con una resistencia de pull-pup a 3,3 y DI la pongo en alto por software junto con CS antes de mandar los ciclos de reloj.

Me ha parecido que cuando mandas el comando cmd1 esperas una respuesta 01 y debe ser 00,
la respuesta de cmd0 si que es 01.

de lo que te voy a decir ahora no estoy seguro no se si usas un pic, pero si es asi mira haber las instrucciones de tu pic porque el mio no tiene movfw, es movf nombre,w.

Yo los comandos que uso y me funcionan siempre para inicializar son el cmd0 y cmd1 y luego le envio cmd16 para pone la longitud de bloque en 512, lo intente con los comandos 55 y 41 y no me funcionaban bien.

Hotra cosa que he visto es que no se si estas poniendo el crc en los comandos pero el unico que lo necesita es es el cmd0 , en spi esta desactivado por defecto, con lo que el ultimo byte puedes enviar FF.

el cmd 16 es para poner la longitud del bloque y debe ser por lo menos para escritura 512 bytes tu envias 50 00 00 00 03 FF y eso no es valido tienes que enviar para ponerlo en 512
50 00 00 02 00 FF ,luego cuando envies los comandos de lectura y escritura el ultimo byte de la direccion siempre sera 00, por ejemplo para leer el sector 2 seria 51 00 00 02 00 FF.

Bueno si tienes alguna duda me lo dices e intentare ayudarte.
 
Hola a todos muchachos!
monly, la verdad que no se bien que le pasa a la tarjeta, te comento, la tengo conectada a la pc mediante el puerto serie, de donde envio los comandos y el micro internamente tiene los 512+2CRC bytes a enviar cuando presiono un pulsador (que seria el "dato" a enviar)
Bien. inicializo la tarjeta todo ok , envio comando 24 de escritura, con la direccion 00 00 80 00 indicando el lugar donde empezará la escritura, la tarjeta me responde despues (creo que de dos bytes FF) con 00 indicando que esta todo ok. entonces ahi, envio los datos mas los 2 crc (FF). una vez esto... la tarjeta queda como muerta... no responde, mande lo que le mande, en algunos lados leí que se debe a que en el proceso de escritura no debe detenerse el clock en ningun momento...
Si me podrias mandar tu codigo para que le de un vistazo, me vendria de lujo... MUCHAS GRACIAS.

Ettneciv. tremendo codigo q t escribiste, la verdad es un poco engorroso. no te conviene al menos hasta q pruebes bien el funcionamiento, enviar los codigos uno a uno desde la pc? es solo una sugerencia
 
Última edición por un moderador:
Hola serchy, antes de mandar los 512 bytes de datos tienes que mandar un token de inicio FE

yo envio FF FF FE despues de recibir el 00.

una vez enviados los datos y los bytes de crc tienes que esperar a recibir un 05 (al dato que recibas tienes que hacerle un and con 1f es la mascara, porque en el token de respuesta los tres primeros bits no nos interesan y reultado sera 05), que son datos aceptados y despues de recibirlo puedes esperar a que termine de escribir mandano ciclos de reloj y te ira contestando 00 ( bus ocupado ) hasta que recibas un ff ahi ya puedes deseleccionarla.

La secuencia completa seria:
CS en bajo
enviar comando
esperar en un bucle hasta recibir 00
mandar FF FF FE
mandar 512 bytes de datos
mandar 2 bytes de CRC (FF FF)
en un bucle esperar hasta recibir 05 (datos aceptados) ,antes de compararlo hazle un and con 1f
mandar ciclos de reloj en un bucle y esperar aque recibas datos distintos de 00
CS en alto
yo despues envio el comando 13 que es el status de la tarjeta y contesta R2 que son dos bytes y deben ser 00 00 indicando que no ha bido error, sino te indicara el error cad bit es un error diferente.

Ahora no te puedo enviar el codigo pero pruebalo y sino te funciona otro dia te lo pongo.

Un saludo.
 
Holas gentes....El tema es el siguiente:
Hace un tiempo tome un codigo de este foro para el pic16f876(si mal no recuerdo). lo modifique para el pic18f452 que tiene memoria ram suficiente para leer un sector de 512 bytes. lo simule en el proteus y todo mil maravillas, hasta coloque una imagen de una tarjeta con formato FAT16 y hasta hice un pequeño equivalente del comando DIR.
Pero ahora que tengo el pic"REAL"tengo problemas para leer y escribir la memoria no asi para inicializarla lo cual anda perfecto.
este el codigo que estoy usando para leer:

Read_SD(Sector)
{
int estat;
SD_Adress=Sector*512;

output_high(CS); // Deshabilitamos la SD


// Enviamos un mínimo de 80 clocks para inicializar la SD
for (i=0; i<10; i++) SPI_write(0xFF);

// Habilitamos la Tarjeta SD
output_low(CS);


SPI_write(0x51);
SPI_write(MAKE8(SD_Adress,3));
SPI_write(MAKE8(SD_Adress,2));
SPI_write(MAKE8(SD_Adress,1));
SPI_write(MAKE8(SD_Adress,0));
SPI_write(0xff);
SPI_WRITE(0xFF);
estat=SPI_read(0xFF);
if(estat==1)printf(lcd_putc,"\fHa ocurrido un error al leer");



while (SPI_Read(0xFF) != 0xFE); // Espera aquí hasta que recibimos 0xFE
printf( lcd_putc,"\nRecivi 0xFE");

for (i=0; i<=511; i++)
{

buf = spi_read(0xFF); // Leo 512 bytes

}

printf(buf);


SPI_write(0xFF);
SPI_write(0xFF);

}





La memoria me responde 0XFE y de ahi en adelante nada. Con el oscilocopio puedo que no hay clock despues de recibir 0XFE.
Tengo dos memorias con la SD TOSHIBA 2 GB logro recibir el 0xFE y con MicroSD SanDisk 128MB se inicializa perfecto y de ahi en adelante nada.
POR FAVOR CUALQUEIR AYUDA ME SERIA SUMAMENTE NECESARIA...
SI ALGUIEN LE INTEREZA TENGO INFO DE FAT oficial de Microsoft y otras concluciones que sacado yo.
SALUDOS

:LOL: :LOL: :LOL:
 
hola el codigo de comunicacion con la sd es el que esta publicado en el foro proba_mmc.c aunque para mi sd lo tuve que modificar y aun un sd sandisk no me anda no se bien cual es el tema con eso de las marcas.

Para trabajar con FAT use:

http://homepages.mty.itesm.mx/al778081/ es muy resumida pero da ideas
http://www.ucontrol.com.ar/wiki/index.php?title=FAT_al_desnudo esta esta muy buena en realidad es una traducción de un texto de microsoft con algunos ejemplos buenos.

y luego use el programa Hexplorer para sacar mis conclusiones... tengo pensado hacer una mini guía cunado finalice.

Yo trabaje con fat16 pues la única limitación es la capacidad y para "aparato" que solo almacene datos en txt sobra aunque para hacerlo con Fat32 es minima la diferencia.

Saludos.
 
Última edición por un moderador:
Ya he resuelto parte del problema con la simulacion en proteus. Hace falta un archivo en la carpeta del simulador que se llama "disk.bin2 para poder simular la memoria, el cual viene en la version de proteus 7.2 sp6. Es importante comentar que la version 7.1 sp2 no la trae.

Si tengo avances los publico. Por favor a los web master del foro, hagan lo posible para que el sistema admita subir los archivos de proteus y asi poder compartir las simulaciones tambien. Gracias.
 
hola, si efectivamente el archivo que te solicita es para emular el contenido de la tarjeta y versiones anteriores no las traia, yo con la 7.2 sp6 me anda al pelo, y en estos dias estoy haciendo la plaquita para probar la memoria.
para compartir los archivos del proteus podes crearte una cuenta en www.4shared.com, ahi te dejan subir hasta 4 gigas si no me equiboco, zipeas toda la carpeta de la simulacion del proteus y despues la subis, ese sitio esta bien piola porque no te hace esperar una banda como rapid o megaupload...
me gustaria que comentes como tenes pensado implementar y para que proyecto...
 
hola, veo que tomo vida de nuevo este hilo del foro... :LOL:
bueno, primero alguien sabe si la nota de aplicacion que posteo meta es para implementar el sistema de archivo fat32 con alguna libreria incluida dentro del compilador c18 de microchip? (porque eso es lo que entendi pegandole una ojeada por arriba, despues me pongo a leerlo bien). si es asi habra que traducirlo a ccs asi hablamos en el mismo lenguaje... :LOL:
para el jhonatan que pedia la conexion entre la tarjeta y el pic:
pata de la tarjeta pata del pic
clk-------------------------------------------------sck\scl
DO------------------------------------------------sdi\sda
di--------------------------------------------------sdo
cs--------------------------------------------------int
para el programa que esta en este foro l apata int es la rb0, no puse los numeros de las patas porque varia respecto a cada micro, y cabe aclarar que tiene que ser un micro con isp por hardware, aunque tambien se puede hacer por soft pero a la larga te trae bastante complicacion si queres hacer aplicaciones de mucho volumen de información. tambien a cada pata tenes que agregar el divisor resistivo para adaptar el voltaje.
tambien te aconsejo usar un micro de la serie 18f ya que tiene suficiente ram para poder manejar bien los bloques de memorias y poder implementar fat.
cualquier duda consulta y anda posteando resultados...
yo estoy haciendo las placas para probar y lo quiero implementar con un 18f2550 que es un canio ese micro.
 
Muchas gracias , voy a ver si empiezo a hacer algo con las targetas sd que me tienen tan intrigado , a nutriax ¿ que pic , me decis que tiene isp por hardware? no es i2c o spi?
igual gracias por la respuesta tan rápida .
 
jajaja si parece que se canso y tiro todo al carajo....
bueno jonathan, primero antes que nada i2c no es igual que spi, por mas que microchip utilise internamente componentes en comun, pero no son iguales.
estaria bueno que busques como es el protocolo i2c y el spi para que entiendas mejor la diferencia pero del vamos ya tienen capacidad de transferencias totalmente distintas el i2c llega a 20k mientras que el spi puede llegar mas de 20 megas...
segundo, los pic que implementan spi por hardware son muchos, pueden ser 18f2550 (el que yo voy a usar), el 16f877 que usa el creador de este hilo, el 18f4550, etc. como te dije antes, yo personalmente me tiraria por la serie 18f ya que tienen mas memoria ram, y hasi despues poder implementar el sistema de archivos fat.
cualquier cosa posteen...
 
Hola:

La comunicación del I2C en ASM lo explica muy bien en este libro www.pic16f84a.org mientras que el SPI no tengo idea pero dicen que es mejor.

Los 18F más bien utilizarlo si utiliza C, los 16F si utiliza ASM, si se te ocurre usar el 18F en ASM, más prestaciones tiene ya que puedes ahorrar más códigos dentro del mismo programa, y de memoria RAM, hay de sobra.
Aún así, los 16F se usan más y venden más, con los años veo que cada vez se utilizan más los 18F.

Habrá que enviarle un privado al creador del tema para que se entere que ya hemos hablados unas buenas páginas. Esto es lo que pasa en un proyecto ambicioso.

Un cordial saludo.
 
tiene razon meta, pero tambien tenemos que ser realistas, hoy en dia el que programe el protocolo spi, la comunicacion con la mmc o sd e implemente un sistema de fichero en asm, realmente tiene huevos de oro....
yo ni en pedo me pongo a perder tiempo para este tipo de aplicacion, unicamente utilizo asm en cituaciones criticas y cuando necesito control total de tiempos y de hardware, pero en este tipo de aplicaciones ya tenes todos los protocolos programados en c, simplemente los tenes que usar...
si lo hiciera en asm tardaria muchisimo tiempo (calculo que mas de 100000 lineas de codigo fasil) y obtendria practicamente el mismo resultado. y por lo que salen los 18f... ni lo pienso...
 

Temas similares

O
Respaldo de eMMC en tarjetas RealTek
2 3
Respuestas
40
Visitas
2K
D@rkbytes
D@rkbytes
heidyvanesa19
Proyecto Arduino Reset para Caja de Mantenimiento Canon MC-G02 (G2160 / G3160)
Respuestas
3
Visitas
2K
heidyvanesa19
heidyvanesa19
lazarus666
Problema para conectar pantalla TFT a ESP32 usando SPI
Respuestas
1
Visitas
268
ilkidior
I
zealot2
Sobre tarjeta de split inverter
Respuestas
1
Visitas
206
alicia3213m78
A
H
Delay de nanosegundos ESP32
Respuestas
3
Visitas
901
HOOBE
H
Atrás
Arriba