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

si justamente es por lo que te dije (por memoria ram) por lo que no puede leer mas de los 192 bytes principales, lee el codigo fuente y compilalo y despues recien ahi te vas a dar cuenta por que es esto...
con respecto al servidor web tambien esta en mi mente hacer uno pero primero quiero hacer este proyecto de la tejetita...
y he visto muchos modulos como el que mostras pero el que mas me gusto es el de tibbo que esta todo dentro de un solo encapsulado y tiene 4 led de indicacion tx, rx, link y conexion.
y a que no saben como se comunica el pic con este componente? siiiiiiiiiiii por spi jajaja :LOL: :LOL: :LOL: asique mejor apronder a usar el spi para las tarjetas y despues encaramos el otro proyecto...
repito este esta muy bueno porque no tiene placa extra ni nada por el estilo...
aca tienen una imagen para que lo vean
em202-middle.jpg

y la pagina del fabricante (tiene muchos modulos parecidos)
este es el link http://www.tibbo.com/em202.php
 
Hola:

Hay que ver el motivo de no guardar bien los datos. Para estas cosas es mejor usar PIC18F.

Lo del WebServer, parece muy bueno el que indicas, de hecho lo es hasta la comunicación. Tengo el libro www.pic16f84a.org donde te explica muy bien el protocolo de comunicación I2C. En cuanto al SPI que cada vez veo que se usa más y que tiene 20MHz de velocidad de datos, está muy bien porque funciona más rápido que el I2C sobre todo si usas imágenes.

Saludos.
 
Tengo que guardar datos de temperatura , cantidad de luz, humedad
tengo que guardar un informe de lo sucedido con esos parámetros durante 1 dia y luego enviar esos datos a la máquina por puerto usb
 
y porque no juntamente con esos datos guardas la fecha y la hora en que fue tomado el dato? eso lo haces facilmente con un ds1307 (aparte de la memoria sd para guardar los datos) y conexion i2c o tambien creo que el ds1304 o el ds1302 era por spi, este es un reloj calendario y esta muy bueno, te da el dia de la semana fecha y hora, y ademas tien memoria (chiquita pero para guardar algun datito sirve).
 
voy a utilizar el ds1307 para el rtc , como vos decis y el SHT71, para la humedad y temperatura. Para la luz tendría que usar un ldr conectado al adc del micro luego esos datos guardarlos de a tres (luz,temperatura,humedad), junto con la fecha y guardarlos en la sd para que al pasar un día me los envíe por usb a la pc
 
no te creas que se te va a complicar... igual yo quiero guardar en un archivo txt y eso lo podemos desarrollar en conjunto a traves de este foro, primero yo me voy a centrar en leer y grabar en la sd, pero despues voy a implementar fat para eso, si te prendes podemos desarrollarlo juntos y por este foro.
una pregunta, cuanto pagaste el sensor de temperatura y humedad?
 
Gracias nutriax por el apoyo, mirá el SHT71 me sale u$15 y el ds1307 u$ 7 pero todavía no los compro los voy a pedir a fin de mes , por que ando corto de plata con los 3 pic18f2550 me gaste $133.50 y no me queda mucha guita asi que estoy ahorrando , pero mientras tanto voy a ir desarrollando el código para ir escribiendo la SD con el ejemplo de proba_mmc aunque todavía lo estoy tratando de entender , lo del USB ya lo tengo un poco más claro. Como vos decís me adiero para desarrollar el código en CCS

PD: Tambíen pienso adquirir un PICKIT2, con lo cúal voy a poder programar más cómodo con la laptop ya que la pc y el jmd o el clon de propic2 que tengo hay veces que no funciona del todo bien.
 
