Embedded - 45: Yanking on a Cat's Tail Is the Only Way to Learn

Episode Date: April 2, 2014

David Anders (Google+) joined Elecia to chat about open source hardware, what it means, how to do it, and why.  Dave will be speaking at the embedded Linux conference in San Jose, CA on April 30th: 9:00am: Panel: IoT and the Role of Embedded Linux and Android 4:20pm: Hardware Debugging Tools 5:20pm: Debugging - Panel Discussion  Open Source Hardware Association describes the gradient of open source hardware. Sigrok looks at open source and open source friendly tools Dave works for CircuitCo, manufacturers of the mysteriously elusive BeagleBone Black. While he didn't explain their absence (other than they are super popular for OEM'ing), he did announce the brand new Intel-based MinnowBoard MAX. Some open source tools we discussed included Tin Can Tool's 40 pin DIP Linux processor, Flyswatter, and Flyswatter 2. Also, check out Dave's past eLinux presentations.

Welcome to Making Embedded Systems, the show for people who love gadgets. My guest today is Dave Anders. We're going to talk about debugging widgets, especially open source debugging widgets. Hi, Dave. Thank you for joining me. Greetings. Allison Chaykin connected us together after she was on the show to talk about cars. But you and I have never met. How do you think she'd introduce you?

Well, Allison would probably introduce you or introduce me a little bit different than I would introduce myself. But Allison probably would describe me as one of those weird people that do hardware and software on a very low level. And while there's a lot of people that do hardware, and there's a lot of people that do software, there's a small niche of us that do a little bit of both in between there. And I think that would probably be how she would introduce me. What about you for yourself? Well, I would say myself that my skill is learning. And I do work with hardware and software. But my biggest thing is I don't care whether it's hardware, software, procedural, manufacturing, design, all of those things go together to create a product. And my skill is learning what needs to be learned to either solve a problem

or get a product to market. And that's really my skill. Well, I think that's a good one. I mean, I think that's one I definitely would. I don't know that I'd rephrased it that way. But yes, I totally agree with you. But what about your career? Where are you now? I'm currently working with CircuitCo. They're a manufacturing and engineering company based out of Dallas, Texas, most notably known as the primary manufacturer and developer of the BeagleBoard products, including the BeagleBone Black. And we also have the MinelBoard products, including the BeagleBone Black. And we also have the MinnowBoard.

And we actually have several other projects that we're working on that will be released in the next six months that are all open hardware-based products. So the BeagleBone Black, I feel like I should just ask that. When will they be available again? We're actually ramping up production. We were initially doing about 2,000 boards a week, and we're actually ramped up to about 7,000 a week. And we are starting to catch up with a lot of the backorder demand for it, but we were just really caught off guard towards the end of December as well as for the amount of demand.

And we have a lot of OEM manufacturers that are using the BeagleBone plaque in part of their product, and that demand has simply just skyrocketed. Well, that's great, although if they hadn't been out of stock, I probably would have one right now because I finally have time to work on it. Have you used the Raspberry Pis? I have evaluated them. It's just common course for my line of work

to evaluate all the different boards out there and what kind of features are available on them. And so yes, I have evaluated the Raspberry Pi. And which should people buy, the Raspberry Pi or the BeagleBone Black? Because they're pretty similar, right? They're very similar, but there's some very strong differences between the two boards in the aspect that every single component on the BeagleBone Black is available to purchase in single Gerbers, the board layout, the bill of materials, data sheets, all of that is open to you as a product. So in theory, you could go and build your own BeagleBone Blacks if you wanted to. However, for the Raspberry Pi, that is not the case. You cannot even purchase the processor. It's in limited access from Broadcom. So you cannot build your own

Raspberry Pi if you wanted to. So there's some distinct differences between the two. I totally understand how the Raspberry Pi has gained such a huge market share and following in the community. But there are significant differences between that and the BeagleBoard.org projects. So that's from a maker and builder perspective. What about from a, I just want to pay my 40 to 60 bucks and have something to play with user perspective? Are they, they are similar? They're very, very similar in that aspect. The major difference

