I had previously suggested updating the ports for all digitalWrites on nextTick but then remembered that there are devices whose state is changed from read to write by toggling a digital pin. If a user toggled the pin and expected to be able to read immediately (in the same pass through the event loop), their code would fail and it would be unclear why.
This option requires that a user pass an additional parameter to digitalWrite to cause it to be enqueued instead of written imediately and then call writeQueuedDigitalPorts() to actually update the pins on the Arduino.
This API change will not break other io-plugins when used like so:
Coverage increased (+0.002%) to 99.885% when pulling 2717ad4da2381aa7fa34d272d16792a43f2e899f on dtex:master into d08665e8d43996fdceec940540415aed79904eea on firmata:master.
I had previously suggested updating the ports for all digitalWrites on nextTick but then remembered that there are devices whose state is changed from read to write by toggling a digital pin. If a user toggled the pin and expected to be able to read immediately (in the same pass through the event loop), their code would fail and it would be unclear why.
This option requires that a user pass an additional parameter to digitalWrite to cause it to be enqueued instead of written imediately and then call
writeQueuedDigitalPorts()
to actually update the pins on the Arduino.This API change will not break other io-plugins when used like so:
It's working great. Max step speed went from about 550 to 1000 steps per second.
Open to suggestions on method names as "writeQueuedDigitalPorts" is hard on the fingers.