I’ve been working through a lot of questions around the Bedrock hardware projects this week, stealing away scraps of time between studying for and sitting exams. I’m about halfway through exams now, which gives me a bit of breathing room to work more on this stuff.
→ Click here if you've paid ←
Just a quick note to start, I rejigged the names of the planned hardware projects from last week to make more sense going forwards. The projects are:
bedrock-micro, a piece of circuit board holding the smallest usable Bedrock computer.bedrock-card, a credit-card sized pocket computer with a screen and battery.bedrock-pocket, a multitasking computer workstation in the guise of a 90’s era kid’s handheld.
Hardware projects
I’m digging into bedrock-micro to start because I want to have a working production system by April next year to enter into the entrepreneurship competition, and I won’t have much time during second semester or over summer. Once bedrock-micro is locked down, I’ll be able to move onto card and then pocket, the more ambitious projects of the set.
Minimum usable product
I’ve got a short list of requirements for bedrock-micro: it has to be cheap, useful, interesting, and durable.
- Cheap
I want it to cost no more than NZD$20 to manufacture, though ideally no more than NZD$10 if I can help it. I want this computer to be affordable even after adding in the cost of labour to assemble it. - Useful
It has to be fast enough and capable enough to do useful work, so it needs a full compliment of program memory and enough devices to be useful. I’m imagining someone connecting a hacked-up screen and keyboard and using it to work with spreadsheets. - Interesting
It needs to look the part, to pique people’s curiosities. When someone sees it for the first time, I want them to think ‘that looks like it probably does something cool, I want to figure out how to use it’. It needs a way of displaying output without having to connect any external devices. - Durable
This circuit needs to embody the same principles as Bedrock. It needs to be easy for other people to make more of them, or to repair, or to hack and modify and extend.
More than anything, I need to not get carried away with myself when designing this thing. bedrock-micro needs to be a minimum usable product, it needs to do enough and no more because the more will be covered by future projects. But what does it mean to be minimum and usable? Where do we draw the line? This is what I’m having a hard time answering.
It’s the same balance that I spent so long striking with Bedrock itself. What does it mean for a system to be enough? On one end of the spectrum is the lambda calculus (easy to implement, difficult to use), and at the other end is, say, JavaScript (easy to use, difficult to implement). These qualities compete with one another, each step that you make towards easy to use is a step away from easy to implement. If the system isn’t usable then no one will want to use it, and if the system isn’t implementable then no one will be able to use it.
Let’s walk up our hierarchy of options and try to figure out where we should stop. How do we identify the step that represents enough?
Cheap
The cheapest possible system uses an 8-pin PIC12F1572 microcontroller (NZD$1.53) as the central processor, an 8-pin MCP23LC512 64KB memory chip (NZD$3.83), a square of printed circuit board (roughly NZD$0.90), some header pins or a connector for the 6-pin device bus, and a handful of decoupling capacitors. A 3.3V power source is kindly provided by the user. The total cost comes to around NZD$6.50.
This is truly the cheapest possible Bedrock computer, but it’s a bit of a cheat, the lambda calculus of computer environments. The system is deaf and blind to the world, it relies on the user having to implement and connect up a file or stream device in order for the bootloader to even be able to load a program into the program memory. You could think of the system as being the Bedrock equivalent of a microcontroller, requiring additional hardware in order to turn it into something useful.
Useful
Let’s make this useful as a standalone system. We’ll add a microSD card slot (NZD$1.53) so that the user can plug a card full of programs and files directly into the system, and a new PIC16F1575 microcontroller (NZD$2.51) as a coprocessor to translate the SD card protocol and on-card file system into the Bedrock file device interface. This brings the total cost up to around NZD $10.50.
The new microcontroller is required because the central processor only has 256 bytes of memory, and every byte is already required by the core processor architecture (120 bytes per stack and 16 bytes for the working memory). The new microcontroller has 1024 bytes of memory, which should be enough for all of the buffers and file paths that need to be tracked.
This system should be borderline usable now, we can copy a program to the card and the bootloader can load it into program memory. We’re still limited to batch programming jobs though, there’s no way for a program to receive input or return output outside of reading and writing to the file system or connecting some external devices.
Interesting
There are a few different avenues that we could take to make the system interesting. A screen immediately jumps to mind, but it’d probably blow out the price and it wouldn’t be so useful with the system being based around a raw circuit board. A better idea would be to lean into the circuit form factor and add a couple of rows of GPIO pins to the system, allowing the system to interface with any random collection of buttons and dials and motors and lights. Eight additional pins can connect internally to a row of eight LEDs on the board itself, providing programs with an immediate built-in way to communicate with the user. An easy demo would be flash each light in sequence, ‘ping ponging’ up and down the row.
What does this cost? We’ll need to upgrade our central processor from the 8-pin PIC12F1572 to the 14-pin PIC16F1575, the same microcontroller that we’re currently using for the file device (increasing the cost by NZD$0.98). This gives us a few more pins to work with for a cheaper price than if we’d added a third microcontroller to the mix, and gives us the opportunity to create a more efficient processor implementation at the same time. We don’t have nearly enough pins for the full compliment of 32 IO pins though, so we’ll also need four 74HC595 8-bit parallel-out latching shift registers for setting output states, three 74HC165 8-bit parallel-in shift registers for reading input states, 24 header pins, and then eight surface-mount red LEDs with matching surface-mount resistors. The prices for these are a lot harder to determine, I’ll want to buy them from some bottom-of-the-barrel bargain-bin retailer instead of the premium versions from element14. We’ll split the difference and say NZD$3.00 to be sure, bringing us up to NZD$14.50.
Durable
Lastly, we want to build this thing to last, which means that it will need to be protected from power issues and to be able to support a selection of different power sources. The SD card needs a steady 3.3V power supply, with any deviance or dirt having the potential for data corruption issues (or just straight-up zorching the whole rig).
Let’s add an MCP1252-33X50 voltage regulator to the mix (NZD$3.76), three supporting capacitors (around NZD$2.00 maybe), and a tiny power switch. This gives us an input voltage range of 2.0V to 5.5V and allows us to use everything from coin batteries to direct 5V USB power, meaning that we can pick up a loose board, slot in an SD card, flick a switch, and see our bouncing LED pattern in our hands.
For those keeping count at home, we’re now up at around NZD$20.25 in parts without pricing in labour. Things aren’t looking so crash hot for our cost goals.
The money and the bag
There might be some scope for shaving down the price of a component here or there, but we can’t really remove components wholesale, each one has been carefully justified and fought for. If I want to make a case for this thing being educational, I don’t think I can get away with less. But I think there’s a compelling way to cheat the system. Not every use case is going to require the GPIO pins or the voltage regulator, or even the SD card. What if the board design is modular?
I’m imagining a board with spaces for every component, but where not every space has to be populated with components. Have pads for the SD card holder, file device coprocessor, the voltage regulator, shift registers, battery holder, header pins, and even the 14-pin central processor can be swapped out for the basic 8-pin version with the same board layout. Bedrock is an inherently modular system, it won’t even blink if the entire file management subsystem just burns to the ground one day, it’ll keep ticking along the best it can. People who don’t need a robust power supply can save NZD$6.00, people who don’t need GPIO pins can save NZD$4.00, and suddenly you’ve got a system for only $10.50, but using only a single shared board layout.
I dunno, it feels like a decent solution. I’m not sure how useful it’ll be in practice, but it might give some flexibility.
Thanks
Alright, I’ve gotta head to bed so that I can do good studying tomorrow. Thanks for supporting my work, the motivation to write is really helpful. Until next time!