Does this part exist - spi gpio-expander part, with single-byte transfers?

[julian1]

I want to piggy-back the control of a few extra configuration/status bits over an existing SPI connection.

Looking at typical gpio-expanders - MCP23S08/09 has a 3 byte frame{ control byte, register addresses, value }, while PCA9502 is a two byte frame.

Perhaps a single-byte transfer optimized part is available?
A lot of the extra addressing/polarity/interrupt functionality of typical gpio expanders is also unnecessary in the given scenario.

Looking at the DS - combining 74hc4094/595 and 74hc165 might almost work - with CS employed as strobe after 4 bits, and to sequence the read latch for returned data.
The disadvantage is the lack of regularized spi semantics - eg. strobe instead of cs, no high-z MISO on de-select, and the need to bit-bang.

Perhaps something better exists?

[MarkF]

I haven't worked out the details.

If you're very clever, you should be able to use the SPI hardware MOSI, MISO, and CLK pins connected to the serial-to-parallel SER, Q_H, CLK to perform the transfers while using your CS pin selection as a STR (parallel strobe) and/or OE (output enable).  You may need to use two pins for each STR and OE.

[Benta]

Do you need parallel inputs or outputs? HC595 and HC165 SIPO and PISO respectively.

[julian1]

Note, I would happily use a single transfer byte spi io-expander.
The obvious implementation would have the MSB/top bit used as r/w flag, giving 7 user gpio. but I couldn't one.

There are also many 4bit io expanders, which would suffice, but they're all i2c not spi.

[Ian.M]

Note, I would happily use a single transfer byte spi io-expander.
The obvious implementation would have the MSB/top bit used as r/w flag, giving 7 user gpio. but I couldn't one.

SPI doesn't work like that - there is absolutely no need for a R/W flag.  Every  byte transmitted by the master on MOSI is accompanied by it receiving an independent byte from MISO using the same SCLK pulses.  You cant receive without transmitting  a byte, so it is frequently necessary to stuff the master output queue with dummy bytes (usually 0) or to discard received bytes.

Therefore  you can update eight output bits on a 74HC595, and read  eight input bits on a 74HC165 in the same single byte SPI transfer.

 A '595 is directly compatible with SPI mode 0 MOSI, SCLK and nCS signals, but a '165 needs a bit of glue logic for MISO, SCLK and nCS. It needs a 74LVC1G125 or similar tristate buffer on Q_H, controlled by nCS, if MISO is shared with other devices, and an inverter to drive its SH/nLD pin from nCS so the parallel load data is latched when nCS goes low.  As SPI mode 0 samples MISO on rising SCLK edges, and the '165 shifts on the same edge you also need to invert SCLK to feed its CLK input so the Q_H data on MISO is stable when sampled.  A single 74LVC2G04 can be used for both.  With the glue logic, the '165 latches its parallel input data when nCS goes low and the '595 parallel outputs update when nCS goes back high.

For breadboarding, as 74LVCnGxxx is SMD only, it may be more convenient to use one tri-state buffer from a 74HC125 and two inverters from a 74HC04 rather than assembling SMD to DIP breakouts.  Don't leave unused gate inputs floating!

Both shift registers can be daisy chained if you need more I/O, but using them with multi-byte SPI transfers is outside the scope of your question, except to note that your SPI peripheral must be configured to maintain nCS low for the whole transfer.

[PCB.Wiz]

I want to piggy-back the control of a few extra configuration/status bits over an existing SPI connection.

Looking at typical gpio-expanders - MCP23S08/09 has a 3 byte frame{ control byte, register addresses, value }, while PCA9502 is a two byte frame.

Perhaps a single-byte transfer optimized part is available?
A lot of the extra addressing/polarity/interrupt functionality of typical gpio expanders is also unnecessary in the given scenario.

Looking at the DS - combining 74hc4094/595 and 74hc165 might almost work - with CS employed as strobe after 4 bits, and to sequence the read latch for returned data.
The disadvantage is the lack of regularized spi semantics - eg. strobe instead of cs, no high-z MISO on de-select, and the need to bit-bang.

Perhaps something better exists?

There is nothing perfect. A small MCU might do ?
The 4021 shift register has a active hi PL load, so that can connect to CS, which can also load the output register of a 4094/HX595
( HC165 has active low PL, less useful)

The 4021 also has 3 outputs, that might do some LED tasks, as they are not latched they will change during a shift.

If you want to tristate the serial out, for multiple CS designs and shared MISO, you need to add a tiny logic part.

If you are ok with a single sourced part, TI have a new SN74HCS16507.
That has open collector Serial OP, so if all slave parts have serial in = HI, after 9 clocks they will all float.
Only the addressed part that has loaded new Pin data will pull the serial out bus low.  This part needs SH/LD inverted to use SPI CS polarity, so you have not really saved much.

 There is also a 74HCS596, that has open drain output, so you could make a mixed IN/OUT
 

[Buriedcode]

Just ot add I have done the above as Ian M mentioned - '595 with '165, some sot23-5 single gates to match the clock phases, and a tristate buffer for the MISO line just to make it reasonably compliant with SPI, and frankly, its just not worth it. 

Sure HC/VHC/LCX logic is cheap, but once you start having to add small gates, the board area gets bigger, more to route, and its just easier to use a $0.25 MCU with a hardware SPI port, and a small app that just configures and reads/writes to its pins - thats essentially what the port exapnders are.  As long as you realise that it'll take time for the MCU to read its input port when you bring the CS line low - and as such, have sufficient delay before you start a transfer, its a cheap and quick (and small) way of solving the problem, at the cost of spending a couple of hours writing and verifying the code for it.

side note: I tend to use SPI because I hate I2C with a passion. It's a bias I have that I have come to accept.

Edit: After reading the first post more carefully, and the replies, if you're willing to "bit bang" then you can do funky things with a 4094/595 and a 165, with 3 IO - clock, in, and out, with the clock line controloling the strobe/latch of the shift registers via RC circuits.  It can't be used with an SPI port since you'll have to do funky things with the clock line to latch the data, but its 3 IO, two IC's, and a bunch of passives.

[bson]

I want to piggy-back the control of a few extra configuration/status bits over an existing SPI connection.

Looking at typical gpio-expanders - MCP23S08/09 has a 3 byte frame{ control byte, register addresses, value }, while PCA9502 is a two byte frame.

Perhaps a single-byte transfer optimized part is available?

This is only true if you change direction, but for either input or output you can just keep reading or writing data bytes.  Just disable the address auto increment.