In general, when programming for embedded environments, resources are relatively constrained. What are the key constraints?

• Financial resources (total design bill of materials (BOM) overhead versus maximum allowable cost per design)
  
• Power resources (embedded systems may need to run on batteries, renewables, or other portable or contrained power supplies)
  
• Processing resources (embedded microcontroller units (MCUs) tend to be fairly basic)
  
• Storage resources (MCU instructions, working memory)
  
• Available physical design space (printed circuit board (PCB) size)

It is the sign of a quality engineering organization that all jobs are specified with clear resource allocations. Lower quality design houses such as the thousands found in Shenzhen (深圳) and the Greater Pearl River Delta (大珠江三角洲地区) will often ignore financial and power efficiency concerns, to their ultimate detriment.

After almost one hundred years of iterative improvement, the brightest engineering minds of the Earth have carefully selected two standard bus types which junior engineers will encounter, the simple physical type and the XBus type.

Successful junior engineers must comprehensively cognitively internalize the capacity to fathom the fundamental facilitation foibles and abstract analytical actionables of these artful all-connectors.

Whilst the ultimate purpose of any bus is generally to link multiple components (generally MCUs or inputs/outputs) together, they also fulfil a critical secondary role in temporal regulation and cross-component synchronization.

Thus, let us first consider the different temporal properties:

• Simple physical: Cycle-oriented, low bandwidth, stable read.
  
• XBus: Sub-cycle-oriented, high bandwidth, destructive read.

Cycle orientation refers to the mode by which electrical signals are distributed across a point-to-point or multi-drop circuit topology on the bus in question. On a simple physical bus, we simply place a signal on a circuit, then wait until the next cycle (for example using the slp instruction on MC*-class MCUs) in order to have that signal propagate to all devices. On an XBus, which is a 'true' bus, we are able to shuffle information in a serial stream very rapidly at a speed of many Hz per cycle.

Bandwidth refers to the volume of information that may be passed per clock-cycle. In a simple physical bus, this is typically limited to a small range of electrical values represented within MCUs as an integer range 0-100. XBus, however, allows the exchange of many KHz (ie. practically unlimited) amounts of information within a single clock cycle.

Read type refers to the permanence of information inbound on the bus in question. On a simple physical bus, we may utilize the inbound value at leisure, as it tends to be stable across an entire clock cycle. For example:
In this example we first perform a general test of the incoming value using a tgt (test greater than) instruction, then move on to a teq (test equals) instruction with greater specificity. Note that the same value for the input will be evaluated by both instructions.

On an XBus, however, each read would be for a different value (tgt would read the first inbound XBus value, and teq would read the second). This is often a source of confusion for junior engineers.

Let us now turn our attentions to reviewing the range of circuit topologies supported by disparate bus types.

• Simple physical: Point to point (asynchronous), multi-write (maximum), safe multi-read.
  
• XBus: Point to point (synchronous), multi-write (synchronous), destructive read.

The astute reader will immediately notice that both of the popular bus types offer both point-to-point and multi-drop topology support. However, their properties differ. Let's take a look at the synchronicity of point to point topologies first.

In short, on a simple physical bus, there is no need to ensure that connected components read or write to that bus at all. This means that a given microcontroller unit (MCU) can blindly write to or read from the bus at arbitrary frequencies (many Hz per clock-cycle, occasionally, and in a varying frequency per clock-cycle based upon its internal program objectives). However, on an Xbus it is critical to ensure that each components reading or writing on the bus is doing so at precisely the same frequency as other components, or the MCU will crash while blocking, waiting for the remote side of its synchronous input/output.

Now let us turn our attentions to multi-write paradigms. On a simple physical bus, the multi-write paradigm can be described as maximum. What does this mean? Simply that signals sent by multiple writers on a shared bus will be effectively increased to the highest signal. For example, if one MCU writes a value of 25% signal strength to a shared simple physical bus, a second MCU writes 35% signal strength, and a third or fourth MCU on that shared bus reads the value, both will read a value of 35% signal strength. This demonstrates both the maximum write property and the safe multi-read property. Astute (厉害) engineers will immediately consider the architectural opportunities and optimization potential thus provided by the shared multi-write asynchronous bus paradigm. XBus, by contrast, does allow multiple writers however the remote reader cannot be addressed natively within the XBus protocol and is simply the first MCU to issue a read instruction against the bus. Hence the destructive read property. Together these factors mean that complex multi-drop XBus topologies can be irritating to develop, relying heavily upon perfect synchronicity between multiple MCU's program code, leading to the popular modern Mandarin aphorism "XB就是SB" ('XBus is a ♥♥♥♥♥♥♥♥♥♥♥♥♥♥').

Finally, we should note that there are effectively two types of devices that connect to simple physical buses: those for whom off and on (0 or 100) are the meaningful signals (such as buttons or switches), and those for whom temporal signal strength is significant (such as LED lights). Note also that certain topologies (for example XBus-controlled simple physical bus breakout units) permit only interfacing with the former, and not the latter.

In conclusion, simple physical buses provide a greater engineering flexibility than XBuses with regard to circuit-wide MCU scheduling, however they do so at the cost of reduced per-cycle bandwidth and the loss of architectural options for intra-cycle multi-MCU instruction synchronization. Engineers of a professional caliber will quickly master both buses and their associated architectural paradigms.

Here we shall recap the various approaches that one may take to data storage within the embedded environment.

• MCU instructions (hard-coded)
  
• MCU registers (real time)
  
• MCU control flow branching (real time)
  
• ROM (hard-coded)
  
• RAM (real-time)
  
• Simple physical bus status (real-time)

MCU instructions are the instructions burned in to MCUs before production. These represent one form of data storage.

MCU registers are the small, processor-linked real time memory locations in which small values may be stored.

MCU control flow branching refers to the state of a given MCU's control flow (sometimes known on more complex architectures as the location of the instruction pointer). This potentially provides a bit of extra functional memory in particularly resource-constrained scenarios, at the cost of control flow instructions.

ROM or read only memory is external hardware that allows data to be burned prior to production, then read rapidly, generally via XBus. Due to its high cost and bad habit forming potential, it is typically not provided to beginning junior engineers.

RAM or random access memory is external hardware that allows data to be burned both prior to production and in real time, then read rapidly, generally via XBus. Due to its high cost and bad habit forming potential, it is typically not provided to beginning junior engineers.

Simple physical bus status functions as memory. See also the notes on the maximum multi-write paradigm in the previous chapter.

In addition to these basic memory types, we should also review some common routes for optimization. Even the most basic MCUs offer some valuable instructions such as dgt and dst which effectively allow the storage of up to three disparate values within a single register.

At a high level, all engineers should know that power is used by active microprocessor units (MCUs). Reducing power consumption in a microprocessor-based embedded system is generally a matter of reducing the number of instructions executed by the MCUs. The key commands here are slp and slx.

The power optimizing engineer often asks themself: "Is there an initial or predictable period of inactivity in the validation path during which the MCU could be sleeping?"

In addition, converting slp-based MCU control loops (multiple instructions executing every cycle) in to slx-based loops (XBus-synchronized, occasional execution with the capacity to skip cycles entirely) often offers substantial opportunties for power savings.