Go Down

Topic: Leer bancos de memoria SD (Read 5978 times) previous topic - next topic

StringCGE

No se si con el titulo me expreso bien pero mi propósito es leer una SD sector por sector desde el primero hasta el ultimo sin restricciones de algún tipo de formato de archivo.
mas o menos como leer un byte de memoria del arduino sin importar si se trada de una variable o una entrada a una función o metodo.

Lucario448

Es un tema interesante, pero para eso tendrías que estudiar el modo de operación de una tarjeta SD para con SPI; o si no, explorar en las entrañas de la librería SD.

Hasta el momento, lo que puedo asegurarte, es que las de 2 GB o menos, pueden ser leídos/escritos byte por byte; mientras que de 4 GB en adelante solo en bloques de 512 bytes (efectivamente equivale a un sector lógico).

Sería interesante incluso para mi, para hacer realidad una idea que me había dado un usuario llamado Metaconta; esa idea se trataba de crear archivos bajo un sistema de archivos propio, pero a la vez irreconocible para las computadoras y demás lectores comerciales (como reproductores de MP3),

surbyte

Mira este post con las consideraciones de que es un post del 2011 y que su uso puede traerte algunos problemas de compatibilidad con el IDE que estes usando.

StringCGE

#3
Feb 25, 2017, 01:48 am Last Edit: Feb 25, 2017, 02:16 am by StringCGE
Agradezco sus respuestas y mi objetivo es ese mismo.
Hacer un sistema de archivos distinto uno para arduino pero que coexista con la libreria SD.
No tengo idea clara de como se maneja esto pero hay va.

Hasta donde se es que cada memoria desde la ram de una pc hasta la flash de una usb o de arduino o la rom o un disquet. Poseen una dirección de memoria Ejemplo de como lo veo yo.

Ejemplo.

Direccion                dato           char
de memoria
0000 0000              01010011     S
0000 0001              01110100     t
0000 0010              01110010     r
0000 0011              01101001     i
0000 0100              01101110     n
0000 0101              01100111     g
0000 0110              01000011     C
0000 0111              01000111     G
0000 1000              01000101     E

Entonces eso es lo que quiero.
Poder decirle a arduino que me diga lo que hay en la dirección 0000 0101 y me responda 01100111
que con el Cast respertivo me enterare que es el char g en caso de que fuere.

Trabajo con una memoria de 4Gb y tocaria leer el sector.

Con respecto al post que indica Surbyte.
Code: [Select]
#include "WProgram.h"
esta es la falla que tengo al intentar cargar el boceto
ya que en el header se incluye pero no en el actual IDE.

La funcion.
Code: [Select]
unsigned char SDCARDclass::readblock(unsigned long Rstartblock)
utiliza funciones o métodos que creo que están en WProgram.h

Ahora desentrañando
SPI.h
SPI.cpp

y por consiguiente la librería SD con sus 9 cabeceras y sus 6 archivos fuente
Es una tarea compleja para mis conocimientos actuales pero no imposible.

surbyte

#4
Feb 25, 2017, 02:58 am Last Edit: Feb 25, 2017, 03:20 am by surbyte
Olvida WProgram hasta donde yo se, puedes prescindir.
Solo comentala.

Otra sugerencia. Si miras SD.h seguramente existe el bajo nivel que permita un acceso a nivel de sectores.
Tal vez sean procedimientos privados para la clase asi que podrias crear una librería propia donde estos procedimientos sean públicos.

Aca otro hilo que merece leerse.

El anterior hilo que te sugerí esta pensado para IDE 1.0.X ojo!!! no me había percatado de ese detalle. Te dará muchos dolores de cabeza.


EDITO: He modificado la librería eliminado WProgram y agregando Arduino.h y compila.
Te dejo la prueba con la SD a ti.

La adjunto para que tengas el archivo ejemplo y las librerías todo para una prueba.

Lucario448

#5
Feb 25, 2017, 05:22 am Last Edit: Feb 25, 2017, 05:23 am by Lucario448
Honestamente, yo uso una SD de 4 GB, y ese método no me funcionó; no escribe nada al sector indicado.
Probé con la clase Sd2Card que viene en la librería SD:

