Embedded - 226: Camp AVR Vs. Camp Microchip (Repeat)

Episode Date: June 18, 2020

Jay Carlson (@jaydcarlson), author of The Amazing $1 Microcontroller, joined us to talk about comparing microcontrollers and determining our biases. This was an in-depth comparison of different micro features. Jay is an electrical engineer specializing in electronics design and embedded programming (contact). His blog is new and interesting. We talked to SEGGER’s Dirk Akeman about JLink on #218: Neutron Star of Dev Boards.

Welcome to Embedded. I'm Elysia White. My co-host is Christopher White. We are going to talk about microcontrollers this week, microprocessors, whatever you want to call them. There is so much to talk about. Our guest is Jay Carlson, author of an extremely in-depth article about $1 microcontrollers. Before we get started, I have one announcement to our Patreon supporters. First, thank you. And we're going to go to monthly instead of per episode because of the Patreon fee structure. If you're already a supporter, that will sort of make sense to you. If you aren't a supporter, that's fine. That's really fine.

If you have comments or questions about that or other related things, don't hesitate to hit the contact link on embedded.fo. Hi, Jay. Thanks for joining us. It's very exciting to talk to you. Hey, guys. Thanks for having me. Could you tell us a bit about yourself and your background? Yeah. So I'm a PhD student studying electrical engineering at the University of Nebraska-Lincoln, where I work in the Perceptual Systems Research Group.

I've built camera systems, wireless sensor networks, robotic systems, currently diving into deep learning and just working on all sorts of stuff. In addition to that, instead of having a social life or sleeping, I do a lot of consulting work in embedded systems on the side, working in surgical robotics, precision ag, remote data logging, and just a whole bunch of other sort of embedded-y sort of applications. So many questions, so many directions. No, I have goals. Before we get to the goals, there's lightning round where we ask you short questions. We want short answers from you. And if we are behaving ourselves, we won't ask you how and why in more depth.

The goal is short. Ooh, okay. Do you like to complete one project or start a dozen and never finish them ever? Like all the dozens. Like three dozens, four dozens. I probably have like 50 projects on my desk at any given time, it feels like. Hardware or software? Can I cop out and just say both i'll say hardware i'll say hardware i'm a hardware guy would you rather have one five dollar processor or five one dollar

processors oh definitely five one dollar processors do you have a technical tip that everyone should know? Make sure to pull up your reset pin. Favorite household object that has a micro in it. Television remote control. Preferred board color. Matte black with gold immersion and white silkscreen mental note don't buy his products they'll be very expensive hell yeah okay we're gonna get to the microcontroller part of the show but then i have another announcement before we do that and it's sort of an announcement all the announcements i know i know i sorry. But this is more an apology announcement. We're not going to explain stuff on this show. I usually want Embedded to be very approachable and easy to understand, but we're just going to link to the show notes and to Jay's article, and that will help you unravel the names and letters.

There's so much to cover. This is going to be like word salad, unless you're trying to solve the same sorts of problems we are. So we're just not going to, we're not going to like do acronyms or anything. We're just going to. No explanations. Fire hose from here. So this article,

which is less of an article and more of a choose your own adventure, click through. It is really amazingly laid out. I mean, So this article, which is less of an article and more of a choose-your-own-adventure click-through, it is really amazingly laid out. I mean, it's not like you go and read a bunch of text. You divide it up into sections and you click on the micros. It's a really well-designed thing, web thing. I don't know what a web thing is called, but I hate the word article. It doesn't seem right.

Jay, could you tell us about your web thing? Well, that's a great question. So my web thing started. This is kind of funny. So I found out I needed to get my wisdom teeth out. And I thought I'd have a friend drop me off, pick me up. I assumed that they wouldn't want me driving home all messed up on painkillers and stuff, bleeding out of my mouth. So I was going to have a friend drop me off at my house. And I was just going to kind of camp out over a weekend and recover from my wisdom teeth extraction. And my parents, who live in the same city as me, they inadvertently found out that I was having this major surgical procedure.

And, of course, my mom insisted on me camping out over at their place all weekend long. So I'm hopped up on painkillers, stuck in a bed, having food brought to me and everything I'm completely taken care of. And I have a laptop in front of me. I don't have my desktop. I don't have any of my dev boards. I've got my freelance calendars completely empty for the week. I got nothing going on. And I'm just bored out of my mind. I'm sitting in bed, refreshing Twitter, scrolling through things, can't find, can't find anything to do. And so I thought I should start a blog, right? Why, you know, why not? And so I decided to start a blog. I've blogged before on different platforms, you know, but the last, the last time I did a serious blog

was probably five years ago, at least. And, you know, they always just kind of fizzle out and i thought no this is going to be the time that i'm going to do it and you know i thought that the first thing that i should do is like a review a review of microcontrollers um and i wanted to do like an avr versus pick smackdown because as you two both know that is right that is just that is the top right right everyone is always talking about that. AVR versus PIC, AVR versus PIC. And, you know, I had two reasons why I wanted to do that. One of them was there wasn't a lot of empirical comparisons out there.

You know, for whatever reason, people, when they pick up one of these microcontrollers, it's almost like they take off their engineering hat and like all semblance of, you know, thoughtfulness. And when you start talking about microcontrollers, people just turn in like they see these things as almost like a religious experience. You know, it's you kind of sign up for, you know, Camp AVR, Camp Microchip, and you're committed to the team. That your team and so you just see these outrageous things being thrown around how oh you know the the pic 32 or the pics the pic 16 even though it's you know a four cycle part it's 32 megahertz versus eight so it's just as fast and that's not true and the avr people talk about how fast their part is but it's only got an eight megahertz

internal oscillator and blah blah blah blah there, blah, blah. There's all this, all this discussion going around and there just wasn't a lot of good empirical comparison. So I wanted to do that. And then the other reason why I wanted to do the AVR versus pick SmackDown is I really hadn't used either of those platforms for a long time. And so I sort of saw myself as sort of the objective judge, you know, kind of sitting on the outside, looking in, making fun of the fanboys. And I I sort of saw myself as sort of the objective judge, you know, kind of sitting on the outside looking in, making fun of the fanboys. And I could kind of side with them when it made sense, but then call them out when it didn't. And so that's kind of how it got started. As you can imagine, then it was like, well, maybe I could add an MSP 430.

Maybe I should do some 8051s. And then I remember the big thing was when I decided that we should really add some arm parts into this. Yeah, you need to add the arm stuff. But then you need a limit. Well, but that's the problem. As soon as you add the arms in, then it was just the floodgates open. And I was scrolling through. So what I did was I just went on DigiKey and Arrow and Newark.

And I was just like every single part, right? And I thought, well, maybe I could do them all. And it's like, I'm getting up to 70 or 80 parts. Maybe, maybe you need to get some more teeth out. Yeah, exactly. So finally it's like, this is, this is ridiculous. I popped another painkiller and said, okay, what I need to do, what I need to do is somehow limit this down. Right. And so I was trying to figure out how to limit it. Right. Or, you know, maybe I need to do is somehow limit this down, right? And so I was trying to figure out how to limit it, right? Or maybe I'll do an 8-bit one.

And it's like, no, I need something easy. And it's like, okay, they got to be less than a buck. I mean, it's 2017. You should be able to buy a microcontroller for a buck. And it should be able to do a lot of cool stuff. And so then it's like, you know, I messaged a few people on some forums and stuff and kind of floated the idea. And of course, the first thing is like, oh, well, like a dollar at like 10k pricing or what is this? Oh, God, you guys. Exactly, exactly. So so it's like, okay,

