Use fixed size types in 'hwtimer_arch' function signatures


While working on the MSP430 hwtimer implementations, I came to wonder whether we should use fixed size type (i.e.: uint32_t or uint8_t) instead of ambiguous types like long or short.

It seems to me fixed bit sizes would be preferable, since we work on various architectures for which long or short may not mean the same number of bits. What do you think?

Hi, I think that this is dependent on the use-case. For the timer it may be a good idea, as for example type definitions in the network stack. Where I see a problem with fixed type sizes in data that comes from certain periphirals, though (e.g. network hardware addresses, which are currently 16-bit fixed size in the transceiver module, though the cc1100 chip e.g. uses 8-bit addresses, IEEE 802.15.4 uses 64-bit AND 16-bit addresses, and when we want to have Ethernet support sometime we have to deal with 48-bit addresses).


Hello Martine,

Indeed, it depends on the use case.

In the case of the 'hwtimer_arch' functions, we have two situations:

* the definition of a counter value (be it absolute or relative) which is currently implemented as an 'unsigned long' ; since we want to keep high precision (that is: high frequency) while allowing for long enough delays to be specified, I propose to stick on 32-bit values (==> use 'uint32_t')

* the definition of a timer ID, currently done using 'short' ; since it is highly unlikely that any MCU will offer us more than 255 hardware timer instances to play with, I propose to use 8-bit IDs (==> use uint8_t)

Best regards,

Le 12/02/2014 10:10, Martine Lenders a �crit :



I understand why it was done that way. But what do you think about my proposal: do you think too that switching on fixed-size types is a good thing, or would you stick with generic types?


Le 12/02/2014 11:36, Kaspar Schleiser a �crit :