Code: [Select]
#include <SD.h>
Sd2Card card;

unsigned char buffer[512] ;  // this 512 bytes read from or written to sd card
const unsigned long sector = 10000;  // the sector we will write or read from - leave lower sectors


void setup(){
 Serial.begin(9600);   // initialize serial communication with computer
 memset(buffer, '?', 512); // Llenar un sector completo con signos de interrogación
 if (!card.init(SPI_FULL_SPEED, 4)) { Serial.println(F("ERROR")); return;}
 if (card.writeBlock(sector, buffer)) Serial.println(F("Lo logre!"));
 else Serial.println(F("NOPE"));
}

void loop() {

}

Lo subí, introduje la tarjeta, y el monitor serie me responde con "Lo logre!"; esa es una buena señal.
Abro el programa HxD para hacer una lectura en crudo de la tarjeta, y miren justamente lo que encontré en el sector 10000:



En resumidas cuentas: funciona aún en SDHC (4 - 32 GB).


Creo que con este descubrimiento ya tenemos algo de progreso.

Ahora, lo único que me falta por saber, es cómo determinar la capacidad de la tarjeta en sí; sin tabla de particiones ni sistemas de archivos. Mi idea es convertir (a nivel de software) una tarjeta SD en una EEPROM, o al menos imitar el funcionamiento de la clase File (manipular toda la tarjeta como un archivo)

ferminolaiz

Uhm, el proyecto suena interesante, varias veces la EEPROM se me ha quedado corta.
Si piensas liberarlo como biblioteca, (y si quieres, obvio :P) te puedo dar una mano.

¿Has trabajado con git/github alguna vez?

Saludos!

Lucario448

Actualizo:

Ahora, lo único que me falta por saber, es cómo determinar la capacidad de la tarjeta en sí; sin tabla de particiones ni sistemas de archivos.
Creo que ya lo tengo. No había notado que Sd2Card tiene una función llamada cardSize; retorna la cantidad de sectores que tiene la tarjeta; por lo tanto:

Code: [Select]
unsigned long capacidadEnBytes = card.cardSize() * 512; // Si retorna cero, un error ha ocurrido

El detalle es lidiar con más de 4 GB, ya que es hasta donde puede direccionar un unsigned long en AVR.
Manejarlo sector por sector no sería un problema, hasta 2 TB sería posible; pero mi implementación se supone que debe convertir operaciones "sector por sector" en operaciones "byte por byte".



PD: ¿alguien sabe cómo especificar herencia a una clase en C++? La idea es que mi implementación pueda ser usada igual que con Serial.


varias veces la EEPROM se me ha quedado corta.
¿Hablas en serio? Pensé que con 1024 bytes se almacenaba bastante información. Si lo que sueles almacenar son cadenas de caracteres, no habría duda de por qué...

Si piensas liberarlo como biblioteca, (y si quieres, obvio :P) te puedo dar una mano.
Agradezco tu ayuda entonces, porque alguna no me caería mal :)


¿Has trabajado con git/github alguna vez?
Sinceramente no, pero he oído decir que es una forma fácil de trabajar código en equipo.

Como estaba diciendo antes, estoy entre imitar EEPROM o File/Serial (estas dos últimas lo que tienen en común, es que se pueden usar las funciones establecidas por la clase Stream; entre ellas, el muy famoso print y println).

ferminolaiz

#8
Feb 25, 2017, 05:18 pm Last Edit: Feb 25, 2017, 05:24 pm by ferminolaiz
El heredar de otra clase es algo así:

Code: [Select]
class ClaseHija : public ClasePadre
{
    // ...
};

public indica que todos los métodos heredados mantienen la misma accesibilidad (public, public; protected, protected). Si lo cambiaras a protected, todos los miembros públicos se convertirían en protegidos. Lo mismo con private; convertiría los miembros públicos y protegidos a privados.

Un detalle con el que me encontré trabajando en espacios reducidos es que la clase Stream utiliza bastante espacio (insisto, en relación a los recursos disponibles si uno trabaja con controladores pequeños). 