between the two is the amount of IO that you get to play with projects. For a lot of projects, the Raspberry Pi is absolutely great. There's no argument there. And for a lot of people who are being introduced to Linux and the community around it, Raspberry Pi is an awesome application for that. The problem is that generally when people get to Raspberry Pi and want to move on to more complex things with Linux or to interface to more hardware, generally they'll step up to something like the Big Bone Black or one of the other open hardware platforms available. Okay, so open hardware.

I guess some of the listeners may recall a show a while back where I tried to figure out which board layout tool to use for a tiny motor board, and listener Casey responded with an offer to do the layout for me. He finished months ago, but I finally got the board out to Fab last week. The schematic, the board file from Eagle, which I don't have, but it's there. The Gerber and even the BOM I used to build my little 10 board run are all on GitHub. That's what you listed. I mean, you listed all those for Big O' Bone Black.

Is that how you call something open source hardware? What do you need? Well, there's no one pure definition of open hardware. But what we do have is the Open Source Hardware Association, and that is OSHWA.org. And they have some guidelines that basically list the definitions and guidelines for what you should consider as open hardware. And having all the design files available to you, like the ones you just mentioned, are part of those guidelines. And while this is not a requirement or something you have to fill out or an association you have to join, these are mainly guidelines. So it can be very confusing as to what exactly open hardware is.

And this board is really just for me. It's a little tiny thing that is specific to my project. Nobody's ever going to use it. How do you figure out what's useful open hardware versus? Well, that's kind of an odd thing. If you look back, I'm kind of a study of history, and a lot of the things I talk about as part of the open hardware market, open source market, goes back to the original history, whether it's 20 years ago or 100 years ago or 1,000 years ago. In this case, what we have to look back is the original idea of books. And lots of times the books that were created were hand-created. They were on a library shelf, often chained to the shelf

so that the person that was reading the book couldn't take it away or steal it. That changed dramatically, you know, years later with the printing press where the books became more open for people to use and the sharing of scientific knowledge began to be shared between scientists and people built upon the previous work of another scientist and the amount of knowledge began to increase dramatically. How does this apply to your little board? That little board, although you may not think anybody, it might not be valuable to them,

but as an example for someone else doing their board, they might be able to look at your board and say, ah, that's how she did that. That's exactly what I need to know to make my board the way I want it. So sharing the information is a very, very valuable thing for people to build on top of that. And as long as you make it open to the public, in general as open hardware, they can use that. So it may not appeal to you or sound like it's a big thing, but each little piece of open hardware adds to the collective source material for people to work on. And how do you decide that it is open source hardware? I mean, I know there are a lot of people who will actually give you their schematics, but not the Gerber files. Where is the line? Again, it's more of a gradient.

And from looking at the definition that the open source hardware association lists, there's about 10 different items that are there. And one of those is providing all the design files. And each of the different design files, such as schematic, board layout, Gerbers, bill of materials, everything that you need in order to generate the board. So there are gradients of open, and it varies. So one of the things is that it could be not necessarily a completely open hardware, but it could be open source friendly hardware. So we talked about that a little bit before we started the show, and that's a new concept to me, that there is open source friendly things that aren't themselves open source.

There's a lot of different devices out there, for instance, that might be a USB logic analyzer or a USB oscilloscope, different devices like that, in which the manufacturer may not necessarily want to give away all of their hardware design, but they are completely happy sharing enough technical information for third-party developers to develop open-source hardware for it. Some of this example is the sigrock.org application, which is a group of applications

that allow USB logic analyzers and USB-O scopes to be used freely under Linux. And there are certain companies that are very open and open source friendly to allowing their hardware to work under Linux, whereas there are often companies that are not. And so there's a number of USB logic analyzer companies that will not release any information about their protocols and simply have no interest having open source software work with their product. Okay, and SIGROC was S-I-G-R-O-K, right? That is correct. Okay, so I did find the right, as I type onto Google. Okay, so one of the companies, you say USB logic analyzers, we've had the Salier, at least one of the founders, on to chat about his super neat USB logic analyzer. And they do expose their protocol interface through a C interface.

And you actually can get to more things through their C interface. You can get to their output features, which you can't get to through their pretty software. Is that what you mean, the APIs, the software APIs? Absolutely, but it goes beyond that. If you look at the SIGROT site, there's actually pictures of the hardware broken down. They've taken open the board, looked at it, taken pictures of it.

