Embedded - 191: What, Yogurt!?!

Episode Date: March 15, 2017

Chris (@stoneymonster) and Elecia (@logicalelegance) answer listener emails. Get your entries in for March Micro Madness, the matches start very soon. The short story Elecia finds most memorable is All Summer in a Day by Ray Bradbury. We mentioned Procopio who teaches microcontrollers at the Monterrey Institute of Technology and Higher Education ITESM (site, wiki) Hector sent up the IEEE Code of Ethics, a good high-level set of rules.

Welcome to Embedded. I'm Alicia White, alongside Christopher White, and this week it is just us talking to each other, mostly about listener questions. I forgot to stop the clock. It's going to tick. We'll see if anybody notices i got a new clock it ticks i can't hear it where shall we get started with listener questions or with the random assortment of other things on the list uh let's make the listeners wait okay so we had a party yay party that was like six months ago. It was in fact nearly two months at this point, and we just haven't had a You and Me show since then. Really?

Yeah. It was cool. We had lots of people come, and they showed us weird stuff that they made with hats, or hacks, or both. And for that, we made embedded FM hats, baseball caps. And it was fun to get those because I want them because we live in a place with too much sunshine and I'm always wearing a hat. And then we gave that out to the person with the best hack. Or hat. No, to the person with the best hat. Oh, right.

We gave out... A hack. A dev board. A dev board. Okay. The STM32 that's used in Andre's series, blog series. Right. So, that was very fun. People came and were very nice, and I didn't get to spend nearly enough time with anyone

because I was bopping around. There were a lot more people than I was expecting. There were. Either... Thank you all for coming. Not everybody RSVP'd, or i just didn't count well either way it was fun it was really neat to see everybody and it wasn't very stressful sadly the place we had it that was their last day of operation it turns out

so if we repeat this we'll have to find some place new new venue if you have any suggestions for bay Area venues, we might take them. Don't be so enthusiastic. I don't know. I mean, there's a lot of Bay Area things. I mean, we could go up to San Francisco, but... I'm not doing that. Yeah, I know. Exactly.

Your version of Bay Area now is Monterey Bay, not San Francisco Bay. I didn't think I had to specify which bay. Chesapeake Bay. All right. So, yes, the party was good. For those of you who didn't attend, no, there aren't really any pictures because I'm always kind of shy of posting pictures of people that I don't know without asking them. So, yeah.

Sorry. If anybody did get pictures of their stuff or of the hardware and they want to post it, feel free to. It was really nice to see everybody. And I look forward to doing it again someday. Who won? Who won? Yeah. You were there. Who won? There was a hat. It was a wi-fi hat that was ben henk and he had a hat that was hooked up to wi-fi and you could it was serving a web page and you could type in a mathematical equation to control the lights around the brim the brim yeah we decided that was the best hack and gave him a hat. The best hat were a pair of squid from UC Santa Cruz, who did have a really nice hack as well. So it was fun all around.

Moving on. Moving on. Let's see. We did get some questions from the party. I put out the... What kind of questions? Lightning round questions. Right. And told people they're welcome to take them and write us new ones. So do you want to try out the new ones?

Yes, let's beta test the new lightning round questions. LCD or OLED? OLED. Z80 or 6502? 6502. Three worst features of I2C? Three worst features of I2C? Well, there's the fact that you're in this battle between being super low power and being robust. And so you put those pull-up resistors, if you make them so that they pull up a lot,

then you're burning power for no reason. If you don't make them so they pull up a lot, then you may miss sometimes. And so that's sort of bad. Okay. I have to say I don't like that everyone seems to have their own addressing scheme. And I did actually write a two-wire driver today, in fact. And one person on my team said I thought that part was ice-cold sea, to which I said, yes, yes, it is. Yes, yes, indeed.

They're the same, but different because of lawyers. Yeah, I don't, I mean, spy would be easier to complain about. I guess not. I don't know. Well, iSquidsy has some analog features to it that you have to look at, and so you can't just use a logic analyzer. Right. Spy has so many wires. Yeah. You. I don't like chip select. Spy has so many wires. Yeah.

You obviously don't need that many wires. All right. Not sure about that question. All right. IceCred's here. Spy was one of the next ones. So we'll just. I third C.

Wasn't there. That's new. Yeah. Do you buy it when you need it or do you maintain a stash buy it when I need it I have a bit of

an electronic stash but you didn't pre-populate it it's just accumulated over time from things you did need it one time and then you just kept

that is true I often will buy two. I think there are only a few things that I bought with the idea of I'm going to need that someday. Yeah. I think we'll both buy it when you need it.

Alright. 12 volts, 5 volts, 3.3 volts, or minus 14.5 volts? Minus 14.5? What is your voltage? I'm going to go with 3.3, although 1.8 seems to be happening. Yeah, 1.8 is missing there.

1.2 even. 0.5. Do you start many projects and not finish, or do you start one and finish? That's pretty... Former. I'm definitely in the former. Unless I'm being paid, then in the latter. Personal projects definitely start a bunch.

Favorite RTOS? None. I should give an answer to that. Favorite RTOS? Well, here are the RTOS's I've used I've used VXWorks I've used Green Hills I don't remember what it was called Green Hills' thing

Multios alright let's go with Green Hills that sounds right-ish ThreadX and I'm sure there's something else I've used okay Green Hills. Right-ish. ThreadX. And I'm sure there's something else I've used. Okay. Oh, the thing that comes with embed.

And I don't know, some other stuff. I have used TI's BSP slash BIOS, which is old, old, old. I've used PSOS, which is old. Oh, old. I've used PSOS, which is old. And I've used TI's RTOS, which is the latest one on their BLE chips, which was perfectly acceptable. PSOS, no wait, I already said that, pumpkin salvo. Sorry, I was alphabetic and messing it up. And then I have used microCOS a little bit not as much as i probably should oh i used links to link sauce back in yeah probably don't nobody remembers that but

