Embedded - 167: All Aliens Are Shiny

Episode Date: September 7, 2016

Chris and Elecia chat about Bayes Rule, aliens, bit-banging, VGA, and unit testing. Elecia is working on A Narwhal's Guide to Bayes' Rule.  ACM has a code of software engineering ethics Toads have trackers (NPR story) An introduction to bit-banging SPI (Arduino, WS2812) We talked to James Grenning extensively about testing on 30: Eventually Lightning Strikes (and about his excellent book Test Driven Development for Embedded C). We spoke with James again on 109: Resurrection of Extreme Programming. We also talked about unit testing with Mark Vandervoord on 103: Tentacles of the Kraken. A neat TED Talk involving octo-copters, still four short of dodecahedracopter. Neat Z80 based very minimal computer kit    

Welcome to Embedded. It's just Christopher and myself this week, and it may be a short one because it's summer here finally. Well, where do you want to get started? I just feel like you're always rubbing the weather into people well it's the weather or the otters or you know the dolphins it's something yeah I think you're overselling it

my feet are so cold right now I can't even tell you it may be summer out there but in here it's an icebox it is a basement okay so that was it, right? That was the show. Have a good week, everybody. We'll be back with...

Next week's guest is pretty interesting, actually. I'm not going to drop any hints other than that. Do we have any contest winners to announce? That's not happening yet? No, but thank you for reminding me about the contest. We do have the contest that Bob Apthorpe suggested.

He's giving away three books, and you need to send me a number. And when I said unbounded, let me just say somebody has already chosen Graham's number, which is unimaginably large, I think was the definition of it. Yes. Had more digits than could be fit in atoms in the universe or something like that so yeah um that one's taken and not a winner yeah and i feel like i should remind people that the goal of these kinds of contests is to get the number closer to the chosen numbers so unless one of us had chosen Graham's number, it feels like that's the I don't want to win position.

Even if I had chosen, what is it, a Google? Yes. That's still, if somebody else had chosen zero, Graham's number would not win because it's, on the other hand, I am learning about all sorts of interesting numbers. So, you know, either way is fine. I'll give a hint. The one I chose is a perfect number. Is it? It would be nice if I remembered which one you chose, but happily I wrote it down.

I don't remember which one I chose either, but I do remember it was a perfect number. Okay. So there are three numbers in play, and we need them by October 1st. People have complained that the contests don't run for long enough and you're behind on your podcast listening. So this is a long one.

Well, it's been summer. People are obliged to listen to every podcast the instant it comes out. No, no, they're absolutely not. I mean, we don't like them as much if they don't, but, you know, it's no requirement. I don't really grade my friends on whether or not they listen to the podcast and how quickly they are up to date on my current content. Seems like a good criterion as any. As any, no.

What's on the docket? Well, speaking of current content production, I do want to say that Andre's new series about the STM32F4 Discovery Board is starting out and going along. It's going to be pretty cool. Where Svek takes a very microcontroller and let's look at this from the assembly perspective. Looks like Andre is going to start more on the, so a data sheet, data sheet has a lot of information, can be kind of confusing. So let's talk about what's the useful parts. And he's going to talk more about the, um, cube MX and, and all of the things surrounding ST and their, their environment so that you can just get started. Of course, it's never quite just get started. Especially since didn't they rev the board

after he wrote the first entry? They did rev the board. That was his first entry. Well, crap, this isn't an entry. That's invalidating all the prep he'd done. Yes. And I am working on a two or three part series in which I try to explain Bayes' rule,

which is the same as Bayes' theorem, which is pretty much the same as Bayesian inference. And I try to explain it in terms a narwhal would understand. And if you don't know what a narwhal is, it's the unicorn of the whale world. It's awesome. And they're real. There's no proof of that.

There's actually a lot of proof of that. So, would you like to briefly explain Bayes' rule without the aid of visual narwhals? With a whiteboard, that makes it a little harder. Well, in my posts, I've been doing it in sort of a comic book style. And one of the things that has really been useful for me going through it is the idea that it isn't just one thing. It's how you update your current predictions based on what's in the world. And so that has machine learning aspects to it, of course, because your robot needs to update its understanding of the world

every millisecond, every minute, whatever timescale your robot's working at. But it's also used in forecasting and predictions. People like Nate Silver who do the political predictions or even, I've heard it's used a little bit in weather, although that one doesn't make so much sense to me. But it's a way of taking what you know and what's likely and what's unlikely and putting it all together in a way that allows you to to make sensible choices and there's been some small tiny group that says you should apply this to your life all the time i don't know that i believe for that but you know it's it's kind of neat and it's one of those terms that people run into and then you see it explained in a statistics book and then you run away from it every other time that you've ever seen it. So I'm hoping to make it friendly.

So that was all very general. Bayes' rule in particular is about how to compute conditional probability. Oh, yes. Right? So you have two things, two events, and they might be independent, but they probably aren't, and you know something about the probability of one event,

and you might know something about the probability of the other event, and you might know something about the combined probability, but Bayes' rule says, given I know this, what's the probability of this other thing? Is that right? Sort of. Okay, correct me.

So let's take the idea of you see a light in the sky and it's weird. So weird light in the sky. What is the probability that that is a UFO? 100%. Given that you have seen a weird light in the sky. And I'm using this example because somebody tweeted at me. It is unidentified, therefore it is a UFO every single time. All right.

