I am starting an experimentation effort with Nordic Mesh SDK. I am using Segger Embedded Studio.
I can open/compile/download the Mesh SDK examples.
I wish to start to modify the supplied examples, and I have a few question related on how to and "best practice" to achieve the following.
I tried to find how to proceed browsing the developer network and the internet, but I found partial answers and usually not recently posted.
Can you give me the right hints and/or point me to the right documentation for these "basic" topics?
Many thanks in advnace and
Davide De Nardis
It sounds a bit strange that you would have to do this manually. What change is this, I might be able to find a way to do that from within SES. If it is only what preprocessor define to use for the board then you could just change it in the "Common" options for the project. You should find "Preprocessor Definitions" there under "Code" -> "Preprocessor".
This is poor answer. Why do you (Nordic) not give detailed, clear direction on how to start out with designing for custom boards? The SDK docs give the briefest treatment:
To add support for a custom board, you must create a custom board support file with the name custom_board.h. This file must be located in a directory in the Include path. You can then select to use the custom board by adding the define statement #define BOARD_CUSTOM.
The easiest way to create the custom_board.h file is to start with an existing platform definition file (for example pca10040.h) and adapt it to your needs.
Is that really all there is to say?!
Detailed application notes would be extremely helpful. For each peripheral and for helping users adapt the SDK to their designs.
How on earth you are successful as a company with this kind of support is beyond me.
Thank you for your valuable feedback. While we strive to provide the documentation, guides and support needed for reaching your goals, we are aware that we have blind spots. Pointing out those blind spots is appreciated!
Are there particular points in the "Adding support for a custom board" documentation that are unclear, or is the main issue that we do not have a full tutorial-like document?
I'm glad you feel it's valuable.To be clear, no, it's not that the documentation is unclear, it's that you don't provide any guidance on this aspect at all. This is the fundamental part of embedded development!
You provide examples in the SDK but they are not thoroughly documented and commented.
The frequently cited advice to copy and paste an example amounts to little more than cargo cult programming. As I posted elsewhere, you don't have any application notes. I offer this as an example of how it is done well:
If you delve into their documentation there are examples for each peripheral with schematic diagrams and code samples. The examples are minimal and clear and follow a consistent format.This layer of documentation is vital and is yet it is entirely absent from the Nordic canon.
Thanks, I think I understand a bit more what you are referring to now. From what I can understand, this is in part a difference in approach, and in part - as you write - lack of guidance on one or more given aspects.
What we do have, is for each SoC the full hardware documentation for the peripherals, with registers, and in some instances also a couple of lines of code. See e.g. the SPI master documentation in the nRF52832 Product Specification.
What we also do have, is documentation for the high-level libraries in the SDK, both general information about the libraries and API documentation. See e.g. the SPI transaction manager library documentation (with some example lines of code) and the SPI transaction manager API documentation. From what I understand, this is one point where better overall documentation including to-the-point code excerpts are lacking.
Then there are the examples in the SDK. See e.g. the SPI Transaction Manager Example. Today these work as "quickly getting something up and running". But they are less suited for "figuring out how things work" / "build custom applications from", in particular due to lack of documentation providing a thorough understanding of how each component works.
For some aspects of development we have tutorial like guides, including guides for some aspects related to the SDK. For some of the issues raised in this thread this could be a good place to add more guides.
For some aspects of development we have Application Notes and White Papers, albeit predominantly hardware related. There seems to be some missing pieces for the software side of things.
We are aware that we have little or no low-level application notes / guides / documentation for how to use peripherals/registers directly. Simply put, as is, we expect anyone interested in direct registry manipulation to read the product specifications and look at the low-level header files directly. We expect the vast majority of developers to use our higher level libraries and never need to manipulate registers directly. Therefore, the higher levels of the SDK is where we primarily put our documentation efforts.
So in summary, I see that there are some missing connections on the higher SDK levels, regarding getting an understanding of how things fit together. I also get what you mean by "cargo culture programming", in particular when starting on a new project. This is definitely something I will bring up internally, and see what we can do to improve on. Any further feedback might be useful in that regard. If you have the slightest feeling or idea that I might have gotten something wrong here, then please let me know.