What is this?

I've been studying from Contextual Electronics, and had a silly idea on the back of one of their "make a blinky" tutorials. Wouldn't it be cool to have Morse blinkies? (Not really.) And wouldn't it be cool to generate them programmatically on demand? (Er. No.)

So, we've had PaaS (Platform as a Service), IaaS (Infrastructure as a Service), SaaS (Software as a Server). But is the world ready for Morse Blinkies as a Service? (MBaaS, obviously.)

Enough talk already. I want my blinky!

Enter some text on the front page, pick some options, press the big blue button and in a few seconds you'll get a link to a ZIP file containing KiCad files that implement a Morse blinky blinking out your text.

Here, "KiCad files" means a netlist, some footprint libraries (to keep everything nicely self-contained) and a README telling you what to do with it all. You'll need to do the PCB layout for your blinky yourself: that's the artistic part!

What's in my blinky?

There's a 555 timer (of course), one or more LEDs with current-limiting resistors, and in between there's some 74xx-based logic to decide when to switch the LEDs on and off.

The logic is just some counters and some AND and OR gates. You count through the bits in the sequence of on/off states you need to blink the message, and use logic based on the bits of the binary count to switch the LEDs on and off.

What are the options?

• LEDs: you can choose between "blink a single LED" or "blink multiple LED groups, one group per letter". That means you can make a blinky with LEDs laid out in letter shapes.
• Speed: you can choose a blink rate.
• Footprints: you can change the footprints used for the different components in the blinky by downloading, editing and reuploading a JSON rules file. Let's consider that advanced usage. You'll figure it out if you really care.

How does it work?

For such a stupid little project, MBaaS uses some surprisingly powerful technology. More stepping on the toes of giants than standing on their shoulders... Here's the process:

1. Your blinky text is converted into an on/off bit sequence representing Morse dots, dashes and the spaces in between them by some custom Python code.
2. A representation of the on/off state of each LED at each step in the bit sequence is generated. You can think of this as a big bunch of ANDs feeding into a big OR gate (well, one OR per LED).
3. The AND/OR logic generated in the previous step (which has one AND per on state, all leading into a mighty big OR) is simplified using the Espresso heuristic logic minimiser. This results in a much smaller and more manageable logic expression to be realised in gates.
4. The simplified logic from Espresso is placed onto "real" AND and OR gates from commonly available 74xx logic (basically 2-, 3- and 4-input ANDs and 2-input ORs), and those real gates are assigned to real 74xx chips. This is done with some more custom Python code (using a dumb greedy algorithm that does a reasonable job, but could be optimised).
5. The gate assignments and the connections between the gates are used to drive some code that uses SKIDL to generate a KiCad netlist.

Why did you do this?

Seemed like a good idea at the time. It's obviously completely useless, but since I'm mostly a programmer, not a hardware person, I wanted to see how easy it was to generate hardware programmatically. This application is dumb, but I can think of lots of cases where I might do something like this that aren't dumb. (Also, I've been thinking of it as my "compile to silicon" project, which makes it sound a hundred times more cool than it is.)

If SKIDL was more fully integrated into KiCad's schematic editor, for example, so that you could include blocks of SKIDL code as components in your schematics, you'd open up a lot of possibilities. The tedious things where a schematic is no real benefit (bypass caps, connecting buses, repeated patterns of components), you could do with SKIDL, but you could still have the benefit of having a schematic for the parts where that visual representation is helpful.

Wow! What's next for MBaaS?

Eh, not much, to be honest. It's mostly a joke. And not even a very funny one.

You could improve it in various ways. You could improve the logic placement algorithm (which is, being generous, not of the highest quality). You could generate a schematic as well as a netlist. You could generate a simulation of the blinky using something like Logisim to verify that it works (Logisim is a nice little tool). You could (somehow) make the output more editable/customisable (that would probably need some SKIDL integration into Eeschema).