Stefano is a professional engineer in Telecommunication Engineering. He started developing software in MATLAB and C for a ray-tracing and earth subsurface tomography, a cluster computing solution. Then he moved working with Qt and C++ for a GUI-based subsurface imaging product. After a really nice period with plain Modern C++ in a financial cluster computing institution, he encountered the Yocto Project and never left it. He is currently Head of the Competence Center Embedded Systems at the consulting firm adesso Schweiz AG. Father of two daughters, high-handicapper golf player, host at C++ User Group Lugano and ISO C++ Committee Member, co-founder of Italian Embedded.
Preparing a firmware image has never been so easy. Avoiding the struggles to implement a custom software update procedure. Facilitating even more the developer life. Freeing time to concentrate on the actual business logic of the application. All these targets are reachable if you start your next product development from the implementation of the chosen software update strategy. Leveraging all the community-backed implementations of common best-practices will help your team in delivering safer and maintainable products to the market on schedule. I will briefly show you how to have a FOTA-first approach with the Yocto Project, SWUpdate and Jenkins pipelines on a RaspberryPi 3.
What is the primary reason Stefano recommends a "FOTA-first" approach when starting a new product project?
ATo avoid having any bugs in firmware because OTA updates eliminate the need for testing.
BTo ensure the product is designed from day one to be updatable in the field so the update procedure is tested throughout development and devices can be updated easily.
CTo replace field service engineers entirely so no one ever needs to visit devices again.
DTo guarantee that hardware will never need to be changed because software updates can cover all future requirements.
ETo minimize development time by postponing software quality checks until after deployment.
In Stefano's CI/CD example using Yocto and Jenkins, what important role do the CAS YAML configuration files play?
AThey act as the device-side agent that downloads and applies SWUpdate packages on the product.
BThey define the build repositories and dependencies and serve as a manifest for reproducible image builds.
CThey contain the binary SWU update payload that is directly flashed to each device.
DThey are used to run unit tests and sanitizers on the target device automatically.
EThey are proprietary configuration files only compatible with Raspberry Pi 3 and cannot be reused for other boards.
Which best describes the delivery step used in Stefano's demo to install an update on the Raspberry Pi 3?
AA cloud backend pushes a notification and the device automatically pulls and installs the update without any manual steps in the demo.
BJenkins directly flashes the SD card of each device over USB as the delivery mechanism in the demo.
CThe pipeline builds an SWU update file, then the demo connects via SSH, copies the image to the device and instructs the SWUpdate client to install it.
DThe demo uses a custom home-grown update protocol instead of SWUpdate to demonstrate flexibility.
EUpdates are delivered by physically swapping hardware modules so the device receives new firmware.
Me too :( but I hope you have one spare in your lab or among your colleagues to try it out. Let me know if you have a specific topic you want to deep dive into.
Thanks @TimGuite, you exactly got the aim of this micro talk right. Hope you'll can follow along the repo yaml configuration files and have a PoC smoothly working within hours.
Thanks for the talk, very interesting. Not sure about the general availability of Raspberry Pi 3 (or 4) these days ;-)