Aliens, let's go with, what is the probability it is aliens? 92%. Given that it is a light in the sky. All right. So now, if you look at it just without any useful forward thinking, it's the probability of both of those things. It's the probability of seeing a light in the sky, which you don't always. You don't always, every time you look up, you do not always see an unidentified light in the sky. Okay. And the probability of it being aliens.

Okay. So you have to think about it as both of those things are happening. A lot of people are like, well, what's the probability of aliens? What's the top level question though? Are there aliens in the sky right now? The top level question is, given I have seen an interesting light object, are there aliens in the sky? What is the probability of there being aliens?

All right. It seems weird to me that you take into account the probability of there being a light in the sky. Well, you do have to because it acts sort of as a normalization problem. I see. Because, you know, right now there's one giant light in the sky because it's daytime probably definitely aliens and it's not it's not unidentified so you know there's some okay and that goes back to you need a and b to be true got it you need both conditions both the light in the sky and the aliens and so the that that whole is it aliens given I've seen light in the sky, is equal to this first part that's sort of the likelihood. And that's the weird one that people look at it and it's like, that's just the opposite of what you said before.

So, the first part is, given that there are aliens in the sky, is there a light? What's the probability I'm going to see a strange light? And that's the funny one. I mean, given there are aliens, no matter what the probability of aliens is, but right now we have aliens, what is the probability there's a light in the sky? Because you know what?

Aliens should be cloaked. I mean, really, shouldn't they be? Why do you expect a light in the sky just because know what aliens should be cloaked i mean really shouldn't they be why do you expect a light in the sky just because they're aliens so that's zero already so you're done well it is maybe that maybe there are you know one percent friendly aliens who come maybe it's the close encounters aliens who have the christmas tree lights all over their ship they did have lights so you do have to know that probability you can't really go on unless you can make an estimate of that okay um and then so so the that's the likelihood of when people talk about likelihood that's sort of what they're talking about is that

you have you had a given b and now your likelihood is b given a and you're like that makes more sense when you talk about what's the probability of getting a positive test given that I have a disease or given that I don't have a disease. What is the false positive rate? Sure. And then you're looking at the other side

when you're looking at, do I have a disease given that I've gotten a false positive? It starts to make more sense with statistics. Okay. Aliens less so. Okay, so now you have the likelihood, given that aliens are here. So let's just ballpark this example for fun.

Okay. So let's say aliens have to have lights on their ship. No cloaking devices. Okay. So if there are aliens in the sky, then there's definitely, so that's a, then there's lights. Then there are lights so that that's a then there's lights then there are lights so that's a very high probability let's call that 90 okay so all

our aliens are shiny yeah okay all aliens are shiny we're making so many good show titles right now uh so the next next term is the probability of aliens and that's probably well alien let's let's let's specify that a little closer are you gonna look it up no i'm not looking you're gonna look up the aliens no i'm looking at bay's rule i'm not looking at bay's rule i'm just making sure that i got this right yes it is the probability of aliens is the next term. Probability of aliens in general? In the universe? In the universe. It depends on where you want to set that.

If you want to start with the probability of aliens visiting Earth. Okay, so that, let's say, is very, very low. Okay, so now you have something that's almost true with something that's very low. Yeah, so 0.0001. And now you're going to divide both of those terms, which you've multiplied, by the probability of there being lights in the sky. Which is high. Which is pretty high.

It's pretty high. So you've got a small number. Not 100%. But, you know, you probably see strange lights maybe once a year. So the way we've built this we've got a number close to one times a very very very small number so we get another very very small number divided by a large number so the probability of it being aliens when you see lights in the sky is low right based on our completely bogus ballparking well that was one of the things I wanted to do with my drawing was to do that ballparking.

Don't worry about what is the exact probability. But there's highs and there's lows. And if you have a high times a low, all right, that's usually a low. And if you divide that by a high or you divide that by a low, it changes it. It was kind of fun in the comic I managed to prove, where prove is definitely under air quotes, that unicorns are more likely than mermaids because there are fewer land-based animals with single horns than there are marine-based mammals who sing.

I know, it sounds tortured, but I've been having a good time doing it. And so that's been my project for the blog. So where would you use this as a software developer and embed it? Does it come along with things like Kalman Filters? No, the chances are you won't use it as an embedded software developer. and embed it? Does it come along with things like common filters? No, the chances are you won't use it as an embedded software developer. You'll just hear about it and then you'll be in a meeting and it'll be, oh, I'm not even going to ask you a question because the last time I saw that it was so intimidating.

But it does revolve around machine learning and how they come up with algorithms. Okay. When we talk about like the aliens given the lights in the sky, the lights in the sky is a feature. And then you're trying to figure out the probability of some event given a feature. But when you talk about like gunshot systems, gunshot location systems, you have features of how loud is it? How far is it? Is it high frequency or low frequency? And you start adding these probabilities all up and you can get a good sense of,

is this a gunshot or is this a basketball bouncing? Even though initially they're both just impulsive things. Can you think of simple examples for like robotics and stuff where it might be navigation or trying to pick out some object in the visual field? Are you reading ahead of my notes? No, I'm generally curious how you could use this because, I mean, I did all this in college and forgotten it all, but, you know, now I'm thinking about it and going, well, I mean, you could have a little tiny, you know, you could build the equation for a certain conditional probability you're interested in for a kind of motion or action you want a robot, robot? Did I just say robot? A robot to take um well in the in what i worked on today actually was um the page where i have a

