pi-parport connected via SPI

[quorten]

I've been looking at the pi-parport project for quite some time, but one thing that threw me off from using it was the number of GPIO pins the hardware interface required, which doesn't leave much room left for other peripherals.

Of course, I've also been a relative novice with Raspberry Pi and embedded and now I realize that it should be fairly simple to connect the hardware interface through SPI via a GPIO port expander chip. (I2C would also work, though it couldn't be as fast as SPI.) With the right chip or two, the hardware changes should be fairly simple.

The driver changes would depend on which chip is selected. Though it should be easy to get a basic interface running, there may also be room for tweaking and optimizing the speed of the SPI interface above the basic results.

It may make more sense to add this as a second hardware interface option and maintain both in parallel rather than have this be a successor design. In any case, I'm open to thoughts on this idea and thought I'd post it here.

[garlick]

Yeah, it's a bummer that it pretty much eats your whole pi.

The SPI expander would be interesting to try. The extra latency might be a concern for some applications, though maybe not for those game controller ROM people who seem to manage to bit bang through ppdev in user space!

If you do try it, one thing to look at is the calls to gpiod_cansleep() in the driver, which (I predict) will return true for an SPI expander and cause the driver to abort. You could take those tests out and see how it goes. The camera driver I was working on originally would disable interrupts while bit banging. That's probably why those checks are in my driver (sleep with interrupts off == bad).

Edit: forgot to mention - driver changes (other than the cansleep check mentioned) shouldn't be needed if you use one of the expanders that already have a kernel driver that makes them appear as gpio devices. You'd just have to prepare a new device tree overlay.

[andrewtubbiolo]

Hi Andrew and Jim:

FYI I've been using this project for about 8 months now on a SBIG St-8 ccd camera. Be careful on the timing requirements for your application Andrew. Make sure the serial xfer's in and out to your shift register won't mess up any timing of your parallel port application. What you are describing is the same sort of thing USB to LPT ports try to do, and even USB to IEEE1284 ports would not work for me. Also keep in mind when I'm clocking my camera the bit banging soaks up an entire core. I was hoping I could port this down to a Pi-zero, but I don't think it'll work. I'll try it soon and see how bad the train wreck is.

Andrew

On Wed, Mar 11, 2020 at 4:57 PM Jim Garlick notifications@github.com wrote:

Yeah, it's a bummer that it pretty much eats your whole pi.

The SPI expander would be interesting to try. The extra latency might be a concern for some applications, though maybe not for those game controller ROM people who seem to manage to bit bang through ppdev in user space!

If you do try it, one thing to look at is the calls to gpiod_cansleep() in the driver, which (I predict) will return true for an SPI expander and cause the driver to abort. You could take those tests out and see how it goes. The camera driver I was working on originally would disable interrupts while bit banging. That's probably why those checks are in my driver (sleep with interrupts off == bad).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/worlickwerx/pi-parport/issues/31#issuecomment-597937843, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJINSVMK5ZOMB4XK25CHWDRHAQO3ANCNFSM4LGAHU4A .

[quorten]

Andrew,

Interesting point to note. On one hand, I assumed it should work pretty well since early 2000s "Windows XP" era PCs with a parallel port are connected in a serialized fashion via the LPC bus to the Super I/O chip.

The maximum Raspberry Pi SPI clock speed of 125 MHz should be comparable to the timing delay introduced by the LPC bus or ISA bus, provided that high-frequency circuit design best practices are followed.

Yeah, good points to keep in mind... for me I was hoping I'd have a versatile Raspberry Pi parallel port for any future use. My present uses are mostly to interface with a Windows 9x printer and scanner, so therefore about 0.120-0.360 microseconds latency is pretty good for me. A 22 MHz SPI clock should be a good starting point many applications.

[andrewtubbiolo]

Hi Andrew:

Running an SBIG ST-8 camera is pretty demanding. It involves intense

