spi_mngr not working under SDK 15.2

[Constantin]

Hi,

going on with the migration from SDK 14.2 to SDK 15.3 it keeps on making trouble. Now the spi_mngr is not working anymore. After changing all calls to perform with extra NULL I am getting the error

error: 'NRFX_SPIMSPI_DS_INSTANCE_INST_IDX' undeclared here (not in a function)

Since I've already had a similar issue with the TWI manager I had to change the sdk_config and delete all parts of old SPI stuff. But if I run the exact same application I now get the error:

<error> app: ERROR 4 [NRF_ERROR_NO_MEM] nrf_spi_mngr_schedule

Although the queue size is exactly the same. Sorry but did some one of you already tested it?

Only if I run it with HIGH priority I can get it running while the performance (again exact same code) is only half as good as for the SDK 14.2. 

I doubt that the spi_mngr uses the SPIM transfer. Am I correct? Is there a spi_mngr version with SPIM transfer? What do I need to change.

[Constantin]

Further if change to SPI3 which should be available for the new SDK it directly hangs in the init routine. So I can initialize the manager but cannot send something.

[makesense]

There is a better driver here more performance and without all that sdk_config.h junk.

https://github.com/I-SYST/EHAL/tree/master/ARM/Nordic/src

[Constantin]

Looks interesting but without the spi transaction manager it does not make sense since the whole handling for finishing transaction has to be handled manually. But still nice idea of making it without the SDK.

[makesense]

What do you mean by without transaction manager finishing transaction manually ?

See usage example https://github.com/I-SYST/EHAL/blob/master/exemples/spi/spi_master_slave.cpp

Read and write to a register of a sensor for example is as simple as that. 

    // write reg
	g_SpiMaster.Write(0, regaddr, 1, data, 10);
	
	// read reg
	int cnt = g_SpiMaster.Read(0, regaddr, 1, buff, 8);

 

[Constantin]

Yes sure that is totally easy but if you look at the spi_mngr it does something more. You can send stuff asynchronously and it is put into a queue and scheduled when the spi device is idle. With your framework you have to send it in blocking mode or via DMA and then check if the DMA has finished. That is why I called it manually. But still it looks promising. And since the manager does not offer the full velocity at the moment I will definitely check your version if it improves my performance.

[Nguyen Hoan Hoang]

Usually a SPI transaction is very short and immediate, rarely delayed.  In case of asynch streaming transfer usually there is a RTOS involved and the queueing is handled in a thread using the queueing mechanism of the RTOS.  Therefore it is not implemented in this driver.  It is meant to be low level and independent of RTOS.  You can of course hook up an event handler and manage the queue.  That is at a higher level.  I guess that is same as what the spi_manager is and the nrfx_spi being the low level driver that does not handle any queueing.

[Constantin]

Then just a short question is it possible to just use the spi_nrf5x.cpp in combination with sdk_config.h or do I have to use all stuff. Because this will be very difficult for us. And why it is a cpp file since it is just normal C code?

[Nguyen Hoan Hoang]

Yes it can be used with other stuff from the SDK.  The implementation is ObjetOriented for high level but also supports normal C in low level.

See this example how OO in in the works.  the same BME680 sensor can work with either SPI or I2C interchangeably without needing to write sensor code for each.  This can only be done in cpp. 

https://github.com/I-SYST/EHAL/blob/master/exemples/sensor/env_tph_demo.cpp

this example is also a generic code that can with other MCU to, such as the NXP LCP11xx for instance without rewriting.

The organization if simple. Anything higher in the folder hierarchy is common to all bellow.  The deeper you go down the more it is specific to a particular implementation.  So you can see all the driver such as sensors are implemented in the top level because it is independent of MCU.  While all the UART, I2C, SPI... are implemented per MCU.  

There are 2 main classes that everything is derived from

DeviceIntrf and Device