2009-10-26 8 views
10

Estoy escribiendo firmware para un PIC32MX, usando HiTech PICC32. Uno de los problemas que quiero evitar es que, dado que la mayoría de los pines tienen varios nombres (por ejemplo, AN0 = RB0 ​​= CN2 = PGED1), yo u otra persona podría usar accidentalmente RB0 sin darme cuenta de que ya se utilizó AN0. (Esto en realidad puede ser catastrófico, ya que la configuración incorrecta de un pin analógico/digital puede ocasionar un consumo excesivo de corriente y liberación de humo esencial.)Macro que indica las clavijas de E/S utilizadas

Además de documentar exhaustivamente cada pin utilizado, me preguntaba si había una manera rápida de hacerlo. para resolver este problema al nivel de la codificación. Quiero una macro que las personas (principalmente yo mismo) puedan usar, digamos CLAIM_PIN(58), que emitirá una advertencia o un error si se ejecuta dos veces.

(No quiero esto a toda costa, si la única solución posible es demasiado horrible o imposible de mantener, entonces me olvidaré de eso y solo desarrollaré una reputación de romper a llorar o prenderme fuego o algo así. también vi esta pregunta sobre macro producing macros, que descarta eso.)

Debo aclarar: el código está escrito en varias unidades de compilación (al menos, creo que esto es lo que significa la frase). Tengo un archivo .h/.c para mi código A2D, similarmente para SPI, y de manera similar para varios periféricos que solo usan ciertos puertos de E/S. El espacio no es realmente un problema, mi código deja mucho espacio en el PIC32MX; también puedo usar otra bandera __DEBUG para eliminar el código de comprobación de PIN para el uso final.

+0

sin respuesta, pero es una buena pregunta. (Supongo que podría ser más fácil si la gente de Microchip se saliera de sus culos y admitiera C++). –

+0

Bueno, no tienen un compilador Linux de todos modos, entonces es HiTech para mí (prefiero sus macros de todos modos). – detly

Respuesta

6

Ok, aquí. Sin costo de tiempo de ejecución.

#define CLAIM(n) struct busy##n {} 

CLAIM(58); 
CLAIM(58); 

Si correr el doble que será de error out:

z.c:4: error: redefinition of ‘struct busy58’ 

Para extender el cheque a múltiples unidades de compilación que se desea envolver la macro en #if DEBUG porque estaríamos usando el enlazador para detectar el choque y, por lo tanto, tendría una huella de tiempo de ejecución.

#define CLAIM(n) char busy##n = 1; 
#define CLAIM(n) void busy##n() {} // bdonlan 
+4

Sin embargo, esto solo comete errores si están en la misma unidad de traducción. – bdonlan

8
#define CLAIM_PIN(n) char claimed_pin_##n; 

Ahora, cuando dos piezas de código tratan de reclamar un perno, el símbolo será doblemente definido y, o bien el compilador o el enlazador generará un error.

Editar: Basándose en los comentarios, esto podría resultar mejor:

#define CLAIM_PIN(n) void claimed_pin_#nn(void) {} 
+2

Esto usa un byte por pin. Si eso es un problema, el OP podría considerar las opciones del vinculador para ubicar estas definiciones en su propia sección y descartarlas de la imagen final. – bdonlan

+0

Ha pasado tanto tiempo desde que utilicé una arquitectura en la que un byte importaba, ni siquiera había pensado en eso. –

+2

Pero no es un error. Es perfectamente legal C hacerlo, incluso en múltiples unidades de compilación. – DigitalRoss

2

Si se lo puede permitir la sobrecarga de tiempo de ejecución o si esto es sólo para la depuración, que acababa de crear algo así como una función de IOPinOpen() que hizo un seguimiento de los pines en uso en lugar de lidiar con el macro trickery.

Por otro lado, Mark Ransom's updated answer valía un +1.

Cuestiones relacionadas