AutomatedRedstone-1.12.2-6.0.2, TIS-3D-MC1.12-1.3.0.15, forge 2529.

I was doing some initial spitballing of some time measuring stuff using TIS-3d and the time sensor from automated redstone, so I was doing some random stuff with it, but I kept noticing that for whatever reason, one of the execution modules would lock up waiting on the serial port.

In order to get a clearer test, I put together a simple test rig with a serial port connected to a bit splitter, and a sensor reader connected to that. Made sure I had the bit ranges/offsets set usefully, and wrote a small program which just divided the time output by 50 (getting an hour value from the 1200 range of a time module measuring in-game day intervals).

Added 65 to make it a letter and send that on to a console for a simple display.

There's basically nothing in this configuration that should possibly get stuck, but somehow, within 5 to 40 seconds, it consistently does -- as long as it has a sensor in the sensor reader. No sensor, no deadlock.

Here's a video of it doing such:
https://www.youtube.com/watch?v=3MlXkpNyu8k

Notably, you can see another machine in the background which is essentially the same thing, but in a slightly different physical arrangement. Same parts, same settings, program slightly altered purely to account for the different directions. It doesn't lock up, whether the sensor is there or not.

I am at a loss. I don't know if this is your concern or the TIS-3d dev's, but since this is involving your serial driver (and the conditional thing of 'needs a sensor present'), I thought I should check with you first.

That's weird.
In my serial driver, the methods that ask the bit splitter whether a value can be read or written, both just always return true, so it never blocks and a deadlock should be impossible. And because these operations just read or set an integer variable (with some bit operations applied) whether a sensor is connected or not should also have no effect.
The only thing I could think about, is that maybe the serial port suddenly decides for whatever reason that is no longer connected to the bit splitter (maybe related to block updates when the redstone state changes). I'll investigate that.

About the wires connected to the bit splitter having no bandwidth applied, is because the Bit Splitter is just implemented as special type of 32-bit Signal Wire. The only difference is that the side connections are configured in a GUI instead of right-clicking the sides and that a bit transformation is applied.
It's intended that a Bit Splitter shares its internal combined signal state with the wire it's connected to and also with other bit splitters connected directly or via wire. If you don't want this, just disconnect them with sneak right-click in the same way you would disconnect wires from each other.

By the way I really like to hear that there are actually people using this interaction feature between TIS-3D and my mod, considering that probably not that many use TIS-3D at all :)

I'm pretty sure at this point there's something funky going on with the internal state of the bit splitter wire, although I can't begin to guess what exactly is wrong.

I'm able to sometimes get it into a indefinitely (I can't promise permanently) working state by futzing around with solid redstone wires connected to the bit splitter.

I have some footage of this sometimes working, if that'd at all be useful for me to upload.

The bit splitter wire also seems to propagate signals to and from solid redstone wires without any bandwidth assigned. This is also demonstrated in the footage I have. It seems to me this should probably not be happening?

I found out that the deadlock exactly happens when value emitted by the bit splitter changes while a module is performing a read operation on the serial port. Unfortunately these read operations take at least 2 ticks even if the computer is running at full speed so it's nearly impossible to ensure in general that the value would never change during a read. And this problem also only occurs in 1.12 but not in 1.11 so I forwarded this to TIS-3D now:
MightyPirates/TIS-3D#76

When you say 'full speed', out of curiosity, do you mean 'redstone 15' or 'redstone 75'? TIS has weird not-well-documented mechanics for 'overclocking', so I'm curious if what I was experiencing with the 'consistently working' states was actually it managing to complete the read in less time due to running at maximum internal speed.

Thanks for looking into this, either way; I adore TIS-100, and what i love about TIS-3d versus more traditional computer mods is that stuff like computercraft, opencomputers, etc are very prone to 'turn-key solutions'. I like needing to solve problems, and TIS-3d, if nothing else, requires me to solve each problem independently.

Its primary shortcomings have to do with the fact that TIS-100 is -- aside from its game origin -- fundamentally a data processing language, and TIS-3d doesn't have a lot of ways of getting input to process.

I think your mod could do a lot to help with that.

TIS-3D fixed this, so it can be closed here as well