GPIO across Linux and Zephyr kernels
Maximizing code reuse in the example of the Oniro doorlock blueprint
- Track: Embedded, Mobile and Automotive devroom
- Room: D.embedded
- Day: Saturday
- Start: 17:30
- End: 18:00
- Video with Q&A: D.embedded
- Video only: D.embedded
- Chat: Join the conversation!
Sometimes it is useful to share code across multiple kernels -- in projects like the Oniro door lock blueprint, for the typical use cases a Cortex-M CPU running Zephyr is more than sufficient, but using its functionality as part of a larger project makes using Linux on Cortex-A an interesting option. Can we find a way to maximize code reuse despite the very different GPIO APIs?
Sometimes it is useful to share code across multiple kernels -- we avoid doing the work twice. However, this might be complicated when one version is using Zephyr with a Cortex-M, and another Linux on a Cortex-A. We will explore this problem using an example of the door lock blueprint from the Eclipse Oniro project - an implementation of basic door lock functionality. For a typical use-case, a Cortex-M with Zephyr is more than sufficient, but we might also want to integrate the same application in a bigger one using Linux on a Cortex-A. Will we find a way to do so?
Speakers
Bernhard Rosenkränzer |