I like the Meshtastic project and really appreciate the documentation effort you’ve put in. It seems as though I cannot simply install Meshtastic as an arduino lib on platformio.
Basically, I’d like to use the functionality of Meshtastic to send messages over my ESP32 nodes that have lots of other code of mine. So Meshtastic will provide a communication layer with features like on-the-edge device preferences, etc.
Have you considered shipping Meshtastic as a lib? What would you suggest at the moment - pulling the sources of Meshtastic as a submodule in my project?
The way Meshtastic is written currently is unfortunately not suited as a library. At times, the MCU can be quite busy and without RTOS, you cannot guarantee it to still work if you have a lot of other code running as well. We even see packet loss happening now already due to e-ink updates that take quite some time, for example.
There is actually a Meshtastic Arduino client library, which you can run on a separate MCU together with your own code. Using the SerialModule, you can then control a Meshtastic device, e.g. to send messages or do something based on received messages.
Yes, I’ve had a look at Meshtatic Arduino lib already. It does not support LoRa communication - the heart of Meshtastic.
I don’t mind large utilization of CPU and/or RAM resources allocated to Meshtastic. I’ll write my own screen updates based on M5eZ. I’ll use only a subset of Meshtastic modules: RFInterface and MeshService.
When I add https://github.com/meshtastic/firmware to Platformio lib_deps or set extra_config to lib/meshtastic_firmware followed by cloning your repo to the lib/ folder, it does not pick the necessary dependencies (I’m not that proficient with Platformio configuration). The only way I see is to fork your repo, add the library.json file, and try it out.
If you manage to successfully separate the MeshService and RadioInterface from the main firmware, please let it know. That would be very interesting, but I’m afraid you’ll run into issues that these parts are too intertwined with the rest of the firmware.
One other option you have is to confine your own code into a module, using the Meshtastic Module API.
The problem with the Module API and the whole idea of integrating user code into a Meshtastic module is that you use custom OSThread that is not compatible with FreeRTOS, utilized in ESP. Some logic like polling a sensor can be rewritten with an OSThread (and I’ve succeeded in that) but the rest of the essential logic, custom graphic libs like M5eZ, cannot be ported into OSThread and the app fails if I spawn a separate FreeRTOS native thread for graphics (because all your modules that rely on OSThread won’t be called).
Sadly, being able to neither wrap my logic into a Meshtastic Module nor FreeRTOS, nor use Meshstastic as a library, I’m forced to abandon Meshtastic at all and write my own radio interface from scratch, perhaps borrowing some of your ideas and implementation.
Where we have devices now like the T-watch S3 and other dual core devices coming out, I would really love to see this added as an option for makers. There’s not really a point of having a watch completely dedicated to Meshtastic without being able to run other code on it (e.g. a watch face, calculator, IR remote, etc.). Interfacing with a 2nd MCU defeats the point of having the LoRa built into the watch in the first place and utilizing the Module API is too limiting. There are simple techniques that could be utilized to get around sharing of resources. Please consider adding this to the roadmap.
oh I totally agree… I think they have future plans to do something with the T watch s3 but at the moment the current build renders it only as a node when the watch can do so much more… seems a bit of a waste since meshtastic is simply about nodes, it doesnt seem to fit what meshtastic are doing. I don’t understand why it can’t be added as a library, boot it as a app that reboots/restarts the watch in meshtastic firmware mode and when the watch restarts/power cycles it goes back to being a watch again or something?.. I don’t know how hard that is to program, i’ve been away from C++ for about 20 years, so I can’t really have a go at it… obviously battery life is the other issue here with the t watch s3… out of most of the devices running Meshtastic, this one is a bit of an anomaly.