treasure that my sailor has found he's the narwhal's friend boy this really just gets weird i have a treasure undersea treasure and it's cursed and you can only take one and you have to close your eyes and there are round pearls and there are coins that are gold and coins that are iron now when the coins feel the same the coins feel the same now given that you want to take spherical things because those are more valuable but then i dump some marbles in and i add coin pearls so now everything's kind of weird and so at each stage do you want to take spherical or do you want to take coin and that's going to be dependent on what's already been taken out of the system and that was where I ended up building a robot mentally drawing graphically

not really conceiving of a robot. And so the robot chooses based on what's left. And that's a simple, you know, it's a while loop. While the robot is not evil, if the probability of spherical having good stuff, the probability of good stuff given a spherical object is greater than the probability of good stuff given a coin-shaped object, then take a spherical, otherwise greater than the probability of good stuff given a coin-shaped object. Sure.

And take a spherical, otherwise take coin-shaped, and then repeat. Update all your probabilities and go on. But you need to keep track of your probabilities as you go along. You do. And the way that I set up the problem, unfortunately, Bayes' rule isn't that important. I mean, it's a reasonable example because you're using the equation and getting accustomed to it, but it goes back to, at some level, we're talking about the A and B

being true. I mean, A given B, sure, that's Bayes' rule. But in the end, if all you really need is a static solution to a static system, it's A and B. And probabilities are easier to calculate than the Bayesian probabilities. If you have all the other information. Yeah. Okay, so that's cool. You mentioned people saying you should apply this to your day-to-day life. And I was thinking about that, and I think, well, humans are bad at probability, number one. They're really bad at probability. But one. They're really bad at probability.

But we're really, really bad at conditional probability. Yes, unless you think about it. Intuitively. Yes. And so this, I mean, it's kind of fun to go through little mental exercises about maybe things that bother you. Like, say, flying on a plane. That's actually one thing. That's like two pages from today.

I'm sorry, I'm writing you a thing. But yeah, but you can go through and say, well, you know, flying on a plane, let's make it an example with probably more realistic consequences, like flying on a tiny plane or something like that, or a hang glider, something that's a little bit dangerous. You can look at that and say, well, how likely is it given for me to crash on a hang glider? Right. What is the probability of crashing given that I am on a hang glider?

Right. And Bayes' rule teases out that little piece that would say, how often am I on a hang glider? Yes. That's the divided piece. Yeah, and that's the important part because if that number is very, very small, your likelihood is... Well, there's also the probability of crashing. Right. I mean, what is the probability of crashing given I'm on a hang glider? The probability of crashing overall,

given all of the other sorts of ways you can, you know, motorcycles and cars and helicopters and all these other things. Oh, the probability of crashing in anything? Well, it depends on where, yeah, you can take, that's how you end up with things like it's twice, you're twice as likely to be in a wreck if you're in a car. Yeah. Because you're twice as likely to be in a car.

Right, right. Or a million times more likely to be in a car. Yeah, and that's the piece that people. You have to normalize these things out. But that's the piece that's interesting because you don't think about that intuitively. You only see the top level probability of some event happening from some aggregated statistics over the entire population. You don't have a chance to say, yes, but how often am I doing that thing?

Or, yes, but here's another piece of information that changes that, that's specific to my circumstance. And this rule allows you to incorporate that information, which you might be able to do a back-of-the-envelope calculation and say, oh, well, that thing I was worried about, yes, this statistic says it's reasonably likely, but given this aspect of my life, it's less likely. That's all. Yes.

And it lets you look at statistics that you might not otherwise consider. Like, I plan on doing the whole crashing with airplanes problem, given all kinds of crashes. Well, if you start to think about that, and you start to think about all the other ways you could achieve this event, given all of the other features, all of the other vehicles, all of the other, you know, bicycles. You should encase yourself in concrete. Well, either you come up with that or you come up with, well, you know, hang gliding isn't that dangerous. See, I don't think that's the conclusion you want to draw. Or that thing we saw this weekend, which was...

Kite surfing. Hang gliding from a surfboard. It was, yeah. Or something. It looks like fun. It looks like a great way to break all of the bones in your body. Yeah, maybe that's a good kingdom of our business.

Given that there are 40 kite surfers in a quarter mile long length of beach, what is the likelihood that they're going to crash into each other? You kept waiting for them to tangle their kites, but I think they were further apart than they looked. Yeah.

We'll put a picture up. Okay. Well, that's enough on that. Thank you for indulging my interest. I hope people out there are like, you can't do this without a whiteboard, because I feel like you can't do this without a whiteboard. You can do anything without a whiteboard.

It's just whether you can do it well. Yeah, and this sadly was lacking in narwhals. Okay, let's see. Steve, quite a while ago, emailed us and said he wanted to give us a show idea. And Steve, I have to admit, I like your show idea very, very much. He was listening to NPR and they had a story about reintroducing endangered toads. Was that this NPR, computer NPR or regular NPR? Regular NPR.

And the interesting part was that every toad had a tracker attached. And Steve wanted me to talk to the person who built the tracker and I looked I mean I seriously looked because I thought that would be awesome I could not find the person I could not find the company I couldn't find anything useful to get me to that person so that's the end of that story I'm Actually, it was more of a call for help. If anybody out there knows how to track toads, we would like to hear from you. All right. Let's see. So Daniel says it would be awesome if we could produce a show that gets into some of the challenges and details about what it would potentially take to move an electronics project from maker to consumer level.

