• I'm now testing multiple SPI ports on my version of the MDBT42Q board and have discovered a bit of 'chicken and egg' problem.

    The Espruino build process uses BOARD.py to define the included features of a board. Ok, creating a new BOARD file and setting

    'spi' : 3,

    seemed to work and allowed me to pass a simple test:

    SPI2.setup({mosi:D07, miso:D05, sck:D04, baud:1000000});
    function tellAbout(intf) {
      if(intf._options.mosi)  {
        console.log("interface is SPI");
        intf.cs = D09;
      } else {
        console.log("interface is I2C");
        intf.addr = 0x1c;

    However, when I tried to actually USE the new port, the SPI hardware wasn't being used. I then looked at the jshardware.c file and saw that it was fixed at 'spi0' only, so I updated that to conditionally include code to instantiate and use spi1 & spi2. This, of course, required that I update sdk_config.h to set the respective SPIx_ENABLE macros (otherwise the nrf_drv...c files didn't know about these devices).

    Once this was all done, the extra SPI ports worked marvelously.

    Unfortunately, when I regressed the build for the original MDBT42Q I got a bunch of compiler errors stating that EVSPI2 & EVSPI3 were not defined. After a bit of research, I discovered the problem. EVSPIx are enumerated in jsdevices.h based on a macro SPI_COUNT defined in the auto-generated platform_config.h. Unfortunately, this macro is also defined in sdk_config.h based on the number of SPIx_ENABLE macros. As a result, using SPI_COUNT in jshardware.c file to conditionally build used the existing macro definition created in sdk_config.h due to the ordering of include files, overriding the definition in platform_config.h.

    I suspected that reordering the include files in jshardware.c to try to solve this problem was probably the way to madness (DAMHIKT!) and ended up creating a new macro, SPI_MAX, in jsdevices.h, so that the proper board specific count of SPI devices could be saved and unambiguously used in jshardware.c.

    This works for the nrf52 builds. SPI_MAX should be benign for all other boards. I think fundamentally having hardware definition controlled from two points (BOARD.py and the sdk_config.h files) is ripe for similar contentions. In normal nrf build structures the platform specific sdk_config.h is located in a platform specific config folder. However, this doesn't work well in this multi-platform situation so I'm not sure if there is an ideal solution. Maybe copying a BOARD specific version of sdk_config.h into the gen folder would work, but I'm not sure about the tooling to do this.


Avatar for TomWS @TomWS started