Birch Books With ATmega48

I last wrote about the Trinket M0 version of Birch Books, which is using CircuitPython and uses a much simplified code structure, while relying on one of two possible I/O expanders. But I felt a bit of a cheat to implement this one with a Trinket M0, which is a very powerful MCU to use for something that should be as simple as to keep a few lights on in a LEGO set.

So, as suggested by a colleague, I looked into the ATmega48, which is a close relative to the ATmega328 that Arduino is based on. Actually, these two versions are pin- and source-compatible so while I have now implemented it with the 48, the 328 (which is more commonly available) should work the same way.

The ATmega48 option is an interesting compromise between the 8052 and the Trinket M0. It’s an 8-bit microcontroller, and it requires to write low-level C to program, but at the same time it doesn’t require any passive components (as long as you don’t need more than 8MHz, and you didn’t make the mistake I made about having an active-high RST button). It turned out that the suggestion was a very good one, and the ATmega48 does indeed seem to fit this project very nicely.

Programming the ATmega48 can be done via 6-pin connectors that need to provide power, SPI bus, and the RST line. This can be achieved with Adafruit’s FT232H board: you connect the SPI lines just as described on the breakout, and use D3 for the RST line, then you just tell avrdude to use the UM232H variant. No other configuration is needed. I actually plan on crimping my own harness for this later, so I don’t need to use a breadboard all the time.

The other main difference between the ATmega48 and the 8052 is that the former has nearly half the pins, but it still has enough I/Os (14 outputs, 2 inputs) for Birch Books that there is no need to add an expander. There’s a few more I/O lines as well, but they are “overcommited” and by default configured to have different meanings. For instance the external clock pins can be re-configured to be additional I/O lines, and even the RST line can be disabled by fuses to gain one more I/O.

Let’s talk about the clock! The ATmega48 is sent out from factory with the fuses configured for a 1MHz clock, but can be configured up to 8MHz. Alternatively it can use an external clock and run up to… I forgot, and the point being I don’t need any of that. I did order 100 pieces of 12MHz crystals just to have them at hand, when I made an order from LCSC, but for this project, the 1MHz clock speed is plenty. So I left it configured the way it came from factory, and that works perfectly fine.

The code ended up being very similar to the 8052 version of course: it initializes the ports, sets up a timer input, and in the loop checks for the test button and otherwise keep updating the port state depending on the calculated virtual hour. While the ATmega48 would have allowed for more fine-grained controls on the timing, and thus allowed me to use the original planned scheduled, I decided to actually keep the same 1/16th of a second “tick” timer, and the same formulas to calculate the schedule.

Another thing allowed by the ATmega48, or rather the fact by the AVR-GCC, would be making the code more modular. As I ranted before, SDCC is not the most aggressive compiler, when it comes to optimizing around functions, and that’s why instead of having more structured code I ended up with a lot of spaghetti. To make it easier to compare and maintain the code together, I decided not to refactor the spaghetti in the AVR version, but I think that’s okay. The simplification around the timer handling is already a huge step forward anyway.

On the logic side, I decided to implement a one second power-on self-test though that turns on all of the lights. This was meant not just to easily test the code while I had it on my desk, but also just as a general “healthiness check” for the LEDs. I backported it to the CircuitPython code while I was at it, as well. And I removed the “knuckle pattern strobing” (which turned on every other LED alternatively), because it doesn’t work quite right or well on the real LEGO set (where two rooms use three LED lines tied together), simplifying the test logic.

The other thing that I found out by using the ATmega48 is that I do have some difference in the current limiting between the Trinket M0 and the other two controllers. When I installed the Trinket M0-based controller, the lights in the bookstore were much brighter, and even if that looked nice, it had me worried, because I knew that the LEDs I’ve been using tend to brown out quickly if they are powered at maximum current. I managed to pretty much kill one LED by keeping it running for just two days without a current-limiting resistor. And indeed, a month later, some of the LEDs are now nearly completely dark, and will need to be replaced.

Since the actuator board is the same, powered from 5V, and with 47 Ohm resistor networks for the LEDs in each case, I’m not entirely sure why this is happening. I might need to add some inline current metering to to see how that fits together. But that’s for another time.

CircuitPython-powered Birch Books

This part April, after leaving one bubble and before joining the next, I found myself deciding to work on some basic electronics, to brush up my down-to-hardware skills and learn new stuff. And since I just had assembled the Lego Bookstore (Birch Books), I thought I would improve on that by adding LEDs and controlling them with a programmed microcontroller.

I’ve been back and forth on choosing which MCU to use, settling on an 8051 clone, which was not entirely straightforward to get to work, but eventually I thought I did. Until I got the actual boards to mount it on, and found out that I couldn’t get any new code on my chips, for some reasons I still haven’t figured out. Instead I decided to take a different approach and use a higher-level programming language and higher-level board, too.

Due to the new job having different set of contribution guidelines, I had to wait a bit before making the new boards and code available, but I have described most of the plans for it in the previous blog post. The code is now dropped in the repository. And I also spent some time to tidy up some of the other boards based on the various bits and pieces I learned from the past few months of trials and error.

The CircuitPython-based implementation relies on either the MCP23016 or the MCP23017 GPIO expanders. The trick for that is that the code is looking for the former at address 32 and the latter at address 33. The pull request to support the older, clunkier ’16 expander is approved but hasn’t been merged yet at the time of writing. I briefly considered making yet another alternative board based on the MCP23018 just to add support for it to the Adafruit library, but… I’ll leave that to someone else for now.

And while I used a Feather M4 to have it working at first, I ended up building the boards to the tinier Trinket M0, which turned out not just to be a good fit for the project, but also a good way to make sure the code would work on more boards. Turns out that on the Trinket, there’s no time.time() and I had to switch to monotonic() instead, and that lead to me finding a bug in CircuitPython.