He's been working on a handheld device for a while and feels he's about to hit a wall of ignorance in his effort to get to market. Yeah, that's a big one. We've touched on this before when talking about our lately it's been well even when we have we've only touched on it yeah but we've talked about arduino and i'm not saying that's what's happening there but um yeah there is a big gap between prototype and and production and i don't know i mean it's a know. And it's a steep gap. It's a steep gap. Well, it depends on volumes.

Yeah, if you're making consumer products or medical products, it's so much more work than you can imagine. Because now you're talking hundreds of thousands to millions. Medical products, maybe not. But that has its own separate issues with FDA or certification problems. Yeah, I don't think we want to do that today, but we should certainly find somebody who would be good to discuss that with. I was thinking about talking to one of the hardware accelerators

and trying to get somebody from there. And that's, I think, what you really need if you're going to. I don't think I would recommend anybody try to do that on their own, especially if they don't have the experience. Yeah, that can be an expensive and scary proposition because they do want quite a lot of your business. But having it fail because you can't... Do it at all. ...fulfill your orders is pretty heartbreaking too.

It's funny because we've gotten to this weird position where you can build pretty sophisticated stuff with modules and without, you know, a lot of hands-on electronics. Basic understanding of electronics is all that's necessary. When in the distant past, say the 80s or the 90s, you know, you had to build your own board and you're probably out there, you know, pouring etchant on stuff and making pcbs yourself if you wanted uh maybe you did it on a breadboard but you're still wiring things up so it was a lot closer to where am i trying to go with this it seemed like it was a lot closer to i understand what's needed

to produce this thing than buying a microcontroller with a board which somebody some other companies already spent you know a year two years developing and putting through mass production so you're you're leveraging somebody else's mass production to make your prototype but that doesn't help you get from prototype to your own mass production well and selling things is remarkably difficult well don't i mean i even don't even know how to comment on that it's just just, you know, we're engineers and we're like, if I build this, they will come. And if only, but there's so many other things and the noise to get past everybody else's small widget is very difficult. And I would remind engineers, we're pretty stupid about's a lot of products out there that I've been involved with that I've thought, this is going nowhere.

Who's going to want this? And then it sells like gangbusters. So I don't understand what makes a good product. I really don't understand what makes a good product or a product that's going to catch on in the market. And vice versa. I mean, there were companies I worked at where I was sure, this is going to be a hit. This is the greatest thing ever.

Look at this advanced technology we've put together. You know, we built the space shuttle six times over. Everybody's going to love this. We're going to make millions. So, yeah, don't be too sure of your market prowess. On the other hand, Kickstarter and even Etsy with their tiny electronics, their custom bespoke electronics. Wow.

Please don't make that a thing. Please don't make that a thing. No. Might be cool. Artisanal bespoke electronics. Well, I think it's more for things that are built into art. Yeah,

sure. But that's a way to dip your toes in, but even that's a pretty big... It's a way to gauge if you have a market, but it's also a way to get in deep trouble. It really is.

Okay, moving along. Good show idea. We'll work on that. Carmen Parisi from the Engineering Commons show asked over Twitter, if he wanted to bit bang a bus that's close to SPY, how would he go about getting started? He's doubly not a software person, so we definitely have to take that into account. So have we defined bitbanging before? I don't think so. Okay.

If we have, it was just a throwaway comment. So sometimes you end up with a processor or even a peripheral, but mostly it's a processor that doesn't have the peripheral communication method you need. It doesn't have SPI or it doesn't have I2C. Or one wire. It doesn't have the peripheral communication method you need. It doesn't have SPIRE. It doesn't have I2C. Or OneWire. Or there's some wackadoodle peripheral communication that the peripheral needs, like OneWire or my rolled-up version of OneWire because I had to do it different because I don't like standards.

Somebody out there is doing their own thing. Right. And sometimes you have processors that can support these. You kind of shove NeoPixels or the WS2812 LEDs. You can shove those into SPY if you work at it. Okay. The timings work out and you just have to, it's not normal SPI, but it's close enough.

But the basic idea is you've got dedicated hardware on the processor that handles these buses. And if you're lucky, you say write to SPI with this address and it just does it. And it wiggles all the signals in the right order and does it at the right timing. And you don't have to worry about any of that. And it'll do DMA for you. That's really nice.

That's very cushy, the DMA. Now you're saying I've got a processor but maybe all I've got are GPIOs. Right. And so bitbanging is using the GPIOs to replicate a bus communication. And so if I wanted to do Morse code as a bus communication, this isn't the best example, but hey, I'm just talking here.

No, no, I'm going to take this and do it now. Morse bus. So let's say I have an accelerometer that speaks Morse code. And it's got one line that we both share. And so I have to say, when the line is down very short, that's going to be a dit and if it's down longer, it's a dash and we're going to communicate back and forth and I have to have like over or something, you know, some way to say it's your turn. But you can kind of imagine that spelling out the dits and the dashes with a timer.

