3 years, 7 months ago.

SPISlave Again. Any developer of mbed can answer this question? PLEASE!!

HI, I am sure that the SPISlave doesn't work as it should (When you have more than 1 devices connected to the master) The class of the SPISlave doesn't make any special configuration for the GPIO. Both uses the

 spi_init(&_spi, mosi, miso, sclk, ssel);

to initialize the SPI. I am not sure if CS has pullup status by default .. I cannot see that in the calss .. In the other hand the other three pins SHOULD be in Tri-stated as far as there is no HIGH> TO> LOW signal detected by the CS.

I don't know where and how to start .. The structure of mbed is quite complicated.. Kindly, Any one can help me to understand where or in which file I should change the configuration of these GPIO pins? Is there any function built in mbed to change GPIO to TRI-STATED and return it to it's previous state when needed?

Please help in fixing this bug.. SPISlave should work .. It is very important . Thanks in advance.

Another strange thing .. Why do the compile get this definition


Don't we have synchronized communications with the normal SPI?? I get these definition when I export the project to GCC + eclipse

posted by Mariwan J. 14 Feb 2018

2 Answers

3 years, 7 months ago.

Actually, only the MISO pin on the Slave needs to be tri-stated when NSS is high. The other pins are inputs on the slave and would not cause any contention with others Slaves that are connected to the same Master pins. According to page 1412 and further of the user manual of the ST32L4 here that MISO pin should indeed tri-state if all settings are done correctly. A detailed comparison between the manual and the mbed SPI lib should be done to find out if anything is wrong.

The problem with the Slave class, The pins would not be the same as for the Master. But MBED lib uses the same initialization function which means there is no special care of the pins. Take for ex the clock .. you shouldn't be needed to specify the clock .. as the slave take the clock from the master. I am sure the SPI api needs to be modified and the SPISlave should be changed. To be safe (electrically) you should tri-state the DATA pins .. You never know what other digital devices could cause for problem when multiple slaves connects to the master

And as I said by default the exported project gives an Asynchronous active when you compile the code. Why?

posted by Mariwan J. 15 Feb 2018

If you check at the implementation of SPI_Slave you will see:

SPISlave::SPISlave(PinName mosi, PinName miso, PinName sclk, PinName ssel) :
    spi_init(&_spi, mosi, miso, sclk, ssel);
    spi_format(&_spi, _bits, _mode, 1);
    spi_frequency(&_spi, _hz);

So the call to spi_init() is the same for Master and Slave. However, the switch to Slave is made by the call to spi_format(). The last param is a 1, and that will configure the SPI hardware engine as Slave. This should also result in the MISO pin of the slave to become tri-state when NSS is high.

Details are hidden somewhere deeper in the implementation for the L476 platform. I did not have time to check that.

posted by Wim Huiskamp 15 Feb 2018
3 years, 7 months ago.


Although I have not used slave mode, for the master mode I usually define cs as a GPIO with initial value 1.
In my test_spi project
I defined

DigitalOut cs(PIN_INT0, 1) ;

as cs sometimes requires special timing to be changed.

and in my code I controlled cs before and after spi transaction like below

    cs = 0 ;
    for (i = 0 ; i < loop ; i++ ) {
        mySpi.write(value) ;
    cs = 1 ;

Probably SPI slave application needs to use interrupt-capable pin for cs and prepare for the communication when its cs is asserted.


For SPI that is possible. But for SPISlave you must give the CS pin to the class. So, that will not help.

posted by Mariwan J. 15 Feb 2018