349: Open Down to the Transistor
Transcript for Embedded 349: Open Down to the Transistor with Drew Fustini, Christopher White, and Elecia White.
EW (00:00:06):
Welcome to Embedded. I am Elecia White. I'm here with Christopher White. We'll be talking about Embedded Linux, RISC-V, and FPGA tools. Our guest is Drew Fustini.
CW (00:00:19):
Hey, Drew, thanks for talking to us today.
DF (00:00:21):
Hello.
EW (00:00:22):
Could you tell us about yourself as though we met at an open-source hardware something conference?
DF (00:00:31):
Or bring-a-hack, which I think is where we actually met for the first time.
EW (00:00:35):
Actually, that's true. Yeah.
DF (00:00:37):
Yeah. So, I'm Drew Faustini. I'm originally from Chicago, but I live in Berlin now. I'm an Embedded Linux developer and hardware hacker. I'm part of the BeagleBoard.org Foundation. We create small single-board computers, with our wonderful community and manufacturing partners.
DF (00:00:57):
Some of you may know the BeagleBone Black, which is probably one of the most successful boards going back to 2008, where we had the original BeagleBoard, which is one of the first low-cost ARM dev boards. I'm also part of the Open Source Hardware Association, or referred to as OSHWA. Some people may know it, we're the organization that organizes the Open Hardware Summit.
DF (00:01:18):
And then, we also have our open source hardware certification program. I think we'll have a link in the notes there if people want to check out more about that. And then, for my job, I work for OSH Park, we're circuit board manufacturing service in the US. And I design hardware projects for them, and work with our customers that are doing educational and open source projects.
DF (00:01:40):
Also, more recently, in the last year, I started writing a monthly column about hardware in HackSpace Magazine. I think we'll have a link there in the show notes. Try and take some topics like FPGA, and RISC-V, and try and distill them down to 400 words introduction to those topics. Also, one of the people that started Hardware Happy Hour, which now is not really a great time for it.
DF (00:02:03):
But hopefully, in the future when things get back to normal, and we can meet in person. It was cool. It started in Chicago three years ago with Chris Gammell. He's been a guest many times, and another guy from a hackerspace, Andrew Sowa And now, Hardware Happy Hour is all around the world. So, that's been a lot of fun. There's been a few virtual ones. And if anyone's interested, there is a discord for that. So, you can get on there and chat with people, but it has not been a great year for meetups.
EW (00:02:35):
Yeah. And when I met you, years ago, you were at element14.
DF (00:02:44):
Yeah. It's confusing because then, the corporation I worked for was called Premier Farnell. Now, they're Avnet because they're acquired by Avnet. I worked in Chicago. So, we went by Newark Electronics. In Europe, it was Farnell Electronics. And then, while I was there, we've created a new brand called element14, which is just silicon.
DF (00:03:05):
And that may be what people are most familiar with because the products that are manufactured by them, like Raspberry Pi, and BeagleBone were branded as element14. So, it was always very confusing, because depending on where you're from in the world, I had to use one of the different names of the company around the world. That was definitely where I got really interested in electronics.
DF (00:03:26):
Earlier in my career, I've been a sysadmin, and web application developer, and I came to Newark to do that. And then, I was doing a deployment one night to our ecommerce site, and start looking at the catalog, and found a microchip. I think it was the PIC2 kit or something like that. And I was like, "Oh, this looks interesting." So, I ordered that, and then fell in love with embedded systems.
DF (00:03:52):
I enjoy the more visceral feeling of having your code control something in the real world. I think especially too, because I grew up in the era of early web development. So, everything is very abstracted away. So, it's pretty awesome to see your code control something in the real world.
EW (00:04:15):
I totally agree. I totally, totally agree. Okay. So, you're a listener of the show so you already know about lightning round. Are you ready?
DF (00:04:23):
Yes, I am ready.
CW (00:04:25):
Favorite shade of purple?
DF (00:04:27):
Oh, that's a really hard one because it's so dependent on lightning. I would say when you look at a OSH Park circuit board, whatever color purple you see there would be my favorite one.
EW (00:04:39):
What distro are you running currently?
DF (00:04:43):
I'm currently running Ubuntu on my laptop.
EW (00:04:45):
There's more to that. There're numbers or something? Numbers.
DF (00:04:49):
Oh, a 20.04. So, I guess I'm pretty recent. I guess it's October now. So, I guess 20.10 will be out soon. If not now.
CW (00:04:59):
Have you found it not traveling after living so much of your time on the road?
DF (00:05:05):
Yeah. It's been interesting. One of the things is I've actually been pretty busy still attending virtual events. In a way, I think I've maybe even gone into more meetups and events now because I'm not limited by geography, just time zone. But it will say, I think I've had more time to concentrate on deeper technical work on.
DF (00:05:29):
I've made many more contributions to the Linux kernel this year than I had in any previous year. So, I think that's been an upside to it. But looking forward to, hopefully someday, meeting people again in person.
EW (00:05:42):
This is a question I don't understand. It's from another listener. I assume there's a private joke. How is Elvis and have you seen him lately?
DF (00:05:49):
Oh, I don't-
CW (00:05:50):
That's like Ghostbusters quote.
DF (00:05:50):
I don't know. Maybe I'm forgetting something, but I'm not familiar with that.
CW (00:05:50):
It's a Ghostbusters quote. I think somebody was just being funny.
DF (00:05:57):
Is it?
EW (00:05:57):
Oh, okay. Okay. Do you have a favorite weirdest Linux computer? I know there was the Hackaday Supercon badge, but something strange like that.
DF (00:06:11):
Something strange like that. Well, I think Linux running inside a soft core in an FPGA in your badge is quite fun and weird. I will say in terms of unusual hardware, I visited a Linux kernel developer, Linus released in Sweden last year. And in his office, he has this museum of old ARM-based systems. And he had a Corel NetWinder PC, which had a strong ARM in it.
DF (00:06:42):
And one of the things he does, he's a kernel maintainer. And he makes sure that the kernel still boots on these really old ARM systems. So, we actually booted the current mainline on the NetWinder when I was there, which I thought was really funny. Also, the fact that there was a Corel PC, which I did not know that that was something they did. I think it was during the Net PC era, when your computer was just supposed to be like a thin client, but that was unusual.
CW (00:07:10):
The '90s were a weird time. Complete one project ir start a dozen.
DF (00:07:16):
I've heard many people answer this, and I don't think I have the discipline to just complete one project serially. So, I think maybe half a dozen is a better answer for me, because I think maybe I can keep on working incrementally on half a dozen. A dozen is too much, though. Now, I feel bad because I feel like I would not be able to schedule time for each of them. So, half a dozen is my answer.
EW (00:07:41):
Okay, here's the last one. What technical podcast would you listen to on your honeymoon?
DF (00:07:52):
I would say embedded.fm Would be a good choice since me and my spouse have both, well, now been on the show. So, I think that would be a good one.
EW (00:08:03):
Oh, that was funny. Because after they got married, they immediately said they were listening to the show, which I just thought I was awesome. Sorry, I'm easily amused by that.
DF (00:08:13):
I think the last time we listened together, we were on a paddle boat, on a lake outside of Berlin. So, it's a fun show to listen to while you're pedaling around the water.
EW (00:08:27):
Okay. So, someone asked for a guest to talk about Yocto. And that made me email you, because I know you're deep into the embedded Linux side. So, maybe let's start there. Although, once we got talking, I think there's a whole bunch of other stuff we should talk about too.
DF (00:08:46):
Did you... is on me like they're talking-
EW (00:08:49):
Was there a question there?
CW (00:08:50):
There was no question there.
EW (00:08:51):
What is Yocto?
DF (00:08:54):
Yeah. So, maybe a little bit more background is probably many people have, at this point, used maybe a Raspberry Pi or a BeagleBone. And both of those use more general distributions. With BeagleBone, we use Debian. And Raspberry Pi, the most popular distro, I think, is probably Raspbian, which is a recompilation of Debian to run better on the Raspberry Pi.
DF (00:09:15):
So, those are traditional binary desktop or binary Linux distributions, where you have a package manager, and you say, like apt-get such and such, and it'll install the dependencies, and you don't have to compile anything. And you can still do that on embedded systems like with the BeagleBone, and the Raspberry Pi. But when people get towards making a product, or making a system that's going to do a fixed thing, you're not doing rapid prototyping.
DF (00:09:41):
You're making a kiosk, or barcode scanner, or an autonomous vehicle, or a CNC controller, then you don't necessarily want all that extra stuff. Especially, if you're going to make a lot of the product, you probably want to have just the memory you need. Just the ram you need. Just the storage that you need. So, you want to tailor the Linux installation to just what you need.
DF (00:10:05):
So, one of the ways to do that is Yocto. Yocto is a bit of a confusing term because it grew out of another community. So, one of the ways that it's been really popular to make an embedded Linux system for many years is called OpenEmbedded. And this grew out of a community of people that were hacking on old PDAs, like the Sharp Zaurus.
DF (00:10:25):
So, out of that came OpenEmbedded, which is a collection of tools, and knowledge of how to build a Linux system that you can put into your little single-board computer that goes inside of a product. Later on, maybe 10 years ago, the Yocto project started. So, the Yocto itself is a project that is a collection of tools that lets you build your own customized Linux distribution.
DF (00:10:50):
And it uses a lot of the technology that was developed by the OpenEmbedded community. Now, Yocto is not the only Yocto/OpenEmbedded, it's not the only way of doing this. Another popular alternative, or another popular way of doing this is called Buildroot. So, I would say for people that are making their own Linux distro for a single board computer, they're probably going to either be using Buildroot, or Yocto/OpenEmbedded.
DF (00:11:14):
And I think if someone was interested in Yocto specifically, that may be because over the last maybe five years, it's become very popular for the silicon vendors, like Freescale, or TI to provide a board support package, or BSP in the form of a Yocto layer. So, a layer is a collection of what they call recipes for building different packages.
DF (00:11:45):
And that's one of the reasons why OpenEmbedded/Yocto is a nice way of building a custom Linux system is because you build up what you need. So, you'd have a layer for your board support package, which might include a kernel, a branch from the vendor, and other specific things to the hardware. And then, you'd have layers that build the applications that you need, and the libraries that you need, like maybe if you're doing a graphical interface.
DF (00:12:12):
So, you, in a nice modular way, build up these layers that give the instructions about how to take all those different projects from source and compile them. And then, either build binary packages, like RPMs, or DABs, and even produce an image that you could put onto an SD card. So, it's a nice way of creating a custom system. And I think the reason why it's become very popular is it's a really nice way for someone like Freescale or TI to provide everything you need for building a Linux system for one of their SoCs.
DF (00:12:46):
Whereas, I remember when I was at element14 seven years ago, one of the boards we had was a Freescale-base boards, and they just gave a tarball of a bunch of source code that you could compile, and put onto the system, which is not a very friendly way of doing it. So, I think Yocto has brought a nice set of tools, and infrastructure around how to build from source all the packages you need for a full system.
DF (00:13:14):
And Buildroot is similar philosophy. It is however, based on tools that people are probably fairly familiar with, which is make and Kconfig. So, Kconfig is the tool that you use for the kernel configuration options, and then make probably all of us have maybe dealt with at some point trying to get software to compile in a Linux environment. So, Buildroot is a little bit simpler.
DF (00:13:40):
So, in all, it just produces a root filesystem. So, it doesn't produce binary packages, like DABs and RPMs. So, I would say if you're just starting from scratch, Buildroot is probably a little bit easier to wrap your mind around. But Yocto is something that has a lot more flexibility. And also, the SoC vendors tend to use that nowadays to provide the support for their chips.
EW (00:14:09):
I'm always afraid of building, of even trying this. It seems insurmountable because it seems like I'm just going to make a Linux distribution that won't work at all.
CW (00:14:23):
Maybe we should talk about what Linux does. Because if you're coming from microcontrollers, you think of a firmer image, "Oh, it's got my main, and then it's got my loop, and it's all in a hex."
EW (00:14:34):
And maybe you have a second hex that's the bootloader. But you only have two, maybe three.
CW (00:14:37):
That's pretty much it. It's a binary image with your entire program on it, including the ports part, but Linux is much, much different. It's much more of a real Corel computer operating system with layers and things. Just real briefly, what are the pieces that Yocto creates that maybe people coming from microcontrollers don't think about that much?
DF (00:15:00):
Yeah. And before I forget, we'll have it in the show notes. I think one great resource is that people can pull up is, there's a company called Bootlin that does a lot of Embedded Linux development and also, training. They have a lot of training materials that are available under Creative Commons that you can download off their website.
DF (00:15:18):
And they have a course about building a bit of Linux systems with Yocto, and also with Buildroot. So, we'll have it in the show notes, check that out, they have the slides, and also the labs that you can go through that are based around, I think the BeagleBone in a microchip Atmel board as well. The other thing I think we'll put into the show notes is from the recent Yocto Developer Summit back in June, there was a nice tutorial about how to build a system with Yocto using VM.
DF (00:15:49):
So, this was quite nice. So, basically, there's a VM that you can install, it has all the tools set up, and then it produces image that you can boot with QEMU, which is an emulator. So, even if you don't have any hardware, you don't want to mess up your hardware. You can learn how to build a system with Yocto, and have it boot up, and be able to see how when you change recipes, see what the interaction is.
DF (00:16:15):
But in general, for an Embedded Linux system, yeah, there's several things that you'll need, which Yocto can help build for you, also Buildroot. One is the bootloader. And I would say the majority of Embedded Linux boards are going to be using U-Boot. That's the de facto one. The one exception to that is the Raspberry Pi is unusual, and the Broadcom SoC is unusual, and that the GPU actually access the bootloader. But for pretty much everything else, it's going to be using U-Boot.
CW (00:16:45):
Wait, what?
DF (00:16:47):
Yeah. The SoC from Broadcom that's in the Pi was meant for set top boxes, like the Roku. So, it's called the video core. And the ARM processor, at least on the original one was just an add on. So, that the main thing that boots the system is part of the video core. So, it's not like the shaders, but-
CW (00:17:09):
Sure, sure, sure.
DF (00:17:10):
So, it's unusual. Raspberry Pi is probably the most common ARM board out there. But it's a typical on the fact that it has its own proprietary bootloader or almost every other board is probably using U-Boot. So, that's something that Yocto can help you build. The next thing is the kernel. The Yocto project itself has a couple different options.
DF (00:17:33):
They have the stable Linux kernel, which is the most recent release from Linus Torvalds. And then, they have a couple other options, ones that are optimized for real time Linux. And then, there's also the category of vendor kernels as well. So, there might be a branch that TI is developing, or maintaining, or Freescale is developing, or maintaining. Usually, that's because they have support for newer hardware in there that hasn't been accepted to mainline yet.
DF (00:18:06):
Which by mainline, I mean the Linux repo that is Linus Torvalds'. Whereas, there's many different separate repositories that a lot of people maintain. But when we say mainline, we're referring to the main Linux that Torvalds releases.
CW (00:18:26):
So, when you build an application, the embedded developer is mostly going to be working on presumably things in the application layer that are post-Yocto.
DF (00:18:38):
Yeah. So, I guess in addition to the kernel, the other things that it does is the init system. So, with Yocto, you have your choice of having an older System V init system, or systemd. I think there's a couple other options as well. So, you have the bootloader, you have the kernel, then you have the init system that brings up what we would refer to as the user space, which is the application code, and the different services that might be running on the system.
DF (00:19:11):
SSH Daemon or something like that. And then, on top of that, you have system libraries. So, let's say, for example, you're building an industrial control panel, and you're using Qt or "cute" to build the graphical user interface. So, Yocto would be able to build the Qt libraries that you would need.
DF (00:19:31):
And then, on top of that, for most people, they're probably doing maybe C++, or C, or Python for the application code that probably going to provide some user interface, some networking functionality. So, that's, I would say, the way that you compose an embedded Linux system.
EW (00:19:54):
Okay. Is it better for me to take the kernel I've been given from wherever I got my board, and try to strip things out, or is it better for me to try to recompile the kernel, knowing that I'm a little hesitant about getting that right and breaking it all?
DF (00:20:14):
I think, probably the best place to start is for whatever board you have, they're probably going to point you to the repo that they compiled the kernel from. Usually, that's not going to be the upstream, the official Torvalds repo. So, for example, with BeagleBone, we have a Debian image, and we do our own kernel builds. And that's something where we take the TI.
DF (00:20:43):
Texas Instruments has their own repo of the Linux kernel, where they have some additional features they're working on in hardware enablement that hasn't been merged into the upstream kernel yet. So, it's not in Linus Torvalds repo yet, but it's in there. So, we take that, and then we build upon that. So, one of the nice things that we have for people that want to then rebuild the kernel is we have some scripts that allow you to choose which version of the kernel you want to take and compile.
DF (00:21:13):
And then, you get all basically, the setup we have, which you're already running on the image. But you can basically reproduce the kernel that's already running on the image. And the reasons you might want to be able to do that is you want to turn on a driver, or turn off a driver, or maybe enable debugging. So, there's some debugging options that you can turn on inside the kernel config.
DF (00:21:35):
So, oftentimes, someone might be having issue with particular drivers, they want to go, and recompile the kernel to turn on some extra debugging options for that driver. And you can do that by basically, it's a requirement of having Linux on a dev board is you have to point people to source code that was used to build it. So, for us, we have our own, the GitHub BeagleBoard Linux repo.
DF (00:22:01):
And from that, you can check that out, check out the branch that corresponds to the kernel that was the image that you're using, and rebuild that. Now, it can get a little tricky because if you're doing this on your PC, it's going to probably be x86, 64-bit, so you'll need to have a cross compiler. We solve that by having a little script that goes, and grabs the cross compiler.
DF (00:22:25):
So, you can build everything, you can build the kernel for ARM on your PC. Yocto is another thing that does that. So, let's say you have an SoC from Freescale. What is called in the terms of Yocto are these different layers, which are called metalayers, as in metadata. So, you'd have the meta Freescale layer that would have the information of how to go and grab the kernel source from their repo.
DF (00:22:55):
And then, you can also modify the kernel config, you can run menu config, which allows you to turn on and off different kernel features, and recompile it. And then, the most vanilla or pure approach would just to go and grab from kernel.org, grab Torvalds' repo, and just compile that. But that can be a little bit more difficult. One, you have to have hardware that's fully supported upstream.
DF (00:23:22):
So, for something like the processors in the BeagleBone, it's been out for, I think over eight years now. So, that's very well-supported in the upstream Linux kernel. But if you were to take a brand-new SoC that came out probably this year, probably the support is not in the upstream Torvolds kernel yet. So, you'd probably want to be relying on the vendor like Freescale's repo for that. And the Yocto metalayer for Freescale or TI is just a way of making that easier to do. So, does that answer what you were wondering about?
CW (00:24:01):
Yeah, yeah.
DF (00:24:02):
Okay.
CW (00:24:03):
I think so.
DF (00:24:04):
For me, for example, I do upstream kernel development on some of the drivers that are used on the SoC and the BeagleBone, like the pin control driver and the GPO driver. And since I want to submit those patches that make into the upstream mailing lists, I will just go and grab Torvalds repo. But that can be a little bit more difficult because there might be something that's different in the upstream Torvalds kernel than the vendor kernel, like the TI kernel.
DF (00:24:37):
For my purposes, I'm trying to make them the same thing because I want to make basically, possible to just go and grab Torvalds kernel, and build it for the BeagleBone, and have everything work out of the box. That's the goal, and it should be everyone's goal to make sure it all just works with the upstream kernel. So, then you don't have to have these instructions like, "Yo, you have to go make sure you grab this vendor's repository of Linux and use these kernel config options."
DF (00:25:03):
Ideally, for every board, there would just be a configuration in the Torvalds repo that says, "Okay, this is everything that you need to build Linux on this board." So, it gets a little tricky though, when it comes to stuff that's relatively new, or when it comes to vendors that don't put much resources into getting their contributions or the customizations upstream.
EW (00:25:28):
You're not making me less nervous about this though. I still feel-
DF (00:25:33):
Well, I guess, one way to make this may be less hypothetical is, is there a particular board that you're thinking about?
EW (00:25:38):
Well, I'm usually thinking about the TX2, which I know isn't a board that you have a lot of experience with.
DF (00:25:42):
I don't think you're supposed to touch that. Yeah. So, I've not used that a lot. It's a much more capable board than most of the things I work with. But I think that-
EW (00:25:53):
Okay. So, forget the Nvidia side, the Nvidia part aside, and not necessarily this board. But it has Ubuntu, I'm stuck on 16 because I have robot operating system for clients who are stuck on ROS-K, and blah-blah-blah, I'm on 16. The networking system is complicated. And I know what I want my network to be. And I've got three ways to manage it. But I just want one.
EW (00:26:27):
Because apparently, I manage it one way, and other people in my team manage it another way, and we end up with what you'd expect, which is not good. So, I want to recompile not necessarily the TX2, but if I had this problem on a BeagleBoard or something else.
DF (00:26:46):
Sure. Yeah.
EW (00:26:49):
It's just it's getting started, and then it's having the confidence that I did it right, how do I get those?
DF (00:26:54):
Well, I think Yocto is definitely the thing that was meant to help in these situations where you want to be able to customize parts of the system. And it's one of the downsides to using a full distro like Ubuntu. It's a lot more complicated. So, in the case of Nvidia, there probably is an Nvidia metalayer for those SoCs.
DF (00:27:17):
I usually use Freescale as an example or TI because they're really common in the industrial embedded Linux space. But the whole point there is that from the vendor's metalayer that that has the configurations in the repos for the kernel and other things. But you can do things, you can change the init system, you can change for a GUI, what the desktop system you want to use, what session manager you want to use.
DF (00:27:46):
So, it gives you a lot more control over that. Maybe you don't want to use systemd, maybe you wanted to use a different init system, or network manager. When it comes to network managers, there's a lot of different ways of doing it. On Beagle, we use something called ConnMan, which works quite well for us. And it's lighter weight-
CW (00:28:11):
That's an encouraging name.
EW (00:28:13):
ConnMan, yes.
DF (00:28:14):
With two Ns, which is I guess hard to hear when you say it out loud. But it's simpler than the GNOME network manager, which can be quite complicated, or system-networkd. So, there's a lot of different ways of configuring your network.
DF (00:28:28):
And when you get a distro, like Ubuntu, they typically choose away, and then it can be difficult to do in an alternative way, a distro like Ubuntu. So, that's one of the nice things about Yocto is let's say, you want to use ConnMan, or do you have a particular network manager that you are wanting to use?
EW (00:28:52):
The one that was on the Solaris V machine, that I did when I was-
CW (00:28:57):
SunOS.
EW (00:28:59):
SunOS.
CW (00:28:59):
Solaris was the terrible-
DF (00:29:00):
There might be something that deserves semantics like that.
EW (00:29:02):
I just want to use basic one. I don't really care what it is. I just it wanted to be super simple.
DF (00:29:08):
Yeah. Look at ConnMan. That's what we use on the BeagleBone. There's also, if you're using a systemd-based system, Debian is now by default, and also Ubuntu, there's system-networkd, which is common for people to use as a network manager, or you can even not use one at all. Using a system like Yocto, you have control over that.
DF (00:29:31):
So, you can choose a layer, which is a collection of recipes for building the code from source that gives you the network manager you want, or no network manager. Maybe you don't want a network manager, and you have your own scripts that do it manually. So, that's also an option as well. Versus, I think with a distribution like ubuntu, they have chosen a way that they think will work for most cases, and maybe for general cases, but it might not be right for your embedded system.
EW (00:30:07):
For me, it's often that I want to get rid of things because I have this idea that they add complexity in the operating system. And so, I just don't want them. And I want to be able to strip out everything. And is that a reasonable thing?
DF (00:30:25):
Yeah. That's ideally what you should be doing for an embedded system, stripping out all this generic stuff, just using what you know you need right for your project or your product. So, that is what Yocto and OpenEmbedded, give you is the ability to like, they call them layers, which is a collection of recipes, which are basically, where to grab the source, and how to build it, and how to configure it.
DF (00:30:49):
So, there'll be layers that you could probably grab to have a minimal network manager, ones that are meant for no GUI, ones that are meant for a lightweight GUI, or maybe a full good GNOME desktop. So, I think if you look at the Yocto for the board that you're working with, you'll probably find a lot of different options for doing that.
DF (00:31:18):
The other thing I wanted to mention before I forget is coming up next week is the Embedded Linux Conference Europe. And as part of that, there's the Yocto Developer Day, which is a bunch of both presentations, and there's also a Slack chat for it. So, it's a good opportunity to talk to experts, and people that are using Yocto and OpenEmbedded to build products.
DF (00:31:45):
And the upside to the pandemic is the Embedded Linux Conference, which is put on by Linux Foundation. It's only $50 to attend it online, which typically these Linux Foundation conferences are might be $500 and $600, plus hotel, and travel, and all that. So, it is a good opportunity to talk to people that are doing this on a regular basis, building products around it. It's big enough that you'll probably find someone that's already working with the board that you are.
EW (00:32:18):
So, that is the Embedded Linux Conference Europe, and that is October 26 through 29th of 2020.
DF (00:32:26):
Yes.
EW (00:32:27):
And the Yocto Project Virtual Summit is October 29, 30, of 2020. So, that's what next week is.
DF (00:32:36):
And I would say, a lot of my knowledge of Embedded Linux, or than just using it has come from the Embedded Linux Conference over the year, which is put on by the Linux Foundation. So, they have North America and Europe every year. And eventually, they get all the videos up on YouTube. So, that's why I would encourage people if they can to attend it live.
DF (00:32:57):
Because it usually takes several months to get the talks up. And also, we did this one prior time, which was Embedded Linux Conference North America back in June. And it was a really great Slack instance for that with channels for all the different talks. And usually, great to connect to other people that were working on similar systems, and can I answer questions that I had.
DF (00:33:20):
So, I think it's well worth it. And in terms of the past 10 years, I think of this conference are all up on YouTube. So, for any Embedded Linux Conference, or any Embedded Linux topic, you can probably find several talks about it. And because I would say it's really tough to... well, you've written a book about embedded systems.
DF (00:33:42):
And I think you had information in it that was not tied to a specific version of software. But we don't have a lot of books that kept up-to-date about Embedded Linux, because it's changing so rapidly. So, that conference talks are really one of the primary forms of documentation, I think. For whatever area of Embedded Linux, people listening to this might be interested in, I would recommend checking out the Linux Foundation's YouTube.
DF (00:34:10):
Because ELC, the Embedded Linux Conference, I would say is one of the primary sources of information to figure out how to do things with Linux on embedded systems, and also figure out how people are solving these challenges, which we probably all run into at some point in time trying to get Linux to do what we want on a little board.
EW (00:34:31):
So, moving on to conferences, you've always been someone who... following your Twitter feed, you are here, and then there, and this conference, and that conference. And I'm somebody who really didn't leave home before it was required. It's amazing how many conferences you go to, which ones have made the best switch to remote?
DF (00:34:58):
Definitely, I think the best experience I've had so far is a conference called Linux Plumbers. So, a fun take on the idea of like low-level software. So, Plumbers have been going out for, I think, maybe 10 years now. I only started attending it maybe five years ago. But one of the main tenants of Plumbers is that a lot of the presentations there are supposed to be rather short.
DF (00:35:25):
And then, a lot of it is supposed to be discussion. See, my kid, a lot of people that are involved in a particular piece of software, and they all get together. And you might have people from the GCC or Clang team, and you might have kernel developers, and they're all in one room. And someone gives a little presentation on something they're working on.
DF (00:35:46):
And they say, "Okay, but what's a way for us to solve this that all the different stakeholders are happy with?" So, it's one of those conferences where the in-person thing was quite important. It wasn't just giving a half an hour-long presentation. It was meant to be really interactive. And they put a lot of effort into it this year to try, and because they had about six months to get ready, because it was in August.
DF (00:36:13):
I think they made a decision by April probably, that it was going to be virtual. So, they chose BigBlueButton, which is a piece of software that I think originally came out of CERN, essentially, a video conferencing/presentation platform. And it works really well with multiple people wanting to speak. So, this thing where it's like a discussion session, and you might have four or five different people that are going to be talking almost at the same time.
DF (00:36:44):
It works really well for that. And then, along with that, we had a Rocket.Chat instance, which was good for more in-depth chat. You could take it over to a channel in Rocket.Chat. And for people that are not familiar with Rocket.Chat or BigBlueButton, the reason why they chose those is they're free software.
DF (00:37:02):
So, they are able to set up, I think on Linode, all this infrastructure. And the entire conference was done with only free software, which I thought was pretty cool. So, we weren't stuck on a proprietary cloud system like Slack, or Zoom, or something like that.
EW (00:37:22):
What other conferences have you been going to, and what talks have you been giving?
DF (00:37:26):
So, we've already had the Embedded Linux Conference North America, which was probably the longest one that I went to. Because it was a good maybe six, eight hours a day for four days. Not that you have to do the whole thing, but I enjoy it. So, I was on for most of the time, and that was a real positive experience.
DF (00:37:48):
In this case, the Linux Foundation was using Slack. And that served as almost the same experience of hanging out in a hallway, or going down, and getting some food with people after talks. Not quite the same, but it opened up the opportunity. So, there's many times where I'm maybe thinking about an issue, or have an idea how to solve a problem.
DF (00:38:11):
It's not the thing where I would go post it on the mailing list, because it's not really that formal. But when we're in a more relaxed environment, like chatting in person, or in this case, chatting on Slack, I can say like, "Oh, I see the maintainer of the GPIO subsystem in Linux is on there." I probably wouldn't email him thought this, but we're just hanging out at the virtual conference.
DF (00:38:32):
So, I asked him some questions. And actually, it was really great because it helped me get on the correct path to solving the problem that I was thinking about. And I think I don't know if I would have posted to them, unless it's a formal thing, trying to ask for guidance. So, it's those more informal interactions, I think, are the really great part of conferences, and some of them have done a good job of that.
DF (00:38:57):
Some of the other things I've been involved in are just more one way, where it's someone giving a presentation over a Zoom, or YouTube live streaming. There's not as much ability to interact. So, it depends. One of the events that I was a part of, about a month and a half ago, was called the RISC-V Global Forum. So, it was also really interesting, a lot of good presentations.
DF (00:39:22):
And for that, they also had a chat channel for each talk, where you could go in, and ask questions afterwards. The upside to that is normally, if you had a physical conference, you're eventually getting shoved out of the room, because the next talk has to come up. And in this case, you can continue talking about the subject in a chat channel, instead of having all run out to the hallway, and maybe get dispersed.
DF (00:39:47):
So, I think it does allow for more continued focused discussions after a talk. I didn't put it in the notes, but we can add it in there. It's coming up in December is the RISC-V Summit, which the big annual RISC-V conference. So, people can register for that, if they're interested. I think it'll be quite a good conference. It was supposed to be in San Jose, but now, it's just virtual.
EW (00:40:13):
Are people attending these conferences in greater numbers, lower numbers? I haven't been because I spend way too much time in front of my computer already. And I look at them, and I think, "Oh, that would be fun." But then I also think of, if I'm in front of my computer, I'm probably not as happy as if I was not.
DF (00:40:37):
Hard to know. I know for Linux Plumbers, it's a smaller event. So, it's usually bounded by the space that it has, which is usually only enough for 300, 400 people. So, I know in terms of Linux Plumbers, I think they had well over maybe 1,000 people register. So, it did allow more people to get involved. Some of the other ones, they haven't published same stats, I'm not quite sure.
DF (00:41:05):
But these Linux Foundation events are usually pretty large in person, a couple thousand. So, it's hard to tell, but there was always enough people around to have relevant conversations. I do get, though, a lot of people have mentioned the fatigue thing, that in some ways, sitting at your computer, watching talks for eight hours is a little bit more draining than being in a hotel conference center.
DF (00:41:32):
Being able to chat with people person-to-person, I definitely after some of those days, the Embedded Linux Conference, I've been typing a lot, and sitting at my computer for 10 hours. So, it can be a bit exhausting. But I also get really excited when I get to interact with people and discuss ideas. So, I prefer to do it in person. But I think I'm really happy that the organizations were able to figure out how to do this online, and in a pretty quick fashion.
EW (00:42:05):
So, RISC-V, you mentioned that as both that there's an upcoming conference, and something you talked about recently.
DF (00:42:14):
Yeah.
EW (00:42:16):
I've been hearing about it for years.
DF (00:42:19):
Yeah. So, you want me to give a bit of an overview of it?
EW (00:42:24):
I guess so. And why would I want to look at it? In what cases is it interesting, and in what cases should I be looking at more traditional processor cores?
DF (00:42:37):
Yeah. So, just to give a little background. Probably, people may have seen the term thrown around. And a lot of times, it's just used synonymous with the idea of an open processor. But it's a little bit more nuanced than that. So, RISC-V itself, its RISC with a V. So, it's the fifth, but reduced instruction set computer or RISC architecture to come out of Berkeley.
DF (00:43:03):
So, about 10 years ago, people on the computer architecture research group at Berkeley, they were looking for a new instruction set to base their research projects on, like looking into custom accelerators, and things like this. And they didn't want to go to the bother of licensing a commercial instruction set, like our x86.
DF (00:43:25):
So, they decided to just take the knowledge they'd already have from doing the previous generations of RISC instruction sets, and just make a new one from scratch in a clean slate design. An idea behind it was that it was something that would be modular and extensible. So, it was something that scale from small microcontrollers, all the way up to supercomputers.
DF (00:43:48):
Well, the joke from one of the people involved is I say, like, it's one instruction set to rule them all. The idea being is that the instruction set should not be the thing where you're innovating or differentiating. It should be something that's almost boring. And it should be something that you're able to build upon in layers of functionality as you need them.
DF (00:44:13):
So, and just to go back to what an ISA is, the instruction set is just basically the specification or standard of the task that the processor can perform. So, RISC-V itself is just an open specification for an instruction set. It's actually a group of instruction set that specifies everything from a small 32-bit system all the way up to a 64-bit system with an MMU, and you can run a full operating system.
DF (00:44:44):
And even, there's extensions with things like vector operations and stuff like that. So, you don't need to have all that though. So, the bases is just a 32-bit integer ISA. The other important concept is that after something is frozen, it won't change. So, for example, the base 32-bit integer ISA for RISC-V is frozen. So, if you go, and write a program, and compile it for 32-bit integer RISC-V, it'll run on a processor right now.
DF (00:45:16):
But it'll also run on some 128-bit RISC-V supercomputer 30 years from now, because it's fixed. But things extensions for vector operations, they're still being worked on, and eventually will be ratified. And then, if you compile a program for that, it'll still work on a compliant RISC-V core 10, 20 years from now. But that's just the instruction set. So, that's just specifying the task that the processor can perform.
DF (00:45:47):
But it's not the implementation. But I'm really interested in open technologies, and hardware, and in order to have a complete open source processor, we need to have an open instruction set. So, I couldn't go and design a processor that implemented ARM or x86, and distribute that to people. Because that would be infringing upon those proprietary instruction sets.
DF (00:46:11):
So, RISC-V allows us to build fully open processors, but it doesn't mean that it's open just because it's implementing RISC-V. But if you wanted to get more into why would you use it, and why wouldn't you? So, one of the advantages is, especially in the embedded space, ARM is really common. And a lot of companies license ARM cores, like the Cortex-A8 or the A53.
DF (00:46:38):
And most companies that are doing that are just licensing a specific core, they don't have the liberty to do their own implementation of the microarchitecture. Only a few companies do that, like Qualcomm and Apple. They're architecture licensees have ARM, whereas everyone else is just TI's licensing, like a Cortex A53. But if the company like TI wants to differentiate themselves with changes to microarchitecture, they can't really do that.
DF (00:47:08):
Whereas, with RISC-V, you're open to implement the microarchitecture the way you want. So, an example there is Western Digital is actually fully committed to RISC-V now. In the feature, all of their drives, all their storage products are going to use RISC-V based controllers. And the reason for that is they wanted the freedom to be able to do their own micro architecture.
DF (00:47:34):
In this case, they've actually developed something called the SweRV core, which has two... it's a microcontroller with two hardware threads, which for them, allows them to have much greater performance for their storage product. So, having an open standard that allows companies to implement the way that best suits their use case is quite powerful.
DF (00:47:55):
The other big thing is that RISC-V is not the only open instruction set out there. There're other ones like OpenRISC that are also open instruction sets. But it's the one that has critical massive software behind it. So, instruction set is not worth a whole lot unless you have a whole massive software behind it, like toolchains and operating system. So, we have GCC, and clang, and glibc, Linux, and all that's all supported on RISC-V.
DF (00:48:20):
So, you also get all the software you need on it, which is the main reason why we're still using x86 because we just have too much software that was written for it that we're stuck with this 40-year-old instruction set that doesn't make a lot of sense.
CW (00:48:35):
So, is it better for people who are looking at okay, I want to roll a custom silicon, and I want more control over the architecture and the ISA, or is this something that's currently a choice that say, somebody who's designing in a microcontroller would want to explore?
DF (00:48:56):
Yeah. There's, I think a lot of nice examples of things people are doing with RISC-V in the microcontroller space. And that's partly because it's easier to experiment with microcontrollers. Because they're smaller, they're less complex, so that the cost to do the verification, and to get chips produced is much less than a full SoC that can run something like Linux.
DF (00:49:23):
But there are several companies that are doing interesting things with low-power RISC-V based microcontrollers. Some of the work comes out of ETH Zurich, which is a university in Switzerland. And they have several of their own RISC-V open implementations as part of a program called PULP, which is Parallel Ultra Low Power.
DF (00:49:49):
So, they focus a lot on making power efficient RISC-V cores that then companies are going and putting into things. So, there's a company called GreenWaves Technology, and they have some really low-power microcontrollers for doing sensor management. And they're able to leverage these low-power RISC-V open source RISC-V cores from PULP team, and then add the things that they need for their own use cases.
DF (00:50:20):
So, it gives them a lot of flexibility in that. I'd say the other practical consideration is we're starting to see a lot of risk five microcontrollers coming out of China. And one of the reasons is with political tensions. Over the last few years, there's been a lot of concern over the ability to continue to license ARM cores. So, several Chinese companies are exploring RISC-V as an alternative.
DF (00:50:47):
Probably, the cheapest RISC-V microcontroller you can buy right now is from a company called GigaDevices. You may be familiar with them, because they were the company that did a register compatible implementation of STM32. So, you could basically have a really low-cost chip that had the same register map as the STM32. They have really low-cost RISC-V cores called GD32-V, I think, it is.
DF (00:51:17):
So, definitely in the microcontroller space, there's a lot of different interesting things coming out. The other place for RISC-V can be really useful is for companies that are taking a microcontroller, and then putting a custom accelerator alongside that. So, it might be something, especially for machine learning where you want to accelerate inference on a smaller device.
DF (00:51:38):
So, one of the other companies as part of the RISC-V International is Andy's out of Taiwan, and they do a lot of their businesses making RISC-V cores that can be integrated into custom ASIX that customers are making where it has special acceleration for sensor fusion, or neural network inference. And then, they also want the RISC-V core there to do general computation, and have a core that's well supported by tools.
DF (00:52:07):
Because before RISC-V, a lot of these companies had their own cores, which means they had to maintain their own tool chains, do their own ports of real time operating systems and Linux. So, RISC-V saves a lot of that work. So, you can have your custom hardware, but as long as you are still using the RISC-V instruction set, you have the software compatibility there.
CW (00:52:32):
Okay.
EW (00:52:35):
So, Linux on RSIC-V. You mentioned that with respect to the Hackaday badge, are there other ways to explore Linux on RISC-V?
DF (00:52:48):
Yeah, there are. I would say actually, the first thing, it's a little bit boring for us embedded people, but the easiest thing is actually to go get an emulator. So, RISC-V works perfectly well in QEMU. And also, in another emulator called Renode, which I really like. So, even if you don't have any hardware right now, I guess I'll recommend Renode. It's from a company called Antmicro.
DF (00:53:15):
It's an open source project in emulator that basically, you can say okay, I want to pretend I have this RISC-V development board, it emulates all the hardware that you'd have on there, including the networking. And you can go and run Fedora, or Debian, which both have RISC-V ports on that, say, there's company called SiFive that has a pretty high-end Linux development board.
DF (00:53:38):
So, you can emulate all that on your PC right now. But that's only limited fund, because it's not real hardware. So, one of the issues when it comes to Linux on RISC-V is in order to have a system on chip or SoC that's capable of running Linux, it's a lot more of an expensive proposition. So, we haven't yet seen a lot of options for that microchip, has finally launched the system on chip that has a hard RISC-V core in it, called the PolarFire SoC.
DF (00:54:08):
And they have a dev board called the Icicle. And that just started shipping from crowd supply. It's a bit expensive, though. It's $500 because it also has an FPGA in it. I think next year, we'll see a lot more options in terms of lower cost, maybe around $100 dev boards that can run Linux on RISC-V in an actual ASIX hard core inside of an SoC. And hopefully, one of those will be Altoids shaped and dog friendly if things work out.
DF (00:54:40):
But for right now, probably one of the more practical options to run Linux in RISC-V is to use an FPGA. So, the idea with using FPGA is you can actually have what's called a soft core, or you can figure out the gates inside the FPGA to represent the implementation of a RISC-V core. So, you can actually run inside that soft core, Linux inside an FPGA.
DF (00:55:04):
And one of the ways that this gets even easier, is there are now several FPGAs that are supported by open source toolchains. So, when I first started using FPGAs, maybe 10 years ago, I was using Altera Cyclone, and you had to install this awful IDE in a Windows, and took up a lot of space, and they're still just as bad. Xilinx is 50 gigabytes I had to install.
DF (00:55:33):
So, there's been a lot of movement in the last couple years of basically, there's this great open FPGA community. And they've been working very hard on documenting the bitstreams. And then, producing tools that are open source that can do the same things like the synthesis, and the place in route that the vendor tools are doing. The ones that work really well right now are for FPGAs from Lattice.
DF (00:56:01):
So, the iCE40, and the ECP5. The iCE40 is a little bit smaller. So, you can do things like have a soft core for a microcontroller inside of it. And I think we'll have in the show notes, one board for that is called the iCEBreaker. And another one is called the Fomu. That's a little tiny one that can fit inside your USB port. But those are both great if you're interested in learning about FPGAs.
DF (00:56:28):
And also, don't want to have to deal with the proprietary tools. That's really nice. Hackaday SuperConference, and also, at Crowd Supply Teardown last year, there was workshops. And the nice thing about the free tools is they can just give you a small USB key thumb stick, and you can put in your computer, and you can get everything up and running. And you don't have to install 50 gigabytes just to use the FPGA.
DF (00:56:57):
So, that's really nice. Now, in order to run Linux, we need a little bit bigger FPGA than the iCE40. So, that's where the ECP5 from Lattice comes into play. And more recently, people got free software toolchain working with that. So, what was on the Hackaday SuperConference badge last year was an ECP5 FPGA. So, during the course of the conference, we were able to get Linux running on a soft core inside that ECP5.
DF (00:57:26):
And the project we used particular, we'll link to this in the show notes, is called Linux on LiteX-VexRiscv. So, it's a bit of a mouthful, but LiteX is this set of different IP, which is what hardware chip level people refer to as basically peripherals and libraries for chip design. So, things like DRAM controller, Ethernet controller, USB Controller.
DF (00:57:56):
And then, VexRisc is an open source implementation of a 32-bit RISC-V core. So, those things all together give us basically a full system on chip inside the FPGA that can run Linux. And it's all wrapped up into a nice repo where you clone it. And then, you run the build script, and it produces a root filesystem, and a kernel, and even the script that will then go unload that into the FPGA.
DF (00:58:27):
And there's several different FPGA dev boards, including the Hackaday badge that are supported by it. So, you can get one of those boards, which I would recommend a board called the OrangeCrab, which is from an awesome hardware hacker named Greg Davill, who many listeners may have seen on Twitter with. It's beautiful, photos of PCBs.
DF (00:58:49):
Earlier this year, he came up with a board through GroupGets. That's Adafruit Feather form factor with the ECP5 FPGA on there. And that's fully supported by the LiteX project. So, you can get one of those boards and clone that repo. And in a few minutes, you'll have Linux booting inside a soft RISC-V core inside the FPGA using only open source tools. So, I think that's really fun and really powerful.
DF (00:59:21):
The ECP5 is not the highest end FPGA. So, that it's going to be running at more like 50 megahertz to 100 megahertz, which is probably slow for a lot of us. It reminds me more of my PC from the '90s. But one of the cool things when it comes to FPGA is, well, the software might be limited in terms of clock speed. There's a lot of room there to implement custom peripherals.
DF (00:59:45):
So, let's say you want to do something where you're reading from sensor and normally, you're having to continue to pull some value, and check to see if it's changed. And you're reading a bunch of cycles on the core, that way, you could also maybe implement a peripheral that did that for you. So, let's say you have a motor encoder. And normally, you have to have interrupt fired and look at if it's changed, if it's rotated.
DF (01:00:14):
But you could also implement inside the FPGA, a peripheral that did that for you. So, Tim Mansell is someone that speaks a lot about the power of these open source tools and FPGAs. And while they're not as fast as the ASIX as a hard core, we have the flexibility to tackle the problems from a different angle. Rather than having the software run really fast on a fast core, you might put some of that complexity into the peripherals that are defined inside the FPGA.
DF (01:00:49):
I think the quadrature pulse decoder is a good example of that. Where normally, you have to make sure your CPU is running fast enough, and not getting interfered by other software build to accurately comp the pulses, or you could define some hardware logic that did that for you.
CW (01:01:08):
Yeah, and I've done that.
EW (01:01:10):
I've done it both ways. And definitely having the chip there is the way to do it.
CW (01:01:15):
And having your quadrature decoder on the FPGA, and then a counter that the thing reads was really nice.
DF (01:01:19):
Yeah. So, I think those are good examples. Because if you get a board like the OrangeCrab, and you get Linux on there, 100 megahertz isn't super fast. But you can now if you have a bigger FPGA, you can actually have multiple cores. But it's like, maybe instead of having a CPU running at a gigahertz, what you need is a set of custom peripherals, or things like software PWM.
DF (01:01:44):
On a Raspberry Pi, you can bit bang PWM, or with a much slower core and FPGA, you could have a bunch of different hardware blocks that generated the pulses. So, there's a bit of a different way of tackling the problems. But I think the key thing here is, we now have open source free software tools that allow us to do FPGA development, free of the awful vendor tools.
DF (01:02:09):
And also, now there's more and more open source IP, which is to say, the building blocks, so things like Ethernet controller, DRAM controller, even things like USB 3 controller, and PCI Express controllers, you can drop into that FPGA. And in particular, one of the things that Tim Mansell talks a lot about, is using Python for chip design. And that is possibly because of this framework called [Median 01:02:33].
DF (01:02:34):
And that's what we are using inside of that Linux on my next project. So, if you actually dig into it, what it is that actually Python code. So, it's not very long, it's not VHDL, it's actually Python code. And that was really useful. So, me and several other people, we sat down at SuperCon, and we were like, that's good. Linux putting on the badge by the end of the weekend.
DF (01:02:55):
And I think what really helped us do that was by using LiteX and Median. It was not Verilog that we're looking at, it was Python code. So, for example, we had a DRAM chip on the board that wasn't already supported in LiteX. But we were able to just inherit the Python class for the DRAM chip, and then changed some of the parameters based on the timings, and the datasheet for our DRAM chip, and then it worked.
DF (01:03:21):
So, we didn't have to sit down and write our own DRAM controller in Verilog. And I think, especially for me, I don't come from a chip design background. But I'm very familiar with Python. It was much easier for me to look at, and also leverages object-oriented nature of Python. So, I think things like LiteX and these open FPGA tools are really opening up chip level design to a lot more people.
EW (01:03:48):
There's so much you've shared. My brain is exploding with ideas, and Linux, and FPGAs. But you do have one more major role in your life, and that's OSH Park. You work for them. A, what do you do for them? And B, how is OSH Park doing?
CW (01:04:12):
I design, open source hardware projects. Some of the bigger projects that I've worked on over the past couple years was conference badges for the Open Hardware Summit. So, back in 2018, we did a fun e-paper badge that had an ESP32 on it. So, you could connect to it, and change what it said on the screen. And worked with a couple of people from the community on that, Michael Welling and [Alice Camilo 01:04:40].
CW (01:04:39):
And that was really cool example, I thought of using online collaboration. So, when it started, I just posted on hackaday.io, which is awesome site if you're working on hardware projects, and like, "Hey, we're going to make the badge for the Open Hardware Summit this year, and started going through some different ideas." I got feedback from people like, "What should I do for the battery? What wireless should I use and these sorts of things?"
CW (01:05:09):
And one back and forth for a while, we thought about using the Rigado Nordic module, and then ended up going with the ESP32. So, it was a really nice way to go back and forth. And on that project ended up getting several people involved from around the world working on it. So, that was a lot of fun and learned a lot. And in the end, ended up having to stay up all night and program all 300 badges before the event.
CW (01:05:36):
But it was rewarding and fun. And everyone was excited about it. Because one, it was a paper, and two, we actually had MicroPython running on it. So, you could actually write little Python programs, and transfer them over WiFi onto the badge. Some person made a magic eight ball app, because there was an accelerometer on there. So, you could shake it, and it would give you a different answer.
CW (01:06:00):
So, for the most recent Open Hardware Summit 2020, me, and Michael, and Alice, we got the group back together, kicked it off at SuperCon got some people into a room, and discussed ideas for badges. And this started worked out really well. It was a great collaborative project for OSH Park. We made the boards, and SparkFun did the assembly. And actually, it was great.
CW (01:06:27):
Digi-Key, actually, because after 2018, I talked to some people from Digi-Key they're like, "If you do this again, just let us know. We'll give you parts. Oh, cool." Because that was the main reason I didn't go with the Rigado Nordic module because it was a bit more expensive than the ESP. So, for the 2020 badge, we decided to go with a wristwatch form factor inspired by... in Germany, there's this hacker camp called the Chaos Communications Congress.
CW (01:06:56):
And every year, there's this convention, and every four years, they have this big hacker conference or camp. And they have these cool wristwatches that had Bluetooth on them, and a little OLED. So, we thought that was really neat. So, we made our own version for the Open Hardware Summit. Unfortunately, the Open Hardware Summit ended up being virtual this year.
CW (01:07:14):
So, it was supposed to be the second week of March. So, it was a very difficult time to know if we should do it or not. And we ended up canceling it. So, all the badges are still unfortunately at NYU, but eventually, we'll be able to send them out to the people that were registered. But yeah, that was a great example of a project, where got some people together from around the world.
CW (01:07:39):
And we all collaborated on the open hardware project, which produced a fun little Nordic based circuit Python running wristwatch that people will be able to hack on, when they finally get them. The only things I do with OSH Park is I'm very passionate about KiCad. And after the conference earlier this year called FOSDEM, there was a developer day there, and I've gotten more involved in KiCad development.
CW (01:08:08):
And it's really fun to run the development version, and see all the features that are getting added, and trying adding some of the things that I've been wanting to see in there. One of which is we have this really fun black circuit board, which we called After Dark. So, fiberglass is normally tan color. So, we're about to find fiberglass that was dyed black.
CW (01:08:36):
And then, we use a clear solder mask over it, which means you can see all the circuitry. So, you see the copper traces everywhere. They're protected by the solder mask. So, it's a really nice aesthetic. It's pretty interesting because you can see all the routing on the circuit board. So, we call this After Dark. And one of the things I was working on this year was trying to figure out how to render that correctly in KiCad.
CW (01:09:00):
Because it didn't really have the concept in there of how to differentiate between copper that was under a clear mask, which it looks like normal copper color versus when it's not underneath the solder mask where it's plated with gold finish. So, that was an interesting thing to work on it. And eventually, with the help of one of the KiCad developers is now able to render that correctly.
CW (01:09:27):
Which hopefully, we'll link to in the show notes, but the Hackaday SuperConference badge around Linux, the reason I was able to do that was there was a little board in the back that had a DRAM chip on it. And that board was done in After Dark. So, you can see all the little traces between the chip and the connector on it.
CW (01:09:47):
The other thing that's been new, mostly almost going on two years now, but it's an interesting journey to learn more about it is flexible circuits. So, about two years ago, we started offering two-layer flex in a small quantity. So, you can get for $15, a small flexible circuit board, which has really opened up, I think a lot of ideas for experimentation. One of the things I've been working on... so, unfortunately, a lot of my ideas are based on conferences.
CW (01:10:18):
So, one of my ideas was a little LED, or a little battery tester. So, the idea is you have a little flexible PCB that wraps around both ends of the battery, maybe a coin cell or a double A. And then, it can light up an LED to show if it has charged left in or not. So, that was interesting, because by using cutouts in the PCB, you can allow it to better wrap around the battery.
CW (01:10:42):
So, that's a fun thing that I've been iterating on. Though, yeah, unfortunately, a lot of my hardware projects have been based around business cards or conference badges. So, it's been a bit of not been as much of a need this year for that. But definitely, but I've been getting a lot more involved in KiCad, and I think with version six, which will be coming out towards the end of the year.
CW (01:11:06):
It's really getting to the point now where it's as capable as professional packages, I think like Altium. And I think definitely, for people using Eagle, it has a lot of the capabilities that people might be used to in Eagle.
EW (01:11:21):
Drew, I'm sure that you could go on, and I have more questions from listeners, and from myself. But I am in need of lunch. So, do you have any thoughts you'd like to leave us with?
DF (01:11:36):
Yes. One thing I did not mention, which is the most exciting thing I've seen happen in 2020 so far is, and hopefully we can link to it in the notes is, it's not possible to design a completely open chip all the way down to the transistor level. And this is because of a project at Google in a fab called SkyWater in Minnesota where they've opened up a process development kit, which is the most specific sensitive details of how the transistors are made.
DF (01:12:09):
So, that's all open now. In addition to that, they also, if you design an open source chip, they will manufacture it for free as part of these free manufacturing rounds they're doing. So, if you put a link into it to Tim's talk, Tim Mansell's talk, but really exciting. You can now make a system that's completely open all the way down to the transistor level, the atoms that are constructing the gates level.
DF (01:12:37):
And I think that's really exciting. That's new. We've never seen that before. So, I think we're going to see a lot more interesting things happening in terms of open source chip design.
CW (01:12:47):
Awesome.
EW (01:12:52):
It has been wonderful to talk to you. Our guest has been Drew Fustini, Embedded Linux developer, board member of BeagleBoard.org Foundation, and open source hardware designer at OSH Park.
CW (01:13:04):
Thanks, Drew.
DF (01:13:05):
Yeah, thank you.
EW (01:13:07):
Thank you too, Christopher for producing and cohosting. Thank you to our Patreon listener's lack for some questions, and for Drew's mic. And thank you for listening. You can always contact us at show@embedded.fm, or at the contact link on embedded.fm. And now I thought to leave you with. Mostly for the US folks, vote. I don't care what you vote for, just vote.
EW (01:13:31):
Embedded is an independently produced radio show that focuses on the many aspects of engineering. It is a production of logical elegance, and embedded software consulting company in California. If there are advertisements in the show, we did not put them there, and do not receive money from them. At this time, our sponsors are Logical Elegance and listeners like you.