You can say a dit has to be 50 microseconds, but no more than 100 microseconds. It has to have some timing. And a dash has to be, I don't know, say a millisecond, something horrifically long. And it too can only have a little bit of slop. It can always have some slop, but it has to have a little bit. Well, now you can do this with a GPIO. You can sort of picture how to do this because you're toggling it up and down. Your processor isn't doing much else because it has to keep on top of these things. Yeah, the timing has to be, depending on the bus you're using,

the timing might be very strict, and so you can't go away while it's doing something. You might be able to put it in a timer interrupt. Right. And then every time you do the interrupt, you do whatever state machine you have to do to get to the next step. So maybe if I'm doing SOS, I do a dit and a dit and a dit and a dash and a dash and a dash.

Right. And then that lets me sort of organize, queue the information that's coming through. But I'm still just, you know, GPIO up, GPIO down. GPIO up, GPIO down. Depends on the timing, but that is the only thing I get to change now if you're doing spy spy normally has the clock line which is which is clock and that's going to be pretty easy because you are going to put that one on a timer and then you have the well maybe well maybe okay well we won't put time. Because you want it to be synchronized with your data bits.

So you have data bits in and data bits out. And let's just work on the data bits out, because that's pretty easy. It's sort of like the Morse code. You have a clock, so you wait for some period of time to make the clock happy. You put your clock up. Now you wait for half period of time to make the clock happy. You put your clock up. Now you wait for half of a clock period,

and you put your data into whatever state it needs to be. And then you put your clock down, and the other person samples on the down of the clock. Now, whether or not you are sampling on the up or the down depends on your spy mode, and there's a Wikipedia article about spy, and that is there's a wikipedia article about spy and that's the only way i remember whether you're sampling on up or down and see for something as complex as spy you kind of want a state machine probably i think so i think you would want a state machine um but for

something as simple as one wire you probably can get away without that because all you're doing is uh one wire only has signal the clock is embedded in the in the data so you can kind of you have writes and you have reads and you just need to get the timing right and wiggle the the signal line on the other hand if you are doing um bit banging on a uart like serial. You have to have very precise timing because you don't have a clock to go along with this. You have to be 9,600 baud, plus or minus 10%, or the other person won't understand you. So I would say, as advice, I mean, I would read the data sheet,

not the data sheet, read the protocol specification for your particular thing. Probably the peripheral will have yeah detailed specification very closely and this might be one reason you're doing it because sometimes peripherals are a little weird and maybe i don't know in the past i've encountered peripherals that don't work well with a particular spy perf with a spy and i'm overusing the word peripheral a a device like an accelerometer or something doesn't really work with your spy master peripheral for some reason and so you fall back to okay i've got to do all the timing myself that's kind of a place you don't want to be in but

i can see that happening um because it is a huge suck on your processor it just doesn't it's not good. I did come across a tutorial about Arduino control of the WS2812 LEDs and they talk about bitbanging it and what I liked about this particular example was they did it in assembly so that you would really understand that the timing of this is critical but on the other hand you should read your datasheet that the timing of this is critical. But on the other hand, you should read your data sheet and make sure the timing, if it's critical, this may not be the processor you want to use.

Yeah, I mean, you should ask yourself why you're in this position to start with. But if you do have to do it, then you build it from the data sheet and I would build from kind of the bottom up. Okay, here's a write function, here's a read function, depending on the protocol, and then build on top of that.

But you're almost certainly doing a state machine because you need to do something at each clock tick. And I would advise people to write it in such a way that they can rip out the layer that does the bit banging. When they get a real processor. When they get a real peripheral so they don't have to rewrite a bunch of stuff that's all spaghetti code

and intertwined. But, yeah. I mean, the example I remember most was I came into this place that had already picked a bunch of hardware very strangely.

It was a PC, single board computer, so x86. And I guess it was running VXWorks. Yeah, VXWorks. And then they had national instruments, PCI boards for digital output.

And that needed to talk to OneWire. So it was VXWorks, you know, doing bit banging over an NI, digital outboard, digital in and out, doing OneWire. And that worked, mostly kind of. And that isn't an example of the processor being deficient. It's just

you had a layer that didn't work together. It was deficient because it was basically a general-purpose computer architecture, which doesn't have SPI or I2C or one wire. And back then, I don't think there were one wire masters on anything, so it didn't

really matter. You know, I mentioned in Spy whether or not you sample on the rising edge or the falling edge depends on parameters. Those didn't used to be parameters. Those used to be you had to get the right one, and one vendor had this kind, another vendor had that kind, and your peripheral had to work with the vendor. That's what I'm remembering.

And it was awful. And that is where BitBanging really, it's why we all know about it. But now, even I2C seems to be a lot easier to put in and a lot easier to manage. There's fewer derivatives, fewer wackadoodle separate things um so yeah okay so hopefully we've answered him and i will i will post this i don't know if this is called bit banging but there's lots of projects now where people make things wiggle in a processor to generate rf did you see the us, the code that runs on any USB stick and it does accesses to the USB stick

so that it will transmit radio waves to a receiver? So somebody can put code on a USB stick and plug it into the computer and they can steal stuff. That would be very slow. Because it's a radio transmitter. It was quite slow, but it worked,

which was sort of terrifying. It is also sort of terrifying. Yeah. Yeah, you can make, I think you can, I've seen projects where people make radio transmitters by just hanging an antenna off a GPIO and going to town with the thing. I'm not sure that's bit banging because it eventually becomes analog, so maybe it's just bit wiggling.

