Embedded - 172: Tell Forth You Me Please

Episode Date: October 19, 2016

James Cameron of One Laptop Per Child (OLPC) tells us about Forth, science fiction, and laptops. We have some tickets for ARM's mbed Connect conference is Oct 24, 2016 in Santa Clara. Will you be in the area? Want to go? Contact us if you want one of our free tickets! (There are still some tickets remaining.)  One Laptop Per Child is one.laptop.org.  Some getting started information on Forth: Mitch Bradley's Forth and Open Firmware Lessons James has been writing about putting C Forth on a Teensy (more on the Teensy from the creator's site). He also has a post on using Forth to snoop the Milo Champions Band's BLE.  James is Quozl on most sites that require a unique ID (such as Github:  https://github.com/quozl). This is from a book called Quozl by Alan Dean Foster. The other older-sci-fi reference was to the Pern books by Anne McCaffery, specifically to the White Dragon. 

Welcome to Embedded. I'm Elysia White here with Christopher White. Our guest this week is James Cameron. We're going to talk about the fourth programming language and one laptop per child. These are related, I promise. Before we get started, don't forget that Embed Connect is coming up probably the Monday after this drops. So if you want tickets, still email me and I can get you in. Also, finally, I am handing out stickers, both at that conference and in mail. So if you want a sticker,

send me your mailing address and I will mail you a sticker. Okay, that's all. Hi, James. Good morning, I guess. Good day. That's nice and generic. Can you tell us a bit about yourself? Well, let's see.

Tall, bearded, gray. From the point of view of languages, because you asked me about fourth, my first language was English and then solder, then basic, and after that was machine code, and then fourth. I had a TRS-80, and I was a child. Which one? Well, young male human, actually. I said, yes, a Model 1 Level 2. All right.

With the reset button at the back. It was always fun. So I had weeks and weeks of learning how that thing worked, reverse engineering it, peeking and poking. And my father used to bring home some articles on things and he brought home an article from Byte on 4th and I was hooked. Yeah, so that's how I started in computing. Then later on, I got a degree in business and didn't really go back to electronics and embedded systems except as a hobby.

But these days, I'm more into it than before. So now I'm a developer at the non-profit One Laptop per Child, and I'm focused on sustaining engineering to make sure production will continue. I live with my wife in the Australian outback, miles from anywhere. Six hours from the beach. Yeah. With the kangaroos. Yes, plenty of kangaroos. Well, I know you listen to the show, so you are familiar with Lightning Round. Now we're going to reflect it upon you. Have you thought about all the questions and what you're going to answer? Yes, I'm afraid I have. I'm

looking forward to the question that I haven't heard. I have one. Okay, good. What language should be taught first in university courses? For programming. I would say English is the first start. I've struggled over this question, but mainly it doesn't matter because programming is emergent from the symbols that you have inside you.

And so it really doesn't matter which language. So I haven't been able to recommend one. I mean, I've tried a few. I'm afraid that answers a bit long. That's okay. You know, you get points off for that, but the points won't be any good. So why not? Yes. All right, favourite fictional robot Doors Venabully from Foundation series by Isaac Asimov

I love that everybody has a really different answer for that one Least favourite planet Least favourite? Oh The Red Planet on Anne McCaffrey's Pern series. The Planet of the Thread. Oh, that's a good answer.

That would be my least favorite. I cried when that dragon first went there. That was the white dragon. Yes, that's what it was, yes. I was young. People out there are nodding along and Christopher's shaking his head. That's like the one series I haven't read. Give it a try.

I will, I will. I keep meaning to. Is a mobile phone an embedded system? Well, I don't take my phone to bed so it's not embedded. Yes and no. It's hard to. Yes and no. It's hard to say. It changes. The boundary is one of those flexible ones where since everyone has one,

it can't be embedded. That's kind of an interesting point of view, actually. Yes. Should we bring back the dinosaurs? We have them now, the birds. They're with us. We need to keep them rather than bring them back. We saw a really big one this morning.

Yeah. Great Heron was trying to fish in our pond. And it is great. When making something new, should you target ease of use for new users or powerful features for more advanced users? I think targeting powerful features for more advanced users is the right thing to do

because when you're the maker making something, you are the most powerful user for the thing you're making. And if you hold back with what the thing can do, then you're intentionally defeaturing it. You're crippling your own creation. Later on you might pull out things that you realise are dangerous. But initially it should be as complex

as you can manage. What lightning round question should we add? Hmm. You wanted a new question. Analog or digital multimeter? All right. We'll ask.

Most important to your daily work, soldering iron, keyboard, mouse, or pencil? Keyboard. I use Emacs. Tabs or spaces? Yes. How many spaces are in a tab? Eight. Eight?

Eight. Wow. Yes, there are eight spaces in a tab um you have to have that assumption because someone some way is going to be using a character cell terminal um so that's one reason why i don't use tabs much at all i press the key so that the text moves, but I would prefer the text to move as a result of spaces rather than tabs because there isn't an agreement on how big a tab is. So I have a tendency to commit code in Git with all the tabs changed to spaces just so that I can be clear about what I mean,

and especially if you're using Python. Oh, God. Oh, yeah. Besides Embedded FM, what do you listen to for podcasts? Several of the government radio podcasts in Australia, some of them are on BBC as well, such as All In The Mind. I listen to Dave at the Amp Hour and lots of stories like Escape Pod and Drabblecast

and Cast of Wonders and that sort of thing. Escape Pod is really cool. Varied, but very escape, but very cool. All right. Last question for lightning round. What is your preferred calculator? A HP33E from 1979. It still works.

I knew that that was going to have a definite answer. So let's go on to what we promised, which was fourth. And this is a programming language. Yes, let's go on to what we promised which was fourth and this is a programming language yes let's go forth let's be forthright about this i have so many of these um yeah so i guess the way i should phrase this is tell forth you me please yes yoda yes it's hard to say because it was so long ago that I started and the choices you make when you're a child for programming languages are not the choices you make when you're pushed into them by university or management or a project at hand. But FOR fourth is a very strange language. It can be as strange as you like.

The syntax is weird. The grammar is weird to non-existent. But it's, I think for me, the language that closest fits to the way English works, how a word in English can have multiple meanings and depends on context and the arrangement is variable. I think that Forth started out being someone's pet project, Charles Moore, and then a few people saw it and thought it was great and it went on from there.

And it was heavily used in the radiophysics community, and I had some connection into the radiophysics science research labs in Sydney, and that was interesting. But as a language, it's a set of words and each word has a defined meaning and you assemble those words into new words and that's your functions and each word is delimited by a space so the only word you can't use is something with a space in it or a tab, which is handy. And you build these words up into this dictionary. And because there's no punctuation or grammar,

parameter passing is like a stack. Hence, if you like HP33E calculators, you automatically like stacks because the only way to get anything done on a reverse polish calculator is to put things in the right order and hit the operations. So with no syntax for parsing arguments, everything becomes what you do with the stack. And so these are always interpreted. Forth is always an interpreted language, not compiled, not like C. Well, sometimes compiled or interpreted, it's really up to the developer to explain that.

Think of embedded systems development with cross-compilation. When you use C or C++, you edit your source and you compile on your host and flash the image into the target and then press the big red button off, it goes and runs. And to change anything, you have to edit the source on your desktop or laptop and recompile and flash it again. And that latency in the iterative cycle can really kill the thought, can really make it hard to debug. But when you're using Forth, the first few steps seems the same, but the last steps are different. You edit the source and you compile on the host

and you write the image into the target as you did before. But to change anything, you can compile or test on the target over the serial port or whatever connection you have and if you fail you can hit reset on the target and try again and once you're happy with what you did you bring it back into your host add it to your source file and your next image will have it and so the latency is reduced because you can do development directly on the target instead of being tied to that long cycle of changing source and building. It's pretty interesting because the closest we come today with normal C development is, oh, I might change the value of a variable in the debugger to cheat. But I can't actually change the code. I mean, I suppose I

could maybe if I really wanted to, but probably not. Yes, but you have to know in advance that you're going to need that variable. And so once you realize that, well, I'm not sure what that delay should be between those two things, then in C what you tend to do is make that a variable and then add a user interface to your code so that you can change that variable on the target, like toggling a GPO or something like that.

And while that works, it takes a lot longer and you have to go back and do it again. Whereas with Forth, you get that advantage of operating on the target as a command language and just making things happen. And you can do some seriously weird stuff, you know, change the dictionary on the fly and things that we don't really have the tools to do in the C environment. Kind of thing like back in the day, you'd write your C program

and running your compiler, and I'm talking 20 years ago, was so expensive in time that you'd feel, well, maybe if I just change the hex file, you know, edit something in, change one of the parameters in there, and that would shortcut your development. So this is taking it further and doing that editing of things on the live target. And, yes, it crashes a lot. But it crashes because you've done something seriously silly.

You know, you've started a loop that the watchdog doesn't get to be touched anymore and so the watchdog goes off. Or like on the ESP8266, if you write a fourth loop, which takes all the time away from the rest of the multitasking operating system, then the watchdog goes, I don't want you anymore, and you get a reset. So I came across Forth as a way to bring up boards. Given a relatively complex system and a hardware engineer who preferred Forth. He built a Forth interpreter, and over the serial line,

we would verify that each GPIO worked the way we wanted and make small little functions to test sub-modules so that when he gave me the board, he could say, if you run this, it works, therefore it should run in your code and be fine. And then I would program in C. And I've continued the idea of board bring-up tests.

It's something that I do talk about a lot, and I think it's important, and how they become manufacturing tests often. But I have to admit, I do tend to write my own command line. I mean, a command line interpreter is a, I don't know, it's a maybe thousand line file, maybe, including all the commands, and you get a little bit more control and a little more reusability for me in manufacturing. Why should I be using

Forth instead of my own custom command line? Well, a command line interpreter is fundamentally something that takes text input and puts it into a buffer and then parses it into words and looks for the words in a list of commands. And that sounds like a fourth interpreter. The command line interpreter then has to execute those words, and if you're not going to pass parameters between the words,

then yes, you have what you need. I mean, I could imagine building a fourth that doesn't have a parameter stack, but you'd have to never be able to pass parameters between the commands you type. It's kind of like trying to use a bash shell without redirection. You can do it and it makes it nice and easy because you don't have to worry about the complexity of passing data between processes. So my view on it is that Forth is also a command language interpreter, and it just happens to be a little more flexible than a static one.

But you might not need the flexibility, or you might not want to leave such a powerful tool on your shipping product. You know, it depends. Some manufacturing crews wouldn't want that sort of thing. Because it is powerful and it can lead to, let's just call fire. Yes. Depending on your system. You can wire things up in such a way that the system that you've left behind on the product is capable of damage

and that can bring you to a few problems like how do you cope with that and being able to restore to last good configuration is a good one. An answer that I've used before is try not to save any state on the product. A product which has no saved state can never be in a configuration that won't boot or won't start up properly. And so if you can utterly avoid saving anything, then it will always work the same way. I like that in theory, but I find in practice I never get to do that. And then I thought it was almost always interpreted, and when you

as your description, you can then fold back in, makes a lot of sense. You build up your commands, and if you want to build them up in the interpreted part where you type at it, or you want to build them up into the compiled part, you can do either one. Does that mean you're writing your compiled code in fourth? I've always written fourth in C, so I'm new to the idea that you really build a fourth interpreter in fourth.

Yes, you build the fourth interpreter in whatever you have to hand, which could be C or it could be fourth. With one of the fourths I use, OpenFirmware, it's built in fourth, and the fourth makes a new fourth. With the other one I use, C4th, yes, it goes forth, that's right. With C4th, you build it out of C, and there's an inner interpreter which implements the threaded code. And so there's two meanings for the word interpreter. There's the software is interpreting as you time or when you present her,

or there's an inner interpreter which implements the threaded code model where the definitions are a series of pointers to implementations. And that conflict in the meaning, also that commonality in the meaning can be a bit misleading. You see, a full system spends very little time compiling or interpreting. Most of the time is spent executing the code that you've asked it to. There are ways to quibble about that fourth systems vary on how they've been implemented depending on what you need to optimize for memory or cpu cycles so the fastest is sub subroutine threaded code where

a program a function a word is a series of machine language call instructions. So the processor just jumps to it, executes it, and then on return it's finished that function. It's fast, but it's expensive in memory because you end up having three bytes, a 16-bit system for every reference or 32 bits on an arm for every reference because they're going to be relative calls. And so it's not often done that way

because there are other ways of doing it. Indirect threaded code is where a word is a series of pointers to the machine code. And direct threaded is where the word is a series of pointers to the machine code and direct threaded is where the word is a series of pointers to other words but that latitude types they need this inner interpreter to guide the execution which runs through the the tables of data and and makes the calls to the machine code. So, yeah, there is this confusion about whether it's interpreted or compiled. Whenever you're talking to a fourth using a keyboard, you're answering the question from the interpreter,

what do you want to do next? But if you make a new definition, that gets compiled into the dictionary. It's really obvious when you're Bit banging when you want to make a GPO toggle on and off if you turn the GPO on and off on the command line And press enter and you watch that on your oscilloscope It's a nice long pulse because the interpreter had to look up each word. But if you define that into a new function, a new word,

and then execute that, the pulse is extremely short because the execution is much faster. Okay, that makes sense. It's an interesting kind of, like you said, it's not quite clear. It's more of a hybrid than a pure. It doesn't map to the meaning of compiled and interpreted used in other languages. So it's hard to get it across. putting C4 on a Teensy, one of the Cortex M4 versions, Teensy 3.1. Can you tell us a little about that? Yes, I was already using C4 for other work, and I heard about the Teensy and it looked interesting,

so I bought one and bought two because you always buy two in case you zap one. Exactly. And worked out how the SDK worked that Paul provided with that and found I could make something blink. And once you can make something blink and and use the UART you can put C4 on it if you've got enough memory and so I took the important parts of the software development kit the UART functions the processor initialization, getting all the clocks running, and called that from C4.

And as a result, C4 is then up and running. It's just a matter of merging critical parts of the SDK with the important parts of C4. You see, C4, what it wants from the hardware is read a byte from the UART, write a byte to the UART, and that's it. The rest of it's execution. So that simplified API to the hardware means you don't have to implement much to bring the thing up on any given chip. So how big does this Teensy C4 implementation end up?

I didn't try to make it terribly small. There's a lot of junk I left behind because I didn't need the space, but I think it was about 51 kilobytes. I think there is a smaller one out there, Micrisp Stellaris. They did it several months after I did, and theirs was smaller. But fourth is by nature very small because the functionality is all encoded in a dictionary, most of it, instead of in machine code,

and the dictionary tends to be a little bit smaller than the machine code. Really? Well, for a given amount of functionality, yes. Okay. You pay for it in performance. Right, right. For particularly time-critical functions,

you would write them in C and create a fourth word, which is a wrapper for the function. Like if you had to bit bang SPI or something, or where you wanted to use a library from the software development kit. But most of the time, for a given amount of functionality, you end up using far less flash space, less space in your hex file. And that's one of the compelling advantages.

When you're stuck with a hardware platform, when you're stuck with a particular size of flash, you have a choice of cramming, removing functions if you're using C, or trimming down the amount of memory that you've allocated. But with Forth, you start out with using a lot less anyway. So there really does seem to be a difference in the density. I'm not quite following. I mean, if I have a function in C that is, I don't know, toggle GPIO line at 1 kHz. And inside this function I have a GPIO set and then a stupid delay loop and GPI clear and a stupid delay loop. And then I just do a while around that,

or maybe you have to call that all the time. Something like that. And if I do it in Forth and I put it in the dictionary so that it is faster, don't I still have to do those same operations? I don't understand how Forth can be smaller, given that the operations in the end have to be done by somebody. It's a consequence of the extreme modularization, the factoring that occurs.

In Forth, there's a word called MS for milliseconds, and you call that when you want a delay. And for GPO access, we typically have a word which takes a GPO number and sets it or takes a GPO number and clears it. And so the definition of a 1 kHz bit banging oscillator would be a loop construct around a delay call and to request to change the GPO state. So it would be of comparable size in experience, to the direct C implementation.

But that's because it's using other parts of the dictionary which were already defined. Oh, I see. Okay. I guess I was assuming reuse in C as well. And so I wasn't getting those together. Okay, that makes more sense. One of the ways you know that you're using a fourth interpreter is the backwardness of it.

I'm going to rephrase that. The Yoda-ism of it, the reverse Polish-ism? I'm not sure. The fact that you do the function call first, and as you noted, you put it on the stack. You say set GPIO or whatever you're using for that command, and then you're saying GPIO1. Or maybe you say set GPIO weight, GPIO one, and then a time. And so it's always, it's usually verb, object, object, or verb, object. Are there other idioms and identifiers that a C programmer would be able to say, oh, right, you do that and forth. It's a different way of thinking about it.

Yes, yes, there are. The way that you refer to GPIO pins is you put the GPIO number on the stack and then say, please set this. And so you put in the argument first, the parameter goes first, whereas in in C you tend to call a function and then put the arguments in parentheses but the way the compiler deals with that in C is it takes the arguments puts it before the call instruction so the compiler does the reversing for you in fourth the compiler just compiles a reference to the word. And so you have to have prepared the parameter stack

before you get to that point. So everything's odd the first time when you look at a new language and pretty much most of the fourth will seem odd. The lack of grammar in the parameter stack and you don't just assign values to variables using the equal sign there are certainly patterns of syntax that do repeat there's a tendency for fourth programmers to make a new word for anything you see a lot you know if you if you find yourself typing three words in fourth more than once you tend to make a new word to encapsulate it if you find yourself typing three words in fourth more than once you tend to make a new word to

encapsulate it if you can figure out a way of describing that so yes there are certainly idioms and pretty much unlike any other language means that you're learning them from scratch see this is this is one worry I have because I always used an RPN calculator when I was in high school and college. And I forgot it one day during a grad school exam, but they had ones for me to borrow, but they were all the normal infix calculators

and I could not use it. So I'm worried that if I start using Forth, I will break my brain and never be able to write code again the right way. No, that doesn't happen. When you look at Forth, your brain automatically switches into Postfix. It's so quick and so easy that you can even have an editor buffer on screen where you've got C code down on one frame and fourth code up on the other, and you switch between with your eyes, and it becomes totally transparent to you. Your brain very rapidly learns what fourth looks like and what C looks like, and you never have any confusion.

So, no, the human brain is excellent at recognizing patterns and assigning a set of neural networks to each pattern. We should have recognized Casio calculator. You're still bitter about that test, aren't you? I do remember with great enjoyment handing my calculator to kids at school and them not being able to figure out how to make a simple sum because they couldn't find the equals key. And their complaint was that there is no equals key.

And that approach to the problem, that there is no equals key, therefore I cannot use this calculator, wasn't quite well thought out on their behalf. It should have been, why is there no equals key? Yeah. Why is there a really large key marked enter? And what does it do? It pushes the stack. Okay, so it is different.

We agree. And it is a little brain bending, especially since my description was backwards, because I don't do RPN in my head. But how do you recommend learning forth? I know we need to actually do it, we need to type it in, we need to work with it. But even before that, just syntax and getting a little bit used to it. Do you have any recommendations? Well, the method that I used was I had a lot of time. I was very young. And I started building things with it. And that really applies to any language. You build something with it and you overreach and you struggle and you fail and you struggle again

and read the source code and break the problem into smaller pieces and solve each one in turn. Basically, you're going to fail a lot in learning any new language. And as long as you can keep failing, you can keep learning. The same thing works with learning someone's spoken language. The look on their face when you make a mistake is very revealing and you need to adjust your words. The same thing with fourth. If you do something enormously enthusiastic and it crashes,

then you know you've done something wrong. So do it again. Oh, it crashes again. Well, at least that crash is reliable. Break it into smaller pieces and see if it'll crash in the first half or the second half. But if you were doing it formally, you would start with a vocabulary, a list of words and

what their meanings are. And a vocabulary or a word list will list out each word and what their stack effect is, what they do to the parameter stack, how many arguments they consume, how many arguments they give back so the plus key on a hp calculator consumes two arguments and gives back one and when you're working with fourth you keep this in mind all the time how many arguments have i got on the stack because if you get that wrong your function will leak arguments or will consume more than it should. And you end up in control of all the stack operations. So learning is a matter of doing.

And yes, it would not be easy for someone who has never used it before. But there doesn't seem to be any limit to human learning. I've met some very old people who can just have picked up a musical instrument they'd never played before and fiddled with it for a few days and then they can do it. So it's the same thing with computer languages. I've surprised myself several times in learning languages I thought were never a good match for me, like Python. I can do Python now.

I'm happy about that. And then there's using all the standard libraries, all the conventions and the standards. Forth is based on a standard. There's been several standards, just like in the XKCD cartoon. There's been several standards of Python as well, and the libraries available in Python are great if you're operating on an operating system,

but Forth hasn't historically been heavily used inside operating systems, and so there aren't the equivalent standard libraries. But you can figure out how to call out. Forth on a Linux host, for example, can quite easily call out to subprocessors, can make network connections. Just the other day I was, I bought this tin of chocolate-flavoured stuff from the shop and it came with a kid's fitness band for, I think it was about $30 in your money. And it turns out to be Bluetooth low energy and it turns out to be easily scanned using Linux.

And so I hopped into C4th, which has an interface to the Bluetooth layer on Linux and started sending some interesting messages to see how it would react because I didn't really want to load the app and use their software. I wanted to find out whether I could make it work myself. And, of course, I had some excitement. At one stage I sent a random command and it shut down

and didn't wake up again. And I figured out that I'd triggered the prepare for shipping command where the device shuts down and you need to plug it into the charger to wake it up. And so I was able to wake it up again. That's good. Didn't have to buy another one. But being able to just compose packets in Bluetooth

and send them over the link to the device was really flexible. And so I learned a lot about how that particular layer in C4 would work for me. And I didn't know it before. And occasionally I had to read the source and occasionally I might brick something. But without bricking something, you won't learn much about it. This has been part of your job, too. This isn't just for bricking BLE bands. Yes, yes.

I mean, it never was. My early career was in, I was working for an electrical engineering company, and then I worked for digital equipment operation and then Compaq when we were bought out and then HP when we were bought out. And my time in the big iron side of things, we almost never touched forth. There was just no demand for it.

But when I left HP, there was this project starting up called One Laptop Per Child. And I'd already been involved in the projects before I left HP as a volunteer testing the laptops in the outback where there were no wireless signals to confuse things. And so when I left HP, I asked OLPC if they needed anyone, and they said yes, and so I ended up there. And yes, OLPC used fourth in the BIOS for their laptop. Okay. And one laptop per child was something I heard a lot of for a little while, a lot about for a little while, but haven't

heard much about it lately. And I'm not sure everybody is sort of aware of what they do, although you'd think the whole one laptop per child thing would give it away. But can you tell us? It could be a rule. No more than one. Yeah. Can you give us a little bit about what that organization does?

Well, when it started, there were no netbooks. There were no small laptops. And in my opinion, back then, the laptop market was trying to increase margins and making bigger and better laptops and charging more for them. And no manufacturer back in 2006 seemed willing to go down towards cheaper and smaller. They were all heading upwards towards bigger and better. And I was working for a manufacturer of laptops at the time, though I was working in the big server room stuff, Vax EMS systems. manufacturer of laptops at the time though i was working in the big server room stuff back to ems systems and so what one laptop per child did was create an entire new market by pushing downwards and smaller and cheaper and after after they started, while I was still a volunteer from a distance, they caused other vendors to say, well, look, there is some money in this. And so the Asus EEPC came out and all these other small laptops

started coming out. So it was a good push which made a good change to the industry but yes originally it was make laptops for children in the third world who needed laptops not the people who needed food first but the kids who needed laptops and get the school systems, the education departments of the countries to deploy these laptops and have useful content on them like extracts of Wikipedia or resources and books. Learning to read programs.

That's right. And many of these countries love the idea of having something in English as well because English was felt to be the gateway to success. But, of course, they also want their local languages. They want to be able to teach their local languages. So the laptops had to be thoroughly internationalised, a keyboard designed for the local language in collaboration with the local authorities and software built for them.

And all that huge amount couldn't practically be done if it was going to be closed source. So base it on an open source operating system and build everything as open source as possible. And so that's from 10 years away, that's what it was mostly about. And we had lots of people involved. I was just a minor tester when i was first involved um but as time went on the team has changed and people have come and gone and products have come and gone we made four different models uh the01, which was based on a geode processor with 256 megabytes of memory.

Oh, that was a lot. And then the X01.5, which was based on a VR processor with one gigabyte of memory and four gigabytes of micro SD card mounted in a cage in the inside. And so I joined about that time once they'd settled that design. And then we moved on to ARM and made the XA1.75 with a Marvell system on a chip. And so that had soldered down EMMC, soldered down RAM, all passive cooling, so heat spreader rather than a fan,

but all in the same original industrial design, same external case with a few changes. Well, and that was important because that initial industrial design was very focused on being rugged. Yes, very thick plastic, very droppable, and fairly resilient to water ingress. Not totally. We saw some laptops come back from being buried in mud for a few weeks and

yet we know what happens to them. You get electrolysis of the clock battery and the main battery and things don't work afterwards, but they can take a brief shower. They can take being dropped, which if you're giving to kids is a good idea that they can take a brief shower. They can take being dropped, which if you're giving to kids, it's a good idea that they can withstand that sort of thing. And the whole idea was about child ownership, so that the children would be the security system for their equipment rather than locking them in a classroom and only letting the kids use them during school hours.

The idea was to let the kids take them home and use them at home. Some countries did it like that, some didn't. There was variation, but the product supported both modes of operation. And roughly 2.6 million have been produced and shipped. I don't get to hear much from where they went, unless there's a technical problem which affects a thousand of them, and then I get to hear about it. Hear about it, but not in a good way. No, no, it's more sort of, how can we fix this?

What do we need to do to make it work? Yeah. So right now you're mostly focused on sustaining engineering, is that right? Yes, yes. The product has been produced still and has been produced for several years. And as second sources come online, the task has been to write drivers for those things, like a new camera module or add features to the operating system if we can or things like that. No way is as large amount of development as early on, but still enough to keep things going.

And it's still all open source? Yes, yes, mostly open source. The plan was at the beginning for everything to be open source. The operating systems and the apps are open source, but in the end, the wireless firmware remained closed. And there's always people who will say, oh, that should have been open too, but I can't find any wireless firmware which is open

unless it's a wireless module that you can't upgrade the firmware on, in which case it has the firmware in a flash chip on the module. And so, yes, it's closed. It just happens to be over there and we don't touch it. But the wireless firmware on the XO laptop, it's built into the open firmware as a binary, so we can load it from every laptop. So you get a copy of it automatically.

And how does it being open source affect how you feel about it? I don't think I would have been as involved or as easily encouraged if it was closed source because with closed source product you have to do it all yourself with open source you can build on the shoulders of giants you can borrow and reapply the source code you have from elsewhere so we're using the linux kernel and we're using the fedora operating system or more lately, the Ubuntu operating system. And being able to rely on those things is immensely helpful. It reduces the effort, the time, the cost.

Lots of people get to rely on those. How does it be in open source change what you do does that make sense am i headed off in a totally different direction not sure because it requires thinking about an alternate reality of how would it be if it wasn't open source um it would be me alone with the source code and I wouldn't have as many friends. That would be sad. There is that, that it is a community. You know, a lot of people work from home or as you do work remotely

and you lack some of the office chatter and so having it be open source does imply that there is some office chatter although maybe of a different sort but it's still there are people working on it when it's a vendor relationship you don't always notice that the other side are people. You're just communicating through this user manual and this API. Yes, working on closed source projects at Digital and Comprac and HP firstly you're working with a very small

group who's paid to do the job and so there is very rarely any quibble about code quality or comprehensibility it's more sort of well the boss is paying this guy to write this code it might be crap but um you know he's being paid and um we need to integrate it. And so we need to make sure that our code will integrate with his code, even though we don't like his code. But in the wide world of open source, if you put crap out, you get told. And so there's a very great tendency to write better.

And in my opinion, the overall code quality of open source is somewhat higher than the code quality of closed source in small teams. But on the other hand, you do get people who are, you know, punctuation Nazis who will spend their time giving you their opinion about exactly how it should have been phrased. And tabs ate spaces? I bet there are a lot of people out there who want to tell you that.

They want to tell you all about the goods and bads. That's right. So there are advantages and disadvantages. When working on kernel patches, for example, if you have to, as I did, write a kernel driver for a camera, do I engage with the open source community or not? I could write the driver and hold it in our kernel repository and might never get out. Or I could write the driver and post it for review, and that review will tell me things I didn't need to know and things I did need to know. And if you want to keep getting something reviewed,

you have to keep up with the process of posting your patch to the Linux kernel mailing list or the appropriate list for what's being talked about and deal with the feedback. And that may mean rewriting parts of it or reimplementing the way you do it. But by doing that, you'll eventually become better at writing for the community that you're targeting. And so the next time you write something, it's going to be a better match for their understanding

and it will be more likely to be accepted. Most of my publicly accepted kernel patches are very small things. I'm not a big kernel writer. It's just sort of fixing the odd thing here and there, adding a USB device to some driver or fixing a wireless driver that we use on the Excel laptop

so that it works better. Little things like that. You did a little bit of kernel work, Christopher. Yes, yes, but my experience was different for different reasons. It was less about getting feedback on the code and more about, we don't think this thing should exist.

So, a separate issue. And these laptops are quite complex. You sent me a link to a schematic, and it was 40 pages long, and I went, wow. And all of the pages were dense. Yes, that's the schematic from our wiki.laptop.org for the X04. Yes, it is a lot more dense than a typical embedded system. It's a laptop.

Exactly. It's composed of several embedded systems, and one that works out where to put the power and when and assists with the battery charging and the other one which does the application processing for the user. And then there's embedded systems for the wireless and for the storage and for touchscreen and they're all separate and they've all got to work together.

I was talking to a friend recently about how do you learn new things that are related to your career choices. And it was just after I had looked at the schematic, and I'm like, well, open source does have some value there too. You don't have to contribute. You can just read it and probably get a lot out. Where would I start if I wanted to really look at that schematic? It was a little much to just deal with the wall.

Is there an area, is there a special part that you think is the most fun um feel free to say your own part we all do that i understand yes yes well not much of the actual hardware was mine um we had some great electronics engineers back in the design stages and my job was more about testing and coding but in the latest model the ambient light sensor the original design was mine and it was modified slightly and that's just a an led operated in reverse and measure the capacitance and that was very low cost and the led was already on the bill of materials, so it was a no-brainer.

And that was implemented in firmware first by me and then by Richard and Paul, the firmware engineers who worked on the embedded controller. The touchscreen manufacturing tests were mostly mine, so I was very familiar with how the touchscreen worked. It's a infrared emitters with 180 degree light guide so they emit away from the screen and then the light gets turned around toward the screen, goes across the front face of the screen and then gets turned around at the other end again to come into

the detectors. And it's like rows and rows of detectors and emitters, and they're at a slight slant so that the lines of infrared go across the screen on a slight slant. And the firmware in the touchscreen chip deals with all that, and all we have to do is read the values out of the chip. But there's ways in which that assembly can not be assembled right, and so we needed tests that would show what might be wrong. And so those tests in open firmware were mostly mine

with some help from Mitch. But over the years, I've had my finger in almost all of it. And I'm very familiar with it because it's part of what you do as sustaining engineering. You hear about a problem, you look into that part of the schematic and you work out what could have been wrong and what might have gone wrong in manufacturing and work out how to deal with it.

But I don't think there's any place you can really start in a complex design. It's kind of like how to understand fourth. You dive in, you stall, you try and understand what something is. In the case of a schematic, you see if you can find a data sheet for the component to figure out what it is because there's very few explanations in schematics for what each device is for.

Overall design, there's a page at the front or at the back which shows the power domains and how they're connected and that's helpful to get a basic idea of which bits are powered and when that's probably that sort of thing is the sort of thing where i would probably go through each page and try to make each page one block on a sketch page and then try to connect all those blocks and then make bigger blocks or smaller blocks we need to get a hierarchical picture of the whole thing if you have just the schematic and the 40 pages it's i mean it's hard to get an overview and so you almost need to go down and break it down and say okay this is the major high low and okay here's where this is referenced and then start taking large pieces and trying to understand it that way but yeah if you're faced with the thing as it is

it's very difficult to kind of comprehend that at once. The waterfall model of software development, let's write a specification of what we're going to have the software do and then write the software. The same thing happens with hardware definition. You can have a functional specification of a product and then negotiate with the electrical engineers until you end up with a schematic which describes the implementation

of the design of the specification. So, yes, there is a spec for the laptops, and you have that spec for other reasons as well. But if you had read the spec of the laptop first and then read the schematic, then you would have a different view. But just diving into a schematic of a product is kind of like opening it up and trying to reverse engineering it. It's a tough way of doing things, but it's not necessarily the right

or the wrong way. It's just a way. As long as the number of things that you keep in your mind never exceeds seven you can keep that up forever but as soon as the number of things in immediate memory exceeds seven you're going to have to write it down or figure out some way of memorizing it and then assembling a coherent understanding of a complex machine is a matter of grouping things together until you understand how everything relates. I look at a car these days. I remember back in my day. Yeah, a

carburetor and a block and a fuel pump and an exhaust manifold and then you're done. A couple of wheels. I live in a farming community where things are held together with fencing wire. And it's hard to do that with the cars these days. All right. This has been a great discussion, and I have a few more questions for you. Hit me. Quozle, your handle, it's sort of what you're known as online, probably because some movie director took your name

or used it or something. Oh, I have been confused for being the movie director before. Yeah, I did have a bunch of questions about submarines, but I took those out. It's from an Alan Dean Foster book, is that right? Yes, yes. The name I picked for myself was when I was playing Net Trek, the computer game, back in the 1990s, before we gave the internet to the masses. It was the name of an alien civilisation and not an individual.

So whenever I refer to the name, it's a name of a group. And I chose it when playing the game at lunchtimes at Digital. I chose it because of their honourable approach to conflict, their stance, the rules of engagement, I guess the chivalry of how they approached a challenge because that was always an issue for me. If you're going to fight, you need to have a good reason and you need to do it fairly.

And so that's why it became my handle once i was using it in netrek once the internet was released to everyone it was a matter of oh this this this username hasn't been taken so i'll use that and since most of my existence on the internet back in those days was because of my association with NetRec, I ended up having hosting provided for me by one of the people involved on the project. And so my website got called Quazzle at the Front. It's a great book.

I recommend the book. I'm not getting any kickbacks from Alan. And I've read a lot of his work. And if I was choosing a handle today, I would not choose that because I feel I would be imposing on someone else's creative works. But yeah, that's how it began. And it's more sort of every time I'm faced with what username do you want, it'll be something I try first.

But it didn't mean anything by it. I understand. I mean, Chris's handle is Stony Monster. I'm sure. Just tell everyone. It has a nice little history about it, but he's doomed forever with it. But I can always get my username. Pretty much.

There's been a couple places where that hasn't been available. Yeah, so I'm Quazel on GitHub. Cool. This is the advantage to having an oddly spelled name. All right. Chris, do you have any more questions? I did have one question. Excellent. I'm kind of going back to fourth for just a minute i don't know if we really touched on if if somebody wants to learn fourth

or get into fourth or try it out um and maybe they're coming from an arduino background or hobbyist um what would you recommend just kind of the getting started kit to to fourth james has been working on esp 8266 those four dollar those $4 Wi-Fi processors. Maybe I should let him tell us about it. Yes, I was using Lua with NodeMCU on the ESP8266 and I've got about 15 of them around the house doing various things like temperature sensing, controlling pumps and motion detecting and all that sort

of thing, all on a local network, not on the great internet of things. But I kept hitting limits with NodeMCU. I'd add functions and then the dreaded out-of-memory conditions would occur. And when Mitch Bradley, the inventor of OpenFirmware and C4th, ported to ESP8266, I jumped on board and I've been testing and extending it. It's based on the latest C4th and C4th itself can be built for various targets. So you can try it out on Linux or Windows.

But you can build it for ESP8266 using the ESP open SDK, and we also borrow some of NodeMCU just to get the sort of like a shim, a wrapper. We use NodeMCU for the lightweight IP layer so that we can send TCP packets, and I'm quite impressed so far. It works great. I can write applications with it. I've done a few interesting benchmarks just to satisfy myself

that I could do some genuine work with it. I tested the rate I could get by doing bit banging on GPIO. I measured the GPIO interrupt to GPIO output interrupt latency. So I set up the crow and set up a test script that would send a pulse into the thing and measured how long I had to wait before I'd get the response from the interrupt function, pin change interrupt.

It's got TCP IP networking, so you can write servers and clients to do things. But since you're writing in fourth, everything's different. It's not like you're using code from somewhere else. And so I've been able to bring up various I2C and one-wire things. That's worked great. One of the recent changes has been embedding open firmware on top of C4 so that the device tree thing and the ability to access file systems.

So one of the recent tests I did was micro SD card, being able to read whatever file systems on the micro SD card. So that's great. I don't think that's something that I could do easily on NodeMCU, or at least not with as much memory left over. So, yeah, that's up on GitHub. It's really not in a great condition. Like it's not a nice shiny GitHub repository for the uninitiated.

You really have to be comfortable with compiling C programs and understanding what we might have forgotten to push. So, yeah, have a look at GitHub for that. I do have a couple of binaries. People can email me and I can send them the binary if they just want to try it out. But I'm not sure if I'm asking for help because it's interesting just using it myself. But if anybody does something with it

then great, we're interested. And are you communicating to the fourth interpreter, because clearly I'm all about the interpreter part, through the serial port or through Wi-Fi? Well, both, actually. The fourth interpreter is so well encapsulated that it's possible to do both. When it starts, you're communicating through the serial port on the ESP8266. And I've tested it on ESP01, the little 8-pin modules, and on ESP12, Outerfruit

Hazars. I don't know how to pronounce that word. That was what I would say. Oh, good. But I've also written a Telnet daemon, which lets you Telnet into it. No security. We're talking IoT here. So you can enter fourth commands over Telnet, and that's great for scripting with Python. And I've built a thing like an FTP server so that you can read and write files on the Flash file system.

But when I've built applications with it and I have an application running on my bench at the moment just reading from a temperature sensor and transmitting to a web server that application could be either you build forth with this fourth source file included and then flash that into the chip. Or you can use a script which is stored in a file on the file system on the chip and just load that automatically on boot. And so I've used both methods. And the latter method costs you an extra second of startup time

or a seventh of a second, I think. And your choice as to which way you want to do it. Or you can just type the commands in and see what happens. That's the way we do things in Forth. All right, that does sound pretty interesting. I can think of times when I have wanted to Wi-Fi into my device and debug it. And let everyone else do it too. Well, yes, there is that.

But yeah, well, IoT and security. Might as well leave it open. They're going to break the lock anyway. Well, I mean, who's going to figure out that it might be running forth? That's weird. I don't think that obfuscation is a replacement for security. No, it never is. Do you have any last thoughts you'd like to leave us with?

Yes, yes, yes, I do. I think what I've learned by having to do everything is that the time you learn is when you're doing something really complicated that you don't understand. And you get this doubt and fear in your head. I can't do this. This just looks wrong. I don't understand it. And that's the best state to be in if you approach that state with a willingness to step through the parts you do understand and look for ways to explain the parts that are in doubt

then you get out the other side and you do understand it and so I'm beginning to yearn for that state of mind because that means I'm learning That is excellent. Very good reminder. I sometimes get in that state and get unhappy, but I think next time I'll remember what you said and maybe it will make me happier.

Our guest has been James Cameron, a developer for one laptop per child. I will include his GitHub link in the show notes along with a bunch of others. Thank you, James, for being with us. No worries. Thank you also to Christopher for producing and co-hosting. And of course, thank you for listening. Hit the contact link on Embedded FM if you'd like to say hello,

sign up for the newsletter, or subscribe to the YouTube channel. I'm going to have to change that because you're not supposed to get the contact link for all of those, but you'll figure it out. You're very smart. The subscribe link. For some of them and the contact for others. Yeah. It'll all make sense, I'm sure. Don't forget, if you want to get a free ticket to the Embed Connect conference, email me and say so.

If you want stickers, email me your address, your physical address. Do not email me your email address if you want stickers email me your address your physical address do not email me your email address that doesn't work yet and now a final thought this one from ee cummings who oddly is a poet i like very much though don't understand much trust your heart if the seas catch fire. Live by love though the stars walk backward. Advertisements in the show, we did not put them there and do not receive any revenue from them. At this time, our sole sponsor remains Logical Elegance.