i don't know i they're all i didn't like vx works very much buts very much, but that was 13 years ago. Upon having to choose one for a small budget-constrained company, Pumpkin Salvo was the one that I went with within the last five years. I hear a noise. Somebody's shouting from Canada. Yeah. Do you hear it? It's R-TEMS.

Oh, right. R-TEMS, yes. It's good hearing there. Yeah, I haven't used RTEMS. It looks a little scary to install, but I do also now hear the shooting. Okay, having gone through that litany, I don't think I can pick a favorite because they're all gross in some way. I guess Linksauce was the easiest to work with because it acted just like Linux.

So it wasn't Linux, but it was POSIX-y and boring. All right. One last lightning round question here. Oh, good. Because it's not very lightning. And you could tell Chris and I are just a little on the tired side. It was like, come on. I mean, that required explication.

True, indeed. Yes. But we're still not going with the right. Anyway, favorite place toocene megafauna. Megafauna? Yeah, none of these shrews. Favorite Pleistocene. Oh, that's easy.

I'm going to pick something wrong. Giant sloth. Giant sloth? Was that Pleistocene? We both turned to our computers and started typing. It's going to be a great podcast as we type away. It applies to seeing the Ice Age. Okay.

Yes, that sounded right. Well, if I pick the Woolly Mammoth, everybody's going to be like, of course. Sabretooth Tiger. Yeah, but secretly it's the Woolly Mammoth. Because I had them in the tar pits. I remember them. They were cool. Yeah, LA tar pits.

All right. Well, some of those are all right. Yes. I don't know They were cool. Yeah, LA Tar Pits. All right. Well, some of those are all right. Yes. I don't know when Lightning Round is coming back. It is a nice vehicle to get people to relax on the show, but it also- It doesn't work for me. I'm even more tense than I was now. Yeah.

Thinking about I Squared C. Trying to figure out why I don't have complaints. Indrik's show where we talked about arduino the product and about visiting estonia we did not intend to disparage arduino in any way which i think was right after we said something negative about arduino we immediately said although we love arduino just get started with or for prototyping but still we we do love arduino it's a great platform it's great for beginners but as a full-time consultant it is sometimes tedious to try to explain how it's not the end of the product it's the start yeah we're often having to explain ourselves

with beating up on Arduino, so just take it as a blanket statement that we like Arduino for its intended uses. We wouldn't know so much about it if we didn't use it. So, yeah, we do like Arduino. No disparagement intended.

And the person who mentioned that we were hard on Arduino also asked, who are audiences? I don't know. It seems like it's time for another survey. Yes. Episode 200, which will be coming up in a few weeks, like 10 or 9 or whatever. 8. 9.

8. Some number. Episode 200 will have a please give us feedback survey. So you can start thinking about how much fun it was to listen to Patrick Polarski talk about bionic arms. Or Matt Godbolt talking about Compiler Explorer or Squishy Robots. Squishy Robots. I mean, we've had some really great shows lately. But we also will ask for things you want to see better and maybe people you can connect us to that you would like to see on the show.

Although my list is long, I always want to know more. And we will ask a little bit about you. Like, what do you do and why do you listen? And your credit card number and your address. No. No? No. So, be forewarned that that's coming for those of you who are 10 weeks late. Go ahead and skip to that episode, episode 200. It's like we're time travelers somebody said they missed the party because they were so far behind i'm like we started talking about the party in november but yeah that's fine i understand i am very late on my podcast as well so what else uh

what did we just talk about uh who are audiences who are audiences well we didn't really answer the question uh when i just talked about the survey are audiences? Who are audiences? Well, we didn't really answer the question. We just talked about the survey. When I'm trying to get people to be on the show, I say our audience is primarily made of hardware and software engineers. And then that's usually followed with, you can be as technical as you'd like. Yeah.

Yeah. We get a lot of college students writing it. Yes. And grad students. And people. And hobbyists who have nothing to do. People who used to be engineers and are either retired or went on to something else, but are dipping their toe back in or doing it as a hobby. I have to say a lot of our.

A dentist. We have a dentist who listens. Okay. It's not our dentist, is it? No. What if she argued while she was doing things to our teeth that would be awful we could record a show of me having no okay um yeah but we'll find out we'll find out who our audience is and let's see march madness oh i'm excited about that i should actually act excited about it huh let me do this pretty good i mean he sounded reasonably March Madness

really those are like the puppy dog eyes please stop that what am i supposed to do there? I don't know. You could cheer. Yay! Like to cheer the minions given despicable whatever. They don't mean it. I know it. So March Madness, I mentioned it last week. This is where we arbitrarily match up dev kits in order to

I don't know, arbitrarily learn more about dev kits. The key word is arbitrarily. I think some people might be confused that there's a deeper point, or it's really just kind of a guessing game. I currently have a list of about 32 different characteristics from what their price is on Amazon to how many are in stock on the first result given on findchips.com. This is how we're choosing them. So it's more of a grab bag. Right. And so those list of questions will be used to battle everything out. But that list is long and it will be randomized to battle it out. So the point is other people fill out the form however they want.

Right. It's kind of like bingo. It is a little like bingo. Right, right. So you guys don't fill yours out based on any criteria except whatever you want. And what you like. And then we're going to kind of randomly choose. Which is a lot like basketball, which is what this is all based on any criteria except whatever you want. And what you like. And then we're going to kind of randomly choose. Which is a lot like basketball, which is what this is all based on.

