delayMicroseconds again

Maybe this should have been part of the last thread, but I didn’t want this to get lost.

re: delayMicroseconds

Am I the only person who thinks it’s kind of crazy to be throwing away 1/4 us resolution just to make the units come out to us’s instead of .25 us’s? If you give them more precsion, someone’s going to use it.

Then again the present code has the inertia of the function people have gotten used to, and all the existing code that will break if this is changed, will be a hassle.

Ellen Ullman has a fun essay on legacy code, in which she points out that legacies used to be a good thing, and now many tech companies view legacy technology as some kind of albatross that must be taken into account but is mostly just an annoyance.

from the function delayMicroseconds

      // the following loop takes a quarter of a microsecond (4 cycles)
      // per iteration, so execute it four times for each microsecond of
      // delay requested.
      us <<= 2;

I think we felt it was worth the lose of precision to simplify the explanation of the function. That is, we actually wanted a function that would delay for a certain number of microseconds, not the smallest possible resolution. On the other hand, jims has written some code that provides a delayClockCycles() function and a delayTicks() function (which does something like what you're asking for). We could consider adding those to the core too (probably in the advanced / expanded reference).

Maybe documenting a good one-line timing hack wouldn’t be a bad idea, somewhere.
Here it is - a little more explicitly - for those who may not have followed this discussion so far.

To increase the resolution of delayMicroseconds, (and consequently change the units from 1 us to .25 us)
comment out the line “us <<=2;” in the file wiring.c (see below). This will also change the largest working parameter value to 65535 from 16383.

Then recompile - you may have to delete the wiring.o file.

      // the following loop takes a quarter of a microsecond (4 cycles)
      // per iteration, so execute it four times for each microsecond of
      // delay requested.
      us <<= 2;      // comment out this line to increase resolution

Of course I’d like to see more utility functions included in core, such as jims’ timing files and the autoscale functions that were discussed on the developers list.

Because the linker now only includes functions explicitly used in a sketch, it seems like there is not much downside to including more, rather than less, in core. Are there some more subtle issues I’m missing on this; or maybe it’s just a matter of the priority level on the (impressively large) to-do list.

It's partly a matter of priorities and limited time to spend on the development. It's also a matter of wanting to limit the number of functions to keep the platform approachable and easy-to-use. Part of the philosophy of the Arduino software is to try to find the core set of functions that serve most purposes, not provide a function for absolutely everything. Someone who wants that much flexibility is probably better off with something like avrlib. Which doesn't mean that there's not a need to add more - there is, but we don't want to make it too complicated (and four separate delay functions is starting to get there). In any case, these are the kinds of discussions that are probably best held on the developers list.

Part of the philosophy of the Arduino software is to try to find the core set of functions that serve most purposes, not provide a function for absolutely everything.

Yes, exactly! The success of a project like Arduino lies in providing a set of functions that is simultaneously simple enough for the target audience to understand, and powerful enough to get a lot done.

Someone who wants that much flexibility is probably better off with something like avrlib.

Or assembler. All of which you CAN merge with the arduino environment. The beauty of open source is that you can take the existing delayMicroseconds(), cut and paste it into your own sketch code, edit as described here, rename it to delayQus(), and have both sets of functionality.