I guess we should have asked Carmen to ask his question, and then we could have asked this question back to him. Would have been fair. Okay, next question from Ben. You convinced me unit testing is good, now how do I get started? That's not my job. Ben is a software engineer, and he's having trouble getting started in unit testing with Embedded C++.

He tends to work with Embed or Arduino boards, but does that even matter? How does he set up a unit test? What tools should he use? Should he use hardware emulators or mocks? How do you actually do unit testing? Well, there is this podcast, and it's called Embedded.fm. We don't unit test the podcast. I don't know where you're going with this.

We've had a couple of episodes, is what I'm saying, where we've talked to experts on this very topic. James Grenning has been on the show a couple of times and he has a book um test driven development in embedded c i think it's embedded c and he has all of the answers to your questions it's it's setting up the environment it's it's separating whether you want to use mocks. And a mock is what? A mock is a lower level that fakes out your hardware. And he sets it up so that it all runs on your PC. And it's in C++, which is slightly odd, but it works. And we also...

The framework is in C++. Your code doesn't have to be. No. And it's pretty nice. I've used his framework at a couple places, and it's a pretty easy framework, and the fact that there's a book that tells you how to do it really helps. Which one is that?

Which framework? CppuTest? Okay, that's the one yeah yeah i've used that too and then we had another guest um i want to say vanderford come on you're expecting me to remember i think that's right tentacles of the kraken mark vanderford yes and he has throw the switch.org which is a good place to get started for test I think that's right. Tentacles of the Kraken, Mark Vandervoort. Yes. And he has throwtheswitch.org, which is a good place to get started for test-driven development. He has a couple of courses on how to do it and where he really walks you through videos. I seem to think James might be starting that as well. He has some online courses.

Yeah, I know he does training. So either one of those, whichever one of those sounds best to you is a good place to start. I would definitely just start with James' book and then branch out from there because it's easy to... Well, we're both book people. I'm starting to really understand that there are people who are video people.

And I'm not really one of them. Video people killed the book star? I see, maybe. Yeah. And then as for how do I use it, sometimes I use these frameworks. Sometimes I am in a client who really doesn't like those for one reason or another. Usually it's something about having been burned in the past about offline testing and online testing being different. And so with those clients

I usually do on-chip unit testing in a separate project where I'll test each module and have them build and compile and load separately. So it's an extra step it doesn't happen on every compile, and they get broken when other people change your interfaces. So it's not as good. It's better if your team can really do it together. It depends on your project, too,

because maybe you can run all your unit tests off-device, which is really nice, because then you can do it nightly, automated fashion, and you get a report back. Or anytime somebody commits something, that's a great one, because you immediately get feedback that, oh, this is broken, this thing that you didn't think you were changing. And I would say the thing that I think stops most people

from doing unit testing is a completionist attitude. Like, I've got to unit test this whole thing. Oh, no. I think pick the most important parts of your product the most important pieces of code maybe the core algorithm maybe the the thing that is doing most of the thinking and start there yeah pick pick the mathy piece pick the piece that you've gotten confused on twice now yeah or pieces that are likely to get some change pretty often.

Because I see a lot of things where people write a unit test for a module, like a device driver or something. And that device driver gets solidified really quickly. And then it never changes. And so the effort to do a bunch of unit tests for it,

it's questionable whether that's better than just having it locked down through the normal course of testing in the first few weeks of use. I don't know. I'm still kind of toying with this in my mind. There are times that unit tests overlap with manufacturing tests for me. Well, that's important, yeah.

And so those driver-level things, I like to put them in unit tests because I like to write the tests early and get them in for the manufacturing. I'm not saying don't do it, but be judicious about what you unit test. You don't have to do everything. Because you'll burn yourself out on it. That's what I'm worried about. And I think James said that.

You know, you do one improvement a day is sufficient. You just have to keep doing that. I don't know how you're going to unit test your one wire bit bang driver one thing we didn't talk about that derailing this and coming back for a second is the receive side if you have to bit bit receive that can be a challenge too because but then you have a clock and you sample yes on every um clock or whatever whenever you need to. But you may need to time things. But you may need to time things. Because if you are receiving SPI and you are updating not on clock edges, then you have to go halfway between what your clock is. It does get

confusing. But it's about sampling at the right time and making sure you keep doing it. Don't do that. But going back to this, Ben asks about Embed or Arduino, which made it a little harder to answer. Because Embed has their code online. Yeah. And then you have this step where you have to go online to offline.

Did they have any framework as part of the... They didn't last time I checked. Arduino's a little easier. You can fake out setup and loop by just making a C file that calls setup and calls loop at the right times. And you don't need all of the other Arduino stuff happening. But embed, I don't think they have a testing facility.

If I ever managed to get one of the embed folks on, we'll grill them about that. Yeah, that seems like a potential area for trouble. Although, I mean, you can export the code and use CPP to test, right? It just is a little painful. Yeah, it's another step.

And I think embed now has reasonable version control. Do you think people are using embed for products? Like, using the IDE and things? I think they are. There's a lot of stuff there. But as far as I can tell,

everything's public. Because I would expect people to grow up out of that much like they grow up out of Arduino and then move to standard tool set where all of this is possible.

I don't know. I've never used it for a product. I've only used it for a hobby. Yeah. I would certainly hesitate using anything like that for a product but then you look at the price of iar and a debugger and you're like well i don't have that much money to drop right now and this is free why are you making a product well there's that and it's not free because it's on every board not saying go out and buy ir if you're making a product or that everyone should have the quantity of money no no no i don't