In truth, you can hotwire anything to these boards as long as they have I²C and can talk to the MCP23016/7. And while the connector on them is designed with my actuator board in mind, what it has is pretty much the whole 16 I/O lines coming from the expander. Were you looking for an easy way to connect a Trinket M0 with 16 I/O lines to a breadboard? There you go — you might just have to connect the top header as a male pin header on the bottom of the board. Making an adapter to use this with a Feather would be relatively straightforward.

The (nearly) end result is fairly pleasing:

The version you see there is not the most recent design that you’ll find in the repository, but rather the first prototype of this version of the board that, surprisingly, managed to work the first time — nearly. The actuator board needed some work after I set up the Trinket: at first it kept blinking really fast, because it kept going in and out of test mode (which turns on all the LEDs), and in and out of “fast forward” mode (I’ll get to that in a moment). The reason turned out to be that the inputs needed an explicit pull-down. Which is why the new version of the actuator has three resistors to the side of the buttons. I also learnt that I really should pay attention to the orientation of components on the design, since at first I messed up and pulled up one of the inputs constantly.

Let’s talk a moment about the “fast forward” mode. When I originally came to design the inputs for the project, I decided I would want to have a way to run the whole cycle faster, to make videos out of it without needing to use a time-lapse or something like that. This turned out to be a good idea for testing, as well. But it’s implemented in fundamentally different ways between the 8052 firmware and its CircuitPython counterpart.

In the 8052 version, the time is kept as a number of ticks increased by a timer interrupt. When the fast-forward mode is engaged, instead of adding one tick per interrupt, it adds sixty four. Which is the speed up time of the fast forward. It also means that fast-forward works similar to a fast-forward on an old cassette tape, as it speeds up time while pressed, but it starts and end with normal time.

In the CircuitPython version, the “virtual hour” (as in, which scene we’re at) is wholly dependent on the monotonic time since start up, and the fast forward mode just changes the divisor between real time and virtual time. Which means that pressing fast-forward completely changes the virtual time. Oops. I couldn’t find a decent way around that that would have made the firmware overly complicated, so I pretty much gave up.

On the bright side, since I already have a repository for flame effect code for CircuitPython, it might be a good time for me to include the design for the fireplace, since it should be trivial to do so with the boards as they are right now!

Overall, I’m fairly happy with the result, although it feels less “self-contained” than I originally planned. I was honestly afraid at first that the Trinket M0 would be more power-hungry than the STC89, but it might be the opposite. Indeed I’m now having some issues with at least one one of the LEDs that I put in the bookstore being “burned down” — I fear my current limiting calculation was too tied to the STC89, as noticed when the ground floor LEDs turned out to be much brighter than with the breadboard. I need to make sure I got my numbers right — and if I need to, I have some new, fancier LEDs I can install, although those were rated for 12V, in which case I might need some rethinking of the whole setup.

Now to wrap this up a few words about this whole experience: I have worked on hardware before, but never down to this level. I have worked on firmware for very tiny systems that go into HVAC control planes, and for bigger systems built with COTS components but treated and sold as embedded solutions. But the closest to anything like this for me has been high school, which is over fifteen years ago!

This journey has been a learning experience, and I want to thank the folks over on the Adafruit Discord server. I also welcome any comment and critique on the code or the board designs — the latter particularly because I really have no idea what I was doing, and I had to improvise.

I also want to keep talking about mistakes as I make them, and even wonder out loud when I think I did something wrong, for two reasons: first of all, as I just said, I welcome more critiques of my thought process — if I’m going around something the wrong way, please let me know. The second reason is a bit more “squishy”: while making these mistakes is a sure way to learn more, they are not cheap mistakes. Ordering another set of five prototypes is around £5, but then you need to batch a few and spread over the shipping costs, plus the “bill of materials” tend to add up, even if the single components are just a few cents. I hope I’ll be saving someone else’s money when they look around to “how did someone else do this for this stuff?”

Art Projects Setbacks: Birch Books’ New Brain

You may remember that two months ago I declared my art project completed, and posted pictures of it. I have asid back then that it wasn’t quite all done and dusted, because I have been waiting for PCBs to arrive from PCBway, an online PCB ordering service that has been heavily advertising on YouTube makers’ videos for the past year or so. I ordered those back in April and, now that it’s July, they still haven’t turned up! I decided instead to follow again the advice of bigclive, and tried JLCPCB instead, which turned out to be a very good idea: ordered on Sunday, the boards arrived on Friday!

So on Friday I set myself to spend some of the time listening to training talks, and solder on the boards, which turned out to be a bit less practical than I intended — I might try again to solder microUSB connectors, but then I’ll follow Richard’s advice and try without the shielding in the back. After some screwups, I managed to get working boards, programmed a new STC89, and went on to connect it to the LEGO set — and it all turned up at once, which it wasn’t meant to!

After trying a few combinations of different Darlington arrays, and flashing a new build of the firmware, I ended up figuring that all the micros I flasked anew were completely stuck, with all the I/O ports staying at 5V with an occasional momentary pull down. At first I thought I screwed up the R/C network for the reset line, but no, I managed to check it with the Saleae Logic Pro and the reset line behaves exactly as it should have. I also popped in the original STC I used, before the ones I ordered on AliExpress arrived from China. And it worked fine, if a bit misconfigured (the new firmware has a few fixes). I also tried it and one of the “pristine” ones on the programmer, and they all work fine, but anything I program anew fails the same way.

It’s not a firmware problem either: I tried going back in time and build even the first draft version; I tried demos written by someone else; I tried four different versions of SDCC — all to no avail. Nothing changed in stcgal so it doesn’t sound like it’s a problem there… I’m at a complete loss of what’s going on there. I honestly felt desperate about that, because it worked perfectly fine two months ago, and now it suddenly stopped.

