Yes, the F020 is it. BTW, the only reason I recommend that one is that it is nicely loaded with peripherals that are useful. It isn't the simplest uC to use because of the way you setup the I/O. If you are playing with the development board though this isn't a problem. If you are laying out a board you better have the I/O configuration nailed down or you can shaft yourself inside a microsecond. Don't ask me how I know this.
Let me see what else I can say about programming microcontrollers and RTOS's. I really enjoy programming at this level. It can be a lot of fun and, as a hobby, there are tons of places where one can apply them.
I've used other uC's in their line-up with good results. Of course, Microchip has a number of good ones too. Probably cheaper. It's been a while since I've used one of theirs.
Once you get to a certain level (and to a certain type of problem) moving up to 16 or 32 bit uC's is a good idea. You can even run really compact versions of embedded Linux on some of these. I've played with chips from TI (MSP430 family, if I remember correctly) and others. But first steps are better taken with simpler 9 bit MCU's. It is important to learn what you can with just a few bytes of code and data.
I am currently teaching my son embedded programming using a number of tools. We started out with Lego Mindstorm and their graphical programming approach. That didn't last long. I am sure there are people who love it, but I find it incredibly restrictive. It is very, very difficult to express and describe complex logic with icons and wires.
I've had the same experience at a much higher level. When developing with FPGA's you have the option to use graphical (schematic) tools to describe functionality and have the compile infer circuitry. When I was getting started with FPGA's I thought it'd be great. It didn't take long to realize that the graphical approach is limiting and hard to maintain. A few pages of Verilog (a C-like language used to describe circuitry) is light-years away in terms of usability, expression and maintainability.
Digressing. So, we moved to RobotC from Carnegie Mellon:
Very cool. Neat way to learn some level of embedded programming without having to go too low level. You have high-level commands to run the motors, read sensors, buttons, etc. It makes it easier to focus on learning the basics of programming, robotics and algorithms.
I also have him cranking on Java through the use of another wonderful too: GreenFoot, from the University of Kent.
I couldn't recommend GreenFoot more as a really neat way to learn about OO programming and programming in general. Yes, I know, I may have sounded like I was jumping in the anti-OO wagon in earlier posts. That is not the case. I will use any tool at hand and happen to like OO very much when it makes sense.
There are tons of very nice tutorials for GreenFoot that have you writing mini games within a few sessions. Very, very cool tool.
The next step is to move him to a PIC or SiLabs development board and go back to pure C. Start from scratch and write the code to do things like blink LEDs, sense switches and switch arrays, run a double-buffered serial port, etc.
The first project is always something like making a single LED blink.
Then you move on to making eight LED's light to reflect an internal 8 bit value.
Then you turn that value into a counter and you use various techniques to make the count visible. A uC running at 20+ MHz can count so fast that the LED's would simply look like a blur. A beginner might use loops to waste time between output events in order to slow down the count. Then you move on to using timers and then timers with interrupts.
The next step could be to build a simple clock or stop-watch with a set of seven-segment LED displays. Now it starts to feel like a real project.
After that, maybe an RC servo driver and then a multiple RC servo driver. Then make it so that it can be commanded through a serial port.
These are just a bunch of ideas. They have a progression of design complexity in both the electronics and software. With the right guidance and tutorials there's a lot to learn right there and we are not into RTOS's at all.
Eventually you get to a point where you need to start doing more than one thing at a time. This is where one starts to learn about time-slicing the microprocessor in order to do a little bit of one task and then the next and so on. One common pattern is to break-up execution into, say, 1ms slices and hand that millisecond, if you will, to a given task. The task would have to quickly do something and then give control back to the scheduler so that the next task can get a shot. There are a number of ways to do multitasking, each with its own pros and cons.
Example: Say you are building an auto-pilot for an RC plane or helicopter. You are going to need to monitor commands from the pilot (via radio), temperature, voltage, acceleration, gyroscopic and magnetic sensors as well as possibly a GPS receiver and other resources. And you are going to have to do this very quickly in order to create the illusion of doing it all simultaneously. This is where multitasking and an RTOS come into play.
Multitasking doesn't necessarily demand an RTOS. I've done plenty or projects where lots of I/O is being services without a real RTOS in place. There are well understood techniques to do this sort of thing.
The field is vast and can be very interesting and rewarding. I'll probably have my son go through the above (not the auto-pilot, that was just an example) and the task him with something like building a sprinkler controller or some such project entirely on his own at some point.
I am hoping that by the time he gets to college he will have programming in his DNA. This will allow him to focus on higher-level work. I seems to be developing a real interest for robotics, which could lead to AI and other interesting fields of study.
Incidentally, I am doing all of this because, of course, I want to teach my kids everything I know. I am also very interested in teaching other teenagers about programming, robotics and technology in general. So, I am using my oldest son as a test subject to develop the framework for a potentially neat tech summer camp for teens to be launched here in the Los Angeles area next year. We'll see how that goes.
Thanks again for a great post. Not sure this really adds anything to the conversation, but felt that I should thank you again. For what its worth, I never thought you were dismissive of OOP; your original post seemed rather clear, if rather alpha in tone, that you thought the important thing was to use the tools at hand.
Funnily enough I was asking for the same reason that you had in mind: I have a child with an interest in robotics who recently hit the the limits of Mindstorms. Alas it has been 15 years since I last did any embedded programming so I am rather out of touch. (Indeed it has been a while since I have done any programming.) The silabs dev board seems to be an amazing deal in terms of the amount of peripherals and documentation available, thanks for pointing that out. I think I shall get one and have a fool around, it looks like great fun!
Let me see what else I can say about programming microcontrollers and RTOS's. I really enjoy programming at this level. It can be a lot of fun and, as a hobby, there are tons of places where one can apply them.
I've used other uC's in their line-up with good results. Of course, Microchip has a number of good ones too. Probably cheaper. It's been a while since I've used one of theirs.
Once you get to a certain level (and to a certain type of problem) moving up to 16 or 32 bit uC's is a good idea. You can even run really compact versions of embedded Linux on some of these. I've played with chips from TI (MSP430 family, if I remember correctly) and others. But first steps are better taken with simpler 9 bit MCU's. It is important to learn what you can with just a few bytes of code and data.
I am currently teaching my son embedded programming using a number of tools. We started out with Lego Mindstorm and their graphical programming approach. That didn't last long. I am sure there are people who love it, but I find it incredibly restrictive. It is very, very difficult to express and describe complex logic with icons and wires.
I've had the same experience at a much higher level. When developing with FPGA's you have the option to use graphical (schematic) tools to describe functionality and have the compile infer circuitry. When I was getting started with FPGA's I thought it'd be great. It didn't take long to realize that the graphical approach is limiting and hard to maintain. A few pages of Verilog (a C-like language used to describe circuitry) is light-years away in terms of usability, expression and maintainability.
Digressing. So, we moved to RobotC from Carnegie Mellon:
http://www.robotc.net/
Very cool. Neat way to learn some level of embedded programming without having to go too low level. You have high-level commands to run the motors, read sensors, buttons, etc. It makes it easier to focus on learning the basics of programming, robotics and algorithms.
I also have him cranking on Java through the use of another wonderful too: GreenFoot, from the University of Kent.
http://www.greenfoot.org/door
I couldn't recommend GreenFoot more as a really neat way to learn about OO programming and programming in general. Yes, I know, I may have sounded like I was jumping in the anti-OO wagon in earlier posts. That is not the case. I will use any tool at hand and happen to like OO very much when it makes sense.
There are tons of very nice tutorials for GreenFoot that have you writing mini games within a few sessions. Very, very cool tool.
The next step is to move him to a PIC or SiLabs development board and go back to pure C. Start from scratch and write the code to do things like blink LEDs, sense switches and switch arrays, run a double-buffered serial port, etc.
The first project is always something like making a single LED blink.
Then you move on to making eight LED's light to reflect an internal 8 bit value.
Then you turn that value into a counter and you use various techniques to make the count visible. A uC running at 20+ MHz can count so fast that the LED's would simply look like a blur. A beginner might use loops to waste time between output events in order to slow down the count. Then you move on to using timers and then timers with interrupts.
The next step could be to build a simple clock or stop-watch with a set of seven-segment LED displays. Now it starts to feel like a real project.
After that, maybe an RC servo driver and then a multiple RC servo driver. Then make it so that it can be commanded through a serial port.
These are just a bunch of ideas. They have a progression of design complexity in both the electronics and software. With the right guidance and tutorials there's a lot to learn right there and we are not into RTOS's at all.
Eventually you get to a point where you need to start doing more than one thing at a time. This is where one starts to learn about time-slicing the microprocessor in order to do a little bit of one task and then the next and so on. One common pattern is to break-up execution into, say, 1ms slices and hand that millisecond, if you will, to a given task. The task would have to quickly do something and then give control back to the scheduler so that the next task can get a shot. There are a number of ways to do multitasking, each with its own pros and cons.
Example: Say you are building an auto-pilot for an RC plane or helicopter. You are going to need to monitor commands from the pilot (via radio), temperature, voltage, acceleration, gyroscopic and magnetic sensors as well as possibly a GPS receiver and other resources. And you are going to have to do this very quickly in order to create the illusion of doing it all simultaneously. This is where multitasking and an RTOS come into play.
Multitasking doesn't necessarily demand an RTOS. I've done plenty or projects where lots of I/O is being services without a real RTOS in place. There are well understood techniques to do this sort of thing.
The field is vast and can be very interesting and rewarding. I'll probably have my son go through the above (not the auto-pilot, that was just an example) and the task him with something like building a sprinkler controller or some such project entirely on his own at some point.
I am hoping that by the time he gets to college he will have programming in his DNA. This will allow him to focus on higher-level work. I seems to be developing a real interest for robotics, which could lead to AI and other interesting fields of study.
Incidentally, I am doing all of this because, of course, I want to teach my kids everything I know. I am also very interested in teaching other teenagers about programming, robotics and technology in general. So, I am using my oldest son as a test subject to develop the framework for a potentially neat tech summer camp for teens to be launched here in the Los Angeles area next year. We'll see how that goes.