Hello All, Just wanted to say that there are people here to review and apply patches. As Brian wrote - there is more love needed and that comes from contributors - therefore please do not hesitate to upstream your code as much as possible.
Codecoup cares about Mynewt and especially Nimble, where we keep contributing. Best Łukasz On Tue, 8 Dec 2020 at 09:47, Brian Wyld <brian.w...@wyres.fr> wrote: > > 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