So instead, I spent Saturday working on my plan B: using CircuitPython for the main scenes logic, with an Adafruit board — in particular I decided to start working with the Feather M0, but I’m targeting the Trinket M0, which is cheaper, smaller, and still plenty powerful for what I need. This was also fun because, since I designed the actuator board to be separate from the MCU and in particular to be possible to plug it into a breadboard, which means that half of the design was already known working and didn’t need redesign.

Unfortunately what I didn’t think of was to produce a test board that would just plug into the pins on the actuator board to test it, without connecting it to the bookstore… so I ended up having to manually wire a lot of LEDs on the breadboard to turn them on. I’m going to use this as a visible example of why you should always build a fake of your service if you’re writing a client, to run integration testing with! I am addressing this by ordering an explicit testing board to connect on top of the actuator, so that I can just use it. Also fun fact: it looks like the LEDs that I have used in this pictures are… more sensible than the other ones, and Sparky the Blue Smoke Monster came to visit me again when I gave it a straight 5V.

There’s more jankiness going around with this board, though. When I was looking at expanding the I/O capabilities of the Feather, I ended up buying a few MCP23016 expanders. These are I²C chips that provide access to 16 input or output lines while only requiring two wires on the MCU. I can’t for the life of me remember or figure out why I went with this particular model, that currently sports a «Not Recommended for new designs.» warning on the top of the Microchip product page. I might as well have mistyped the MCP23017, which is the modern version of the same chip.

Beside not being (at all) pin compatible, the documentation on Adafruit’s website is designed for the later (’17) variant, and indeed the older (’16) version is not currently supported by CircuitPython (although I’m addressing this). It doesn’t stop there: 16 requires an additional R/C network, which turned out to be very unreliable: it ended up working better with a single resistor on the CLK line, and I’m not at all sure on why. So in general, the difference between MCP23016 and MCP23017 is that the latter is much nicer to use. Since I do have a few 16, and the components needed for the RC network, I’ve started writing the CircuitPython code based on that first, but also designed a separate board to fit the ’17, using a non-default address, so that I can distinguish between the two at startup.

Part of the reason for that is also that the ’16 is very finnicky, and when it receives a command it doesn’t entirely like, it decides to simply crash, and requires a full power cycle (not just a reset), which isn’t very good.

There’s another jankiness that you can possibly spot on the right side of the board: why is there a transistor, in this fairly minimalistic design? I mean okay, the pull-up resistors for I²C lines, and the RC network already ruined the idea of having the daughterboard and the expander only. But a transistor? Well, it turns out when I designed the actuator board I made a silly mistake: I didn’t consider that reset lines (RST) are not always active high (as they are on the 8051), but are sometimes actually ¬RST — and as you can imagine now, both the Feathers and the Trinket M0 are indeed active low.

And since pushing the Reset button is bridging the RST line of the actuator board to VIO (hey, at least I did realise that if I went to a different platform I would need a different “logic high”!), it wouldn’t work at all. Instead, it now activates the transistor, so that it bridges the RST line to ground. Basically, a NOT gate implemented with a single transistor — which I might have remembered thanks to Richard Feyman Lectures on Computation, which is a book I actually would recommend for those interested.

And if you’re wondering why the I/O lines are all orange, I checked which equipment wire roll I had the most of, turned out to be orange.

Also, a word of advise that I found out by complete random chance as well: the default for “quote dimensions” in Eagle is to put them in as traces at the top of the board! When I sent the generated gerber files to JLCPCB this time, they noted some dead shorts and asked me to confirm if that was intentional — so kudos to them for noticing. They allowed me to upload new, fixed gerber files after that.

Art Project Completion: Lighted Up Birch Books

The first Birch Books scene

I started talking about my quarantine (or, well, lockdown) art project at the end of March, with a plan. I did manage to (mostly) complete it by the end of April, while the lockdown (and my sabbatical) are still in full swing.

I have shared some work in progress pictures over on Twitter, including a 2-minutes video (shot on my phone by hand, so not very high-quality) showing the full set of scenes (before the latest “firmware revision”). As you can see from all those pictures, the cables are still pretty much in the way and very visible. That’s not something I have addressed yet, but I’m waiting for the PCBs to arrive before doing that.

At the end, the result is that throughout the building there are 12 bright white LEDs, connected via Dupont connectors to a harness that then goes into the breadboard — that’s so that the harness can disappear the moment I have the PCBs.

For the PCBs, I think I made a rookie mistake. I ordered them from PCBWay, as I heard good about them on the tubes, and they seemed to have a good price point even for assembly of the SMD versions. That was not the mistake. The mistake was to send a single order with both the SMT and the through-hole PCBs, to save on shipping. I’m now having to wait until the end of this month to receive the boards, and hope I didn’t make any more mistakes on them. Edit 2020-07-01: nearly three months later, the PCBs have not turned up. I ended up ordering a new batch from JLCPCB (not an affiliate link) that arrived within a week. Beware of YouTubers being paid for it.

I’m also sure that there will be changes I’ll need to make. These are literally the first printed circuit boards that I design, and beside obvious stylistic mistakes (such as not marking the value of components), I’m sure there’s more mistakes than that. So I expect I’ll have to update the designs later on. Hopefully it won’t get a mess of bodge wires when I try to use it properly.

I think it might be dinner time.

I have to figure out how to fit all of this into a box, eventually. Probably a Lego box of some kind. And I’ll probably have to make sure that the USB plug is fit properly. Soldering a microUSB connector on a PCB is… not easy and not something I’m looking forward to. That’s why I added a 5-pin header on the design, so I can use one of the cheap breakout boards you can find all over on AliExpress or eBay.

The 8051 based firmware is available on the same GitHub repository, and it includes a full 16-scenes (although not unique scene) schedule that now runs in about one minute.

