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).
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)