SPI help

[Postal2]

A crystal oscillator is an analog circuit. SPI data transfer is a digital circuit.

Perhaps I was not clear enough. The "empty wire" example applies to analog circuits and RF. The case described here involves introducing an additional resonant circuit into the main circuit, formed by the connected probe, its capacitance, the inductance of the probe-to-ground loop, and the inductance of the section of the design from the probe connection to the circuit in which the resonance occurs. Therefore, an attempt to simulate a probe connection with a capacitance of 10 pF gave the opposite effect.

It looks like this (picture):

[dietert1]

A SPI transfer that fails or becomes unreliable by adding short wires is typical for a wrong configuration of the clock/data timing relationship. With a wrong configuration setup/hold times are marginal and the circuit shows exactly that strange behavior the OP reported. It will be gone with a valid digital configuration. Trying to make the wrong digital design work better by some analog mods is a waste of effort.

Regards, Dieter

[Postal2]

... With a wrong configuration ...

So, you're implying that while the device's author turned away, someone snuck up and changed the polarity? Please show an example of a standard library that has a non-standard signal phase by default.

The non-standard phase of the spi module may be needed when working with Microchip via ICSP or implementing Microwire via spi. It is unlikely that you can accidentally copy such source code, if you can find it at all.

Although peter-h regularly posts his code for the non-standard ADS1118, scaring people.

[Siwastaja]

A SPI transfer that fails or becomes unreliable by adding short wires is typical for a wrong configuration of the clock/data timing relationship. With a wrong configuration setup/hold times are marginal and the circuit shows exactly that strange behavior the OP reported. It will be gone with a valid digital configuration. Trying to make the wrong digital design work better by some analog mods is a waste of effort.

Regards, Dieter

Yeah. A bit more about this:

Synchronous digital logic (e.g. as used in digital ICs like microprocessors) is based on data and clock changing "simultaneously". But this involves a carefully designed clock tree. It is a clock edge which triggers change of data. Then the data propagates through gates which have some guaranteed minimum delay. By modelling it is then guaranteed that the changed data value gets to its destination significantly after the clock transition - this minimum acceptable time is called hold time.

This arrangement, "output data as soon as acceptable but not any sooner", leaves maximum possible time for data delays before the next clock transition - the margin that needs to be left at the end of the slot is called setup time.

But SPI does not do this kind of delay management and matching. If you try to run SPI like "normal" synchronous logic, hold time violations are very likely. Or even beyond that; sampling the data even before it is outputted, so violating setup time plus being off-by-one bit.

SPI instead is specified to clock the data in on the opposite clock edge it is outputted: expressed in time, exactly half-way the bit time slot. This completely prevents the issue of data being sampled "too early", but of course reduces the time margin to the next transition to half, but that is generally OK for the clock rates used in SPI.

Now if the clock configuration is incorrect, SPI tries to operate like normal synchronous logic inputting the data at the exact same time as its being output. If the system was designed for this, like normal synchronous logic, it would correctly read the previous bit, but being not delay-matched for this purpose it has pretty much equal chances of sampling the previous bit, the current bit, or the invalid transition area between them which could sample in either value or result in metastability (which is an interesting failure condition in itself).

[peter-h]

Although peter-h regularly posts his code for the non-standard ADS1118, scaring people.

Rubbish. A troll...

A bit more about this:

A good explanation of how to do, and not do, FPGA design At some point, probably late 1990s or so, Xilinx reduced their silicon geometry (even for existing part numbers) which made them run a lot faster and this broke more or less all designs except those that used the global clock nets for practically all clocking. Since that was always how FPGA design was supposed to be done, Xilinx didn't care

A lot of SPI slaves have weirdly bodged SPI interfaces. Like this one
https://www.eevblog.com/forum/projects/anyone-using-the-u-blox-neo-m9n-gps/
and others have rediculously low max SPI clock speeds e.g. the STLED316 (max 1MHz).

[dietert1]

..
A lot of SPI slaves have weirdly bodged SPI interfaces. Like this one
https://www.eevblog.com/forum/projects/anyone-using-the-u-blox-neo-m9n-gps/
and others have rediculously low max SPI clock speeds e.g. the STLED316 (max 1MHz).

