build log #4 • hardware requirements, data flow
This week, we dive into the kinds of chips we need for a device that turns your old electronics into your own little cloud.
data
Let’s think through the structure of the printed circuit board (PCB) that will act as the physical core of little cloud. We likely need an array of USB ports through which diverse worker devices will be recruited into a unified cluster. USB is very versatile, as it can support internet tethering, storage media, debug shells, keyboard input, video output, and many others. To decouple hardware requirements from the exact software methods we’ll end up using for handling various classes of worker devices, we can keep our options open and simply mandate that every port should be able to present itself as anything the USB standard supports.
USB is an asymmetric protocol that requires an explicit host and device. Most laptops, and virtually all desktops and servers, are hard-coded to only act as hosts. Old smartphones and tablets are hard-coded to only act as devices, while modern versions can act as both. The chips behind standard USB hubs are typically hard-coded to connect many USB devices to one USB host. This means we can’t really get away with just using one hub chip to back all our ports, because then little cloud wouldn’t be able to easily connect to many laptops, desktops, and servers over USB.
What we could do is have one cheap “dual-role data” microcontroller (MCU) per port, whose role would only be to present itself as anything that’s needed and act as a simple bridge to some beefier integrated circuit (IC) that manages them all. Typical USB connections span “full speed” (12 Mbps), “high speed” (480 Mbps), and “super speed” (5 Gbps). The upstream link from the port MCU to its beefier manager might be SPI (1 to 100 Mbps), on-board Ethernet (100 or 1000 Mbps), or actually one of the same USB variants above. I think we could go for high speed on the port and SPI on the manager link initially.
That said, I did manage to find a very narrow niche of MCUs that manage to pack insanely many USB buses on the same chip. WCH’s CH645 for instance, whose product page isn’t even available in English at the moment, boasts 8 independent buses, 4 of which can effectively be dual-role data, with the other 4 host-only. Their sales team quoted me a price just below 2$ when asked for 1K volume. With a niche MCU like this, we’d get extreme design consolidation and cost reduction, at the cost of a more brittle supply chain. Would it be worth it? Not sure, we might regret going for this if supply suddenly becomes unavailable. But only needing one dirt-cheap MCU per product instead of one per port is appealing for sure.
power
Not only is USB versatile in terms of what kind of data is being transferred, but it is also versatile in terms of what power it can carry. Older USB can do 5V@0.5A (2.5W) all the way to 5V@1.5A (7.5W). On a Type-C connector with a proper power delivery (PD) controller behind it, two devices can negotiate dynamically up to 20V@3A (60W), and even higher if the cable itself is marked electronically.
In addition, modern USB can flip power direction relative to data roles, such that the device can power the host. It can also negotiate an emergency contract where power flips if the wall-plugged device loses its power while a battery-enabled one carries on. As with data, let’s reduce coupling between hardware and software constraints and push for ports that are able to simply do whatever is needed when it comes to power.
However, we can cut a corner here and limit ourselves to 5V only across ports. This is partly to avoid having to add DC-DC converters and further support circuitry on each separate port that would’ve allowed it to independently climb up to 20V. After all, we need to charge phones and tablets as slowly as possible anyway, in order to avoid heat buildup and maintain battery life. We need to be able to dynamically charge them a bit faster than they drain, though, so hard-coding 5V@0.5A wouldn’t cut it. The 5V simplification largely does lock us out of being able to power laptops through vendor-specific adapters, though I think the vast majority of people just use the original power-brick cables. We’re not touching AC in this version, so anything other than a phone or tablet needs to separately plug into its own power outlet.
manager
The manager chip needs to be a bit beefier than the port-facing MCU(s). One option is to go with a tiny Linux-capable microprocessor (MPU) with co-packaged RAM to avoid having to route (and buy) dedicated RAM chips. Allwinner MPUs seem decent at around 4$ at 1K volume via Chinese distributor LCSC, depending on the exact model. They have 64-256 MB of RAM, >1GHz processing, and all kinds of handy peripherals. Our bill of materials (BOM) could swallow ~4$ given it’d be a single MPU per board. Compare that to per-port MCUs that plummet under ~1$ really fast at higher volumes.
We could also just go with a beefier MCU for the manager. There are ecosystems like Zephyr OS, backed by the Linux Foundation, which provide mature networking stacks and other handy utilities designed to fit in the KBs of RAM of an MCU. Going for an MCU brain would also consolidate the software toolchain, and might constantly force the removal of non-essential features to keep things lean. I’m not sure if it’d be beefy enough to orchestrate and network the worker devices, though. Plus I think targeting an MCU with an Yggdrasil build would be extremely difficult, even though WireGuard has been ported to MCUs successfully as another VPN technology.
auxiliary
Besides the port MCUs and the manager MPU, the top signal layer will likely need to be populated with a few other things as well. A few gigabytes of persistent storage in some flash chip would be handy for storing prebuilt images or binaries for pushing on worker devices during recruitment. We’d also have the miniPCIe slot gated by a pin multiplexer for accommodating future long-range radio, as foreshadowed in earlier updates. We could also throw in an RJ45 port, integrated into a MagJack to avoid worrying about magnetics ourselves, as an internet uplink for when we lack worker devices equiped with radios of their own, such as some desktops and most servers.
We also need some components to handle the incoming power responsible for little cloud’s own chips, as well as for any phone and tablet workers it powers. We settled on having laptops, desktops, and servers get their own power separately, though maybe we could at least integrate some hidden tray for storing the laptop power-bricks. Little cloud should be able to negotiate as much power as it needs via PD from its upstream USB-C power supply, such that it can charge phones and tablets a hair faster than they drain. It can locally negotiate above 5V, but we should clean that up and convert it to 5V as soon as possible.
stackup
It might drastically simplify routing to then dedicate an entire internal PCB layer to our unified 5V, turning it into our power plane. Then, from anywhere on the top signal layer, we can use several vias and a copper pour to tap into 5V directly. Similarly, a ground plane would also be pretty handy for routing, and also useful for shielding during certification tests. We mainly get the bottom signal layer for crossing below other intersecting traces, maybe also with some extra writing on that bottom silkscreen. We’d try to use co-packaged RAM and avoid ultra-dense footprints in order to get away with just two signal layers and simpler signal routing. This gets us better hand-solderability and repairability as a bonus.
That would leave us with four PCB layers in total. Even if a bit more expensive than bare 2-layer boards, I think it’d vastly simplify the design, especially given the non-trivial currents we’d be moving around. These would have otherwise required chunky traces all over the place if it weren’t for a dedicated power plane. Plugging some numbers into JLCPCB’s online price calculator, we find that a 45 x 5 cm 4-layer board with default settings is around 2.5$ at 1K volume, compared to 1.7$ for a 2-layer one. I’ll take the easier power routing, especially given the MCUs and MPU would probably be at least 10$ together.
