manejo - Sugerencias de estructuras de archivos en C incorporadas

lectura y escritura de archivos en c++

Question

No puedo encontrar buenas sugerencias sobre las estructuras de archivos en el software embebido típico en C. Aquí hay varias preguntas y respuestas sobre SO, pero ninguna que cubra las inquietudes que presento o que parece estar adaptada a los sistemas integrados en C.

Entiendo que no hay una bala de plata. Si eso ayuda a limitar las sugerencias, mi aplicación típica debe encajar en objetivos con entre 8 y 32 kB de memoria flash, y unos pocos kB de RAM. Relojes en el rango de 4 a 20 MHz.

1. Capas

He visto el código fuente organizado en capas, cada capa tiene su propio directorio:

• solicitud
• capa de transporte
• capa de abstracción de hardware

El problema es que los módulos a menudo tienen archivos en todas estas capas, por lo que separar las capas en los directorios significa que los archivos de un solo módulo están dispersos por todo el lugar. Poca encapsulación.

2. Módulos en directorios, h archivos en $ ROOT / includes /

Un directorio por módulo Lo bueno es la encapsulación real. Lo que no estoy seguro de cómo hacerlo bien es cómo publicar la API de un módulo. La aplicación de PC de código abierto SW parece:

• tener todo el código fuente en el directorio del módulo (todos los archivos C y todos los archivos de encabezado que se deben usar solo dentro del módulo)
• publicar el archivo de encabezado API fuera del directorio del módulo, en $PROJ_ROOT/includes .

De esa forma puedo tener -I$PROJ_ROOT/includes (o equivalente) en mi comando de compilación, y no hay rutas de búsqueda en mis declaraciones #include .

Un problema es que la API está fuera del directorio del módulo, lo que rompe la encapsulación. Es más difícil mantener un módulo como independiente en un VCS, por ejemplo.

3. Módulos con API en directorios

Lo mismo que arriba, pero con el archivo de encabezado API en el directorio del módulo. Encapsulación adecuada y módulos de control de versiones más fáciles, pero el archivo de encabezado de la API está en el mismo nivel que los otros archivos de encabezado del módulo, que se suponía que eran privados. La tentación de incluir un archivo de encabezado "privado" fuera del módulo puede ser demasiado grande para un futuro desarrollador, y no es visible qué archivo h debía ser público y cuáles no.

4. Módulos con API en directorios, estructura privada en subdirectorio

Coloque solo el archivo de encabezado API directamente en el directorio del módulo y todos los demás archivos en un subdirectorio o varios. Esto podría funcionar, pero creo que la estructura se está volviendo más y más compleja, lo que realmente no me gusta.

Siento que debería ir por 2 o 4, pero apreciaría muchísimo la idea. ¿Cómo abordar los inconvenientes relacionados que describo? Otras alternativas?

Los enlaces a SW de código abierto exitoso de este tipo de tamaño también podrían ser buenos. El asesoramiento de literatura también es bienvenido.

Answer 1

Con una cantidad de memoria tan limitada, la aplicación + sistema operativo será bastante pequeña. He trabajado en proyectos que son varios gigabytes de código fuente, y la cantidad de módulos en miles, y la construcción de binarios instalados que están en el rango de "gigabytes". Cuando llegue a ese tamaño, definitivamente necesita tener sus archivos de encabezado, etc., en el lugar correcto.

Creo que el siguiente es un concepto bastante decente, sin embargo:

1. Archivos fuente por módulo Los módulos pueden separarse en grupos más grandes por "uso" (por ejemplo, "Base / OS", "Gráficos", "Audio", "Red", "UI", "Aplicaciones", etc.).
2. Cada módulo tiene una lista de "entradas exportadas" (de cero a bastante grande), que, cuando el módulo se está construyendo, se copia en un directorio de tipo general "$ {ROOT} / includes". Eso proporciona la interfaz EXTERNAL, pero los archivos de objetos producidos como el módulo mismo pueden usar "$ {module} / includes" también, donde hay declaraciones y definiciones privadas, no "públicas" para los usuarios de la API.

Esta es aproximadamente la forma en que funcionan la mayoría de los proyectos grandes. Si funciona para proyectos grandes, también debería estar bien para proyectos más pequeños. Sin embargo, si la cantidad de archivos fuente es de una docena o dos, realmente no veo mucho sentido dividirla en absoluto, tal vez un "src" e "incluye", quizás también un "include / private" si quieres para garantizar que las API estén limpias. ¡Mantenerlo simple tiene grandes ventajas!

Tenga en cuenta que la parte de "exportaciones" debe construirse antes de compilar los módulos reales, o deberá asegurarse de que no haya absolutamente ninguna comunicación cruzada entre los módulos [o al menos garantizar que ningún módulo "temprano" necesite ninguno de los módulos archivos de cabecera de módulos "posteriores" - que se vuelve bastante difícil si el sistema se está volviendo grande].

También debe tener un conjunto de reglas sobre cómo y qué exponer, y durante la revisión del código, verifique que se sigan estas reglas.