I also changed the “boot test” mode in the second “firmware revision”: instead of trying to turn on each LED one by one, it turns on each room one by one. The reason why I did that, is that I have hooked up multiple Darlington gates through a joint to provide more current for a couple of rooms that have three LEDs on the same room. This might have been a bit of a mistake and I should probably rewire those rooms to just use multiple LEDs, but that’s not going to happen any day now.

Also, with a bit of a hindsight, I should probably have just left the current-limiting resistors off the actuator board altogether. While the resistor networks are great to simplify the design, I could have just as easily soldered the resistors inline on the cable and wrapped them with heatshrink. I know because I did exactly that on another Lego set, when I realised that powering it directly from a 5V supply was significantly overheating one of the two LEDs.

This is, by the way, another “trick” learnt while watching bigclive on YouTube. Probably not something that would be worth a complete video on, and maybe something that felt fairly natural and not required to explain to him but… something I’m very happy to have learnt. Which is why I love rambling on about small choices in my thought process, as it’s very possible that something that is natural and obvious to me, is not for someone else reading me. And why I do welcome comments asking for clarification on points I may be glossing over.

Also, both my wife and my mother have been pushing me to figure out what the next Lego model I will be adding lights to is going to be. I don’t honestly know, right now. But I guess the lessons learnt with this model should allow me to step up to something a bit more complicated next time. For sure, it would be a cheaper and easier job, since I procured a lot of tools for it anyway.

I think that the things I will consider changing for next time are not just the place the current-limiting resistors are connected (which I can probably retro-fit on the current PCBs), but also the type of wiring I use for the LEDs. I used equipment wire for this build, and it turns out to be fairly stiff and unwieldy. If I were to re-do this, or do it to another model, I would probably use the equipment wire only within the rooms themselves (that way I can push it out of the way), and then solder it just outside the model with a stranded, softer wire.

I think this will probably be the end of the regularly scheduled updates on my art project, at least until the PCBs arrive. I did intend to draw some documentation with a tool like Fritzing, which is used by Adafruit for their documentation, but I’m having quite a few headaches even figuring out how to set it up. None of the components I need are part of their parts libraries, and the documentation is out of date regarding the parts editor, so don’t hold your breath.

Birch Books: 8051 and Yak Shaving

I have previously discussed my choice of splitting the actuator board, pointing out I’ll probably try designing an alternative controller board using something like the Adafruit Feather M4 and writing the firmware with CircuitPython. Part of the reason for that is that it’s just easier, but part of it is because 8051 is an annoying platform to work with.

There are a few different compilers for this platform, but as far as I know, the only open-source and maintained one is SDCC the Small Device C Compiler. I hadn’t used this in forever, but I was very happy to see a new release this year, including C2X work in progress, and C11 (mostly) supported, so I was in high spirits when I started working on this.

A Worrying Demonstration

I started from a demo that was supposed to be written explicitly for the STC89. The first thing I noted was that the code does not actually match the documentation in the same page, it references a _sdcc_external_startup() function that is not actually defined. On the other hand it does not seem to be required. There’s other issues with the code, and for something that is designed to work with the STC89, it seems to be overly complicated. Let me try to dissect the problems.

First of all, the source code is manually declaring the “Special Feature Registers” (SFR) for the device. In this case I don’t really understand the point, since all of the declared registers are part of the base 8051 architecture, and would be already declared by any of the model-specific header files that SDCC provides. While the STC89 does have a number of registers that are not found otherwise, none of those are used here. In my code I ended up importing at89x52.h, which is meant for the Atmel (now Microchip) AT89 series, which is the closest header I found for the STC89. I have since filed a patch with a header written based on other headers and the datasheet.

Side note: the datasheet is impressive in the matter of detail. It includes everything you may want to know, including the full ISA description, and a number of example cases.

Once you have the proper definition of headers, you can also avoid a lot of binary flag logic — the most important registers on the 8051 chips are bit-addressable, and so you don’t need to remember how many bits you need to shift around for you to set the correct flag to enable interrupts. And while you may be worrying that using the bit-addressed register would be slower: no, as long as you’re changing fewer than three bits on a register at a time, setting them with the bit-addressed variant is the same or faster. In the case of this demo, the original code uses two orl instructions, each taking 2 cycles, to set three bits total — using the setb instruction, it’s only going to take 3 cycles.

Once you use the correct header (either my contributed stc89c51rc.h, the at89x52.h, or even the very generic 8052.h), you have access to other older-than-thirty-years features that weren’t part of the original 8051, but were part of the subsequent 8052, which both the STC89 and AT89 series derive off. One of these features, as even Wikipedia knows, is a third 16-bit timer. This is important to the demo, since it’s effectively just an example of setting up a timer to “[set] up and using an accurate timer”.

Indeed, the code is fairly complicated, as it configures the timer both in main() and in the interrupt handler clockinc(). The reason for that is that Timer 0 is configured in “Mode 0”: the timer register is configured as 13-bit (with the word TH0, TL0), its rollover causes an interrupt, but you need to reload the timer afterwards. The reason for that is that you need more than 8 bit to set the timer to fire at 1kHz (once every millisecond), and while Timer 0 supports “automatic reload”, it only supports 8-bit reload values — since it’s using TH0 for the reload value.

8052 derivative support a third timer (Timer 2), which is 16-bit, rather than 8- or 13-bit. And it supports auto-reload at 16-bit through RCAP2H, RCAP2L. The only other complication is that unlike Timer 0 and Timer 1, you need to manually “disarm” the interrupt flag (TF2), but that’s still a lot less code.

I found the right way to solve this problem on Google Books, on a book that does not appear to have an ebook edition, and that does not seem to be in print at all. The end result is the following, modified demo.

// Source code under CC0 1.0
#include <stdbool.h>
#include <mcs51/8052.h>

volatile unsigned long int clocktime;
volatile bool clockupdate;