fine. $1 at 100 units. And man, have I gotten some pushback from that? Because people are like, they're telling me about these great parts. And well, if you know the guy at the company, you can kind of- You can get it off the back of a truck and yeah, they might not be the spec exactly. Oh, I can buy anything on Taobao. Yeah. So anyway, what ended up happening was I said, this is my firm rule, $1 at 100 units, that's it. And so I don't care if it costs $1.01 or $1.02 or maybe there's a sale at Newark right now. No.

So that was kind of the framework. And then once I had that framework, the rest kind of flowed from there. Yeah, it seems really easy to take 21 different chips and then just compare them. I mean, their software, their performance, their peripherals. Yeah. So that took you like, what, the rest of the weekend? So this, I had my wisdom teeth out, I think, middle of summer sometime. You know, your blog started in June.

Yeah, there you go. There you go. See, you know, you know better than I do. I. Yeah, there you go. There you go. So, you know, you know, better than I do. I don't even remember. And so pain pills again. And so what ended up happening was I realized like this, this project is getting ridiculous. I need to get some other content out there. So I sort of publish these cutesy little things like, oh, you can turn your J link into something that's less crappy if you do this, or you can get real-time tracing if you're on a Silicon Labs part. And just kind of a cutesy little history of the 8051 and, hey, look, we can use modern dev tools with this 40-year-old part.

Kind of cute little posts that I think a couple of them got picked up on Hackaday and got a little bit of publicity. That sort of kind of got the juices flowing. And it's like, you know, I should really do this. So yeah. Okay, how long did it take? Well, I think you said it, it was, I mean, I started it in June, really. And it's just, it's incredible. I did not realize it would take this long. Everyone said, well, this will take months. And I rolled my eyes, and it took months. I mean, and I was working on this almost as like, I don't, I hope none of my freelance clients hear this, but I was working on this probably as much as I was working on the stuff that I should have been working on, you know, and it's just, it takes forever because, so first of all, like some of these parts, yeah, you just grab the, I don't know, pick a part, SCM32.

You grab a little nucleo board or a little discovery board. You download whatever. You get it all set up. You kind of do your thing, whatever. But some of these parts were a little more esoteric. I don't know if you guys have ever tried to get ahold of a Sanyo LC 87 debugger, but, uh, so my first, my first stop was DigiKey and Arrow and Newark and Farnall. And then I went to Octopart and looked to see if anyone had any of them in stock. No one did. So I got in touch with an FAE over at On Semiconductor,

which you know how everyone just acquires everyone constantly these days. And I guess today on that particular day of the week, On Semiconductor owned Sanyo's microcontroller stuff. So I got in touch with On Semiconductor. And I think these parts, I don't think anyone uses them. I think that they're like stuck in a warehouse somewhere. And because on semi guys were just like, they were what? Yeah, yeah. First of all, I don't think they really knew what I was talking about. It took them a couple of days to get back to me. And then after that, they, they, they basically,

they said, Oh, yeah, the debugger, it's like $600, and then the dev boards are $600. And I sort of politely replied back and said, yeah, I'll pass. And then the next day they replied, and they're like, oh, the factory's agreed to send them to you for free. Yes. Oh, okay. And they sent me three setups. Like, I have, I don't, what is that, 600 times, two times. I can't even do math, but that's like thousands of dollars worth of dev tools that I got in a little box next day shipped to me just

because I inquired about the part. And I'm not encouraging anyone to do this because it turns out these are pretty lousy microcontrollers. But what was, what was funny is Micah Scott, who, you know, I don't know if you guys know, but she does a lot of work. Yeah. She's on, she's been on the show a couple of times. Oh, great. Great. Yeah. So, you know, she's done, she's just does all this cool stuff.

She's just constantly doing cool stuff. And I saw a wake on tablet teardown that she did. And she's like, right, right, right. I remember that glitching the firmware and pulling, pulling the firmware off of that. And I felt kind of bad because like, you know, she's doing all this like real engineering and hacking to try to pulling the firmware off of that. And I felt kind of bad because like, you know, she's doing all this like real engineering and hacking to try to get the firmware off. And I just call up on Simi and say, can you send me a debugger? And they just do it. I felt like I definitely needed to get this stuff over to her. So I sent her a box full of stuff.

And, you know, she's working on her crazy cat winch bot thing right now. But hopefully if she ever comes back to the tablet, she can just plug in one of the debuggers that I sent her and she can keep working on that project. We need to go back a little bit because we need to talk about what chips. OK, so we have this weird Sanyo chip and we have some AVRs and we have some picks. And you mentioned STM32. There aren't a whole lot of 32-bit chips that fall into this, are there? Fall into the under a dollar thing. You know, if we were talking a year ago, the answer would be no. But, you know, recently there's been just a big push. So ever since the Cortex M0 came out, which was supposed to be the 8-bit killer. Yeah.

Yeah. The M0 Plus. Yeah. And the M0 Plus especially, which reduces the caching down to, it's a two-cycle cache, right? And a two-cycle pipeline, I'm sorry. And which, you know, which gives it a little bit better latency. And that so that's one thing that the 8-bit parts definitely, definitely still have the advantage of. But you are right, there's a lot of ARM parts that are starting to, they're

starting to get in the dollar market. So what do I have? I don't know if you want to go over them, but I've got the SAMD10, I've got the PSOC, Cypress PSOC 4000S, which I would say is like a fake PSOC chip. It's not really like a Cypress PSOC. It doesn't have all the cool stuff that the real PSOCs do. It's basically just the Cortex-M0. The KU-04, the KU-03, those were originally Freescale parts, which then got acquired by NXP. The Infineon, the XMCMC1100, which is a great little Cortex-M0, one of my favorites from the review, actually. Now, if we're just talking

32-bit parts in general, Microchip has the PIC32. And they went kind of their own direction, right? They went with MIPS as opposed to ARM. So that was a really interesting comparison to see that, you know, how did this MIPS part compare with the ARM parts, right? And then, you know, NXP stuff, I think I had an LPC 811, which kind of comes from the same lineage as the famous 812 that I think a lot of hobbyists got into because it was an 8-pin DIP package, right? And so here's the 811, which is sort of from that lineage. And then the STM32F0. And I think that's it of the ARM parts. Which is a lot. Every manufacturer, every vendor that I know of is represented here. And you're right. A year ago, there wouldn't have been nearly as many ARMs on this list.

Yes. And I remember Freescale, I think, was... So I have kind of a funny background where I started on the PIC16, but then pretty quickly, I was looking for a micro and I was on DigiCane, I just realized how expensive they were. And there were these Freescale Kinetis parts out there. And they were really cheap, 48 megahertz, you know, 16k of flash, all these peripheral 16-bit timers everywhere, and fabulous ADCs, analog stuff, comparators. And they were really inexpensive. So I sort of just picked up some of those Freescale parts when they first hit the market, because those were the first cheap ARM parts, if I remember right. And those came out maybe 2008, 2009, somewhere around there. Okay, so you got all these dev boards and you got a bunch of different programmers. Yeah, I tried to get dev boards.

Some of these parts, I just couldn't get dev boards. So I had to end up making my own for some of these chips and kind of cobbling together stuff on breakout boards. And, you know, I, I reused my J link a whole bunch of times. Uh, but yeah, you basically had to build a independent setup for each, each, uh, microcontroller. How many different, uh, debugger units did you need? There was the J link, the Sanyo specific one. What else did you have? Oh, so that Atmel stuff I was using there on onboard debugger. But the problem was I was having issues getting low power stuff working because a lot of these dev boards just aren't built for that. And so I think I had to grab an AVR Dragon, the Cypress stuff that comes with it, Freescale.