Chinese TFT driver chips are known for their issues. E.g. the ILI9488 doesn't three-state its SPI data output. One needs to add an external gate to make it SPI bus compatible. Many TFT displays available from China don't have that gate. Instead they provide two separate SPI interfaces for display and touchscreen. And of course their example software won't even try to read from the display driver chip.

Regards, Dieter

[peter-h]

Interesting.

AFAIK the Ramtex library doesn't read the display either. There is no fundamental reason to. But for the touch screen you obviously do need to read it.

[ebastler]

AFAIK the Ramtex library doesn't read the display either. There is no fundamental reason to.

Well, many microcontroller-based systems will not have enough RAM to keep a full frame buffer in the microcontroller. So one may want to read the prior pixel contents from the display (for specific pixels or a small local area) before drawing some moving objects or traces.

[Postal2]

Although peter-h regularly posts his code for the non-standard ADS1118, scaring people.

Rubbish. A troll...

Who?

................
   case KDE_SPI_MODE_ADS1118:
      m_spi.Init.Direction = SPI_DIRECTION_2LINES;
      m_spi.Init.DataSize = SPI_DATASIZE_16BIT;
      m_spi.Init.CLKPolarity = SPI_POLARITY_LOW;               // correct per data sheet
      m_spi.Init.CLKPhase = SPI_PHASE_2EDGE;                  // likewise - sample on -ve ck edge
      m_spi.Init.NSS = SPI_NSS_SOFT;
      m_spi.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_16;     // 2.6MHz (max 4MHz for ADS1118)
      m_spi.Init.FirstBit = SPI_FIRSTBIT_MSB;
      m_spi.Init.CRCPolynomial = 7;
      m_spi.Init.Mode = SPI_MODE_MASTER;
      m_spi.Instance = ADS1118_SPI;
      break;
................

[peter-h]

Well, many microcontroller-based systems will not have enough RAM to keep a full frame buffer in the microcontroller. So one may want to read the prior pixel contents from the display (for specific pixels or a small local area) before drawing some moving objects or traces.

See this thread
https://www.eevblog.com/forum/projects/graphics-on-an-embedded-system-tft-display-need-help-with-some-pointers/

Reading back the display is some way down the list of doing it efficiently. One might do it with purely memory-mapped graphics...

Indeed, in embedded graphics you don't normally have a full frame buffer but even if you did, SPI won't usually be fast enough to just modify the buffer and then send the whole buffer up to the LCD. You could probably draw a clock face on a 256x256 LCD, with 10MHz+ SPI, that way, but that's about it. For anything more real, one needs to be be clever and keep tabs on the area which has been affected and send only that. See above link.

case KDE_SPI_MODE_ADS1118:

Yes, but context is everything. I don't think you understand the concept of "context" which is why your posts usually make a bit of sense but are of no use to anybody working on something specific.

[Postal2]

.... your posts usually make a bit of sense ....

Thank you, captain.

[Northy]

Hi all,

Sorry for the silence, I've not been feeling well for a few days.

I looked at the bus with a logic analyser on Friday morning, and it looked right for the ethernet IC (although my clock idles low and the data sheet looks like it idles high).

I can assure you there is nothing else in the LCD datasheet other than what I have posted. The manufacturer has been contacted though. However, the timing looked the same as ethernet IC.
I'll look at the timing again this week, and try and get a specific timing diagram from the LCD IC manufacturer.

If set up/timing does seem to be correct I'm thinking this is some serious ringing on the lines. If so do I just try resistors on the outputs (that I should have added, and usually do  ) or should I add 'something else' either side of the FFC cable too?

Thanks,

G

[peter-h]

You need an oscilloscope, not a logic analyser.

[Northy]

I've looked on a scope too. I was looking at the timing relationship on the logic analyser.

I'd like to see any ringing on the scope, but adding the probe changes things.

Or am I getting the wrong end of the sick again here?

G

[Siwastaja]

Hi all,

Sorry for the silence, I've not been feeling well for a few days.

In the mean time, will you ever disclose what the SPI master is? And the reason why you did not test the different SPI modes, it takes literally a few minutes to try?

[Postal2]

.... If so do I just try resistors on the outputs ....