They document a lot about how it works. And they're not restricted from that. You don't get a cease and desist order or anything like that. Whereas for some of the other companies, they find this type of hacking on their hardware very offensive. And I myself, along with other Sigrock developers, have received cease and desist orders asking to remove pictures of boards and things like that. So there's a very big difference between the attitudes in different companies as regard to both open source and open hacking on their particular product. Yeah, I guess I saw that some with GE when they first came out with those LED lights. In the beginning, they were not happy they were hacked. They kind of tried to suppress

the information. And later they started to help disseminate it because it sold a lot of their products. Absolutely. Absolutely. How did you get into this? How did you become passionate about open source hardware? Well, it's a fairly long story, but I'm going to try to summarize it here. I was actually working for a point-of-sale company back in 1998, and I had developed some very unique Linux-based point-of-sale units. And I found it was very frustrating to get the type of hardware that I wanted. We actually found a company that was manufacturing Linux-based handhelds, and we were able to purchase those and customize them. And with that in mind, I decided that I really enjoyed doing development with Linux and open hardware.

Later, around 2002, I went to work for a small company that was making open hardware. And we had designed a replacement device, which was a ARM-based Linux system that actually fit in a 40-pin DIP package. And it was intended to replace actually a 40-pin Z80 processor in a very old lathe system. And we had developed it as a product for this particular customer. And the customer ended up deciding to replace the entire design, not just the Z80 processor. So we were left with this very unique little 40-pin DIP ARM package that ran Linux. And the owner of the company and myself decided to start a small company called Tin Can Tools. And we were going to market this little 40-pin DIP package that was a complete ARM Linux system.

One of the things that we realized very quickly is that we needed a way to program the flash and to help open source developers to debug the board, which we had named the Hammer board. And so Dominic Grath, who was doing a PhD thesis on JTAG devices, had developed a program called OpenOCD, which is on-chip debugger. And he had created some very simple JTAG debuggers to go with the software. And so we developed one of our own, and we called it the Flyswatter. And this was our very first foray into open hardware tools. Amazingly enough, we didn't sell a whole lot of the hammer boards. It just never took off.

But what took off was our JTAG debugger. Before long, we were selling 20 of the Flyswatter boards and only one of the Hammer boards. And so we began looking at how we could make other tools. And really, that's where we've been going from day one is making open source hardware tools, not just for development purposes, but for other things like logic analyzers, oscilloscopes, HDMI, DVI debugging, all of those types of things. And I've become kind of a coach or a cheerleader for doing open hardware development. That is pretty cool because you actually get to see the insides of your tools as well as all of the software associated with them. Do you still work on these or are you more focused on your current position? Tin Can Tools is more of a hobby business, I guess you would say.

Rusty Herod, who's the partner with me at Tin Can Tools, we of a hobby business, I guess you would say. Rusty Herod, who's the partner with me at Tin Can Tools, we still work on designs and push them out. It's more of a research and a hobby program now. But I currently have worked with Texas Instruments, American Microsystems, and now with CircuitCo on a lot of open projects. For Texas Instruments, I did the Panda Board, which was an OMAP4-based design. And we did that as an open hardware platform, which led to development of products such as the Nexus Q from Google. It was used as the base for Google Glass, did a lot of work, code work specifically for Google Glass.

We also were able to develop a proof of concept for the original Amazon Kindle Fire based on the Panda board. So, you know, creating open hardware platforms leads to actual commercial products down the line. And that's one of the things that I do on a regular basis. And is it all tools that you do or what else have you worked on? It's a combination between tools and development platforms. Platforms like the Bigaboard products, the Bigabone Black, the PandaBoard, MinnowBoard. These are open platforms

to allow you to actually look at implementing a specific process or SOC. So there's a wide variety of development platforms that I work on as well. And you do a lot of the software implementation for these? Correct. And really, I do more on the kernel level. To be honest, once the system boots up and I have a shell login, I kind of lose interest in the user space. So it tends to be more on the device driver development level. And I can, you know, design from schematic, board layout, getting the board manufactured, finding out what's wrong with the board during manufacturing, doing board bring up, re-evaluation of the design,

and then kernel device drivers. I don't usually use operating systems, and if I do, I don't usually get all the way to Linux. I use smaller things. So it's a little far outside my area, but I remember when I did work on embedded Linux devices, there were a lot of different licensing requirements for different open source software I could run alongside my code. Do you know anything about those?