I was using J-Link. So Holtec to get this HC66 running, this 90-cent little microcontroller running, I was scrounging Ally Express and eBay. Couldn't find anything. I ended up setting up a Taobao account, which, by the way, like, I mean, that should be almost like praiseworthy enough. Just like setting up a Taobao account, which is just really challenging. But, but so I set up a Taobao account and was able to buy one of these HE66 debuggers from from China. And then, you know, the microchip stuff, I was using a picket. Yeah, I probably went through, you know, four or $500 worth of debuggers, I had some of this stuff laying around, you know, I have a lot of freedom

in the consulting gigs that I have where I do a lot of R&D stuff. A lot of this stuff is pretty easy to justify. My clients have no problem saying, yeah, if you need this tool, if you want to check out this part for something, you know, go for it. So I was able to buy a lot of this stuff

or I already had a lot of this stuff laying around. And then I spent a few hundred bucks on debuggers and development tools. So these parts are actually kind of cool. The SCC8 doesn't actually even need a debugger. It has a built-in UART. It's very weird. It's like this weird UART monitor program. You download this firmware image to the chip, and it runs its own debugger in software on the chip.

So what's cool is you can just use a UART to do debugging with it. But not just printf debugging, but like real debugging. Yeah. Yeah. Yeah. So and I don't know what your experience is, if it reaches back that far. This is before my time, but this was apparently quite common in the 90s when they were late 90s even,

where they did monitor programs. And they would basically put this firmware on the board. There'd be a timer interrupt that would kind of periodically check in with the monitor. And yeah, very interesting design. Even running systems, we sometimes would still have a fourth monitor that you could get into to do debugging like this. Even now, I'm thinking about a client last week was shocked when I finally gave him the keys to the console debugger so that he could type in the commands and get some data out.

And I'm like, yeah, it's a UART. It's not hard. I swear to you, a console command line is really easy. But, okay, so you have some boards. You have all of the debuggers you need. But what about development environments? I mean, you can't just GDB and GCC all of these. That's one of my biggest beefs with the PIC system is their compiler. But even if you do PIC and GCC, that's not enough.

So how many different development environments did you have to deal with? Okay. So at first I thought I'd be crafty, set up one Eclipse instance to rule them all. And that failed miserably. That was a disaster. I just, yeah. Because so the other thing is I wanted to evaluate the IDEs. It wasn't just a matter of let's get some code on here because we haven't got into this yet. But, you know, I started to do some performance benchmarking.

That's why I need to actually run code on these parts. But then I realized,, you know, the IDEs, that's, that's as big of a part of this as anything. And, and what's interesting you guys is the stuff that we don't think about ever talk about things like header files. You know, when was the last time you sat around and said, God, the headers for this microcontroller are just terrible. You know, I've actually said that recently, but yeah. Well, okay. We're kind of nerds though. I've actually said that recently. Well, okay. We're kind of nerds, though. I feel like a lot of people would not be thinking about that. And they sort of just accept

that this is what it is. And once you see it one way, it's really hard to look at it some other direction. Exactly. So I think the main if there's one kind of summative goal for this, it's to get everyone realizing that, all right, you're in Camp Atmel, you're in Camp Microchip, you're in Camp Nuvaton or whatever. Take a step out, look around and see what everyone else is doing, because there might be cool things that they're doing that you don't get access to.

You know, so some of these header files, like I mentioned Nuvaton, because they have more or less the entire reference manual inside the header files. So above every single register, they have all the content relevant to that register from the reference manual in the header file. So think how cool that is. You can just control click into a register and it pops up, gives you a description of what all the bits do, everything like that. In addition, they have, you know, bit masks and everything for every possible bit. And it was just, so in my opinion, it's 2017. I shouldn't have to crack open a data sheet every time I want to do something like the header files, the peripheral libraries, whatever, whatever method you like to develop it. And I tried to stay agnostic in the review. But the idea is that everyone sort of has their own way of developing.

And so what I did was I used every IDE, every manufacturer's IDE, and kind of used the header files and the peripheral libraries and code gen tools for each one. And just tried to evaluate it as someone using that architecture would use it. Some vendors have preferred IDEs. Some of them like IAR or work more with Kyle or don't work with either one of those and support GDP more. How much did you follow their tutorial getting started guide and how much did you just do what you needed to do? So, okay, the first rule was, so as you guys know, there's vendors like Kyle and IAR that have support for tons of different parts. So the first rule was use the vendor, like if the vendor provides an IDE, you've got to use it. So I was

not testing the mega AVR using the IR compiler, right? I was using AVR GCC inside Atmel studio. Right. Um, so that's, that's one thing. And that, that really helped me a lot. Cause that would be insane if I reviewed every IDE for every part as well as all the parts. Yeah. So, so anyway, I, so some of it was, you know, follow, following example projects and things like that. And, and I talk about that in the review about how some vendors really, you know, these peripheral libraries who sort of give you, you know, Doxygen, here's an HTML file with, you know, a list of all the members in our, in our peripheral library, go knock yourself out, have fun. Here's some example file with a list of all the members in our peripheral library. Go knock yourself out.

Have fun. Here's some example projects, right? And so the Kinetis, K-L-O-3, I have to fault as probably the worst in terms of just ease of use development getting started. The peripheral libraries for it have no documentation. It's just a list of functions, basically. You have to kind of guess what they're doing. There's example projects, but they're all trivial toys.

None of them use peripherals the way that you'd actually use them. No interrupt-driven stuff. It's just a mess, especially compared to the Freescale KE04, which is hilarious. You know, Freescale had this huge transition phase. They went from processor expert, sort of cool, nifty code generator stuff, which has huge faults that we could get to. And then they went to the super lightweight runtime peripheral library. And those are the kind of the two camps that you see these parts in.

You see them in peripheral library mode or sort of code gen mode. And what was funny is just how Freescale, I think, fell from grace when they switched to that runtime library. It just got so challenging. And these were the easiest parts to use when I first got started. Like nothing was easier

than using Processor Expert on a Freescale part. You didn't even really think that you were programming a microcontroller. You have like such high level functions that you don't even think about what peripherals are actually even being used to do this stuff. And they sort of did a complete 180. It's miraculous how little importance we place on fantastic libraries like that when it can make our jobs so much easier. Exactly. And what's interesting is you see the Atmel stuff, you know, Atmel software framework, probably I think Microchip renamed it to Advanced Software Framework when they acquired Atmel,

trying to get rid of the Atmel name on everything. It's to the point where that whole ecosystem, which is largely seen as the most sort of hobbyist, maker-friendly, is really, in my testing, quite the opposite. No one uses any of these peripheral libraries. No one uses Atmel Studio. Everyone hates all of this stuff among the makers, hobbyists. And so you end up with an ecosystem where all the tools and header, not header files, those are standard, but all the tools that people use are all community developed. And I just like, I mean, I have to roll my eyes at Atmel who makes very little effort to

really support these projects, you know, from my research. It just doesn't seem like they really help out the community. And so everyone sort of brags about how great, you know, the ATNOL, the AVR stuff is for open source, you know, indie developers and students and hobbyists. But all the tools that they use are these like open source debugger, or not even debuggers, programmers, and all these tools that the vendor doesn't even provide or support. Once you get out of Arduino land, there's just this huge cliff. And it's sad because they could do so much better to ease people into a good experience. But no, you either are cosseted in this land of everything is done for you and you have to use all the Lego blocks or you're setting up your own GCC, probably compiling it from source for your particular, just,

there's got to be a middle ground. Exactly. And when you get on the forums, do you see people talking about, well, here's how you do an app? No, you see people saying, oh, I just downloaded this GCC tool chain for Linux. You know, hope you're running on Linux. And, you know, you just kind of build it. And here's a $5 eBay programmer.

