Embedded - 416: EEs Are From PIC, SWEs Are From Arm

Episode Date: June 9, 2022

John Catsoulis is the founder of Udamonic and creator of the Forth-based Scamp development board. He spoke with us about Forth, electrical engineering, and writing a technical book. Find out more about Udamonic’s Scamp at udamonic.com. There are some hardware projects under the Create menu. The Forth programming language is famous for its small size, portability, and post-fix (RPN) nature.  John wrote O’Reilly’s Designing Embedded Hardware. While some parts are out of date, the general theory is still good. CuriousMarc’s YouTube channel is full of retro-computer goodness. Long ago, Elecia read The Eudaemonic Pie and imagined a life of high tech crime. Please don’t tell her if it doesn’t hold up well. Transcript

Welcome to Embedded. I'm Alicia White, alongside Christopher White. Our guest this week is John Katsoulis, 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. Hey, John. Hi, Alicia and Chris.

Nice to be on board. Could you tell us about yourself as if we met at an electronics conference in Brisbane? 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,

30 years experience in software and hardware design. 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. And these days, I have my own little company called Eudaimonic, and I produce small embedded controllers that run forth. Wait a second. You said mining imaging radar? Yeah. So the company in Brisbane called Ground Probe that does slope stability radars.

So they 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. They can detect sub-millimeter movement up to five kilometers away. About two and a half miles, three miles. I just always like those mysterious imaging things that can do high precision stuff at great distances or very, very high precision. Yeah, anyway. Yeah. Are you ready for lightning round?

I've derailed us already. Yeah, that's fine. Define Eudaimonic. Eudaimonic is just my small business, which is a venue for me to produce hardware that I find interesting and useful. What I make is useful for people. That's my primary goal, make stuff that's easy to use. Define the word eudaimonic. Define the word eudaimonic.

It comes from the ancient Greek word eudaimonia, which is the satisfaction you get from doing something well. I feel like there was a book with that in the title. Eudaimonic pie. Oh, okay. I forgot what it was about. Gambling. Using math to gamble.

Okay. Slightly different idea. 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. I like it. I like it. Yeah.

So that's what my goal was with starting eudaimonic, just do things that interested me and, uh, you know, gave me pleasure from doing it. Okay. I'm enjoying this, but you are failing lightning round. We're failing. We're failing. We're failing.

Um, so pick 32 or cortex M. Uh, probably cortex M cause I like arms, but pick 32 is based on MIPS and I've always been a fan of MIPS too. So yeah, but probably cortex M. Beach or rainforest?

We've got both here, so do I have to pick? But probably beach, I have to pick one. Cats or dogs? We've got both. So either one. I think I'm throwing this lightning around. Post-fix or infix? Probably post-fix.

Hardware or software? Hardware. Do you like to complete one project or start a dozen? I tend to fall in between, so I start six projects and then will complete them before I start anything new. So I will finish a project before starting a new one. Do you have a tip everyone should know? Not really, no.

All right, a bonus question then. Favorite fictional robot? Probably R2-D2. Okay, he's all right. Yeah. So your company, Eudaimonic, makes Scamp. Yes. Why that name first?

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. And I'd just been watching a YouTube video, a YouTube channel called Curious Mark, who does lots of interesting retrocomputing stuff. And he was talking about a very early microcontroller system called the SCMP, or otherwise known as the SCAMP.

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. And it's programmed in Forth. It oh oh sorry yes could you tell us about scamp okay think of it it's it's like an arduino um but i rather than arduino is 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. 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 a line of code simply by interacting directly with the hardware. So it's fantastic for that sort of thing.

And it's an interpreted language. At least the part you're talking about is interpreted. Yes and no. It's sort of like an interpreted language, but when you type a line of code, even as an interpreted level, it actually compiles to machine code before it runs so it compiles on a line by line basis and when you

for example type the plus operator that compiles down to a single addition instruction for the processor and it executes as a single addition instruction there's no overhead it's really efficient. Some of the fourth applications that you can write for a scan, 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 FizzBuzz. It's a simple programming quiz. And I've seen versions of FizzBuzz running on PCs under Python, and FizzBuzz running on the fourth was over 300 or 400 times faster than a PC running Python, which is not bad for little microcontrollables. Yeah, big processor

running python or a little controller running forth yeah fourth is known for its post-fix operations which is mind-melting for some of us rpn it is yes it is it is yeah it it's the sort of thing that people either love it or they hate it love it uh yeah if you um if you've come from an assembly language programming background fourth is the type of language that makes an awful lot of sense it started if you think 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 fourth is just a wrapper around that.

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 everything individually. It's a bottom-up programming language rather than top-down programming language. 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. And the way you work with Forth, it's post-fixation of 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 and you can clutch something together and it will work and it might not be the best approach to writing software

