NRF_DRV_SPIS_INSTANCE(1) results in GCC Exits with code 1

Question

First some general info: 
 * Compiler GCC 7.2.0 GDB 8.0.1 
 * VisualGDB 5.3R8 Build 1973 
 * Visual Studio 2017 
 * SDK 12.0 
 I try to build an application using the SPI slave. But I'm out of luck quite quick. 
 The steps I did: 
 1. Set the SPI Driver to slave in the embedit framework 
 2. Enable SPIS in the sdk_config.h file (eg #define SPIS_ENABLED 1) 
 3. Enable instance 1 as this is the only slave instance availible for the nRF51 series (eg #define SPIS1_ENABLED 1) 
 4. Include the header files: 
 #include "nrf_spis.h" #include "nrf_drv_spis.h" 
 Now if I try to create an instance of the SPI slave with: 
 static const nrf_drv_spis_t m_spi_slave_1 = NRF_DRV_SPIS_INSTANCE(1); 
 I get the folowing error code: 
 "Error Failed to compile LEDBlink.cpp. GCC exited with code 1 SPI_Slave C:\Program Files (x86)\Sysprogs\VisualGDB\MSBuild\Targets\gcc.targets 85" 
 What am I missing here. I did use the SPI master in the past without any problem. So I'm a little bit in the dark here why this time things dont seem to work. Any help is welkom.

Nguyen Hoan Hoang · Accepted Answer

Nordic MACRO such as NRF_DRV_SPSIS_INTANCES(1) and many other like that are not compatible in compilation of C++. You need to manually assign the value instead of using that macro. These kind of macro are bad programming practices anyway, avoid them if you can.

awneil · Answer

Ad said: Failed to compile LEDBlink.cpp Nguyen Hoan Hoang said: not compatible in compilation of C++. 
 Ad - having the .cpp extension tells GCC to compile the file as C++

Ad · Answer

Nguyen Haan, You are right. If I change the extension to .c the project compiles without a problem. So manny thanks for your help here!!!!!! Can you explain me the main reasons why using this Nordic Macro's are considered Bad practice? (I just want to learn) 
 And is there somebody from Nordic who can explayn why Nordic is promoting this Macro's?

Nguyen Hoan Hoang · Answer

Best practice is to limit macro to define a constants never to define a portion of code. Assignments of a specific variable or structure is code. Macro with stringily and concatenation makes code unreadable and extremely hard to follow when you need to debug them. The worst thing of all is 3000 lines of unnecessary conditional compilation and hardcoded values of sdk_config.h to get things compile. That is the worst programming practice of all. 
 Let take an example why you should be careful and limit use of macro. 
 #define SUM(x) ((x) + (x)) 
 int a = 1; 
 int b = SUM(a++); 
 print("a = %d, b = %d
", a, b); 
 so we would expect a=2, b=2, right ? Wrong, with that macro, the actual result is a=3, b=3 
 That is just a simple macro, imaging that with a more complex macro Nordic loves to use. It'll become a debug nightmare. 
 
 Some people may argue that using macro to create inline code for speed. Yes, inline makes code faster but wrong to use macro for that. You want inline code, use inline function. So back to the macro above with inline instead. 
 
 static inline SUM(int x) { return (x) + (x); } 
 You would get the expected result a=2, b=2.

NRF_DRV_SPIS_INSTANCE(1) results in GCC Exits with code 1

Top Replies