It doesn't even support debugging, right? There's no open source debugger for the Atmel AVR. And that doesn't seem to faze anyone. And, you know, you guys both do embedded development. Can you imagine, like, not having access to any sort of debugging? Yes, I can imagine that. Oh, really? I'm too stupid to work without a debugger.

I'm not that smart. It's not smart. I'm just too lazy. Yeah. You know, print effing everything. Yeah. I have to be able to just double click on the line and say, what, you know, what the heck is going on right here? You know? And so I think that that's, that's one thing that, that that's sort of one theme that really came out from this. And, and, you know, the Atmel

ARM stuff is fantastic. Like in terms of value, the SAM D10, D11, D20, D21, those are great chips in terms of their, what, you know, what's on the chip. Whoever designs those chips, they do a good job. But then the peripheral libraries, the development environment, the debugger, you know, what does Atmel Ice cost? Those are like $140, $150. That's insane. You can get a J-Link EDU Mini for $18, like an official SEGGER J-Link EDU Mini. And a lot of things that aren't official for similar prices, yeah, that do the same protocol. What's funny to me is, you know, and I think you tried to make this part of your review,

is that, yeah, you've got this whole range of processors out there and they all do different things. And it's really easy to look at one and say, oh, thing has the best specs this is the exact one it's like 50 cents per you know per unit and 100 quantities is the perfect one for my project and then oh yeah but um you're going to spend three months you know learning to operate its peripherals you're going to have a huge learning curve with whatever random ID they have and its debugger costs $1,000. Or you can buy one that costs $0.55. Or $1.

And it works right out of the box and does 95% of what you need and you can be almost done. I think that was kind of my reaction to reading some of the about some of these chips. It's like, why does this exist? Why are you still

selling this yeah you look at like the the stm8 or you know yeah the sanyo lc87 some of these these ultra cheap parts the whole tech stuff um and yeah you know they are just they're really really really cheap you know these parts you guys today could go on Ally Express or Taobao and buy these, you know, buy 50 of them, 100, like not even quantity, right? For, you know, 20, 25 cents a unit. These are so cheap. And that is, you know, that is the advantage, you know, of course, when you're doing real engineering and you're building 100 billion units, you're going to, you don't care if it takes you an extra week to get the firmware running. Right. And then so but then the thing was and that was a common thread from people.

But what I wanted to do is see, OK, is that really true? Like you look at a part like the whole tech HT66. This is a super cheap, weirdo, 8-bit part that no one's ever heard of. And I think we all would go into this thinking that, oh, this seems to be really hard to use, terrible. You only do it if you're doing big volume stuff. But here's the funny thing, you guys. I

kind of liked the HT66. It has this funky IDE that feels like it's from 2000, but it's got text completion, It's got a debugger. It runs, I'm not making this up. It uses eight megabytes of RAM when the IDE is running on your computer. Take that IAR. Right? Eight megabytes of RAM. Like you could run a hundred instances of these on a Raspberry Pi. And the funny thing is you, you, whenever you save, whenever you build the project, it immediately starts debugging in

the background. So you almost feel like you're on the simulator where, where you're kind of writing some code, you hit the build button, it compiles, and then you can just immediately like hit a break point. Imagine if you're doing kind of a master while while true loop, right? You're kind of main app loop. You could just at any point while you're writing code, testing things, you just double click on a line and you'll stop there eventually and see what's going on. So it's a super cool kind of iterative development. I kind of like it, you guys. I kind of like it. I might be reaching for one of these parts, you know, in the future for personal stuff. I have no idea, you know, can I get 10,000 of these reliably every year for the next 15 years?

You know, some stupid stuff like that. But for personal projects, I like the idea of sort of hackers, hobbyists reaching for some of these more obscure parts and saying maybe I don't know, maybe there's something here. And then with some of them like the STM8, I don't know if there's really anything there. You know, there's some of these parts, yeah, they're cheap, but it's just the development environment's clunky, and it's just, I don't know if it's worth it. But some of them are just kind of cute, and they're kind of fun to play with. Okay, taking it away from the chips for a second,

and I know that it's hard to divorce them. What was your favorite and least favorite debugger, programmer unit? Because you could do an entire article about those and their differences. Oh, yeah, absolutely. Absolutely. Okay, so I'm going to cop out a little bit and give you just a couple, a couple ones to look at. These are the good ones first. Yeah, these are.

Yeah, yeah. These are. So the J-Link is something that everyone needs to have a real official. I'm not talking about a clone that won't work or that, you know, an official J-Link debugger. And the reason is because these can do everything. Every arm part. First of all, they're completely supported. If you are a hobbyist or a student

or a maker, anyone working non-commercially, you can buy a full J-Link debugger for, I think, like $50 or $60. They're really inexpensive compared to the competition. Now, if you can even get the

mini one, the J-Link EDU Mini, it's $18. Adafruit sells them, DigiKey sells them, probably find them on Amazon. And these are just great little debuggers. They also support, kind of interestingly, they also support the Silicon Labs EFM8, which is an 8-bit 8051 microcontroller, one of my favorite microcontrollers from the review.

So I really like the J-Link. It's by far the fastest debugger that you can buy, a reasonable person can buy. You can get $40,000 weird proprietary things. But the J-Link is by far the best debugger that you can get. It's proprietary, but it has good support in Windows, Linux, and Mac, works in every IDE that I, every ARM IDE that I tested. And that's kind of another thing. You know, you want a debugger that's just going to work. You don't want to have to install extra ARM plugins and configure things. You just want something that's going to work. And every single manufacturer

IDE for ARM processors supports the J-Link. And because it is so inexpensive for hobbyists and students to get into, $18, and because professionals can justify the, I think it's like four or 500 bucks for the base, professionals can easily justify that. It's less than a half day's work for a lot of pros. I think that it's the only ARM debugger that you should consider. It's got a USB 2.0 full speed or high speed. I'm sorry, high speed interface. It's a 480 megabit per second interface. It's got fastest flash programming.

Yeah, that's easy. Now, there's some other ones that you should consider if you're looking at specific parts. So the STM32, I would go for the ST-Link. Those are great. Yeah, the ST-Link is great. I haven't had a good experience, but okay, sorry, go ahead. Oh, well, yeah. Well, I want to talk about that after I do my spiel.

So in my experience, so the ST-Link works well with not ST Visual Develop. What's the system workbench? System workbench for STM32. That's the official Eclipse-based free IDE for the STM32. ST-Link works great with that. It's also by far the cheapest ARM debugger you'll be able to buy. You can get them on Amazon or eBay for $5, the clones of them. And these are somewhat semi-sanctioned clones by ST.

ST, you can kind of pull the firmware off these debuggers and make your own clone, right? And that's what people in China have done. They're great. I really like them. I understand that they probably don't have as good a support in other operating systems other than windows but i'm sort of just i've sort of just been programmed that if i'm doing any sort of embedded electronic stuff i need to have access to a windows computer but i understand that a lot of people have different different mindsets about that and that's totally fine too okay so the st link i have used a number of times and I sometimes will give up and use the J-Link instead, even if the client has an ST-Link and I know I'm going to be giving it back to them. Usually in that case, I want to use the client's tool so that my documentation is all good. But if I am just trying to blow through some code, I will switch to a J-Link because I find that the ST-Link fails.

And as you were saying, you want it to always work. The debugger is the thing that cannot break in your tool chain. And I hate having spent an hour debugging why I'm having this weird crash bug only to find out what I needed to do was reboot my ST-Link. It's your debugger. Oh man, that's the worst. Isn't that the worst? It's such a waste of time. Oh yeah, no, exactly.

