Developers

This is a list and description of the most important folders in the repository.

├── config/ - configuration header files
├── └── featuresets/ - different build configurations
├── inc/ - main include directory for C++ headers
├── ├── c/ - includes for c code
├── └── nrf52/ - specific nrf52 includes
├── inc_c/ - include directory for C headers
├── linker/ - linker scripts
├── sdk/ - modified nRF SDKs
├── softdevice/ - softdevice hex files
├── src/
├── ├── base/ - wrappers for SoftDevice functions
├── ├── c/ - drivers and other c code
├── ├── mesh/ - mesh functionality
├── ├── modules/ - functionality wrapped in modules
├── ├── utility/ - helper classes
├── ├── Boardconfig.cpp - runtime pin and board configuration
├── ├── Config.cpp - configuration
├── ├── FruityMesh.cpp - bootup and main functionality
├── ├── GlobalState.cpp - holds references to basic classes
├── └── Main.cpp - Startup Code
├── util/ - tools and utilities
└── src_examples/ - code templates and examples

Functionality that is not part of the meshing algorithm should be placed in the fruitymesh/modules/ folder and extend the Module class. A Module will receive all events that it is interested in and can save and load its configuration from flash memory.

Have a look at Class Structure for some more detailed explanations on how the code is structured. Also keep in mind Instances when implementing new functionalities.

There are some utilities in the /util folder, for example a python script that will open a putty terminal for all connected serial devices and a wireshark dissector that can be used together with the nRF Sniffer to inspect the advertising packets.

Most settings are found in the fruitymesh/config/ folder in Config.h. Module specific settings are kept within the Module’s header and cpp file.

FruityMesh uses so called featuresets for creating different distributions for different use-cases. A featureset defines the compile time and run time configuration for a Node. The make process can be configured differently for a featureset, a number of different defines or macros can be used during compile time and different code is used during runtime. This also allows FruityMesh to run on a number of different boards (different pin settings or configuration) with the same binary. You can specify the featureset by e.g. calling make with make FEATURESET=featureset_name or by creating a Makefile.local

FruityMesh does not run on devices with only 16kb of RAM. It might be possible to optimize the build and resize some buffers, but this is currently not supported. The binary of FruityMesh is around 50 kb depending on the configuration and will easily fit on devices with 256 kb flash together with the softdevice and still be updatable using dual bank updates.

All kinds of contributions are welcome. Before you start coding, we’d love to talk to you to make sure that we get along nicely in the development process :-)

If you have a general question, the best way is to open a new issue and label it with "question". This way, we can build up a knowledge base of questions and answers that are easily accessible in the future. If it is a commit-specific comment or question, you can just comment under the commit.

We’d love to develop the FruityMesh protocol as an interoperable protocol that works across devices from different developers. If you want to make any changes to the protocol itself, please contact us first so that we can work out a mutual agreement. Every implementation that is compatible with the current official release of FruityMesh is welcome to use the M-Way Solutions Company identifier (0x024D) in the manufacturer specific data along with the current mesh identifier. Be sure to read the Specification for some basics. That is only very basic documentation, we will try to continually improve the specification and add more details. In the meantime, do not hesitate to contact us or have a look in the implementation.

The implementation has been written in C++ because this makes it easy to implement new functionality and seperate it from other parts in a clean way. Refactoring or refinement tips are welcome. If you contribute, please comment your code thorougly and keep the implementation as readable as possible. This will help other contributors understand the code quickly. If you have documentation to add, please post a pull request as well.

FruityMesh is published under the GPLv3 version which is available in the repository.

TODOm Dual licence ?