W2uC: Why to Get Started With Microcontrollers

Shouldn't it be "How to..."? No. I won't tell you how to get started with uCs. You can find a lot about how you can get some LEDs blinking in the internet. This is about what things you might want to consider and why to do so. I will introduce you to some typical problems and suggest some solutions. I want to give you some starting points so you can make your own decisions, because I don't know what exactly you want to solve with your uC. I don't even know, which uC you will decide on. And I won't tell you on what you have to decide.

There is always more than one solution to a problem and since the the problems differ none of these solutions is the best in all cases. So it's all about making reasonable decisions. Thus I want to tell you why you might want to choose one way or another.

If you are actually interested in the questerion "Why to get started with microcontollers?":

• it can be a lot of fun
• you can do a lot of cool things with uCs
• it might be a daunting at fist, but it's not that complicated
• you already use uCs daily (if you own a TV, a fridge, a car, a mobile phone, ...) so it's not a bad to get some understanding

What is a microcontroller?

A small computer in a single package. It contains:

• a control unit (CU), that interprets the commands and instructs the memory and the ALU
• a arithmetic logic unit (ALU), that performs the calculations
• memory for the program and the data
• buses for internal communication
• peripherals for additional tasks
• interfaces to interact with the outside

Should you start with reading a lot of theoretical stuff about uCs or just jump into the deep end and try to build something with your uC? I had my first contact to uCs during a three-day seminar I looked really forward to. The instructor had a lot of administrative tasks to do so he left us basically alone with some uCs and the tasks to get some LEDs blinking. We had some notes written by typewriter and copied many time overs, no access to the internet and little knowledge about uCs. Two of us got the LEDs blinking (maybe they had already tinkered around with uCs before) and the rest of us got asked what we did the whole time. So practical without theoretical might not the best way.

My first real lecture on the topic was the polar opposite. Once a week we heard in a lecture hall about Assembler commands to shift the bits in the register of some old-fashioned 8-bit uC to the left or the right. Long lists of commands, one by one. For weeks. It was dead boring and I felt like my brain fell in some low power mode bypassing all informations, that entered my ears, right into the nirvana. When the practical tutorials started after some weeks, I was astonished how much I memorised about Assembler commands. It was quite easy and fun to solve the given tasks - at least for me.

So you might need some theoretical background to understand how you can get things done and some practical experience to keep things fun and interesting. Find the mix, that works best for you. I stick to theory, when I reach a point that I can't solve in praxis. And I return to praxis, when I get bored of theory. It's always a mix of both.

I heard that 8-bit controllers are a lot easier to use. I don't think so. The most simple uC is normally the uC you know best. And if a uC is not to your liking, you would usually not get to know it very well. So if you programmed 8-bit controllers for some time, if you know every register of you uC, know which Assembler command to use to shift the bits to the left or to the right, yeah than it is the easiest way to do things. To get used to something else might be a hurdle you don't want to take. I won't force you. But no, 32-bit uCs are not only suitable for professionals.

32-bit uCs can be as reasonable a choice to get started with, as 8-bit controllers can be. Every controller is complex, even a seemingly simple one. And the problems you might run into can be partially different, but they are not more difficult to solve.

If you use some small uC with limited resources and you projects get more complex, a lot of thinking might go in how you can save memory, processing time or get a good trade off. With a newer uC you might never reach these limitations.

If you use some newer uC, you might have quite the number of peripherals and it is not always easy to understand which one you should or could use for which tasks and how to do it. On the other hand a peripheral, that just does what you need, if you get a few configurations right, can make your life so much easier.

So what uC or uC-board to choose? It's up to you, but I have a few suggestions.

• one you fancy for some reason
  • maybe you saw it in cool projects, than it should be good for projects you like
• one that is widely in use
  • you will find more informations and projects featuring it
  • more people might already have run in the same problems you will and posted their solutions somewhere
  • there are more experienced people you can ask
  • many people might get stuck to it, because it is somewhat easy or comfortable to use
• an affordable one
  • it may get hand in hand with the points above
  • in the beginning there can always go something wrong (Why risking some expensive board?)
• one with features you need (if you know about it already)
  • maybe you need some interface like USB or CAN
  • or a lot of outputs (pins)
  • analog to digital converters (ADCs) to read in signals
  • digital to analog converters (DACs) to give out analog signals
• one with many relatives
  • there are whole families of similar uCs so you can always get a similar one with more memory, an interface you suddenly need and so on
  • you don't want to start from scratch with every project with slightly different requirements
• the one your friend uses
  • it's always good to have someone you can ask (And who doesn't like to talk about his hobbies?)

For a beginner many things point to a ready to use development board. Getting started with uCs is not all about programming. You need hardware that works. And the newer the uC is, the harder it gets to find it in a package that is somewhat easy to solder in your average workshop. As the packages get smaller and the pins get more, the pins move closer together. Sometimes most of the pin is under the package or you have a uC with ball grid mounting. An array of small soldering balls right under the package? Not something I could get done at home.

If you can solder the uC you like, you should still follow the manufacturers design guidelines. To get a ready to use board is far easier - especially if you don't have experience with circuit design. And you can be (almost) sure, that the manufacturer of these boards got the design right. Some mass produced boards are even far cheaper than you could ever get the parts in low number. And then you would still have to mount your parts on a board.

Again:

• use hardware widely in use
  • if something is wrong with it, you might find information about it and maybe some workarounds
  • mass produced things tend to be cheaper
    

If you have some special hardware requirements, a own design might sill the best solution. If done right, it will fit your project perfectly. If you feel confident, than go for it. You can learn a lot while you do your own design.