but you can make something work fairly easily with Forth really makes you think about what you're actually trying to do, how you're trying to solve the problem. And you end up with much more efficient code, much leaner code, and far less bugs simply by the way force forces you to approach the problem. I found that RPN, 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 and of course i can't use a regular calculator that confused me but um one of the difficult things is if you try to write out a series if you try to hand somebody here's how I did this calculator, it's not easy to read. No, that's right. But the difference with Forth is it's not a single

line of code. Well, you can do it as a single line of code, but it's 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. But I have heard Forth referred to as a write-only language. I thought that was Perl. Oh, yes, exactly.

And pick assembly. Yeah, it can be a bit like that. That's the best way to describe it. It has a long history going back to the late 60s, early 70s, written by a guy called, well, originally created by a fellow called Charles Moore for controlling telescopes. And it's a language that was created for embedded systems. I think 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. 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 who, is it because it's more like assembly? It's more like the processor itself?

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're right on the hardware. 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

and you can do things very quickly and very fast um to give you give you an example um my nephew's into model railroad so i was going to make a controller for him and this before i did the scam i was using arduino and i spent a good part of a morning writing the software for a controller for his model railroad 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 scan, I timed myself and writing the application actually took less than one minute. 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. There is a learning curve with Forth. You can't, 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. I've used it for board bring up primarily. Okay. And then switched over to C to do the larger algorithms. Yeah.

That's a very common approach. Yeah. These days with the larger Cortex-Ms, I see a lot of people putting CircuitPython on them. Yeah. Have you tried that out? 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. 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. 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. That's true. Especially for board bring-up.

Yeah. And CircuitPython has the advantage that it usually has a USB interface and you just type the file on the microcontroller and then it runs 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? You can do that, yes. Basically, yeah.

Yeah. But it's not as complicated or as hard as you might think it's. In terms of board bring up, it's actually fairly very lean, very short process to actually get things up and running. And I actually use scams to bring up other systems, so I will use the scam to debug other hardware in a target microprocessor system. Try and figure out what the iSquaredC address is or why SPI isn't working. It's probably a great tool.

Yeah, that's right. I haven't used Forth since I was larval back in the early 80s, I guess, when it was kind of like on early PCs and Apple and Timex Sinclairs, you had BASIC, you had basic, you had assembly, and a lot of times you had fourth. And so I played with it some, but I don't really remember it that much. So now thinking about it now, one of the things with microcontrollers

is there's this, at least with more modern ones, not necessarily picks, is there's just a lot of peripherals and things that require a lot of configuration. 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? You can twiddle all the bits, but with the SCAMP's run type of Forth called Flash Forth, and Flash Forth out of the box doesn't actually provide any hardware support at all, but there's a layer of additional software.

Programs in Forth are called words, so there are words to do analog and digital IO, PWM, serial, I2C, SPI, all of the standard stuff is there, 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. 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. But that does require Forth to know how to make something into a switch, which... It does, yeah. In C, you have the hardware abstraction layer, and if you're talking about STM32, there's like 4,000 lines of code in order to set a GPIO to be... Several fathoms down. Yes. Yeah.

And why does it need to be that complicated? Well, it does. It does. Well, I'll tell you. Well, I'll tell you. Go ahead, Louise. Because they are supporting so many different processors, and they're all the little corner cases.

If they had one how per processor it would make our lives so much easier but it would make their lives so much harder which it should be their life should be hard as far as i'm concerned yeah one of the guiding principles of force when it was created was that each version of force for each machine should be tailored specifically for that machine. So you don't have one standard force. You have a thousand different forces for a thousand different machines to get the most out of each machine.

Yeah. And that's a very embedded systems concept of not allowing the extras to weigh you down. Yeah. And that's one of the force was very common and very popular in the 80s. allowing the extras to weigh you down. Yeah. And that's one of the fourths 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 the ANSI – I'm generally in favor of standards, and I think the ANSI standards are great, but ANSI fourth is awful.

And when they did ANSI fourth in the 90s, they tried to make one very large, bloated, generic 4th that did everything for everybody, and they just made it hard to use and confusing. And I think that's what killed 4th for a lot of people. And 4th is now starting to have a comeback because people are discovering the lean versions of 4th 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. And a lot of people will try using ANSI Forth on something like a PC or a Mac, and they decide within 20 seconds they've decided they don't like Forth and they won't ever touch it again. Please move your thumb away from the hammer and stop hitting it. That's exactly right.

