trystan4861:
El aporte no es para "obligar" a colocar una SD, es para ayudar a aquellos que ya la tienen colocada a reducir drásticamente el código fuente encargado de procesar el archivito...
Lo sé, pero solo comentaba el detalle de la memoria. Dejando eso de lado, tu solución está genial. 
trystan4861:
En cuanto a lo de usar los strings... es porque al leer los datos me presentaba la cadena contenida como números ascii
Caracteres, bytes; en ASCII son lo mismo.
Por "números ASCII" no está claro si te refieres al valor binario de los caracteres, o caracteres que representan números.
trystan4861:
bueno, hay que recordar que en realidad estás accediendo a un "archivo de configuración"... no es muy común tener la biblia en pastas escrita en sánscrito como contenido de una variable de configuración...
No lo decía en ese extremo, sino que tu idea no necesariamente puede aplicarse sólo a temas de configuración; también podría ser una especie de base de datos, donde (por algún motivo) haya un campo donde se permitan textos "relativamente" largos.
trystan4861:
¿hay otra forma de conseguir lo que se precisa?
En mi caso, yo hubiera preferido los registros de longitud fija; pero como todo, tiene sus desventajas.
trystan4861:
No entiendo eso de sumar cada objeto file... no sé cómo se tratan las variables en c... yo vengo de otro leguaje de programación... pero entiendo que una vez que la ejecución de la función ha finalizado la variable... ¿muere? si no es así ¿tal vez debería crear realmente una variable global? Si se va a usar más de un registro de memoria (de los bytes que sean) para acceder a los ficheros... mejor crear uno único... total... no se va a acceder simultáneamente a más de un archivo ¿verdad?
Cuando una variable permanece durante toda la ejecución, es global y el compilador la toma en cuenta a la hora de reportar la memoria libre inicial.
Las variables locales se crean y destruyen dentro de una función; como son temporales, no se toman en cuenta por el compilador.
Ahora, cuando hablo de sumar el uso de memoria con objetos File, es porque la creación (declaración) de estos dentro de una función, no se toma en cuenta en el reporte del compilador.
Para tu ejemplo claramente sólo un archivo a la vez se abre; sin embargo, combinado con otro proyecto puede darse el caso que más de uno esté abierto al mismo tiempo. Uno mismo no se puede abrir dos veces simultaneas, distintos sí.
¿Problemas? Prácticamente ninguno ya que la ejecución del programa siempre es secuencial. El único muy extraño caso donde sí podría, es que el programa principal y una rutina de interrupción hagan uso del mismo objeto File.
Dices venir de otro lenguaje; si es de Java, comprenderás mucho lo que voy a decir a continuación:
Al ser Arduino programado con un lenguaje de alto nivel, la memoria RAM se distribuye en dos secciones de tamaño acorde al momento (variable en el tiempo): la pila de ejecución y el heap.
En la pila de ejecución, se almacenan las variables "primitivas" (las de tipo meramente numérico, incluidos los punteros de cualquier tipo de dato) declaradas localmente (solamente dentro de una función); crece cuando se invoca una función, y decrece cuando una termina.
El mal manejo de esta también provoca cuelgues, el error es conocido como "desbordamiento de pila" ("stack overflow" en inglés) y usualmente es causado por un nivel muy profundo (o infinito) de recursividad.
Consume la memoria desde el final hacia el principio.
Luego tenemos el heap; aquí es donde se almacenan las variables "primitivas" globales (o declaradas con la palabra static) y las estructuras de datos (struct, vectores y atributos de objetos).
Las cadenas de caracteres son vectores, los objetos String realmente ocupan 6 bytes en el heap (puntero a un vector, tamaño de este y longitud real de la cadena; respectivamente cada uno de tipo char*, int, int). ¿Recuerdas cuando dije que concatenar con String podía colgar el programa? Bueno, pues el hacerlo muy repetidamente provoca que el objeto esté solicitando reasignar espacio al vector que contiene la cadena; y el estar en eso puede generar "huecos". El problema con estos es que el manejador de memoria dinámica (el heap) de Arduino no implementa compactación; entonces si entre tanto "hueco" no encuentra espacio para un objeto, lanza una excepción (alerta de situación excepcional) que Arduino tampoco maneja (al no hacerlo, el micro recurre a "congelarse" o "colgarse").
Estas deficiencias en la implementación de C++ para Arduino tienen un único motivo: rendimiento. No es justo comparar un PC que tiene procesador de 4 o hasta 6 núcleos, de 64 bits y que van a velocidades en el rango de los GHz; con un pobre ATmega328P que tiene un procesador de 8 bits, un único núcleo y va a 16 MHz. Y en memoria RAM sobra decir...
La compactación y "recolección de basura" en un PC tarda máximo un parpadeo de ojos; mientras que un Arduino podría llevarse hasta varios segundos (asumiendo hipotéticamente que tiene dichas funcionalidades). Sólo imagínate que ridículo sería que un Arduino repentinamente deje de funcionar por entrar en un ciclo de "recolección de basura".
Creo que he hablado "sin frenos", así que avísame si te he dejado atrás (tienes algo sin entender) para que me alcances.