You need only one resistor or inductor on the CLK line, absolutely nothing else.

I would prefer inductor (I wrote which one in my first message in this thread).

[Siwastaja]

And really, just in case it's not clear already, ignore Postal2. Do not put inductors on any of the SPI lines.

[Postal2]

... ignore Postal2. ....

For those who have read this thread from the beginning, it is clear who should be ignored.

[ebastler]

Well, many microcontroller-based systems will not have enough RAM to keep a full frame buffer in the microcontroller. So one may want to read the prior pixel contents from the display (for specific pixels or a small local area) before drawing some moving objects or traces.

See this thread
https://www.eevblog.com/forum/projects/graphics-on-an-embedded-system-tft-display-need-help-with-some-pointers/

Reading back the display is some way down the list of doing it efficiently.

Thanks for the link -- some good discussion there. But the use case I was thinking of is not really covered, I believe:

Let's say you have a complex background pattern drawn on the screen. Just as an example, a world map which you drew from vector outlines, with overlaid day/night zones (changing slowly depending on the time of day and the season). Now you want to draw a few moving satellites or other objects and need to update them regularly.

How do you restore the background pattern when the object moves away to a different spot? You could recalculate the whole background pattern just to figure out which color goes into those few pixels. But it seems much more efficient to read the original background pattern from the display (and store it in a small buffer in MCU RAM) before drawing the object in its new location, and restore the background from that buffered info when the object moves on.

I am currently working on a related use case: Draw a few fast-changing traces, over a background which comprises a coordinate system with variable axis labeling, some UI (menu) elements which may change, plus some measurement results determined from the time-averaged traces. Same thing -- the background info changes slowly and is not trivial to recalculate on the fly; the traces should overlay the background; but of course the background pattern needs to be restored when the trace moves away.

So I think there are some meaningful uses for reading data back from a display. The chip manufacturers must have had some reason to make data transfer bi-directional...

[peter-h]

The data for the world map must have come from somewhere. Probably stored as a block of data in FLASH. So, since you know the initial position of the moving object, fetch that little rectangle from the FLASH and send it out over SPI (which deletes the said object) and then draw the object in its new position.

[dietert1]

Maybe the OP could mention parts, clock rate and other setup. Show your measurements! Until now the only thing we know is the clock polarity may be opposite to what is in the specs - which can already cause a setup/hold timing issue. The SPI variant and clock to be used for a display is specified in the datasheet of the graphics chip built into and driving the display.
Recently i made a little graphics card for a TFT display without display memory, using a STM32H730 MCU and its LTDC peripheral. It generates digital video from a large buffer in the MCU address range, in my case inside the MCU RAM. It can work with 8 bit per pixel, using the color palette on the fly while generating video and it supports two frame buffers. Their images get mixed on the fly using a transparent color (green screen method). The nice demos they show use one of the frame buffers as background image and the other one for "sprites". The solution even works for video with overlays. Depending on the size of the screen external RAM may be required.

Regards, Dieter

[ebastler]

The data for the world map must have come from somewhere. Probably stored as a block of data in FLASH. So, since you know the initial position of the moving object, fetch that little rectangle from the FLASH and send it out over SPI (which deletes the said object) and then draw the object in its new position.

As described, my first assumed case has a world map rendered from vector graphics, plus a dynamically generated day/night overlay. My current actual use case, as also described, has a background comprising dnamically generated coordinate axes with labels, menu items, and measurement results.

So no, there's no way to just fetch the background section from some static store. (Or to regenerate it dynamically with very simple code.)

[peter-h]

The axes should be super fast to generate and send over SPI. And maybe some other stuff too. Otherwise, yeah, you need RAM

[Northy]

The parts are:

ADUC7023
KSZ9893
BT817

G

[Someone]

It's impressive how after almost two pages of posts the clock/data timing relationship has not been verified.

End of page 3, finally the part numbers are revealed and the data sheets all have clear and unambiguous statements about the clock phase requirements/settings. So its one of those threads:

The LCD chip has no proper timing diagram 

If we can find it trivially, either you're providing the wrong part numbers to us or you've not bothered looking.

"I've Tried Nothing and I'm All Out of Ideas"