Building a new version of MDBT42Q with different libraries.

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:

I2C1.setup({scl:D10,sda:D11});
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;
  }
  
  console.log(intf._options);
}

tellAbout(SPI2);
tellAbout(I2C1);

console.log(SPI2);
console.log(I2C1);

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.