{"id":32616,"date":"2021-04-09T18:17:56","date_gmt":"2021-04-10T01:17:56","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=32616"},"modified":"2021-04-12T10:52:06","modified_gmt":"2021-04-12T17:52:06","slug":"show-dotnet-animating-40-leds-with-charlieplexing","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/show-dotnet-animating-40-leds-with-charlieplexing\/","title":{"rendered":"Show dotnet: Animating 40 LEDs with charlieplexing"},"content":{"rendered":"

For Pi day 2021, I published a fun post on how to Blink LEDs with Raspberry Pi<\/a>. As part of that writeup, I wanted to include a 40 LED charlieplexing<\/a> example, but couldn’t get it working. It is working now, and I decided to do a follow-up post to show it to you. What’s interesting is what I had to do make this sample work. Surprisingly, I only had to change one line of code<\/a> in the CharlieplexSegement<\/code> device binding. It’s this single line change that I want to share as much as being able to control the forty LEDs.<\/p>\n

I’m using this post to start a new blog series I’m calling “show dotnet”, intended for Fridays. The new series is inspired by Show HN<\/a> over at Hacker News. The idea is to create space on the .NET blog for showing something interesting or new, with no requirements on being the perfect post or aligned with the current release. The post can be quite short or super long. Doesn’t matter. The main thing is that it demonstrates some interesting or useful scenario of using .NET. It’s also perfect for guest posts. I’ve already got the first few posts lined up, and will curate these posts for a while. If this works out, I’ll broaden who can post. For now, this blog series is an experiment.<\/p><\/blockquote>\n

Animating 40 LEDs<\/h2>\n

Let’s take a look.<\/p>\n

\"Image<\/a><\/p>\n

Make sure to click the image to see the animation.<\/p>\n

I’m using the same demo code<\/a> as I did for the previous post. I have plans for writing some fancier code. Perhaps that will be another “show dotnet” post.<\/p>\n

In terms of code<\/a>, my app looks like the following:<\/p>\n

\/\/ To use with (8) directly connected GPIO pins\r\n\/\/ int[] pins = new int[] { 4, 17, 27, 22, 5, 6, 13, 19 };\r\n\/\/ using IOutputSegment segment = new GpioOutputSegment(pins);\r\n\r\n\/\/ To use with charlieplexing\r\nint[] pins = new int[] { 23, 24, 25, 12, 16, 20, 21};\r\nusing IOutputSegment segment = new CharlieplexSegment(pins, 40);\r\n\r\n\/\/ To use a shift register\r\n\/\/ using IOutputSegment segment = new ShiftRegister(ShiftRegisterPinMapping.Minimal, 8);\r\n<\/code><\/pre>\n
The rest of the code is identical to the rest of the Program.cs file<\/a>.<\/p>\n
As you can see, I’m using 7 GPIO pins to control 40 LEDs. On the Charlieplexing wikipedia<\/a> page, you will see a table that demonstrates that 7 GPIO pins can be used to control a maximum of 42 LEDs. That means I’m using the 7 pins near to their limit with this example. I go into much more detail about charlieplexing in my last post on LEDs<\/a>.<\/p>\n
The following is a quick description of Charlieplexing taken from my earlier post<\/a>.<\/p>\n
It is a multiplexing scheme that does not require using an integrated circuit like a shift register<\/a>. It takes advantage of the tri-state nature of GPIO pins, which can be either Low<\/span><\/code>,\u00a0High<\/span><\/code>\u00a0or\u00a0Input<\/span><\/code>.\u00a0Low<\/span><\/code>\u00a0acts as ground,\u00a0High<\/span><\/code>\u00a0is obviously power, and\u00a0Input<\/span><\/code>\u00a0doesn\u2019t allow power to flow in any direction. These three options enable you to create circuits on the fly, in software. It\u2019s a bit magic, definitely awesome, but also a bit of a hack.<\/em><\/p>\n
You might be thinking that charlieplexing has got to be the least practical way to control LEDs. Look at all those wires! It’s worse than an ethernet run in an office building. There is a lot of truth to that. It’s also time consuming to wire 40 LEDs. I made several mistakes and had to do it slowly. Now that I’ve done it a few times, I can go faster. I actually wrote a crude test tool to make it easier. If you want it, tell me in the comments, and I’ll make it available.<\/p>\n
Yes, there are a lot of wires. A lot of that is just a function of electronics on breadboards. If you want to control 40 LEDs, you will likely need 80 wires (one for each leg). Once you move to PCBs, things get a lot easier. For example, Adafruit has some nice charlieplexed LED matrices<\/a>. They operate on the same principles, and have the advantage of hiding all of the required connections on the underside of the PCB. These charlieplexed LED matrices are on my list to target. I already have a few of them in my toy box.<\/p>\n
Perhaps I’ll demonstrate controlling 40 LEDs with shift registers in a follow up. The wiring required for that configuration would be very different, although there would still be a lot of wires.<\/p>\n
Let’s take another look at the same demo, 90 degrees rotated.<\/p>\n
\"Image<\/a><\/p>\n
I’m now going to transition to what I had to do to make this demo work.<\/p>\n
Sleeping on the job<\/h2>\n
When I first wrote the CharlieplexSegment<\/a> binding, I used Thread.Sleep to create a delay<\/a>. You need delays to make persistence of vision<\/a> systems work. I was aware at the time that Thread.Sleep<\/a> wasn’t the right API because it is graduated in terms of integers representing milliseconds, making 1ms the minimum sleep. I knew from observation and looking at other examples that I needed a delay much shorter than 1ms.<\/p>\n
This situation is a little embarrassing. I should have been able to find an alternative myself, and I have excellent access to several threading and concurrency experts who would have been pleased to help me. Eventually, my colleagues at dotnet\/iot<\/a> pointed me at DelayHelpers.cs<\/a> for inspiration. dotnet\/iot #1249<\/a> is also relevant.<\/p>\n
In the end, I just switched from Thread.Sleep(1)<\/code> to Thread.SpinWait(1)<\/code>. It’s like the old joke “I improved performance by removing all the calls to Thread.Sleep<\/code>“. That’s what I did. As a result, the code is delayed ~1000x less. The impact of the change to my 40 LED example is both extremely obvious and pleasing.<\/p>\n
In short, Thread.Sleep<\/code> uses operating system and CPU features that enable creating delays without affecting the overall performance of the machine by yielding, similar to Thread.Yield<\/a>. Thread.Spin<\/code> is the opposite, it actually just uses the CPU — making a given core unavailable for any other execution — to create a short delay.<\/p>\n
In the process of writing this post, I asked my favorite threading experts to review this content. I was given the following advice (which I will absolutely apply).<\/p>\n
Thread.SpinWait does not make guarantees about the wall-clock time that it is going to wait. That\u2019s not good \u2013 it makes the code fragile. For example, the next time you upgrade your RPi or we make a performance fix in the runtime, your code may break because it will be too fast again. Instead of just calling SpinWait, it would be better to active wait for a specific number of nanoseconds, like is done in DelayHelpers<\/a><\/p><\/blockquote>\n
I was also given the following detailed feedback:<\/p>\n