And, and, and I think that there's, you know, I know someone that like they use a DB nine serial port with a diode and a resistor hung off of, right. And that works for them. It's like, okay, maybe your time, I guess your time is just not as valuable as mine. But I need stuff to work. I want to, you know, and the whole thing with this is I want to focus on solving interesting, cool problems. I don't want to mess around with debuggers. I don't want to mess around peripheral libraries that suck. I don't want to mess around slow code gen tools. I don't want to mess around building my own IDEs. And I think if people are like me,

they'll appreciate reading something like this and kind of going through it. And yeah, seeing that the J-Link, this just works, right? Now, if you are short on cash and you need to do commercial development, you know, you can't use a J-Link EDU for commercial development. You can get a $5 SD-Link. You can make it work and plow through it. But yeah, definitely first recommendation, J-Link EDU or J-Link EDU Mini. Definitely. Cool. And my recommendation is borrow a grown-up J-Link when you need to do commercial stuff. And then you can use the ST-Links in the factory where if they do it twice, it won't kill them.

Yes. Yes. That's a great recommendation. I like that. And that's kind of one of the other reasons why some of these other parts, like the microchip stuff, it's really getting harder and harder to recommend. Because the PitKit, if we're talking about the worst kind of going on the other side, the worst debuggers, PitKit, by far, PitKit is absolutely atrocious.

It's 50 bucks. It costs about the same as a J-Link EDU and it's orders of magnitude worse. In my testing, I'm not making this up, it took to fill up a 32k flash on a PIC32, I think it took 18, no, like 30 seconds. Yeah, it's unbelievable. It's so slow. And there's a quick hack. The default option in MP Lab is to like reconnect to the tool every time you start a debugging session. And you have to change that. There's like all these stupid little hacks that you have to remember to do.

It's very annoying. I don't like them. I don't know that the PIX stuff is as lucrative as it used to be, other than if you're an industry, like an industrial product, and you need 20-year guarantees on chips. That's really the main draw to me for microchip. I know that they're always going to be there. MP Lab is also one of my very least favorite development environments. Yes. Do you have favorite, least favorite development environments too?

So I'm totally on the Eclipse train. I like the idea of every vendor using the same base for an IDE because it lets me switch from different vendor tool chains very quickly. And so even though Eclipse is kind of bloated, I think it's getting better. It's not what I use in my day-to-day programming outside of embedded systems. You know, I'm in Visual Studio, I'm in Visual Studio Code, text editors, I'm in, you know, other things like that. And, but, you know, if you need, if you need an IDE, I think it's the best. I was really excited to see Silicon Labs move their 8-bit stuff to an Eclipse-based IDE, which was, I think, the only 8-bit tool chain that I reviewed here.

So if you're looking for an 8-bit... Seriously, if you guys are looking for an 8-bit part, I cannot plug Silicon Labs' EFMA to enough. They're great little parts. Like I said, you can use a J-Link debugger. So if you're sort of used to the ARM ecosystem, you've got your Eclipse-based IDE, you've got your J-Link, all this sort of stuff, and you want to do a little 8-bit project, you know, because these things can get down to 600 nanoamps with an RTC running. Like just crazy low power consumption. Crazy, crazy stuff like that. You can download for free Simplicity Studio.

You get your Eclipse-based IDE. You can use your same dev tools. And it, you know, it feels, well, it feels like you're working on 8-bit microcontroller. You've got memory regions. You've got kind of funny interrupt stuff. But it's like, yeah, it just, it feels kind of nice. It feels kind of nice.

They've got great peripheral libraries, great code gen tool. So, yeah, the pick stuff not, not good with either the, either the IDE or the, or the debugger and the header files are pretty, they're, they're okay. They're, they could be worse. Other least favorite debuggers, they could be worse. They could be worse, but that's not, that's not a resounding support of that. Other debuggers are somewhere in the middle, I think. I think those are kind of on the ends of the spectrum.

The Atmel stuff, I think that they use like a D infinitely better than the mega AVR that we all know and hate. What is it? They have that debug wire. It's super weird. If you want to debug a mega AVR, you've got to put it into this weird SPI mode. You flash it, and then you can enable the debug wire thing, and then you can switch to this one-wire debug interface, but you can't program fuses with it it's very weird and clunky and dumb did printf yeah yeah exactly i don't think i ever used a debugger on on the on the megas yeah all in all you have to you have to dedicate you know what six pins just to debug a mega avr and i granted they're you know they're typically larger

chips but but still that, that's pretty silly. The tiny AVR has a new one-wire does-everything debug mode called UDPI or UPDI. Universal... One of those. I forget the letter order, but it's a brand new one-wire debug protocol. I really like it. I really wish that it were available in something other than $140 Atmel ice though. Yeah. Okay. So we had a listener question about why do I hate picks? Do you think we've answered that? Or do you think we should continue to bag

on the picks? We should talk some more about picks and how terrible they are. Every time I've come onto a project where the electrical engineer is specifying everything. And it's always the electrical engineer. And it's a micro project. It's always a pick. I've never worked on a project where the firmware engineer or software engineer picked a pick.

Yeah, that's because us electrical engineers, we don't have to worry about programming them. Exactly. Or if they do, they're in their hand machine code doing stuff. They're doing assembly language on the PIC. And I'm like, no, that is not a good use of anyone's time. So that's pretty much my experience of PICs is wasting a whole bunch of everybody's time.

Yeah. And they have terrible debuggers and they have terrible development environments. Which you don't care if you're putting in bytes of machine code to program them. Exactly. You learn to program in 69. It's 2017 and Microchip wants us to fork over thousands of dollars for a compiler for their own chip. We're not talking about Kyle or some third party vendor that makes money selling compilers. No, we're talking about the vendor themselves charging thousands of dollars for software to allow you to use their part. You know, like it's, yeah, it's pretty, it's pretty ridiculous. I have to say Microchip reached out to me after the review and they were very polite and they actually hooked me

up with one of the lead architect guys. And, you know, he explained some interesting things about, you know, some of the design decisions of the PIX16. So, you know, us three have been focused on kind of the development side. It needs to be said that the chip itself is very, very slow. And that's not necessarily a bad thing, but it's a fact of the architecture. It's a 4T architecture, which means that, you know, for every four clock cycles, you only execute one instruction cycle. Now it is a single cycle machine in the sense that each instruction, except for jumps, takes one instruction cycle. So, you know, they like to call it a risk machine. It's really kind of a, and even that sort of that marketing

terminology kind of leaked into my blog in a few places. And someone pointed out for me to me, and I sort of cleaned it up a little bit because it's not really a risk machine. It's a, it's a single register machine. So everything you do and the elegance of the pick is that everything you do is you take something, you put it into your working register, and then you take the working register and you put it back into memory somewhere. And so there's something kind of elegant about that. You have to remember what it was originally designed for. You might as well write it in assembly. Yeah, it's like a 6502.

Exactly. And you guys have to remember, it started out as a peripheral controller for a general purpose processor. Yeah. So it wasn't even intended to be its own thing. I guess the thing that bugs me is it seemed like there's always a better choice. So why? Why?

Why was this chosen? Okay, I'll play devil's advocate to myself. Good, good, good. And let me justify the pick a little bit. So one thing is DIP package availability, which hobbyists love. I don't't know why i think it's 2017 you can solder an soic chip on a breakout board it's really not the end of the world but i get it i get that a lot of people they really like to take a dip chip and put it down on the breadboard okay point to micro microchip no that's maybe a half a point okay okay a quarter of a point to microchip for that

i mean if yeah no i and i'm totally with you guys i i have no issue you know doing a little breakout board you can get you know 100 packs to breakout boards on ebay for nothing so just just do it but that is for whatever reason people that is what they are obsessed with now another thing about the pic is it does have quite a few peripherals. It's got some funny kind of cutesy, interesting peripherals. They've got decent analog selection. They've got a lot of timers. Now, these aren't like great timers.

