Embedded - 469: Saving the World Is Not a Hobby
Episode Date: January 28, 2024Chris and Elecia chat with each other about motor encoder reading methods, conferences coming up, soldering irons, schematic reviews, looking for a new job, and general life. Some conferences coming... up in the embedded space: Embedded Online, April 29-May 4, virtual (Elecia will be speaking) Open Hardware Summit in May 3-4, Montreal, Canada Embedded World in April 9-11 in Nuremburg, Germany Evil Mad Scientist Laboratories was purchased by Bantam Tools! Starter soldering irons? It seemed like small pen-style ones were more popular than big soldering stations. See the Adafruit USB C Powered Soldering Iron - Adjustable Temperature Pen-Style - TS80P. Or for much less (but you can write your own firmware!), the Pinecil. And one vote for the RT Soldering Pen on Tindie because it uses Weller RT tips (which are more expensive than the soldering pen but much less expensive than the Weller station that uses the RT tips). Embedded Artistry has excellent advice for the role of the firmware in schematic reviews. Adafruit Playgrounds looks like a neat place to write up your project. Transcript Nordic Semiconductor empowers wireless innovation, by providing hardware, software, tools and services that allow developers to create the IoT products of tomorrow. Learn more about Nordic Semiconductor at nordicsemi.com, check out the DevAcademy at academy.nordicsemi.com and interact with the Nordic Devzone community at devzone.nordicsemi.com.
Transcript
Discussion (0)
Welcome to Embedded.
I am Elysia White, here with Christopher White.
We're going to be chatting about this and that, sundry and myriad things.
The other thing.
Is that the other thing?
Well, yes, of course, the other thing.
The computer that is now banished and on the floor, closed,
because we couldn't get
the podcast going today because seven years is apparently ancient for a computer and no longer
can function as a computer. And yet it is not that computer's fault that this show is late.
Oh, no, no. It's the fault that we're starting recording late from where we intended today,
but it is not the computer's fault that we were recording on Saturday for a podcast that we're starting recording late from where we intended today, but it is not the computer's fault that we are recording on Saturday
for a podcast that we intended to release on Thursday.
True.
The fault also lies on the floor.
Dog.
But it is a dog.
She's still cute.
A dog that the ER vet said was charming and stable.
Right.
She was less charming and less stable before we brought her to the vet.
Yes, much less.
Anyway, the dog is fine.
We're fine.
And we're mostly recovered.
But this is a show about computers.
Yes.
Do you want to do straight technical things to get started?
Whatever you have on your agenda.
That's fine.
Before we get into all of these things in the meat of the show, I do want to announce the two winners for the Nordic Power Profiler Kit 2.
The first is Evils.
Thank you for putting that down as the name you'd like to be called.
I believe it's Evils Devils. Thank you for putting that down as the name you'd like to be called. I believe it's
Evils Devils. And the second is Ken Chen. I did not mean for them both to rhyme, but they are
winning the Power Provider Kit 2 with its wide current measurement range and its eight digital
inputs, which allows it to also function as a logic analyzer. That's Ken's reason for wanting it. And Evil's one reason for wanting it is the PC
software works on Linux and can be used to control things like dynamic range and battery power usage measurement analysis.
Okay, so those are our two winners of the PPK2.
We will be starting a new contest with a different question.
Look for that in the ad spot coming up.
Okay, so you have a motor and you have an encoder.
The encoder basically is a piece of paper with black and white strips.
Or something transparent that you shoot a light through that also has black and white strips.
But we're talking about, you know, edges of, you're getting electrical edges of ups and downs. Every number of, some number of degrees, it switches from being occluded to white to black or whatever.
Or up to down.
Or it has, never mind.
I'm not going to get into quadrature.
Go ahead.
No, we're not doing quadrature.
Okay.
So how do you hook up that up and down line to your microcontroller?
Okay.
So the up and down line has to be detected by something.
So I'm going to assume it's like a light sensor.
Oh, we're past that and into electrical.
Okay.
So you just got an up and down line.
It's just an up and down line now.
Okay.
So that line goes to another motor that when it's up, the motor goes left.
And when it's down, the motor goes right.
And that goes to a little door.
And the little door opens, and when it's open,
there's a little food pellet that a mouse can eat.
And when it's closed, then the mouse can't get the food pellet.
And so as the motor goes, the thing goes back there.
And so what you do is at the end of the day,
you measure how much food the mouse has eaten,
and that's how many times your thing has gone around.
All right. I'm sorry thank you you have you have an input gpio a general purpose io digital logic input that either reads high or low or whatever or is bipolar or whatever but electrically there's
an on and off kind of indication that comes into your GPIO.
And you can either use an interrupt
that will signal you when the state changes
and then you count.
And then your higher level code
looks at that count periodically or whatever.
Or you can be in a tight loop
and look at the state of that variable
and see it changing.
And depending on how fast
it's changing, one or both of those might
work. This question actually
came from Silas who asked about
if your
actuator motor is running too fast,
would an encoder
interrupt service routine miss it?
Sure.
And so with your method,
there's a GPIO set to edge detection,
and when the edge detection interrupt happens,
it counts and then goes away.
Sure.
And we're only talking one direction.
We're not going to worry so much about going in the negative direction. Let's just go one direction for now. Sure. And we're only talking one direction. We're not going to worry so much about going in the negative
direction. Let's just go one direction for now.
Yeah. But the problem
is that if your interrupt
speed is too high,
that whole... Interrupt
speed is... If it's
signaling too fast. Signaling too fast.
Then you are
stopping the processor, pushing
down the stack, going to the interrupt space.
Meanwhile, the motor's still spinning.
Counting something, and then going back to your normal code,
and should you have any areas, critical sections where you've disabled interrupts,
if your motor is moving, you just don't get those counts.
Right.
Okay.
And on the small microcontroller, it's entirely possible that the motor, that you've got a
system configuration where the motor's spinning too fast, or you have too many, you have too
fine pitch resolution, you have too many edges, you know, so there's all kinds of ways to
configure that that you can't keep up with an interrupt-based scheme.
And what if you wanted to know the speed of the motor?
If you want to know the speed of the motor,
then you have to periodically look at the difference
between counts at moments in time.
So like every millisecond,
you would see what the count is now
versus the count one millisecond ago.
Yeah.
And then you would do dx over
dt, the distance
traveled, the number of counts
over the amount of time. You have to know what a count means
in terms of degrees.
And then you can convert that to
fractions of
revolution.
Okay.
You can connect it to
a timer counter input.
Yes.
I mean...
That will do this work for you.
Counters are not just for outputs anymore.
Were they ever?
No.
Okay.
So you connect it to a counter, and every time it sees an edge, it counts.
Shocker.
And you can, like interrupts, you can do rising edge, falling edge either.
Yeah.
Most counters also have a mode that when it triggers, it will tell you what time it is.
Okay.
So, like the timer is going all the time.
It timestamps the trigger. It timestamps the trigger.
It timestamps the trigger.
Yeah.
So when I said about velocity
and doing it every millisecond,
what if you weren't traveling that fast?
So there's not only the problem
with going too fast.
That's too slow.
There's the too slow problem.
Yeah.
And this triggering
when you get an interrupt,
doing a timestamp
when you get an interrupt allows doing a timestamp when you get an interrupt, allows you to do lower velocity movements, slower movements.
Because it's going to count up until it's got what you want it to count to or whatever.
Yeah, you can set the counter to go at whatever speed you think you're going to be getting your inputs.
But that's actually the critical piece here,
is you can't set any of this up until you have an expected velocity range.
Right. And doesn't this also kind of, isn't sampling theory implicated here too?
Like you have to be able to, right?
Yes.
Yes, okay.
Yes.
Sorry, I'm very tired. That sentence just trailed off but go ahead with this you have to be able to you have to be able to sample twice as fast as the smallest
uh feature change you want to to detect in time if you were polling if you were polling yes
with interrupts you're guaranteed to be getting when the edges happen. No, no.
You're guaranteed to get when the edges happen when things are constructed correctly and you're fast enough.
And you're fast enough.
So even this interrupt thing can't work if your interrupts are coming too fast.
But what you're saying...
Or even the counter thing can't work if the counts are coming too fast.
Because there are limits on your processor.
When you think about setting up a timer
counter system to
toggle an output,
you know that there's a maximum
speed that that output can toggle. If you have
a 2 MHz processor...
You can't output a terahertz from your GPIOs?
Not if I have a 2 MHz processor.
How are you making a radar system with your 8051?
Exactly.
Yeah.
And so when you look at the outputs for the timers, those are usually the same as the inputs for the timers.
Yeah, yeah. get yourself in a world of hurt if your counter velocity measurement system is either too fast
or too slow for your motor speeds. We finished a cohort at Classpert and I did the critiques,
which are really interesting and really hard. Students spend a lot of time making these projects
and they do a good job of writing it up
because I stress that writing it up is a big part of it
and they try to make their code.
I mean, they just do a really good job.
And there was one person who spent a lot of work,
but he didn't do the math at the beginning.
It was never going to work the way he wanted it to. But if he had sat down and thought, what are my input speeds? What are my
output speeds? What does that mean in terms of resolution? You have to sit down and do the math
up front, or you can get into this position where it's just like, I promised this and it can't work.
That's something I do on almost all systems. When somebody's asking me for something,
like, okay, I think the term that we used at Cisco, that the people I worked with were always
talking about speeds and feeds. Yeah, that's the term you've infected me with.
It's like, okay, how fast does our processor go? And how fast is data coming in?
Do we need to move data in and out?
And does that whole thing compute?
Like, does that all add up?
Can we do that?
And so in a lot of systems, like when you're doing camera work or signal processing,
yeah, you should look at, okay, I have a camera. It's taking a picture every five frames per second, let's say.
And it's got this many
pixels. And I've got to push it over this kind of interface, and that's got to go to the CPU,
which has to do this processing on it, and then ship it out, say, another interface.
It's really important that those things add up, because it's really easy to buy the wrong part,
or use the wrong interface, or have the wrong clocks configured.
And so you can't make it work because there's just too many bytes and too little time to go through the system you've designed.
And these are not hard computations.
Usually it's just arithmetic.
But it's sometimes hard to identify where the bottlenecks are.
Yeah. And at the beginning of a project,
I often feel that
I don't know all the numbers.
Right.
And that's the situation I'm in right now
with something I'm working on for a client.
It's, we would like to use this interface for this data.
And I'm like, well, it's a standard interface.
You know, it's USB.
Standard interface.
You read, you know, USB.
I always get high speed and full speed confused because USB is stupid.
But the 480 megabits per second speed, that is what the wire rate is, what we're using.
But you don't know how fast the microcontroller can keep that full.
And you don't know how the driver layer and the RTOS, you know, there's a
whole bunch of things. So yes, like you said, until you test it, you may not know how fast
something that on paper is a gigabit, you know, that's just how fast it can wiggle the wire.
It doesn't mean the computer behind it can actually put wiggles on that fast. But as you start to design a system,
you start with,
okay, I want two gigabytes per second
to go from here to there.
And then you realize
the wire in between is 480 megabits per second.
And then you release bits and bytes
and you're like, oh no.
And it just...
Oops, I have to multiply by eight
or divide by eight.
And yeah, you do have to multiply by 8 or divide by 8.
Yeah, you do have to sit down and do the math.
So anybody who's out there thinking,
I just don't know how all these things are going to go together,
let me recommend that you just sit down and think about how those things are going to go together
instead of doing the driver that you know how to do.
And the thing I found out yesterday was that
the USB, we could push about 68 megabits per second, which is fine for application, I think.
For now, for testing.
But it's not 480 or 480 minus overhead.
But that could be in your computer, in your stack, in your microcontroller, in your DMA processing.
Right, I tried different computers and they differed a little bit.
Yeah.
I changed the DMA buffer size to every variation I could think of
and it didn't change, so.
Oh, sorry.
I was hoping that would be useful.
But there is a whole pipeline there
and you don't know where the bottleneck is.
But at least now you have a number to start with.
Yeah.
You can't really improve upon it until you have a number to start with.
Yeah, exactly.
And it's, you know,
it's useful to have those numbers
because if you test again
and they've gone down
because you've made some change.
Yes, you make it slower a bit.
Then you know,
oh, this isn't broken.
I've made a change
that's created a new bottleneck
or there's some tuning
that has to happen.
But getting computers
to perform at peak,
you know,
to actually fill,
to get them to operate at 100%,
or as close to 100%,
when you have some application, right,
where you have data coming in and out,
and you want to optimize things
such that you're paying the least amount possible,
but getting the system to work.
And so you're filling up the part that you've bought,
its CPU capability and its bandwidth capability.
So it's running with just a little bit of overhead.
That's really hard to do.
It's really hard to get things past a certain point
and get them tuned.
It's funny, we had a question recently on a show
about why do people pay for processors that are too big.
That was the 6502 show.
Yeah, yeah.
And I was like, oh, oh, I know this one.
I know this one.
It's because we're too lazy to optimize.
Optimization is hard.
It's a skill.
I don't say too lazy.
It's a trade-off.
I mean, it's a cost-off i mean it's a cost benefit right if you want to spend like there
people going i was listening to a podcast yesterday and i guess there's a person and i don't have a
link for it i can go find it but they've been going back to the original nintendo 64 and optimizing
super mario 64 more so they have the original super mario, which had all kinds of compromises because it was running on the Nintendo 64, which, while cool for 1996, was possibly less powerful than your thermostat is now.
But they've been going in and rewriting the code of Super Mario 64 to get rid of fog and draw distance and fix texture mapping so it's better and finding ways to make it go faster.
So Super Mario 64 runs at a higher frame rate and looks cooler on the original hardware.
And I forgot where I was going with that.
Optimizing.
Optimizing can be fun, yes.
Oh, and the 6502.
Like, yeah, you can do that, or, you know, you can just get the next thing and not worry about it.
I've been having trouble with my hobbies lately.
They're pointlessness.
Oh, we're going back to the optimizing guy?
No, no.
I mean, that came out really wrong, didn't it?
Ouch.
Sorry.
How?
That's all right.
If your hobbies are pointless, that is great.
Nope, that still didn't work. Let me see.
Just talk about yourself.
Pointlessness is fundamental to the human... Nope, nope.
I'm still stuck on where I was going with the Super Mario 64 thing and optimization.
Did some people like to optimize, I thought.
I think the point was, like, Nintendo had to release it.
Yeah.
Oh, yeah. Nintendo had to release it. Yeah. Oh, yeah.
Nintendo had to release it.
Sure, 30 years later, people have been spending 30 years optimizing this game or whatever, right?
But Nintendo didn't have 30 years.
And so the tradeoff between, you know, buying a slightly bigger part and spending less time optimizing could be quite quite important right yes i could get doom running on a you know
completely underpowered system if i spent years you know finding mathematical tricks and things
but and that's probably worthwhile and interesting and compiling as a problem to solve as a problem
to solve but as it as as as a business as a business it's a bad idea yeah okay your hobbies
are point you think Your hobbies are pointless.
You think your hobbies are pointless.
Yeah.
Let me tell you about hobbies.
They're supposed to be pointless.
I know, but shouldn't I be doing something pointy?
What does pointful mean to you?
Saving the world, saving the environment, making other people happy.
Saving the world is not a hobby.
I hate to break this too.
Except to maybe Superman, who's like, you know, overpowered in every sense and pretty
bored probably most of the time.
Yeah, I don't think saving the world qualifies as a hobby.
Saving the whales, no, no, not a hobby.
I think saving anything except like, you know, baseball cards and coins, I don't think not a hobby i think saving anything except like you know baseball cards and coins
i don't think it's a hobby uh do you feel like your work is not impactful is that the problem
do you feel like you need to be doing something important do you have do you have do you have uh
a sense of missing glorious purpose like Loki or something?
I do. I do. I do.
Millions of people prior to us and our ancestors and generations before us
worked very hard to make it so life would be easier for the next generations.
And so that not everyone would have to always be thinking about,
you know, dire consequences all the time.
I think you've done a lot of good things.
You can, you know, that's the thing.
You don't give yourself credit for things you've already done.
The podcast is good.
People like the podcast.
I believe that once every 10 or 12 episodes,
we say something that helps one person.
Yes, exactly.
So that's pretty good.
That's a good track record.
I don't know where that was all going.
We started with motors.
We ended with saving the world.
So I think we've done a pretty good job today.
Thank you for listening.
I mean, I guess it's weird because I have this,
my hobbies are pointless,
and I also have this New Year's resolution
of doing more silly things.
Uh-huh.
So you want to save the world in an exceptionally ridiculous manner.
That has always been my goal.
I just haven't figured out the details yet.
Details are where the devil lives.
I don't think that's the phrase, but I'm going to go with that.
I'm very punchy.
What's next on the agenda? What's next on the agenda?
What's next on the agenda?
We are not making it to the Evil Mad Scientist Laboratory garage sale, much to my sadness.
Which is happening right now.
Which is happening today.
Yes.
They're having a garage sale, selling kits and parts and tools and raw materials.
And it sounds glorious as a party, let alone actually buying cool stuff.
But they are moving from their very nifty Sunnyvale warehouse to New York.
New York City?
I don't know that it's New York City,
but thank you for that.
It's Poughkeepsie.
Poughkeepsie.
That's actually even funnier.
Poughkeepsie is so hilarious.
Poughkeepsie.
It has many more letters than you would expect.
I wonder if it's actually pronounced Pugh-kipsie,
now that I think about it.
Anyway, yes, we're sorry to see them
move to the other side of the continent.
But very happy for them that EMSL has been purchased by Bantam Tools.
Bantam, and they're now the COO and CEO, or CTO and COO, respectively.
Although I didn't say who, which, so respectively applies to nothing.
Wendell is CTO.
Right, okay.
Wendell is CTO. Right, okay.
Wendell is CTO. And Lenore is COO.
Of Bantam.
So congratulations to them on their new adventures.
I look forward to new devices coming out of Bantam with their inputs.
That's true.
We're going to have to keep a much closer eye on Bantam
with them having the ability to have a little creative freedom.
Let's see other things that are going on.
Embedded online is happening.
April.
I think in April.
It's something I should know since I've already started working on a talk for it.
I've not only started working on a talk, I have an outline.
I've practiced it.
I have decided that it does not have enough fun in it.
And I have gone back to the drawing boards,
trying to figure out how to add in D&D characters or chaos theory or earthquakes,
possibly soccer teams.
I haven't decided.
Probably only one or two of these things.
But it will be about hard faults.
Putting the fun in dysfunction.
That is better than my title of causing chaos and hard faults.
Putting the fun in dysfunction.
Would it be DYS function or would it be DIS like this function?
I don't know.
That's the kernel of the idea.
You can have that for free and do what you want with it.
For those of you who don't want to go
to the online conference,
there is Embedded World in April
in Germany in Nuremberg.
And in May in Montreal in Canada,
there is the Open Hardware Summit. I mentioned
these because they have been mentioned on Slacks and Discords I'm part of, and they both
seem like really fun things that I won't be going to. Other people will be going to,
I think it will be great. Let's see. I have a book coming out, blah, blah, blah.
I need to have a praise quote for the cover.
Yeah.
And the one by Jack Yancell is super cool right now, but I'm going to get another one or maybe two others.
And it seems like it's important.
The name is more important than the quote from the very limited amount of research I did.
So you need like, you know, Oprah.
Well, I need somebody who is popular in the embedded systems field.
Oh, so not Oprah.
I don't know that she knows.
I mean, Jack Ansel.
Jimmy Carter's still around. He was a nuclear engineer. It's close enough.
I don't think you're helping. Were you intending to help?
I don't know what kind of help you were looking for.
Right. Anyway, if anybody has ideas for who you would buy a book because they said it
was a good book, let me know and I will talk to them.
Or attempt to.
Or attempt to, yes. Or just randomly talk to people. You know and I will talk to them. Or attempt to. Or attempt to, yes.
Just randomly talk to people.
That is actually...
You know you can't just call anyone.
I could try.
Yeah.
So, that is going well.
I am in the process of waiting for the images to come back.
And I requested a few images early and...
Needed more chicken.
Needed more chicken, needed to be less terrifying.
No, I agree, disagree, I think more terrifying.
I don't see how that picture could get more terrifying.
Oh, I'm planning, there's lots of ways that picture could have gotten more terrifying.
Adding blood to that picture wouldn't have made it more terrifying.
I don't think you should put blood in an embedded systems textbook.
I don't think you should put blood in an embedded systems textbook. I don't think you should put terrifying pictures in.
I do.
And there was definitely not enough chicken.
And the chicken wasn't silly enough.
Didn't you say that the picture should be slightly scary?
Slightly scary, not horrifyingly nightmare-inducing.
Oh, come on.
It was just a...
Oh, I'll show it to you again.
You had a nightmare that night, I know.
No, I didn't.
It was one of those, you know, the teddy bear skulls that, you know, that like, remember, didn't Elmira in one of the Looney Tunes have like a teddy bear skull barrettes or something?
Who am I thinking of?
I know who you're thinking of, but I don't, name's not going to come up.
Maybe it was in Animaniacs or something.
Okay.
Okay.
Your book is coming out.
My book is coming out in March.
March.
March.
Which is like a month.
Wow.
Because February is only like a week long.
I'm not sure I should have taken that contract.
Should I cut that?
No, no, no, no.
It's fine.
It's fine.
None of the clients who I have recently taken contracts with know which one it is that I am
talking about. I'm sure it will all be fine. We'd like to thank the sponsor of this show,
Nordic Semiconductor, a market leader in IoT connectivity,
providing hardware, software, tools, and services to create the IoT devices of the future.
Together with Nordic's vast ecosystem of development tools, developers can reduce
their development cycles and accelerate time to market. The NRF Connect for VS Code provides the most advanced
and user-friendly IoT embedded development experience in the industry. Nordic has a number
of academies and dev zones and tools to help you get started. If you would like to know more about
Nordic Semiconductor, it is nordicsemi.com. Please check them out. And now we are
giving away another Power Profiler Kit 2. And the question for this month and next month and the one
after, so there'll be three giveaways, is if you could make one modification to the Power Profiler app or kit, what would it be? How would you make this better?
And if you win, then, well, you can get one.
Let's see. What else do I have on my list? Praise quote for the book that's coming out.
Chris Lott asked, what sort of manufacturing and board information do folks typically
write into the info flash of their
microcontroller?
I don't know. I haven't done that in a long time.
Serial number, lot
number, possibly manufacturer
location or
some sort of manufacturer ID if you have multiple
manufacturers. A date.
That's a good one.
Year of manufacture, week of manufacturer.
Board revisions, if you can do that somehow. Board model number and board revision.
That seems like a pretty comprehensive list. Yeah, I'm trying to think of anything else that
would be super important. I mean, sometimes you put calibration data in there. Of course. Okay, let's see. We had another person who asked about Saturn air recommendations on the Embedded FM Slack channel.
What recommendations?
Soldering iron.
Yes, sorry. I heard Saturn something.
Saturn rocket recommendations. Saturn 5 was the best one. Soldering Iron recommendations.
You want to just go through their
recommendations because I don't have one.
I was really
surprised that
the ones that I used weren't
in the list at all. Somebody mentioned
tacos. I guess
so, but that wasn't... I mean, they're
nice fixed position ones um but there were ones
i hadn't heard of had you heard of i've heard of the pine soul and those little pen ones yeah
they're intriguing i don't i don't yeah i i don't know if i i don't know if they're good for like
building a whole kit or something or doing a lot of soldering or just for rework so that was a
question i didn't didn't ask in there but maybe somebody has an opinion but they're they're nice because they don't have
well i don't know some of them i think they're usb powered but they don't have batteries
right the pine cell was usb powered um but it also had a wall war right okay it could be either
uh which is nice because you want to be able to provide enough power, but...
Well, if it's USB-C, you can provide more than enough power.
But there was also a USB pen-style one as well.
It was quite a bit more expensive, but it seemed...
Who's that one from?
TS80.
Okay, TS80.
Chic and smart soldering iron powered by USB Type-C and QC 3.0 standard.
Normally we'd scoff at trying to power a soldering iron off of USB,
but thanks to the USB-C standard, it's powerful.
Blah, blah, blah.
Yeah, you can get a couple hundred watts, I think.
But this Adafruit one is temperature adjustable.
Well, that's really important.
That's one of the things I like about the Hotco.
Huh, interesting.
The PineCell one, it seemed like you could program it if you wanted to.
I think its name comes from Pine64.
I was just kind of boggled that those
were the getting started and being
kind of serious about it. There was another pen from
Tindy. Pinecell runs RISC-V.
They used Weller
RT tips. Okay.
Something cool about
the RT tips.
I don't know. I just am so
used to... I mean, the Pine Cell's only 25
bucks, too, so it's kind of like...
You know,
a big soldering station is usually
much more expensive than that.
So just having it around would be useful.
And the tip set costs as much as the soldering iron.
So I haven't decided whether or not I want to get a soldering project
just so I can get a new soldering iron.
You could just get the new soldering iron.
Backwards. Well, yes, but I need a good reason to use it. just so I could get a new soldering iron, which seems... You could just get the new soldering iron.
Backwards.
Well, yes, but I need a good reason to use it.
You could buy one for me for my birthday.
Is it time to be thinking about that already?
I don't know. It's another five months away until I'm officially super old.
Oh, my God.
Oh, my God.
Anyway, moving on.
Christopher and I are six months apart.
So as soon as he becomes super old,
I become six months later, super old.
So we can't say that sort of thing.
You do know that the best person
to complain about your age to,
the best person is your parents.
Stop it.
Because they laugh and they laugh.
One time I did it,
I think my mom laughed for like a year afterwards.
She just thought it was great that I complained about my age to my parents.
I mean, my mom did often laugh at me, so there's that.
Andy McGregor asked about giving schematics to your software team for review.
Please do.
What are review comments that you're looking forward to hear from them if you give them schematic comments?
Or as a software engineer, what comments can you usually offer?
Test points is the number one thing that I look for.
Are there any?
Is there some device that's like
i squared c or spy or something else that's going to be annoying that i would need to put a logic
analyzer on i squared c tends to be one where i have a lot of trouble with addressing or something
else and it's nice to see on a scope if i'm doing something wrong especially if it's on a device
with a terrible data sheet or with some opaque initialization procedure with tons of registers that they just
hand you and or you have it from an example project you actually like i've had to on one device
i had to use a salient to copy their so they sent a dev kit example kind of thing which was a
complete system and i booted up and configured a display. But they didn't document the initialization procedure.
So it was like 100 registers you had to write
that weren't part of the data sheet.
Nice.
This is very common with displays and cameras.
It's just like, okay, write 600 bytes.
But I couldn't get it right.
And I had example projects from other code,
but they didn't work.
And so what I ended up doing was
snarfing their dev kit with the salier and copying the bytes they used to initialize it, the undocumented ones, and putting them in my code.
And then it worked.
So test points can be important.
One of the people on the Patreon Slack had already typed their answer before I got to it, but checked our UR polarity.
Yeah, polarity is all things.
I found one of those recently, and I was so excited because Rx and Tx were swapped as they should be in all the places they should be.
But then Miso and Mosey were swapped.
And I was like, no, you don't swap those.
And then he was like, yeah, you can fix that in software.
So I'll just switch those pins and it'll all be fine.
And I was just like, wait, but I found a hardware bug.
It was so exciting.
Make sure things that you think should be connected are connected,
especially like GPIO things, stuff like that.
Like if there's a device that has, you know, it might be a Spire or a Square-to-C device, but sometimes they have GPIOs to control other stuff.
Right, that reset or command line.
Yeah, just make sure those are hooked up.
Make sure they're hooked up to, this is one I haven't really come across too often, but make sure they're hooked up to things that actually work on your micro.
I was thinking, make sure they're hooked up to lines that aren't the ones you're using for SWD.
This is what I'm saying, yeah.
Things like that, or you have I2C coming into an IOPort,
and oh, by the way, that IOPort, you can't put I2C on there.
Yes.
There's a lot of these chips, they have multifunction muxing.
So like you've got these gangs of pins
and you can set some of them to be SPI A
and I2C A or zero or one or whatever,
but some of them can't be.
And it's all, you know,
it's how they routed inside the chip,
but there's limits to that.
And so you can't just willy nilly say,
well, I'm just going to put I2C here
and here and here and here and here and here.
And no, you have to probably spread them around to ones that can support it.
So that's something I agree with you.
As software engineers, we need to do it.
But usually I ask for a netlist for that.
Yeah. Because it's a much simpler process to have it be on the netlist
than to try to trace all of the lines on the schematic.
But when you're doing a schematic review,
it makes sense to do the netlist review as well.
I wouldn't look for bypass capacitors and other nonsense
that have nothing to do with electronics.
I don't calculate the resistor network.
Yeah.
One, they're easy to change.
And two, I have no real facility with what it's supposed to do.
There's looking for things that are wrong
and there's others also looking for things that would cause you pain.
Oh, it would be really nice if the programming and debugging headers are on the edge of the board.
Well, yeah, that's true.
I mean, if they can be.
Because I've had programming headers that were between two giant capacitors and you can't get the programmer in.
Or worse, yeah, clearance issues.
Those are hard to see on a schematic, though.
Because usually, these days, when you get a schematic, it's basically a block diagram with pins, right?
Yes, but it's a good time to say, will those be on the edge of the board?
What was I going to say?
Oh, there's, like, if there's power sequencing stuff.
Yeah, that one I've got several different voltages that need to come up.
Is there an order they need to come up?
And it doesn't have to be an accusation.
No, it's just clarification.
It's just, how am I supposed to make this work?
And is it supposed to be the 3 volt comes up first and then the 1.8 or the other way?
What else is on schematics?
LEDs.
LEDs can be quite good.
And if there aren't enough of them, sometimes that can make things a challenge.
Like if you've got an LED, if you've got no LEDs.
You hate LEDs because you don't like things blinking at you.
Right.
I am...
Horrible.
My feeling is that maybe you want at least one LED
that you control from software to see that, you know,
you can control something from software,
that something's running.
Or that, you know, once you've got the firmware out there,
it turns on and quite possibly blinks to indicate that the system is working.
I'm sorry, that's how the world works.
Test points. You can do that with test points and saliates.
Yeah, but what if you don't?
No, no, you're right.
That's ridiculous.
It is nice to have a blinking light.
Sorry you don't like blinking lights, but, you know, we have five senses.
Would you rather have a clicking speaker?
No.
Okay, well, there you go.
You got a blinking light.
Okay.
I can handle the blinking light.
What else?
Do other people have good suggestions?
What things can I monitor?
So voltage, current, temperature, fan speed. Yeah, good. What things should I monitor? So voltage, current, temperature, fan speed.
Yeah, good.
What things should I monitor?
What things would be useful to have as test points so I can look at them during debugging.
Yeah.
I mean...
That's more of a question for you, the developer.
Yeah.
But they are...
It's fair to ask your hardware engineer, what signals should I be monitoring?
And then making sure that those are also available on the boards, that what you monitor inside your processor is the same as what you can monitor on a scope. Yeah. Apparently, this question came up, but Philip at Embedded Artistry actually has a whole
blog post.
So this was all not necessary.
Oh, okay.
We'll put that in the show notes.
You should just go to the blog post.
System architecture, I assumed we'd already talked about that.
Voltage domains, pull-ups and buses, pull-downs, and default states.
Default states is something you should talk about with your EE as you're doing the schematic review,
especially if you have a low-power system.
Alternate functions and pin mappings.
Do both sides of a connector have the correct pin out?
The answer to that is always no.
No, they don't.
They really don't.
Debug options, signals to test.
Is there an LED to indicate that the board is powered?
That's weird.
Somebody just said something about LEDs.
Is there a block diagram?
If not, why not?
All right.
Well, we'll put that in the show notes.
Yeah.
So I should have looked further,
and Philip's list is fantastically complete.
So we can go on.
Let's see.
There was another question about looking for a new job.
I don't recommend it.
Why not?
Jobs are for suckers.
We've been rewatching Parks and Rec.
And I realize how many of the things that Christopher and I kind of say to each other just to make each other laugh have a lot to do with that show.
It's kind of embarrassing to realize that there's a whole language we have around it.
I like to tell people no.
It lowers their enthusiasm.
Okay. Okay.
Okay.
Questions regarding a new job.
How do you do expectation management during applications?
Like the person who asked, Osau,
I've worked with different things at a small company,
which I think makes my resume look better on paper
than in reality.
I don't want them to get the impression I know everything.
I'm mediocre at best at anything.
Well, first of all, this is like the time
where somebody wrote in with a very simple question
and then we'd had a whole long episode
about imposter syndrome.
Yeah, yeah.
Well, first of all,
make sure you put things that can't be tested on your resume.
So like jujitsu expert. It's not going to come up in embedded systems very often. So this is a situation where you might be a mediocre jujitsu
practitioner, but they can't really test you on that. So that's
perfectly fine. So you should put expert because it can't be tested.
Right. Yeah. Same thing with embedded systems.
You can kind of branch out from there and be like, well, you know, I've done a lot of GPU design.
Not going to come up in embedded systems. You're fine. They can't test you on that.
What else? You know, radar transmission engineer. Depending on the job,
not going to come up. So you can put things on your resume that you don't know how to do
as long as they don't apply to the job. That's completely ethical, I've heard.
From people wearing orange?
I don't think you could go to jail for lying on your resume.
No, but...
But you can be fired or sued, so...
Right.
Okay.
So he's got things on his resume, but he doesn't feel good about them?
Is that...
So he's like, I've done this, but please don't expect me to do it well?
Is that...
So, like, you're a director at a four-person company.
Yeah.
That's a lot different than being a director at a Fortune 500 company.
I feel directly attacked.
I don't... You were a director at a bigger company than I was
a director. I was a director at a 20-person
company, so yeah. Oh, was
it only? No, there were more people. When I started
at Avenger? Yeah.
But later there were a lot more people.
Yeah, but I already quit
being a director because I hated being a director.
Anyway. Yeah.
Yes, there are definitely situational things
where something means something different
depending on the context.
But I think that's well understood.
Yeah, I agree.
That's the thing is,
you have to put yourself in the interviewer's shoes a little bit.
Like, they know what...
People who are good at interviewing, at least,
know what resumes say and mean versus your expectation of, I mean, unless you're lying, don't lie.
But if something's on your resume that you've done, that's totally fair.
Not only is it totally fair, I want to say don't hold back.
Yeah, don't hold back.
Yeah, exactly. That's where I want to say don't hold back. Yeah, don't hold back. Yeah, exactly.
That's where I'm headed.
Don't, okay, you want to put concrete things.
I have on my resume, or I did for a long time, PID servo controller made from a 50-cent DC motor.
Sure, yeah, yeah.
Because it was cool.
It made sense at LeapFrog where things needed to be cheap.
I could talk about the puppetry of it and how we
recorded the puppetry, which is something I love to talk about. I talk about the PID.
I could talk about the servo. And the encoding
feedback and all of that and how there was very little feedback and it made it really hard.
But it made it cheap. It was something I could talk about. It was very numeric and eye-catching. So could I also talk about mentoring other people and all of that, sure.
As long as I liked it.
I think what you said about I can talk about it is the important thing.
If you feel like you're putting something on your resume that you're not comfortable being kind of excited about a little bit talking about and you can go in depth and then maybe
don't put it on your resume, you know.
Or at least push it to late second page.
Example.
I used to put things like x86 assembly on my resume because, of course, I had some experience
with it.
But if somebody asked me, in retrospect, I realized, if somebody asked me an x86 assembly
question, I would be pretty screwed.
It's something that if you handed it at me in the morning, a problem that involves assembly, and I've got some books, I can
deal with it. That's the kind of experience I have. But I do feel like sometimes putting something on
your resume invites people to ask you questions about it, and you should be able to expect them
to talk about it. So if you want to put something like that that you're not fully comfortable with, I
think there are ways to do that.
Like debugging experience with assembly.
Like, you know, you can calibrate your experiences a little bit.
Yes.
Explored assembly to fix bug.
Yeah.
I mean, with more words in there, but...
Bug-fixing knowledge of assembly, you know.
I'm not going to write a program in assembly,
but if I look at, you know, 10 lines
and I have a reference manual,
I can figure out what's going on.
So your resume should have
things you want to talk about.
Yes, and you should focus on those.
Things you want to do.
Yeah.
Because if you, like, I don't have SQL on my resume, even though at one point I was nearly expert level SQL.
Me too, right?
I did a huge database project on a medical device, learned all about my SQL and how to deal with it.
And if you asked me a question about it right now, I'd say select star from, and that's all I remember. At ShotSpotter, I didn't use it
for my embedded systems, but anytime I needed to test
or check or monitor something, I needed a query.
And, you know, I needed a query from a certain place
and a certain sensor, but it never made it on my resume
because I don't really want to spend my
life doing sql queries right right yeah that's a good yeah i love that for you don't put things
on your resume that you don't want to do um so things you want unless they're impressive things
that are like i did something super cool and therefore i'm a cool smart person right but even
that you kind of have to be careful like I would put SQL in service of something else.
Yeah, that makes sense.
But be careful with that.
And make sure, I mean, SQL is kind of a skill,
not a major part of life.
So things you want them to ask you about,
the keywords for the robots,
and things you want to do in the future, but not things you don't want to do.
So if you've worked at a startup and you've gotten to do a lot of things with great titles, and you've gotten to do a lot of things in a broad scattershot sort of way, breadth instead of depth. That's okay. I mean,
we need engineers who are deep and we need engineers who have a lot of breadth.
I think-
And it's okay to travel between them.
I mean, we used to be called generalists.
Thank you.
I'm a generalist and a software engineer, and I have been since the beginning of my career,
because I've had to do a little bit of everything at various companies,
from mobile apps to twiddling GPIOs.
And that's a fine person to be,
and they're very useful and in demand.
But looking at somebody's resume
and seeing that they are a generalist
already gives you some clue
that they're probably not a depth in any one area unless they highlight that.
I mean, there's probably a few depths you have, but yeah.
But you have to highlight those.
I mean, you have a hundred words in your keyword list and then you have another keyword list
that's like deep skills.
Anyway, I think you're selling yourself short.
And I think mediocre at best is not the way to describe yourself to anyone.
Not even yourself.
I would put mediocre at worst for myself.
No worse than mediocre.
Yeah, no, I think you're right.
I think when people say things like that, I do want them to pause a little bit and make sure they're really evaluating themselves correctly.
I have met mediocre engineers.
It's immediately apparent. I had someone who I was told was a mediocre engineer join my team.
And I took a look at what they were doing, and I talked to them a bit about what they
liked to do.
And I switched them to a different project.
Yeah.
And they became like a secret weapon.
Yeah, yeah.
They were great at the other project.
Other teams loved that project.
My team wasn't really sure about the value of it,
but the other teams got so much value out of it.
And they were so much happier because they felt like they were contributing.
So I'm not even going to say mediocre.
I've met people who aren't in the right job.
And I've met people who don't care.
That's fair.
People who don't care, those are harder.
But usually we're in this for the puzzles.
We like the puzzles.
Okay.
So the other question from Osau was, what do you use to compare jobs to make an objective comparison as you're looking to accept an offer?
Like how interesting do you need to find the company's product or technology or how important is the maturity of the organization or the difficulty level of the role?
What do you look for to compare potential positions?
Wow.
It's all about the money, right?
Show me the money.
I mean, that's a big part of it. But it's really tough because just as it's difficult to interview a candidate
because you only got effectively a few minutes
to meet someone, assess their skill level,
assess their ability to work on your team
or on a team and all of that stuff.
It's actually more asymmetrical, right?
Because when you're interviewing,
they're mostly asking questions of you.
And you get some time to ask questions of them, but it's really hard to get a sense for things.
But even that is an interview question.
Companies have a, you know, you talk about putting things on your resume that you're uncomfortable with.
Companies are lying to you, too.
They have put on their best shirt and shined their shoes.
All of them are pretending to get along. They have put on their best shirt and shined their shoes.
All of them are pretending to get along.
There's no interpersonal issues happening.
Oh, the project is going well.
There's that and the other thing.
And the instant you show up there, it's a different place.
And you start learning about what's really going on. I remember interviewing at a company and they said that they really don't want people who carried grudges.
What?
And that was like such a big red flag. I was like, who on your team is such a jerk
that you're basically filtering people out that can't work with them because they are such a jerk?
Please don't. Please tell us you're not someone who gets mad at things.
Yes, exactly.
Yeah. So, but that's where I'm headed with that is like, a lot of the stuff
you want to evaluate is unknowable without, you know, joining the company or sneaking around the
company for a week, going to some meetings and seeing people, you know, that's the thing. It's
always been eye-opening to me. It's like, oh, we're happy fun. And then you go to a meeting
after two weeks of being there and people are yelling at each other and it's like uh-oh is that how you have fun or or the one
company i went to where everything was fine for a month until the person who apparently was the ceo
decided to show up and then the company changed right that right this is no longer a fun place
this is a uh a very stressful place because they wanted something different than I thought was happening. There was no way to know. So yeah, try to get some sense of that through interviewing. you're talking to, especially other engineers. Because the management people are going to, if they want you and they want to impress you with the company,
they're going to make everything sound like puppies and roses.
And remember, after you have an offer,
you can ask to talk to one of the people you interviewed with.
Yes.
Maybe have lunch with the person you're going to work with most,
or your new boss.
But of the thing, there's like the interest level,
that's something you can, you know, the application interest.
Application has always done it for me.
But this is so different for everybody.
Yeah.
I mean, there are the necessary things.
The things that you don't even look at a job if it's not going to cover.
Right.
Like money, location, maybe PTO is one of those things that's on your list.
Intensity.
If you're somebody who's not interested in working 70-hour weeks, that's something you need to gauge.
That's hard to find.
Something you need to gauge.
It is something you need to gauge.
And luckily, you know, at some places that they were really upfront with that, like Apple, who told me I would never see my family again.
So that was cool that they, you know, were clear about that.
Yes.
Then you could cut the interview.
Actually,
the question,
actually,
the question is the summer.
The question was,
do you like summer?
And I was like,
yeah,
I love summer.
Summer's great.
And the answer is,
well, you'll never see it again.
Yeah.
I was like,
why would you tell me that?
He wanted to measure your commitment up front.
Commitment to iPod.
Do you have a passion for iPod?
I did not. Sorry.
Yes, next.
One person
pointed out that
mentorship is something
that you can kind of try to figure
out during an interview.
Is there someone
who will be willing to teach you
and that you can ask questions of
and see what the arrangements are for learning?
Even better if the company volunteers that,
says you will have a mentor.
This is, you know, I will be guiding you.
But it's a good question, yeah.
Yeah.
Bigger companies tend to be much better at that.
Like Cisco was like, here is your mentor.
Have a nice year.
Well, we were new college grads.
That's true.
There was a process for that.
I mean, junior people need mentors more than senior people.
Although senior people still need them.
There's really no good answer.
You can ask about what processor they're using,
if that's important to you.
I mean, you can ask quality of life things,
like which computer environment do you guys use to program on,
what compilers are you using?
You can get a sense for the organization,
like, okay, what's your source control scheme?
What's your software development process?
Are you doing Agile?
Are you doing something with Scrum?
Are you doing Scrum and Agile?
Do you have professional Scrum masters?
Do you have daily stand-up meetings
that last in excess of 30 minutes.
What is the meeting load here for
a working engineer?
Stuff like that is easy to get
answers that they probably won't tell you
lies because it's hard to come up with a lie that fast
about stuff like that.
Most of the lies tend to be along the lines
of the
culture is great, the team is great,
everybody loves working here, that kind of stuff.
Rah, rah.
If you work here, you'll be a millionaire by Tuesday.
So there's a site, adafruit-playground.com.
It seems to be kind of like hackaday.io
in that it's projects.
Oh, posting projects?
Yeah. Okay. Or hackster.io in that it's projects. Oh, posting projects? Yeah.
Okay.
Or Hackster.io where you're posting tutorials and projects and maybe continuing on later.
The comments on the projects are nice and it's all pretty positive and supportive.
Seems to have been around since about November.
Oh, okay.
So it's kind of new.
Huh. It's all pretty positive and supportive. Seems to have been around since about November. Oh, okay. So it's kind of new.
Huh.
We've had at least one person on the Slack post there and was happy.
I just wanted to bring it up because I hadn't seen it and it seemed neat.
Oh, cool.
I'll check it out.
Let's see.
We have a Patreon Slack group, as mentioned a couple of times. If you want to see that,
you have to give us a buck on Patreon or Ko-fi,
coffee,
and then you get access to these people who are really cool,
much cooler than us.
Yeah, if only we could convince them to record the show,
we could just sit back.
I'm easing into that.
Don't give away my plans that quickly.
We also have a newsletter
which was
totally on time, just like this show
is on time. Totally on time.
And under budget.
Last week it was about
music stuff.
Various posts like...
Because of your project.
Your class. Because of my class.
I coughed up some of the links that I found interesting as I critiqued student projects.
I just kept opening tabs of things that I would look at later and finally wrote them up.
A lot of them were music related because we had a number of good music projects this time.
And that's it.
Thank you for listening.
Thank you to Christopher for producing and co-hosting.
Thank you to our Patreon Slack group for all that they do.
And of course, thank you for Nordic for their sponsorship.
We really appreciate it.
All of you.
And now Winnie the Pooh.
At this point, it is Eeyore's birthday.
Pooh went to go get him a jar of honey
and then got hungry and ate the honey.
Bother, said Pooh.
What shall I do?
I must give him something.
For a little while, he couldn't think of anything.
Then he thought, well, it's a very nice pot, even if there's no honey in it.
And if I watched it clean and got somebody to write a happy birthday on it,
Eeyore could keep things in it, which might be useful.
So as he was just passing the hundred acre wood,
he went inside to call on Owl, who lived there.
Good morning, Owl, he said. morning poo said owl many happy returns of eeyore's birthday said poo oh is that what it is what are you giving him owl what are you giving him poo I'm giving him a useful pot to keep things in.
And I wanted to ask you.
Is this it? said Owl, taking it out of Pooh's pot.
Yes, and I wanted to ask you.
Somebody's been keeping honey in it, said Owl.
You can keep anything in it, said Pooh earnestly.
It's very useful like that, and I wanted to ask you.
You ought to write happy birthday on it. That was what I wanted to ask you, said Pooh, because my spelling is wobbly.
It's good spelling, but it wobbles, and the letters get in wrong places. Would you write
a happy birthday on it for me? It's a nice pot, said Owl, looking at it all around.
Couldn't I give it to you from both of us?
No, said Pooh.
That would not be a good plan.
Now, I'll just wash it first and then you can write on it.
Well, he washed the pot out and dried it,
and while Owl licked the end of his pencil and wondered how to spell birthday...
Can you read, Pooh? he asked a little anxiously.
There's a notice about knocking and ringing outside my door, which Christopher Robin wrote. Can you read it?
Christopher Robin told me what it said, and then I could.
Well, I'll tell you what this says, and then you'll be able to.
So Owl wrote, and this is what he wrote.
Hippy peppy birthday.
Pooh looked on admiringly.
I'm just saying happy birthday, said Owl carelessly.
It's a nice long one, said Pooh, very much impressed by it.
Well, actually, of course, I'm saying a very happy birthday with love from Pooh.
Naturally, it takes a good deal of pencil to say a long thing like that.
Oh, I get it, said Pooh.