void clockinc(void) __interrupt(5)
{
        TF2 = 0;  // disarm interrupt flag.
	clocktime++;
	clockupdate = true;
}

unsigned long int clock(void)
{
	unsigned long int ctmp;

	do
	{
		clockupdate = false;
		ctmp = clocktime;
	} while (clockupdate);
	
	return(ctmp);
}

void main(void)
{
	// Configure timer for 11.0592 Mhz default SYSCLK
	// 1000 ticks per second
	TH2 = (65536 - 922) >> 8;
	TL2 = (65536 - 922) & 0xFF;
        RCAP2H = (65536 - 922) >> 8;
        RCAP2L = (65536 - 922) & 0xFF;
	
        TF2 = 0;
        ET2 = 1;
        EA = 1;
        TR2 = 1; // Start timer

	for(;;)
		P3 = ~(clock() / 1000) & 0x03;
}

I can only expect that this demo was just written long enough ago that the author forgot to update it, because… the author is an SDCC developer, and refers to his own papers working on it at the bottom of the demo.

A Very Conservative Compiler

Speaking of the compiler itself, I had no idea of what a mess I would get myself into by using it. Turns out that despite the fact that this is de-facto the only opensource embedded compiler people can use for the 8051, it is not a very good compiler.

I don’t say that to drag down the development team, who are probably trying to wrestle a very complex problem space (the 8051’s age make its quirk understandable, but irritating — and the fact that there’s more derivatives than there’s people working on them, is not making it any better), but rather because it is missing so much.

As Philipp describes it, SDCC “has a relative conservative architecture” — I would say that it’s a very conservative architecture, given that even some optimisations that, as far as I can tell, are completely safe are being skipped. For example, doing var % 2 (which I was using to alternate between two test patterns on my LEDs) was generating code calling into a function implementing integer modulo, despite being equivalent to var & 1, which is implemented in the basic instructions.

Similarly, the compiler does not optimise division by powers-of-two ­— which means that for anything that is not a build-time constant you’re better off using bitwise operations rather than divisions — it’s another thing that I addressed in the demo above, even though there it does not matter, as the value is constant at build time.

Speaking of build-time constants — turns out that SDCC does not do constant propagation at all. Even when you define something static const, and never take its address, it’s emitted in the data section of the output program, rather than being replaced at build time where it’s used. Together with the lack of optimisation noted above, it meant I gave up on my idea of structuring the firmware in easily-swappable components — those would rely on the ability of the compiler to do optimisation passes such as constant propagation and inlining, but we’re talking about the lack of much lower level optimisation now.

Originally, this blog post also wanted to touch on the fact that the one library of 8051 interfaces I found hasn’t been touched in six years, has still a few failed merge markers, and not even parsing with modern SDCC — but then again, now that I know SDCC does not optimise even the most basic of operations, I don’t think using a library like that is a good idea — the IO module there is extremely complicated, considering that most ports’ I/O lines can be accessed with bit-addressed registers.

Now, as Andrea (Insomniac) pointed out, Philipp also has a document on using LLVM with SDCC — but the source code this is referencing is more than five years old, and relies on the LLVM C backend, which means it’s generating C code for SDCC to continue compiling. I do wonder if it would make sense to have instead a proper LLVM target for 8051 code — it’s beyond the amount of work I want to put on this project, but last year they merged AVR support into LLVM, which allows to use (or at least try) Rust on 8-bit controllers already. It would be interesting to see if 8051 cores could be used with something different than C (or manually written assembly).

You could wonder why am I caring this much for a side project MCU that is quite older than me. The thing is I don’t, really. I just seem to keep bumping around 8051/2 in various places. I nearly wrote a disassembler for it to hack at my laptop’s keyboard layout a few years ago. I still feel bad I didn’t complete that project. 8051 is still an extremely common micro in low-power applications, and the STC89 in particular is possibly the cheapest micro you can set up prototypes at home: you can get 20 of them for less than 60p each from AliExpress, if you have the time to wait — I know, I just ordered a lot, just to have them around if I decide to do more with them now that I sort-of understand them. the manufacturer appears to make many multiple variants of them still, and I would be extremely surprised if you didn’t have a bunch of these throughout your home, in computers, dishwashers, washing machines, mice, and other devices that just need some cheap and cheerful logic controller without breaking the bank. Heck, I expect them to be used in glucometers, too!

With all these devices tied to closed-source, proprietary compilers, I would feel more comfortable if there was some active work on supporting a modern compiler platform in the open source world as well. From my point of view, this sounds like the needs of the industrial users, and those of the hobbyist community, diverged very much on this topic.

Sum It All Up

So for my art project I decided that even SDCC is good enough, but I wanted to make sure I would not end up with broken code (which appears to happen fairly often), so I ended up reading the generated assembly code to make sure it made sense. Despite not being particularly familiar with 8051 ISA, thanks to the Wikipedia article and the detailed datasheet from STC, it wasn’t too hard to read through it.

While I was going through it, I also figured out how to rewrite parts of the C code to force SDCC to emit some decent code. For instance, instead of a branch that either adds 1 or 32 to a counter, I was better off making a temporary variable hold 1, or change it to 32, add that variable. The fact that SDCC couldn’t optimise that made me sad, but again it’s understandable given the priorities.

Hopefully I have kept the source code still fairly readable. You can check the history to see all the various things I kept changing to make it more readable in assembly as well. Part of the changes meant changing some of my plans. In my first notes I wanted to run through 20 “hours” configurations in 60 minutes — but to optimise the code I decided that it’ll run 16 “hours” in just over 68 minutes. That way I could use a lot of power-of-twos and do away with annoying calculations.

Birch Books MCU Selection