These are like little funny timers. They've got like a little 8-bit counter that has like really deep prescale. They've got, but no like auto reload, no period register. So you can't set it up to do precise, precise stuff. But it's got deep prescalers. It's got – and it's got like such a weird selection of kind of funny different little things that you can do with it. It's got arbitrary waveform generators. It's got some 10 generators. It's got, you know, some 10 bit PWM

outputs. It's, it's, you know, if I were building a very low power, little part, little project, it's not necessarily a bad choice because it really doesn't use much power at all. And that is something that's important to recognize. It's, it's pretty hard to use more than, you know, a few micro amps with a pick, you know, really when you get things dialed in and you have to, there is something to be said about that. And, and kind of going back to what I was saying before, you know, when I was talking with the sort of the lead developer, one that he was talking about was flash, flash read speeds and how, you know, with this 4T architecture running at 32 megahertz, it's sort of like

kind of an optimal way of doing it because your flash read time is only eight megahertz on this sort of process that they're on, on kind of a low power flash process. So even if they made it a lot faster than a 32 megahertz part running at, you know, one fourth instruction cycle, you're not really going to be able to see that performance because of flash timing. And if you guys want to dive deep into a little detail, one thing I really noticed was the difference in performance due to flash and flash acceleration or lack thereof. Yep. That's a big factor that's hard to expose in a data sheet. Exactly. And no one talks about that, right? So you have like the Infineon

XMC 1100, which I really enjoyed. This is a cool ARM part. It's got awesome timers. You can go like 64-bit deep. You can do really cool communication stuff where the communication peripheral itself can more or less be configured to babysit itself. Think about doing I2C transactions, kind of doing the reads and the writes. You normally have to have sort of an ISR service, that sort of stuff. This thing can actually do all that by itself without any use of the CPU. Very cool chip. It's also got flipped memory specs. It's got 16K of RAM. This is a $1 microcontroller. 16 kilobytes of RAM and 8K of flash. So it's actually got

more RAM than flash. And I was trying to figure out, why did they do this? I started testing it. I realized immediately why. They have no flash acceleration. They have no prefetch. They don't do anything. They simply go into wait states. So you more or less have to...

Move all flash to RAM. Yeah, you got it. You basically just run out of RAM. You start projects with these things and you're like, oh, the CPU is super fast. This is great. And then you get into it and it's like, oh, wait a minute. All of my storage has 24 weight states.

So, uh, uh-oh. As long as you have lookahead and no if statements, you're fine. Exactly. That's why, like, if you've got, I mean, if you look at like my biquad, you know, filtering results, uh, you look at like the number of clock cycles that, you know, each part takes, you would think all the cortex M zeros, uh, would take exactly the same number of cycles and they don't.

They take different numbers of cycles, and it's all because of flash. And sometimes it's pretty crazy that Infineon takes 40 cycles to do something that the fastest parts do in 27 cycles. But the microchip takes 1,466 cycles. The whole tech. But they're very cheap cycles. Yeah whole tech. But they're very cheap cycles. It's out of my perception. Yeah. Yeah.

Oh, and we should actually, so we didn't talk too much about some of the code you wrote for this, but Chris was saying how this wasn't just an article. It wasn't just a blog post. It was this whole web experience. Well, it's not oversell it. I mean, there's no 3D graphics. Or was there? I've got some animation.

You've got a lot of animation. But in this biquad filtering section where Jay wrote some code and he ran it on each processor and looked at how long they took, it's got tabs. And one is about how fast it worked, the filtering speed for this filter, and then the

clock cycles and the power consumption and the efficiency, the power per sample. And they're different. I mean, you don't just look at one, like I was like, okay, so let's look at this pick and see how much it sucks compared to the MSP430. And- We're going to get so many emails. I know. And then you go over to the clock cycle one, and there's the PIC, and it just is hilarious looking. Although the PIC 16 is huge, and the PIC 24 is tiny. And then the PIC 32 is tiny. And so these are all really different chips, and they have different responses and so much variability that we don't always see.

Particularly, I get stuck in families. Like if you ask me what chip do I want to use for X thing. It starts with S and ends with T. My first response is, let me look in the family I used last for something similar because I'm used to it. And yet, what this is saying is that is not the right path. Yeah, the great thing about this is you can look at data sheets forever, right? And you probably can't figure out for your particular application what between half a dozen chips or even three. You can't keep this much in your head. Which one is better? Because you have to look at it from a system perspective,

which is I think what this does is say, okay, let's try this. And here's what happens to the chip when you exercise it in this way, which you can't answer on a data sheet, right? You can't say nobody puts on a data sheet. Well, we ran this code and, you know, with this much of it in Flash and this much in RAM and this is what you get.

And so there's really no way to evaluate without doing this kind of a deep dive. Exactly. And I think it was important to break things up into these different categories because, you know, so I've got an application right now that's basically a data logging system logs to nfc memory this needs to be deeply embedded running off us like a cr2032 battery like for multiple years right and you know i'm looking at how quickly i can process data on that and sure i can do it really fast with one of these arm parts but then you look at you know deep you know deep sleep kind of power consumption just doesn't hit it so you always have to be cognizant of all these different things. And and sometimes, you know, sometimes I just need something that filters it the absolute fastest. Right. Sometimes I need that, you know, eighteen hundred kilo sample per second by quad filtering. Who would have thought that I can take a 16 bit waveform and filter it on a $1 arm part at 1.8 mega samples a second. That's pretty crazy. You know, if you think about that, and that's not doing any weird optimization, that's just straight C code going into a normal bi-quad

filter, you know? And so sometimes you need that speed, but sometimes you really don't need that speed at all, but you need to do something kind of slowly, continuously, and you can't go into sleep. So it really depends on the application. And so that's really what I wanted to do with the testing. You know, what's funny is, you know, we look at the biquad filtering. Now, I also implemented a DMX receiver. So the idea is, all right, here's a classic sort of real world project. I've got an RGB, you know, DJ light, all right, here's a classic sort of real world project. I've got an

RGB, you know, DJ light, disco light, whatever. And I want to receive DMX 512 messages, which is a communication protocol commonly used in theater stage, you know, club lighting. MIDI for lights. Exactly. You got it. Yeah. That's a great description. If you know what MIDI is, that is. That's fine. We're not explaining anything. Yeah. So, you know, you want to implement something. That's fine. We're not explaining anything. Yeah. So, you know, you want to implement something like this. And I know it's a little silly, right? If you've got, you know, some 10 watt LEDs,

do you really care if your microcontroller uses 470 microamps or 500 microamps? But, you know, I think what's great about the DMX test is it shows kind of a different side. It shows which parts are really good for sort of low power, running all the time, shuffling bytes.

What I consider is like classic microcontroller work. I don't think of like DSP as sort of classic microcontroller stuff. Most MCU projects that I'm dealing with are basically reading in bytes, using peripherals, doing just a little bit of processing

and doing something with them. And here what's funny is look at how the tables have turned. All of a sudden, the microchip PIC16, which was like the worst in the last test, is now like the best in this test. You know, it only uses 470 microamps when running this DMX receiver. Now, there's other micros that do a little bit better than MSP430. Of course, of course, got to give that a shout out. Problem with the MSP430 is it costs like 10 times more than every other part for the same specs. Not 10 times, two times. Unless you're looking at the AVRs, then those cost 20 times what everybody else has for the same specs. Except if you're

looking at the new tiny AVRs, which are actually priced competitively. Yeah, exactly. Yeah, they're new to everyone. The new one series. And that was, you know, this is, I think, one of the first major blog posts that you'll see about the new tiny, tiny AVR one series. They're not very popular yet among hobbyists because of sort of the limitations in programming and debugging that we were talking about earlier. So, yeah, there's a lot of different stuff going on. And I just wanted to get it all on the page and sort of let everyone dive into it and figure out there's like so many little