Basketball is a game of skill. Right. No chance in that. Anyway. And then there's some sort of matching and then some sort of winning? Yes. There will be several rounds and we will continue to select criteria through the end of the month. And at the end of the month, we will crown a champion dev kit based on all of our assorted randomly selected arbitrary criteria. What about a hat?

And that person shall be given a hat. All right. Assuming that they get their thing filled out before we start naming criteria. Okay. So, which will be soon. So, if you're listening to this right now, you'd better start. And if you're listening to it 10 weeks in the future, then it's over. You can just look at the answers.

It's May. Yeah. It can't be March Madness. That's how you can tell. Okay, let's go on. On. Listeners, listener emails. How exciting.

We get emails. I feel like we need a little bumper music for the email bag. Okay, you can write new. No? No. All right. So Hector Torres said that he really enjoyed Andre Cicak as a great guest, and he likes it when we cover embedded tech in automotives. Cool. Recent graduate with an EE.

He's been looking into arm development and now MISRA. We mentioned IAR with Andre, but the MISRA isn't available in their free version. So how do you get MISRA checking if you don't want to pay for IAR? I don't know. Do you know? No. Why do you think I would know? Why should I do this? That's why.

So the thing is, people write in, and if I know the answer, I reply. Uh-huh. And if you don't know the answer, you just ask me and assume that I know. If the question is odd or something I think a lot of people ask, then I reply and I put it in my list for posting on the blog. And then usually those and all of the others, when I don't know the answer, I just shove it into a file and Chris and I talk about it on air, as we're doing right now. And sometimes that's even successful. Sometimes that's successful because I go through and actually answer some of these.

So I think what I told Hector in email was that I don't know of a MISRA GCC sort of free support. And the question here, does anybody out there know about it? And if you really want to get on that path, then PC Lint is the way to go or Clang. Clang doesn't have it. Clang doesn't have MISRA, but it has a lot of other things. So at least you'd be a little closer. So let me Wikipedia that for you.

Oh, good. Compilers that support MISRA conformance. And Wikipedia, as we know, is a definitive source of all knowledge. Greenhill Software, which is not free. IAR Systems, which as we know, is mostly not free. Tasking, which I've never heard of. And TI compilers. Oh, Altium. What? Just ignore that. But there is a big list of tools that support MISRA conformance, and PCLint is of course one of them. None of those are free.

I think it kind of is one of those things that may not be possible to be free because you may have to be part of... Well, you can't get the Miseric guidelines themselves without paying for it. Right, so anybody who implements it is going to have to charge money to recoup that. Even tell you what they are. It's like 50 bucks just to get this piece of paper. It was weird. Yeah, so... This electronic piece of paper.

Unfortunately, you're going to have to find something that is cheap that you can do. Hector also says that they have to learn and memorize the IEEE Code of Ethics in their senior ethics class. Where is that? IEEE.org slash about corporate governance no i meant where they were making him that didn't thank you it'll be in the show notes i don't know actually okay well he didn't say where he was from moving on um to emmet on to Emmett. Emmett starts his email in an extraordinarily frightening way.

Oh, God. I have been listening to you guys for about a month now, averaging five podcasts a day. Okay, Emmett, now is the time where you can just stop listening to us for like a week or two, we are too much in your head. There is no way that five Chris and Elysia podcasts should happen at any day. I'm not even sure five a week is healthy. Okay. It does seem like that's more than yes. I can't even listen to the voice in my head that much. I know. Emmett also is a fairly recent graduate with a double E degree. See, this is telling us all about our audience. At least the ones who write in. He wants to build an RFID reading dog door with a display in his kitchen, but he doesn't want it on the internet.

And he wants to be able to add visitor dogs. Doesn't want it on the internet. So what's the display supposed to do? I mean, you could do Wi-Fi, but have it all be internal Wi-Fi. So I think that would be the safest way to go. I mean, ZigBee or BLE or whatever you want. Well, BLE is too short too. I mean, you need to go from the door to the kitchen.

Depends on how far that is. Yeah, and can you do two BLE modules talking to each other? You can actually, although in this case, I would put a Raspberry Pi with the display and a BLE Master. Yeah, just do Wi-Fi. Yeah, just do Wi-Fi. And then you need to do the RFID part.

Right. And then you just buy a module. SparkFun had a module. It was very expensive, but they were cheaper modules. And then you need a dog. Right. We can send you ours. We have two. They're very poorly behaved. But they would enjoy a door. Because they We can send you ours. We have two. They're very poorly behaved. But they would enjoy a door because they don't have one.

All they do is sleep. Yeah, you don't want our dogs then. Get a better dog. From Stephen, having listened to the podcast enough, he appreciates that my book, which is Making Embedded Systems and published by O'Reilly.

Yes, I have a book. You should read it or not read it. You should just buy it. Anyway, he appreciates that the book is written in my voice. It is literally in her voice as I read it. And the side notes, like the definition for embedded systems, come out in Christopher's voice. What?

Yes. So, Stephen likes to read the book because he can hear it. We should record an audiobook. I hope to. I have talked to O'Reilly about that. Audiobook technical books? They do exist, and I know somebody emailed in and asked for a link to that, and I didn't get it because the person I was talking to about it never got back to me. But yes, there do exist technical audiobooks, and I think that one of the refreshes on my book will be to add alt text to the diagram so that we can read that book.

It would be cool. Paul Whitfield wants to start helping out at a Coder Dojo. Wondering if we had a story, if we'd ever done a story on it. No, but now we have a search button. Or if we knew anybody involved that could provide some tips. If we'd ever done a story on it. Or ever done a show on it. I thought we did.

On making a Coder Dojo? I'm going to go use our new search button. All right. Dojo. So I know that Andre... Hacker Dojo. Just started. Mountain View.