A uC without a program does nothing. Computers are stupid in a seemingly clever way. They do what you tell them to do. If you don't tell them to do anything, than they don't do anything. If you tell them to do something stupid, they do something stupid. It you tell them to do something that doesn't make sense, they do something, that doesn't make sense. If you tell them to do something, that doesn't work, they might do nothing. Or they do something unexpected. Or they overheat and generate some smoke. If you tell them to do something, that seems smart, they seem smart. That's how it is. So write them a program, that allows them to shine.

You heard a lot about artificial intelligence lately? Forget about it for now. AI is coming soon as long as I remember. You won't solve this riddle on your first uC-project. If you do nonetheless, you may tell everybody that it was all due to this "Why to..."

It's a matter of taste. Assembler is as close to machine language, as it makes sense to go for a human. The uC only knows 0 and 1 - endless confusing rows of zeros and ones. So programmers like to sum up 4 binary digits to on hexadecimal digit. But coding in hex is still no fun and out of fashion for a very long time. In Assembler each command the processor knows (as a row of zeros and ones) has a label that makes some sense to a human. And yeah, the commands processors know differ. So the Assembler you learn won't be assembled that way for all processors but for processors of the architecture you work with.

Using Assembler you must know and will learn a lot about the architecture. You can decide in whitch register the data are written before you process them with the ALU, you can calculate to the clock cycle how long your program will need to be execute some task. You can try to optimise it for memory or execution time or find a good balance. If you feel like you really want to understand in depth what your uC does, you can try out Assembler.

In C you have a set of commands, that works for each processor. The reason is simple: You don't write Code, that the processor can execute directly. A compiler will translate it for you. You get a binary or hex file, that you can load to the uC and will be executed. Modern compilers can optimise code more efficiently than most programmers versed in Assembler. You can decide on which criteria the compiler shall optimise it and change your decision by just changing the compiler settings.

The same holds for C++. It enables you to code on a more abstract level than C, but it doesn't force you to do so. You can do pretty much the same as in C, if you want. And when you code uCs you normally stick close to the hardware and try to code efficient and make good use of your resources. So not getting too abstract, might be a good idea.

The language I use in my uC projects is C.

Well, you need a toolchain. Your toolchain consists of the software tools you need. The Assembler will pretty much translate all you wrote one to one to machine language. There is not much of a toolchain needed. So let's see what you need, when you code in C or C++.

A text editor, since all program code is just text. It's nice if it comes along with a syntax highlighter supporting your language. The colours of terms are different according to their category. This way it is easier to see the structure of the code and to get what purpose the particular elements serve.

Some libraries to use. There are standard libraries for C and C++ containing functions that are often needed. So not every programmer has to write them anew. You can include parts you need in your project. If you need a mathematical function like sin() you can use the function from math.h, but for uCs there might be better solutions since sin() would take a lot of resources. There should be libraries for the processor family you use and your specific device.

Some libraries aim to enable more abstract programming with your uC and form a hardware abstraction layer (HAL). For the register addresses labels are defined, you can set BIT_5 instead of 0b0001000 or 0x10 and so on. It is still necessary to know a few things about your uC, if you want to write good code. There might be a program that makes it possible to make some configurations for your processor on a graphical interface and adapt the settings in the HAL accordingly.

You need a compiler, that translates your code to something the processor can understand. If you know, that code size is of more concern as execution time, you can tell it to your compiler and it will optimise the code accordingly and vice versa.

Since your software project will consist of more then one C or C++ files you need a linker, that links the compiler output from the different files to one executable.

A debugger to look inside your uC is of great use. For uCs debuggers also include a piece of hardware that can access the registers, stop the code during execution, look into variables,... via a special interface. This makes it a lot easier to find some nasty errors.

Do you need to get all those separately and somehow connect them? No, you can choose an IDE (integrated development environment), that brings all these things along. Again it's up to you. And again I have some suggestions:

• use an IDE widely in use
  • the community might be able to help, if you stumble upon some problem
  • most of the bugs might already be found and fixed
  • you might be able to find information about bugs not fixed yet and maybe some workarounds
• use a IDE supported, promoted and maybe even developed by the manufacturer of your uC
  • professional users might work with the same IDE and provide good informations
  • the developers should get informations from the manufacturer timely and integrate new stuff early on
  • the manufacturer is interested in providing tools, which keep his customers happy

Somehow you need to get your program to the uC. I use the debugger exclusively for this tasks. So I need a debugger. And I need to configure my debugging interface in all my projects. It is quite troublesome if I don't. I tried it out (erasing the memory under "under reset" helped). Some uC boards come along with a embedded debugger. You can just use the USB port oft these boards to debug and program.

Another way to get your program to the uC are bootloaders. They need an interface. During the boot up the uC checks if there is some computer connected, that tries to feed it with some new software. If not it jumps to the program already loaded to its memory (if there is one). So you need some pieces of software understanding each other on your computer and your uC. And you need some interface both can share. Maybe it works via USB. Otherwise you might need some USB to TTL device or something similar.

You want to make your uC interact with its surroundings. There might be one or two LED and one or two buttons on your uC board. But I guess playing around with those is not all you want to do with your uC. Breadboards are great for prototyping. When everything works you can maybe solder a nice PCB and put everything in a solid housing.

Before you use outputs, it is great to know how much current they can source. Before you use inputs, it is good to know how much Voltage they can handle. Whenever I want to use something new, I look in the documentation first and try to understand what I am going to use, how it works and what it's constraints are. I told you how I switch between praxis and theory. That's part of it.

And believe it or not: Documentation is helpful. After trying many things out, you might find your answer right under your nose in the documentation. There can be an application note describing something similar to the thing you want to do. There is the datasheet, there is a programming manual, ... I try to use them well.