want that to be a barrier but there's you know there's certainly embedded alternatives to ir that are not costly the entire gnu tool set for example yeah rolling your eyes. Oh, no. No, I want to like Gnu, but... But you have to see OpenOCD. If you named something OCD, I should have known I'd have to follow every step each time perfectly. Ah, Nahom from Ethiopia. This was sort of interesting. In my country, it is not easy to source materials for projects, and I've always wondered what would be the cheapest way to use a normal LCD computer monitor.

Those are readily available for about 50 US, and Nahom wants to use it as a display for electronics projects. Oh boy. Please exclude Raspberry Pis that are not available. Oh boy. Ideally, if there exists a board one could make with some microcontroller, then that would be ideal. So here's what I would suggest.

I think BeagleBoard has to be excluded as well. That wasn't what I was going to suggest. Okay, go ahead. First, I have to assume that the computer monitor has VGA input. If it does not have VGA input, then this all gets a lot harder. Right. So VGA is one standard for driving LCDs, and HDMI is another. Yeah, and VGA is analog.

And VGA you can do with a microprocessor. You can do... HDMI, you really have to have an HDMI driver. So you can basically, and going back to the first part of the show, you can basically bit-bang VGA with a powerful enough microcontroller. And I think

people have done it with Arduino. You'll have to look it up, but it doesn't take much. Although it takes a lot of your CPU power. So as you said, if you have two of them, one can be doing display and one can be feeding it. So VGA is what I would look at. There's

many projects on Hackaday that I've seen that have composite output TV signal, like they do for some of the heads-up displays that overlay on first-person view for radio-controlled planes and things over the camera. Those are available, and they can do some basic line drawing and text, and those are individual ICs. But I would explore the VGA route if your display is doing it. If it's HDMI or DisplayPort or something is all you have access to, or DVI, I don't know how easy those are to drive.

Well, I know HDMI is extremely hard to drive because you need the encryption stuff. Don't know if DVI is easy to drive. So, yeah, VGA. VGA is the way to go. And VGA is also the way to go because it has a higher voltage range. Oh, okay. Very friendly. And so it is friendlier to the Arduino-style processors.

Stay off the processors that are 3.3 volts, because those are likely to cause trouble. Okay. Ah, let's see, what else? I said this was going to be short, but we aren't cooking through this as fast as I expected. That's because I made you explain aliens. Frank says he has not heard the first 70-ish episodes, but would like to. Yes, yes, yes yes so we have this plan squarespace holds 100 and itunes holds 100 itunes holds 100 and i have to say i never imagined we would have too many yes um but libsyn who hosts, who hosts the actual file that holds the audio,

there's no limit there. So there's an alternative link that you can use, although I don't know how to put it into iTunes or anything. It's an RSS feed. It's an RSS feed? So it's an alternative Rss feed from the squarespace one it has all the episodes the problem is we hadn't been keeping that up to date so there were no show notes so we've been slowly going through and copying the show notes over well i did it in a

couple of bursts and then i kind of at around 70 i started working on narwhals and then we had a major distraction and we didn't finish so So we have taken this on the list, taking this as, as a, as a prompt to finish that up. Uh, we will put the alternative link in the show notes. It goes all the way back to episode one.

I will add it to Squarespace once we have copied over the show notes. Um, and people should be good to go if they want to do that. Yes. So you can listen to the early ones And there were some really good early ones. And if you want to complain to Apple and Squarespace... That would be okay with us too. You know, five stars, I just wish I could listen to all of them.

It's not my fault. Ah, Spencer Owen noted that Chris was talking about building his own 6502 computer from scratch. Spencer did a similar thing a few years ago, but based around the Z80. He says it was a fantastic learning experience. It gets down to the nitty gritty of what a computer really is. And then, and then, he has this as a kit, a minimal computer kit. It's available on Tindy, and I will have it in the show notes,

so you can look for that. This was quite cool. Yeah. The Z80 was a really cool processor. We talked about that a little bit a couple episodes ago, but that was another one of those interesting little late 70s, mid-70s processors. You could learn it in an afternoon.

Okay, not really, but you could imagine learning it in an afternoon compared to what we have to learn now. The processor I'm working on, the user manual, 1,400 pages. Is that all? Well, it doesn't include the USB stack or anything. That's just the processor. And it doesn't include the fact that it's a core text. So there's a whole other manual out there.

Hmm. Yeah. And I feel like I'm cheating because I'm just reading the sections I want. I'm not even skimming the others. It's gotten to the point where it's like the laws. Like, if you want to be, you can't understand every law because they're all thousands of pages long. Yeah.

So, no, you're not expected to. I expect me to. Well, if you want to learn the whole process or go learn one of these. Yeah, I think the ZD would be a lot more satisfying for that. Jim GF also had a comment about a previous show, the one where we talked about quadcopters with flybricks, Rob Walters, and then before that we had talked about the

dodecahedrocopter, and apparently there's a TED Talk with an actual professor showing off an 8-prop quadcopter? It would be an octocopter. I can't say that. Every time I point at you, you have to say it. Octocopter. Anyway, Jim sent us a link for that so I will include it

it was a pretty cool little talk I'm sad that somebody's almost done what I suggested but hardened that there are four props short 12 short I thought it was 20 you're going to make me look bad