A couple of people have asked me why I started the art project down the path of using an 8051 MCU, which is a fairly old microcontroller (heck, I found out I looked at those chips back in 2006!), rather than using one of the more modern hacker/maker solutions such as Arduino. The answer I already gave in that post: I had it already here.

I bought a devkit for it hoping to be able to hack on the LED heart I bought as a surprise for my wife on Valentine’s day, which was centered around the same micro. Now, with hindsight, that was silly: the board was explicitly marked with an AT89S52 name, which is a much more common chip, and probably one for which I could have found a devkit/programmer in much shorter time, but it turned out to be a nice exercise nonetheless.

Indeed, I ended up having to learn a lot more about this chip, its programming, and refreshing my (terrible) electronics understanding. And while this has been breaking my brain at times, it also stretched it to learn something new. I guess I now know how my wife is feeling while learning Python coming from a humanities background.

I had another micro at home. Some time ago I wanted to figure out how to send a certain sequence of infrared commands to my TV via Google Assistant (it’s a long story, sometimes my TV doesn’t initialize the audio return channel correctly), and I ended up buying (but never using) an Adafruit Feather M4 and an AirLift FeatherWing. I soldered the terminals and made sure they worked, but only played with it briefly.

The Feather comes with CircuitPython, a MicroPython implementation firmware, which actually is fairly nice to write simple logic for the microcontroller, and is very easy to deploy: you just need to copy the Python files in the virtual USB flash drive that appears when you connect the board to the computer. It also includes a very nice interactive Python shell you can use to experiment without needing to commit to code (yet). And with the AirLift you also get support for controlling remotely via WiFi, and setting up all kind of request handling.

On the other hand, the 8051 is a fairly complicated tool. The ISA has not had any refresh since 1980 for what I can tell, and that’s on purpose: binary and pin compatibility appears to be the main advantage on using 8051 derivatives chips (or cores on FPGA). You’d think that with that having stayed the same we would have very advanced toolchains for it, but you’d be wrong. As far as I can tell, the only maintained open-source compiler for this is SDCC, and even that barely just. You might have seen my rants about this on Twitter, and if not, fear not: I’ll write a post about it next week.

So why did I go for the 8051, which is significantly older, harder to write code for, harder to program (you either need a devboard, or make sure you provide the right ISP headers on the board), and with quite a few question marks on its availability?

Well, the Feather only has a few really general purpose I/O lines. While both the M4 and the ESP32 supposedly should have enough GPIO lines, the Feather is a specific configuration, that commits a lot of lines to specific usage, such as an I²C/SPI bus to communicate with different Feathers. The usual answer to this is to include something like the MCP23017, which is an I/O expander that you drive via the I²C bus. But as it turns out, not only I don’t have one of those at home, but even Adafruit appears to only sell it on an Expander Bonnet for the Raspberry Pi. I’m not sure why there’s no FeatherWing with it, despite the fact that they document how to use one with CircuitPython, and while I’m sure I could design one, or look for an unofficial one, it’s something I don’t want to get to right now.

On the other hand, 8051 and its clones come with a lot more GPIO lines, and most of those are uncommitted if you start from nothing. The DIP-40 packages have 32 lines, and if you don’t need to use external memory, you have at the very least 16 uncommitted lines. Of the other 16 lines, some are shared with other functions, including external hardware interrupts, serial port, and most in-system programming interfaces.

Now, theoretically it seems like the ESP32 chip also have quite a few GPIO lines, although I only counted 14 uncommitted lines on their QFN packages. I guess you can scavenge a few more lines by not using some of the features, but that might end up conflicting with the MicroPython interfaces anyway.

So yeah I will probably eventually move to a different design that includes the MCP23017. Maybe I’ll end up designing a Feather Base (if not a proper FeatherWing) for it after all, to prototype with the already designed (and sent to fab) actuator board. But that’s a story for another time.

Birch Books Controller and Actuation Boards

Now that I’m free from my previous employer’s open source releasing processes, I’ve finally decided to put ideas to the computer and figure out how to actually build the controller board, and its firmware. It does help that I’m still missing the crimping tool to add connectors to the LEDs so I can test them, and that I had to think things through a bit more before ordering chips.

First, I needed to figure out what interactions I would get. As I said in the previous post, the plan is to have a single pin pair per driven LED, even when LEDs would always switched on and off together. It just makes the layout much cleaner, particularly as then there’s no need to encode knowledge of the final layout into the electronics. The final count of LEDs I’m looking at is 13, and as I’m going to use two Darlington arrays (ULN2003), I rounded that up to 14. And just to have some extra, I decided to add a straight +5V pin on the final connector, just in case I decide to do something else with it later.

As the target micro (STC89C32/AT89S52 and similar chips) comes with four 8-bit ports, this means that using two ports only, I can add an additional two inputs, which fits with my needs: a button to toggle turning on all the LEDs at once (useful to take detailed photos), and one to “fast forward” — so that instead of waiting for X minutes to change scene, it would wait X/Y (numbers and timing still to be defined).

Choosing the ports turned out to be a bit more complicated than I would have expected. The reason for that is that I also wanted to keep track of how to flash the micros. While I do have a “programmer” board (which is actually an overall test board) for the STC micros, I wasn’t sure how it would look like once completed, and didn’t really feel like unsocketing the chip every time I wanted to make a change.

According to the two datasheets (STC89Cxx, AT89S52), both chips include “In-System Programming”, but they do it quite differently. The STC uses the UART (serial) line that is standard on the 8051 chips and forms part of P3. This is what stcgal uses to program the chips, and I have tested that it works with any serial adapter connected to the right pins. The Microchip version uses I²C instead, using the three upper lines of P1.