bueno me alegro que te adieras para desarrollar el codigo en ccs...
con respecto a la capacidad de la memoria no esta dado por la memoria del pic, esto es un eror que se comete y es muy comun cometer este tipo de errores, paso a explicar, y de paso aca se van a dar cuenta de porque este muchacho puede leer hasta los primeros 192 byte y tambien se van a dar cuenta de porque se necesita mas memoria o pic mas grande...:
si se ponen a leer información de las tarjetitas, ya sea de 8mb 16mb, 32mb,64mb.... asi hasta 8gb, 16gb,32gb, etc etc etc... dicha información dice que en cualquiera de estas tarjetas se lee y se escribe por bloque (de 512 byte), es decir que las transacciones son atomicas y que cuando uno graba o lee si o si se hace de 512 byte.
entonces que pasa... supongamos que todos estamos trabajando en el proyecto de jonathan.
definimos cuantos byte se usan para reprecentar las muestras que va a guardar
datos utilizados para fecha y hora ocupan 8byte (esto es una suposicion y puede ocupar menos o mas byte)
datos utilizados para temperatura ocupan 2byte
datos utilizados para humedad ocupa 2byte
datos utilizados para algun checksum o algo asi ocupan 1byte
con lo que tenemos 13byte.
ahora como lo guardamos en la memora?
tenemos comunmente 2 formas(pueden existir mas alternativas pero voy a explicar las 2 mas comunes), ir grabando en tiempo real, o buffereando
grabando en tiempo real es:
1- inicializar tarjeta y todo lo demas... (para mas explicacion veer los primeros post)
2- indicar a la tarjeta en que direccion lo voy a grabar.
3- tomar fecha y hora.
4- grabar fecha y hora.
5- tomar humedad.
6- grabar humedad.
7- tomar temperatura.
8- grabar temperatura.
9- esperar x tiempo (que es el tiempo entre muestra y muestra eso lo estima el amigo jonathan segun como lo quiera hacer el y que frecuencia de muestreo se adapte mejor a su proyecto)
10- repetir desde paso 3.
cabe aclarar que a medida que uno va grabando se ingrementa sola la posicion (eso creo, ahora entre un poco en duda pero es cuestion de verlo a eso).
pero en esencia lo que hace es ir grabando nomas.
la otra forma es, mantener un puntero a la ultima direccion que se grabo para saber cual es la siguiente libre, y hacer lo siguiente.
1- inicializar tarjeta y todo lo demas... (para mas explicacion veer los primeros post)
2- indicar a la tarjeta en que direccion lo voy a grabar (la direccion del ultimo bloque que se grabo, es decir del ultimo bloque de 512 byte que se grabo).
3- leer el bloque (digo leer todo el bloque porque si o si se tiene que leer todo, eso es por protocolo de la tarjetita y a este bloque lo tengo que mantener en memoria del micro para poder modificarlo)
4- buscar dentro del bloque cual es la direccion del primer byte libre.
5- tomar fecha y hora.
6- grabar fecha y hora dentro del vector que tiene el micro con los 512 byte.
7- tomar humedad.
8- grabar humedad dentro del vector que tiene el micro con los 512 byte.
9- tomar temperatura.
10- grabar temperatura dentro del vector que tiene el micro con los 512 byte.
11- si se lleno el bloque (los 512 byte) grabar bloque de 512 byte pisando el bloque viejo (el que leimos en el paso 3), sino seguir en el paso tres hasta que se llene el vector de 512byte.
12- esperar x tiempo.
10- repetir desde paso 3.
esta forma ustedes diran que es mas complicada y que es muy tediosa al vicio, pero asi es como se deberia hacer, y de hecho asi es como lo hace el sistema fat, esto es porque es mas rapido trabajar con los bloques levantados en memoria y mas eficas y no produce un bloqueo de la tarjetita.
tambien ronda un monton de teoria que tratan a dicho tema y ni porsupuesto tambien tenes que manejar toda la paginacion de esos bloques, todo eso es otro monton de teoria que ya me lo tuve que comer en la facultad y me gusta , pero es muy tedioso programar eso :cry: pero de eso ya se encarga el sistema de archivo fat.
por eso es importante que definas como vas a grabarlo.
lo que le pasa al amigo que hizo el prueba_mmc es de la segunda forma, por eso el 16f877 no tiene lugar para leer los 512byte, sino que lee los primeros 192 byte y los manda a un vector para procesarlo (como explique anteriormente), esto lo hace leyendo y almacenando, y va preguntando si se va a leer el byte numero mayor a 192 entonce dar los clock para leerlo peor no almacenar el resultado, esto es simplemente porque uno cuando hace el programa utiliza variables y un par de cosas mas como las funciones que te chupan la memoria ram del micro, y por ende le quedan unicamente libre 192 byte que lo usa para este vector.
ahora imaginensen usando sistema fat para el 16f877, directamente no nos compila el css porque nos dice que no tenemos la memoria ram suficiente en el micro para correr el programa.
espero que les guste mi explicacion y que me entiendas, sino pregunten.
 