I had a bad analogy, but I don't understand why somebody would do that. I mean, because you say, I want to learn fourth. Yeah, okay. And so you do it that way, but that isn't what it's for. Yeah, yeah. So whether it's my hardware, 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. It does sound like there's an application space for it. Yeah. Other things occupy but don't do a great job at in terms of small, dedicated, like the original embedded concept, the small dedicated piece of hardware with small firmware, not something, you know, I'm not sure you'd want to write a smartwatch in Forth, but. Well, Charles Moore, Charles Moore, who created Forth,

he did a VLSI CAD program in Forth and the whole application was less than 64 kilobytes. Yeah, but that's when you only had 64 kilobytes. 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, the SCAN, 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, 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 fourth, that's more than enough memory. 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 4 is so lean, there's very little overhead associated with it. 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. 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 commands or the code ends up looking very odd. It doesn't look. Well, the machine code. The machine code is very hard to reverse engineer.

Have you heard anything about that, John? 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 they, as I said before, they're just assembly language subroutines.

So when you compile a Forth program, they're just calls to assembly language subroutines. So what you're 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. 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 at disassembly. Even though it's fourth, it's still effectively disassembly of an assembly language thing, if that makes sense.

What is the processor you have on this camp? 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 Flash Forth, which was written by Mikael Nordman in Finland. Mikael's a very bright guy, and Flash Forth did everything that I wanted it to do.

It's a really beautifully written little language. It's got some very nice features. And that was for the picks 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 the PIC24 now. It's a really capable, very fast 60-bit 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 some quite a bit of horsepower out of it when it's programmed very efficiently. 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-bit. It's a 24-bit address space, which is where the name comes from.

Okay. It's confusing for me, too. It's actually a 16-bit processor. Yeah, there were a bunch of 24-bit address processors back in the in-between era. They were 16-bit, but they had 24-bit addressing. Well, it's good that you chose a pick probably because you probably, if you'd chosen an arm, you wouldn't be able to obtain any now. So I can't get any parts out to order at the moment.

So I've just finished designing a motor controller little board, which I designed on a Texas Instruments part. And I had it on the parts on back order, and they were on a Texas Instruments part. Oh. And I had it on 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. And say which June? That's right, yeah.

Getting parts at the moment is a challenge. I do have a lot of Scamp 3s in stock, but making new ones at the moment is going challenge so i do have a i do have a lot of scant threes in stock but making new ones at the moment is going to be hard i have been hearing 70 to 90 week it feels like it i don't have that kind of patience i've got i've got a friend who works at microchip and microchip apparently selling lots of development boards at the moment, simply so people can pull the parts off them and reuse them on something else. I mean, that's going to have some reliability issues.

There's some limits to that. Yeah, yeah. So you've been through several versions of this board. Yeah, yeah. So this is the SCAMP3. So there have not been major differences between them, just minor tweaks and additions. So the Scamp 3 is the latest one.

It sounds like you use this and you like it for your own work. But how do you – I know you're an engineer. How do you go about selling Scamp? I don't spend a lot of time advertising or trying to market it. There's a small user group and people hear about it and then word of mouth sells. 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. It's just a nice little board that I'm happy to sell to whoever wants it. Most of the customers are in the US and Canada and the EU, actually, which I find interesting. Yeah, international shipping is not cheap. Or fun. 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. You ship them to Adafruit, and then Adafruit ships them. Not that I'm volunteering them. Just it is possible. I did talk to DigiKey about it, but I couldn't get any sensible answers out of them, and that sort of fell through. I might follow up with Ada for it. That's not a bad suggestion, actually. 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. I absolutely agree. Okay, and so you'd always be able to tell absolutely great okay and so there 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 yes yes yeah double e's are from pick and uh software engineers are from arm there's that book right i i i have a friend and sometimes when we sit down, we'll see somebody walking past and say, yeah, that's a software engineer. That guy's a hardware engineer.

You can pick them by the way they walk and address, I think. But, 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. Why? I just find they have a different approach to the problem. Isn't that good? No, I think he's saying the hardware engineer has a different approach to the problem.

Yeah. I think the hardware engineers have a better understanding of what the software is really doing when it's running on the hardware. 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. I would say that's true for the deeply embedded space. I would say that's true for the deeply embedded space. I would say that's true for the fourth and assembly speakers. Yeah. Well, I think once you get to the STM32...

I'm talking about C programmers and Linux 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. You're talking to software engineers. That's fine. I want to let you know that. I think I'm talking to hardware engineers who can do software.

