MDBT42Q page documentation clarification needed

Sat 2019.03.30

While this content might better be addressed by @Gordon, others' comments welcome.

My questions resulted from an attempt connecting the Ublox NEO-6M to the MDBT42Q breakout. Surprisingly, communications and rendering data output in the WebIDE went without a hitch. Kudos to Gordon for concise documentation.

http://forum.espruino.com/conversations/332295

Beneath breakout board image:

Note: The nRF52 port has one available I2C, SPI and USART (and infinite software SPI and I2C)
ref: http://www.espruino.com/MDBT42Q

Other questions resulted:

Q1: Is the 'nRF52 port' just a reference to pins D6 and D8 ? (what port?)
Q2: It is not possible to have both BLE and the NEO-6M communicating at the same time (?T one or the other?)
Q3: I presume that I2C and SPI are allowed only on pins D6 and D8 if Q1 is true (doc isn't really clear here, where are the hardware I2C and SPI?)

Beneath breakout board image:
Note: The nRF52 port has one available I2C, SPI and USART (and infinite software SPI and I2C)
ref: http://www.espruino.com/MDBT42Q

Other questions resulted:
Q1: Is the 'nRF52 port' just a reference to pins D6 and D8 ? (what port?)
Q2: It is not possible to have both BLE and the NEO-6M communicating at the same time (?T one or the other?)
Q3: I presume that I2C and SPI are allowed only on pins D6 and D8 if Q1 is true (doc isn't really clear here, where are the hardware I2C and SPI?)

@Robin, Re Q1, I believe that Gordon is referring to the software 'port' of the code to the nRF52, not a specific hardware port. In the case of the MDBT42Q, the Espruino code only identifies one of each type of port even though the device supports up to 3 SPI, etc.
Q2: If NEO-6M is connected to any available SPI or I2C then it certainly can be used while BLE is active.
Q3: SPI or I2C ports can be arbitrarily assigned to any available GPIO pin. There are default pins, as defined in the Espruino Board package, but these can be overridden. Pin re-assignment occurs when you configure a SPI or I2C port as in:

SPI1.setup({mosi:D07, miso:D05, sck:D04, baud:1000000});

Sun 2019.03.31

'referring to the software 'port' of the code to the nRF52, not a specific hardware port'

Thank you for the clarification @TomWS that does make more sense, however, your comment:

'the Espruino code only identifies one of each type of port even though the device supports up to 3 SPI, etc.'

now generates another question, that is where may I ask is the declaration device supports up to 3 SPI? Three is specific, but the note below the image indicates one h/w and infinite s/w SPI. I was attempting to understand where the h/w SPI is defined and for which pins.

There are different types of support:

• hardware (only), also called appliances - hardware specific arrangements that predefine certain pins' function and registers/logic/micro program behind that does the work without (over)loading the CPU and even less the application code
  
• software, where everything is done in software w/ almost just any pin and driven by the CPU.
  
  

As you see, latter one leaves less horse power for the application because it is shared with functions that usually are implemented in hardware. Corollary, speed is the most impacted... so baud rates are usually much lower.

If - according to datasheet - a device supports up to 3 SPI - it has 3 predefined SPI appliances that can be used, and the choices of pins is limited to what these 3 SPI hardware implemented appliances define to be usable. Usually not all pins are connectable to all possible appliances. It is like a big old telephone switchboard where with patch/switch cables the connection is crated on request, for example, pins that serve multiple functions, like digital and analog reading are connected software controlled to either appliances for these functions:

• digital: to a 1 bit register that can be written to and read from by software
  
• analog: to a AD converter that on conversion puts the result into a multi-bit register (8...12..16), that then also can be read from by software. The conversion process though does not take any CPU resources; it is done by the hardware built-in AD converter 'appliance'.
  

The default espruino build for this model only has 1 spi defined:

https://github.com/espruino/Espruino/blob/master/boards/MDBT42Q.py#L60

Support could be added for SP2 and SP3 in hardware.

https://github.com/espruino/Espruino/blob/master/targets/nrf5x/jshardware.c#L1072-L1123

Pins are checked to see if they can be used:
https://github.com/espruino/Espruino/blob/master/targets/nrf5x/jshardware.c#L1164-L1169

Thanks @Wilberforce for the source links as that helps cement the h/w count as specified in the note on the module page.

Thanks @allObjects for the narrative.

'the choices of pins is limited to what these 3 SPI hardware implemented appliances define to be usable'

and, that is what I'm attempting to understand, which are the usable hardware pins?

If I view the color key, green for SPI, for the Pico

http://www.espruino.com/Pico

I am able to determine the three hardware SPI 'appliance' access pin numbers. (Note there isn't software SPI or I2C for the Pico STM chip)

As pointed out by the source code from links in #5 there is only one hardware SPI. But viewing the color key of the MDBT42Q, there isn't a color reference similarly to the Pico diagram.

Could it be that: as pointed out in #4 the CPU acts as the appliance for s/w defined SPI, and as internally the one h/w SPI 'appliance' needs to be wired (electrically) to the breakout board pins, that as long as there aren't any naming conflicts, may be wired to any three GPIO pins, thus no need for the green color key reference, as this would clutter the diagram and subject to how configured by the user code? (unlike the yellow key USART pin designations that apparently must be physically/electrically connected to only those pins)

@Wilberforce, exactly so! Thanks for adding the links.

(Note there isn't software SPI or I2C for the Pico STM chip)

@Robin, are you using MDBT42Q or STM chip???? (I'm not sure why you're mentioning SW SPI or I2C for STM chip in this context.) The subject line says MDBT42Q in which case, as I said in my post, you can assign ANY valid GPIO pin to a Hardware SPI circuit. As Wilberforce's links indicate, the construction of the MDBT42Q Breakout core code will only enable ONE SPI hardware block (the nRF52832 supports more). That one block, however, can be connected to ANY valid GPIO pin.

And, since your application seems pretty clear, you can simultaneously support communications with both your GPS receiver (via SPI, or I2C, or UART, no matter what pins you want to use) and BLE.

@TomWS am using the MDBT42Q breakout board.

'(I'm not sure why you're mentioning SW SPI or I2C for STM chip in this context.)'

In #6 the balance of that post starting with "If I view the color key, green for SPI, for the Pico"

I was drawing the correlation between the color keys that are present for the Pico but not for the MDBT42Q pin designation images, wondering why the h/w USART has a color key but the h/w SPI and I2C do not.

'you can simultaneously support ... both your GPS receiver ... and BLE'

Although I'll defer to @Gordon for that, my belief is that the USART Rx pin is checked, and if in a specified state, BLE is then not available with the IDE. Serial1.setConsole(true); Everything appears fine as long as the NEO-6M is physically connected to the specified USART pins.

The reason for freeing up the USART Rx and Tx pins is that in order to program the NEO-6M according to their data sheet, is to be able to use their U-Center API accessible with a USB-TTL converter. (which also functions when physically connected to the USART, and unfortunately removes the MDBT42Q, therefore no BLE)


It appears I may have another situation, as when I attempt not to use the h/w USART, I get this error: Uncaught Error: Function "setup" not found! at line 112 col 9 and error: Uncaught Error: Function "write" not found! at line 118 col 8 when attempting to send data out through the USART.

I may need to start another new thread as this error may not be related to this thread title.

wondering why the h/w USART has a color key but the h/w SPI and I2C do not.

As the comment under it says: "...Unlike other Espruino boards, these peripherals can be used on any pin.". There's no point me putting all USART/I2C and SPI tags on all pins :)

my belief is that the USART Rx pin is checked, and if in a specified state, BLE is then not available with the IDE

No - BLE is completely separate to Serial.

If you force the console to Serial1 with Serial1.setConsole(true) then yes, the console will go to Serial1 and not Bluetooth, so the Web IDE won't be able to connect. Bluetooth still works though and is then available for use by your code.

I think what you actually want is Bluetooth.setConsole(true) so let you use Serial1 without the REPL interfering with it, while allowing the IDE to stay connected over BLE

as when I attempt not to use the h/w USART, I get this error

Yes, start another thread for this and post your code - but note that software serial really isn't that reliable right now so you may hit issues.

Honestly, if you have one-time configuration to do on the GPS, then use the USB UART device they recommend with the app that they provide for it. You're just making your life needlessly difficult trying to go through Espruino.