That was when we recorded there. Nope. Really? This is great radio. Episode 25. Wow. Okay. So there was no way I was going to remember that.

700 years ago. 700 years ago. Back when we recorded to wax cylinders. We discussed with Jen Castillo. Castillo. Castillo. New product development and working from Hacker Dojo in Mountain View. Oh, that was because she was doing development there.

Yes. So not starting one necessarily. Well, I mean, Paul is asking about helping out at one. I know that Andre started his whole blog series based on a class he was doing at a Hacker Dojo type place. And that he hasn't continued at the class there, but maybe one day again. And I don't know if he has any particular advice. Maybe we should ask him.

It's good somebody proofed through these and looked to see that we could answer them. I think you just cut and pasted them all. Yeah. NJ said that the future is automation. Well didn't say that he said other people say or she said that some people say that people have said people have said the future is automation now i'm going to read this everybody at least wow i can't read this now everybody at least developers have good knowledge in how automation can change the software development processes. But can automation revolutionize embedded software development? Even in embedded software testing, the idea of automation, is it even feasible?

Anyway. Automation. Yes, feasible. Yes, feasible. would you anyway automation yeah yes feasible yes feasible I guess the problem the the sticking point for many

is that there's a device that I need to talk to and it's hard to automate talking to a device and stuff but that's actually pretty tractable

if your device has a UART you can engineer your software with a command line interface and trigger all sorts of actions and see all sorts of results.

If it has a display, it gets a little trickier, but you can still do things like save off the frame buffer and download it and then compare it to a known state.

Yeah. But you can do Raspberry Pi in a camera too. That's surprisingly easier than you think it is. Well, I mean, but you have to do image processing

to figure out. You're comparing this image to that image. Yeah, but it's through cameras. Yeah, but you're going to put it in a darkened box. So it's not like you're going to be. I wouldn't suggest people

do that to start with. Maybe not to start with, but maybe as a secondary. but uh yeah there's tons of automation you can do and the the console the serial console is a great way to start because you can use it as a manufacturing tool as well but i go beyond that i like to do the hardware in the loop testing. And that is when you take out the sensors of a system and you replace it with known inputs. You put in a DAC and you pump in what you want the system to do and then you get the results out. It's almost like unit testing with hardware. Yeah. How is that different from just, I guess you're testing the full driver path then instead of just injecting

the data below that. Even testing the electronics to some extent. True. Okay. But yeah, I would start with, and there are even

automation frameworks that I think you can, I don't have any offhand, but. Yeah, we haven't really used those. But I do think that automation is important. And even

as I look at developing from scratch, this time as I go through the Nordic example and toolchain and path of making a new little product, they have all the stuff. And I don't agree

with how they've done all of it. But even if I only rip out 20% of their code, that means that I'm keeping a lot. And it's been really nice. And so that automation of just getting more from your vendor is pretty powerful. And this is like the CubeMX from ST, where you kind hook it together, and then it generates all these drivers for you. Well, that's a different kind of automation and testing. I guess the question was all of automation. So, yeah, I was thinking testing.

So, yeah. But cogeneration is going to become more important, particularly for these things where it's just, I want these 12 pins to do these four functions sorted out. Sorted out. Well, that's the kind of ugly bookkeeping stuff that we keep having to redo. And you have to do it for each one. And your chip is different. You have to test it for each one. Yeah.

Yes, but there's no reason why we should continue writing UART drivers. It used to be a joke that I would write a UART driver every six months. And I'm not writing them as often as I used to be a joke that I would write a UART driver every six months. And I'm not writing them as often as I used to. Now I just get them from the vendor. Yeah. And in testing, it's really nice because unlike unit testing, unit testing is good for some things, but it doesn't test integration. Right. It can, but it's harder. And my hardware-in-the-loop idea of ripping apart the system

and shoving in what you can is expensive. And it does test a lot, but there are smaller things to do. Well, yeah, I was thinking more along the lines of tests that you can't... Unit testing doesn't test longevity. No. So it's not going to find, it might find a memory leak if you run it the right way, but it's probably not going to. It might

find weird issues with your device where, oh, I ran this for 15 hours and it got into a weird voltage state because the battery was at this point, or this component got hot. Those are the kinds of things that full device automation can find for you.

You can just stick something in a closet and run it for 24 hours. Yeah. And then, you know, even more mundane forms of automation like triggering tests based on builds. Right. Like unit tests that kick off.

Okay, every night we take the source tree and we build it and we put it on these devices in the closet or we run the unit tests on them and we just do that automatically and the next morning when everybody gets in they're all sad because something broke all right well i i think we have we agree that automation, yes. Everybody likes automation because it means not working. Right. Procopio. Procopio. Villarreal.

Villarreal. Greetings from Monterrey, Mexico. He owns a consulting company that does embedded product development, has been in business for 28 years, which is even longer than ours. And he teaches microcontrollers and he sent me a link. So I'm going to share that link to the show notes. Okay. I don't know. I guess I could share it on Twitter too, but we'll do both. It is www.w.itesm.mx. He says that he recommends our show to his students, but then he ruins it by saying that he recommends the other show as well, our Enemy podcast.

And that link goes... I put it at the bottom, so I will send it out. Greg is also in the process of listening to all of the Embedded FM podcasts. Again, I say, don't do it all at once. That's too bad. That's too bad? It's bad. I mean, that sort of thing can cause insanity.

Oh, this is one that actually I did write a blog post for, although I don't think it's been posted yet. He went to a small company, and they have multiple versions of the same code, and it's been worked on for seven years, serially. Oh, this poor person. The original author of the code was not a coder. The person who took over after that person was not a coder. The person who took over after that person was not a coder.

