When I went to college, I majored in computer science. I took classes about algorithms, data structures, software engineering, design patterns, systems analysis and design (now that is a BORING topic!), web development, databases, operating systems, and even assembly language and computer architecture. To be honest, I actually thought those last two classes I listed were some of the more interesting topics my education covered (and they were both electives, not really part of the core CS curriculum). Maybe that’s a sign I should have done more in the computer engineering side of things. I don’t know for sure.
I’m not saying I didn’t enjoy my CS education, because I did! It was awesome, and I always looked forward to taking my CS classes. I was a math minor as well, and as you can probably guess, I enjoyed taking math classes. I actually took more math classes than I needed (such as operations research) just because they were fun. I guess my point is that I’m not dissing on my CS education; I’m only trying to point out that I had multiple interests in college.
After graduating college, I ended up working at a place that does a lot of work with microcontrollers. I’ve also written some “ordinary” desktop or web-app software, but I’ve found myself really enjoying the work with microcontrollers. As a person with a bachelor’s degree in computer science, I didn’t have any trouble picking up on the concepts. After all, computer science is not a “here’s how to program a generic desktop application in Visual Studio” type of education. You can apply what you learn to many different fields. But in order to fully understand the concepts, you have to do examples, at least in my opinion. And the examples I did in college were C/C++ console applications running on Linux, Java console and GUI applications, shell scripts, and websites in various flavors such as Java servlets, JSP, ASP.NET, PHP, and Ruby on Rails. All of this stuff is pretty high-level–even C apps running on Linux are high-level compared to bare metal code. So in doing this, I understood the general computer science ideas that the curriculum was actually teaching, but I didn’t really have any kind of concrete experience with directly programming to a microcontroller. Even in the assembly class, we ran programs on floppy disks inside of DOS, so that wasn’t bare metal either.
So as you might expect, when I first started at the place where I work, I knew literally nothing about how to use microcontrollers. I had no idea how microcontrollers actually did anything. I remembered from my assembly language class that x86 machines use a software interrupt instruction to talk to a PC’s BIOS, but that was about it. I heard my coworkers throw around terms like “SPI”, “I2C”, “UART”, “GPIO”, “PWM”, “DMA”, “CAN”, “Timers”, “Watchdog”, and all that kind of stuff, but had no idea what they meant.
Luckily, I have become familiar with this stuff (thanks to reading datasheets and my awesome coworkers, of course!), and once you get down to it, it’s really not complicated. It turns out I didn’t understand what goes on inside computers at one specific level. My computer architecture class was at too low of a level (transistors, gates, adders, ALU, etc.), and my assembly language class was at too high of a level (this is what registers are, this is what instructions are, here’s an example of how you multiply two numbers in the x86 instruction set, now go make your own DOS program that uses DOS and/or BIOS interrupt routines to do something cool), if that makes any sense at all.
I think it’s important to understand both of those levels, but there’s a level in between as well. I think I’ll call it “memory-mapped peripherals.” It turns out that microcontrollers have a bunch of special extra devices built in to assist you. They might do stuff like communicate with another chip that’s connected to it or display a message on an LCD display. Ok, so memory-mapped I/O is not really a “level”, but it points out a concept that somehow slipped through the cracks of my education.
So anyway, I’ve decided I’m going to write a series of posts about how to do microcontroller programming from the perspective of someone who has experience with “normal” application programming. I’ll try to teach all the stuff that datasheets just assume you know. I’m sure there are people out there with this same kind of issue. I know I was one of them! If you’re interested in this, stay tuned, and I will start doing more posts! Below is a list of posts in this series I have already written, and I’ll keep it up to date as I add more.
Posts in the series:
- Microcontrollers: Memory-mapped peripherals
- Microcontrollers: GPIO
- Microcontrollers: Interrupts
- Microcontrollers: Timers
- Microcontrollers: Interrupt handlers
- Microcontrollers: SPI
- Microcontrollers: SPI (Part 2)
- Microcontrollers: GPIO/Timers/Interrupts example and LPCXpresso LPC1114 review
- Microcontrollers: Interrupt-safe ring buffers
- Microcontrollers: UARTs
no comments