Hey there everyone. Please join us for a virtual Q&A session with the Bristlemouth core development team. We’ll be quickly covering the state of Bristlemouth, what’s coming up next, and plenty of time for questions.
** Q: Where can I get started if I want to start getting familiar with the programming?
** A: Start posting on Projects or Pioneer Program and let folks know what you’re working on and ask for some advice on approach.
** A: Separate the whole effort into smaller bite-size parts. E.g. getting data from a sensor, parsing data, sending data to the SD card, getting the right power set.
** Q: Any support for Windows and/or Linux [for the onboarding guides]?
** A: Windows will be a while. Linux is likely to be sooner, no concrete dates but we’re going to try to get this slotted in pronto. [Let me also add, that if you know your way around Linux really well you can likely do most of what’s there now.]
** Q: You mentioned an Arduino integration, what about RasPi?
** A: Yep. We want to be as universal as possible.
** Q: Where can I get started with specific water quality sensors?
** A: Multiparameter sondes are the state of the art. They are very expensive. It may be better to start with something as a proxy or proof of concept. Maybe from Atlas Scientific or Sparkfun.
Thank you very much to everyone who was able to join us on the panel or as a guest. See you at BristleCon!
As you can see there, the 2nd and 3rd parameters are a buffer of data and the length of that data. There are no restrictions on the content of the buffer.
In order to receive the data elsewhere, you’ll have another node calling bm_sub to subscribe to a topic. You provide a callback to bm_sub that will get called by the system when any messages arrive for that topic.
Hope that helps! And of course ask if anything’s unclear.
The maximum message payload is currently a bit under 1500 bytes:
#define MAX_PAYLOAD_LEN (1500 - sizeof(struct ip6_hdr) - sizeof(struct udp_hdr)) See src/lib/middleware/middleware.cpp for more details on the interface between messaging middleware and network layer.
This is constrained by the MTU of the 10Base-T1L PHY. We have a roadmap item captured to implement mult-packet support in the network layer and make the message interface to middleware clients transport-agnostic. (But we can’t promise specific timing on that feature yet).
The proof-of-concept MicroPython support worked as of my last testing, which was performed on version v0.3.0. We don’t have a timeline for fully supporting this yet.
It is possible to build MicroPython into a Bristlemouth app. This includes a REPL and some initial platform support. The necessary information is currently in the commit log. I will reference the specific commits below.
The three necessary steps, from my experience, are:
add -DUSE_MICROPYTHON=1 to your cmake invocation
depending on your build platform, you may need to follow the instructions in the ENV_SETUP.mdhere
for effective use of the REPL via the USB serial console, decrease the frequency at which the onboard sensors are being sampled and printed to the console. Instructions here. Perhaps 10 seconds is appropriate.
Please let us know if you have any further questions!
commit fc657c6ff0de3ec3246ff5d48728102956a3906c - how to build
Adding VERY basic micropython support! (#273)
* Adding VERY basic micropython support!
Added it to bridge app when cmake flag of `-DUSE_MICROPYTHON=1` is used.
To test, build bridge app with `-DUSE_MICROPYTHON=1`, connect to pyserial-miniterm with `--raw` argument and run the `repl` command :D
* Add micropython to ci 🤦♂️
* Fix ms delay
Co-authored-by: Russell DeGuzman
commit 36de147c1706705f8fd7d33bef9d969590cf2157 - adds device info
Add our very first micropython module! aka `device` (#275)
* Use micropython heap size from CMakeLists.txt
* Make sure `make clean` removes generated micropython stuff
* Move APP_NAME define lower (so we can include in APP_DEFINES and MICROPY_DEFINES)
* Add our very first module! aka `device`
commit 9bba99f7b96ad179fe9c4003e06c0017b2cb9556 - bristlemouth platform support details
Micropython Improvements (#322)
* Trying to get modules working
* Many changes!
`import time`, `time.time()` now provides the correct time and date using RTC!
We can now import and pre-compile python modules from both the micropython-lib submodule as well as custom made ones!
* Start adding `machine` module
* Adding _very_ basic I2C support in micropython
Disabled -Werror for micropython 😭
Example use of i2c in micropython
MicroPython v1.20.0 on 2023-06-12; bristlemouth with stm32u5xx
Type "help()" for more information.
>>> import machine
>>> i2c = machine.I2C(1)
TODO: Initialize with freq and timeout
>>> i2c.writeto(65, bytes([0x3E]))
>>> i2c.readfrom(65, 2)