#define vs. enums para direccionar periféricos

Question

Tengo que programar registros periféricos en un microcontrolador basado en ARM9.

Por ejemplo, para el USART, almaceno las direcciones de memoria correspondientes en un enum:

enum USART 
{ 
    US_BASE = (int) 0xFFFC4000, 
    US_BRGR = US_BASE + 0x16, 
    //... 
}; 

Entonces, utilizar punteros en una función para inicializar los registros:

void init_usart (void) 
{ 
    vuint* pBRGR = (vuint*) US_BRGR; 
    *pBRGR = 0x030C; 
    //... 
} 

Pero mi el maestro dice que es mejor que use #define s, como:

#define US_BASE (0xFFFC4000) 
#define US_BRGR (US_BASE + 0x16) 
#define pBRGR ((vuint*) US_BRGR) 

void init_usart (void) 
{ 
    *pBRGR = 0x030C; 
} 

Como tal, dice, usted no tiene la sobrecarga de asignar punteros a la pila.

Personalmente, no me gusta #define s, ni otras directivas de preprocesador. Entonces, la pregunta es, en este caso particular, ¿vale la pena usar #define s en lugar de enum sy los punteros asignados a la pila?

---

pregunta relacionada: Want to configure a particular peripheral register in ARM9 based chip

Answer 1

El enfoque siempre he preferido es definir primero una estructura que refleja los periféricos registran diseño

typedef volatile unsigned int reg32; // or other appropriate 32-bit integer type 
typedef struct USART 
{ 
    reg32 pad1; 
    reg32 pad2; 
    reg32 pad3; 
    reg32 pad4; 
    reg32 brgr; 
    // any other registers 
} USART; 

USART *p_usart0 = (USART * const) 0xFFFC4000; 

Luego, en el código que sólo puede utilizar

p_usart0->brgr = 0x030C; 

Este enfoque es mucho más limpio cuando se tener varias instancias del mismo tipo de periférico:

USART *p_usart1 = (USART * const) 0xFFFC5000; 
USART *p_usart2 = (USART * const) 0xFFFC6000; 

Usuario sbass provi Ded de un enlace a an excellent column por Dan Saks que da muchos más detalles sobre esta técnica, y señala sus ventajas sobre otros enfoques.

Si tiene la suerte de estar utilizando C++, puede agregar métodos para todas las operaciones comunes en el periférico y encapsular las peculiaridades de los dispositivos.

Answer 2

que necesariamente no diría que de cualquier manera es mejor. Es solo preferencia personal. En cuanto al argumento de su profesor, es realmente un punto discutible. La asignación de variables en la pila es una instrucción, no importa cuántas, generalmente en el formulario sub esp, 10h. Entonces, si tiene un local o 20, sigue siendo una instrucción asignar el espacio para todos.

Yo diría que la única ventaja del #include es que si por alguna razón, en el futuro, usted quiere cambiar la forma en que se accede a ese puntero, solo tiene que cambiarlo en una ubicación.

Answer 3

Me inclinaría por el uso de una enumeración, para una posible compatibilidad futura con el código C++. Digo esto porque en mi trabajo, tenemos muchos archivos de encabezado C compartidos entre proyectos, algunos de los cuales usan código C y algunos usan C++. Para aquellos que usan C++, a menudo nos gustaría envolver las definiciones en un espacio de nombres, para evitar el enmascaramiento de símbolos, pero no se puede asignar un #define a un espacio de nombres.

Answer 4

Me temo que enum son un callejón sin salida para tal tarea. El estándar define las constantes enum para que sean del tipo int, por lo que en general son no compatibles con punteros.

Un día en una arquitectura con 32bit int y punteros de 64 bits es posible que tenga una constante que no se ajusta a un int. No está bien definido lo que sucederá.

Por otro lado, el argumento de que enum asignaría algo en la pila no es válido. Son constantes de tiempo de compilación y no tienen nada que ver con la pila de funciones ni más que las constantes que especifique mediante macros.

Answer 5

En mi experiencia, una gran razón para usar #define para este tipo de cosas es que es más de la expresión estándar utilizada en la comunidad integrada.

Usar enums en lugar de #define generará preguntas/comentarios de los instructores (y en el futuro, colegas), incluso cuando el uso de otras técnicas tenga otras ventajas (como no pisar el espacio de nombres del identificador global).

Personalmente me gusta usar las enumeraciones para las constantes numéricas, pero a veces debe hacer lo que es habitual para qué y dónde está trabajando.

Sin embargo, el rendimiento no debería ser un problema.

Answer 6

La respuesta siempre es hacer lo que quiera el maestro y pasar la clase luego en su propia pregunta de todo y averiguar si sus razones fueron válidas y formar sus propias opiniones. No puedes ganar contra la escuela, no vale la pena.

En este caso, es fácil compilar para ensamblar o desmontar para ver la diferencia, si hay alguna, entre la enumeración y la definición.

Recomendaría la definición sobre enum, he tenido molestias en el compilador con enumeraciones. Desanimo el uso de punteros de la misma forma que los usa, he visto que cada compilador no genera las instrucciones deseadas con precisión, es raro, pero cuando sucede, se preguntará cómo funcionaron sus últimas décadas de codificación. Señalar estructuras o cualquier otra cosa es considerablemente peor. A menudo me entusiasman por esto, y espero esta vez. Demasiadas millas alrededor del bloque, se corrigió demasiado código roto con estos problemas para ignorar la causa raíz.

Answer 7

Dan Saks ha escrito una serie de columnas sobre esto para la Programación de Sistemas Embebidos. Aquí está uno de sus latest ones. Habla sobre C, C++, enumeraciones, estructuras, clases, etc. y por qué uno puede ser uno sobre otro. Definitivamente vale la pena leerlo y siempre es un buen consejo.