Stubbing funciones en simulaciones

Question

Estoy trabajando en un proyecto de C integrado que depende de algún HW externo. Deseo eliminar el código de acceso a estas partes, para poder simular el sistema sin utilizar ningún HW. Hasta ahora he usado algunas macros, pero esto me obliga a cambiar un poco mi código de producción, lo que me gustaría evitar.

Ejemplo:

stub.h
#ifdef _STUB_HW
#define STUB_HW(name) Stub_##name
#else /*_STUB_HW*/
#define STUB_HW(name) name
#endif /*_STUB_HW*/

my_hw.c
WORD STUB_HW(clear_RX_TX)()
{ /* clear my rx/tx buffer on target HW */ }

test_my_hw.c
#ifdef _STUB_HW
WORD clear_RX_TX()
{ /* simulate clear rx/tx buffer on target HW */ }

Con este código puedo activar / desactivar el apéndice con la etiqueta del preprocesador _STUB_HW

¿Hay alguna manera de lograr esto sin tener que cambiar mi código de producto y evitar muchos ifdefs? Y no mezclaré código de producto y prueba en el mismo archivo si puedo evitarlo. No me importa cómo se vea el código de prueba siempre que pueda mantener lo más posible fuera del código de producción.

Editar:

Estaría bien si fuera posible seleccionar / renombrar funciones sin reemplazar todo el archivo. Como tomar todas las funciones que comienzan en nRF _ ## y darles un nuevo nombre y luego insertar test_nRF _ ## en nRF _ ## si es posible

Answer 1

Acabo de crear dos archivos ActualDriver.c y StubDriver.c que contienen exactamente los mismos nombres de funciones. Al hacer dos compilaciones que vinculan el código de producción con los diferentes objetos, no hay conflictos de nombres. De esta manera, el código de producción no contiene código condicional o de prueba.

Answer 2

Como dijo Gerhard, use un archivo de encabezado común " driver.h " y archivos de implementación de la capa de hardware separados que contienen las funciones reales y parciales.

En eclipse, tengo dos objetivos y excluyo de la compilación " el archivo driver.c que no se va a utilizar y asegúrese de que esté incluido en la compilación. Eclipse luego genera el makefile en el momento de la compilación.

Otro problema a destacar es asegurarse de que está definiendo enteros de tamaño fijo para que su código se comporte de la misma manera desde una perspectiva de desbordamiento. (Aunque desde su ejemplo de código puedo ver que está haciendo eso).

Answer 3

Estoy de acuerdo con lo anterior. La solución estándar para esto es definir un conjunto abstracto opaco de llamadas de función que son el " controlador " a la hw, y luego llamar a eso en el programa principal. Luego, proporcione dos implementaciones de controlador diferentes, una para hw y otra para sw. La variante sw simulará el efecto IO de la hw de alguna manera apropiada.

Tenga en cuenta que si el objetivo es a un nivel inferior, es decir, escribir un código donde se simule cada acceso de hardware en lugar de funciones completas, podría ser un poco engañoso. Pero aquí, diferente " write_to_memory " y " read_from_memory " Podrían definirse funciones (o macros, si la velocidad en el objetivo es esencial).

En ninguno de los casos es necesario cambiar los nombres de las funciones, solo tiene dos archivos por lotes, archivos de creación o objetivos de compilación IDE diferentes (dependiendo de las herramientas que esté usando).

Finalmente, en muchos casos, una mejor solución técnica es optar por un simulador de sistema de destino completo, como Qemu , Simics , SystemC , CoWare , VaST , o similar. Esto le permite ejecutar el mismo código todo el tiempo y, en cambio, crea un modelo del hardware que funciona como el hardware real desde la perspectiva del software. Requiere una inversión inicial mucho más grande, pero para muchos proyectos vale la pena el esfuerzo. Básicamente, se deshace del desagradable problema de tener diferentes compilaciones para destino y host, y se asegura de que siempre use su compilador cruzado con las opciones de compilación de implementación. Tenga en cuenta que muchos paquetes de compiladores incorporados vienen con alguna habilidad básica de simulación incorporada.