sub stories. We could talk, as you guys know, for eight, 10 hours about this. You know, the STC8 is a single cycle 8051. And it has like an ISR latency of six cycles. And that doesn't mean like six cycles until it hits your ISR, sort of your preamble or your prologue and your epilogue code or whatever. No, six cycles until you hit your C code. And that's pretty crazy. That's way better than any ARM chip can do. And so, you know, if I were building, I don't know, like a quadcopter or something that, you know, I need really fast latency, I might look at an SCC8. It's an 8051 part, does not have good math performance due to the compiler, due to Kyle C51, which does not do a good job of compiling math. But if it's fast enough, then combine that with its low ISR latency

and you've got maybe a useful system there. So there's like all these little stories, all these little threads that I hope people sort of discover by looking at the data. And so you're super, super tired of people asking you which one is the best, right? Yeah. Choose a micro for me. I need to make something with Bluetooth and a sensor and the internet.

And the light. The internet. Also the light. It's always got a light. I will say one of the problems is today we've got, everything is about internet of things, cloud connected, smart, whatever, you know, all these buzzwords. And, you know, not one of these parts has, you know, any sort of radio on them. They can't do Wi-Fi or Bluetooth

or anything like that. And so I think in many ways, these parts are people, people don't think of these as being kind of new and sexy parts for their projects because they don't, you know, attack that IOT craze. But they're a dollar, but they're a dollar. They're still super relevant. And yeah, so I just think that I think that any of these parts, almost almost every one of these parts has a area that you're trying to target or what you're trying to do, where you're coming from, then I think that that's a lot easier to make recommendations. Well, you know, we have a lot of venture capital and we're building an experience. Right. And we have catered lunch. Well, I think we just need to synergize a little bit on this and really, you know, get started on the ground floor and really just, you know. Okay, okay.

So I have a system that needs at least 100 milliseconds. She's putting it into this. A sample time of, I need 10 hertz sample from three different ADC channels, and I need to control a display either directly or over SPI, and I need an I2C to control DAC output. What kind of display? A little, oh, because it affects the RAM, doesn't it? SPI LCD. SP oled um 128 by 64 oh okay so small yeah small i and you want to get those with embedded frame buffers do you want it to be like low power or do you want it to be really fast to get the prototype off the ground

i want it to be fast to get the prototype off the ground. I want it to be fast to get the prototype off the ground, but I'm willing to do some work to get the sleep current down. Running current, no, I don't care. But the sleep current, I want to be nothing. Okay, I'm going to go back to it. Grab the Sulcan Lab ZFM8. It has plenty of RAM to do what you're talking about. You don't need, most of those graphic LCDs

don't need a frame buffer in RAM on the microcontroller. You can just tell it to update pixels here and there. These things have great sleep current. They have a completely free development environment. So you get Kyle C51, which is like $4,000. You get it for free when you download Simplicity Studio. And it's unrestricted. You can use it for commercial, non-commercial, whatever.

No one cares. Great code gen. So even if you've never used the part before, you'll be able to get going really quickly with it. And you can get low cost debuggers for $10 to $12 for clones on eBay. Otherwise, if you've got a Jlink laying around, go grab your Jlink, plug it in and it'll just work. They're great little chips. Okay. So for people who want to ask you this question, of which I am sure there are a bunch, are you going to charge like 50 bucks for a description to processor conversion? Well, I'm currently training a neural network to do that, to do a text processor.

Yeah. A little chat bot that will... Oh, I'm sorry. Okay. Yeah, exactly. One of the interesting things about this whole process is the assumptions that we make. And the... I mean, my assumption is I'm going to use the chip family I just used because I'm lazy.

Did you change your mind by doing this did you start out with assumptions that ended up being changed through the process totally so uh one thing we already talked about flash flash prefetch i'd seen that word bounced around i knew what it was uh i did not realize just how much it affects everything in terms of performance and power consumption. And then another thing is compilers. I sort of assumed in 2017. So I always knew that, you're making a lot of assumptions about 2017 that I don't think are holding up. I know, right? Yeah, it's terrible. I just sort of assume that, you know, okay, GCC is sort of the gold standard among hobbyists. And for some reason, I always thought of that as being more because it's free and open source. And it's just like super FOSS friendly. But then in my testing, I realized GCC produces really, really good code. It's really good. I tested it's really good these days, you guys. I was surprised. On ARM? Exactly. I tested

it against MDK, the gold standard ARM compiler. And MDK's terrible with math code compared to GCC. And I tested Kyle C51, this $4,000 compiler for the 8051. Kyle is terrible

in just performance. It has it will, it has no concept of inlining math code. So every time you do any sort of math operation, that's non-native to your architecture, it has to push a bunch of variables into memory and call, call a function, a little math routine. And that, you know, and it's just, it's really, really slow. And so I think that those were sort of the two main things that I walked away from. I, I will say one more thing. Um, there's, I thought that there, this is, this may be odd, but I thought that there was more variation in value than there turned out to be. I sort of, I sort of remember being like some microcontrollers that just seem like they just

offered so much more value than other parts. But you know, what's interesting is most of these chips, you know, I don't know, like if we're counting peripherals or everything like that, there's sort of like the outliers that offer bad value. But among the vast majority of them, they all have fairly similar sorts of configurations. You can do most general purpose projects on any of these. Now, like we said, the MSP430 is very expensive. So when you're buying a $1 MSP430, you're not getting very much. Same with the Cypress stuff. But honestly, among the ARM chips and the 8-bit chips, the EFM8 was fairly well endowed, but the tiny AVR, really nice, really nice peripheral set. Even the PIX16 has a lot of peripherals going on for it. And so,

you know, you can sort of get, I'd say you can extract the same value, you know, peripheral-wise from almost any family, you know, if you shop around a little bit. And that was actually kind of a nice surprise versus some of the sad surprises with the Flash and the compilers and stuff. Did you find much correlation between price and value? I mean, because these weren't all 99-cent chips. Some of them were a great deal less. Yes. And I guess when I say value, I'm really talking about like true value, which is, you know, the amount that you get for the money.

You know, if you look at like a tiny AVR one series and an EFM eight, these are both eight bit parts that cost about the same for the same memory configuration. And they turn out to have about the same in terms of peripherals, you know, and the same goes with the arm chips. You know, these are definitely closer. Most of them are pushing, you know, ninety nine cents, even a dollar even. Now, among the ultra cheap parts, you know, those also have about the same value. They have less peripherals. You know, the Holtec HD66, you know, has way fewer analog to digital converters. And it's got analog to digital converter channels, I should say. And, you know, timers and things like that.

But it's also a lot cheaper than some of the other parts. So I think there is a lot of similarity in value across the board, I will say. And there you have it, folks. Economics works. Exactly. But the dynamic range between the top and the bottom in the $1 set, is that comparable to the dynamic range between the top $1 and a $10? Yeah. Ooh, no, no. I think that once you get above a dollar, it just turns into wild west. I mean, there is, yeah, it just gets really crazy really quickly and things just change so much. You know, last time I was using STM 32 F4 in a project, I think I was paying nine, eight or nine bucks for them at quantity. Not big quantity, but still at quantity.

I just bought a couple of ScoreBot robot things, and I've been working on an open-source motor controller for them. And I grabbed an STM32F4 from Ally Express. I think they were $350 a pop. It's crazy. So pricing has been really volatile. And there's new parts that are coming out all the time. And it's really shifting things around. I think that there's going to be some of these microcontrollers probably need to be axed.

