In C

Real life has intervened yet again and made this post much later than I had originally intended. Nevertheless, here I am again, and this time I’m going to look at some actual code! Whoop!

In Lab 2 I followed instructions for downloading a simple program to the micro on the LaunchPad demoboard. I didn’t mention anything about that code at the time, but now here it is in all its glory:

Lab2 main.png
Figure 1. The Lab 2 “main.c” code as seen in Code Composer Studio

The code shown in Figure 1 is written in a computer language called “C” (yup, just that – the letter C).

C is an extremely common programming language which has existed, in more or less the same form, since the late 1970s. There is a very informative history of the C language at this link. C is versatile, powerful and ubiquitous and is used for a huge number of different purposes, not just embedded programming.

My first exposure to C came in 2007 when I joined a work-based project based around an embedded microcontroller. Sadly the project was cancelled two years later, but in that time I managed to teach myself enough C to not be completely clueless when viewing code like the example shown in Figure 1. Disclaimer: this does not make me in any way a C expert, though! The book I used to learn C was “C How To Program” by P. J. and H. M. Deitel, which I highly recommend.

I was subsequently involved in two more embedded programming projects which were also cancelled before they came to fruition. Although this was frustrating, the positive take-away was that I also gained some exposure to the Eclipse Integrated Development Environment (on which TI’s CCS is based) and the processes of editing, linking, compiling and so on, which I’ll come to in due course. I suppose that in revisiting this subject, I’m really putting together a lot of fragments of knowledge from earlier projects into a more coherent whole.

Returning to the main.c example shown in Figure 1, if this example of code in its existing format was somehow downloaded into a microcontroller, it simply wouldn’t work – the micro wouldn’t have a clue what to do with it. That’s because C is an example of a “high-level” language i.e. a language which is easily understood by a human programmer. In order for the program to be usable by the micro it has to be translated into the micro’s own “machine level” language. This is essentially a large collections of ones and zeros, and is known as “executable code”. The process of creating executable code is shown in a somewhat simplified form in Figure 2.

Code creation process.jpg
Figure 2. The process of creating executable code (somewhat simplified)

Note that a similar process would be used for other microcontroller architectures such as the Microchip PIC architecture . The techniques learned for programming ARM-based micros are therefore somewhat “portable” to other architectures.

Every C program has a “main” component, more properly known as a “function” and the main function is where the programmer’s code is written. In Figure 1, main begins at line 7, with the code to make the LEDs flash sitting between lines 9 and 21. As well as the main function, a few other pieces of code are needed in order to produce a working executable file which can be downloaded to the micro. These include:

  • Library files. Certain pieces of code will typically be used over and over again in many projects. It therefore makes sense to store these pieces of code in locations where they can be copied (or “linked”) into a project as and when required, rather than constantly re-writing the same pieces of code. So referring to Figure 2, the compiler turns the C files into object code, but that code has gaps in it where the library functions need to be inserted. the linker understands this, and where those code libraries are kept, and inserts the necessary bits of code before turning the whole thing into the executable .out file.
  • The startup file. This code sets up various parts of the micro’s hardware and converts it from an inert piece of silicon into a machine with the potential to do useful things. I will examine the contents of the startup file in a later post.

So there you have it – a brief explanation of the code creation process as I understand it, hopefully without too many errors. Please be aware that I am writing this stuff to document my own learning in this field, not to provide an authoritative explanation of the subject to anyone else. If you see mistakes, please feel free to point them out.

Next time: a closer look at what’s going on in main.


PS: The title of this post – “In C” – is also the title of a piece of music by the minimalist composer Terry Riley. I participated in a performance of In C many years ago. Here’s one example from YouTube.


Just press the button!

Spent the past few days working through Labs 1 and 2 of the Workbook I mentioned in my previous post.

Lab 1 is all about downloading and installing the various bits of software, including Code Composer Studio (CCS), needed to run the subsequent Labs. It also covers connecting up the demoboard and ensuring that the drivers install and the hardware basically works. A pretty lengthy process, but a necessary one and all done without any significant problem.

