What is Anachro?

Anachro is two things: A Network Protocol, and a PC architecture for a microcontroller-based system.

Name

The name "Anachro" comes from the word "Anachronism", as Anachro was originally designed as a sort of "future-retro" PC. It takes inspiration from the Retrocomputing and the Demoscene, but is instead focused on building systems of modern and available microcontroller components, rather than classical computers.

Provenance

The Anachro-PC was first described in a blog post by James Munns, which described some of the original ideas, including the physical network topology used by Anachro PC, and parts of the Anachro Network Protocol.

The Anachro Protocol and first Anachro PC were showcased at RustLab 2020, on Oct. 14th, 2020.

Get Started

Anachro is still in early preview! The best way to get started is to:

• Check out the GitHub Repo
• Join our Matrix Chat

The Anachro Protocol

The Anachro Network Protocol is a low complexity, frame oriented, transport agnostic messaging protocol that is designed to be usable over a variety of different physical layers, including SPI, UART, TCP, or wireless packet radios.

It is split into seven layers, allowing for re-use of higher layers when replacing the physical transport, or porting the Anachro protocol to new types of hardware. A longer discussion of the Network Protocol can be found in the Network Chapter.

The Anachro Protocol exposes four different "planes" of communication, each with differing reliablity and usage profiles. These planes include a "Control" plane, a "Pub/Sub" plane, an "Object Store" plane, and a "Mailbox" plane. More information about the planes can be found in the Network Chapter.

The Anachro PC

The Anachro-PC Architecture is an extensible PC architecture intended to be composed of multiple individual microcontrollers. It is designed to be a teaching and hobbyist grade PC architecture, with a performance goal of approximating the capabilities of mid to late 1980's PCs such as the IBM PC XT.

Communication is managed by a single Arbitrator, which coordinates communication with standalone Cards, which each perform one dedicated PC function, such as the Main CPU, Keyboard Controller, Display Interface, Modem/Ethernet Interfaces, etc.

The Arbitrator in the Anachro PC Architecture fulfills approximately the role of the Northbridge in modern x86/x86_64 PCs. It is also responsible for managing the main system memory.

The Anachro-PC Arbitrator and all cards communicate using the Anachro Network Protocol, used as a replacement for the use of PCI-E or dedicated Memory interfaces used in current day PCs. Cards are typically connected to the Arbitrator through the use of a hardware backplane, or direct wired connections.

A list of Anachro PC implementations can be found in the Anachro PCs Chapter.

Glossary and Concepts

This section introduces terms and concepts specific to Anachro.

Arbitrator

The arbitrator is responsible for acting as the central connection for all cards.

In the Anachro protocol, the Arbitrator serves as a local server, providing pub/sub capabilities, card-to-card communication, and discovery of other cards.

On Anachro-PCs, the arbitrator serves a similar role to the Northbridge in desktop PCs: managing access to shared resources such as system memory and communication busses.

The Arbitrator also may serve as a connection adapter between different data link protocols, such as SPI, UART, TCP, or ESB.

Card

Cards are the "end devices" on an anachro network. These devices connect to the Arbitrator, and communicate through other cards through the arbitrator.

In an Anachro PC, all components act as a Card, including the main CPU, storage interfaces, network interfaces, and video adapters.

Interface Control Document

Crates that contain message types that are used "over the wire". These crates are typically shared between many different devices.

ICD crates are typically #[no_std] to maintain compatibility with embedded devices, and often depend only on serde for the Deserialize and Serialize traits.

Network Protocol

Planes

The Anachro Protocol exposes four different "planes" of communication, each with differing reliablity and usage profiles.

You can read more about Planes in the Planes Sub Section

Layers

The Anachro Protocol is implemented across seven distinct layers, separated to make it easier to port the Anachro Protocol to new transports and physical hardware.

You can read more about layers in the Layers Sub Section

Network Planes

The Anachro Protocol exposes four different "planes" of communication, each with differing reliablity and usage profiles. These planes include:

1. The Control Plane
   • This plane is required to be implemented by all Anachro devices.
   • This plane is used for establishing connections, and configuration of devices over the network.
   • This plane has acknowledged messages and sequence numbers for improved reliability.
2. The Pub/Sub Plane
   • This plane is optional for Anachro devices to implement.
   • This plane is used for periodic sending of messages, such as sensor readings
   • This plane has no acknowledgement or sequencing of messages, and should be considered (relatively) unreliable compared to other layers.
   • This plane is loosely inspired by MQTT-SN with a QoS level of 0.
3. The Object Store Plane
   • This plane is optional for Anachro devices to implement.
   • This plane is for bulk message sending and storing for devices on the Anachro Network
   • This plane has acknowledgement of messages for improved reliability
   • This plane is loosely inspired by Redis or S3 when used as network caches
   • Note: As of 2020-10-10, this plane has not yet been implemented.
4. The Mailbox Plane
   • This plane is optional for Anachro devices to implement.
   • This plane is for sending small one-shot messages with guaranteed delivery between devices.
   • This plane has acknowledgement of reception and Ack/Nak of whether the message was placed in the mailbox of the other device (or if the mailbox was full)
   • This plane is typically coupled with the Object Store Plane to send references to bulk messages stored in the Object Store Plane.
   • Note: As of 2020-10-10, this plane has not yet been implemented.

Network Layers

The Anachro Protocol is implemented across seven distinct layers, separated to make it easier to port the Anachro Protocol to new transports and physical hardware. These layers include (in descending order):

• The Application Layer
  • The Application Layer is intended to be the individual "business logic" responsibilities for each card.
  • A given card may have one or more "applications", that describe a single responsibility
  • This layer is only relevant to Cards, as routing of messages is transparent to the Arbitrator.
  • This layer is implemented by each Card.
• The Routing Layer
  • The Routing Layer is intended to manage the distribution of messages received from the Arbitrator to individual components of a Card's Application.
  • This could include handling of messages from different planes (e.g. Pub/Sub, Object Store, etc.), or messages from within a given plane (e.g. different pub/sub topics on the Pub/Sub plane).
  • This layer is only relevant to Cards, as routing of messages is transparent to the Arbitrator.
  • This layer is implemented by each Card, with components provided by the Anachro Card/Client library.
• The Protocol Layer
  • The Protocol Layer is intended to manage the connection between an Arbitrator and a Card.
  • The Protocol Layer is implemented as a Struct that can be paired with one or more implementors of The Protocol Interface
  • Cards will typically have a single Protocol Layer, used to communicate with the Arbitrator
  • The Arbitrator may have one or more Protocol Layers it supports, depending on the connection topology to the Cards it will connect to.
• The Protocol Interface
  • The Protocol Interface is a connection between the Protocol Layer and the Data Link Layer
  • The Protocol Interface is implemented as a minimally specific Trait, which allows multiple Data Link Layer implementations to be used interchangeably with a single Protocol Layer.
  • This layer is generally a simple "Send Frame" or "Receive Frame" interface.
  • This layer is defined within the Anachro Protocol, and is not typically re-implemented by end users.
• The Data Link Layer
  • The Data Link Layer is intended to handle any Anachro-specific usages of a given Physical Layer, such as Anachro's use of a "GO" signal and shared-peripheral orientation over an SPI link.
  • In some cases, dedicated Data Link, Data Link Interface, and Physical layers may not be necessary when using a straightforward line protocol, such as "COBS framed bidirectional UART".
  • This layer is typically implemented as a struct that contains a generic Physical Layer struct, which implements the associated Data Link Interface trait.
  • This layer typically implements the Protocol Interface Layer trait.
  • This layer is typically either provided as part of the Anachro Protocol (for already implemented physical transports), or to be implemented by end-users when porting to a new physical transport or hardware platform.
