Embedded - 405: Bacta Tank for Your Brain

Episode Date: March 11, 2022

Chris and Elecia talk about burnout, a SPI + RTOS bug, newsletters, receiving feedback, Elecia’s class, and listener projects. Elecia’s Making Embedded Systems course on Classpert is starting a new cohort on March 19th. She gave a live talk related to the class about looking beneath the surface of Arduino (YouTube version). She’s excited about the Wokwi Raspberry Pi Pico simulator with C. Want more interesting email? ThePrepared is a weekly email about engineering, infrastructure, and manufacturing news Elecia was interviewed by TheAnalog.io newsletter which is a weekly email about manufacturing and engineering Embedded.fm has a weekly newsletter about topics related to the engineering focused podcast (and transcript) Chris Lott wrote a Hackaday article about episode 404: Uppercase A, Lowercase R M with Reinhard Keil. Elecia enjoyed Thanks for the Feedback: The Science and Art of Receiving Feedback by Douglas Stone and Sheila Heen. Serial Wombat peripheral expander for Arduino will be on Kickstarter soon Chris wanted machine readable datasheets, listener Nick responds with Cyanobyte on github. Infineon (previously Cypress) PSoC (wiki) is a chip/FPGA thing. We talked with Patrick Kane about it in episode 32: Woo Woo Woo

Welcome to Embedded. I am Elysia White, here with Christopher White. We have lots of little things to talk about today. Like the dog? I hope not, he's being good. Is he? He doesn't look very good. Our dog Bear is 16 years old. Maybe 17.

Old enough to start buying drinks on his own. Wait, is that the drinking age? Well, in dog years. In dog years, okay. Why are we here? I have a couple of questions. All right. And I've read a couple of interesting books, and I heard you had an interesting bug.

And let's start with burnout. Because at the end of the discussion, burnout will just stop recording. Exactly. Okay, go for it. How do you define burnout? I think at its simplest, for me, what I mean by burnout is when I don't feel like, not only do I not feel like doing anything, when I try to do things, I am basically ineffective. Or much less effective than perhaps I am when I'm not burnt out. How long does it take you to get burnt out? It took me one year to get burnt out

and I have not ever become unburnt out. That was like 20 years ago? Maybe 30. I don't know because getting unburnt out can sometimes happen very rapidly if the reason for the burnout is not necessarily just fatigue. So like there've been plenty of times when I've been working at companies and

I would consider myself burnt out because the work I was doing wasn't that interesting. Or it was very frustrating to get work done because there was some process that had been introduced where now doing a simple task took 24 hours instead of 20 minutes, things like that. And so, or even just having not enough work. There have been places I've been at where the project was just kind of this thing in a giant company and nobody cared, nobody showed up.

And I basically sat and read news for the whole day because there was nothing to do. And that kind of burnout can be shifted. And it feels the same to me. It feels like I can't do anything. I don't want to do anything And that kind of burnout can be shifted. And it feels the same to me. It feels like I can't do anything. I don't want to do anything. This sucks. That for me has been shifted by just changing surroundings, jobs, whatever, to something more interesting. So I've gone from feeling like I can't do anything one week to the next week being totally engaged in a project and learning stuff and making huge progress because I'm doing something that seems fun. So that might be a different kind of burnout

than just having worked super hard for so long that you need to recharge. And for me, I don't know how long that is because I honestly have not been able to may be politics or I'm just not getting it. And then I go and work on a different piece of the project and it makes sense and it's fun. And I solve the intellectual puzzle and then I go back to the first one and it's fine. Because I've kind of recharged my resilience reservoir. And then there's, I think, the burnout we're all experiencing with a constant level, not even a low level of panic of what's happening in the world. That's really hard to separate. I think it adds a level of exhaustion to everything.

Yeah, well, it's a cognitive load thing, right? Yeah. That's, I i think real burnout involves not being able to deal with the cognitive load and if there's a chunk of that taken away by something you can't get rid of yeah then then you know that that level of your your ability to do things has dropped your Your gas tank is less full. Yeah, and there's no way to fix that besides ignoring things and pretending they don't exist, which is not actually all that useful.

But doing things does help, paradoxically. It may be that sometimes I find that I can't do something really technical or thinky in that situation. And so I'll go do something else that's manual, you know, with my hands or some project that doesn't involve a lot of thinking, but still occupies my entire person without focusing on those other things. So at the end of last year, in January of this year, I was finishing two big projects. And I was teaching class and I was doing all my normal things of podcasting and mentoring and generally trying to keep up with the world. I definitely had less cognitive load due to the state of this stupid world right now. And it took, I mean, I had been doing those things for nearly six months,

doing them intensely for four months, And I could feel myself burn out. Changing. So what does that feel like for you? Changing tasks. It didn't matter. There was no recharging. It was all just out. I got so that even origami, which is usually fun for me, was just as draining as anything else.

Yeah. It was solving a puzzle. for me, was just as draining as anything else. It was solving a puzzle. It was sometimes writing code, but more often trying to get my hands and my brain to agree on what something should look like. And there wasn't anything that was recharging. There were a few things that weren't taking more energy, generally reading novels, learning I could do in spurts. Like, I got a couple of great books for Christmas, and I could read them, and they were interesting, and then I could just feel my brain go, yeah, but that's too much. And I mean, it was definitely depressing. There's definitely a level of depression to it, but it wasn't like I was depressed about anything,

except that my brain was very, very tired. And I could work, like I could work for a couple hours and then it was just like, no, it wasn't a, oh, this is too hard. I don't feel a couple hours. And then it was just like, no. It wasn't a, oh, this is too hard. I don't feel like doing it. It was just a, no. I have no more cognitive power for you today. You might as well just go to sleep because we're not doing anything else. It was really hard.

And I thought, well, I won't have the two big projects. I'll just have class and the podcast and it will be easier. And unfortunately, when you teach a class, it will suck up all time available. There's always something to do. There's always something better you can put in some way that will be more demonstrative to the students. There's always more you can do. So thinking that that would recharge me was not correct. The students were fantastic, and I wanted to be recharged by them because I was learning so much, and everybody was helpful to each other it was a really good situation but it was still a couple hours of grind and then no and i couldn't find anything else to do

i mean it wasn't just origami there's a lot i mean i do a lot of random things i understand that not wanting to do anything or not thinking that anything is going to be interesting. Is that what you're talking about? Like you couldn't find anything else to do? It meant there was just nothing that you felt like doing? No. I mean, it wasn't sometimes, but it wasn't really boredom or depression that way.

There were things I kind of wanted to do, but I just couldn't. Drawing seemed too hard. Okay. And definitely writing was not going to happen. Anything to do with the screen got tossed pretty quickly. And like I said, it took me months to get there, and I knew I was doing it. In November, I knew what I was doing. I was using resources that I usually did not expend because they are my hoarded resources, mental resources. And so I just, now the question is, how do you deal with it?

You don't do stuff. You just sit immobile for weeks at a time until you've completely recharged in like a capsule. I saw this on Boba Fett. Yeah. And there's the liquid. Yeah, yeah. The bacta. You need a bacta tank. I need a bacta tank for Fett. Yeah. And there's the liquid. Yeah, yeah. The bacta. You need a bacta tank.

I need a bacta tank for my brain. Title. Yeah, no, I don't. I mean, I'm sure there are people who know about this stuff and study it who have, there's like, you know, some psychological or physiological thing. I mean, most people say, go on vacation. I'm like, okay. Vacation for me leads to burnout.

Because you let yourself get bored. No, I just, you know. Most people think of vacation as travel. And travel is very stressful for me. And so the definition of vacation, I need to move it toward not need to worry about stuff for an extended period of time. And I think that does help sometimes, but you really need to do it. I'm not looking pointed think about anything related to embedded systems or computers or C compilers or anything like that. Here's what I'm going to do.

I'm going to go in the garage and I'm going to finish building that ukulele for a week. And that's what I'm going to do and listen to podcasts or music or something. I don't know. I have found the times when I've been in that kind of burnout that just, I need to totally disconnect for a while. I did that. I was, okay. After my first startup, I was completely fried. I left there and I went to grad school, which you would think would not be a way to recover from burnout, but it was because it was a shift from, it was a shift of work completely. I wasn't sitting at a computer all day. And it was a difference between output and input.

Yeah. And I, uh, I was thinking about different things. I was responsible to myself instead of being told what to do by, you know, a manager. The performance stuff was different. I got, you know, instant feedback. Yes, this is right. No, this is wrong. And there were no larger overarching, oh, I've got to finish this thing, you know, kind of stuff. It was all naturally broken down into, okay, I'm learning this, I'm learning this, I'm learning this.

And my time was scheduled in a way that was really freeing, because I had time to relax, even though I was doing a lot of work, because I was no longer sitting at a desk from whatever it was, nine to seven back then, or nine to eight, or whatever I was doing, and staring at a laptop by myself. And it was differently social too. Working with students is different than working with coworkers. Um, so it was a major shift and it was still hard, but I did feel like I recharged pretty

quickly from that. I also had some other issues from later on, but, uh, that I felt like I like that bounced me back pretty quickly. When you were at the startup, it was all learn and output as soon as possible. And in school, it was learn to put into yourself. The output was checking, not producing. So I think there's some element of that, of recharging means putting things back in instead of a constant life of produce, produce, produce. For me, I'm still kind of burnt out. I'm getting a little better. I did take time off, but time off was teaching class and doing podcast stuff.

There's a reason why we have a new homepage. I don't, because I really wanted to do origami and I just, and I got a little bit of stuff done. I can do more open sea snails now. I still haven't quite got conscious, but I think I know how. Anyway, I am trying to recognize that it probably will take me months and that I need to be more open to input and less work, work, work. I kind of wish we had a little bit more space between

the red jellies cohort in Classpert and the Orange Stars. You're going to have to tell people what that means. Oh, so it's a cohort-based class, and the groups have names. And I needed to be able to tell which group it was, and I just didn't want to do one, two, three because boring. And so they're color-coded ROYG BIV, so red, orange, and then a sea creature, and sea creatures are random. The next one is yellow seahorses, which I think the icon for that is going to be a dragon because of a Japanese anime we saw once,

and so that makes sense to me. Okay. But we were talking about, oh, you were talking about the break between semesters or class groups was being too short. It was too short, which was my doing. I should have pushed it.

Partially because the class projects took forever to grade. And I mentioned this. Grading is hard. Grading is real hard. Well, and I mean, nobody failed because they were all really good. But it's still, how do you give good critiques? Yep. And you have to do it at a reasonable pace so that you're not giving a really good critique to everyone

so you'll get done grading in six months. That was kind of what happened. The mentors all went through the list of what they were supposed to do and filled out the project rubric, and then they were supposed to give a paragraph or two of comments. And mostly they gave like six paragraphs. Yeah. And I was supposed to go through their review just to make sure it was okay. And then to take a look at a

high level at the projects. But of course, you know, I looked at the code because I wanted to know. And so I was supposed to give like one or two sentences and I gave one or two paragraphs. So, you know, but even as Classpert was saying, do a worse job on this and you won't feel so burnt out, I was like, I can't. I can't

do a worse job on that. Or I can't be me and do a worse job on that. It was a lot like the Hackaday Prize. Although there were fewer submissions and I did more in-depth analysis. And yeah, the next cohort starts on March 19th of 2022, which is like a week after this post. We expect to sell out.

It'll be a little better than the red jellies because we have some pacing problems, I think, fixed. We're not using embed. Instead, we are using Uri Shaked's Wokwi, and it is simulating the Raspberry Pi Pico. We had him on the show a while ago, and one of the things about the whole simulating the processor and then letting people run code on the cloud to run on that processor was that it was all Arduino covered. Right. Because he targeted toward hobbyists to start with. Yeah. And everything was set up in loop. But Uri and I have been talking since he was on the podcast. And he now has a Raspberry Pi Pico simulator that you can run Z code on.

So that's what we're going to use for the simulator. And that changes some of my classes. But I'm kind of excited about it because his simulator is so detailed. Lots of stuff with that. So that's cool. I mean, that's cool beyond the class. Yeah, no, it's, it's totally cool beyond the class. You don't have to be in the class to play with the Raspberry Pi Pico running C.

You can do that on your own. Cool. And then another reason the class was too close was because I did that live session with Bjorn Arduino. That was about looking at what Arduino is made up of in terms of electronics and the software a little bit instead of just here's how to use Arduino or what was the... I didn't watch it. That's okay. It is available in a video, but unfortunately the first couple minutes were cut off

and that was where I told people that they were supposed to ask questions and I had it all set up to do this choose your own adventure with people asking questions and I'd go to different parts of the program. And it totally didn't work because nobody heard that part. But it was about looking at the Arduino schematics as if you were looking at a development board. Oh, okay. And then looking at the processor like you would if you were looking at an STM32 development board. And you were looking at the processor.

Let's look at the data sheet. Look, there are application notes. And then considering the difference between looking at the Arduino as a black box to looking at it as an engineering tool and what you don't get with that, like a debugger, and what you might get with something else. I had fun preparing it, but most of the fun I had preparing it was the whole choose your own adventure part that didn't end up working. But I might try that again because it was kind of hilarious. Oh, I have one more thing to say about Classpert and then we'll be done with them. They are now on Qualcomm's internal training accepted training list. And what that means is you will get

reimbursed if you take the class and you're at Qualcomm. So my question is how do we get on everybody's list? I don't have the list. This is better if your employer pays for it. And they should because it will make you more effective at work.

You need to get on the government list to get some of that sweet taxpayer money. Wait, that's my, what? Okay. All right. I heard you had a tough bug recently. I did, and it made me... This is what happens when we try to record the podcast before 10.

I cannot speak. Yes, I had a bug, and you helped me with it. And also somebody on the Slack helped me with it. And I should find who they were so that I can credit them. So give me one second here to find the person who helped me. Yes. Okay. So anyway, so I've been working on embedded stuff for my client, which I have not been doing in a while, so that might explain why I had a little trouble figuring out what's going on. But without details of what the product is or the device I was talking to, to set the state, I have a device that is basically an ADC, and you can configure it to have a certain fixed rate of conversions

on multiple channels. And so there's a fair amount of data that the device has that I need to get from it. It's a spy device. And it has its own internal hardware FIFO. And so the way I had it set up was you can set a watermark on the FIFO to say, hey, when this is half full, send me an interrupt and I'll go set a watermark on the FIFO to say, hey, when this is

half full, send me an interrupt and I'll go get the stuff out of the FIFO. Pretty standard stuff. Which is why I'm describing the bug, because it's actually all pretty standard stuff and other people could get tripped up by this. So that was working mostly fine. So I'd get the interrupt and I would go and do a long SPY transaction. And the way you get the stuff out of the FIFO on the device is you write FF as the command, and then you just write whatever. You just write, and it will keep giving you data for as long as... It responds on MISO for as long as you've got stuff in there. So if I know how long the FIFO is full, then I read that many bytes.

So I'm using Cypress, and the command I'm using right now is part of their low-level API, and it's basically writeArray. And what that means is I give it a buffer of a certain number of bytes corresponding to the number of bytes I want to read, plus the command. And I call this writeArray function, and it just does it. And then when that's done and I know it's done, I read stuff out of Cypress's FIFO. Now this is where things get interesting.

Cypress, the spy device on Cypress is this little FPGA. The Cypress devices have these little reprogrammable logic blocks. It's a PSOC. Yeah, PSOC. And they are like little fpgas but that's how they do all their peripheral configuration so you get the arm core and then

you can use their library of vhdl verilog some hardware-ish language that does fpgas and it's all abstracted up so you don't have to really think about that if you don't want to. Yeah, you just plop in, here's a spy device. Yeah, so there's this graphical thing, and you drop in, okay, I want a spy here, and I square it here, and I want a GPIO here on these pins, and you route all the pins, and it's completely reprogrammable, which is really cool.

The flexibility is incredible. So they're a little spy block. You go in and you configure it, and it's got a FIFO of its own. And so if you dig into how their API works, when you do that write array function, it's basically a for loop, and it takes each byte from your array, and it stores it that byte and stuffs it in the hardware FIFO. And then the state machine and the actual SPI block in the FPGA bit handles, you know, taking that FIFO and starting to transmit it over SPI. Okay, so what was happening was this was all working great. But sometimes, within 30 seconds to a minute, my whole data capture state machine loop would just stop. I was no longer getting interrupts saying the FIFO is full. And you need to read stuff. It was just like, yep, the device is done. So that was super weird. So I pulled out my salier on your suggestion after being very flummoxed by this because it just didn't make any sense. Actually, the first suggestion you had was

instead of writing zeros to the device when I'm intending to read, is to write FFs. And it never stopped when I wrote FFs in that big array. And the reason was because somehow the device was interpreting zero. Zero is a badly designed device. Zero, turns out, is the command that turns the FIFO off. So, aha, somehow the device, when I was intending to read from it, was interpreting some of the zeros that I was using to, you know, trigger spy read as an actual command. And it was saying, oh, I'll turn the FIFO off. So I at least had the mechanism for what was going on. So on your

suggestion after that, I took the salient and lo and behold, I could see that I would write FF and then immediately have a few zeros to read out, but then it would stop and chip select would go up. And then 30, 40 microseconds later, chip select would go back down and then it would just start writing zeros like it was finishing the rest of the array. So I was a little bit confused by this and i let myself get confused by the fact that oh this spy thing is hardware and so how could it be interrupted by the r toss

and it turns out it was interrupted by the r toss and i put too much faith in hardwareness to be this autonomous unit that can't be interrupted. Because think back to how it works, and Mitch on the Patreon Slack, he kind of pointed me in this direction very, very easily.

Because he's worked with this before and he's seen it. So what's happening is, like I said, it's a for loop that takes every byte out of my array and puts it into that FIFO. Well, the RTOS comes along sometimes. And maybe for 10 milliseconds, that for loop isn't running. But the hardware is running autonomously. So it was actually not helping me to be autonomously running. Because let's say I wrote eight bytes into the FIFO, and it starts its spy engine going. And now the RTOS comes along, and my for loop pushing stuff into the Cypress FIFO

is interrupted, while the hardware is still transmitting. And so its FIFO is emptied. And now it thinks it's done. So it moves chip select up. And then when the RTOS comes back, we continue our for loop and start filling the FIFO again. But the hardware block, the hardware spy controller block thinks, oh, this is the start of a new transaction. My FIFO just got filled again, moved chip select down, and we will go. So it was the RTOS all along, but it was really kind of subtle because it's this interaction between the peripheral doing its thing, a whole bunch of asynchronous things happening in such a way that I underfloat the FIFO on the SPY peripheral in a way that made it split up my transaction into two bits with catastrophic effect.

Is your RTOS preemptive? Yeah. Really? It's free RTOS. Well, I mean, you can still configure it to be... Well, an interrupt comes in. That doesn't matter what happened. And so you just need to add a critical section around that.

That's what I've done. And there's... Mitch points out that he usually uses... So there's a configuration in those SPI blocks where you can have the hardware control chip select or you can control chip select for software. So that's the other way to get around it is, okay, I'm putting chip select under my control,

which means that even if I take a break in transmitting bytes, I'm not going to flip that chip select, which is going to make the device think the transaction is over. So that's probably the easiest and least destructive way to do it in terms of not having a big critical section where you're writing out a whole bunch of data for a long period of time and blocking other stuff. But isn't that just a mem copy from your internal RAM to your SPI FIFO?

No, because the SPI FIFO registers one byte wide. Oh, so you are really blocking. So it has to be a for loop. Oh, it has to be a for loop, but that for loop shouldn't be taking any time. Sure. It should just be a... But you get preempted by an interrupt.

That's all it needs. No, that's true. I just am surprised that what should be taking almost no time takes long enough. And I only need to be preempted for maybe a microsecond or whatever. It's an 8 megahertz spy. You can do the math of how long it takes to transmit, say, 7 or 8 bytes. It's not very long.

But you aren't transmitting them. You're putting them in a FIFO for later transmission. Right, but the hardware block is transmitting them. So all it needs to do is be idle long enough for those eight bytes to have gone out and nothing else to be left. Yeah. No, it's tricky. I feel kind of dumb, but it's one, it's one of those embedded things that, oh, yeah, you just make a spy thing and then you do your thing.

Like, well, yes, but. All right. No further comments? I have many, but I don't really think that they're necessary. And you have ways to solve it, including DMA. Oh, yeah, you don't need to solve it. I'm planning to go to DMA. Well, maybe.

There's other details about this device that I won't go into, but I had planned to use DMA. But, yeah, there's a lot of ways to solve it. It's just getting to the point of understanding so that you can solve it is tough sometimes. Oh. Because you have to understand how each of these pieces work to know how they're not working.

And that's, I mean, that's why we feel stupid so often because you have a bug and once you understand the bug, the fix is two lions, maybe two characters. But until you understand what's going on, you can't do anything. And I have a little bit of a bias, a little bit of a prejudice to think, well, this should be easy. It's just spy. You know, you write, it gave me an API.

I wrote the stuff. Their API should be tolerant, right? See, I have such a bias against RTOSs. I'm like, well, if something's going wrong, did I screw up something bias against RTOSs. I'm like, well, if something's going wrong, screw up something with the RTOS. To be fair, I don't know how the RTOS is configured. I usually assume things are preemptive unless told otherwise, because that's the most safe assumption in terms of things can be screwed up. But there's always a source of preemption, even if you're not running a preemptive scheduler. Yeah, so fun things. I'm sure there'll be more fun things like that, but it's embedded as hard even if you've been doing it a while.

You've been having fun with this project, though. Yeah. Newsletters. Newsletters. In an effort to make our newsletter better, we started looking at other newsletters. And Chris Svek, who is not the host of this show, recommended The Prepared, which is an engineering, infrastructure, and manufacturing newsletter. Weekly, free, kind of entertaining too so pretty fun links and links to blogs it's a kind of an aggregation you get to see lots of other things happening it's not necessarily them doing them where ours is usually 97 links to embedded and whatever our show notes have.

So that one, I've been enjoying that. I also found the analog.io, which is founded by the CEO of InspectAR, InspectAR, that we talked to a while ago. We didn't talk to the CEO. We talked to engineers that work there. But he has a newsletter that is lots of general stuff, hardware related. And he asked me for an interview.

So I did that. It was pretty fun. Let's see. Oh, I wanted to tell people about Thanks for the Feedback, which is a book I read. You weren't thanking people for their feedback. This is a book called Thanks for Your Feedback. Right. Okay.

It's about how to receive feedback, which was kind of odd. There are so many other things out there about how to give critiques and how to give feedback. But this is how to accept it, which was kind of weird. A lot of people are bad at accepting both positive and negative feedback, right? Oh, yes. And I am definitely one of them. Even, I mean, positive feedback makes me uncomfortable. Negative feedback makes me defensive.

So, you know, either way. Don't give any feedback. No feedback. Just stare blankly. Try and make no moves. No eye contact either. In fact, let's just type. This would be so much easier for both of us. But the book actually went through a lot of scripts. So people tend to get defensive because they don't agree with the truth of a piece of feedback, because they don't agree that the person who is giving it to them has good reason to give it to them, or because it hurts their identity in some fashion. If you say that was an unkind thing to do, that makes the person trigger back to,

I'm a kind person, so what you say must not be right. They also broke it into three different kinds of feedback, which, and this is a piece that if I had had earlier in my life, it would have been so much easier. There's appreciation, which is obvious. People are saying thanks, and it motivates you, and it generally lets people know that you notice them. Appreciation, I think we all understand. And then there's feedback that is coaching. Here's a better way. I want to help you grow. And the last one is evaluation. And that's assessment. And here's where you stand. Here's where you are compared to other people. Here's where you are compared to some rubric or list of criteria. And so many times people have been trying to give me coaching and I hear evaluation. People try to say,

it would be easier if you did X and I hear you're not doing it right. And since I'm getting it done, then I trigger back and get defensive about it. You're not correct. That's not the truth. I'm doing it fine. But the thing with the book is that, I mean, there are these things which are, this is like the first paragraph, first chapter, but it goes through scripts of how do you break that down? How do you break the cycle of getting defensive? How do you figure out what they're commenting on when what they're saying is you're unkind? That sort of thing, that's a label. It doesn't tell me what I can improve on.

So, you know, give me an example or even that's not how I see myself. Let's talk about why you feel that's true. And this script, the giving me words of how to respond so that the part of my brain that says, no, no, no, no, fire alarm. Oh, my God, this person doesn't like me is quieter because I can shut that person away and go towards the, this person may have something useful to tell me. And I didn't, gosh, scripts are amazing. I didn't know growing up that there were scripts. Do you use them? Do you, do you look for them? Um, I have been told to use them in the past, but I don't, Well, not for dealing with other people, no. I have learned how to deal with people through trial and error. Does that work?

Yes, eventually. I just, I find scripts magical. If this happens, these are the three things I could say, and these are the outputs that I will probably get from them. But don't you find that that sometimes can lead you into trouble if things don't go according to script? Like, there are times where I have pre-gamed out difficult conversations, to the point of

possibly a script. But they almost never proceed in a way that that works. And maybe it's the people who I'm employing that technique against, but sometimes, sometimes things go so differently that I'm off script and now I'm just back to, okay, making stuff up as I go along and trying to,

trying to solve a situation. Well, there's a difference between pre-gaming or pre-considering a conversation and trying to identify what can go wrong and what can go right and how you would respond if they respond to that. Scripts are more when I don't know what to say or I realize that what I'm about to say is not what I want to say, really.

Sure. What do I fall back on? And they sometimes sound, you know, really can't. Like, that's not how I see myself. Let's figure out where the discrepancy is. Yeah, but what if this person responds, yeah. Yeah, no, I get that. I get that.

I'm not poo-pooing the idea. I'm just imagining scenarios where I would have applied that. In those circumstances, the other person needed a script too, because it's, yeah. I guess a lot of this presupposes that at least one person is being rational in the conversation. Well, that was the goal for me, was to be the rational person. I see. Yeah, okay, okay. I don't want to go with my first impulses. I know when people say, you should do this better, and I say, do you have a podcast? And they say, no. And I say, well, then I'm not going to take audio advice from somebody like that. I fail to say, oh, you're a professional producer of podcasts.

Or I can ask more questions if I don't immediately go to no. And I so often go to no. And this gave me a list of questions to go beyond that. And it gave me ways to ask for feedback. Instead of saying, can you give me feedback? It's like, what one thing could I be doing better to get out of my own way? Yeah, sure. Because just asking for feedback is really hard.

It's like, I don't know, you did fine. Or you did terrible, but I don't really want to talk to you about it for the next hour, so I'm going to, you did fine. Or you did terrible, but I don't really want to talk to you about it for the next hour, so I'm going to say you did fine. It's been a really good book for me. I recommend it. It's an important skill, and it is probably a skill for a lot of people to develop because feedback is something in our professional lives we get a lot and a lot of the worse uh professional disagreements and arguments and uh you know near near fights and things that

i've seen not necessarily been a part of have been over technical kind of things like oh here's your code review and you and here's the feedback on what you should do differently. And people not taking that well or not giving it well, does it have, I mean, thanks for the feedback seems like it's tailored towards accepting feedback, but giving feedback is also quite difficult to do in a way that doesn't get people's hackles up a lot of times, depending on the person, of course. But that's another thing you need to be aware of is how individuals take feedback. You can't just go, no, this sucks to somebody's PR. But I've seen that.

Yes. And there's very few people who are going to take that well and so you have to ask what was the intent of the feedback um so it's a two-way street but it is hard to take feedback sometimes and i think that's an interesting thing to focus on it discusses some about how to give feedback or how to deal with feedback that is completely baffling. And it also had a section which I think is important for me, is sometimes you don't take the feedback. Sometimes you listen, you understand, and you just say,

okay, I'm not defensive about it. I just don't want to do that. Oh, my response to that kind of feedback is noted. Yes. Thank you for your input. I love that for you. It doesn't really work, but bless your heart. Yeah, those don't apply.

But I appreciate noted, especially if you say it in a slightly, slightly flat, irritated tone. It's passive aggressive. Oh, do they say that's not good? No, I'm saying... There isn't a big chapter on improving your passive aggressiveness? They do talk about passive aggressive and whether or not that gets you where you want to be. It doesn't necessarily get me where I want to be, but it feels really good. Yes. Yes, indeed. Let's see. We got some nice emails.

Kurt and Allison and Dan Matthews all sent me emails that will be going into the folder for days when I have a bad day. Because their emails were very nice. We got some links to various things. The Serial Wombat that's having a Kickstarter soon that's a pick-based Arduino-like thing. Yeah, I needed more of a, what is that? If you're taking feedback, I would put right at the beginning, what would I use this for? Which I think you've tried to do, but I still couldn't quite.

But it might be interesting if you are a pick fan. It's an expander. It's a peripheral expander. For I2C and UR. Yeah. So like you've got, if you run out of stuff you can add one of these and it adds some peripherals it's like you know

what are they GPIO extenders but it does more stuff than that yeah and it's easy to program from Arduino yeah so there you go serial wombat so you're not you're not developing for the PIC And it's easy to program from Arduino. Yeah. So there you go, Serial Wombat. So you're not... And it's a little chip.

You're not developing for the PIC. You're developing for the Arduino, which talks to the PIC. Yeah, so it adds A to D and GPIOs. And so if you've got a really small thing that might have, let's say, just one or two, not one or two serial things, but a small number of GPIOs or no ADCs or small ADC. This is a little eight-pin guy. And you can add a whole bunch of them on I2C

and talk to a whole bunch of other stuff. And it's pretty smart about these things. We also had Nick sent us a link about Cyanobite, which is meant to define machine-readable data sheets. Oh, yes, yes, I did see this. Device registers are defined with other pieces of metadata, command line to generate usable code depending on your hardware platform, Arduino, Raspberry Pi. This was the sort of thing I was demanding a few shows ago because I was dealing with, I think, the LISP2DH data sheet,

which was annoying. And all data sheets are annoying in terms of, well, the one I just did has hundreds of registers and they're all sparsely populated and you have to configure a lot of them and there's bits all over the place with shifts and masks and turning that into C code is a multi-day adventure, which you will get most of it wrong, I've discovered in the last two days. just really fiddly and tricky to verify. And it would be nice if the vendor just provided that since they made the table in the data sheet, they already know how. So this is the sort of thing that makes that possible. And I hope some people start adopting this

because it's really cool. You aren't bitter though, are you? It's just a waste of time. You know, from an economics perspective, it's dead weight. It's just a waste of time. You know, from an economics perspective, it's dead weight. It's not secret. It's not trademark. It's imposing a cost that does not need to exist on your clients.

It would be trivial to do once and help people appreciate it. But this is how we end up with hardware abstraction layers from ST. Yeah, but having a system to take your register definition and put it into C code is a one-time thing. It's not an abstraction layer, it's a script. So I like this, and please everyone start doing things like this so I can work less and complain less about computers. I'll still complain, but I'll just fill in with other complaints.

I have a few show things before we sign off. All right. We talked about marketing. Patreon, the Slack group, now has a show and swap, which you can swap boards or you can just show people your hoard and make them jealous the newsletter continues to improve we're on Facebook, Instagram, Pinterest

Pinterest and Twitter and according Chris Lott wrote a very nice piece about Reinhardt Kyle's episode on Hackaday. So I will link that in. Oh, thank you, Chris. And according to my Twitter, which of course is the source of truth and knowledge,

people want 10 to 20 minute podcasts. What? The 45 minute podcast is too much. Well, this, this right now is five, 10 minute podcasts. This is a sick pack.

What are they complaining about? I don't know. Um, okay. So they want short people like short podcasts. Okay. And, and it seems like a whole heck of a lot of work to trim these down to 10

minutes. I'm not going to do that. Okay. I mean, we could take... We could just take the discussion about burnout. Sure, for this episode. But like when we have a guest, I'm not sure. That's a trickier prospect.

Like I could take several interesting questions. I mean, it's an editorial thing. I could do it. But would people, by taking subcontent out of our existing podcast, I feel like that's cannibalizing our podcast. We're not going to get additional listeners, are we? We would get the people who only want to listen to the 10 or 20 minute podcast because they don't want to invest.

What if we release the podcast as volumes? Like, we'll just take the existing podcast, divide it up five ways and release it once a day. You know, I think that that actually might work. I mean, given my new expertise with marketing, having read the visual MBA book would irritate the people who don't mind

listening to long podcasts. No, it'd be two streams. Okay. Well, that's, that's an idea. I, it'd be two streams. Okay. That's an idea. We need to think about it more. I'm not against it.

I would, I still have a slight preference to doing something additional. That's a short podcast, but he wants us to have a 10 or 15 minute podcast. It's just us talking about whatever you want us to talk about. Yeah. Which might be, you know, whatever the previous guest talked about, but more our opinion. Or something that's happening on the Slack.

Yeah. Yes, today there was a post about LED colors and being able to see, to convert from nanometers to color on your web browser so you can see what your LED colors will be. So, yeah, give us feedback about that, especially since it's minute 57 of this podcast, and anyone who wants a 10-minute podcast would have stopped listening a long time ago and would not have feedback that's relevant to this question.

We're not supposed to just ask for feedback. We're supposed to say, what's one thing we could do better to get out of our own way? But anybody who wants a 20-minute podcast has already given up. Yes, yes. All right. That's all, right? I guess so. My meeting got canceled, so we can keep going.

Yes, but our transcriptionist asked us to stop doing super long episodes. Keep it short. Okay. Thank you for listening. Thank you to our Patreon slot group for continuing to be amusing. You can join that if you want. Patreon

Embedded. And I guess you can still email us, show at embedded.fm. Those are getting through again. Or hit the contact link on embedded.fm for your what's something we could do better. But you don't have to give us feedback. Chapter five, in which Piglet meets a heffalump. One day, when Christopher Robin and Winnie the Pooh and Piglet were all talking

together, Christopher Robin finished the mouthful he was eating and said carelessly, I saw a heffalump today, Piglet. What was it doing? asked Piglet. Just lumping along, said Christopher Robin. I don't think it saw me. I saw one once, said Piglet. At least, I think I did, he said. Only, perhaps it wasn't.

You don't see them often, said Christopher Robin carelessly. Not now, said Piglet. Not at this time of year, said Pooh. Then they all talked about something else until it was time for Pooh and Piglet to go home together. Well, that's a waiting for Godot sort of section.