Definitely not. And I do think it's different. I mean, you know, I have a Riley book too and I really have thought about how many of my double E friends who write software,

they don't understand reusability. 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 do, who will do better than software engineers in that zone. But once you get beyond that into other things, there's stuff software engineers

do that is better. For lack of a better word. Decreases the complexity by understanding the generalities. When I say a hardware engineer, I'm talking about specifically someone from the microprocessor space rather than a generic person. Yeah, yeah. But I also think once you get beyond a certain... Like, if you're talking about a Linux person, I doubt there's anybody who's... There aren't many people who understand what a desktop-class microprocessor is doing anymore.

And I don't think you're going to write software with that knowledge that helps you. There aren't many people who understand what a desktop class microprocessor is doing anymore. Yeah. And I don't think you're going to write software with that knowledge that helps you. Yeah. 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, like, one or the other. But, yes, there's areas where each excels in different ways. Yeah. I mean, my students, the software folks are pretty hesitant about data sheets. Oh, God. I can understand that.

They build character. Yeah, exactly. They build character. And the double E's are like, well, okay, I'm still trying to set up the compiler, and the software people have finished their projects. Yeah. There's a lot of truth to that. They're tortured by the tools. Well, I think the problem is today we're being asked to do things that are desktop-like things. Oh, my goodness.

As soon as you put networking and Bluetooth and multi-cores and a display with colors and now you're talking about it's a computer and certain things no longer 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. Yeah. I think that Yeah. So, yeah, it's a mess. I think that's right, yeah. So talking about your book, is it still relevant? Do you still talk about it? 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 in, we'll talk about processes in the book, but you just can't get it anymore. Yeah. 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. So that's indicated I want to move away from the embedded space going forward. I remember when your book came out or when I first found it and said, oh, this, this I want. Oh, okay.

Thank you. I don't remember the second edition, but that, you know, it's hard to say exactly when that happened. And your editions were pretty close together. Was it 2002 and 2005? Yes, something like that. Yeah, that's right. What made you do a second edition?

The first edition was done, 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 um the second edition was the way to go back and and put in all the extra stuff that i just didn't have time to put into the first edition so as soon as you finished the first edition you wanted to start the second yeah yeah as soon as I finished my book, I was like, never, ever, ever again. Yeah. See, I enjoy the writing process. I haven't done anything like that for a while,

but I actually enjoy the writing process. Did it open up doors for you? 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 you because of this. So, yeah, it has actually. It's one reason to share the knowledge you gain is because then it does help you in your career as you go along. Yeah, I think so, yeah. Do you have suggested resources for people who want to learn hardware now?

Yeah, my website. Okay. So there's more to it than just Forth. I'm still going through and doing it, but I've periodically added new pages with just hardware design stuff in there. I show you there are examples of how to write software for the SCAM to talk to hardware, but there are hardware examples in there. 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 fourth-based because I think fourth is the easiest way to talk to the hardware 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 calculate the current limiting resistor and really simple stuff for people that don't know how to do that. 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. Okay.

So I'd be happy to introduce you to the person trying to convince me to write a second books. Okay. So I'd be happy to introduce you to the person trying to convince me to write a second edition. Okay. Yeah, it's probably, yeah, okay. Possibly, I'll think about that, yeah. So back to Scamp, what are some applications you've seen that you really like that other people have done?

I'm amazed by what people are using this for. There's a guy in Texas who uses it to control his coffee roaster. Cool. There's a guy in Germany using it for quad rotors. There's another guy who's done a wheelchair, would make a wheelchair. I've sold a few to CERN, the big linear accelerator in Europe. There's a guy who uses it on his farm for various things.

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. Quadcopter control would be interesting. That requires a lot of math. Yeah, yeah.

The PIC-24's got six channels of PWM, and you can configure those PWMs with one line of code each on the SCAM. 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's trivially easy on the SCAM. I won't tell you what I had to go through to configure a PWM on the PSoC 6. It involved drawing things. Yeah. I mean, I'm not convinced that the FPGA

thing is good. I am not convinced. In fact, I am very much convinced. I love FPGAs. I haven't used one for a while. Oh, FPGAs are fine. The little FPGA bit they tack onto the Cypress PSoC 6. Ah, okay. Yeah.

I've never used that. The worst of all worlds. This has become the PSoC 6 complaint hour. I'm sorry. We do this every week. No, that's not true. You mentioned you have done management. I have.

And now you are doing more development type. Yes. 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? Navigate is 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. 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.

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 will just produce something and they'll have a fun time doing it and they'll come up with really great products. 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 console service, so for big data centers. 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 and it wasn't making the slightest bit of difference to what the company was doing or the products we were developing.