This means that, to keep the board as simple as I can, without using the same pin for two functions, I’m better off using the P0 and P2 ports — these are used for address and data busses, when using external memory with the 8051, but that’s not something I need, so they are easily dedicated to drive the I/O of the controller board. Annoyingly, in the 40-DIP version of the 8051 and compatible chips, P0 and P2 are, yes, on the same side of the chip, but also “bookended”: pin 32 is P0.7 (highest bit of P0), and pin 28 is P2.7, which means that to keep the outputs linear you either need to reverse them in software, or in hardware. I went for hardware, since EAGLE’s Autorouter can do that faster than I can do it in software.

I also got bitten by a quirk of the 8051: P0 is the only port that needs pull-up resistors! The I/O lines on P0 are tristate (On, Off, NC) and floating by default. I didn’t notice that before because obviously the devboard I’ve been using has them already. Thankfully, before ordering anything I wanted to try the whole set of components on a breadboard (pictured right), and found that out pretty quickly. There was a hint of this in the heart-shaped circuit I keep going back to: the LEDs on that board are all wired with common-anode, which effectively turn their resistor into the pull-up. I totally missed it, but I was in time to fix the board, and to order some resistor networks so that I don’t have to end up soldering 16 extra legs, but just 9.

Now as I was preparing this I also figured out that, if I do provide the ISP connectors for both AT and STC chips on the board itself (and at least it appears that the STC programming works the same way for other chips, including the STC12C5A60S2), I don’t need to limit myself to DIP chips — I can use a socket PLCC, or a surface-mount LQFP, and just program it on the board. So I tried to figure out how different would an SMD board would be — and realised that there’s effectively two parts to the board as I had been picturing it it in my mind: the controller, with the microUSB plug, the micro and its paraphernalia (crystal, RC net, etc.), and the ISP headers — and the actuator, which receive the signals to turn on and off the LEDs, and sends the button presses, and then translate those in the actual powering up via the Darlington arrays.

So what I ended up doing was designing two separate boards, connected with a straight 1×20 pin header, carrying the 16 I/O signals, and a few extras. In addition to the +5V and the ground, it carries an RST signal (which can be either consider the 17th I/O, or just wired straight into the micro’s reset line, like I did), allowing the whole board to be reset, without having to powercycle it, and it also carries a Vcc line.

Why the extra Vcc line? Well, as I’ll explain in a post next week (hopefully with more positive information rather than just the rant it would be now), I’ve been considering alternative MCUs as well, for the controller. Not least because the 8051 is a very strange thing to program. One of the chips I was considering was the ESP32, which is fairly cheap and easy to find in the market, since nearly anything “IoT” is using it, as it supports WiFi and Bluetooth out of the box, and can be used as a “co processor” as well. It turns out to have enough GPIO pins to not require a multiplexer, but it also uses 3.3V CMOS levels rather than the 5V TTL levels that I’ve been thinking in, for the 8051 version. And for that reason, I need to distinguish, in the actuation board, the supply used to power the LEDs on, and the logical High for the inputs.

This exercise was useful to also figure out that I was completely wrong in the board files I pushed originally! I had not paid enough attention to the ULN2003, and assumed it was a standard PNP transistor, but Darlingon arrays are NPN transistors. So LEDs will have to share the supply cable, and use multiple ground connections going through the Darlington. Again, this would lead to a common-anode design.

So now the boards are in the repository, even though they are probably terrible. There’s some basic documentation as well explaining the pin connections. There are two versions of the actuator board, one using SMD components and one using through-hole (PTH) — the reason is that I’m likely going to buy the prints from PCBWay, and they can manufacture the SMD version fully — but it will take 40 to 50 days. So I’m planning on having that manufactured for later, but in the meantime I wanted something I could prototype on — so the through-hole came later, as you can tell by the fact I realised I could put resistor networks between supply and anode, rather than between cathode and Darlington.

Edit 2020-07-01: nearly three months later, the PCBs have not turned up. I ended up ordering a new batch from JLCPCB (not an affiliate link) that arrived within a week. Beware of YouTubers being paid for it.

Birch Books: Access Points

I already introduced my quarantine art project, and as I promised here comes the second blog post on the topic, just to keep my own running notes around.

First of all, I decided to at least (partially) follow the advice from Adam Savage in his biography, about making lists and planning carefully. Indeed, I decided to write on paper as much running notes as I could and I could make sense, particularly since, as I said in the previous post, I’m not really at ease with electronics and I’m just lost at most of the things that are needed for this project, truth be told. So shout out to my friend Srdjan for helping me keep an eye on the things that are required!

My picture trying to figure out where to access the model to get wires through.

One of the things I clearly needed to solve was the access point for the wires themselves. The cable I have at home (without me going and buying more) is “equipment wire” (I got this a couple of years back because it’s single-core and made my protyping on the breadboard easier), and it is 0.6mm in diameter. I’m sure I can probably look for thinner wire, like wire-wrapping wire, and it’ll be perfectly fine to run 5V/50mA. But unless I deem it’s going to be impossible to keep hidden the wire I already have, I don’t think I’ll be buying more wire just yet.

Because of the nature of the model, the easiest way to modify the set without it being too noticeable it’s on the sides — Birch Books is designed to fit together with other Creator kits, and can be connected together through the base. Indeed, the kit itself is composed of two buildings that are connected at the base, and otherwise perfectly independent. This would be a problem if I decided to buy more sets of Creators, but then again, let’s cross this when it comes.

I also want to make sure that I don’t have to modify the pieces coming from the original kit. While I’m sure all of those are replaceable, it’s easier to keep them aside, and modify other pieces. I bought myself a box of assorted bricks, and I was lucky to find a few pieces that were already the right colour and shape for what I need.

I have then started dividing the set into rooms, and then for each rooms figured out how many LEDs I want (and where) and how many independent control lines I want. My current design involves bringing either one or two wires in each room: where multiple LEDs are needed in a room, I can connect them in parallel, and where a room has multiple control lines, I can share the ground connection between them.

