Further into main


Welcome to the latest instalment of my blog!

This time I’m getting stuck into the main code, line by line, and working out how exactly those three LEDs are able to flash on and off all on their own…

There’s quite a lot of text formatting needed in order to make this post intelligible. WordPress isn’t the best platform for that sort of thing, so I’ve written up the majority of the post as a Word file, saved in pdf format. Not ideal, I know, but the best solution I’ve come up with so far. You can download it here:

Further into main

In writing this post I have had a strong feeling of fragmented bits of my existing knowledge coming together into a more coherent whole. Things that didn’t make sense before are finally now starting to make sense. I’ve tried to be as accurate as possible with my terminology, especially as it relates to the C language, as I feel this is a good habit to get into. But please feel free to point out any errors I may have made – that’s what the Comments section is for.

Just to reiterate, this blog isn’t intended to be a beginner’s guide to programming microcontrollers, or a definitive guide to C, or anything like that. It’s just a record of my personal journey into the world of embedded programming.

Until next time…




What I have learnt since last time…

Time to look a little closer at the Lab 2 main function. Here it is again, for reference.

Lab2 main.png

#include statements

Starting with the “#include” statements in lines 1 – 6, I mentioned in my previous post that some pieces of C code tend to be used over and over again, and so it makes sense to store those pieces of code in library locations which can be accessed by any program. When the compiler finds a reference to one of those pieces of code it simply goes to the appropriate library and copies over the relevant code into the program it is compiling. However, to do this, the compiler needs to know the name of the library file(s) in question, and this is where the #include statements come in. The “hash” (#) symbol is more properly known as the “preprocessor directive”, and the six preprocessor directives tell the compiler the names of the various library files it may need to access for successful compilation.

Files in angle brackets ( < and > ) are part of the standard libraries which are built in to the IDE whilst those in quotes are specific to the device for which the code is being compiled. These would be supplied by the device manufacturer and in this case would reside in the TI TivaWare C Series driver library.

By way of example, the function SysCtlClockSet (line 10) is found in the sysctl library, the GPIOPinTypeGPIOOutput function (line 12) is in the gpio library, and so on.

A few words on functions

I’ve used the term “function” quite a lot already without explaining what it means. So before we go any further, a definition:

A function is a pre-packaged piece of code which carries out a particular task or operation. Some functions are built in to the C language, and the programmer is also free to create his or her own functions or utilise libraries of functions written by other people. Functions can have parameters “passed” to them and can also “return” values.

The general format of a function is:

return-value-type function-name( parameter-list )





(from Deitel and Deitel, ch5, p152)

A simple illustration may make this clearer. In the following example, function “addtwo” takes two parameters (integers a and b) and returns the value of their sum, which is also an integer:

int addtwo( int a, int b )


int c;

c = a + b;




so if we “called” the function with the following statement

answer = addtwo(2, 5);

the function would add the numbers 2 and 5 together and assign the result (7) to the variable “answer”.

Note that functions need not necessarily return values or need parameters to be passed to them (many do not).

Note also that the integer variable c, defined within the function itself, is an example of a “local variable” A local variable is used only within the function and is not accessible outside of that function. You could not, therefore, go on to use the variable c elsewhere in a program.

This is a very simple example of how a hypothetical function might be used. The concept of the function is central to the C language, and is not something which I am qualified to explain in any great detail. For more information you might like to follow this link or consult the excellent Deitel book I referenced earlier.

The main function

Every C program must have at least one function – main – but main can also contain other functions and in general functions can be “called” (or executed) by other functions.

The structure of the main function can be seen to comply with the example described above. On line 7 the statement

int main(void)

shows us that the function’s name is “main”, that it returns an integer (or int) value and that no parameters are passed to it (“void”). The code which actually flashes the LaunchPad LEDs appears in lines 9 to 20.

There is some debate as to whether, in the context of an embedded system, it makes sense for main to return a value (return it to what?), but I’m really not going to get into that here. If you absolutely must, see this debate on StackExchange (amongst many others).

Further into main.

I had intended to now go into the details of the main function to explain how exactly it causes the three LaunchPad LEDs to flash in sequence. However this post is already over 700 words long, and so I think it better to start a new post on the internal workings of main. This has certainly been an interesting “refresher” for me, once again tying together fragments of knowledge from previous projects. Hopefully any errors in this post are not too egregious – feel free to point them out!

Until next time…