piscsi
piscsi copied to clipboard
PiSCSI
Add ID EEPROM to RaSCSI board
An ID EEPROM is recommended for Raspberry Pi HATs so that drivers can be automatically loaded when the corresponding HAT is connected, and automatically not loaded when a different HAT is connected. In the particular case of RaSCSI, it would also facilitate indicating to the software whether the standard or fullspec board is connected and it could adapt accordingly.
@akuker I'm wondering, which future board revision do you think it would be a good idea to work in the hardware changes to add this? I'm willing to make the changes to add this to a future board revision, but since the boards you've designed are pretty crammed as-is I'm curious what your thoughts/ideas are.
Another thing, I feel like putting a README in the hw directory containing a brief description of each hardware revision and its history would be really helpful.
I was thinking of starting a "3.0" board sometime in the future.
When I started digging into this a couple months ago, I thought I ran into a problem. It looked like the GPIO header pins for the HAT EEPROM conflicted with some of the pins used for RaSCSI signal lines. I haven't found a definitive specification on how this is supposed to be wired though.
Now that I'm double-checking this tonight, the Ki-CAD "Hat" template shows that the EEPROM data/clock lines go to pins 27/28 of the GPIO connector. These are currently unused in the RaSCSI design, so I don't know what I was thinking before.
The 2.7 version of the board originally had the EEPROM on it. There is an area in the center of the board that is wide open. That used to have the EEPROM on there. (Its probably still in some of the previous revisions in Git) You could also put the eeprom on the bottom of the board.
You are welcome to create a "3.0" version and see if you can get something going!
I like the README idea too. This information is available on the wiki https://github.com/akuker/RASCSI/wiki/Hardware-Versions . But, it'd be nice to at least have a README that points to it. I think I shall do that tonight
@quorten - I guess I didn't look hard enough for the official documentation - https://github.com/raspberrypi/hats/
The camera flex cutout definitely wont fit without a major redesign. The display flex cutout might be do-able, but not sure its worth it.
So I've started looking through the schematics, and I might have spotted a design oversight.
What was the particular problem that the Raspberry Pi 3.3v pull-up resistors were added to the RaSCSI board to solve? Normally using the software-configurable pull-up resistors inside the BCM SoC is sufficient. A compelling reason to do otherwise should probably be accompanied with a note in the schematics since this is seen as a common beginner oversight with Raspberry Pi.
If I recall correctly, when the Raspberry Pi boots, all GPIO pins are initialized as outputs and then pulsed low-high-low, so using the pull-up resistors for the sake of pre-boot behavior is moot. Raspberry Pi uses approximately 50k resistors for internal pull up/down.
EDIT: After the boot-time pulse, looks like the GPIOs are then either set to their Device Tree config or inputs. It could be that the low-high-low pulsing happens through different pull up/down resistor configs.
What was the particular problem that the Raspberry Pi 3.3v pull-up resistors were added to the RaSCSI board to solve? Tbh - I'm not sure. They were on the original RaSCSI design, and I just left them there.
During runtime operation, the direction of the GPIOs is changing constantly, so perhaps the original developer ran into issues? I'm totally open to removing them if you don't feel they're necessary.
So I'll put this quick observation out here, it appears that having two of the bus transceiver chips rotated around 180 degrees is non-ideal for early-boot behavior, rotating them back 180 degrees, switching the A and B sides, and negating the software assertion of the direction signals would allow the early boot assertion of the direction signals to be such that all the transceivers are put in input mode until the Raspberry Pi finishes booting. That would definitely eliminate any need for the Raspberry Pi 3.3v pull-up resistors. (Plus it would make assembly easier too.)
Another thing, I noticed that there are no bypass capacitors on this board, although there should be one 100 nF bypass capacitor for each transceiver chip. (Of course, many early RPi HAT board revisions get away without this design best practice just fine.)
For the current design, most of it was just copied from Gimons' original version. I wanted to get comfortable with the initial design before changing things. That being said.... I'm fine with changing things :)
That would definitely eliminate any need for the Raspberry Pi 3.3v pull-up resistors.
Agreed, but it would drive changes to the software. Right now, there isn't a way for the software to know what board it is connected to. If we add the eeprom, that would allow the software to detect which way those chips are installed.
I noticed that there are no bypass capacitors on this board, although there should be one 100 nF bypass capacitor for each transceiver chip.
I agree this would be a good update
Nope - Let's close it. If we decide to add an EEPROM at a later date, we can do it. But there aren't any immediate plans to do it.
Bummer! I would love to coordinate the inclusion some time in the future. Sure, those two years were big news for me but not for this ticket.
@quorten Just re-open the ticket when you are ready to start working on it.