Hi all, I worked at Wyres SAS based in France, and we started using MyNewt on our STM32L1 LoRa boards beginning of 2019. We got into it because it was recommended by another French LoRa company (Kerlink) who use it as the base OS for their LowPower-Iot LoRa Reference Design for lora objects. Initially for a student project to get experience with it, then integrated into a CD/CI-build chain integrated with our gitlab/jenkins servers (to align with our existing backend java dev CI). One of the major points in the favour of MyNewt was the newt+yml build tools and the structure allowing a lot of flexibility in the dev architecture....
We used it in our most recent product releases start 2020 (although Wyres has now been absorbed by Kerlink and this product range is no longer available). As part of our dev, we aimed to build 'useful' blocks as repos on top of MyNewt to help the application development - simpler logging/error handling integrated with the assert/reboot cycle to help with debug - some basic utilities (circular buffers, gps nema parsing, cbor) forked in from other projects - a lorawan stack wrapper with an api suited to async operation - blocks to homogenise/manage config, time, gpios, leds, low power, uart access, ble and gps operations - state machine framework to structure the application around a state machine event-based pattern - core application framework as a generic state machine that fits a lot of IOT device operations (so the core device operation and message format is very stable across mulltiple products) and a plugin 'module' architecture for product specific operations (eg doing sensor reading, or accessing a GPS). The config framework offered by mynewt via the pgk.yml and syscfg.yml was critical to being able to structure and make independant the framework - it helps a lot for the re-use design! --publicity alert-- all of this code is released under an open source apache license, runs directly on MyNewt, and is available on github here: https://github.com/wyres/mynewt-generic-base https://github.com/wyres/mynewt-generic-app (as well as the BSP for our lora card) --end alert-- MyNewt is not perfect, there are rough edges or overly complex bits (IMHO!) which make some functionality hard to use (we rolled our own device driver code and config apis for example) Wish list? Improve the newt build speed: - have the 'newt' tool be more intelligent about which yml files it parses (currently every one it finds, rather than those referenced by the target being build) - move the BSP modules into separate repos, to lighten the mynewt-core repo and increase build speeds (and also change updates that reference BSPs that I don't care about!) Add control of the low power operation (alert bsp/app to low power entry, allow selection of low power 'level' by app, etc) - we added some features to a fork of the core for this for our MCU (but haven't managed to make this a viable/acceptable PR yet...) As a final point, it seems like FreeRTOS and Zephyr are getting a lot more of the 'visibility' right now (due to integration with some big names) - I think the biggest risk for MyNewt is falling behind in the BSP/MCU support race and not getting the love it deserves! I see I have written a lot more than I intended - sorry about that - hope some of it helped! A+ Brian ________________________________ De : Vipul Rahane <vrah...@gmail.com> Envoyé : lundi 7 décembre 2020 22:49 À : dev@mynewt.apache.org <dev@mynewt.apache.org> Objet : Re: mynewt roadmap and future Hello Mike and others, I have started working for Proxy Inc recently and it gives me immense pleasure to mention that Proxy has been using mynewt since a few years and have deployed a lot of products using the same. We would be contributing a few drivers, middleware modules and BLE related functionality to mynewt in 2021. While I am a bit of an active maintainer of mynewt, we should see more soon :-). Others using mynewt, please chime in. On Tue, Dec 1, 2020 at 2:10 PM Aditi Hilbert <aditi.hilb...@juul.com.invalid> wrote: > Hi Mike, > > We used Mynewt OS + NimBLE in our first connected product offering at Juul > Labs. We decided to use it on our next connected device as well. In the > process we worked on and submitted PRs for the NimBLE controller + host > code that runs on a new Dialog chip. We hope to get that Bluetooth SIG > certified in the next few months. NimBLE has been ported to Linux, > FreeRTOS, Riot as well - so you have a few options there for the OS. > > There’s a mynewt-core release planned in a month or so. The community > should be reviewing and resolving most of the outstanding PRs before that. > > I should admit Juul getting “right-sized” earlier this year has limited our > activity somewhat, but we are still quite active with patches and PRs to > the mynewt suite of modules when we need them. I urge other companies who > have adopted Mynewt to speak to their experience in this thread. Slack is > the other forum where a lot of technical conversations happen. > > thanks, > Aditi > > On Mon, Nov 23, 2020 at 11:09 AM Mike Grobler <mike.grob...@pax.com.invalid > > > wrote: > > > PAX Labs has used mynewt for one of its nRF based products. We are > > contemplating using mynewt on a new product, but before we commit, we > would > > like to understand the future of mynewt. > > > > Please would someone provide a knowledgeable mynewt contact with whom we > > could have a quick 30-min meeting? > > > > -- > > _____________ > > Mike Grobler > > Firmware > > PAX Labs <https://pax.com/> > > > > mike.grob...@pax.com > > > > > -- > Aditi Hilbert > Juul Labs <https://www.juullabs.com/> | 560 20th Street, San Francisco, CA > 94107 | > < > https://www.juulvapor.com/skin/frontend/juul/live/images/juul-labs-logo.jpg > > > < > https://www.juulvapor.com/skin/frontend/juul/live/images/juul-labs-logo.jpg > >[image: > photo juul labs_sig2_zpsb4y2zjwf.jpg] <https://www.juul.com> > This message and any files transmitted with it may contain information > which is confidential or privileged. If you are not the intended recipient, > please advise the sender immediately by reply e-mail and delete this > message and any attachments without retaining a copy thereof. > -- Regards, Vipul Rahane Staff Firmware Engineer | Proxy Inc | https://www.proxy.com
