bluerange-io / bluerange-mesh

BlueRange Mesh (formerly FruityMesh) - The first completely connection-based open source mesh on top of Bluetooth Low Energy (4.1/5.0 or higher)
https://bluerange.io/
Other
288 stars 109 forks source link

Problems when compiling the cherry simulator when a custom feature set is using a newer Nordic SDK #206

Closed cfrstr28 closed 3 months ago

cfrstr28 commented 8 months ago

Hello,

currently I am facing some problems with the cherry simulator. Perhaps you can assist me.

In accordance with the instructions, I have created a __build folder with the subdirectory 'vs' and subsequently executed cmake ../../ -DBUILD_TYPE=SIMULATOR -A Win32 in this folder, using the following tools: -- Building for: Visual Studio 17 2022 Build type is SIMULATOR -- The C compiler identification is MSVC 19.37.32825.0 -- The CXX compiler identification is MSVC 19.37.32825.0

Upon opening the resulting .sln file and compiling the simulator, I encounter the following error message, which is presumably related to the Nordic SDK used:

However, when I follow the same steps with the reference implementation, I do not encounter any error messages, and I am able to execute the cherrysim-runner.

As far as I understand, the reference implementation uses Nordic SDK 14 for the simulator. Could these issues arise because we are using version 17 of the SDK for our implementation? Can the CMake files be adjusted without complications to use version 17 for the simulator as well? If so, how can this be accomplished without deviating significantly from the reference implementation, making changes exclusively to the CMakeLists.txt in the cherrysim folder?

I look forward to hearing from you and wish you wonderful holidays and a great start to the new year.

Best regards Christian

mariusheil commented 8 months ago

Hi,

there is no VendorPingModule in the official codebase, so I think you have added this yourself. Maybe by following the HowTo from this page? https://www.bluerange.io/docs-internal/fruitymesh/ImplementingCustomModule.html

CherrySim uses the FruityHalNrf.cpp together with SystemTest.h/.cpp to implement the hal functionality as close to the nRF SDK as possible. As we have started with SDK14, this has not been refactored for now.

The issue probably arises because you have included a specific header in your custom module that was fetched from SDK17. The first question would be, if this is necessary. If possible, you should use the functionality from the FruityHal (if available) to make sure there are no problems if your implementation and FruityMesh work on shared resources (peripherals, flash, nrf drivers, etc,...) that are not safe to use in parallel.

If you need to use functionality that is not available in the HAL, the best way would be to extend the HAL with this functionality and make sure the functionality is implemented for both SDK14/17 at the same time. However, this might be too much for your use-case in the beginning.

So what you can do as well is to make sure that you include the functionality using "#ifndef SIM_ENABLED [....] #endif". You need to add these sections to your includes and to your implementation. Of course, the simulator will not be able to simulate this functionality later as it is not compiled in. You can decide to write some simple mock functionality instead.

The CMake files of your featureset are not used for the simulator. The simulator compiles all featuresets in one binary, so it will also not honor preprocessor directives used in the featureset headerfiles.

Hope this helps, Marius

domhel commented 5 months ago

Are you still having issues and need further help or clarification?