And I just thought, there's no point to this. Sounds very familiar. Yeah. I think a lot of people can relate to it. Is that when you started consulting? 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 has slowly dropped away and the scamp sales have slowly climbing up so yeah and i'm much happier i'm earning a lot less money than i was before from the stamps as opposed to a management salary but it's a lot more fun and that's what it's about it's hard to to think that because the money nice. I mean, generally more money is better, but figuring out that you need to be happy. 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 is 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 can't face that, then that's not what it's about.

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, 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.

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... No, I've actually done it previously. So I did do it early in my career. I ran my own engineering consulting business for eight years in the late 90s, early 2000s. Do you have advice for people wanting to start consulting?

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 and then you'll have another big contract and then you'll have nothing and a little while, and then you'll have another big contract, and then you'll have nothing, and it's a rollercoaster income. So you need to have a buffer there

to be able to sustain yourself long-term. How about finding clients? That's something that we kind of took for granted because both of us, when we started consulting, well, you started earlier than me, but for the most part, at least to getting going, we consulted with people who we'd worked with, who had moved on to other companies and such. So we had built up a network that we were using. 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 consulting going that way. Because unless you're no one, no one's going to give you a gig. Yeah. Unless you write a book. Unless you write a book. But you were consulting before the book.

Oh yeah. Yeah. Yeah. But then I was consulting, I was doing, I was doing work with, um, yeah,

for people that, through contacts and people like that. Were you consulting when you read the book? Yeah, I was. 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. So lecturing at university, did you – 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? The latter. You just talk about what you know. You've got to make it interesting.

The more – it's got to it interesting. It's got to be simple. It's got to be simple. You've got to relate to the students. You engage with them and make them interested in what you're talking about. So I actually taught for eight years at one university and then another five years at another university. It's all embedded systems type stuff. I used to really like that. And you don't anymore?

They changed. 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 but i think i think the teaching workloads these days at universities i don't know what it's like in the states but certainly in australia the teaching workloads are horrendous um there's

there's a lot of management bureaucracy and emphasis on pushing students through as fast as possible. And it's more on getting students through rather than teaching the students, which I think is counter to what it should be. 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 and some that are research-focused, and that does make a difference. But there's fewer of the teaching type. Yeah, I think that's right. 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 you do them because you enjoy them. Do you also do them because there's a service aspect to it? 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's not for ego gratification.

I just purely get pleasure from that sort of thing. 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. I'm not it will 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. And, you know, it's natural to want to do the same with other people. Now, 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. And you're putting your knowledge out there to show it's not just somebody else's knowledge should be free yeah i think so yeah what are you

doing to keep keep current um something that i'm terrible at it so i'm asking i'd say i'm terrible at it too we con people into talking to us every week yeah we have this podcast where people tell us new things and that's how we learn things. So could you tell us what you've learned that's new? 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 to be 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'll find a new way of solving that and i'll learn whatever process i need to do to do that but um you know i wouldn't say as current as i should be how do you stay interested yeah that's a good

one tell me how to stay interested it's it's it's it's very simple You do things that you find interesting. Nobody's going to pay me to play drums, John. You just need to find the right person. No, I think you're right. Flipness aside, I think you're right. It depends on... That's one of the beauties of consulting, is being able to... To pick and choose what you want to do.

Yeah, and to say, no, I don't want to work on yet another Bluetooth light bulb. Sorry if you work on a Bluetooth light bulb. I'm sure your Bluetooth light bulb is much better than anyone else's ever has been. For a few years I was working as an engineering manager at 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. 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? 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. That's a good way to see new things and to see how things can be put together more quickly than you expect. Yes. Yeah, I think that's right. Well, John, it's been wonderful to talk to you. It's been lovely to talk to you both as well. Do you have any thoughts you'd like to leave us with? I would say to people, go and try some Forth.

Not my board, so don't, I'm 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. 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. 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.

Yeah, that's right. Yeah. Yeah. Yeah. And if you go to my website, which is www.udemonic.com, there's a lot of stuff teaching forth, explaining how forth works, giving an overview. That's all there free.

Some of it is specific to the scan, but most of it is applicable to a lot of other forths. So I hope it's a good learning resource for people and that's truly available. So please check it out. Our guest has been John Katsoulis, engineer and owner of Eudaimonic. Check out the show notes for links to Scamp

and links to his website. Thanks, John. Thank you very much to both of you. It's been lovely talking to you. Thank you to Christopher for producing and co. It's been lovely 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.