This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF_DRV_SPIS_INSTANCE(1) results in GCC Exits with code 1

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.

Parents Reply Children
  • Failed to compile LEDBlink.cpp
    not compatible in compilation of C++.

    - having the .cpp extension tells GCC to compile the file as C++

  • 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?

  • 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\n", 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. 

Related