Conveners
Embedded & Internet of Things MC
- Stefan Schmidt
- Jan Lรผbbe (Pengutronix)
Description
The Embedded and IoT Micro-conference is a forum for developers to discuss all things Embedded and IoT. Topics include tools, telemetry, device drivers, protocols and standards in not only the Linux kernel but also Real-Time Operating Systems.
Current Problems that require attention (stakeholders):
- Boot time optimizations (Tim Bird, Khasim Syed Mohammed)
- Kernel size and memory requirement optimizations
- CAN subsystem (Marc Kleine-Budde, Oleksij Rempel)
- Linux-wpan subsystem (Stefan Schmidt, Miquel Raynal, Alexander Aring)
- Sync device tree description of hardware between U-Boot, Linux and Zephyr (Nishanth Menon)
- Generic MCU communication driver (Schuyler Patton)
- Any other topics embedded and IoT
We hope you will join us either in-person or remote for what is shaping up to be another great event full of collaboration, discussion, and interesting perspectives.
This talk will cover some of the boot time optimizations that we've found to be helpful on Android systems that should apply equally well to embedded systems. Most of these guidelines have been launched in a public product and have been shown to work well.
Zephyr RTOS offers a rich ecosystem, but embedded engineers often face the challenge of porting code across environmentsโfrom Zephyr to another RTOS or even to bare metal. This discussion is about a practical guide to extracting a โbare metal flavorโ of code out of Zephyr so that it can run independently of Zephyrโs driver and subsystem layers.
NOTE: The HAL approach isn't the right...
In this session we will discuss how to improve system stability of boards using fusb302 (or similar) chips for their USB-C port without any backup power source. This kind of setup is often found on Rockchip boards (e.g. Libre Computer ROC-RK3399-PC, Radxa ROCK 5B or ArmSoM Sige 5) and quite a pain, because a hard-reset effectively kills the board power.
The session starts with a short...
The Common Clk Framework (CCF) is expected to keep a clockโs rate stable after setting a new rate with "clk_set_rate(clk, NEW_RATE)". However, several longstanding issues affect how rate changes propagate through the clock tree when CLK_SET_RATE_PARENT is involved.
Current behavior allows a child clock to change its parentโs rate to satisfy its own request, but this adjustment happens...