Support for Raytac's MDBT40 module (nRF51)

[Heimdall11]

Does this core also support nRF51822 based MDBT40 module from Raytac? Here's the product link-
http://www.raytac.com/product_detail.php?id=38

Thanks

[dlabun]

Not directly... You would need to take the generic device and modify it to match the MDBT40 pin out.

[nhnifong]

Here's a spec on the MDBT40.
https://www.tinyosshop.com/datasheet/MDBT40%20spec-Version%20A4.pdf

I've been trying to modify the generic device, and I'll really like some guidance on the purpose of the fields in the variant.h and variant.cpp files of a board definition.

1. In variant.cpp, What is g_ADigitalPinMap a map from, and to?
2. In variant.h, there seem to be two numbering conventions. for example in
   #define PIN_SERIAL_TX (1) // P0.01
   The one being defined in parens, and the p0.01 in the comments? what's the meaning of these, how does it relate to the map in variant.ccp?
3. Should PINS_COUNT and NUM_DIGITAL_PINS ever differ?
4. The raytac mdbt40 has no led, should PIN_LED be 0?
5. The raytac mdbt40 appears to have no analog pins other than XL1 and XL2 for connecting to the crystal. Should these be defined in A0 and A1, somewhere else? left out? should A0 thru A5 be 0?
6. Basically all the other pins are generic digital io. None are marked specifically as tx and rx in the MDBT40 spec, though in my case, the MDBT40 is soldered onto another board (GBR-RC2100-BTM-V2_01) which is using two of them for tx and rx. So, it seems like any tx,rx definitions for an MDBT40 would be specific to whatever it's incorporated into.

Sorry for all the questions!

[sandeepmistry]

In variant.cpp, What is g_ADigitalPinMap a map from, and to?

From an Arduino pin to a Nordic pin.

Should PINS_COUNT and NUM_DIGITAL_PINS ever differ?

Yes, NUM_DIGITAL_PINS is the number of broken out digital pins. PINS_COUNT is the total pins.

4. The raytac mdbt40 has no led, should PIN_LED be 0?
5. The raytac mdbt40 appears to have no analog pins other than XL1 and XL2 for connecting to the crystal. Should these be defined in A0 and A1, somewhere else? left out? should A0 thru A5 be 0?
6. Basically all the other pins are generic digital io. None are marked specifically as tx and rx in the MDBT40 spec, though in my case, the MDBT40 is soldered onto another board (GBR-RC2100-BTM-V2_01) which is using two of them for tx and rx. So, it seems like any tx,rx definitions for an MDBT40 would be specific to whatever it's incorporated into.

I'm not sure what the advantage of having a separate variant from the generic is for a module. Variants are more intended for developer boards.

[dlabun]

I think more and more users are coming across this project and are looking for out of the box support for mass produced nRF modules they can get off the internet. As long as the community wants to submit new variants to the project, I see no reason not to start supporting more prebuilt modules as it's not too terrible of an administrative burden.

I also see this as an opportunity to get more help from the community to update the project to a later revision of the Nordic SDK and ARM compiler.

[nhnifong]

MDBT40 isn't really a development board. It was in the bluetooth module that came with a Chinese robotic arm I was tinkering with called an XYZ Robotics 6 DOF robotic arm kit. The configuration I used was only different from the generic in the TX and RX pin numbers and everything else was apparently not important.

I was able to successfully program it, with your help, so thank you. I just wanted to contribute something in return. If you don't want the maintenance burden, that's ok. Perhaps I'll leave just the relevant files in my forked repo (is that normal around here?)

I seriously doubt I'll be of any help with the Nordic SDK migration, sorry.

[sandeepmistry]

I think more and more users are coming across this project and are looking for out of the box support for mass produced nRF modules they can get off the internet. As long as the community wants to submit new variants to the project, I see no reason not to start supporting more prebuilt modules as it's not too terrible of an administrative burden.

@dlabun maybe the modules can just be a boards.txt entry and use the Generic variant folder for pins. Since there is no fixed pins for UART, SPI, I2C etc. the <something>.setPins(...) API makes a lot of sense.

MDBT40 isn't really a development board. It was in the bluetooth module that came with a Chinese robotic arm I was tinkering with called an XYZ Robotics 6 DOF robotic arm kit. The configuration I used was only different from the generic in the TX and RX pin numbers and everything else was apparently not important.

@nhnifong got it, in this case a specific variant for the robotic arm would make sense. However, as @dlabun mentioned there is value for having a variant for the module too.

[sandeepmistry]

@dlabun regarding #302 (comment), what do you think about my comment above?

For #297, I think we can remove the Raytac_MDBT40 folder and change the following boards.txt line from:

Raytac_MDBT40.build.variant=Raytac_MDBT40

to

Raytac_MDBT40.build.variant=Generic

The selected UART pins in the variant are a bit specific to the "XYZ Robotics 6 DOF robotic arm kit" in my opinion.

Then some how also enable the <something>.setPins(...) API's like: https://github.com/sandeepmistry/arduino-nRF5/blob/master/cores/nRF5/Uart.h#L34-L37

If you are happy with the way #297 is for the v0.6.0 release, we can merge it as is.

[dlabun]

@sandeepmistry I'm honestly unable to make up my mind on this one... We have other boards like the hackaBLE and RedBear Nano that are essentially just breakout boards for these very same Raytac modules. Part of me says stay with status quo, merge it and push out v0.6 while another part says now is the time to draw the line between generic modules and dev boards with hard-fast pin assignments.

Do you want me push out v0.6 and hold this PR for further debate?

[dlabun]

Should have read the PR first.... Since changes are required I am going to hold it out of v0.6 regardless of this conversation.

[sandeepmistry]

Should have read the PR first.... Since changes are required I am going to hold it out of v0.6 regardless of this conversation.

Sounds good.

We have other boards like the hackaBLE and RedBear Nano that are essentially just breakout boards for these very same Raytac modules.

The RedBear Nano has some (suggested) pin outs in it's docs:

I must admit I didn't carefully look at the hackaBLE entry at the time, the tindie store images don't clearly specify any specific UART, SPI or I2C pins like the Nano: https://www.tindie.com/products/ElectronutLabs/hackable-tiny-nrf52832-ble-development-board/

[sandeepmistry]

Update: I've found some pin out docs for the hackaBLE here: https://github.com/electronut/ElectronutLabs-bluey#pin-mapping

[dlabun]

Your second post is for the Bluey, not the hackaBLE... But anyways, that line between generic module and dev board is getting more difficult all the time.

[sandeepmistry]

Good catch, I followed some links from the hackaBLE page and ended up there.

For a generic module, I think as a minimum we should support setPins(...)'s API's for it to be customizable. Then having it's own variant folder for default pins is a coin flip.