En cuanto a la EEPROM, rectifico, una vez me quedé corto en la práctica, efectivamente, almacenando strings; las demás fueron en el papel, almacenando configuraciones y una serie de instrucciones :P

Para manejar tarjetas mayores a 4GB, se me ocurren dos opciones. Una, que el usuario especificara con qué sector quiere trabajar, y otra (que parece menos lógica pero me parece más eficiente): asumiendo que el tamaño de todas las tarjetas mayores a 4GB son multiplos de 4GB (nunca vi una de 6GB, corijanme si me equivoco), uno podría dividir la tarjeta en "sub tarjetas", o sectores de 4GB, y que la biblioteca se encargue manejar las direcciones que correspondan.

Saludos!

Lucario448

Un detalle con el que me encontré trabajando en espacios reducidos es que la clase Stream utiliza bastante espacio
¿Entonces qué sería más eficiente (en espacio)? ¿Heredar o simplemente implementar las funciones desde cero?
De ser la segunda... sería un desafío entonces; lo digo por funciones como print, println, find, findUntil, parseInt, parseFloat. Las que no mencioné, son fáciles para mi de recrear.


En cuanto a la EEPROM, rectifico, una vez me quedé corto en la práctica, efectivamente, almacenando strings
Ja, lo sabía.
Cuando la memoria es poca, los strings se vuelven demasiado grandes. Si es para almacenar constantes, esas irían en la memoria flash; lo que podría ir en la EEPROM, son instrucciones que indiquen cual string imprimir (instrucciones de uno o unos cuantos bytes).

Ejemplo: para mostrar las configuraciones actuales en una LCD, en vez de almacenar las cadenas en la EEPROM, se hacen en la memoria flash; esta primera lo que contendría, es el ID asociado a esa configuración y cadena de caracteres.


Para manejar tarjetas mayores a 4GB, se me ocurren dos opciones. Una, que el usuario especificara con qué sector quiere trabajar, y otra (que parece menos lógica pero me parece más eficiente): asumiendo que el tamaño de todas las tarjetas mayores a 4GB son multiplos de 4GB (nunca vi una de 6GB, corijanme si me equivoco), uno podría dividir la tarjeta en "sub tarjetas", o sectores de 4GB, y que la biblioteca se encargue manejar las direcciones que correspondan.
De hecho, yo tenía pensado combinar ambas. El direccionamiento por sectores siempre será absoluto, mientras que el direccionamiento por bytes será relativo si se detecta una tarjeta >4 GB. ¿Relativo a qué?, en caso de que preguntes; será relativo a algo que llamaré "número de banco", que es lo mismo a tu concepto de "sub-tarjeta".

Esta técnica tampoco es nueva, también se utilizaba en los cartuchos de las consolas de videojuegos en la época de los 80; en inglés se le llamaba "bank-switching", el cual consistía en "expandir" a nivel de software, el mapa de memoria que tenía el microprocesador con el cartucho (el cual era efectivamente por bytes). Frecuentemente está técnica era utilizada para adicionar memoria RAM a la que traía la consola por sí sola, o cuando el juego era muy avanzado y se almacenaba en una ROM más grande que la que puede mapear nativamente el microprocesador.

Entonces eso haré: una especie de "bank-switching" para que el direccionamiento a nivel de bytes pueda ir más allá de 4 GB. Como a nivel de sectores siempre será absoluto, dependiendo en la posición en la que se encuentre, ese cambio se realizaría automáticamente.


Y por último, es cierto que la capacidad crece "en múltiplos de 4", aunque en realidad lo hace en "potencias de 2"; ¿o si no por cuál otra razón las capacidades crecen en una secuencia de 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024 (1 GB o 1 TB dependiendo de la unidad en que lo hayas visualizado)...?

ferminolaiz