one of us is going to look bad. It's funny when I type in dodecahedra, the first thing comes up is dodecahedrocopter. .com dodecahedron 12. 12, alright.

There are only four short. That was close. That was close to exposing my my lack of there's no 20 that's sad maybe how can we make

hang on D&D dice without knowing this oh you're right what's it called special cases of the pyridohedron teteroid tetragonal pentagonal

dohetechohedron well that's ugly I'm sure people tune in just to listen to us say these things The tetoroid, tetragonal pentagonal dodecahedron. Well, that's ugly. I'm sure people tune in just to listen to us say these things that sound implausible. That's fine. They like us. They have to listen now. It's in their podcast downloader.

They can't stop the car and switch. It's too much work to delete a podcast you subscribe to. We did get an email about the ACM having a code of ethics, which was pretty cool. ACM is the Association for Computing Machinery. Why I joined IEEE instead of ACM, I don't know. But. So, maybe I need to go look at that some more. And if you know about it or you were part of making it,

email. And maybe we will talk some more. What? We'll have a whole ethics episode? Nah. Is that ethical? Ah, who knows. Okay, let's see. I will be looking for a new gig soon not right away but soon i haven't quite finished the old one so if you have something interesting i would like to remind you

that we put on a podcast and that we write interesting things on the blog and that I do a little bit of management of my co-contributors on the blog. And this is all the stuff I do for free. Imagine what I do if you pay me. Was that a good ad? I'm not sure. I'm still thinking about it. Okay. So anyway, I will be looking for a new position soon,

and possibly I will be speaking at the Silicon Valley IEEE Computer Society in early October. I probably shouldn't have just slagged IEEE. Duh. Ah, and for those of you who purchased my book, because we told you that I have a book, thank you very much. I do appreciate it, and I hope you like the book. And if you don't, please give it to someone you don't like.

You're going to do a second edition soon? The whole toy book, which is sort of on the shelf right now, metaphorically on the shelf right now, stopped that. But a second edition is sort of in the works. I don't think we're going to change a lot. I think I'm going to redo the math chapter and I'm going to add a little bit about manufacturing process. Oh, and you're going to talk about BLE

over here. You're going to have a big, fat chapter explaining BLE, right? I'll be updating some of the communication protocols, but I don't want to write a book about BLE. I want it to be general. You want to have written a write a book about PLA. I want it to be general. You want to have written a book about PLA. No, I want it to be a, here's how you design things, here's how you build things,

and here's how you go out and look at other people telling you how to do protocols. And then the big change for the second edition will be, I'm hoping to redo all of the images to also have words behind them for people who can't see but also

in case we actually do an audio version. Audio version of a technical book? That doesn't make sense. There have been a couple and I find it very amusing. Are you going to get to read it? Oh, you want to do it?

That's fine. That makes sense. I was just thinking amusingly, you know, have Will Wheaton do it or something. It wasn't meant to be on Slack. It was a, what random person can we get? And with that, Chris, do you have anything else? I don't think so, but I can come up with something.

Oh, now. I don't think I can come up with something right now. Alright, well then I'm going to close the show now. You're going to close the show? Well, not. Are we turning the sign around? No longer says welcome, come in.

Thank you, sort of, to Christopher. You're taking that artificially more negatively than you need to. Yeah. Maybe Bobcat Goldthwait will read it. Oh, that would be great. See? too. Yeah. Maybe somebody, maybe Bobcat Goldthwait will read it. Oh, that

would be great. See? I can't do a Bobcat impression or I would right now. Anyway,

thank you to Christopher for producing and co-hosting and of course, thank you for listening. If you do

have guest suggestions, I'm not running short, but I always like to hear them. So go ahead, send me your guest suggestions. And if you know them, if you have their email, it is so much easier because then I'll send you a little introduction and you can forward it along and it will all just smoothly happen. You know, you can also email them and say, you should be on this show. And if they email me, anyway, guests. And we have a blog.

We talked about that. We have a YouTube channel. Subscribe, people. Y'all asked for it. Actually, you didn't, but. I think like three people asked for it and they did subscribe. So, you know, I think we're.

Well, they're obliged to get their friends to subscribe. There's a contact link on embedded fm that will direct you to the youtube channel it will also direct you to subscribe oh i see well yeah okay and and it will let you email us and i'll let you sign up for the newsletter which is still working yay um So it does lots of things. Go to the website, check out the show notes. There's going to be a lot of links in the show notes. Yeah. So now Winnie the Pooh. Let us continue with Winnie the Pooh from last time.

This is going to take a really long time. It really is. So when we last left Winnie the Pooh, he was nearly at the top of the tree to get the honey and he had stood on a branch and crack oh help said Pooh as he dropped 10 feet on the branch below him

if only I hadn't he said as he bounced 20 feet onto the next branch you see what I meant to do he explained as he had turned head over heels and crashed on another branch 30 feet below what I meant to do, he explained as he turned head over heels and crashed on another branch thirty feet below. What I meant to do? Of course, it was rather, he admitted as he slithered very quickly through the next six branches. It all comes, I suppose, he decided as he said goodbye to the last branch, spun around three times and flew gracefully into the gross bush.

It all comes of liking honey so much. Oh, help. Embedded FM 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 any revenue from them. At this time, our sole sponsor remains Logical Elegance.