input by clocking out a 1.5 megapixel CCD at 16 bits per pixel. Unlike most parallel port applications it's an awful lot of in and very little out. I think piparallel port is pretty capable. It's worth trying out.

Interesting insights into the advanced parallel support chips from the 00's PC's. I wonder if that serial stream fed a state engine that did all the real time bit banging and data x-fer?

Andrew

On Mon, Mar 23, 2020 at 3:56 PM Andrew Makousky notifications@github.com wrote:

Andrew,

Interesting point to note. On one hand, I assumed it should work pretty well since early 2000s "Windows XP" era PCs with a parallel port are connected in a serialized fashion via the LPC bus to the Super I/O chip.

The maximum Raspberry Pi SPI clock speed of 125 MHz should be comparable to the timing delay introduced by the LPC bus or ISA bus, provided that high-frequency circuit design best practices are followed.

Yeah, good points to keep in mind... for me I was hoping I'd have a versatile Raspberry Pi parallel port for any future use. My present uses are mostly to interface with a Windows 9x printer and scanner, so therefore about 0.120-0.360 microseconds latency is pretty good for me. A 22 MHz SPI clock should be a good starting point many applications.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/worlickwerx/pi-parport/issues/31#issuecomment-602901643, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJINSX75CIL6NDAXLZINYTRI7SLPANCNFSM4LGAHU4A .

[quorten]

A few observations related to this feature discussion.

• The current GPIO pi-parport is not as efficient as it could be. If the 8-bit DATA was aligned to BCM GPIO16...GPIO23, then only about 7 CPU instructions are required to write all 8 bits simultaneously, and only about 4 CPU instructions to read 8 bits. The current bit scrambling/unscrambling implementation could require, by one estimate, around 113 CPU instructions to write 8 bits, and about 80 CPU instructions to read 8 bits.

  Point in hand, if bit twiddling at the interface is the limit, there is still plenty of room for improvement in the current implementation, and what is lost on an SPI shift register can be compensated for by additional optimization.

• The current driver might not allow GPIO port expanders by simply changing the device tree definitions because it fails if gpiod_cansleep() is true, like might be the case when connected through a port expander.

[quorten]

So, some other relevant notes around this idea. Raspberry Pi 4 Compute Module can have a PCIe bus wired up to it. It could therefore be possible to attach existing PCI parallel ports to a "PC" built around a Raspberry Pi 4 Compute Module, and this would be another way to alleviate the I/O connector problem.

Also related to that mention, I also saw there to be proprietary hardware similar to pi-parport, but with an RS-232 serial port on top too.

[andrewtubbiolo]

Those PICe modules have proper state machines for the parallel port functionality, along with buffer space for data going out, and data coming in. So a radical departure for the code in general. ... Right? ....

A fast question, I've been static on my ST-8 interface project, but it seems I heard that SBIG open sourced the SBIG drivers, have those changes been introduced into the new releases? SOrry guys, I need to catch up.

Andrew T.

On Thu, Oct 22, 2020 at 10:15 AM Andrew Makousky notifications@github.com wrote:

So, some other relevant notes around this idea. Raspberry Pi 4 Compute Module can have a PCIe bus wired up to it. It could therefore be possible to attach existing PCI parallel ports to a "PC" built around a Raspberry Pi 4 Compute Module, and this would be another way to alleviate the I/O connector problem.

Also related to that mention, I also saw there to be proprietary hardware similar to pi-parport, but with an RS-232 serial port on top too.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/worlickwerx/pi-parport/issues/31#issuecomment-714637586, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJINSSWPGSKWCAPX64XTTTSMBSBZANCNFSM4LGAHU4A .

[garlick]

Yeah that pcie port is a game changer!

A fast question, I've been static on my ST-8 interface project, but it seems I heard that SBIG open sourced the SBIG drivers, have those changes been introduced into the new releases? SOrry guys, I need to catch up.

They (cyanogen) agreed to open source the kernel module for parallel port cameras, and the updated project is here:

https://github.com/garlick/sbig-parport

but as far as I know they haven't opened up the user space component, the "sbig universal driver". If you hear different LMK!

[herrkuhn]

The extra latency might be a concern for some applications, though maybe not for those game controller ROM people who seem to manage to bit bang through ppdev in user space!

Just wanted to say I really had to laugh out loud at that. :D Unfortunately those "game controller ROM people" run into timing issues with one device with their bit banging from user space that they just can't get rid off, so there's that...

[garlick]

Sorry if it sounded like I disparaged your elite group! :-)

Point taken.

[quorten]

I should note my latest idea on this concoction. Probably the most sane way to do this on non-PCIe Raspberry Pi would be use use an AVR microcontroller for the "shift register" handling... because beyond the most basic shift register configurations it gets pretty complicated to find a single, small part that meets your need, so it's either programmable logic or microcontrollers from there. AVR microcontrollers should be fast enough to meet the Pi's SPI speed limits. As mentioned (or hinted) on other topics (#43, #45), an AVR microcontroller is a (hackish) solution for integrating multiple components into one: EEPROM, RTC, SPI shift registers, Power Management Controller, and stand-alone USB gadget (via V-USB).

Okay fine, those last few are some new mentions.

[herrkuhn]

So, some other relevant notes around this idea. Raspberry Pi 4 Compute Module can have a PCIe bus wired up to it. It could therefore be possible to attach existing PCI parallel ports to a "PC" built around a Raspberry Pi 4 Compute Module, and this would be another way to alleviate the I/O connector problem.

Just tried it. The problem seems to be the PCIe card needs the I/O in the address range for PC parallel ports, which aren't available on the Raspberry Pi/CM4.

[herrkuhn]

While this thread has been hijacked with throwing around ideas: still having a problem reading from the control ports, which is impossible with the SN74LVC161284. I've stumbled over the SN74ALVC164245 (https://www.ti.com/product/SN74ALVC164245), which looks like it could be used as a replacement for the SN74LVC161284, by connecting the read-only status port directly to the GPIO via voltage divider and using the second tri state port of the IC for the control port. It would require me designing a new PCB, of course, but the modifications to pi-parport for this to work would be minimal. Any thoughts?

[garlick]

Just tried it. The problem seems to be the PCIe card needs the I/O in the address range for PC parallel ports, which aren't available on the Raspberry Pi/CM4.

Do you by chance still have that test setup together? I'm curious what lspci -vvv says about your card, and whether you tried to build the parport_pc module and get it to claim the card?

Edit: could we redirect the PCIe discussion to #50?

[garlick]

Might be good to open a new issue on reading from the control port. I've lost track of the use case driving that need?

[quorten]

@herrkuhn What particular application are you using that needs to read from the control ports? There's a number of other projects that are well-suited to adapting to anything beyond the host-side PC parallel port use case, you might want to check out the RaSCSI board and adjust that to suit your needs. If you don't need to rapidly switch back and forth between read/write, a simple rewiring dongle could also do. See issue #40 since it is related.

[herrkuhn]

@garlick attached the lspci -vvv output to the new topic, together with the segfault message I get with parport_pc, maybe we'll get somewhere.

@quorten @garlick my use case is video game copiers for retro consoles, mainly the SNES/Super Famicom, but also Mega Drive/Genesis, Game Boy, NeoGeo Pocket, et cetera. These copiers from the 90s usually have a 3.5" floppy drive to load games from floppy and a parallel port to load games and save states from/to a PC. Most devices work without problems with pi-parport (e.g. Super Wild Card and Pro Fighter series of copiers), but there's one device series, the Game Doctor SF 6 and 7, that uses the control port in a non-standard way that I can't get to work. GDSF6/7 uses control port pins 0 and 1 to acknowledge transferred bytes, which only works with parallel ports on PC, but not the SN74LVC161284 IC, which lacks the hardware to read from those pins.