Go Down

Topic: writeDigital() too slow (Read 4595 times) previous topic - next topic



I am not sure, if this question was already asked.
Playing with arduino and oscilloscope I've found that simple code like

digitalWrite(pin1, 1);
digitalWrite(pin2, 1);

results in a delay of 4.75us between edges. This is with interrupts disabled. Assuming that ove cpu instruction takes 2 cycles (there are also single cycle istructions and 4-cyclers, but majority is 2 cycle) it should mean about 38-40 cpu instructions for single digitalWrite() function.

Isn't it just too much for operation that in cpu op-code would take less than microsecond? I know that it is possible to play directly with bits (as fast as one could manage his asm or lowe level c code), but  wonder why is it so slow, what is the reason and would it be optimized in the future.



You are free to look at the source code for digitalWrite, and see what it is doing. There's probably more going on than you think.

And, yes, under some circumstances, it could be optimized. Which hardware would you like to drop support for?

There are options, as you noted, if you think digitalWrite takes to long. Portability goes out the window if you use some of them.
The art of getting good answers lies in asking good questions.


An interesting thread to read is - http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1267553811/0
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)


Just read about direct port access, there is something in my first tutorial and I will post more about it in the future:


Dec 21, 2010, 11:01 am Last Edit: Dec 21, 2010, 11:13 am by snizamov Reason: 1
Thank you all!

I have found that suggested "digitalWriteFast, digitalReadFast, pinModeFast etc" approach is probably the best way to go. The last version published recentlz is hopefully interrupts safe.  


PS I am not sure if PaulS and Paul Stoffregen are the same person :)
Kudos to both of them anyway


I am not sure if PaulS and Paul Stoffregen are the same person

I am. We're not.
The art of getting good answers lies in asking good questions.


Dec 23, 2010, 04:50 am Last Edit: Dec 23, 2010, 09:46 am by bperrybap Reason: 1
Pay close attention to the licensing of the digitalfastwrite code on the google code site. (It is not cleanly/properly done)

The code itself in the header file does not contain
proper copyright notices nor the proper GPL notices.
So in the absence of any other notice, you have to assume the copyright
is as noted on the main google code page or worse that it is not "open source" at all and subject to the personal copyright of the author(s).

While I'm a total fan of GPL and totally detest LGPL (which is what all the Arduino supplied libraries are),
many others seem to not agree with my way of thinking.

LGPL allows closed source projects to be created using open source, while GPL does not.
GPL v3.0 has even stricter restrictions against closed source and
patent related issues than the previous 2.x license.

The current "digitawritefast" code license as stated on the main google page for this code explicitly calls out GPL v3.0
which means "as is" you cannot use this code in a closed source project unless you get a special license agreement with the author(s).

I'm a big fan of open source, so I have no issues with that; however,
some people wish to create closed source projects/products
perhaps to make money, and to save time, wish to incorporate the works of other open source authors.

In its current form, that use along  with any other
use in a closed source project is prohibited by the GPL license.

--- bill


Much discussion (how slow is it, how to make it faster, how fast can you go) here: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1230286016

Go Up