Skip to content

Software platform content

While software design and development focuses on individual .em files – modules, interfaces, composites, templates – a more coarse-grained construct known as a bundle serves as the unit of software delivery within the EM platform. Like the packages they ultimately contain, each EM bundle bears a globally-unique qualified name suggestive of its publisher and purpose – though individual .em files will only reference packages by name, and never the containing bundle itself.

Representing "components-in-the-large", an EM bundle will not only publicize the elements it provides but will also identify other bundles it requires for successful deployment; de­pendent bundles may in turn require other bundles – reminiscent of the hierarchic import relation between individual .em files. Bundles can also serve as a unit of software versioning within the platform, with dependencies optionally constrained to particular labeled releases.

In the sections that follow, we'll respectively explore these three EM bundles:


hardware-independent packages fundamental to EM


hardware-dependent packages comprising a typical EM distro

hardware-independent example programs which use the prior bundles

Portable content

As its name suggests, the em.core bundle incorporates rudimentary and essential content present in all distributions of the EM software platform – some of which we've already visited earlier in this document. Through aggressive use of the proxy – interface pattern, a critical subset of the em.core bundle – specifically, its em.mcu and em.utils packages – in fact remain 100% portable across all target environments.


This package contains abstract interfaces reflecting the functionality of low-level hardware elements found within embedded MCUs – ConsoleUartI, LedI, WakeupTimerI, and many others; this package contains also contains "empty" implementations of these interfaces (ConsoleUartN, LedN, etc), often used as default proxy bindings. As such, this package serves as a critical hardware abstraction layer (HAL) – prescribing a fundamental architectural boundary that insulates portable (hardware-independent) content from target-specific (hardware-dependent) content.


This package comprises a somewhat eclectic (and ever-expanding) collection of run-time application services – ranging from elementary modules like ListMgr and FiberMgr up to more sophisticated templates like ButtonT and LedT. While mostly supporting program run-time, special host modules like BoardInfo and BoardMeta offer (portable) services used by EM distros at program build-time.


Unlike em.utils, this package generally limits its contents to what we'll term as global proxies – a set of well-known modules that implement certain em.hal interfaces by effectively forwarding function calls to a conformant delegate; ConsoleUart and Poller illustrate this pattern. This package also contains the widely-used Common module, which conveniently aggregates additional global proxies into a single unit.


Invisible to most clients, this package helps bootstrap the implementation of the EM language itself through several distinguished interfaces declaring intrinsic configs and functions:  ModuleI, that all modules or interfaces will inherit; CompositeI, that all composites will inherit; and TemplateI, that all templates will inherit. This package also contains the Console module and its ConsoleProviderI interface – supporting printf statements innate to the language. Finally, this package houses common C/C++ and JavaScript code fragments interpolated during the EM program build-flow.

Using EM will take a more detailed look at the source code of specific .em files found in the first three of these packages.

Target-specific content

Complementing em.core and its portable packages, the ti.cc23xx bundle delivers support for the Texas Instruments CC2340R5 wireless MCU. While specifically targeting a particular MCU family, the organization of the packages found within the ti.cc23xx bundle follows a pattern generally seen within any EM distro.


This package (and in fact the entire ti.cc23xx distro bundle) revolves around a single composite conventionally named BoardC – responsible for configuring parameters as well as binding proxies exposed by elements of em.core. This package also contains two other conventionally named units found in any EM distro:  the McuC composite, which (in this case) focuses on the ti.mcu.cc23xx package; and the special host BoardMeta module, which effectively defines the schema of the board-specific YAML file mentioned earlier in the context of configuration and pre-configuration.


Many of the modules in this package provide MCU-specific implementations of abstract interfaces found in em.halConsoleUart0, Idle, OneShotGpt3, and others. Likewise, this package features templates such as GpioT and InterruptT whose em$generateUnit intrinsics synthesize MCU-specific implementations of other HAL interfaces at program build-time. Finally, this package contains even lower-level auxiliary modules (eg, Regs and Rtc) whose clients typically remain within the distro itself.

This package contains host modules that control the compiling / linking of target EM programs using a particular C/C++ toolchain. The modules typically pass target-specific information such as memory maps or register declarations to generic modules found in a special bundle, which we'll discuss in a later document.

Porting EM will dive into virtually all of the .em source files found in these three packages, as well as explore the bundle mentioned above.

Elementary programs

The  em.examples.basic package within the bundle contains a curated set of programs described at length in Using EM. A live sequence of "guided tours" that view / build / load these programs revolve around the following modules:

 HelloP hello world Tour 00
 BlinkerP basic blinker Tour 01
 BlinkerDbgP real-time debug Tour 02
 FiberP threading with fibers Tour 03
 Button1P button handlers Tour 04
 Button2P button fibers Tour 05
 Button3P button objects Tour 06
 OneShot1P timer handlers Tour 07
 OneShot2P timer fibers Tour 08
 PollerP timer service Tour 09
 Alarm1P wakeup alarms Tour 10
 Alarm2P aligned wakeups Tour 11
 TickerP cyclic tickers Tour 12

To ensure their portability, none of these programs explicitly reference the "current" EM distro package [ ti.distro.cc23xx ] by name; rather, these programs use a special language intrinsic [ em$distro ] as a logical name which you will bind to a particular distro package.

Learning more EM

If you want to learn more about EM – but continue to fly at 10,000' for now – we strongly recommend reading through Using EM to get a sense for the platform's tooling and runtime from a ground-level perspective; a quick pass through the other documents at this site should prove informative as well.

When you want to hit the ground running and start coding, however, you'll definitely need to first work through Installing EM before proceeding onward to Using EM. Both of these documents also accomodate a special ** FAST-TRACK ** option, which enables you to rapidly experience the EM development environment as well as learn more about  em.core.

The Porting EM document continues on the ground, exploring the  ti.cc23xx bundle in greater detail as well as outlining the steps required to create new EM distros that support other MCUs. Over time, we expect Porting EM will draw upon a broader set of distro bundles to further reinforce the EM platform's architecture for encapsulating target-specific content.

Finally, Mastering EM contains an ever-growing collection of standalone articles addressing a wide-range of topics about EM. While many of these articles expect that you've already spent time on the ground coding, others presume just a 10,000' understanding of Using EM.

Case in point:   we strongly recommend the Energy Consumption article, which presents further evidence supporting a hypothesis about EM put forth earlier.

Happy coding !!!   🌝   💻