The result is now 50 to 60,000 lines, 15 header files, and 14 source files. Every source file or every header file is included into every source file. Variables and structures are global. There's no encapsulation, not even any attempt at it. There are few comments, but no documentation. And this was the one where I started the advice with, it's okay to keep scotch in your desk. And then I kind of erased that and decided that was not the good advice. That's not good professionalism advice.

I used to keep scotch in my desk. At a company. At a company. At a company. I even got used to it a couple times. Greg wanted to know how to tackle he's convinced his boss and colleague that encapsulation is

good, but how do you even get started? The problem is, you've already started. You have 60,000 lines of code. It'd be a lot easier if you were starting over. That's a lot of code. It really is.

And I think you wrote a blog post that hasn't been posted, but I remember you were going through some of it and tried to figure out if there was a way to kind of graph things,

call it the call graph. Yes, that would be- Try to get a handle on how it's currently organized. And if I recall correctly, he sent it in and it looked like spaghetti. Yes, he did. It was, I suggested a call graph. You can generate one with Doxygen. Even if you don't have Doxygen comments or anything, it will still generate this graph

of what function is called by what other function. And, you know, if you, in a perfect world, you have main, which calls three or five other functions, which each call individually down and down and down. And so you, you end up with this beautiful tree structure. If your code is layered. If your code is layered and each. Modular. Each module calls only the next one or maybe one or two near it

if it's a monolith it just everybody calls everybody and some people call nobody and some people who should call things don't appear to call anybody but they get called a lot yes and and then global variables mean that there are these connections you can't even see um so yes we suggested a call map i suggested a call map first as a way to untangle it so a lot of the problem with this is it's unclear how much leeway he has right so if i came into a company and i was a new employee and this is this is what they gave me. And they said, okay, here's this. What do you suggest? And I had completely open possibilities. You know, the first suggestion would be, can we start over?

Which is a valid, viable suggestion. But it isn't always what you can do, because the code currently works, the code handles weird corner cases that your new code won't. And you do have to make product to feature incremental development as you go on. So you can't burn it all down. I mean, usually you can't, even as much as you want to. The second thing would be, how long do I have to kind of get a handle on this? Because if you have a really long time, you can sit down with the thing and just drink lots of coffee and kind of plot it all out. Because I think part of the problem was getting a handle on how it all worked, right? So that it could be maintained.

Yeah. But that's one of the things where a call map gives you the first view. Yeah, but it didn't. And then if you can start... But it didn't. But he did have some functions that were called by fewer things. Those are your first modules. You clean up the easy stuff first and you just start untangling things. So you carve out sections and modularize them one at a time?

Yeah. And if you can, you make sure your boss and colleagues stay on board by making this a feature. And so you... That's the hard part. It's all working. Why are you doing this? This is a waste of time and money. But it isn't because the next person will be cheaper. I was being the manager. I know, but it really isn't. And, you know, if you, if this kind of code, I always suspect also has never had warnings checked. So if you keep this list of how many warnings, how many global variables, how many unread, undocumented, untested functions, then you, you can start keeping a score.

People seem to be, managers that I've had have always dealt well with having a score. I'm getting better and so I have fewer warnings this week than last week and I have more code coverage. As you untangle things and encapsulate them, you can also make unit tests. That's a really good time to try to test the code. And you test it when it's wrong and bad initially, and then you fix it, and then you test it again. And that lets you know that you haven't broken it, because that's always the fear. You're going to make a bunch of changes. You're going to add some features. You're going to clean up the code. And at the end of that, you've broken it. And now

you have to erase both the new features that you need and the code that you need. No? That's just never going to happen. It happens. We get a Friday afternoon thing. Yeah. As long as you have a long time to do it. But if you're kind of thrown into the deep end, sometimes you don't have a long time to do it. But if you're kind of thrown into the deep end, sometimes you don't have a long time. Sometimes you have to fix stuff. This doesn't work.

There's a huge bug. Okay, here's 50,000 lines of code. How do you tackle that problem? That's a different problem than refactoring. That's learning enough. I wanted to refactor slowly. But you may not have the opportunity. Well, you get the big bug and you're as lost as you would be without

refactoring. Yeah. And if last week you had refactored something, and you now know a little bit more about the system, because maybe you didn't change a lot of code. Maybe you just made the global a static and took that header file out of every place else. And now there's a function that's an accessor function. And so you didn't make a minor change. But that's 3,000 lines of code where you know the bug isn't. And so I really do think that carving it up, it sounds slow, and if you can do it in three weeks instead of having

it be a day, a week for six months, great. But burning it down never works. Well, you don't need to burn all down but yeah no you rarely get an opportunity to do that unless you switch companies and do the same thing at the next company um i do feel for him i have no it's a terrible problem it's a terrible problem and he's as he says he's every single source file is loaded at every other source file which makes me worry that there's.c's being included.

Oh, there weren't. I actually checked that. Oh, okay. Global variables everywhere, no encapsulation, few comments, and no documentation. I mean, at some point you're going to have to go through and document it yourself. Yes. And recognize that this is a part of your job. It may not be the best part of your job, but don't think of it as this thing that takes you away from other things. What you're doing is making your code good for the next person. You're loading it into your brain, you're learning it, but you're also making it so that nobody else has to go through this amount of pain.

Right. Now, to be fair, they will go through some pain. You can't protect them from everything. But maybe a little bit less next time. Yeah. 50,000, 60,000 lines. Yeah. That's a pretty sizable project. I don't think you could just read through that and understand.

No, you have to. You can't load that into your head. Especially the way it's been organized. So you have to carve things off. You have to start with a model of, this is how a system like this should be organized. And then see what maps to it with the current implementation and what doesn't. Actually, that's a good thing.

