A Tiny Cloud

Infrastructure as a Service, for when you need infrastructure made of the ittiest bittiest computers.

Q: What's an embedded engineer living near the metal supposed to do in this world overcome with ache for life in the clouds? A: Yank those clouds down to the metal.

The Goal: serve some web content from a load-balanced cloud of networked ATtiny10 microcontrollers.

The Plan:

  1. Make a device that can program and communicate with an array of ATtiny10s via USB
  2. Use the TUN/TAP driver in Linux to create a network interface for each ATtiny10. Behind the scenes data is shuffled over USB and then over serial to and from the microcontrollers.
  3. Set up NGINX to load-balance requests from the WWW across the microcontrollers.
  4. Write a web server and then a blog engine in AVR assembly.
  5. Uh...
  6. Profit?

Hardware Design

To make our tiny cloud we need two basic things from the hardware:

  1. A way to tell the infrastructure how to do a thing
  2. A way to give the infrastructure things to do it with

Said another way, we need to be able to:

  1. Flash programs to the ATtiny microcontrollers
  2. Communicate with those programs once they are running

To gain these abilities I'm using an ATmega32U4, which is a microcontroller that has a USB interface and a good number of pins. But not quite a good enough number of pins, so I've thrown in two shift registers as well.

There are 16 ATtiny10 microcontrollers to a board. During programming the shift registers are used to hold a particular one of them in reset while the same two data and clock pins that are connected to all of the ATtinys are wiggled just so - as dictated by the Tiny Programming Interface specification - in order to flash that particular chip. All those not in reset will ignore the wiggles, so we can walk through the entire array by holding each one in reset in turn. This is kind of slow, but we're not planning on reflashing them all the time so we'll live with it.

Once the ATtinys are flashed we'll start shuffling serial data to and from them via ports B and D on the 32U4 (one half of the array per port so it takes 2 assembly instructions to grab the state). The 32U4 will accept packets over the USB bus that contain the index of an ATtiny and some data to send to it, and in reverse it will export packets distilled from the tortured screams of the ATtinys.

PCB Design

Software Design

Projected to ship next quarter...

Share this article: Link copied to clipboard!

You might also like...

Wireless Gateways for a Metacortex with Wireguard

Containerizing ROS Melodic with LXD on Ubuntu 18.04

Beta Processor Extensions