Yeah, I've looked at different licenses over the years as far as which ones to use um source code wise virtually everything that i do is gpl v2 uh released uh because generally i do everything directly in the linux kernel uh but i do do some user space utilities and gpl is generally what I release everything under. Now, as this applies to open source hardware, most of the licenses that most people who are software developers are familiar with are not generally accepted in the hardware realm. Generally, from the hardware perspective, Creative Commons licensing is generally what's used for most open hardware. And so it's a little bit different between software and hardware market. Okay, so I remember BSD, you pretty much just have to put their name in saying you used BSD.

You don't have to release your code if you use BSD-licensed things. And I'm not a lawyer, so these are all just like my, kind of how I remember them. And then LGPL, as long as you compile the module in as a library, you don't have to release your code. But then there's GPL and GPLv2 and 3,

where if you use an open- source file of this license type, your code then becomes that license type. It's sticky. That's a very good generalization of it. So that's a very good explanation of it. Yes. And between v2 and v3 there's some some enforcement options that are slightly different between the two uh and but uh in in general most uh the software developers i

know are generally releasing under v2 are there hardware equipment equivalents to the different levels and is there any stickiness when i put an open source module into a larger system, am I making my whole system open source? If I wanted to, that's great, but if I didn't want to? Yeah, as I was saying, it's slightly different in the aspect because most of the open hardware is released under Creative Commons, and the license applies directly to the file and the information. Like, for instance, the schematic itself is released under Creative Commons.

And what's generated as a result of that file is not under the same license. So it's more about the file itself and the information. So each of the files have to be licensed separately, one for the schematic, one for the design files, such as the Gerber separate loan for the board layout. Each of these files are treated more or less like a book in the aspect that it's a creative piece that applies to it. And what does Creative Commons mean for me, the user? Basically, it's very similar to the BSD license, where you're free to use the design any way that you want. However, you have to leave in the accreditation or the credit for the development in the files and information about who originally developed the file. Credit where credit is due. Exactly. And there are several variations of the Creative Commons that are available out there, but the most common is Creative Commons Share Alike.

So you can actually look at the Open Source Hardware Associations page, and they have some descriptions of the different open source licenses that they recommend. Okay. I'll have to take a look at that for my little board, although right now anybody can use it. It's fine with me. Exactly. And then back to software again.

One of the problems I have with using some open source software, the GPLv2, is that if I have a small device where I don't have an operating system, I have to link together all my code. And because of the stickiness, if I'm writing code for clients, it basically means I can't use GPLv2. Are your devices running Linux so you don't link them? You can run different programs, and is all of it GPLv2, or do you have some that's behind the curtain?

Well, if you look at one of the prevailing embedded OSs that people are talking about right now is actually Android. There's a very big… Sorry, that doesn't count as embedded to me, but okay, we'll go with it. It's a touchy topic, but there's a very big push to use Android as an embedded OS. And if you look at it, the Linux kernel itself is GPL. However, about 98% of the user space applications are not GPL. They're under BSD or Apache license. So there's different licensing. So really on the Linux side, the only thing that you absolutely have to have as GPL is the Linux

kernel. There are alternatives that you can have to replace your entire root file system with non-open source if you choose to. And there are companies that are out there that produce BSP packages that are completely free of GPL or LGPL licensing. So under Linux, really, as long as you're using the Linux kernel and complying with the GPL requirements of that, you can do whatever you want on it. I myself generally use a lot of GPL device user space applications because there's such a good selection out there and they're widely supported. And I've only run into a very few instances where a customer has a very big issue with utilizing open source code under a license like GPL. One of the most common ways to get around this particular deal is that companies will break up the hardware into multiple pieces. For instance, they may have an ARM core that's running Linux with open source where they and connected

to that ARM core will be a separate processor such as a small Cortex-M device or an FPGA or some other device and those will be running closed source material so there's a very big gap in between our wall to prevent contamination of protocols or software. Yes, contamination of your source code. Exactly. Okay, so what open source tools do you use for development? I remember GCC, of course. I use that fairly often. I had a project about three years ago using OpenOCD and the House of Cards that it was built upon. Are those still the most popular open source tools, or are there new ones? Well, on the software development side, of course, GCC is absolutely the king as far as doing compile because you have AVR GCC.