#10
Feb 25, 2017, 07:45 pm Last Edit: Feb 25, 2017, 07:58 pm by ferminolaiz
¿Entonces qué sería más eficiente (en espacio)? ¿Heredar o simplemente implementar las funciones desde cero?
De ser la segunda... sería un desafío entonces; lo digo por funciones como print, println, find, findUntil, parseInt, parseFloat. Las que no mencioné, son fáciles para mi de recrear.
Lo que haría sería agregar las funciones que realmente se necesiten, pero todo depende de qué se quiera hacer. Si uno pretende recrear una EEPROM, habría que implementar las funciones que permiten manipular tipos de datos mayores a 1 byte (como hace la lib de arduino). Sino, si la idea es manejar strings, puede que sea mejor heredar de Stream.
O, de última, hacer una base y una extensión que puede manejar strings.

Ja, lo sabía.
Cuando la memoria es poca, los strings se vuelven demasiado grandes. Si es para almacenar constantes, esas irían en la memoria flash; lo que podría ir en la EEPROM, son instrucciones que indiquen cual string imprimir (instrucciones de uno o unos cuantos bytes).

Ejemplo: para mostrar las configuraciones actuales en una LCD, en vez de almacenar las cadenas en la EEPROM, se hacen en la memoria flash; esta primera lo que contendría, es el ID asociado a esa configuración y cadena de caracteres.
Eran strings modificables por el usuario :P (Esos tiempos en donde no tenía un módulo SD y aun no me había armado uno propio..)

Y por último, es cierto que la capacidad crece "en múltiplos de 4", aunque en realidad lo hace en "potencias de 2"; ¿o si no por cuál otra razón las capacidades crecen en una secuencia de 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024 (1 GB o 1 TB dependiendo de la unidad en que lo hayas visualizado)...?
Lo sé, lo escribí muy al pasar jajaja

Saludos!

================
Edito, el quote me traicionó, espero haberlo llegado a editar a tiempo.

Lucario448

Sino, si la idea es manejar strings, puede que sea mejor heredar de Stream.
Es que... si los find y parse no fueran tan necesarios, entonces implemento sólo lo que necesito.

O, de última, hacer una base y una extensión que puede manejar strings.
Esa no la entendí... ::)


Eran strings modificables por el usuario :P
Entiendo, ¿pero tantos o tan grandes eran?


Edito, el quote me traicionó, espero haberlo llegado a editar a tiempo.
Eso explica los 4 párrafos repetidos antes de la corrección.

StringCGE

¿Como hacen cast string a long o UL?
Ya probé el boceto y sale lo logre pero leyendo la SD con e programa HxD en el sector 10000 que es el que se supone estaría escrito, no hay nada.
Como escucho al SPI de arduino.
Hay alguna funcion como
Code: [Select]
Serial.available  y
Code: [Select]
Serial.read o similar.

Leyendo por hay encontre este PDF.
Manejo de SD con Pic


ferminolaiz

¿Para qué serían el parse y/o find?

Con lo de una clase base me refiero a una que emule el funcionamiento de una EEPROM, para que el usuario la pueda utilizar como quiera; y otra clase que implemente, a partir del anterior, el manejo de strings.

Sobre lo otro, eran una serie de menúes modificables por completo.

Saludos!

Lucario448

¿Como hacen cast string a long o UL?
Con un array de char, es con atol. Con un objeto String, con la función toInt.


Ya probé el boceto y sale lo logre pero leyendo la SD con e programa HxD en el sector 10000 que es el que se supone estaría escrito, no hay nada.
Oh, es que había olvidado ponerle una parte que compruebe que efectivamente se haya escrito al sector.

Si no aparecen los signos de interrogación, se me ocurre que posiblemente hayas seleccionado "Disco lógico" en vez de "Disco físico".


Como escucho al SPI de arduino.
Hay alguna funcion como
Code: [Select]
Serial.available
  y
Code: [Select]
Serial.read
 o similar.
Si hereda de Stream debería implícitamente. Según los ejemplos, todo apunta a que en cada transfer se recibe la respuesta.
No lo sé, por eso es que nunca alcanzo a entender SPI

Veo que lo haces a tu manera, aunque... ¿recuerdas cuando te mencioné sobre desentrañar la librería SD? Pues gracias a eso, es que tengo un punto de partida para una librería que está en camino; la cuál permitirá manipular una tarjeta SD como una EEPROM/archivo gigante.


