Way to make it confusing

[bson]

How's this for an SPI timing diagram?

Not the BUSY output.  And the apparent DCLK stretched for its falling edge to coincide with BUSY.  WTF?!

But then look at the "detailed" timing diagram.  No clock stretching?  It's basically just saying BUSY consumes one cycle, during which there will be no meaningful data output.  Fair enough.  But then why have a BUSY output at all, why not just say the MSB of the first byte will always be '1' (assuming MISO isn't driven)?  Or drive it to '0' just to be nice?  Actually, the diagram DOES show it driven to '0'. So... huh.

In the end, I think all I'm looking at here is plain old SPI and can ignore the BUSY output.  So it's DMA friendly.  It's just the 12-bit data will be in bits 3-14 of a 16-bit big-endian word.

[PCB.Wiz]

And the apparent DCLK stretched for its falling edge to coincide with BUSY.  WTF?!...

In the end, I think all I'm looking at here is plain old SPI and can ignore the BUSY output. 

Hmm, who is in charge of BUSY ?
If it is the SPI device, my reading is that busy goes HIGH on last control/command clock, and remains high until some subsequent clock edge sees it go low.
ie the clock does not stretch, but at least one clock is needed to poll BUSY

Easy to check on a real device ?
If you want to ignore BUSY, some lower speed clock could make that possible ? does the data give a widest value needed for BUSY (may vary with command)

[T3sl4co1l]

If BUSY is not an async signal, it doesn't make any sense at all to provide separately; it should just be a status bit in the next frame.  Where there's evidently a suspicious gap that it would fit perfectly in.

Not doubting your interpretation of the diagrams; more to say, I agree, there's probably some dumb design going on here.

Tim

[NorthGuy]

You don't say who's the master, what is the direction of the signals (e.g. is DIN looks like MOSI, but we can only guess).

Looks like BUSY is gating the clock for DOUT, that is DOUT is valid only when BUSY is low. The diagram shows BUSY gets low after the first clock, but if the clock pulse occurs earlier, or if  the chip is busy doing something, the BUSY may go low after the second, third, or subsequent clock pulse.

This should be explained in the datasheet.

[Bassman59]

How's this for an SPI timing diagram?

SPI is a completely meaningless initialism.

The timing diagram you posted is not what we think of as "SPI" -- it's just a wacky synchronous serial interface.

The hilarious -- by which I mean "completely hateful" -- thing is that nonstandard wacky synchronous serial interfaces are, uh, standard on low-pin-count multichannel converter chips.

The interfaces are all pretty goddamn stupid.

And this is one reason why I'm thankful I use FPGAs to talk to them. Instead of trying to force a microcontroller's standard SPI or USART peripheral to deal with these things, I just code up the exact interface I need. This of course assumes that the data sheet is comprehensive and correct.

In the "jeez, it would be nice" category: It Would Be Nice if the converter manufacturers could supply a bus-function HDL model of their parts for the customers to use to verify their FPGA designs, so I don't have to write them. There is nothing like using the same assumptions for design in the verification, right?

And It Would Be Really Fucking Nice if the manufacturer tech support response to "Do you have VHDL models of your converter ADCxxxx?" was not "You can find the IBIS models here ..."

Anyway.

[bson]

Yeah, this is the datasheet for a device and the signal is output by the decice.  I don't actually have the BUSY signal on the header I use to talk to the device, all I have is the other signals.  The device is a TSC2046 resistive touch controller on a display board.  (Or, more likely, a Chinese clone - but it seems to work like the original.  Not rocket science exactly.)

It doesn't say much about the pin other than it indicates the device is busy...

If it's a predetermined quantity I don't even understand why it's there.  The device already has an interrupt out to signal a touch event.  Perhaps they envision an interrupt-driven master that sends a command, then on an interrupt on BUSY reads the data?  But I don't see how this could work either; can't start clocking out the data (on DOUT/MISO) when it goes high, and its falling edge coincides with that of the clock.  So it can't be used for this.

But, I ignore it and feed ithe device a fixed byte sequence using DMA, capturing the data sent back using another DMA channel ("stream" in ST lingo, again talking of unncecessary complications, in this case redefining canonical terminology...).  Then extract the results from the rx buffer.  Like I said, it works just fine (or maybe that's just the clone?) - so why make the timing diagrams so complicated.   Shrug.

[SiliconWizard]

While the detailed diagram seems to imply that the BUSY signal is held high only for exactly one clock cycle, this is something I would like to see written clearly in the documentation.
Plus, the confusing part is that in the first diagram, DCLK is shown interrupted during the BUSY high state, while in the second, DCLK keeps clocking. So. Without seeing the whole doc, I'd say to whoever did this: get a life.

[bson]

While the detailed diagram seems to imply that the BUSY signal is held high only for exactly one clock cycle, this is something I would like to see written clearly in the documentation.
Plus, the confusing part is that in the first diagram, DCLK is shown interrupted during the BUSY high state, while in the second, DCLK keeps clocking. So. Without seeing the whole doc, I'd say to whoever did this: get a life.

Agree totally.  There's a huge difference between "FYI - I'm doing a conversion now" and "woah, hold your horses, you can't read the results before the conversion is complete!"

[madires]

Should be compatible with the ADS7843 which comes with a more comprehendible datasheet.

[NorthGuy]

The device is a TSC2046 resistive touch controller on a display board.

The datasheet seems to imply that the part is fine with continuous clock (see "Figure 13. Maximum Conversion Rate, 15 Clocks-per-Conversion"). So, I'd say BUSY is purely informational.

[MarginallyStable]

I get the impression that the busy signal is simply to indicate the time where the sample is taken. Not sure it is really needed for the interface.