You have various builds specifically for ARM. There's even GCC builds to compile Windows applications. So GCC is still the king in the open source compiler business. There are other tools that are starting to really reach out to not just the maker community, but even on the professional level. And those are for, like, for instance, the SIGROC utilities in order to support oscilloscopes, logic analyzers, devices for measuring power consumption, multimeters that have logging capabilities. All of these tools are becoming very available to the maker community and commercial developers. There are other things such as simple things like GerbV, which is a small Gerber viewing application.

It's a software tool that you can actually install it with your base build of Ubuntu or Debian or Fedora. And this allows you to actually view your Gerber files before you send them out or to do analysis of it. Other tools, you mentioned KiCad, and there's also JITA, which is a group of tools to do schematic capture, board layout, modeling, simulation, all of those are open tools. Now, they've come a long way in the last 10 years as far as development and usability, but one of the applications that still pretty much king in the market because they make their package available to developers as a free version for download is EagleCAD. And this is another example of open source friendly.

They could easily charge for their application like many other schematic and board layout packages, but they do make it free available to a lot of developers as long as they're not making commercial products. And so... That's really hard for me. I kind of want to break in there because I don't know if I'm making a commercial product. I have my little motor board. It does go into this shirt that I'm kind of hoping to build. And then I kind of want to do it. I only want to build about 10 because I'm too lazy to do production. And I recognize production is hard. And if I want to do 100, I'm going to modify my design from there and do Kickstarter and do 2000 and work with the CM and all of that. But right now, as I'm designing my system, I don't know if I am designing something

for commercial use or not. How do you deal with that? I'm not the only one in this boat. Yeah, agreed. And the thing is, Eagle, which has always had the attitude, is we take at your word on it. And most of the time,

they're not enforcing these types of things. There are limitations to the free version of the package. It's limited to a certain PCB size, and it's only two layers. So there are some limitations to the package. For 98% of the people that are doing hobby work, that's more than enough. As far as I'm concerned, if you do end up designing something and going to commercial with it, I would recommend spending the $49 or $150 to support Eagle in their open source and open source friendly works. Be on your honor and take care of that. Oh, yeah, of course. I mean, you should pay for what you use. I completely agree.

And I will, well, probably not Eagle. I think I'm in the KiCad camp. Maybe I've been listening to Chris Gamble too much. But definitely, I not only want to learn how to use it, I'm a software engineer, so if I could learn how to use it effectively, I could modify it to be better for everyone. Absolutely, and that's what I recommend for a lot of people. However, the biggest thing is KiCad and JITA have in the past really been designed by engineers for engineers, and usability hasn't always been the best, like a lot of other open source applications. It is reaching critical mass at this stage where people who are joining the project are adding and making it better, and I highly recommend it.

Absolutely. I have worked with other open-source software, and I've mostly tried to contribute to other open-source software projects, but it's not easy. You've been working with putting things in the Linux kernel. My business partner has been doing that too. And it's, it's a tough crowd. The communities are very difficult to break into.

What advice do you have for people who are interested? Well, this might not go over very well with what I'm saying, but really is you have to take all of their feedback and everything with a grain of salt. And you have to have a fairly thick skin and not take the comments personally. You do have to learn a little bit of patience and understand the mindset within not only the kernel development community, but other open source communities. They have a project that's their baby, I guess you would say, and they want to make sure that it stays that way, that it's a good project and bad code is not introduced.

And oftentimes they treat it as their own little fiefdom in the aspect that they want to make sure you're worthy of coming in and taking care of it. So you do have to have a thick skin when you work with a lot of it. I'm afraid that I'm going to probably stick mostly with the DIY space where open source is a lot about, I'm doing this for me, feel free to use it, I don't care, sort of attitude instead of the, I'm building a better community, which I would like to have, but I'm not as willing to play politics in my off time. And that's what I feel like it takes. Absolutely.

And I'm in very much the same boat as you on that. So I try to avoid getting involved with a lot of the bigger flame wars and things like that that go on. I'm more of an aspect that open source works for me to make commercial products. And I try to make sure that I meet the open source ethics, the mindset. But in the end, I am really about making money and making commercial products. And it just so happens I use open source hardware and open source code in order to do that. And you do get to contribute to open source as part of your job, right? Absolutely. And as I said, over the last