Lab 2 moves on to actually building a simple project in CCS, downloading it to the demoboard and checking it runs. It’s often the case when learning new software (or anything else for that matter) that in the early stages you just have to follow the instructions without understanding why you’re doing what you’re doing. You just have to press the buttons like you’re told and trust that all will become clear(er) later on.

The buttons may not always be red, though.

Everything was going swimmingly, or so I thought, until it came to actually building and running the project. Many, many error message! And none of them comprehensible to my untutored brain. At this point there are two possible courses of action:

  • Randomly fiddle with things in the hope of making it work.
  • Ask for help.

One of these is more useful than the other – can you guess which?

Part of the Texas Instruments ecosystem is its “E2E” Community. This is a large collection of forums, blogs and other resources specifically designed to help people learn about and use TI’s products. I signed up, read the rules and posted a request for help. Was pretty sure I’d get a response, but was astonished when it came within minutes of posting, and was from Ki-Soo Lee, the forum moderator and TI employee. That was impressive – all the more so considering that this service is completely free. You can see the full exchange here.

Turns out the problem was a subtle inconsistency between the workbook and the configuration of CCS as it appeared on my PC. I’d inadvertently told CCS to look for an #include file but specified a search path location rather than an actual file. I think. I have some familiarity with the concept of #include files from  previous work on C and PICs, but the implementation in CCS is still very new to me.  Anyway, got it fixed and everything worked as expected.

All for now – next time I may try to get into the workings of some actual code. In the meantime, if you like big red buttons you might want to visit this page.


TI LaunchPad

Well, hello.

It’s been a while… did you miss me?

That’s the thing about blogs, see: easy to start, not so easy to keep going.

But in my absence I have not been idle. Uh-uh. I done got me some learnin’.

You might recall, in my last post, that I’d found a cool CPD course on micros starting next September. I was also looking for more informal, non-academic training to do in the meantime, to get a head start on the subject. Did a lot of browsing around the ARM-based micro manufacturers and was starting to give up until I came across this.

I like this. I like it a lot. I like it because:

  • Texas Instruments. ‘nuff said.
  • There’s a full and extensive training course in the pdf workbook under the “Workshop Material” section near the end.
  • It’s based on inexpensive hardware (demoboards) readily available from, for example, Farnell .
  • The software is all free for personal/home/hobby use.
  • There’s a whole design/support ecosystem around these micros. This is exactly what Microchip have been doing so well for years with their PIC range.

So as you might have gathered, I’m going with this one.

Last time I searched for learning resources for ARM-based micros, which was admittedly a few years ago now, I didn’t see anything like this. So this is undoubtedly progress.

I don’t know about you, but if I’m trying to follow something in printed text I much prefer actual paper rather than an on-screen pdf. I therefore invested twenty quid in having the workbook printed out – all 330 pages of it – at my local print shop. Here it is, in a colour coordinated ring binder with the teeny weeny LaunchPad evaluation board.

LaunchPad and workbook. That’s a lot of paper.

In future I’m going to aim for shorter, more frequent posts as I work through this course. So – more later, and hopefully not too much later this time.


Studying Embedded Systems


OK, so. I want to learn how to program micros, and I’m looking for a micro and associated training material that will:

  • If possible lead to some kind of qualification that I can wave at a future employer
  • Allow home study
  • Use readily available hardware and software
  • Focus on programming in C (employers seem to want this)

Back in the day, pretty much the only way to earn paper qualifications (at least in the UK) was to attend  a college or university in person for a period of several years and hopefully come away with a recognised qualification at the end of it. The one notable exception was the venerable Open University, which was founded in the late 1960s specifically to allow students to follow a non-traditional, distance-learning route to higher education.

Pre-internet, the OU’s material was delivered using a combination of written material, television programs and occasional short residential schools. More recently, delivery methods have also included electronic media such as DVD and delivery over the internet. It’s a great system which has allowed access to higher education for countless thousands of people around the world who otherwise would not have had the opportunity. I studied a single OU module myself in the 1990s (on thermodynamics) and the standard was exceptionally high.