There’s another question that I needed answering and that would be what the interface between microcontroller and the LEDs would be. I settled for simple pin headers, similar to motherboard front-panel connections, and using Dupont connectors. I’m still uncertain on whether to follow the motherboard option of using pins on the board, and female headers on the LEDs, or go the more theoretical approach of using female headers on the side with actual power going through.

Awesome video by bigclive on crimping tools.

Also as an aside. If you ever decide, like me, to start crimping your own Dupont style connectors, don’t just get the first random crimping tool that Amazon Prime will deliver to you, like I did. Watch the awesome video by bigclive, and go for a better tool. I have been fighting with the one I bought for a whole day, until I watched the video, and the one I’ve been trying to use was one of those he dismissed immediately without even going into details for. I ordered the same IWISS he was using at the end. Your mileage may vary, but it’s worth considering that.

I’m still not sure what the final controller board will look like, but to make things easier for myself, my current design assumes that there’s going to be a single pin pair per LED, connected to a 47Ω resistor. This means that even for rooms with a single control line and three LEDs, I would end up crimping them into a 3×2 connector, wiring the three VCC lines together — as long as the GPIO lines are kept at the same state, this should mean that the current is provided and limited in the right amount I need for those LEDs.

Speaking of GPIO lines — part of the reason why I decided to stick to the STC89C32 that I had at hand was also because they come with quite a few GPIO lines. Indeed, the AT89S52 from Microchip also comes with 32 easily accessible GPIO lines, which is plenty for this project. Unfortunately, they don’t have particularly useful maximum current draw. The LEDs that I got here are fairly bright at 35mA, but not particularly so at less than 3mA that they are getting from the GPIO line as is, and even I/O expanders such as the MCP23016 have a limit of 25mA per line. So instead, I settled for adding transistors, or to be precise to add two ULN2003 Darlington arrays, giving me space to drive 14 LEDs (I only expect 13 of them to be used).

In addition to the time-scheduled updates, I expect to want a button to “fast forward”, which allows me to show off the effects without having to stand around the kit for an hour — and a “full on” that works both as a way to test that everything is working, and as a way for me to take pictures easily.

I don’t have anything remotely sharable about that part of the work just yet. But hopefully soon I’ll be able to get drawings, pictures, or anything at all useful, and start sharing. Because if I didn’t think this horribly wrong, the board itself should be usable for many other configurations, just by programming something different on the micro using the same base software. And as I said previously, I think I’ll try turning around a number of different designs, just for the sake of it.

Quarantine Project: Birch Books Smart Home

By now, everybody knows we’ll be spending a few more weeks closed up in our houses, flats, or rooms. And so everybody is looking for new ways to keep busy. While I do have a significant number of incomplete open source projects to dedicate my time to, I also felt I needed something that was just for myself. So I decided to start what could be described as an “art project”.

A few months ago, I have bought for myself a Birch Books Lego set. It’s a lovely set, and I have a particular place in my heart for bookstores in general (despite having switched to ebooks many years ago). I wanted to take good pictures of it, particularly since I have a few macro lenses that should do it justice, but to do so I felt the need for lighting it up.

Now, you can buy light kits on Amazon for it (and for most other kits out there), but I wanted to do something. So I ended up buying a bunch of battery holders, white LEDs, and a box of assorted lego bricks for me to take a look at, for modifications. I also got lucky, and found a number of bricks the right color for the set.

And since I’m a geek and I love overkill solutions, I started thinking “can I make wire this to a microcontroller, and have it control the lights over time?” — Originally I considered keeping it aligned to the wallclock (as in, the time in the real world) but it turned out that it’s not that interesting to change so slowly — and it’s actually much harder. Having it cycle at a fixed speed is much easier, and with a couple of button controls you can do pretty much all you need.

As it turned out, I had most of the stuff I needed at home already: for Valentine’s Day, I ordered three heart-shaped LED kits on eBay (three because that’s how many they sold it as), that came with a microcontroller — a STC89C51, which are Intel 8051 compatible micros with 35 I/O ports. Back then I also decided I would like to try programming one for custom patterns, and bought a programmer/development board as well, and it came with another micro. While this seemed like a fairly niche micro, it made prototyping easy, since it’s a DIP micro, which I can just put on a breadboard.

The first problem I had with this was figuring out how to flash anything on the micro. What I found online suggested using a set of Windows tools that are only in Chinese. I then found another page, that suggests to just use SDCC and a tool called stcgal, which is Python command line tool that allows one-command programming of the micro. This worked great — the Special Function Registers are described in the datasheet, so it shouldn’t be hard to describe in a header.

So I turned to EAGLE first, and KiCad second, trying to figure out how I would layout what I need on a board, and couldn’t find the STC anywhere. And then I started thinking that maybe this is a clone of something else. A few Google searches later, I found the AT89S52 — which turns out to be exactly the same pinout and most likely the same registers as well. The STC89C51 is (mostly) a clone of the AT89S52. It does not appear to share the same programming protocol, and it actually appears to provide a list of additional capabilities and registers that the Microchip MCU does not have, but it does mean I can just write the code targeting the AT89S52, and be done with it.

Now let me remind you that I’m not particularly versed with electronics, so I’ll probably be making tons of mistakes throughout this experience. But I’ll also be trying to provide regular updates on how the project is going and, assuming I do make it to get it to work, I’ll be publishing all the source code, and any schematics I might end up drawing for the project.

I’m actually happy of having found out that the chip is just a Microchip/Atmel chip instead — because this increases not just the usefulness of me talking about the design, and opening up the sources, but also for myself as I would rather play with something that I can reuse later, rather than with some specific micro I just happen to have at home.

Also, I might end up designing a few alternatives for this anyway. The original draft of this blog post was written when I just started thinking this around, but I’m now putting a few more edits on it while having fleshed out some of my intentions for the project, and it might just be I’ll run with a number of different options around. We’ll see.