• The Data Link Interface
  • The Data Link Interface is a connection between the Data Link Layer and the Physical Layer
  • The Data Link Interface is typically implemented as a minimally specific Trait, which allows multiple Physical Layer implementations to be used interchangeably with a single Data Link Layer.
  • This layer is analogous to interfaces like embedded-hal's SPI, UART, or I2C traits.
  • This layer is typically either provided as part of the Anachro Protocol (for already implemented physical transports), or to be implemented by end-users when porting to a new physical transport or hardware platform.
• The Physical Layer
  • The physical layer is intended to handle the interactions between the Anachro network stack and specific microcontroller peripherals, such as SPI, UART, etc.
  • The physical layer is typically implemented as a struct that contains the hardware specific peripheral and associated logic
  • This layer is typically either provided as part of the Anachro Protocol (for already implemented physical transports), or to be implemented by end-users when porting to a new physical transport or hardware platform.
  • This layer typically implements the Data Link Interface trait.

Anachro PCs

This section is intended to showcase Anachro PC instances.

At the moment, there is only one physical Anachro-PC, the Anachro Stargazer

Stargazer

The Anachro Stargazer was the first Anachro-PC, designed to be demonstrated at RustLab 2020.

It was built out of an RC2014 Z80 Backplane and Proto board kit, as well as with hardware modules from Adafruit, MakerDiary, and a Raspberry Pi.

It featured:

• An Arbitrator
• A backplane
• A CPU
• A Keyboard
• An HDMI display interface

The "Stargazer" name comes from the Stargazer Lily.

Backplane

The Stargazer Backplane was an 8 socket RC2014 backplane module, originally inteded for Z80 based PCs.

It features 40 parallel pin connections for the 8 card slots.

The Stargazer Backplane also featured a USB-PD compatible USB-C module to provide up 5V/3A for use by the attached cards.

Pinout

The following pinout was used for the Stargazer Backplane:

Feather Template

The following google sheet was used to roughly design the Cards for the Anachro Stargazer.

CPU

The first Stargazer CPU module was based on an Adafruit nRF52840 Express. It included a TI SN74AC245N to gate access to the shared SPI bus based on the "GO" signal as an output enable line.

It was built on top of an RC2014 Prototype card.

Note that Pin 1 was actually ABOVE the card, as the Prototype card only had 39 pins.

For a list of signal lines, please see the Backplane Page.

Arbitrator

The first Stargazer Arbitrator module was based on an Adafruit nRF52840 Express. It required no additional components.

It was built on top of an RC2014 Prototype card.

Note that Pin 1 was actually ABOVE the card, as the Prototype card only had 39 pins.

For a list of signal lines, please see the Backplane Page.

Original Design

Keyboard

The Keyboard for the Anachro Stargazer was a MakerDiary M60. It contains a Nordic nRF52840. It was connected to the PC via the Debug Card, using the programming/serial port header available on the M60.

Display Adapter

The Stargazer Display Adapter was a Raspberry Pi Zero W, connected to an RC2014 Console Module.

It also had an FTDI breakout header for connecting the serial lines to an external device.

Currently, only the following signals are connected:

• GND
• +5v
• Reset
• SERIAL1-TX
• SERIAL1-RX

For a list of signal lines, please see the Backplane Page.

Note that the Console Module card does not connect Pins 39 and 40.

Debug Card

The first Stargazer Debug Card was intended to break out the SWD lines (Clock, Data In/Out, Ground, and Reset) for each card. It also provided a connector for the Keyboard to connect to the Arbitrator via UART.

It was built on top of an RC2014 Prototype card.

Note that Pin 1 was actually ABOVE the card, as the Prototype card only had 39 pins.

For a list of signal lines, please see the Backplane Page.

Pinout

The following pinout was used for each of the debug headers. This is from Left to Right.

The headers were connected in the following order, Top to Bottom:

• Card 1 SWD
• Card 2 SWD
• Card 3 SWD
• Card 4 SWD
• Card 5 SWD
• Card 6 SWD
• Card 7/Keyboard SWD (common)
• Arbitrator SWD

Below all SWD headers, is a Keyboard Header. This pinout matches the headers on the MakerDiary M60. These pins are numbered from Left to Right