They probably do not need to exist anymore. Like the Mega AVR, I don't know why it really exists anymore. The Sanio LC87, that can go away. STM8, not really sure why that exists anymore. Like the Mega AVR, I don't know why it really exists anymore. The Sanio LC87, that can go away. STM8, not really sure why that exists anymore because the STM32F0 is just so inexpensive. And the main difference between those two is the 8-bit versus 32-bit. It's not power consumption. The STM32F0, the ARM version of the STM8, uses about the same amount of power. In fact, it uses a little bit less. So there's some of these parts that can probably go, and they tend to be toward the lower end. But honestly, I think that everyone's sort of,

and I don't know if everyone's kind of on the same page, but everyone seems like they're sort of hugging that $1 price break and trying to get really close with it. But then, yeah, as soon as you go above that, everything just gets crazy. There's so much stuff out there. In five years, you're going to have a 1 gigahertz something with a GPU for 75 cents. Oh, in three months, I'm going to have to delete this blog post because everyone's going to be yelling at me because it's going to not matter. None of you can run Linux, you know. I mean, what's wrong with you?

Yeah. Given what we have now, all of these processors that cost less than a buck, what technology does this enable? I mean, looking towards the future and not just at our tactical needs right now, what does this variety and value give us? Well, for one thing, really smart 555 timer projects. I think, yeah, so in this price range, you're not... So one problem is...

So what I want to talk about is smart dust. This is, in my lab, this is sort of the... Ooh want to talk about is smart dust. This is in my lab. This is sort of the. Oh, I heard about this in 1999. Yep, exactly. This is sort of my advisor talking about, you know, just taking a bucket of paint and painting the sensors on the wall. And, you know, we're not there yet. None of these chips have connectivity.

But what's interesting is because these chips, you look at the performance that you get at a dollar. The cool thing is what you get at $1.50 is now you get Bluetooth connectivity, right? You can get Nordic or Silicon Labs or TI. Well, maybe not TI, but you definitely get Nordic and Silicon Labs Bluetooth solutions in sort of the $2, less than $2 price range. Less than. I mean, you can get TI in there too. Yeah, yeah, I bet you can. Maybe you'd have to go up to $250 or $300. Yeah, yeah.

So I think that like, you know, looking at things like that, that's where, that is, you know, the next frontier. But I think that there's going to be a lot of products that we don't necessarily think of typically using microcontrollers. And what I think of is dumb things that aren't cool to talk about on podcasts. But wherever you have a mechanical switch and a relay sort of weird thing, like an electromechanical sort of system. No, you just put a microcontroller there. So I'm imagining lots of soft

switches for everything, you know, in the future. A microcontroller and an accelerometer and you never need another button. Exactly. Exactly. And you can do more things than, you know, tap on, double tap off, triple tap to dim. It could do all kinds of things. And that's exactly. And you look at uh the low cost of power fats which that could be a whole nother blog post you just look at where power electronics are these days it is insane how cheap this stuff is getting so you add a triac or a power fat a microcontroller and you know something like the lis3dh or one of those really low power IMUs that some of these things run at one microamp. Like they're running, collecting data, one microamp. Crazy.

I mean, not collecting fast data or maybe not collecting super accurate data, but collecting data that is good enough. Yeah. I mean, 8-bit, 100 hertz data. That's pretty good in my book. But yeah, of course it depends on the application. So you are a grad student and you are a contractor. Has this led to more contract inquiries for you? Yeah. So when I published this, I had six job offers the next day, all from probably less than reputable startup firms. And, you know, I haven't, you know, I need to do a better job of sort of connecting with people and getting back to them. I'm sure

that this has got my name out there, which is nice. But you know, the main idea was was just to get the ideas out there. You know, I really like the idea of people getting comfortable with hopping on DigiKey, finding a part that's actually right for the application, you know, regardless of who lasered, you know, whose logo is lasered onto the package. And, you know, so that was sort of the whole reason for the blog post.

Everything else is just, it's kind of a nice side effect. Okay, what about the other side your your graduate degree is this is this an area of research for you is this an area of interest for research for you i don't think that there's really much here that's academic you know it again in 2017 i don't know that you're going to be writing conference papers or journal papers on anything in this in this realm. You know, I'm I'm mostly interested in trying to trying to do robotics work with deep networks and sort of plug those two things. And that's that's sort of my my current project that is on my desk and hopefully will turn into a dissertation in the next 20 years. And, you know, I'm trying to focus more on that sort of stuff. I did a lot of wireless sensor network work before, sort of got burned by that project. You hit a glass ceiling pretty quickly

with publications because it's just, there's a lot of that stuff's done. You know, a lot of those problems have already been solved. Yeah, deep learning in arms. I understand. I have some interest there. Yeah, there's some really cool stuff. There's, you know, Google has been doing some really wacky, they lock, you know, 20 robots in a room

and train them for three months on picking up things. And they learn how to pick up different objects. And there's some really cool stuff there. And I think that there's definitely some insight that I can bring to that from sort of my other areas of expertise. And if anything, it's actually,

it's nice to keep my lab work very, very, very separate from my contracting work. Because if I had to go to work every day in my lab and design PCBs and program stuff, and then come home and do the same thing, I would probably kill myself. So instead of killing myself, I work on very different things during the day. And then when I get home, that's kind of my time to play around, you know, in Altium and, you know, in my, you know, IDEs and work on embedded stuff. It's really great. I understand. If I'm writing code at work, I'm probably writing words at home. And if I'm

documenting at work, I'm more likely to do code at home. So I totally understand that. Yeah. The separation. And what's great about it is, as you probably know, you're at home working on something completely different. And you have an idea or it inspires you and you go to work the next day. And, you know, I always try to keep, you know, everything on the table. And I'm trying to, you know, you asked me earlier, you know, one project or a dozen. And I always try to be super busy with everything because there's all these connections between different areas of engineering and just different areas of life

that all combine together and form really interesting connections. No knowledge is ever truly wasted. If only learning it itself is a good exercise. Yes. We have kept you for long enough, and I actually have a whole bunch more questions for you. And this has been wonderful. It's been really great to go through these and think about my own biases and all of that. But is there anything you'd like to leave us with, a thought to leave us with? Well, I just, you know, I hope that this project has inspired people to get comfortable kind of getting out of their shell, looking around out there, seeing what other people are doing. If nothing else, if you go through my code, if you go through my discussion, you'll see that it's never been easier to pick up a new part. You know, a lot of these parts I picked up and did, you know, wrote all this code, all these examples, did everything from start to finish in like a couple hours. Like it's incredible how fast you can get going on a

lot of these parts. And it's never been a better time to, you know, reach for something new and, you know, try to find a new part for a new project. Every time you start a project, especially if it's a personal project, if you're not on the clock, go grab a part that you've never used before, try it out, see what you like about it, see what you hate about it, and come back and comment on my post and start a discussion. This is good advice. Our guest has been Jay Carlson, an electrical engineer specializing in electronics and embedded programming. He is the author of The Amazing $1 Controller, an in-depth exploration of 21 different controllers. It will be linked to in the show notes, of course. And Jay, thank you so much for being with us. Thank you so much. Thank you to Christopher for producing and co-hosting.

Thank you to Ian for asking about pics. Boy, you didn't really think we were going to just skip over that, did you? And of course, thank you for listening. I have a quote to leave you with from Claude Shannon. And I think it's funny that Jay says he works on dozens of unfinished projects and yet he finished this incredible survey. So Claude Shannon says, authors should submit only their best efforts and these only after careful criticism by themselves and their colleagues. A few first-rate research papers are preferable to a larger number of poorly conceived or half-finished.

The latter are no credit to their writers and a waste of time to their readers. Embedded is an independently produced radio show that focuses on the many aspects of engineering. It is a production of Logical Elegance, an 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.