Closed fgrfl closed 3 years ago
Also note that rawSHT1X should set IO0 to input, IO1 to output, and IO2 and IO3 according to the input settings.
I added tracking of the IO State changes to every raw function that potentially writes to the IOs: rawAISample, rawDIO, rawCounterPWMDIO, rawAIBurst, rawAIContinuous and rawSHT1X
Is this change sufficient?
I am getting a bug where when I use eDigitalOut if I open Channel 0-7 and then open Channel 8-15, channels 0-7 close. The same in the reverse. Is this bug fix supposed to fix this? Because it does not seem to for me.
This pull request was mainly looking at the IO terminal tracking. The D-line issue you are seeing should be a pretty quick fix, and I will make a new branch and pull request for it here shortly.
On linux (__os_name != "nt"), when setting one of the IOs to Input or Output, all of them are changed, not only the channel you want to change:
If you call eDigitalIn(0), IO0, IO1, IO3 and IO4 are set to input. If you call eDigitalOut(0, 1), IO0 is set as ouput and high, IO1 to IO3 are set to output and low.
For D0-D15, the current state is fetched from the U12 and the newly written state only differs in the channel given as parameter.
On windows, the C function EDigitalIn or EDigitalOut is called, which caches the current state locally.
Since the current direction of IO0-3 is not returned by the U12, the state needs to be cached locally like in the C implementation.