martinrusk / xpldevices Goto Github PK

Was missed when renaming everything from Python style to C++ style.
Problem: compatibility

Just renaming LedShift is not a good idea.
ShiftOut needs only HIGH/LOW state and no timer. So we will provide a new class or even make ShiftOut the parent class of LedShift.
Separate class is preferred, since we can use a compact storage with one bit each, so just needing 8 int8 words.

Useful for multi position switches where only "on" switching is required.

Use direct port access for read, as for the setting of the address lines. No SREG handling required.

The LedShifter device could be used basically unchanged for output shift register; actually, the only change required is that ShRegs come in blocks of 8 outputs.
As a generalization, both LedDrivers and [chains of] shift registers could be grouped in a single device by simply adding a parameter/attribute with the number of 8-bit blocks.

An alteration is anyhow necessary for daisy-chained DM13A.

Bypass the digitalWrite. Further optimization is possible by only once saving SREG and setting cli().

A consideration: IMHO, in practice, it would make sense to limit this to multiplexers.
For other expanders (MCPs and, even if not [yet] foreseen, shift registers/SPI MCPs, particularly if chained) reading one input directly would mean reading all their input set, which basically defeats the purpose of having a quicker direct read.

Add an overloaded method calling registerCommand.

Since the shift register driver lines are also heavily switched, it would make sense to use the direct GPIO handling for those too.
This would mean adding one more byte for each line (3 bytes) per device, but given the expected number of devices, I would not expect this to be a significant drawback (to be evaluated of course).

Since the shift register driver lines are also heavily switched, it would make sense to use the direct GPIO handling for those too.
This would mean adding one more byte for each line (3 bytes) per device, but given the expected number of devices, I would not expect this to be a significant drawback (to be evaluated of course).