MarkT:
bperrybap:
The real question is if you want a delay of 1us when the delay you are asking for is 0?And my question of curiosity is why are you asking for a delay of zero?
Is this caused by some sort calculation that results in truncation?No, this is a real glaring bug and it should be fixed in the library source. There are many times
you will want to calculate a delay and don't want to have to deal with zero as a special case.
The restriction on the argument size is also a bit yucky and incompletely documented - it depends on the system
clock speed whetherdelayMicroseconds(20000)does what you expect, for instance!
My questions were totally separate from the question as to whether the library should be fixed.
And we still don't know if k7michal needs a delay of 1us rather than no delay when a delay of zero
was asked for.
Whether it should be fixed could be argued either way. It could be documented as explicitly not
working for 0 or it could be fixed, but fixing it may have side effects like reducing the minimum supported delay.
I always try to do as much at compile time as possible so
typically when I have code that does sub millisecond or even sub microsecond delays, there is no calculation occurring runtime
because the delay is usually do to some hardware constraint that is known in advance.
Any needed delay value calculations are all done at compile time.
Where cycles really matter, I use macros that ensure that if the delay is zero or not needed,
that any delay related code is completely eliminated.
--- bill