SPI half-duplex slave sensor

I've not read your device's data-sheet - yet will make "general" comments - usually found helpful:

• it is unusual for any non-MCU, SPI device to assume the role of "master."   (I'd ask you to consider, "Just how this device can determine when & what to send to it's "slave?")   I don't believe it is intended as a slave.
• MISO (pin 5) of that device will transfer data (send data) to your MCU's SSI_Rx pin - I believe.
• SCLK (pin 4) is unlikely to be self/slave generated clock - instead is (far) more likely to RECEIVE data from the (real) master - your MCU
• SS (pin 3) again is likely generated by the master/MCU
• Two of your three direction arrows (signaling output) are reversed - to my mind.

Might I be wrong... (again?)   By your diagram - w/all 3 pins (pins 3-5) temporarily "pulled-up" - would not a "Parade of SCLKs, SS, and MISO signals" appear - with NO effort whatsoever - upon your part?   That must be true if this device is a true master - must it not?   (pile of pre-"Derby chips" bets against your/other's representation of HIH as master)

Again -

• reverse 2 of those 3 arrows -
• agree that there is NO Data (input) to this slave device (HIHx) - 
• properly drive SS & SCLK from your MCU (MASTER)

and

• observe MISO emit data (all by itself) in response to SS & SCLK from your MCU (which IS and REMAINS) the MASTER.

Enjoy your SPI "Slave..."

[edit] 13:55CST - It's hard to note the unusual font & green color you employed to mark "R/W" (I think that's what you marked) @ MISO pin.  (pin 5)   That "shared" pin would invalidate this chip as a TRUE SPI device - in my experience.  (and your attempt @ highlight failed due to the unrecognizable font!)

Your attempt to employ the MCU's (or any MCU's) SPI function may be defeated here - as the necessity to first "Put Data" will almost surely cause data contention w/the Slave device's Output signal!   I don't like that at all.

If your heart is set on this device - and this device only - - I believe:

• bit-banged GPIO for the TX Command from the Master (MCU) (separate GPIO from SPI_Tx) followed by "tri-stating" that GPIO
• and that followed by (silent) "Put Data" (SPI_Tx driving only a load resistor) - SPI_Tx NOT connected to this device - is one possible, though awkward/inefficient, alternative.

This is a very minority use - breaking (FAR) from "usual SPI standards" - and is not typically best means to quickly/easily gain wide market penetration!

Hello cb1

I checked the device data sheet. It is a Slave. The SS is the Slave Select Active Low signal.

However the data sheet does not mention how data is sent to the master!!! In fact all glamor....

Regards
Amit

Hi Amit,

Thank you - it would have been most unusual for such device to serve as Master. (and you/I both knew that)

I believe the (single) Data Line is able to become "bi-directional" - first receiving a Command - then switching to transmit - and sending (on that same line/wire) back to the Master (MCU.)

Great signal management & timing complexity is traded for the "savings" of one reduced pin. "Fool's gold - some may say." (I'd be among them!)

Hello cb1

Till we get the full datasheet from Honeywell or the poster, we should still allow for a reasonable level of head room.

Regards
Amit

Ok, it's Honeywell's usual parsimonious to just shy of pointless datasheet but it appears that
It is SPI
It is a slave device
It's slow, check the maximum speed before using
It just has no need for a MOSI line, it never receives data.

Robert

Thus - as first argued here - TWO of the THREE connecting, signal lines must have their arrows reversed! (it is only the Slave's Data line which serves as an output.)

Note that poster believed (perhaps still does) that he must, "Send a command to the MISO pin." Poster Robert's read challenges the requirement to (send) commands...

Not to feel (too) bad - a too rushed scan/read of datasheet proves far less "sinful" than the (well) considered (& universal), "Does not Work!"

You may wish to check "Sensiron" devices - should reveal higher performance and better compliance w/"standard" SPI.   (although I recall (some) having interface difficulties with their devices, too...)

Hello Fjpolo,

So now that makes sense....

Regards
Amit