In recent years, more institutions have started offering courses which can be studied by distance-learning. In engineering these range from BTEC HNC level all the way up to MSc and PhD. A couple of examples here and here. Some also allow students to study individual modules from a course as part of a process of Continued Professional Development (CPD).

For my purposes I’m not looking for another full degree or masters course as I don’t want to commit to a likely three or four years of study. Instead I’m after something shorter which still offers some kind of recognised qualification at the end. This does “narrow the field” somewhat, but after a lot of searching I finally hit gold with PGCert option of this course. The University of Leicester’s  Postgraduate Certificate (PGCert) in  Reliable Embedded Systems takes four modules from the MSc program of the same name and lasts for a single year. Study is distance-learning with four one-week residentials and the cost is definitely affordable. Start date is September 2017 and I’ve already confirmed that the course will run this year. Perfect – exactly what I’m looking for! So unless things change significantly between now and September, that’s what I’m going to do.

Of course, that does leave me with eight months or so before September. I already have plans as to what I’m going to do with that time, and yes it does involve micros. More on that next time…


The ARM Business Model

In my previous post (I really have to think of some new ways to start new posts…) I looked at the two main micro architectures – PIC and ARM – and decided on ARM as being the one I would learn. That still leaves a lot of open questions, though, as there are many variations on the ARM architecture. Before I get on to that, however, I need to explain a little about the ARM business model.

ARM, the company, doesn’t actually make physical micros itself. Rather, it produces designs (AKA “IP” for “Intellectual Property”) for the core micro technology which are fabricated by other companies, from that IP, under licence. Each of those companies will add its own flavour of “special sauce” to the basic ARM IP to provide the end user with somewhat customised variants. So a micro based on the ARM “Cortex-M3” technology manufactured by Company A may be quite different from a micro based on the same technology made by Company B, and so on.

To use the car analogy again, it’s a bit like saying that ARM produce the designs or blueprints for engines which are then sold to the car manufacturers who tweak the designs a bit for their own needs, build the engines and install them in the finished vehicles. The key point is that ARM produce the basic designs – the IP – which are then turned into physical micros by other companies. ARM don’t make microcontrollers themselves. This is a very astute business model, as it relieves ARM of the burden of making silicon chips (a complex operation best left to people who specialise in that sort of thing), leaving ARM to concentrate on the thing they’re good at – designing microcontroller technology. This is explained far better on ARM’s website, and in a lot more detail at this link.

Several companies have licensed ARM’s IP for use in their micro product ranges, including Qualcomm/NXP/Freescale, Renesas, ST Microelectronics, Infineon, Texas Instruments, etc., etc., etc. Micros from these manufacturers are freely available for anyone to buy and use in their own finished products. So if I was a company making internet-connected toasters, for instance, it would be perfectly feasible for me to use a micro from one of the companies I’ve just listed in my latest toaster designs.

Incidentally, some of the bigger mobile phone/tablet/gadget manufacturers use ARM-based micros in their products and are big enough to manufacture their own custom versions. These include Apple, Samsung and Microsoft amongst others. These companies don’t, however, make their micros available for other people to use as far as I know. Incidentally, and I’m going off on a bit of a tangent here, if you take a look at this link you can see a summary of (some of) the various different end uses to which ARM IP has been put (right-hand column of the table). Remember me saying that ARM technology is used rather widely? And that list probably isn’t even up to date…

Lots of smartphones in the world, each using one or two ARM micros. That’s a lot of micros.

Anyway, back to the matter in hand… I haven’t counted them, but there are probably several hundred ARM-based micros on the market from the various manufacturers that I listed above plus others. So which to choose?

The point of this exercise is to learn how to program micros, so obviously whichever one I choose has to have some kind of training course or program associated with it – either from its own manufacturer or from a third party. Ideally, that course or program should:

  • If possible lead to some kind of qualification that I can wave at a future employer
  • Allow home study
  • Use readily available hardware and software
  • Focus on programming in C (employers seem to want this)

I think I hear Google calling… More soon!