20 years that I've been doing embedded development, there was a really big change around 2000 when I began to be able to actually do open source work at work. And it became very important to me that all of my future jobs would be revolving around the ability to contribute to open source and open source hardware. And how do open source tools make money? How does open source hardware make money? I know it isn't about the profit necessarily, but you have to have enough profit to maintain yourself. How do you, I mean, you're selling the Flyswatter, which is cool, but you've also made it so other people can build it. Absolutely. The original Flyswatter was 100% open hardware, as we discussed earlier, based on the Open Source Hardware Association's definition. Now, the successor to the Flosswater was actually the Flosswater 2, and it's not a 100% open platform.

If you had to scale it, it would be about 75% open. We release the schematics. We release information about the board. However, we do not release the Gerbers or the board layout files. And the reason that we don't do that is we found that a large number of Chinese manufacturers in Asian markets were making duplications of the product, but they weren't doing it well. They were making products that were not of good quality. So this particular one is a lot more expensive than the original Flosswater, and it's targeted at more commercial developers in the fact that it actually comes with a case.

And this also goes back to open source friendly, as we were talking about. We provide all the necessary information for third parties to develop software around it, but we don't necessarily enable them to make the board itself. So many open hardware projects can lead to commercial development. You know, we began talking about the BeagleBone Black early on in this discussion. What we find is a large number of OEM developers will actually take the BeagleBone Black and design a product around that. They'll do their proof of concept. They'll test all their code. They'll do a demo for their Venture Capitalist or Kickstarter campaign. And once they have a product ready, they'll come to the people who design and manufacture the

BeagleBone Black, which is CircuitCo, and say, we need a custom version of this design specifically to make a product. And that's where the open source hardware leads to commercial and money making is, if you have the skills that you've developed an open source hardware that someone has used, they're generally going to come back to the person who's developed that to make a custom version or to develop something specific around that hardware. And that's when the money becomes important. Yes. And that makes a lot of sense. But going back to the flyswatter, because you said that it was reproduced and you weren't happy with the Asian reproductions.

Yeah, it wasn't the fact that they were being duplicated. It was the fact that they were being duplicated poorly. Okay, yes. I just wanted to stress that it wasn't, it's okay to duplicate. You just have to do a good job at it. Exactly. And so that was more of the key than anything else. And this procedure, I guess you would say,

of transitioning from open source hardware to closed hardware or partially closed hardware is actually being duplicated in a lot of ways. If you notice that some of the 3D manufacturers out there originally did their entire design as open source and later on have transitioned to either closed source or actually closed hardware. So it's a very easy path to start out with open source and transition into closed and to make more money on it. But you'll find that most of the people who start off with open source designs tend to continue contributing back to the open source community, even if some of their products are no longer open source. Well, this is a little different than, I mean, we're saying open source and we're talking

about open source software and hardware. And I can see how the hardware definitely, the path you're talking about uh where you you build something and it's cool and other people want to use it and so they want you to help them build their neat new thing that makes a lot of sense but with software you build something and then they want to use it and i guess you can be like mona vista where you or Red Hat where you provide support for that, but software can't be closed again. Well, it depends on the license, for instance. Some of the licenses allow you to of the time companies that do software for money, they're going to be doing adding features or making changes specifically for you. It's very similar, but the result will still be open source if it was the original was open source.

But yes, there can be some very different models with open source code versus open source hardware. I kind of like the hardware model better. It's a little simpler. I can see a path to monetization more easily. And it's, I don't know, maybe it's because hardware still has a cost associated with it. But once you reproduce software, everybody can have it. Exactly. It can be very confusing, but I agree with you that hardware tends to be a little bit more interesting on my part. Yeah, well, embedded systems are where it's at. So we talked a little bit about the Embedded Systems Conference, which is going to be happening the week this podcast gets released.

So we're releasing the podcast on April 2nd. Do you have any secrets to tell me? I'll only know for the next two weeks. I can keep a secret that long. Next week. Sure. As I said earlier, CircuitCo is actually a manufacturing developer of the Minelboard, which is minelboard.org. We initially released an Intel-based Minelboard last April, and it was a very interesting project to learn how we could do open hardware in conjunction with Intel. And the project, although it didn't sell a lot of boards, was a very big success because not only did CircuitCo understand how to work with Intel-based designs, but Intel also learned

