Leer bancos de memoria SD

Lucario448:
¿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.

Lucario448:
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 :stuck_out_tongue: (Esos tiempos en donde no tenía un módulo SD y aun no me había armado uno propio..)

Lucario448:
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.