In PC, many times it does not matter whether the operation takes 1us or 1ms or 1s (many times it should matter but they simply don't care - ever succeeded to prepare and drink a coffee until a PC did it's job? :-( ). So, the natural choice is to spare the programmer's time and use a high level language, which should alleviate the programmer from thinking about the implementation details, including range checking (<flame of the week> I said, should, as life's different, and a strange PDP-originated-assembly language (a.k.a. C) is used widely, instead of a proper high level language; and people like to code today instead of program</flame of the week>).

But, the prudent embedded programmer should make the mcu's life as easy as possible; especially if this is a snippet which occurs within the interrupt. First, it's your responsibility to take care of the limits, so either you make sure it will never overflow the type of your choice, or precede this line by some range checking code (or, as is the sad but most common practice today, ignore it and wonder why it does not work) - preferrably the first. Second, you should precalculate as much constants as possible. I'd for example split your figure into the addition (which is constant), and multiplication, and think very very hard, whether the division is absolutely necessary. I'd also never attempt to make the routine absolutely flexible in regardas of crystal value; rather, prepare a set of constant for the common crystal frequencies (7.3728MHz, 11.0592MHz, 12MHz, 14.7456MHz, 16MHz, 18.432MHz, 20MHz, 22.1184MHz, 24MHz). At the end of the day, you'll find out that these are in fact only 2 sets of frequencies with a relatively big common denominator and that'll govern the chosen "simplification" pattern.

YMMV

JW