how to work with open hardware designs. And as a direct result of that at EE Live, we're actually going to announce the successor to the Minelboard, which will be called Minelboard Max. And this will be a Bay Trail-based design. A what-based design? Bay Trail. Okay. You may be familiar with some of the press releases going out from Intel talking about their embedded market and everything.

So it'll be a very low cost compared to the previous board, and it will be completely 100% open hardware. That means the schematics, bill of materials, board layout, Gerbers, all of those will be released to the public. And so the next step of Intel working with open hardware will be happening. And this is significant. If you look at the last year, Intel has announced the Minelboard, the Galileo board, and now the metal board, Max. Intel has realized that open hardware is really an important thing to them in the long term. And this is just continuing down that path. Yeah, I don't really think too much of Intel and open source together. So apparently I need to start thinking about that.

Well, Intel has had a very big influence on open source for about eight to 10 years. They've been a very big contributor to the Linux kernel and development. What they haven't been is open hardware. And so that's only happened in the last 18 to 24 months. In fact, when we initially started the mental board, they had procedures in order to approve the release of source code as open source. But they had no procedures to release design files as open source. So those procedures had to be developed specifically for the open hardware. All right. And I will be speaking at EE Live.

This release is on Wednesday. And if you hear it before noon, come on down to San Jose Convention Center. The expo passes are free. And I'll be talking to Jen about the BIA Watch again, which is another podcast I've done here on Making Embedded Systems. On Thursday, if you pay to attend, I will be telling people the lies that marketing tells about the Internet of Things, which might be a podcast, but only after the event, because I have to do the event first,

and then I'll talk to you about it. And you, Dave, you're also speaking at the end of April in San Jose. Correct, at the Embedded Linux Conference, which is a Linux Foundation event. I'll be part of a panel on Internet of Things with several other folks, as well as holding several sessions based on embedded open hardware development and testing and debugging. It's funny.

One of those is with an Intel person. Indeed. And then the IoT one that you're talking about also has to do with the role of embedded Linux and Android. Correct. And Kareem Yogamore, he actually has a book on embedded Android development and does training on that. So he is very, very informed on using Android for embedded. Yes. very very uh informed on using android for embedded yes well it seems like you and i should probably stop chatting with each other and start getting working on our presentations

me more than you because you have a month absolutely absolutely any last thoughts before we sign off uh Well, I'm a fan of Mark Twain, and he had a saying that really kind of plays a part for embedded development. Really, you have to jump into embedded development and just start working on it. Although, as you know, there are a lot of books out there that help you get started. But a lot of times you really have to just buy the pieces and blow stuff up and hack things around to get what you need as far as experience in working with embedded. And it's very, very rewarding. But Mark Twain once said that a man who carries a cat by its tail learns something in a way no man could teach him. So that applies directly with embedded development. You really have to carry that cat by its tail.

Yes, yes, I am familiar with that cat. And yes, carry it by its tail and you will learn a lot. Also, the smoke does escape if you carry it by its tail for long enough. My guest this week has been Dave Anders of CircuitCo, makers of the BeagleBone Black, and amid a number of other boards, including the Intel Minimax. Thank you so much for being here. Thank you. And thank you to Allison Chaiken for thank you and thank you to Allison Chaykin for connecting Dave and me thank you for listening

and if you're going to fix that right Christopher so thank you listeners for listening if you'd like to suggest guests or make comments hit the contact link on embedded.fm or email show at embedded.fm. I do like to hear from you. Christopher says he's not going to fix that, so I'm not going to thank him for producing the show.

And a final thought. This one is about free software since the whole Mark Twain cat thing has already been taken. It's not even going to be a joke this time. The word free in the English language is a bit confusing. And the open source people have a way of helping you with this, with it having too many meanings. So we're going to switch over to Latin, because it separates zero price, gratis,

from no restrictions, libre. And that's why free software is sometimes free as in beer, meaning gratis, which is what we all prefer to pay for beer, to distinguish it from being libre, free as in freedom and free speech. So free beer, free speech, they're different. Have fun.