SPI hardware NSS

[carl0s]

Hi.
I understand the pby.SPI driver doesn't implement chip/slave select at all.
I remember that STM32 can take care of it automatically (Hardware NSS). Is there any chance this might be implemented ?

I was hoping to use a micropython board for tinkering/experimenting with the SPI initialisation code for a MIPI bridge chip. I thought it would be easier than recompiling stm32 stuff constantly while I try to figure out how to do it all, but I just keep running into difficulties in SPI implementations on all the micropython boards I'm trying - Kendryte K210, both MaixPy and Loboris' version - they just crash if you try to set greater than 8 bits, and so I thought I'd try a pyBoard v1.1 but that doesn't do the chip select. I do have an Adafruit feather m0 and an ESP32/lorawan board that I haven't tried yet.

[jimmo]

I just ran into this myself the other day, using machine.SPI though where this isn't supported. However I noticed that pyb.SPI does actually support it, it's just not documented. Looking at pyb_spi.c, I think if you set the nss kwarg to SPI_NSS_HARD_OUTPUT (0x00040000) it will enable this.

[carl0s]

[quote=jimmo post_id=39196 time=1567817641 user_id=3071]
I just ran into this myself the other day, using machine.SPI though where this isn't supported. However I noticed that pyb.SPI does actually support it, it's just not documented. Looking at pyb_spi.c, I think if you set the nss kwarg to SPI_NSS_HARD_OUTPUT (0x00040000) it will enable this.
[/quote]

Hi. I have had a look, and that part of the code seems to be commented out, with the remark 'To do'. I've tridd it anyway 0x00040000 and there's no activity on pin X5.

[jimmo]

Interesting -- the actual constants are commented out from the class locals, but the code appears to be implemented.

I will investigate at some point... might be worth trying to get this supported in machine.SPI for STM32. (pyb.SPI is sort of deprecated anyway).

[jimmo]

I checked on my pyboard -- setting nss=0x00040000 does "work" in that it does what the reference manual says it will. But this may not be what you were hoping the behaviour was (certainly wasn't what I expected).

When you enable hardware NSS, the behavior is that NSS will go high, then low on the first read/write operation, then stay low until the SPI controller is disabled. (i.e. .deinit() ). So I guess there's no reason you can't write your code like that, but doing NSS in software sounds easier.

[carl0s]

I checked on my pyboard -- setting nss=0x00040000 does "work" in that it does what the reference manual says it will. But this may not be what you were hoping the behaviour was (certainly wasn't what I expected).

When you enable hardware NSS, the behavior is that NSS will go high, then low on the first read/write operation, then stay low until the SPI controller is disabled. (i.e. .deinit() ). So I guess there's no reason you can't write your code like that, but doing NSS in software sounds easier.

Hi! Yes that's exactly what I noticed when I tried it! Is that the STM32 reference manual? Or uPython reference manual? It's not what I expected either, although I've looked back over some of my earlier captures from an ST-Disco board, and it looks the same.. I hadn't realised. Well anyway, this confirms that the thing I'm trying to achieve did actually work with the NSS staying low all the time, despite my target chip's timing charts showing otherwise, so I'll carry on. Thanks for your help.

pic from when I had the chip talking to my disco board last year, which I'm struggling to do again this year (same chip, on a pre-made board this time instead of a DIY breakout):

[jimmo]

Is that the STM32 reference manual?

Yup, the F405 ref manual.

[carl0s]

Is that the STM32 reference manual?

Yup, the F405 ref manual.

Thanks Jimmo!