¿Cómo abrir y cerrar correctamente los archivos "dentro" de una función miembro? [cerrado]

4

Estoy usando Arduino Uno y Ethernet Shield con una tarjeta SD de 2GB. Tengo el siguiente código de trabajo que se utilizará para escribir datos en la tarjeta SD ( nota : la biblioteca de SD está correctamente iniciada y solo oculto el código reated para mantener las cosas más pequeñas):

class Logger {
  private:
    File myFile;
    char *myFilename;

  public:
    Logger (char *myFilename = "text.txt") : myFilename(myFilename) {
      myFile = SD.open(myFilename, FILE_WRITE);
    }

    void writeAction () {
      if (myFile) {
        myFile.print("Sample text.");
        myFile.close();
      } else {
        Serial.print("Error opening the file ");
      }
    }
};

void setup() {
  Logger logger;

  ...

  logger.writeAction();
}

Sin embargo, si cambio un poco el código anterior como se indica en el siguiente, no funcionará como se esperaba: el "Sample text." es no escrito / guardado en la tarjeta SD.

class Logger {
  private:
    File myFile;
    char *myFilename;

  public:
    Logger (char *myFilename = "text.txt") : myFilename(myFilename) {
      // Note: Here is the change. File opening statements are moved
      // "inside" the writeAction function.
    }

    void writeAction () {
      myFile = SD.open(myFilename, FILE_WRITE);

      if (myFile) {
        myFile.print("Sample text.");
        myFile.close();
      } else {
        Serial.print("Error opening the file ");
      }
    }
};

void setup() {
  Logger logger;

  ...

  logger.writeAction();
}

¿Por qué sucede? ¿Cómo puedo hacer que myFile se abra y cierre correctamente "dentro" de la función writeAction ?

    
pregunta Backo

1 respuesta

1

Un problema común (y difícil de aislar) que a veces ocurre en el desarrollo de sistemas integrados es que algo que funcionó anteriormente deja de funcionar después de algún cambio aparentemente inocuo en el software. Hay muchas razones por las que esto puede suceder, pero las dos más comunes son:

  • Desbordamiento de pila (he escrito sobre este ampliamente )
  • Dependencias / Suposiciones de tiempo no documentadas (o no realizadas)

El desbordamiento de la pila suele ser el resultado de intentar apretar demasiado el chip y no dar suficiente espacio al código para respirar. También puede ser el resultado de errores de software desagradables que involucran punteros que llevan a pisotear la memoria que no esperaba alterar.

Las dependencias de tiempo son mucho más complicadas. A menudo, estos se vuelven locos cuando estás usando "el código de otra persona" y el patrón de uso en el que se basa el código no está bien documentado. Si realmente entiende los periféricos con los que está trabajando, puede resolverlo investigando el código de esa persona o usando un instrumento para realizar mediciones directas de las señales. Enterrado en alguna hoja de datos en algún lugar, probablemente dice que no haga X dentro de Y milisegundos de hacer Z. En casos como este, hay un contrato implícito (circuito abierto) entre el controlador y el periférico para que las cosas tengan tiempo de hacer cualquier cosa antes de interactuar con otra vez

Una API debería dejar claro el tipo de dependencia, pero los mendigos no pueden ser selectores, como dicen. Este es un desafío cuando se trata de Arduino, y el código funciona bien siempre y cuando no se aleje demasiado de los ejemplos. Pero si no funciona en su contexto, debe estar preparado para entender realmente lo que está sucediendo y ajustar las cosas en consecuencia.

Idealmente, la interfaz a un periférico debe escribirse de manera que sea "insensible a la demora" y use algún tipo de mecanismo de sondeo para controlar el progreso. Código de comportamiento como lo que está viendo aquí es lo que me gusta llamar desarrollo "basado en la fe". Confiar en los comentarios de un dispositivo siempre es mejor que cruzar los dedos y seguir adelante.

    
respondido por el vicatcu

Lea otras preguntas en las etiquetas