You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Though it's a hack, passive SCSI bus termination (resistor-based) could be just good enough to get reliable communications with parallel port devices. Or it might require crude modifications to get sufficient termination behavior.
This could also address issue #4 since RaSCSI uses sequential BCM GPIO ordering for the data signals and (to the extent it matters) the control and status signals.
The text was updated successfully, but these errors were encountered:
The interesting thing about the RaSCSI project is that it is very similar to the v1 design of pi-parport. Personally I plan on using the RaSCSI board as a SCSI hard drive and I'll see if I can make it double as parallel port interface.
We should have considered ourselves foolish not to realize this...
On pi-parport, if we connect A13, Y13, PERI_IN, and PERI_OUT rather than grounding the input and not using the output, api-parport board is also capable of being used as a RaSCSI board. However, you can only use it as exclusively an initiator or a target at a time, changing roles requires switching a DB25 rewiring dongle.
Investigate writing a Device Tree Overlay and building a DB25 rewiring dongle to allow using the RaSCSI board as a pi-parport parallel port interface.
https://github.com/akuker/RASCSI
Though it's a hack, passive SCSI bus termination (resistor-based) could be just good enough to get reliable communications with parallel port devices. Or it might require crude modifications to get sufficient termination behavior.
This could also address issue #4 since RaSCSI uses sequential BCM GPIO ordering for the data signals and (to the extent it matters) the control and status signals.
The text was updated successfully, but these errors were encountered: