416: EEs Are From PIC, SWEs Are From Arm
Transcript from 416: EEs Are From PIC, SWEs Are From Arm with John Catsoulis, Elecia White, and Christopher White.
EW (00:06):
Welcome to Embedded. I'm Elecia White, alongside Christopher White. Our guest this week is John Catsoulis, author of O'Reilly's "Designing Embedded Hardware." But that first came out 20 years ago, so we're going to find out what he's been up to since then.
CW (00:22):
Hey, John.
JC (00:24):
Hi, Elecia and Chris. Nice to be on board.
EW (00:28):
Could you tell us about yourself as if we met at an electronics conference in Brisbane?
JC (00:36):
Okay. Well, okay. I'm an engineer with a physics background. I did an undergraduate degree in, I started out doing quantum physics and sort of slid sideways into electronics from there. I've been working for a number of years, over 30 years experiencing software and hardware design.
JC (00:57):
I spent 16 years in engineering management, and I've worked on things from mining imaging radars, industrial automation, mechatronic systems, avionics, energy metering, remote sensing, data logging, a wide variety of things.
JC (01:12):
And these days I have my own little company called Udamonic, and I produce small embedded controllers that run Forth.
CW (01:20):
Wait a second there. You said mining imaging radar?
JC (01:23):
Yeah.
CW (01:23):
Wow.
JC (01:23):
So there's a company in Brisbane called GroundProbe that does slope stability radars. So basically for the big open-cut mines, they monitor the mine walls to predict collapses, and they can predict a collapse up to 24 hours before the mine gives way.
CW (01:39):
Wow.
JC (01:39):
So they're going to take sub-millimeter movement up to five kilometers away. It's about two and a half miles, three miles.
CW (01:46):
I just always like those mysterious imaging things that -
JC (01:48):
Yeah.
CW (01:49):
- can do high precision stuff at great distances ... Anyway.
JC (01:54):
Yeah.
EW (01:57):
Are you ready for lightning round?
CW (01:58):
I've derailed us already.
JC (02:00):
Yeah, that's fine.
CW (02:02):
Define Udamonic.
JC (02:04):
Udamonic is just my small business, which is a venue for me to produce hardware that I find interesting and useful. I hope what I make is useful for people. That's my primary goal, make stuff that's easy to use.
EW (02:17):
Define the word Udamonic.
JC (02:19):
Define the word Udamonic. It comes from the ancient Greek word eudaimonia, which is a satisfaction you get from doing something well.
CW (02:27):
I feel like there was a book with that in the title.
EW (02:30):
"Eudaemonic Pie."
CW (02:31):
Oh, okay. I forgot what it was about.
EW (02:34):
Gambling.
CW (02:35):
Okay.
EW (02:35):
Using math to gamble.
JC (02:38):
Okay. Slightly different idea, but yeah.
CW (02:40):
Yeah.
JC (02:40):
Yeah. So the ancient Greek idea was that it's not a short-term thing. It's from doing something over a very long period of time, purely for the pleasure of doing it well, not to make money, or fame, or anything else, just doing something well. That's eudaimonia.
CW (02:57):
I like it.
EW (02:57):
I like it.
JC (02:58):
Yeah. So that's what my goal was with starting Udamonic, just to do things that interested me and gave me pleasure from doing it.
EW (03:07):
Okay. I'm enjoying this, but you are failing lightning round.
CW (03:10):
We are failing lightning round.
JC (03:11):
I'm sorry.
EW (03:12):
We are failing. So PIC32 or Cortex-M?
JC (03:18):
Probably Cortex-M, because I like Arms. But PIC32s are based on MIPS, and I've always been a fan of MIPS too, so yeah. But probably Cortex-M.
CW (03:26):
Beach or rainforest?
JC (03:27):
We've got both here, so do I have to pick? But probably beach if I have to pick one.
EW (03:32):
Cats or dogs?
JC (03:34):
We've got both. So either on. I think I'm failing this lightning round.
CW (03:40):
Postfix or infix?
JC (03:43):
Probably postfix.
EW (03:46):
Hardware or software?
JC (03:49):
Hardware.
CW (03:51):
Do you like to complete one project or start a dozen?
JC (03:54):
I tend to fall in between, so start six projects and then complete them before I start anything new. So I will finish a project before starting a new one.
EW (04:03):
Do you have a tip everyone should know?
JC (04:06):
Not really. No.
CW (04:08):
Alright. A bonus question then. Favorite fictional robot?
JC (04:11):
Probably R2-D2.
CW (04:13):
Okay. He's alright.
JC (04:15):
Yeah.
EW (04:17):
So your company Udamonic makes Scamp.
JC (04:22):
Yes.
EW (04:22):
Why that name first?
JC (04:26):
Yeah. Good question. Because when I was developing the prototypes, I was using various codes for the various iterations. And when I was getting ready to release it, I knew I had to have a name for it.
JC (04:38):
And I'd just been watching a YouTube channel called CuriousMarc, who does lots of interesting retrocomputing stuff. And he was talking about a very early microcontroller system called the SC/MP, otherwise known as the Scamp.
JC (04:52):
And when I was trying to think of a name for this thing, it just popped into my head. I needed to pick a name, because I was about to push go on the PCB run. So that's what it was. And people seemed to like it, so it stuck.
EW (05:06):
And it's programmed in Forth.
JC (05:07):
It is programmed in Forth.
CW (05:08):
Wait a minute. What is it?
EW (05:10):
Oh. Oh, sorry. Yes. Could you tell us about Scamp?
JC (05:15):
Okay. Think of it, it's like an Arduino, but rather than Arduino's programmed in something which is basically Java-like, the Scamp is programmed in Forth. And Forth is quite a different programming language. It's very efficient. It's very much on the metal. It's very fast.
JC (05:33):
And it's fantastic for debugging. You can interactively talk to hardware. From the command line, you can poke bits in registers and read back registers. And you can basically test your application before you've even written the line of code simply by interacting directly with the hardware. So it's fantastic for that sort of thing.
EW (05:53):
And it's an interpreted language, at least the part you're talking about is interpreted.
JC (05:59):
Yes and no. It's sort of like an interpreted language, but when you type a line of code, even at an interpreted level, it actually compiles to machine code before it runs.
CW (06:09):
Yeah, it's weird.
JC (06:10):
So it compiles on a line-by-line basis. And when you, for example, type the plus operator that compiles down to a single edition instruction for the processor and it executes as a single edition instruction, there's no overhead it's really efficient.
JC (06:26):
Some of the Forth applications that you can write for Scamp, they're literally compiled down to tens or hundreds of bytes of code once they're compiled. It's a very small footprint, and you get very fast execution. I did a little program which exists out there called Fizz Buzz. It's a simple programming quiz.
JC (06:48):
And I've seen versions of Fizz Buzz running on PCs under Python, and Fizz Buzz running on the Forth was over 300 or 400 times faster than a PC running Python, which is not bad for a little microcontrollable.
CW (07:04):
Yeah.
EW (07:05):
Yeah. Big processor running Python or a little controller running Forth.
JC (07:09):
Yeah.
EW (07:10):
Forth is known for its postfix operations, which is mind-melting for some of us.
CW (07:16):
RPN.
JC (07:16):
It is. Yes, it is. It is. Yeah. It's the sort of thing that people either love it or they hate it.
CW (07:21):
Love it.
JC (07:22):
Yeah, if you've come from an assembly language programming background, Forth is the type of language that makes an awful lot of sense.
JC (07:31):
If you think of when you're writing assembly language, you have all these little subroutines, and typically you pass parameters to the subroutines on the stack. And subroutines will return values on the stack to whatever called them. And Forth is just a wrapper around that.
JC (07:48):
It basically just lets you call assembly language subroutines, and manually pass the parameters, and read the parameters back. And you can interactively run any subroutine at any time and test it, everything individually. It's a bottom-up programming language rather than top-down programming language.
JC (08:05):
So you start with the simple stuff at a low-level, build the lower level stuff, and gradually add layers to it. And by the time you finish developing your application, everything is completely tested and debugged. It's a very lean, very efficient way of doing things.
JC (08:21):
And the way you work with Forth, it's postfix nature, or Reverse Polish notation is the other way of referring to it, it makes you think very hard and very carefully about how you need to solve the problem. Because with something like Java or C, you can sit down, you can fudge something together, and it will work.
JC (08:39):
And it might not be the best approach to writing software, but you can make something work fairly easily, whereas Forth really makes you think about what you're actually trying to do, how you're trying to solve the problem.
JC (08:49):
And you end up with much more efficient code, much leaner code, and far less bugs. Simply by the way Forth, forces you to approach the problem.
CW (09:02):
... I loved RPN, and I switched to thinking that way in college and grad school. And so when I was doing exams and homework assignments, I found it very efficient to work that way. No parentheses, organize your thoughts differently.
JC (09:16):
Yeah.
CW (09:16):
And of course, now I can't use a regular calculator. That confuses me. But one of the difficult things is if you try to hand somebody, "Here's how I did this," ... it's not easy to read.
JC (09:30):
No, that's right. Yeah. But the difference with Forth is, it's not a single line of code. Well, you can do it in a single line of code, but you can write it as you would a normal piece of software. So you can have multiple lines, and space it all out, and it all makes sense. And it flows very logically,
EW (09:48):
But I have heard Forth referred to as a write-only language?
CW (09:53):
I thought that was Perl.
EW (09:54):
Well, yes. Exactly.
JC (09:56):
Well, probably just barely. But, yeah.
EW (09:58):
And PIC assembly.
JC (10:00):
Yeah. It can be a bit like that. What's the best way to describe it? It has a long history going back to the late '60s, early '70s. It was ... originally created by a fellow called Charles Moore for controlling telescopes.
JC (10:19):
And it's a language that was created for embedded systems. As far as I know, it's the only language that, its origins are completely embedded. It wasn't intended or doesn't have a history associated with larger systems, desktop-type systems.
EW (10:39):
Why is it that hardware engineers like Forth? I don't know very many software engineers who are like, "Yes, let's do Forth!" But I know quite a few hardware engineers. Is it because it's more like assembly, it's more like the processor itself?
JC (10:55):
It's tied very closely to the processor architecture. So for a typical software engineer from a sort of computer science-y background to use an old term, it's very alien to them. Because they're used to environments that are quite abstracted from the hardware whereas with Forth, you'll write on the hardware.
JC (11:17):
You are interacting with the hardware directly. It works the same way the processor works. So if you've come from a microprocessor background, if you're used to that sort of environment, it just clicks. It makes so much sense.
JC (11:33):
And you can do things very quickly and very fast. To give you an example, my nephew's into model railroads. So I was going to make a controller for him. And before I did the Scamp, I was using an Arduino. And I spent a good part of a morning writing the software for a controller for his model railroad.
JC (11:53):
And most of the time the actual algorithm itself was quite straightforward, but I spent an awful lot of time messing around with the IDE and various things. Later when I sat down to write up the Scamp, I timed myself, and writing the application actually took less than one minute.
JC (12:11):
It was just that fast and that quick. All the hardware, the software to handle the hardware, was there. And it all just came together within one minute, and that's not hyperbole. It really was less than one minute. And the whole finished application was just tens of bytes long. So that's the sort of difference it makes.
JC (12:32):
There is a learning curve for Forth. If you've never seen it before, it takes a few weeks where you're just scratching your head and finding it very hard to get your head around it. But once it actually clicks, it just makes so much sense, you wonder why anyone uses anything else.
EW (12:49):
I've used it for board bring-up primarily -
JC (12:52):
Okay, yeah.
EW (12:52):
- and then switched over to C to do the larger algorithms.
JC (12:58):
Yep. That's a very common approach. Yeah. Yeah.
EW (13:01):
These days with the larger Cortex-Ms, I see a lot of people putting CircuitPython on them.
JC (13:08):
Yeah.
EW (13:09):
Have you tried that out?
JC (13:11):
No, I haven't. I've done Python programming, but I've never tried CircuitPython. Because to me, there's so much overhead associated with Python that it doesn't belong in an embedded environment to me.
JC (13:23):
It's like something with training wheels that makes life very easy and soft for you. But I can't see how you would get particularly efficient code at the end of the day with it. And if you're trying to do real-time applications, I don't really see how it fits.
CW (13:38):
Well, I think the thing is a lot of times now, especially with the more recent microcontrollers, having something super efficient is not actually required. And it works perfectly fine.
JC (13:51):
That's true. That's true.
EW (13:51):
Especially for board bring-up.
CW (13:54):
Yeah.
JC (13:54):
Yeah, yeah.
EW (13:56):
And Circuit Python has the advantage that it usually has a USB interface, and you just type the file on the microcontroller, and then it runs, -
JC (14:07):
Yeah.
EW (14:07):
- as opposed to all the IDE. How do I get my program into Forth? Do I have to cut and paste it at the command line?
JC (14:16):
You can do that. Yes. Basically, yeah. Yeah. Yeah. But it's not as complicated or as hard as you might think. In terms of board bring-up, it's actually a very lean, very short process to actually get things up and running.
JC (14:33):
And I actually use Scamps to bring up other systems. So I will use the Scamp to debug other hardware in a target microprocessor system.
EW (14:42):
Sure. To try and figure out what -
JC (14:43):
Yeah.
EW (14:43):
- the I2C address is -
JC (14:44):
Yeah, that's right.
EW (14:44):
or why SPI isn't working. It's probably a great tool.
JC (14:49):
Yeah, that's right.
CW (14:50):
I haven't used Forth since I was larval. Back in the early '80s, I guess, -
JC (14:58):
Yeah.
CW (14:58):
- when it was kind of on early PCS, and Apple, and Timex Sinclairs. You had BASIC, you had assembly, and a lot of times you had Forth. And so I played with it some, but I don't really remember it that much.
CW (15:12):
So now thinking about it now, one of the things with microcontrollers is, at least with more modern ones, not necessarily PICs, is there's just a lot of peripherals and things that require a lot of configuration.
CW (15:24):
So with the Scamp, have you provided like, "Okay, there's a hardware abstraction layer that Forth calls," or do you have to twiddle all the bits in Forth?
JC (15:34):
You can twiddle all the bits, but the Scamps run a type of Forth called FlashForth.
CW (15:41):
Oh, okay.
JC (15:41):
And FlashForth out of the box, doesn't actually provide any hardware support at all. But there's a layer of additional software programs in Forth that are called words. So there are words to do analog and digital I/O, PWM, serial, I2C, SPI, all of the standard stuff is there.
JC (16:03):
And it's very easy to use. If I want to configure a pin to be an input, so I've attached a switch to pin 2, I simply type "2 switch," and that's it. And it's configured. And if I want to read that switch, I type "2 get," and it's done. So in two lines of code, I've configured the I/O, and I'm using it.
EW (16:29):
But that does require Forth to know how to make something into a switch, which, -
JC (16:34):
It does. Yeah.
EW (16:35):
- in C, you have the hardware abstraction layer. And if you're talking about STM32, there's 4,000 lines of code in order to set a GPIO to be -
CW (16:44):
Several fathoms down.
EW (16:46):
Yes.
JC (16:46):
Yeah, yeah. And why does it need to be that complicated for what that does?
EW (16:51):
Well, it does.
CW (16:52):
Well, I'll tell you.
EW (16:53):
Well, I'll tell you.
CW (16:54):
Go ahead, Elecia.
EW (16:56):
Because they are supporting so many different processors, and they're all the little corner cases. If they had one HAL per processor, it would make our lives so much easier. But it would make their lives so much harder.
CW (17:13):
Which it should be. Their life should be hard as far as I'm concerned.
JC (17:18):
Yeah. One of the guiding principles of Forth when it was created was that each version of Forth for each machine should be tailored specifically for that machine. So you don't have one standard Forth, you have a thousand different Forths for a thousand different machines to get the most out of each machine.
EW (17:35):
Yeah. And that's a very embedded systems concept -
JC (17:38):
Yeah.
EW (17:39):
- of not allowing the extras to weigh you down.
JC (17:44):
Yeah. And Forth was very common and very popular in the '80s. And then it fell out of favor. And part of the driving force behind that, I think, is because, I'm generally in favor of standards, and I think the ANSI standards are great, but ANSI Forth is awful.
JC (18:02):
And when they did ANSI Forth in the '90s, they tried to make one very large, bloated generic Forth that did everything for everybody. And they just made it hard to use and confusing. And I think that's what killed Forth for a lot of people.
JC (18:15):
Forth is now starting to have a comeback, because people are discovering the lean versions of Forth that are tailored for specific hardware. And that makes life interesting and fun. But people trying to use ANSI Forth, I find it horrible. I don't use ANSI Forth at all.
JC (18:33):
And a lot of people will try using ANSI Forth on something like a PC or a Mac. An,d within 20 seconds, they've decided they don't like Forth and they won't ever touch it again.
EW (18:43):
Please move your thumb away from the hammer and stop hitting it.
JC (18:47):
That's exactly right.
CW (18:49):
Yeah. I had a bad analogy, but I don't understand why somebody would do that.
EW (18:53):
Well, I mean, because you say, "I want to learn Forth."
CW (18:55):
Yeah. Okay. Sure. Yeah.
EW (18:55):
And so you do it that way, but that isn't what it's for.
JC (19:00):
Yeah. Yeah. So I don't care whether it's my hardware or not, but get an embedded system, put whatever version of Forth you want onto it, and try Forth in that environment. And it's a fun experience.
CW (19:13):
It does sound like there's an application space for it -
JC (19:17):
Yeah.
CW (19:18):
- that other things occupy, but don't do a great job at in terms of small, dedicated, the original embedded concept, the small dedicated piece of hardware -
JC (19:28):
Yes.
CW (19:28):
- with small firmware. I'm not sure you'd want to write a smartwatch in Forth.
JC (19:35):
Well, Charles Moore, who created Forth, he did a VLSI CAD program in Forth. And the whole application was less than 64 kilobytes.
CW (19:47):
Yeah. But that's when you only had 64 kilobytes.
EW (19:49):
Yeah.
JC (19:50):
That's true. But why do you need more than 64 kilobytes, to paraphrase Bill Gates, which I never thought I would do, but, anyway. With the Scamp, it's only got 8K of RAM and 5K of that is free for users. And that sounds like an incredibly tiny amount of space, but I have never reached the limit of the available memory.
JC (20:12):
And I don't know of anyone else that has either. I mean, obviously you can't do audio processing, or video processing, or something in that space, but for simple control applications, motor control stuff, in Forth, that's more than enough memory.
JC (20:24):
You'll typically only use a few hundred bytes for your application and a few tens of bytes for your data. And it's more than enough memory because Forth is so lean. There's very little overhead associated with it.
EW (20:40):
I had to change memory today to go from a couple hundred bytes to a megabyte. And so, yes, I knew I was being extravagant, but I was tired of messing with it.
JC (20:57):
Yeah. Yeah.
EW (21:01):
I have heard that Forth is very resistant to reverse engineering. This kind of goes back to the write-only language. But because it is interpreted and compiled, but not like C is compiled, the code ends up looking very odd. It doesn't look -
CW (21:27):
What, the machine code?
EW (21:28):
The machine code is very hard to reverse engineer. Have you heard anything about that, John?
JC (21:33):
Yeah, I would agree with that. You can reverse engineer it. You can pull it apart. You need to understand what Forth is doing when it actually compiles, because you have what's known as the dictionary, which is the collection of Forth words. And as I said before, they're just assembly language subroutines.
JC (21:53):
So when you compile a Forth program, they're just calls to assembly language subroutines. So what you are doing when you're compiling something is just putting a whole lot of calls, it's basically thread-to-subroutine calls. So when you decompile it, you get a list of all the subroutine calls that are being called in order.
JC (22:13):
And you can take that, and you can reverse engineer it, and so forth. But it's not particularly readable because you're effectively looking like at disassembly. Even though it's Forth, it's still effectively disassembly of an assembly language thing, if that makes sense.
EW (22:33):
What is the processor you have on the Scamp?
JC (22:36):
It's a PIC24. I was originally going to use an Arm on it, and I was looking around. I was going to write my own version of Forth for an Arm. And then I came across FlashForth, which was written by Mikael Nordman in Finland. Mikael's a very bright guy, and FlashForth did everything that I wanted it to do.
JC (22:58):
It's a really beautifully written little language. It's got some very nice features. And that was for the PICs and for the AVRs. And the highest performance PIC that it supported was the PIC24, which I hadn't actually used before. So I thought I would explore that space, and I've actually quite liked PIC24 now.
JC (23:18):
It's a really capable, very fast, 60 MIP processor. It's got a very nice instruction set, good address space, good addressing modes. It's a really nice little processor, and you can get quite a bit of horsepower out it when it's programmed very efficiently,
EW (23:37):
I was a little confused, because there are PIC16s, and there are PIC32s. And it was bogglesome to think that this might be a 24-bit processor. So I'm glad to hear you say it's a 16.
JC (23:48):
It's a 24-bit address space, which is where the name comes from.
EW (23:53):
Okay.
CW (23:53):
Oh, yeah.
JC (23:54):
It's confusing for me too. It's actually a 16-bit processor.
CW (23:58):
Yeah. There were a bunch of 24-bit addressed processors back in the in-between era.
JC (24:03):
Yeah.
CW (24:03):
They were 16-bit, but they had 24-bit addressing.
JC (24:06):
Yeah.
CW (24:06):
Well, it's good that you chose a PIC probably, because you probably if you'd chosen an Arm, you wouldn't be able to obtain any now.
JC (24:13):
So I can't get any parts at all at the moment.
CW (24:15):
Oh, you can't get PICs either.
JC (24:15):
So I've just finished designing a motor controller little board which I designed on a Texas Instruments part.
CW (24:25):
Oh.
JC (24:26):
And I had the parts on back order, and they were supposed to be shipping in June. And I've just been advised they won't be available until September of 2023.
CW (24:34):
In, say, which June?
JC (24:36):
That's right. Yeah. So yeah, getting parts at the moment is a challenge. So I do have a lot of Scamp3s in stock, but making new ones at the moment is going to be hard.
EW (24:48):
I have been hearing 70-to-90-week lead times.
CW (24:53):
I thought you were going to say years.
EW (24:54):
It feels like it. I don't have that kind of patience.
CW (24:59):
Yeah.
JC (24:59):
I've got a friend who works at Microchip. And Microchip apparently is selling lots of development boards at the moment simply so people can pull the parts off them and reuse them on something else.
EW (25:09):
I mean, that's going have some reliability issues.
CW (25:12):
There's some limits to that.
JC (25:13):
Yeah. Yeah.
CW (25:15):
So you've been through several versions of this board.
JC (25:18):
Yeah. Yeah. So this is the Scamp3. So there have not been major differences between them, just minor tweaks and additions. So the Scamp3 is the latest one.
EW (25:34):
It sounds like you use this, and you like it for your own work. I know you're an engineer. How do you go about selling Scamp?
JC (25:45):
I don't spend a lot of time advertising it or trying to market it. There's a small user group, and people hear about it, and then word-of-mouth sales. So the volumes are not huge, but that's okay. I don't want something that's going to grow particularly fast that I can't manage.
JC (26:04):
It's just a nice little board that I'm happy to sell to whoever wants it. Most of the customers are in the U.S., and Canada, and the EU actually, which I find interesting.
EW (26:16):
Yeah. International shipping is not cheap.
CW (26:19):
Or fun.
JC (26:20):
No, no. It's not cheap. That's part of the problem, yeah. If I could find a way of shipping them more cheaply, it would be great. But yeah, at the moment that's one of the main stumbling blocks.
EW (26:31):
You ship them to Adafruit, and then Adafruit ships them. Not that I'm volunteering them just, it is possible to get -
JC (26:40):
I did talk to Digi-Key about it, but I couldn't get any sensible answers out of them, and that sort of fell through. So, I might follow up with Adafruit. That's not a bad suggestion, actually.
EW (26:53):
I spoke to an engineer recently who strongly believed that people are either software engineers or hardware engineers. You'd always be able to tell.
JC (27:03):
Oh, absolutely agree.
EW (27:05):
Okay. And so you'll always be able to tell which one they come from, and how they're kind of failing to do the other discipline for the folks who are -
JC (27:15):
Yes.
CW (27:16):
Yes. Yeah. EEs are from PIC, and software engineers are from Arm. There's a book, right?
JC (27:23):
I have a friend, and sometimes when we sit down, we'll see somebody walking past them, say, "Yeah, that's a software engineer. That guy's a hardware engineer." You can pick them by the way they walk and they dress, I think.
JC (27:37):
Yes, definitely, there are differences. There's differences in philosophy and differences in approach. And if I'm hiring someone to do software, I'll hire a hardware engineer who can do software rather than a software engineer.
EW (27:50):
Why?
JC (27:52):
I just find they have a different approach to the problem.
EW (27:55):
Isn't that good?
CW (27:57):
No, I think he's saying the hardware engineer has a different approach to the problem.
JC (28:00):
Yeah. I think the hardware engineers have a better understanding of what the software is really doing when it's running on their hardware.
JC (28:09):
So they write their code in a slightly different way and they get better performance out of the hardware. I'm talking in the embedded space, obviously, not in general software terms.
CW (28:20):
I would say that's true for the deeply embedded space.
JC (28:23):
Yeah.
EW (28:23):
I would say that's true for the Forth and assembly speakers.
CW (28:28):
Yeah. Well, I think once you get to the STM32 -
JC (28:31):
I'm talking about C programmers and the niche programmers. Every time I've hired an embedded Linux programmer, I've always picked someone with a hardware background, and they have been absolutely brilliant.
EW (28:42):
You're talking to software engineers.
CW (28:44):
It's fine.
EW (28:45):
Just wanted to let you know that.
JC (28:46):
I think I'm talking to hardware engineers who can do software.
CW (28:49):
Definitely not.
EW (28:51):
No.
JC (28:52):
Okay.
EW (28:52):
And I do think it's different. I mean, I have an O'Reilly book too, and I really have thought about how many of my EE friends who write software, they don't understand reusability.
CW (29:09):
There's a crossover point. There's a weird crossover point, and I think it's application-based. And I think it's complexity-based. And I think there are hardware engineers who will do better than software engineers in that zone.
CW (29:24):
But once you get beyond that into other things, there's stuff software engineers do that is better. So for lack of a better word -
EW (29:35):
Decreases the complexity by understanding the generalities.
JC (29:39):
Yeah. When I say a hardware engineer, I'm talking about specifically someone from the microprocessor space, rather than a generic person.
CW (29:49):
Yeah. Yeah. Yeah.
JC (29:50):
Yeah.
CW (29:50):
Yeah. Yeah. But I also think ... if you're talking about a Linux person, there aren't many people who understand what a desktop-class microprocessor is doing anymore.
JC (30:05):
Yeah. Okay.
CW (30:05):
And I don't think you're going to write software with that knowledge that helps you.
JC (30:10):
Yeah. Okay.
CW (30:10):
Whereas with a microcontroller, certainly. Yes. Knowing what those are doing at a lower level will help you. So yeah, I think there's a crossover point. I think people get wrapped up in one or the other, but yes, there's areas where each excels in different ways.
EW (30:27):
Yeah. I mean, my students, the software folks, are pretty hesitant about datasheets.
CW (30:35):
Oh, God. Well, I can understand that.
JC (30:39):
They build character.
EW (30:41):
Yeah, exactly. They build character. And the EEs are like, "Well, okay, I'm still trying to set up the compiler." And the software people have finished their projects. They're -
JC (30:52):
Yeah. There's a lot of truth to that.
EW (30:55):
- tortured by the tools.
JC (30:56):
Yes.
CW (30:56):
Well, and I think the problem is today, we're being asked to do things that are desktop-like things, right?
EW (31:01):
Oh, my goodness.
CW (31:02):
As soon as you put networking in Bluetooth and multicores -
EW (31:05):
And a display with colors.
JC (31:07):
Yeah.
CW (31:08):
And now you're talking about, it's a computer.
JC (31:10):
Yeah.
CW (31:10):
And certain things, you can't do it without certain kinds of techniques. And I think that's where things get a little tricky. But there's certainly parts of those systems that a smart hardware engineer would do better, I think.
JC (31:24):
Yeah.
CW (31:25):
So yeah, it's a mess.
JC (31:27):
I think that's right. Yeah.
EW (31:28):
So talking about your book, is it still relevant? Do you still talk about it?
JC (31:33):
I think it's not relevant. I think there are parts of it that are still relevant. It's been, well, 20 years, as you said, since the first edition, and there's a lot of material. And we'll talk about processes in the book that you just can't get anymore.
CW (31:48):
Yeah.
JC (31:49):
So yeah, the basic skills are still relevant that I talk about in the book, but a lot of the architecture in the book is no longer relevant. And I had some discussions with O'Reilly about doing a third edition, but that never went anywhere. They indicated they want to move away from the embedded space going forward.
EW (32:09):
I remember when your book came out, or when I first found it and said, "Oh, this. This I want."
JC (32:16):
Oh, okay. Thank you.
EW (32:19):
I don't remember the second edition, but it's hard to say exactly when that happened. And your editions were pretty close together. Was it 2002 and 2005?
JC (32:31):
Yeah. Something like that. Yeah. That's right.
EW (32:34):
What made you do a second edition?
JC (32:37):
... O'Reilly gave me a very tight deadline to get the first edition out, and there wasn't time to cover all the things I wanted to cover. So the second edition was the way to go back and put in all the extra stuff that I just didn't have time to put into the first edition.
EW (32:56):
So as soon as you finished the first edition, you wanted to start the second?
JC (33:00):
Yeah. Yeah.
EW (33:02):
As soon as I finished my book, I was like, "Never, ever, ever again."
JC (33:05):
Okay. Yeah. I enjoy the writing process. I haven't done anything like that for a while, but I actually enjoy the writing process.
EW (33:14):
Did it open up doors for you?
JC (33:17):
Yeah, actually it did. Because every job, every contract I've had since then, it's been because people have known the book and have gotten in touch with me, and said, we'd like to hire because of this. So yeah, it has, actually.
EW (33:34):
That's one reason to share the knowledge you gain. It's because then it does help you in your career as you go along.
JC (33:43):
Yeah, I think so. Yeah.
EW (33:45):
Do you have suggested resources for people who want to learn hardware now?
JC (33:50):
Yeah, my website.
EW (33:51):
Okay.
JC (33:52):
So there's more to it than just Forth. I'm still going through and doing it, but I periodically add new pages with just hardware design stuff in there. I show you. There are examples of how to write the software for the Scamp to talk to hardware, but there are hardware examples in there.
JC (34:12):
And my goal, as I said, the idea of doing a third edition of DEH with O'Reilly fell through. So my goal with the website is to simply make that the third edition. So it's going to be heavily Forth-based. Because I think Forth is the easiest way to talk to the hardware.
JC (34:31):
But there will be a lot of additional hardware material in there going forward. For example, there's one page there on just how to add a status lead, how to calculate the current limiting resistor, and really simple stuff for people that don't know how to do that.
EW (34:50):
Well, I have heard O'Reilly has changed some things, and they are willing to listen to more embedded proposals, and looking for embedded books.
JC (35:03):
Okay. Okay.
EW (35:04):
So I'd be happy to introduce you to the person trying to convince me to write a second edition.
JC (35:08):
Okay. Yeah. Yeah. Okay. Possibly. I'll think about that. Yeah.
CW (35:16):
So back to the Scamp, what are some applications you've seen that you really like, that other people have done?
JC (35:23):
I'm amazed by what people are using this for. There's a guy in Texas who uses it to control his coffee roaster.
CW (35:33):
Cool.
JC (35:34):
There's a guy in Germany using it for quad rotors. There's another guy who's ... made a wheelchair. I sold a few to CERN, the big linear accelerator in Europe. There's a guy who uses it on his farm for various things.
JC (35:58):
There's another guy I know who does his own home brewing of beer, and he uses it to automate his bottle washing process, all sorts of things. So people keep coming up with ideas for them that I've never quite thought of before.
CW (36:11):
Quadcopter control would be interesting. Because that requires a lot of math.
JC (36:16):
Yeah. Yeah. The PIC24's got six channels of PWM. And you can configure those PWMs with one line of code each on the Scamp. So it's very fast to come up with motor control projects. So the algorithms to do the additional flight computer stuff is more complicated than that. But from a motor control point of view, it is trivially easy on the Scamp.
CW (36:41):
I won't tell you what I had to go through to configure a PWM on the PSoC 6.
EW (36:44):
Well, -
CW (36:44):
But it involved drawing things.
JC (36:49):
Yeah.
EW (36:51):
I mean, I'm not convinced -
CW (36:52):
Dragging and dropping -
EW (36:53):
- that the FPGA thing is good. I am not convinced.
CW (36:57):
Alright.
EW (36:57):
In fact, I'm very much convinced.
JC (36:59):
I love FPGAs. I haven't used one for a little while.
CW (37:03):
Oh, FPGAs are fine. The little FPGA bit they tack onto the Cypress PSoC 6 -
JC (37:09):
Yeah. Okay.
CW (37:10):
- is weird.
EW (37:10):
Yeah.
JC (37:12):
I've never used that.
CW (37:13):
The worst of all worlds.
JC (37:14):
Yes.
CW (37:14):
This has become the PSoC 6 complaint hour. I'm sorry. You do this every week.
EW (37:20):
No, that's not true. You mentioned you have done management.
JC (37:27):
I have.
EW (37:27):
And now you are doing more development type.
JC (37:32):
Yes.
EW (37:34):
Many people get to a point in their career where they feel like they have to go into management. How did you navigate going in and out?
JC (37:45):
Navigate's an interesting word. I'm not sure that I really thought about it in that context. I moved into management within a company. I just started managing development teams. And I really enjoy the process of creating products, and managing great engineers, and coming up with really, really cool stuff.
JC (38:06):
The hard part about management is what comes from above, because you often get people above you who don't really understand what you're trying to do or how it needs to be done. And that's the toughest part. I find if you have really good engineers, you don't really need to do much actual management of them.
JC (38:25):
The management process is more about removing the roadblocks that get in the way of them producing what they need to do. If you have really good engineers, they'll just produce something, and they'll have a fun time doing it. And they'll come up with really great products.
JC (38:41):
I think most of the management problems, in many companies, are because people above try to micromanage the process too much and just interfere with the engineering processes. And how I got out of management, my last major role, I was Director of Engineering at a company that did consult service, so for big data centers.
JC (39:03):
And I was spending most of my week in completely pointless management meetings with people who didn't have a clue, who would just talk nonsense to each other. And it wasn't fun, and it wasn't productive.
JC (39:17):
And it wasn't making the slightest bit of difference to what the company was doing or the products we were developing. But I just thought that there's no point to this.
CW (39:26):
Sounds very familiar.
JC (39:27):
Yeah. I think a lot of people can relate to it.
EW (39:30):
Is that when you started consulting?
JC (39:33):
Yeah. So I basically left that and was doing the consulting work while I was doing the Scamp stuff on the side. And the consulting work, it slowly dropped away, and the Scamp sales are slowly climbing up.
JC (39:46):
So, yeah, and I'm much happier. I'm earning a lot less money than I was before from the Scamps as opposed to a management salary, but it's a lot more fun. And that's what it's about.
EW (39:58):
It's hard to think that, because the money, it's nice. I mean, generally more money is better, but figuring out that you need to be happy,
JC (40:11):
You've got to be happy with what you're doing. Yeah. You've got to be happy and all the money in the world's not going to change that. You've got to be happy with what you're doing. And if you get up in the morning and think, "Oh no, I've got to go to work today. I really, I really can't face that." Then that's not what it's about.
JC (40:29):
Whereas doing what I'm doing, working for myself, sometimes I work seven days a week. And if I feel like having a couple of days off to do something else, then I'll just do that. And I work on what I want to work on, things that interest me, things that challenge me at my own pace.
JC (40:46):
And I don't have people above making silly decisions that just interfere with what I'm trying to do. It's a much more satisfying way of doing it.
EW (40:58):
I completely agree, but many people want to start consulting early in their careers. You waited until you had been a director of engineering. So you had -
JC (41:11):
No, I'd actually done it previously.
EW (41:14):
Oh, okay.
JC (41:14):
So I did do it early in career. I ran my own engineering consultant business for eight years in the late '90s, early 2000s.
EW (41:25):
Do you have advice for people wanting to start consulting?
JC (41:30):
I would simply advise to have sufficient capital behind you to sustain you, because it's a roller coaster. You'll get some very big contracts coming in, and then you'll have nothing for a little ... while.
JC (41:44):
And then you'll have another big contract, and then you'll have nothing. And it's a roller coaster income. So you need to have a buffer there to be able to sustain yourself long term.
CW (41:55):
How about finding clients? That's something we kind of -
JC (41:58):
That's the hard part, yeah.
CW (41:58):
- took for granted, because both of us, when we started consulting, well, you started earlier than me. But for the most part, at least getting going, we consulted with people who we'd worked with, -
JC (42:10):
Yeah.
CW (42:10):
- who had moved on other companies and such. So we had built up a network that we were using.
JC (42:15):
Yes. And I think that's the way to do it. And I think unless you have a network, you have to build on a network, and build contacts through the network, and get your consultant going that way. Because unless you're known, no one's going to give you a gig.
CW (42:32):
Yeah. That's the hard -
EW (42:32):
Unless you write a book.
JC (42:33):
Unless you write a book. Yeah.
CW (42:36):
But you were consulting before the book.
EW (42:37):
Oh, yeah.
JC (42:38):
I was. Yeah. Yeah.
CW (42:39):
Both of you.
JC (42:39):
But then I was consulting, I was doing work, yeah, through contacts and people I knew.
EW (42:47):
Were you consulting when you wrote the book?
JC (42:50):
Yeah, I was.
EW (42:51):
Okay.
JC (42:51):
I was consulting. I was also teaching at the time. I was lecturing at a university, so I was doing some lecturing at one university, and I was doing consulting, and writing the book all at the same time.
EW (43:04):
So lecturing at university, there's a lot of discussion now about learning objectives, and pedagogy, and how you teach. Did you worry about all that, or did you just try to get them to understand the hardware?
JC (43:20):
The latter. You just talk about what you know. You have got to make it interesting. It's got to be simple. It's got to be simple. You've got to relate to the students and just, you engage with them, and make them interested in what you're talking about.
JC (43:35):
So actually, I taught for eight years at one university and then another five years at another university, all in embedded systems type stuff. And I used to really like that.
EW (43:49):
And you don't anymore?
JC (43:52):
I don't have a PhD, so where I am, yeah, you can't teach anymore unless you have a PhD. The ironic thing is that all the local universities all use my book as a textbook. So although I'm not qualified to teach them, I'm qualified to write their textbooks which I find slightly ironic.
JC (44:13):
But I think the teaching workloads these days at universities, I don't what it's like in the states, but certainly in Australia, the teaching workloads are horrendous. There's a lot of management bureaucracy and emphasis on pushing students through as fast as possible.
JC (44:29):
And it's more on getting students through rather than teaching the students, which I think is counter to what it should be.
CW (44:38):
Yeah. It's definitely changed from what I've heard. And it depends on the university too. There are some that are very teaching focused -
JC (44:47):
Yes. Yes.
CW (44:47):
- and some that are research focused, and that does make a difference. But there's fewer of the teaching type.
JC (44:55):
Yeah. I think that's right. Yeah.
EW (44:58):
Writing a book, working on Scamp, not being a manager, these are all things that if you were billing for that time, you would be making more money, but instead -
JC (45:14):
Yes.
EW (45:14):
- you do them because you enjoy them. Do you -
JC (45:16):
Yes.
EW (45:16):
- also do them because there's a service aspect to it?
JC (45:20):
It's primarily because I enjoy it. But part of the enjoyment comes from providing a service to people. I enjoy helping people. I enjoy educating people. I enjoy that sort of stuff. And it is not for ego gratification. I just purely get pleasure from that sort of thing.
EW (45:40):
I do too. And I'm always kind of surprised by people who don't, and yet I don't really know how to ask, "Well, why don't you mentor everybody around you?" Because that isn't a question that you can ask -
JC (45:58):
Yeah.
EW (45:58):
- without sounding like a jerk.
JC (46:00):
Yeah. I'm sure it would be the same with you. But when I was coming up as a young engineer, I had people mentor me, and pass on their knowledge, and share their skills with me.
JC (46:11):
And it's natural to want to do the same with other people. I'm a great believer that knowledge should be as free as possible and as open as possible. And it just makes the world a better place.
EW (46:24):
And you're putting your knowledge out there to show it's not just, somebody else's knowledge should be free.
JC (46:29):
Yeah, I think so.
CW (46:31):
What are you doing to keep current, something that I'm terrible at, so I'm asking you?
JC (46:37):
I'd say I'm terrible at it too.
EW (46:39):
We con people into talking to us every week.
CW (46:41):
Yeah. We have this podcast where people tell us new things, and that's how we learn things.
EW (46:45):
Could you tell us what you've learned that's new?
JC (46:48):
I don't know how to answer that. I'm not sure. I wouldn't say I was current on a lot of things. Yeah, it's harder and harder -
CW (46:57):
It is.
JC (46:57):
- to keep current these days. There's so much happening. So I just focus on what I enjoy, and if there's a problem I need to solve, then I will find a new way of solving that. And I will learn whatever process I need to do to do that. But, yeah, I wouldn't say I'm as current as I should be.
EW (47:14):
How do you stay interested?
CW (47:16):
Yeah, that's a good one. Tell me how to stay interested, John.
JC (47:20):
It's very simple. You do things that you find interesting.
CW (47:24):
Nobody's going to pay me to play drums, John.
JC (47:27):
You just need to find the right person.
CW (47:34):
But yeah, no, flipness aside, -
JC (47:36):
Yeah.
CW (47:36):
I think you're right. That's one of the beauties of consulting is being able to -
JC (47:42):
To pick and choose -
CW (47:43):
Yeah.
JC (47:43):
- what you want to do.
CW (47:44):
Yeah.
JC (47:44):
Yeah.
CW (47:44):
And to say, "No, I don't want to work on - "
JC (47:47):
Yeah. Yeah.
CW (47:48):
" - yet another Bluetooth light bulb. Sorry, if you work on a Bluetooth light bulb.
JC (47:51):
Yeah. Yeah.
EW (47:51):
I'm sure your Bluetooth light bulb is much better than anyone else's ever has been.
JC (47:57):
Yeah. I mean, for a few years I was working as an engineering manager of a company that made electricity meters. And they're the most boring products you could possibly imagine. And it wasn't particularly interesting, and that was really hard to stay interested. So yeah, you've got to find something that you really enjoy doing.
EW (48:17):
Back to the, "How do you stay current?" Are there blogs, forums, podcasts, books, resources that you do try to kind of keep up with?
JC (48:29):
Not specifically. I don't follow anything in particular. I will just browse, and read, and see where it takes me. I spend a lot of time on Hackaday, that sort of thing. But yeah, that's about as far as it goes.
EW (48:47):
That's a good way to see new things, and to see how things can be put together more quickly than you expect.
JC (48:55):
Yes. Yeah. I think that's right.
EW (48:57):
Well, John, it's been wonderful to talk to you.
JC (48:59):
It's been lovely to talk to you both as well.
EW (49:01):
Do you have any thoughts you'd like to leave us with?
JC (49:04):
I would say to people, go and try some Forth. Not my boards. Not trying to push my board. But just go and find a little microcontroller system, put some Forth on it, and spend some time playing with it.
JC (49:19):
And if at first you don't like it, keep playing with it for a few weeks, until it clicks. And it's a language worth exploring, because it is fun.
CW (49:31):
And you've got a bunch of posts on Hackaday about Forth, and your board, and some example stuff. So people can go check those out too.
JC (49:39):
Yeah, that's true. Yeah. Yeah. Yeah. And go to my website, which is www.udamonic.com. There's a lot of stuff teaching Forth, explaining how Forth works, giving an overview. And that's all there free.
JC (49:57):
Some of it is specific to the Scamp, but most of it is applicable to a lot of other Forths. So I hope it's a good learning resource for people, one that's truly available. So please check it out.
EW (50:09):
Our guest has been John Catsoulis, engineer and owner of Udamonic. Check out the show notes for links to Scamp and links to his website.
CW (50:19):
Thanks, John.
JC (50:20):
Thank you very much to both of you. It's been lovely talking to you.
EW (50:23):
Thank you to Christopher for producing and co-hosting, and thank you for listening. You can always contact us at show@embedded.fm, or hit the contact link on embedded.fm.
EW (50:34):
And now I do not have a quote to leave you with. So I will tell you that "Eudaemonic Pie" was actually a pretty fun book to read. A bunch of Stanford physicists and computer science folks go to Las Vegas and try to break the casinos. And they kind of succeed.