I didn't suggest that. But to think about how would you do this if you did it from scratch and try to come up with like five different ways you would implement it. How are you going to refactor it if you don't know what you're refactoring toward? That's true. I was still in the just try to unsnarl things. Yeah. And hope that an architecture sort of fell out. Good luck with that.

Well, you have to assume the first person tried. No, you don't. I always do. I know, it's not always right. I mean, a lot of times the first person is like when I wrote my first adventure game when I was a kid and it's a bunch of printfs and if statements.

Thousands and thousands of lines. Choose your own adventure. If this, then this, then print this. I worked at a place and that was how the whole UI was done when I first came in. Yep. Like, drawing buttons and stuff was, the actual pixel numbers were in the code to draw the,

that was murdery. Murdery. This is why Scotch is sometimes in that drawer. That took some serious refactoring, let me tell you. Okay. Well, we've been very helpful for that person. Well, he has written back and he sounded less depressed the second time. And as long as we're giving advice, Matthew is a sophomore majoring in computer engineering.

He's interested in embedded stuff, and he wants to know what important things are to learn as a beginner. He's already taken Java and C++. He's done some Arduino and FPGA stuff. That sounds like the right path, pretty much. Yeah, keep on. Keep on keeping on. Learn everything. I'd play with some non-Arduino stuff. I'm not disparaging Arduino. Pretty much. Yeah, keep on. Keep on keeping on. Learn everything.

I'd play with some non-Arduino stuff. Not disparaging Arduino. ESP8266 or ESP32. I would get experience with some modules that are more standard development environment. Well, ESP32 and ESP8266 both have good ties to the Arduino, and yet they are fussy little microcontrollers, and if you can really understand how they work, it's even better than Arduino. I have to say, if you really want to get into embedded as a career right now, you probably should play around with the STM32s.

With the Cortex-M? Get some Cortex-M experience. Yeah, no, that'd be good too. And there are a lot of really good ones there. And it's not that tricky. And some of the BLE modules also have Cortex-Ms in them. Everything is Cortex-Ms.

Some of them are stacked Cortex-Ms. That's true. M0s on M3s or M4s. Yeah. So everything's going to that sort of thing. I think that if I, while I love embedded systems and microcontrollers, I would also get some embedded Linux experience. Because I think as processor price decreases, the big operating systems.

And that's kind of painful, so getting a handle on that early would be good. It is, and it's... Raspberry Pi? Raspberry Pi, BeagleBone Black, Pine64, even Intel Edison, there are just a whole bunch of them. And all of them are fine. Get the experience you

can based on whatever board is being used. And I think that will be useful even if you don't use it immediately. Even now, the Unix experience I got in college still is something that is helpful. Well, if you don't have any operating system experience. So if you're doing Arduino and you're doing FPGA and Java and stuff,

you're probably not doing any OS stuff. And when you do embedded work, you're nine times out of ten going to be interacting with some kind of operating system. And most of the operating system concepts are the same, no matter if you're using an RTOS, Tiny... Even bare metal. You need to know what the concepts are.

You need to know what a scheduler is. You need to know about scheduling. You need to know about signaling. And interrupts. So all of that stuff, that's kind of a, I don't know if computer engineering departments go into that much.

Computer science departments do. Microprocessors was an engineering class. Right. Did they do OS concepts in that? A little bit, although they did more

building it up from transistors and logic gates. That's not as helpful. So yeah, get some OS experience, you know, and combine it with something else. Like, okay, let's get an STM32 and put RTEMS on it. That's not going to cost you anything much. And that would be a good experience.

And, you know, all the concepts of OS primitives are going to apply, whether it's Linux or whether it's an RTOS. Also, take all the classes you can manage. There are still classes I... No, don't take any classes. I wish I had taken. And there are classes that I ended up taking

because they were convenient for my schedule and they are still useful. Try to get the professor to tell you not to attend class. That worked well for me. Yeah. Oh, and join your robotics team. No, that's a good suggestion. It gives you a lot of insight into electrical and mechanical and software working together.

I mean, that's embedded. And it's usually fun and yet it isn't always a huge time suck and it is your robotics team. Along those lines, if your school has co-ops or internships, get involved with that because then you get to work at a real company and it's a lot different than working on a project team at school. So different. And you learn a lot of things and you learn, you tend to learn what you don't know real fast. Or you find yourself, you know, surprised that you're able to do stuff in that environment, which is always a good feeling too so um well and by co-ops you mean things like where we we worked for the cs

department as um consultants on the and administrators on the unix system no i meant like clinic oh so some schools different do it differently uh mud had a class where and everyone most majors had to do something like this. Or you had the option. You had to do a senior project or you had to do a clinic. And clinic was, outside companies would say, we have this thing we'd like done, and we want student teams to do it. So basically, it would be a semester-long course,

and you would just work for a company on their project in a small team, three to four people. And then you'd present that at the end and you didn't get paid. And the projects weren't necessarily crucial to the companies. They were often things that they were nice to have that they didn't have time for, like evaluate our, I don't know, evaluate our performance in this system. And, or one of my clinic projects actually was for space systems loral and we had to write a series of tests that covered the c standard so that they could evaluate which

embedded compilers that's what i was thinking uh worked according to how c worked and if you want to really understand how language works and all the little tricky bits, go out and make something that's intended to break everything out there. It was so fun. I mostly wrote code. You did two clinics? I did...

Because you did the one with me for a while. For a while. And I did a senior project. Yeah, okay. So I kind of... I did a senior project too. So I don So I kind of... I did a senior project too. So I don't know what we're required to. Not important.

So there are sometimes opportunities like that. Sometimes they have things called co-ops, which is not necessarily during the school year, but you intern at a company and then you use that for class credit. My brother did that at Cornell. It's different from just going to an internship in that it's linked in with your school.

So anyway, hook in with... There's also work-study, and I still think that our administrator experience was fantastic. Yeah, but there are fewer opportunities to do technical stuff with that. That was kind of lucky. Well, I don't know about now. I don't know if that's a time difference, because I also had another... I ended up working, sort of worked for a chemistry professor on his Fortran on a VAX system. It was really, really, really cool, except for the Fortran on a VAX part.

Right. Anyway, yes. Yes. Take advantage of any of those things that your school provides. Take advantage of your school. You're paying enough for it. Next. Next. Next, we have Bilal,

who wants to know what to do for his master's thesis. Not stellar nebula and planet formation using nonlinear fluid flow equations. Did that work out for you? Not well. Christopher does have a master's degree in physics. I didn't do a thesis for that because that didn't, it ended up not working out. As soon as nonlinear is in the title, you're just really hosed.

At a startup, I'm hey so he's at a startup already uh he's working along okay and he's doing a project with porting an r-toss five to six months wow hmm he wants a topic that can be finalized in a five to six month timeline and he wants it to be embedded and he hopes to work in oil and gas. So, I have to take out this startup as important, because I don't know if that's a short-term takeaway. Let's hone in on the oil and gas. I would focus in on some piece of equipment and some improvement that can be made. An actual, even better if it's monetarily important improvement. And a small one. Five to six months,

a small improvement. You're talking about reducing a battery-powered current consumption by 5%. You're not looking for 60%. You could maybe do something large. You could aim for 15. But you tell everybody five

so that they're repressed later. But yeah, I would focus in on something very, improving some existing thing. And you can tack the internet of things onto any of these tools. Yeah. Monitoring, doing better monitoring or something. Better monitoring.

Doing some sort of mesh networking thing where you have multiple pieces of equipment that normally have to talk over wires or

something along those lines. That would be what I would suggest. But keeping it small is really important, especially if a short timeline like that. Even if you have a year,

keeping it small is important because my experience with research is you get a lot less done than you think you're going to. And you can always add something. If you aim relatively, I mean, you aim, there's the bar of where your research advisor will allow you to be. You want to be a little above that bar, but you don't want to be a lot because it's easier to impress them than it is to fail. That's what you want it to be. You want to aim low enough you can be impressive later. And so, you know, there are a lot of oil and gas tools, a lot of equipment. Can you make something that will monitor the health of some big expensive thing? Yes, that's great. Add monitoring of something that's currently not monitored.

And accelerometers are cheap and really, really useful. And I think that if your oil rig is on its side, that's very important information. I mean, yeah. Depends on the oil rig. Some of the shale ones go horizontal. So it's gotten very complicated. But yes, some improvement in power or monitoring or communication would be the way I think possible. Yep.

Yep, yep. Let us know how it goes. Yeah. Possible. Yep. Yep. Yep. Let us know how it goes. Yeah. That's pretty cool. And let's see. Now we have Travis. Hello, Travis.

He has a couple of questions. I have three answers. He has, he's working on a senior project for college, undergraduate. I told you, we have a lot of college people. We do. And he has two semesters to folk on it.

He enjoys hardware as much as software. The kids love us. Sees himself as a future firmware engineer. So, how big does his project need to be to generate the kind of attention to land a job with a reasonable salary and what sort of professional certifications would help him get noticed project does not have to be huge it just has to be good yes and what does good mean good means well organized uh good means being able to explain

it in 30 seconds to your aunt who doesn't care about what you do it doesn't have to be that you explain what it is you're doing it's the i work on children's toys that's so easy to explain but he's i mean he's targeting that that's for employment. His aunt isn't hiring him. I know, but if he can explain it in a short, exciting thing. Sure.

I do agree that's important. But it also, I mean, the details of it have to be. Right. And so you add,

I'm making some neat application widget in some useful language on some cool hardware. And so you just keep adding adjectives? I guess I'm being too... I mean, it depends on who the audience is at companies.

I don't know who looks at that kind of stuff. I don't remember that any of the places I looked at cared about my project, except maybe asking about an interview for 30 seconds. And that's why I said you do need to be able to make it sound really spiffy because in an interview

if they ask you about your project that means they're going to ask more about your project which means they have less time for technical questions. So I guess I would say if you have a narrow interest if you have a particular kind of company

that you're interested in working for narrowing the project scope to that so i went to a networking company and i already knew i was going to a networking company so senior year here already knew my senior project was all about network reliability and stuff like that um but yeah i don't yeah it's senior i'm trying to think of senior projects or all that it depends on the company some are going to be interested and some aren't going to care I don't, yeah, it's senior, I'm trying to think of senior projects or all that. It depends on the company.

Some are going to be interested and some aren't going to care. I think, I think what you want is your resume is going to go into a word salad sorter. And so you want to be able to put a couple of really good words on your resume. C. Okay, that's good. You do kind of want that. That's a letter. Python. C++.

And then you go over to hardware. ESP 8266. Cortex-M is way better for that word search than the ESPs are. And so you can choose whether to get a broad, lots of words on your resume, or to do a relatively narrow... I'm going to back up. I'm going to back up. I'm going to say,

do a project that's directly applicable to Embedit. So you said Cortex-M. Do something that's broadly applicable. Use a Cortex-M. It doesn't really matter what you do on it. Just demonstrate that you have facility with writing code that runs on a Cortex-M and that you can piece together a modular set of hardware. You don't have to be an electrical engineer, but here is my embedded thing.

