No SPI MOSI and CLK without NSS?

[LMI2]

I don't need NSS signal or pin, I would rather use it as a real Chip select. But it looks like it there is no SPI at all without NSS? What should I change? CPU is STM32H750.

Edit: Where did my screen capture go? For a short while I thought that I could insert images from clipboard. But no.

[TDK]

You're changing the wrong thing. Change the "Hardware NSS Signal" pulldown at the top of the page.

[Harvey White]

Correct. Turning the hardware NSS off allows the processor software to control the NSS signal. In fact, you need this behavior when concatenating two transmissions, one with a command, one with data. For writing to some displays, you must hold down CS, sent a command with a separate A0 line low (IIRC), then send the data with the A0 line high. Trying to do this with hardware NSS does not keep the CS to the chip active, but instead, controls it separately for each transmission, which doesn't work.

Hardware NSS works for simple chip interfaces where you can either send commands and data as one unit, (preferably with a known size), or don't have an extra register/data select line (and can concatenate the command and data).

[LMI2]

Thank you both.

You are sure that this "Change the "Hardware NSS Signal" pulldown at the top of the page." alone is enough? I thought that I have tried that too and many other combinations.

Currently I have a single SPI slave, MAX31865 a PT100 chip, on the bus and I am handling the chip select with a GPIO pin. What I have read the NSS signal tells that it isn't very helpful.

[TDK]

Yes, set it to disabled and just go try it. If it doesn't work, post a screenshot.

> What I have read the NSS signal tells that it isn't very helpful.

This is true. Much better to use a GPIO pin as CS and toggle it manually.

[Harvey White]

I've got this kind of thing (software NSS pin) working on a Chinese 240 * 320 display, an Epson S1D13781 graphics chip, and an NRF24L01 RF transceiver.

Generally, you wrap the provided HAL driver and call your own routine.

I use a slightly more complicated driver, so I have a command count, command pointer, data count, data pointer, clock_divider, CS port, CS pin, etc for more pins).

I can change the data rate on the fly, which is needed for some chips. If the auxiliary pins (say an A0 pin) is a null pointer, it's not going to be changed and the program won't crash.

Generally, so far, I've needed a send and a receive routine.

You can make the driver as complicated as you may need. For an operating system driven interface, you'll want a semaphore to protect the interface from being called by two routines at the same time (which can happen in an operating system). You can disable that if the interface is dedicated to one chip.

As I mentioned, if you're writing single blocks to a single dedicated chip, nothing between command and data, then the NSS will work. Any other situation and it will have to be examined carefully.

[LMI2]

I got it working, at least I see clock and MOSI. I have some work to do yet, but got forward. Thank you.

To: Harwey White: Huh. I often wondered if this would be easier by just driving SPI bus with GPIO pins and my own software. You seem to be in a similar position.

Regards

Leif M

[Harvey White]

I can see where you might think that, but the answer is somewhat of a resounding no from my point of view. Bit banging is not useful for me.

There's nothing wrong with the actual SPI hardware that I've been able to find. It works, works well, has a decent amount of support and hasn't been a problem. If you work directly on the GPIO pins for the SPI interface then you're doing bit-banging. This cuts you off from a lot of software support, and is generally used only if you run out of SPI interfaces.

This is not the case in the designs I do. (and yes, both software and hardware). The main problem I've got with the SPI interfaces is only how the NSS pin (or the equivalent) is handled. To state it again, the way the NSS pin works is that you get the NSS pin going low each time you call the chip level driver. I have chips that need, as an example, bytes sent with the A0 line (you have to supply this) low, and then bytes sent with the A0 line high. The CS line needs to be low for both transactions. Using the hardware NSS line, you call the SPI send with the A0 low, then call the SPI send (different pointers) with the A0 high. Wonderful idea, but each call with a hardware NSS line used puts the NSS line back up after each call.

Obviously, this doesn't work. My approach is to use the software controlled NSS line, set it low, call the SPI native HAL routine for the command bytes, then in my program, set the A0 line high, then call the same native HAL routine with pointers to data and data count. THEN I set the CS line high.

So I have no need (or desire, since I don't think it will run at 8 Mhz, which hardware SPI will....) for bitbanging. The auxiliary lines, CS, RESET, A0, and whatever (there's one display that needs a read line and a write line), well, those are under software control in my driver.