Additional device for Espruino to support 8 pins in parallel (for discussion)

Fully agree to "it does less staff compared to shiftOut". Simple reason is, I stopped implementing all options, and use existing code, to get first feedback. If this idea will not make it to Espruino, at least I didn't waste too much time.

Main target was to arrive at about 20msecs for each refresh. Please see attached file for JS code, its also in an early state. There are some additional time saver, in predefining arrays instead of creating new arrays all the time. Thats all I could find.
BTW, found out that an uint8Array was slow compared to an simple JS Array, at least on ESP32

Lets show, what I did:
My first step was to get shiftOut faster, and failed at a point.
One problem was that shiftOut always handles pins, on each call. Sorry, but even if this takes 500usecs it sums up to 8ms. Thats a lot, if you have 20 msecs for one refresh only.
From my point of view, creating a class which splits shiftOut into several steps, could be an answer.
And it would open the option for more byteport functions like reading 8 pins at a time. allObjects mentioned good old Centronics interface, ....

Next came up with use of GPIO.outw1tc, first version added up all bits and at the end sent it to GPIO.out_w1.... Similiar to your JshPinAddress. Once again there was an end of optimization for speed.
Working with pin by pin was too slow.

Helpful step was to create a translation table from byte to pins in GPIO.out_w1....
Obviously this needs some jsVars to store the table
Implementing this in shiftOut would mean, add a lot of #ifdef ESP32. IMHO, we should try to avoid too much board specific ifdefs in core.

Let me try your changes tomorrow.
Its funny to see same naming. In one of my tests I choose a function called jswrap_io_shiftOutCallbackFast :-)

1 Attachment

• JSSource.txt