piscsi
piscsi copied to clipboard
PiSCSI
New hardware with minimal HID
Info
Hi team. I'm using Rascsi with vintage synths and samplers. The oled display is invaluable for when each scsi ID represents a HDD or CD containing samples. What would take the project to the next level would be the use of a rotary encoder with push switch to allow the user to navigate through a basic menu structure allowing the user to change the mounded ISO image on an attached CD drive, the disk in a MO drive and so on. I'm sure this feature would be useful to other demographics too.
The hardware doesn't need much of a change, however, the current python for the oled would need a rethink.
Given that there is discussions around having the oled move from polling to subscription, i thought it a good time to raise my idea.
@hsiboy - thank you for the suggestion! Its definitely an option for control.
My 2 cents on things - the tiny OLED screen is going to really limit the user experience for editing things. It wouldn't be a big deal to upgrade to a larger OLED display.
I definitely agree that it wouldn't be much of a hardware change. RaSCSI eats up most of the available GPIO pins, but we could use some sort of I2C device to handle the rotary encoder.
What do you think about adding a 3-4" touch screen and creating a version of the web interface that is touch-optimized?
So I have cooked something up to prototype with in this direction.
Personally, I don't like the idea of a touchscreen due to the size. I'm kinda thinking along the lines of a 1U 19" studio rack bay for 4 separate rascsi devices. At least I find it useful to have choice and want to use all SCSI IDs for each sampler. Though, I will probably switch to a slightly bigger 1.3" 128x64 I2C display once it arrives.
@bzeiss I've done something very similar, but only two push buttons, because my rotary encoder also has a button.
I've got a larger LCD display, and I've used one of those cheap Chinese i2c display interface adapters. The hardware works, but I need to branch so I can add the LCD lib.
For me, I don't want to use the web interface every time I want to mount a new sample ISO and the RaSCSI won't be located at arms length, so a bigger display is a must.
@hsiboy I'm not sure yet about the acutal number of buttons. I was thinking something like two buttons for recalling configurations and one shutdown button. Or maybe one back button and one shutdown button. I want to use the rotary encoder button (my encoder has one as well) mainly for navigating the menu on the display. I think the display resolution will be good enough, it kind of works fine for me on the gotek drives. I rather don't want to waste two units in the rack, I have too few of them.
I love this!! It would be awesome to make a simple control board (like you prototyped) that could be installed apart from the rascsi.
Would something like this be interesting? (very... very.. very... rough concept)
Yes, absolutely. This is essentially what I was going for. My intuitive right-handed biased reaction would be to want to rotary encoder to the right of the display though ;-) I'm curious about that IC. Are you thinking about separating the front panel from the I2C bus with its own atmega168 or so?
By the way, for the stuff I wanted to toy around with, I also wanted to do something about the power management. It would be cool to have proper startup and soft shutdown switches/buttons or something like that. It's probably step two after everything else, but still, it probably makes sense to think about this as well when designing a front panel.
Here's what I'm thinking so far.... If you're using a RaSCSI, you'd use the 5 pin connector on the left. But, I also wanted this to work generically on any Raspberry Pi. For the RaSCSI use case, the 40 pin header probably won't be populated.
Ditto on the power management concept. I'd love to have a battery connector so that we could have a safe shutdown option. But, right now, with the chip shortage, I haven't been able to find any battery controllers that will meet our needs. I'm not an Electrical guru, so that's going to take more work (If I do the design, anyway) :]
The IC on this is a I2C I/O Expander, similar to the MCP23017 that @bzeiss is using (but a little less expensive and seems to be easier to find)
- Rotary Encoder: https://www.mouser.com/ProductDetail/Alps-Alpine/EC11E15244B2?qs=m0BA540hBPfDpUEkDmFV5A%3D%3D
- Discrete expander: https://www.mouser.com/ProductDetail/NXP/PCA9554APW118?qs=LOCUfHb8d9t6Q6oURZSRTg%3D%3D
- OLED - (Should work with most?) https://smile.amazon.com/Self-Luminous-Display-Compatible-Arduino-Raspberry/dp/B09JWLDK9F/ref=sr_1_4?keywords=i2c+oled&qid=1639278355&sr=8-4
This is looking really nice now! I like the idea to keep it universal with the gpio pins. This is something I would happily use :-)
About the power. One circuit that I came across and that looked pretty simple and sweet with a small footprint is this one:
https://othermod.com/raspberry-pi-soft-onoff-circuit/
It's something I want to test out some day.
Hey @akuker your design is looking very familiar... https://buildalightshow.com/pixel-controllers/117-fpp-pi-control-cape-pioled.html
About the power. One circuit that I came across and that looked pretty simple and sweet with a small footprint is this one:
https://othermod.com/raspberry-pi-soft-onoff-circuit/
It's something I want to test out some day.
That looks very promising! However, it relies on the "TXD" pin, which is also used as the D4 data line by RaSCSI.
I think we could figure out a way to use a spare discrete on the I/O expander for the processor to flag when its ready to shut down. We could put a 20 second delay on it using a R/C circuit.
@hsiboy What kind of lcd did you want to use or have in mind? I'll probably start to do some more abstraction over screen libs and sizes pretty soon, starting with the 128x32 oled and a 2.x" oled I think I have somewhere around.
Hey @bzeiss I was going to use a 4x20 alphanumeric LCD (or its OLED equivalent), I2C based. The LCDs are cheap and plentiful and easily readable from a distance.
Happy New Year btw.
@hsiboy happy new year to you as well. Ok, I'll order one of those for testing as well just in case.
Hey @bzeiss I'm way behind on the changes you've been making, because i took a slight deviation.
I woke up one morning remembering something i had used in my professional work, some time ago LCDProc https://github.com/lcdproc/lcdproc
LCDProc uses the idea of a server client, so the LCD display can be physically located somewhere else and updated over TCP/IP. Thinking about my setup, having the RaSCSI in the rack, close to the gear, with a small remote display, located near the keyboard/workstation for control and information.
It was then i remembered that I had an old Matrix Orbital display that was intended for use in a 5.25" drive bay. Its a graphics LCD with some LEDs, some push buttons etc in a neat package. It was available in USB, Serial, I2C and is fully supported by LCDProc. LCDProc supports a lot of displays and interfaces.
LCDProc was supported by a number of softwares, through the use of "plugins", so I started thinking about a plugin for RaSCSI, and thats the rabbit hole i've been down, with a couple of bald Yaks for company.
Your thoughts?
I'm not exactly sure about the use case for that. If you use RASCSI in a 19" rack with a bunch of samplers, you probably want to put your Raspberry Pi into that rack as well and control it directly from the rack. That's what I'm aiming at. In this case, there is no advantage in decoupling display from the Raspberry Pi over tcp/ip. If you have your RASCSI on a desk with your old Mac and want a hardware interface, you also have the Raspberry Pi+RASCSI standing right next to your Mac and thus within the reach of your hand. Personally, I think that the tcp/ip solution would make sense if you really have the control board physically somewhere else than the RASCSI. For that use case, you might just as well use the Android app. So I can't think of a convincing use case to justify the effort (for myself that is) right now.
That said, there are some first steps towards and abstraction already in there. So it is probably possible with some more refactoring effort to support multiple ways to draw the menu. I'm not sure whether I'm motivated enough to do this though. I have more or less all features in place for the first pull request. It's mostly linting+fixing, documentation and adaptation of easyinstall.sh what is left now.
For that use case, you might just as well use the Android app. Or the web app ;-)
FYI: @bzeiss , my boards are still stuck in limbo at JLCPCB. I'm assuming the lunar new year is slowing them down. If the status is to be believed, I should get them mid-Feb.
@akuker My board also hasn't been sent out yet, but I did add a few other ones which current delay the shipping. I guess I won't have them before mid-Feb as well.
This is done and has been released into the wild! https://www.tindie.com/products/landogriffin/raspberry-pi-oled-controler-board/?pt=ac_prod_search
Dumb question. How do you get this control board to work? I built the hardware and ran the easyinstall script to setup the control board, but nothing shows up on the display. I used Adafruit's test scripts to verify the LCD works, but I can't get anything else to show up on it. I'm running the latest PiSCSI image from November.
@jzmacdaddy There are sometimes problems with fetching of the python packages if I recall correctly. Maybe try to run it manually. In the python/ctrlboard directory, there is a README.md with instructions. Maybe the problem is more visible when run manually. Make sure that the systemd ctrlboard service is stopped before you try this.
@jzmacdaddy In addition, there is a bug in the Nov 2023 release that prevents the Control Board from working. It has been fixed in the development code. https://github.com/PiSCSI/piscsi/pull/1394
You can either wait for the next release, or build the latest code by yourself. Please let us know if you want to try the latter!
@jzmacdaddy In addition, there is a bug in the Nov 2023 release that prevents the Control Board from working. It has been fixed in the development code. #1394
You can either wait for the next release, or build the latest code by yourself. Please let us know if you want to try the latter!
Thanks. I assume it works in the release prior to November? If so, I'll give that a shot.
@jzmacdaddy I don't recommend using an earlier release, because of Python dependency hell. Neither of the Python clients (in particular the Web UI) will work out of the box, forcing you to have to go in and manually fix the dependencies. IMHO it will be less effort to roll forward to the latest development code.
To make a long story short, in all previous piscsi releases we had loose Python dependency mapping. And when a key Python library released a major breaking change late last year it completely broke our dependency tree. So no prior piscsi release version will work fully out of the box anymore. Lesson learned to do very explicit Python dependency mapping...
I honestly just want to verify my control board is working. Are there instructions on how to roll forward with the latest code for a rookie like me?
Sure, happy to help. The wiki has a section with instructions: https://github.com/PiSCSI/piscsi/wiki/Setup-Instructions#upgrading-an-existing-installation-to-the-latest
if you get stuck following those instructions, may I ask you to start a new discussion thread? https://github.com/PiSCSI/piscsi/discussions
Please note that the compilation of C++ code can take hours on low powered RPis.