¿Para qué serían el parse y/o find?
Los "parsers" se usan para convertir un número de texto a binario (variable), leyendo directamente desde el "stream".
El "find" se usa para recorrer el "stream" hasta encontrar un byte (o secuencia de estos) que coincida(n) con el parámetro dado.


Con lo de una clase base me refiero a una que emule el funcionamiento de una EEPROM, para que el usuario la pueda utilizar como quiera; y otra clase que implemente, a partir del anterior, el manejo de strings.
Bueno o malo, más bien acabé juntando todo en una sola clase.


Daré un adelanto de las funciones que tendrá mi librería (hasta el momento).

Code: [Select]
// Initializers
  bool begin(unsigned char cs); // Intenta inicializar la tarjeta SD. Retorna false si falla o no logra reconocer la capacidad.
  bool begin(unsigned char cs, unsigned char mode); // Lo mismo solo que se le puede especificar la velocidad del bus SPI. Las opciones están en Sd2Card.h

  // Read/write operations
  int read(); // Lee un byte desde la poscición en la que está.
  int peek(); // Lee un byte desde la poscición en la que está, pero sin moverse.
  unsigned int readBytes(unsigned char* buff, unsigned int len); // Lee un conjunto de bytes hasta len y los guarda en buff.
  unsigned int readBytesUntil(char terminator, unsigned char* buff, unsigned int len); // Lee un conjunto de bytes hasta len o encontrar el terminador, y los guarda en buff.
  String readString(); // Crea un objeto String desde la poscición en la que está el puntero, hasta encontrarse con el caracter NULL ('\0').
  String readStringUntil(char terminator); // Crea un objeto String desde la poscición en la que está el puntero, hasta encontrarse con el caracter NULL ('\0') o el terminador.
 
  bool write(int b); // Escribe un byte en la posición en la que se encuentre.
  unsigned int write(unsigned char* buff, unsigned int len); // Escribe un conjunto de bytes provenientes de buff, hasta len.
  unsigned int writeString(String s); // Escribe el contenido del objeto String, y le agrega el teriminador; así sigue las reglas de readString().
  bool flush(); // La escritura a la tarjeta SD es asincrónica, por eso esta función garantiza que los cambios se actualicen a la tarjeta (si retorna true).

  // Addressing operations
  bool seek(unsigned long pos); // Mueve el puntero a una posición específica. Si la tarjeta es mayor a 4 GB, esta posición es relativa según el número de banco que se esté trabajando.
  bool seekSector(unsigned long sect); // Mueve el puntero a un sector específico y lo alinia al primer byte de este. Este tipo de direccionamiento siempre es absoluto.
  bool changeBank(unsigned char selection); // Selecciona el banco de memoria a trabajar. El puntero automáticamente se alinia al primer sector y byte de este. La operación falla si la tarjeta es igual o menor a 4 GB.

  unsigned long position(); // Retorna la posición actual del puntero, en bytes. De nuevo, es relativo al banco que se esté trabajando.
  unsigned long sector(); // Retorna el número de sector que actualmente está trabajando.
  unsigned long size(); // Retorna la capacidad de la tarjeta SD, en número de sectores.
  unsigned char bank(); // Retorna el número de banco que actualmente está trabajando. Siempre retornará cero si la tarjeta es igual o menor a 4 GB.

  // Public verifiers
  unsigned long available(); // Retorna la cantidad de bytes que quedan para leer/escribir sin riesgo de llegar a un desbordamiento de banco o alcanzar el final de la tarjeta.
  unsigned long availableSectors(); // Retorna la cantidad de sectores que quedan antes de alcanzar el final de la tarjeta.
  unsigned char availableBanks(); // Retorna la cantidad de bancos en la que se ha dividido la tarjeta SD, para su direccionamiento a nivel de bytes.

Faltan los put y get que vienen en EEPROM, pero más adelante las implementaré. Ahora no porque ahora estoy en proceso de implentar la función bank().

Cuando lo tenga listo, lo posteo y ahí entre los que quieran, lo analizan y lo prueban para encontrar cualquier error o característica faltante que no me haya enterado.

Go Up