Create includable headers for modems and mcus

[SRGDamia1]

Instead of super massive example ino

Use extern to get variable values as needed

[neilh10]

I'm already trying some of this - the challenge seems to be to abstract the hardware platform in the top level example ino -
It seems to me there are a few ways into ModularSensors from a users perspective and progressively adds more value for individuals and teams -
a) as a tutorial where the hardware platforms & sensors are expressly purchased/specified to get into the easy tutorial and the functional tutorial only rarely changes even as software evolves, and the tutorial is a main focus
b) a target sensor "project" environment where the hardware platform is selected based on expected field deployment project requirements, trialing the target sensors for small projects 2-5 devices including project support, where proving the sensor data collection is the main focus
c) a multiple site project environment designed to be able to scale to 5-50 field devices, where repeat-ability across the project
d) an evolving solar powered sensor collector platform that can grow functionally as hardware platforms support it (ARM SAMD ram32k to ARM nRF25xx ram256k support new IoT BT LE longer distance and WiFi 900Mhz and LTE)

So trying to go from the current mayfly to a SAMD1 (but could be nRF25xx with 256kram) is proving to be challenging..
One way model is to use CONFIG (or KCONFIG) concept as way of controlling the subsystems/classes and keep the top level application readable/clean
https://github.com/platformio/platform-espressif32/blob/develop/examples/espidf-ble-adv/src/sdkconfig.h
however that appears to also be an evolving challenge for platformio
https://community.platformio.org/t/tips-for-importing-an-esp-idf-project/5571/2

[SRGDamia1]

What problems are you having with the SAMD21 board? I've tried to test everything on the Adafruit feather M0 that I have before deploying and I haven't found it to be difficult at all. The only thing I change in the program in switching from on to the other is the pin numbers.

[neilh10]

Well I really appreciate the framework that you have put together for AVR & Feather/SAMD21 - but as the SAMD hardware fault showed a different platform is a different challenge and takes testing - and its so nice to have a tutorial when some one has done it already :) but then one forks - and now its surfing with a lot of white water in the wake as well as trying to lean into a different wind.
So this comment was really about what I perceive see the potential future weather to be for ModularSensors and some of the choppiness I'm experiencing.

..... the lib_ldf_mode = deep+ really screwed me up in pulling in multiple libs, especially as it turns out switching different outofdate branches and then getting into understanding library.json . With improvements in a resetPin for the TinyGSM that worked initially for AVR but not for SAMD .... its pretty slow for .piolibdefs to rebuild
So overall I'm focusing on having foundations for main.cpp/.ino with different two(+) hardware platforms. The white water wake for my forked Mayfly/XbeeS6+Wingboard/12V I'm surfing, but getting similar results for Autonoma is still evolving.

Its taken some time to find platformio options for building
[platformio]
;env_default = mayfly
;env_default = adafruit_feather_m0
env_default = sodaq_autonomo

so the learning curve is pretty steep with a forked ModularSensors ...... and I'm also trying to get a PlaftformIo/BlackMagic Probe emulator intergrated - good for device driver testing. That of course wipes out the SAMD21 boot that turns out is embedded in flash not rom. :) ... so somewhat normal for new system development ......

[SRGDamia1]

Done.

[aufdenkampe]

Yes! PR #252 does this!