SPI::_acquire() is inefficient

[multiplemonomials]

Currently, the SPI::_acquire() function is pretty inefficient: if the current SPI class instance does not own the peripheral, it reinitializes the ENTIRE spi hardware peripheral, including setting up clocking and pins again. This has got to be a bit of a performance drain if you are trying to rapidly switch an SPI bus between multiple chips (even though it does mean that you can use the same SPI peripheral on your MCU with multiple pin mappings which is cool). Ideally:

• General setup such as clocking and DMA channels should only be set up once for a given hardware peripheral
• Pin mappings should only be changed in acquire() if the previous owner used different pin mappings than the current instance

[lefebvresam]

What I not really understand is the relationship between the 'owner' and the intantiation of the object. In my understanding you have for instance one SPI port which is serving multiple chips. In that case you create more instances of the same SPI object with csel (and maybe speed) as the only differences. They have to share the same hardware source and each time caller is different there must be a context switch to reprogram some registers. This is however an inefficiënt operation and should be avoided as much as possble. But is there a one to one relationship between instance and caller? What if you derefer of queue the calls? How many context switches are useless?

[multiplemonomials]

Yeah, it's very unclear. I believe that the design intent of Mbed was that different chip drivers should each create their own instance of SPI. If the drivers use the exact same SPI settings (mode, frequency, CS pin) then they can share an object, but otherwise they need different ones.