It does this. If you can hold it, it will work so much better. You can bring that to an interview. It really is nice. Bring that to an interview and be able to talk about, okay, here are the things. Have some artifact that's small enough that you can bring it to an interview that does something interesting. Have it based on current-ish hardware that companies use, Cortex-M, STM32, and be able to describe your code organization and your architecture on a whiteboard in an intelligent manner and answer questions. I think that is a huge, that would be a huge advantage because normally people don't come in with stuff, right?

And be able to sum it up in 30 seconds so that when they say okay what was your senior project and you you excitedly enthusiastically tell them about it they say tell me more and then you pull it out of your backpack and stick it down and now you are running the interview and you are doing great and just make sure it works even if it doesn't work have, yes. On the other hand, I don't want to discourage you from making the kegerator monitor. But the less your project sounds like a party toy, the better. You do want it to sound professional. Even though keeping my beer cold is important, maybe you could ask the chemistry department if you could keep their solutions cold so that you could also use it that's harder to bring into an interview

here is my doer of liquid nitrogen well no i mean here's my monitor of a temperature of minus 473 celsius i just want to point out that it is you you probably do want to work on something that is sort of exciting and applicable to you because that will get you up in the morning. I wouldn't target it to oh this company makes wearables. I'll make a wearable. Doesn't matter. Just make something that's interesting to you that's not a total joke.

It's not, you know but it can be whimsical. It can be whimsical. But it just has to demonstrate solid development skills on a particular useful platform. And the ability to communicate those skills. We really don't emphasize that enough. All right, enough. All right.

We've counseled this person enough. We've counseled them to the ground. Wait, they wanted to know what professional certifications would help get me noticed. None of them. I'm not kidding. I don't think those are important. Yeah help get me noticed. None of them. I'm not kidding. I don't think those are important. Yeah, I don't.

Not in America. I don't know where this person is, but. Yeah, it'd be nice if I didn't strip off their emails, huh? Oh, well. But he did say he doesn't have a lot of time for personal projects. So we just gave him a long laundry list to work on a personal project. But that was his senior project. All right. If we didn't answer your question, email in.

We'll re-answer it in a different way. We'll re-answer it in a different way, yeah. If you don't like our principles, we have others. Jason emailed to ask about IBM Rational Rhapsody. Oh, man. He's been trying to find a way to set up automated unit tests. This was all

in regards to Miro Samic's appearance on the show. Really, I should have forwarded it straight to him. Wow. I'm going to punt on this and uml i've i've been next to uml several times never actually had to use rational i'm sorry that you do wait no that doesn't sound right um but hey he has a new lightning round question for us. Oh, okay. What is your favorite short story?

Favorite short story? Oh, wow. Wow. Wow, that's really hard. Really hard. I've read a lot of short stories. Okay, this is not my favorite because I sort of hate it. And I hated it then and I hate it now.

So that's really not a very good answer to the question. But it is one that sticks with me. There's a Ray Bradbury short story about Venus and the sun comes only very seldom and the other kids make it so she misses it. That story still bugs me and it's, I mean, it's got to be 30 years at this point since I read it. I have a book of Canadian folklore stories. This is true, he does.

And it is one that I have put in the pile of, surely you don't still need this, sweetie. And every time it's pulled out. I'm pretty sure there's a story in there that I like quite a lot, but I can't remember which one. So I've narrowed it down. It's in a book somewhere. All right. All right.

That's how we're going to answer that one. Yeah. I did just read John Scalzi's new book about really tiny short stories. Yeah, it was like 2,000 words was the max. And he has one where the yogurt becomes

sentient and controls the world and we agree to follow its plans. And it all sort of makes He has one where the yogurt becomes sentient and controls the world, and we agree to follow its plans. And it all sort of makes sense as you're going along, and then at the end you're like, it was yogurt. That's on his website too. What? Yogurt? Yeah.

Okay. They were culture jokes. That's, were they like culture, like the Ian Banks culture? Mm-mm. No? It wasn't referencing that in kind of a jokey way with yogurt and Ian Banks, the culture series? I don't think so. I have no idea what you're talking about, so I'm sticking with it.

I don't think so. God, you haven't read any of the Ian Banks books? These are the ones with the super long names of their boats, ships. Well, they're not super long. They're just strange. All right. Now, once again, we are both Googling instead of podcasting. Anyway, yes, some of them are quite good.

You should read some of them. I've read a couple of them. Anyway, the civilization is called the culture. Oh. Oh, yeah. Well, I'll check, but I think I have read some of those. And that brings us to the end of our... Aren't you glad? Aren't you really glad? Next week, we will be recording through all new audio equipment.

Well, not all new. I will have the same mic. Right. I think Christopher gets to keep his mic. And we'll be using the same microphone preamp. But we are upgrading Alicia's mic. We tested... Five or six mics. And a couple different settings on them.

And chose two or three. And Chris gave me the audio. I read a poem through each mic. And then he me the audio. I read a poem through each mic, and then he gave the audio, and we did blind tests of which ones we liked best. And to my shock and horror, this mic that I am using right now And have been for three years. Was dead last for both of us. Yeah.

So, yes. New mic. New mic is coming i will sound totally different except probably the same to you because this is fixable with eq no you might sound different i might sound different unless the ticking of the clock has driven you insane in which case you never have to listen again but you probably aren't listening now all right goodbye children are you going to put that on are you going to put the mic test on the why would i do that to them yeah why would i do that to us it was pretty hard to listen to plus you did say burb for bird every time i didn't say it every time it was pretty much every time je Jeb, jeb, bird.

Birb. Birb. Good night. Good luck. Thank you. Thank you for Christopher and to Christopher. Thank you from Christopher. From, yeah.

Thank you at Christopher.com. And of course, thank you for listening. I thought to leave you with from Maya Angelou this week, even though it probably should be Winnie the Pooh. I know why the caged burb sings. I did then what I knew how to do. Now that I know better, I do better.

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.