Panel

Live Q&A & Panel Discussion - Software Architecture Track

Watch Now

46:58

EOC 2025

Panel

Live Q&A & Panel Discussion - Software Architecture Track

46:58 EOC 2025

Live Q&A & Panel Discussion - Software Architecture Track

46:58

Live Q&A and Panel Discussion with speakers presenting in the Software Architecture track.

1 / 4

Please log in or create an account to test your knowledge and see the answers.

According to the panel, what is the single biggest practical challenge that causes otherwise-good embedded software architectures to fail over time?

A Architectures decay because teams lack the discipline and maintenance to keep them healthy.

B Hardware constraints (insufficient RAM/flash) prevent any reasonable architecture from being implemented.

C There are too many programming languages and no consensus on which to use.

D Regulatory and compliance requirements make maintaining architecture impossible.

E A lack of debugging tools and IDE support is the main reason architectures fail.

What did the panel recommend as the main reason a team should consider using Zephyr for an embedded product?

A When you need a fully integrated IoT stack (Bluetooth/Wi‑Fi) on a specific chip and can't offload connectivity to something like an ESP32.

B Because Zephyr is optimized for tiny 8-bit microcontrollers with only a few bytes of RAM.

C Because using Zephyr forces you to publish your proprietary application source code.

D Because Zephyr is always simpler and less complex than using a thin RTOS like FreeRTOS.

E Because Zephyr eliminates the need to adapt architectures when moving from small to large systems.

For extremely constrained targets (example: ~1KB flash, ~64B RAM), which approach did the panel recommend as practical and appropriate?

A Use lightweight abstractions (Ports & Adapters), keep data in flash where possible, and use techniques like link-time polymorphism to avoid RAM-heavy runtime polymorphism.

B Re-architect the system as microservices so you can independently scale each service on the MCU.

C Rely on dynamic polymorphism with virtual tables and heavy runtime allocation to maximize reuse.

D Avoid abstraction entirely and accept a large, unstructured 'ball of mud' because constraints forbid clean design.

E Always port Zephyr or a full RTOS onto the 1KB/64B device to get modern architecture features.

What did Adam report about the memory cost of code-generated state machines (e.g., from StateSmith) on small embedded targets?

A Generated state-machine code can be very memory-efficient; in one case a generated state machine needed only a single byte of RAM.

B Generated state machines always bloat RAM and are unsuitable for 8-bit targets.

C Code generation requires dynamic heap allocation and therefore cannot be used on static-memory MCUs.

D You must hand-code every state machine to get minimal memory usage on small MCUs.

E Generated state machines force use of C++ virtual tables and thus cost dozens of bytes per instance.

Formatting help

italics	surround text with asterisks
bold	surround text with two asterisks
hyperlink	[hyperlink](https://example.com) or just a bare URL
code	surround text with `backticks`
~~strikethrough~~	surround text with ~~two tilde characters~~
quote	prefix with >

Upvotes Newest Oldest

No comments or questions yet. Be the first to start the conversation!

Partners & Sponsors

CodeSecure

atym

embedd.it

IAR

Become a Sponsor