para que quede claro el porque no esta bien lo que dice jonathan en su ultimo mensaje:
es que no importa el tamanio de la tarjeta, sino que importa tener la suficiente ram para el bloque y para tener un puntero por ejemplo de 32byte para poder direccionar los 2 a la 32 bloques (bloques de 512byte), es decir que con un puntero de 32 byte podemos direccionar 4294967296 bloques, es decir 2199023255552 bytes, lo que es igual a 2048 gb (si es que no saque mal la cuenta).
lo que si se complica un poquito es apartir de las memorias de 4gb en adelante, ya que usa un protocolo modificado, ya que es para mayor velocidad y para mayor capacidad (HD).
espero que quede todo claro... sino pregunten.
 
Muchas gracias por corregirme nutriax, mirá ya me he facilitado la vida consiguiendo un proyecto completo como lo que yo quiero, es más con código fuente y todo + librerías
lo único que me hace falta ahora es lo de la SD y el tema de FAT16 :cool:

PD:

Me compré los benditos PIC18F2550......haa cuanto me costó conseguirlos :rolleyes:

haa también me salieron bastante saladitos 44$ c/u con iva incluido
 

Adjuntos

  • pic_536.jpg
    pic_536.jpg
    18.2 KB · Visitas: 339
Les posteo lo que he conseguido en una de esas le sirve a otro.

Aca está lo del proyecto que les comente + lo de transmisión de datos por usb

Algo importante para aclarar es que lo baje todo de la pagina de J1M (Foro todopic) , con lo cúal la mayor parte
de las cosas son de su autoría (freeware)

www.hobbypic.com/
 

Adjuntos

  • codigo_fuente_104.rar
    48.3 KB · Visitas: 244
  • picusb_vb_423.rar
    286.7 KB · Visitas: 291
Nutriax , conseguí algo muy importante , si no me equivoco creo que son las rutinas para implementar el protocolo fat16 con un pic
está en C de CCS, en inglés de la pag de CCS espero que me ayudes a entender un poco ya que el código es bastante complejo y largooooo
 

Adjuntos

  • fat16_en_ccs_139.c
    42.3 KB · Visitas: 247
Bueno Jonathan, probaste el prueba_mmc? primero te aconsejo que hagas eso antes de meterte con lo otro...
no hay drama para ver el codigo del fat16, pero en estos dias no voy a poder mucho porque la facultad me tiene mal :cry: pero calculo que el sabado que viene lo veo sin problemas, y para ese entonces tambien espero tener las placas echas para grabar y leer el "Hola mundo..." :LOL: :LOL: :LOL:
una vez echo eso ahi me voy a meter de lleno en la fat, pero mientras hago andar el hola mundo te ayudo con el fat16, eso si haceme caso y trata de leer y escribir con el prueba_mmc, asi te aseguras de que este bien el circuito, codigo spi y todo eso.
me gusta que avance cada ves mas este tema...
probalo y postea que resultados obtuviste.
 
Última edición por un moderador:
ok nutriax me voy a tener que hacer de algunas monedas para comprar el pic16f877 y una memoria sd de 1gb para ver el hacer las pruebas , cuando tengas tiempo y algo definido de la fat16 me contas
 
no hace falta que compres el 16f877 ni ninguna memoria. probalo con lo que tenes (18f2550 y la memoria de 32megas si no mal recuerdo).
sabes como convertir el probar_mmc para el 18f2550? sino avisame yo te lo comvierto para que lo pruebes...
 
El tema nutriax es que no he podido programar el pic18f2550 , me he matado la cabeza haciendo placas inservibles y no lo he logrado, mañana inmaginate voy a armar el te - 20se
haber como me va , con lo de convertir el programa para el pic te lo agradesco

pd: no tengo ninguna sd solamente la del celular pero no voy a arriesgarme a quemarla , mejor me consigo una barata con el adaptador y listo

desde ya muchas garcias por ofrecerte a ayudarme con lo de fat16
 
Atrás
Arriba