Let's Make Robots!

Let's learn the basics for robotics? With edX's "Embedded Systems - Shape The World"

Build real-world embedded solutions get and learn how to use a +40 I/O (16 PWM's) microcontroller board for $12, lab-based course.
ServoMotorbyPWM_and_TM4C123.zip597.9 KB
ServoMotorbyPWMADCpotentiomenter.zip1.3 MB

Do you want to learn real robotics from inside?


UPDATE 25-May-2014: videos about servo control by potentiometer and automated successfully!

Here is the video for the manual test on PWM control for a servo motor. Here is also the video for automated test for PWM control for a servo motor, this second test is with two speeds: one is slow to see movement, the other is downloaded to the board on the fly to see the fast automated movement.


UPDATE 24-May-2014: servo control by potentiometer successfully!

The Course is done and over. We received our edX certificates already (I passed it with 100% but I have to recognize it was hard but very satisfactory):

Francisco Dominguez Honor Code 100% Certificate.Embedded Systems - Shape The World-UT.6.01x

It was great and most of us learnt a lot. It's time to move on and do some nice things with all the technology and techniques we have learnt. Controlling servos is a good start for the next robot I think...

Yes I know control a standard servo by a microcontroller is not a great issue, however it looks like it's not that easy for Tiva C boards, TM4C123 board in my case. I tried to find a simple driver in C for the Keil programming environment (the one from the course) to control a servo with my microcontroller board but I only found a handful ones in CCS (Code Composer Studio) or not useful ones: they gave me many compiling errors so they were not useful. I found also many people trying to control a servo with this new type of boards but they have had many issues...

So I started from an original demo routine to handle two PWM outputs from Dr. Valvano (Course's lecturer) and changed it to move just one servo motor. After several days and a great help from a Texas Instruments' employeeAmit Ashara I could do it. Here you have the software in case you want to have a look on it.

But, why not using las Lab 14 with a potentiometer and display to handle the servo by hand? Said and done! Here is the project files to do it. If you didn't see above, here is the video for the manual test on PWM control for a servo motor. Here is also the video for the automated test for PWM control for a servo motor, this second test is with two speeds: one is slow to see movement, the other is downloaded to the board on the fly to see the fast automated movement.

Lab 14 timing for input was fine for Nokia display but too slow for the servo: there was a delay of 1 second between potentiometer and servo movement. So I accelerated Nokia refresh and now servo follows potentiometer movements as fast as they happen. I also see on the display the actual position of potentiometer, what is fancy anyway to check that everything is fine ;-)

Next things to do are: controlling more servos also getting more input sensors to give senses to the new robot...


UPDATE 11-May-2014: Lab14 completed successfully!

This is the last graded Lab for this Embedded System course, this is a wonderful practice on Analog to Digital Conversion (ADC). There is another more Lab 15 about a "Space invader" little game with this Embedded platform.

As I said in this Lab we study the great and necessary world of the ADC, as many of the variables that influence our lives are analog, and with this techniques we can measure them, and later influence on them. From this lab we can build more complex systems for robotics systems, like measuring distance, temperature or light.

To enjoy the whole experience here are the requirements for this actual Lab 14:

"In this lab you will design a distance meter, composed by:

  1. A linear slide potentiometer converts distance into resistance (0 ≤ R ≤ 10 ). 
  2. Your software will use the 12-bit ADC built into the microcontroller.
  3. The ADC will be sampled at 40 Hz using SysTick interrupts. 
  4. You will write a C function that converts the ADC sample into distance, with units of 0.001 cm. 
  5. That data stream will be passed from the ISR into the main program using a mailbox, and the main program will output the data on a display. 
  6. The display is optional."

All these tasks sound hard, but some are easier than other. Let's see from the technical side. This lab has these major objectives:

  1. an introduction to sampling analog signals using the ADC interface;
  2. the development of an ADC device driver;
  3. learning data conversion and calibration techniques;
  4. the use of fixed-point numbers, which are integers used to represent non-integer values;
  5. the development of an interrupt-driven real-time sampling device driver;
  6. the development of a software system involving multiple files; and
  7. learn how to debug one module at a time.

My experience on this lab was very satisfactory, from the software side it was only hard for the conversion side when we have already the value. The hardware side was very easy. I added from myself a 330 ohm resistor to restrict power consumption (and bright) on the Display, and a little 0.01 uF capacitor to filter some glitches, and so gaining stability in the analog input.

The response of the whole system is very stable and linear, as you can see in the youtube video, even they are cheap components and a not very complex design. I'm very impressed about the whole solution and its scalability.

Lab 14 Real Board. DAC and Data Acquisition - Embedded Systems

Lab 14 Real Board. DAC and Data Acquisition - Embedded Systems

From here I'm planning to test some analog sensors I have like a infrared distance meter, also a ultrasound distance meter, to use them in my next robot. Let's see ;-)

Lab 14 Simulation. DAC and Data Acquisition - Embedded Systems

Capture of Lab 14 Simulation. DAC and Data Acquisition


UPDATE 4-May-2014: Lab13 completed successfully!

Well this Lab was really hard. It has not only interruptions, but also calls to different functions, programming in C and even tone conversions. Finally we have a simple but effective digital piano that sounds... well it's better if you check it in the attached video I recorded. But beware! Sound quality is not good as I used a simple opamp 741 and my PC as sound amplifier ;-)

So, in this Lab lecturers asked us to:

"Most digital music devices rely on high-speed DACs to create the analog waveforms required to produce high-quality sound. In this lab you will create a very simple sound generation system that illustrates this application of the DAC. Your goal is to create an embedded system that plays four notes, which will be a digital piano with four keys.

  1. The first step is to design and test a 4-bit binary-weighted DAC, which converts 4 bits of digital output from the TM4C123 to an analog signal. You are free to design your DAC with a precision of more than 4 bits. The simulator supports up to 6 bits. 
  2. You will convert the digital output signals to an analog output using a simple resistor network. 
  3. During the static testing phase, you will connect the DAC analog output to the voltmeter and measure resolution, range, precision, and accuracy. 
  4. During the dynamic testing phase, you will connect the DAC output to the scope to see the waveform verses time. 
  5. If you connect the DAC to headphones you will be able to hear the sounds created by your software. It doesn't matter what range the DAC is, as long as there is an approximately linear relationship between the digital data and the speaker current."
As I wanted to hear the generated sound a bit lowder I looked for a little amplifier with components I had in my little electronics bag: a 741 general OpAmp, so I found this funny schematic and with some capacitors and resistors I did it:
Lab 13 small amplifier based on a 741 OpAmp
Lab 13 small amplifier based on a 741 OpAmp
It sounds lowder enough now to reproduce the sound with my PC, that it aplifies it so I can record it with my mobile meanwhile I record this video showing my test of the real board DAC system. It works great!
I have to say I have suffered in this Lab more than others, due basically it's necessary to control several subroutines from a main routine, that's usual in C language, but I was used to perform simple tasks in my former microcontroller's and microprocessor's projects. However, as C language is still so necessary in Embedded Systems and other technical solutions, I think it was a great chance to improve my programming skills, and it was! After some hours studying the problem to solve and some programming techniques I managed to do the whole project.
It this lab the main routine is checking the switches all the time, i.e.: calling the "piano" function which actually recieve inputs. If there is an input, then the period (frequency of the note to perform) of the wave is fixed: C, D, E, G (Do, Re, Mi, Sol in Spanish music notation).
Just after that, the sound generation function is called, so it gets the period (tone) and generates the wave though the Digital to Analog converter or DAC. Actually the DAC is just a group of digital outputs tied together with some resistors, so when you activate those digital outputs in a certain way, a voltage value is generated. You can then amplify that voltage and have a loud sound. If you change values fast enough in that DAC you have a kind of sound and maybe even music ;-) That's the basis of digital music!

Lab 13 call graph showing the three modules used by this digital piano

Call graph showing the three modules used by this digital piano

It sounds pretty scary isn't it? Well, it was! I had many problems to implement all the functions together, later to test that tones worked in the right frequency, and finally to work well with the physical DAC.

Lab 13 this figure shows a data flow graph for this digital piano

This figure shows a data flow graph for this digital piano


Samples for DAC synthesis

Calculating in MS for Samples for DAC synthesis


Lab 13 tone table for DAC synthesis

Tone table for DAC synthesis


Lab 13 screen capture of simulation on DAC synthesis

Lab 13 screen capture of simulation on DAC synthesis


UPDATE 21-April-2014: Lab12 completed successfully!

First, I have to advise you: keep reading until the end because it even a has a free oscilloscope, a DC motor control with PWM and a Robot Car! ;-)

 Ok, so now my thoughts so far... Lab 12 is not as hard as Labs 10 or 11, however there are some tricks you have to realize in order to solve it successfully.

I had some of this "happy ideas", but there was one that was specially hard, so i had to ask in the course's forum also in our particular Facebook's forum for Spanish people and I manage finally to solve it. Thanks to some tips from students and an instructor. 

I think MOOCs are not just a way to learn hard stuff for free, or even gain some University's certificate, but to learn soft skills like team working in an online environment, which is very common nowadays in many companies, also to solve hard both technical and business problems together, not just alone as formal and traditional studies do.

This course show us also why Arduino platform is so strong now. It's not the hardware or the software, but the healthy community of developers that share and help to each other, that enriches and integrates anyone that want to learn and experiment with these systems. In this way Texas Instruments has a very good help with this course and Mr. Valvano Professors Yerraballi and Valvano.

Ok, so after my strange thoughts here is the Lab 12:

"In this lab you will make a square wave sound at 440 Hz, which is a standard frequency created by a tuning fork. You will interface a positive logic switch as the input, and you will interface the headphones as an output. A resistor placed in series with the headphones will control the loudness of the sound, see Figure 12.1. Any value between 680 Ω and 2 kΩ will be OK. Selecting a larger the resistor will make the sound quieter. Please do not leave this resistor off entirely."

Lab 12 video testing Real Board for Interrupts

Ok, so the programming part is not very difficult as in Chapter 12 we see some similar examples. I had to tune it and change some little things about managing the input and output with the hardware.

The hard part is the coordination between interruption and my main task of detecting when the switch is pressed once or twice. Why? Well, the whole Lab 12 is about it. It should work as follows:

  1. Everything is off: both switch and speaker.
  2. Press switch once and speaker generates a 440Hz sound.
  3. Press switch again and speaker gets silent.

It looks easy but it's actually difficult because:

  1. It is a real-time process: at the moment you press the button the system has to react.
  2. It is a time-strict system: the sound must be 440Hz, a precise tone that if you don't handle with interrupts can very greatly. Just to frame it: if you try to do it with a regular Windows operative system you can expect a 5-10% error in that frequency: you can get 396 to 484 Hz tone. That's too much error in some applications like sound processing, control systems and so on.
  3. It is a features restricted system: you just use a button to operates everything.

Another surprise in this Lab 12 is that we have an oscilloscope in our arsenal's course! It's great to have that tool that's so useful to see how your system works in real time, watching a picture of the generated wave. The way to operate this oscilloscope is very intelligent:

  1. Use an analogue input from the real board to measure the analogue value. It uses one of the Analogue to Digital Converters that this board has at 10 kHz, what is enough for this Lab.
  2. get that sampled values from the board to the PC through the USB and a virtual COM port with an UART operation.
  3. Picture the values against time with the software they developed for this course: TExaSdisplay. That works great to show the graph. Here you have an example:


Lab 12 video - Built-in oscilloscope - testing Real Board for Interrupts

I had a little final issue when grading with the real board (grading in simulation was 100% fine at the first attempt). So as I explained before, after some wanderings around course's forum I solved it. And voilá! Now we know how to handle interruptions with this wonderful board.

In this chapter we learnt how to handle a DC motor in PWM on the hard way: generating the PWM signal by interruptions. Yes, this board has its specific 16 PWM outputs, but it's always great to know how to create it in a flexible way so you can manage different PWM configurations. We also saw a application of this concept with a real Robot Car!

Lab 12 tips for building a Robot Car


Lab 12 a Robot Car with DC motors controlled by PWM

These are just screen captures from the videos inside the course. If you want to see the full videos or event the hardware and software details just enter inside the course website, it's free and full of tips. I know, the whole Robot Car is too basic for this website, but remember: we are learning the basics so later we can develop whatever we want! ;-)


UPDATE 12-April-2014: Lab11 completed successfully!

This Lab11 was a real pain. It was about programming in C for strings management basically, to change between types of data like these real questions from the lab:


// Output String (NULL termination)

// Input: pointer to a NULL-terminated string to be transferred



// Converts a 32-bit number in unsigned decimal format

// Input: 32-bit number to be transferred

// Output: store the conversion in global variable String[10]

// Fixed format 4 digits, one space after, null termination

// Examples

//    4 to "   4 "  

//   31 to "  31 " 

//  102 to " 102 " 

// 2210 to "2210 "

//10000 to "**** "  any value larger than 9999 converted to "**** "

In the middle there is a hardware transmission of data using an UART communications interface at the real board, which is useful to learn, as many actuators and sensors in robotics have serial communications for distributed control. They can be more advanced ones like I2C, or even USB, but learning from the basics with UART is great.

Hoewver handeling with C language and strings from previous and much more simplier Labs make it very difficult, as I saw it by myself also for other people in the course's forum.

Now let's keep going for the Lab12 as I'm already 1 week late but on the right way ;-)


UPDATE 6-April-2014: Lab10 completed successfully!

Ok, it's a long time from last edition, but I have to agree that coping with job, family and study this course is a "bit" challenging. The 10 hours/week of estimation for this course is completely optimistic as some other students were commenting on the course's forum. But I swear all this time is worth it, keep reading and you'll know why ;-) Or you can jump straight to the video here.

After some hours, tests and developments here is my feedback of this Lab10, 2 weeks later than expected, but hey, still doing and fine.

So what is the whole output until now? Well this course is so well designed that, with enough effort you can not just finish off these labs, but you learn deeply about embedded systems (the brain on robotics) and get fun. However we have to admit it can be not only a challenge, but also very difficult for people that don't know anything about electronics, even worse if didn't develop a computer program before. Yes, you have very good introductions for electronics, programming on C and so on, but came on, learn all this stuff and manage to cope with the crazy rithm that has this course is a real challenge.

At the same time, we learn how to manage a very fast and reliable system, that is capable of handling many inputs and outputs on real time: what else can ask a robot's hobbyist for?

So, here is my lab10:

First of all it is a real application on finite state machine using a microcontroller.

The aim for this lab10 is to develop a traffic cross managed by two sets of traffic lights: one for north-south direction and one for east-west direction. There is another set of lights for pedestrians. Here is a diagram about it:

Lab10 aim is to develop a traffic cross managed by three sets of traffic lights

It looks quite simple, but teachers create a very good way to teach us how to manage three major objectives: 

1) the understanding and implementing of indexed data structures

2) learning how to create a segmented software system

and 3) the study of real-time synchronization by designing a finite state machine controller. 

Software skills to learn include advanced indexed addressing, linked data structures, creating fixed-time delays using the SysTick timer, and debugging real-time systems.

Impressive, isn't it? Well it is actually. It's so hard that there were many questions in the course's forum, even myself, I had to ask about an issue regarding input-output, that was not that difficult after a colleague told me a "hint" (not the actual solution) through the forum. This is also about team working, the way to solve engineering problems in real life.

First we had to decide which ports we want to use for the Lab. Then came the actual design of the behaviour of the system. I draw a State Transition Graph like this to solve the system asked to do:

Lab10 State Transition Grap for Traffic Lights system

Circles are states: a stable system's situation, with definite outputs. Arrows going out from states are state's changes produced by changes on system's inputs. Arrows comming from other states are also transitions triggered by inputs. As the whole system is too long to explain here, I recorded a video testing it with the real board, so you can have a better idea of how it works in real life. If you experienced a traffic light cross before you already know quite well ;-)

Then we need to develop a "State Transition Table": a tool in form of a table where there are explained all states possible for the system, its inputs, outputs, delays and next states. Mine looks like this:

State Transition Table for Lab10 Traffic lights control system

These two steps (graph and table) are very straight forward yet powerful tools to develop and test complex systems before you actually start to program them. This saves a lot of time of development, also give enough chances to check, modify and maintain the final solution.

Then comes the task of programming the system. We have some code to start, however this time is different than other labs before. There are several programming tasks we have to take from former labs, assamble them in the right order. Check and configure inputs and outputs in the right way. Then define states, some outputs more and check that everything runs fine. There are so many things that can be wrong that chances of faillure are 100% the first time you check. But this is the right way to learn how to develop a real system. To correct issues you have to learn in deep how the system and all its parts work. That's the right way to learn real stuff ;-)

The best part is, when you simulate the system and it works 100% fine, then you know it will work fine in the real board, and that's good. Here is my real board with some electronics for the actual traffic lights and buttons:

Lab10-My real board with some electronics for the actual traffic lights and buttons

And finally the test was fine. You have the video above or at Youtube: Lab10 Embedded Systems Real board test Traffic lights. The satisfaction of finishing the whole system has not price. For everything else... you know what ;-)


UPDATE 17-March-2014: Lab9 completed successfully!

Well this Lab9 was a bit harder in the programming way, as there were some inputs to test also the state of an output , with timing and storing data in microcontroller RAM... all together sounds a bit difficult, and it was but doing step by step and with the former lectures and labs it's a bit easier. Let's see:

The whole aim of this lab was:

  1. If both PF4 and PF0 switch (main two switches) are not pressed, the PF1 (Red LED) output should be low.
  2. If either PF4 or PF0 switches is pressed, the output toggles at 10 Hz (±10%).
  3. Information collected in the Data array matches the I/O on PortF.
  4. 50 data points are collected only on a change in input or a change in output. (i.e., no adjacent elements in the array are equal). This is the final target for this Lab: to store process information when we want to debug and prove that the system is running as we want to. And to know what is going on in the system if it's not working right. you can think this data is like a black box from a plane: it stores precious information for future investigations.

It sounds a bit challenging so let's divide it step by step:

  • reading PF4 and PF0 switches and activating PF1 (Red LED): we did it already in a past Lab.
  • decide whether to toggle or not the output: it's a decision branch we did already too.
  • collect information in array: it's the first time we do it but the software for the lab brings it already, so nothing to do on it. Well, just to pass the right values but we did it in a past lab. Only a small change on GPIO_PORTF_DATA_R is needed to address the righ data to store.
  • 50 data points collected when a change in input or a change in output: it's also a decision branch we did already.


Logic analyzer output showing PF1 toggles at 10 Hz whenever PF0 or PF4 is low.  If both PF0 and PF4 are high, then the output PF1 should be low

Kiel uVision4 IDE with Logic analyzer and output showing PF1 toggles at 10 Hz whenever PF0 or PF4 is low.

If both PF0 and PF4 are high, then the output PF1 should be low.


So we did already most of the programming or it's already in the software for this lab. So, where is the hassle? Well:


  1. first we have to adapt the former lab's software parts to meet these inputs and output. addressing the wrong address means not doing right. Declaring the two inputs is easy but you have to do it.
  2. second we have to change the LED's toggle frequency, just to the double it's already. If you gave attention to Lab8 you know how to do it.
  3. third you have to toggle the LED when PF4 or PF0 switches is pressed. Easy.
  4. forth you have to AVOID to let the LED ON when PF4 or PF0 switches are not pressed. That was the difficult part, as it is a negative condition of an OR operation AND LED should be ON. After you realise this, it's easy to do.


So after an hour and some minutes of programming and testing (debugging) I finally did it work right. Lesons learnt from this Lab are useful to handle and decide with several inputs/outputs also to debug the system. When you design a robotic system all these tasks are basic and multiplied to a factor bigger than two or three. So good to start learning them from small ;-)

UPDATE 8-March-2014: Lab8 completed successfully!

This lab 8 was not very difficult to me as I'm used to handle with electronic parts, circuits from prototypes to manufacturing. From the software point of view this lab was a small improvement from last both 2 and 6th labs.

However this the first lab where we interact with the "real" world in the way that we read the status of an external switch and we toggle an external LED. We use a protoboard, two resistors and some little wires to do it. You can see the result in the video "Testing board on Lab 8 "SwitchLEDinterface" for EdX Embedded Systems course".

Here there is a complete lab's description:

"Overall functionality of this system is similar to Lab 6, with five changes:

1) the pin to which we connect the switch is moved to PE0,

2) you will have to remove the PUR initialization because pull up is no longer needed.

3) the pin to which we connect the LED is moved to PE1,

4) the switch is changed from negative to positive logic, and

5) you should decrease the delay so it flashes about 5 Hz. To flash at 5 Hz means the LED comes on 5 times per second. If the switch is pressed we turn on the LED for 100 ms, turn off the LED for 100 ms, and repeat 5 over and over."

As the labs before I like a lot the steps to do the whole project:

  1. design procedures in a high level way (top-down engineering), 
  2. then define routines to perform those functions,
  3. design the software and debug in emulation (only PC).
  4. when OK, then download the software and debug in the real board with external switch and LED. This step is just a check as if the step before was OK this will work fine.

Please note: its not about a switch and a LED, but about how to design, test and prepare a system to an entire life cicle, aka: Product Management. The more complex the system is, the wider the team has to be to cope with all the different specifications, technologies and tasks involved.

Here there is a screen capture on the simulation with signals from the emulated switch and LED part:

Lab8 Embedded Systems edX. Screen capture on the simulation with signals from the emulated switch and LED

As a refinement detail, I saw a connection map for the development board in a lecturer's video, so I prepared mine that is here:

Printable REAR connection map for Tiva Launchpad ek-tm4c123gxl(Embedded Systems edX)_by@Franciscodr

Printable rear connection map for Tiva Launchpad ek-tm4c123gxl(Embedded Systems edX)_by@FranciscodrAnd here is how it looks like on my board, as you can see it's the rear part where there are the two female connectors that make easy to connect the wiring:

Picture of Tiva Launchpad ek-tm4c123gxl with rear connection map for (Embedded Systems edX)_by@Franciscodr

The truth is that this little map helps a lot when you are mounting a design as the labels on the board are too small.

Note: there is also a version of the front side that I let here: Printable FRONT Tiva Launchpad ek-tm4c123gxl connection map


UPDATE 2-March-2014: Lab7 completed successfully!

Well this lab 7 was not so hard, however there were some little tricks about it.

The main task was about tuning an actual program to make a SOS signals when a switch was pressed. Modifications imply changing the colour of signal (change of address of bits and number of output bits to handle), also input bits: both instead of only one. Also the timing of SOS was a bit different. 

So the final system has to do this:

"1) Make PF1, PF2, and PF3 outputs. (three bits that handle colour of a three-colour LED on the real board)

     Make PF0 (SW1) and PF4 (SW2) inputs (enable PUR for PF0 and PF4). (Two of the switches on the real board)

2) If either SW1 or SW2 are off, the LEDs should be off.

    If both SW1 and SW2 are on, the SOS is sent on the yellow LED

            a) Send an ‘S’ as short short short pulses on the yellow LED

            b) Send an ‘O’ as long long long pulses on the yellow LED

            c) Send an ‘S’ as short short short pulses on the yellow LED

            d) Wait 4 seconds

3) Repeat step 2 over and over.

After thinking and trying a bit the solution was realised. Here is the screenshot debugging the project:

Logic Analyzer at Lab 7 (SOS system) for EdX Embedded_Systems course

This chapter was very interesting, mainly about software engineering: how to design a system with Embedded solution, Product life cycle and quality design. All aiming to develop better solutions, not just solving a problem, but to maintain it and make it possible in team or with yourself after several months. As we know programming is not very straight forward, even less when the software is not well documented. Deciding about opposite constrains and ways to solve the system were also interesting in this chapter.

Above all, I see that this course is not just about how to handle a microcontroller board, but also about how to develop solid Embedded Systems, easy to maintain and work with.


UPDATE 23-February-2014: Lab6 completed successfully!

Ok, so after a hard weekend trying to make a LED toggle when pressing a switch I did it! Attached there is a small video about it.

The whole program has to do this:

  1. Make PF2 (3rd bit at Port F, where there is a blue LED in the board) an output and make PF4 (5th bit at Port F, where there is a switch in the board) an input (enable PUR for PF4). 
  2. The system starts with the LED ON (make PF2 =1). 
  3. Delay for about 100 ms
  4. If the switch is pressed (PF4 is 0), then toggle the LED once, else turn the LED ON. 
  5. Repeat steps 3 and 4 over and over.

I have to say Lab 6 was harder than I expected, not because the microcontroller special way to handle inputs and outputs (that it is harder than in a old PIC microcontroller or a MOS 6502 microprocessor or even a Motorola 680000 microprocessor), but this lab is harder because programming in C is critical for this topic as you should imagine, and my C programming skills are not at its best after some years without programming on it. However I take this course also to refresh my C and I think it's a good chance.

But don't take me wrong, handeling inputs and outputs in a Texas Instruments TM4C123 microcontroller (ARM Cortex M4 processor inside) is not easy. You have to do some special steps before you send/read any signal to/from any port pin. That makes harder to code and debug any program. For example, if you want to turn on a LED, you have to do these steps in this AND only this way:

"To initialize an I/O port for general use we perform seven steps. Steps two through four are needed only for the LM4F/TM4C microcontrollers:

  1. First, we activate the clock for the port.
  2. Second, we unlock the port; unlocking is needed only for pins PC3-0, PD7, PF0 on the LM4F and TM4C.
  3. Third, we disable the analog function of the pin, because we will be using the pin for digital I/O.
  4. Fourth, we clear bits in the PCTL (Table 6.1) to select regular digital function.
  5. Fifth, we set its direction register.
  6. Sixth, we clear bits in the alternate function register, 
  7. and lastly, we enable the digital port. We need to add a short delay between activating the clock and accessing the port registers. The direction register specifies bit for bit whether the corresponding pins are input or output. A DIR bit of 0 means input and 1 means output."

In programming language (C) it looks like this:

// Subroutine to initialize port F pins for input and output

// PF4 is input SW1 and PF2 is output Blue LED

// Inputs: None

// Outputs: None

// Notes: ...

void PortF_Init(void){ volatile unsigned long delay;

  SYSCTL_RCGC2_R |= 0x00000020;     // 1) activate clock for Port F

  delay = SYSCTL_RCGC2_R;           // allow time for clock to start

  GPIO_PORTF_LOCK_R = 0x4C4F434B;   // 2) unlock GPIO Port F

  GPIO_PORTF_CR_R = 0x1F;           // allow changes to PF4-0

  // only PF0 needs to be unlocked, other bits can't be locked

  GPIO_PORTF_AMSEL_R = 0x00;        // 3) disable analog on PF

  GPIO_PORTF_PCTL_R = 0x00000000;   // 4) PCTL GPIO on PF4-0

  GPIO_PORTF_DIR_R = 0x0E;          // 5) PF4,PF0 in, PF3-1 out

  GPIO_PORTF_AFSEL_R = 0x00;        // 6) disable alt funct on PF7-0

  GPIO_PORTF_PUR_R = 0x11;          // enable pull-up on PF0 and PF4

  GPIO_PORTF_DEN_R = 0x1F;          // 7) enable digital I/O on PF4-0



However, once you manage it, it's easy to handle the inputs and outputs, and having so many of them opens many possibilities for new projects. As a last thing, it's good how in this course they show us about debugging. You realize with these tasks that debugging is a very important part of developing any system.

They teach us in this lab how to use the Logic Analyzer (also able to handle analogue inputs/outputs) that is also included in the free Keil software package used to develop, test and download the software for the board. Here you have a screen capture testing this lab:

Logic Analyzer at Lab 6 for EdX Embedded Systems course


UPDATE 16-February-2014: Lab5 completed successfully!

I just finished Lab 5 (2 days later but with many things to do during the week I think it's OK ;-)

I found this Lab5 easy to do, however there are many different students in this course and I understand lecturers are trying to make everybody can cope with the course's path.

This week there were some basic topics from programming in C language, to learning algorithms for decisions that are basic for any robotic project as we expect to do in the near future.

Now I'm looking forward for 6th part, let's see if I have enough time this week for it ;-) See you around and keep going!

UPDATE 8- February-2014: Lab2 completed successfully!

I know some of you have done already Lab2 and are going much more forward, but in my case I have little spare time for this, so I have just finished my Lab 2 and everything has being fine. Look at the funny picture with IDE developement software running:

Lab 2 OK on edX's Embedded Systems - Shape The WorldI have to say that this is my first electronics lab experience in a MOOC and it was really fine. They worked hard not jus on the theory, but also on the practical tutorials, videos and software. Well done!


UPDATE 22-Jan-2014: you can enter in the course here:


UPDATE 23-Jan-2014:

We could see from the very first day what is inside this course awaiting for us: learning from the beginning, microcontrollers, electronics, programming (from basics to more advanced C programming), and finally building some interactive and robotic projects if we want to! So let's move on!

Here is a screenshot where the lecturers (RAMESH YERRABALLI and JONATHAN VALVANO) show us from the beginning what we can learn in the labs (45% labs simulations + 45% labs running on the real board! + 10% quizzes):

Introducing Video Kit and Lab Solutions for UT.6.01x Embedded Systems - Shape the WorldIntroducing Video Kit and Lab Solutions for UT.6.01x Embedded Systems - Shape the World


Then you need to learn how to design and program Embedded systems

Do you want to learn it from inside and get a +40 I/O (16 PWM's) microcontroller board for $12? Came on you'll get a lot! (See list of board's features below).

It's easier than you think! And you know already what you need for it:

  1. What you want to accomplish: the target for the programmed system, a funny or useful robot for example.
  2. Logic mind: if you can read, write and sum up, then you have more than half of what you need.
  3. Some dollars and hours to watch some videos and test some online and physical circuits.

They provide you a proven path to learn how to build the electronic circuits, program, and test them. You will have colleagues like myself: yes I'll do it! This is the proff ;-)


Let's make robots and edX's Embedded_Systems_-_Shape_The_World-ut.6.01x by Franciscodr


So I let you here the course's introduction that is in its website, and I see you there besides that here in http://letsmakerobots.com

(If you are wandering, I'm just a studend for that course, so let's meet here?)

About this Course

How do they do it? If that is your reaction every time you see an electronic gadget you like, then wonder no more. Join us on a journey that will unravel how these electronic gadgets are designed, developed, and built as embedded systems that shape the world.


Example of lab for Embedded Systems - Shape The World-ut.6.01x


This is a hands-on, learn-by-doing course that shows you how to build solutions to real-world problems using embedded systems. Each student will purchase a Texas Instruments TM4C123 microcontroller kit and a few electronic components. This microcontroller has a state of the art ARM Cortex M4 processor. The course uses a bottom-up approach to problem-solving building gradually from simple interfacing of switches and LEDs to complex concepts like display drivers, digital to analog conversion, generation of sound, analog to digital conversion, graphics, interrupts, and communication. We will present both general principles and practical tips for building circuits and programming the microcontroller in the C programming language. You will develop debugging skills using oscilloscopes, logic analyzers, and software instrumentation. Laboratory assignments are first performed in simulation, and then you will build and debug your system on the real microcontroller. At the conclusion of this course you will be able to build your own arcade-style game.

We will provide instructions about purchasing the kit and installing required software via the course website

And be sure to connect with us on Facebook, Twitter, and Google Plus!

EK-TM4C123GXL board's key features:

Key Features

32-bit ARM Cortex-M4F core 40 pin BoosterPack Connector
Features on-board emulation, which means you can program and debug your projects without the need for additional tools  


80MHz 24x Timer/Capture/Compare/PWMs
256KB Flash 3x Analog comparators
32KB RAM x SPI/SSI, 6x I2C, 8x UART
On-chip ROM with drivers and boot loaders 2x CAN
2x 12ch 12-bit ADCs (1 MSPS) Low-power hibernation mode
16x Motion PWM channels 43x GPIO pins
24x Timer/Capture/Compare/PWMs  

Part Number


Featured Microcontroller

Enhanced by Zemanta

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Hi Photolong,

You were fast! Congratulations for fixing the issue!

I have also some problems to adjust the reading numbers and the actual distance to send to the UART_Convert function. So after some try and errors I found this empyrical formula:

Distance=((((LeerDato())*3000)/2047))*0.965-10; // Calibration for my 6 cm potentiometer

(LeerDato = ReadData in Spanish language ;-) )
So actually "LeerDato" is an interm function to filter quantification noise, and is like this:
unsigned long LeerDato(void) {
 unsigned long result,sum=0;
int i;
    for(i=0;i<128;i++){   // 2048 means result=sum>>11
 ADCdata = ADC0_In(); // Get Analog input from acquisition function
      sum += ADCdata; // Adds value from Analog input
      result=sum>>7; //As this for iteration gets 16 values we have to move 4 bits result to the right
              // If we want to add 128 values for the mean, we have to move result 7 bits to the right
return result;
And it works really great! (I had some help with that last code from some folks in our Facebook course Group :-) ).
Later on, I use the same value to manage my servos (just if you were wandering):
  PWM0Dual_Period(((Distance*0.9455)+2050),0);           // 4833 input = 0º (middle) position for servo motor
As you can imagine 0.9455 is the slope of the line and 2050 is the zero adjustment. for any "Distance" variation that formulae calculates the needed PWM duty cycle to generate the % step, from 0 to 180º.
Servo position    in Degrees Calculated input values for         the PWM function
0 2050
45 3466
90 4833
135 6199
180 7565
1 degree 30
Well, if you are curious you can check my PWM project code that I attached above these comments ;-)
I can now control 3 servos, but I found that disablying dead-band in the PWM modules of our microcontroller, each PWM output can work independently :-) But I'm fighting with the TivaWare C APIs :-)) :
I'm doing that because I see with those API I can manage more of this microcontroller and develop faster. But I have to learn how to use this API.
If that's not possible, I'll continue to program drivers for the rest of the PWM modules. Let's see...
Kind regards,

well done Franciscodr on completing lab14 .... will go through all your info .... and thanks for the tips for lab13 .... unfortunately im stuck again dam laptop .... new profile i created has also crashed for the failed logon problem so lost keil programmer so going to have to reinstall grrrrrrrrrr ... and things being very busy offline so not having any time at the moment .... my Daughter made her communion at the weekend which was great but had kept me very getting things ready for it so no time to sort out my laptop problems ... hopefully this week ill get a chance to sort things out and try and get a bit more done before the course finishes.

Hi Photolong,

Thanks! It was not as hard as other Labs, but a bit tricky in some things as you can read in my article ;-)

Ok, so your issues with the computer are getting long. Don't quit and keep doing! And tell me how things are going.

Nowadays I'm upgrading Lab 14: including a small software filter in order to avoid the "dancing figures" that occurs in the last digits of the measure displayed. And it works very good!

Yesterday I calibrated the whole system to adjust both offset and slope in the potentiometer. Now it's calibrated and works perfect!

Next days I will create a new library for the ultrasonic sensor HC-SR04 I bought in ebay very cheap and good. It will serve as sensor for the next robot I'll develop...

Hi Franciscodr .... well done on completing all the labs .... am now looking forward to seeing what you now do with your board and all you have learned .... so keep us informed.

as for me got laptop sorted ... had a few issues with lab files being mixed up between new profile and old profile but got them sorted ... still havent worked on lab13 focus still not right ... so spent most of my time helping others on the forum sort out there problems ... i have become quite good a debug code others have problems with lol ... being one of my favourite things being able to step through the code see how it works and if it dosent being able to fix it.

will work on lab13 and 14 as i plan to get them done as i dont want to miss out on learning anything ... will then either try lab15 or go back to start of course and go through every thing again as im sure there is a lot i can pick up the second time around that i didnt understand the first time.

also going to make my own programm from scratch ... as was shown at the end of lab15 ... this will be very handy as i like using keil ...

other than that i am extremely pleased with doing the course and got far more out of it than i ever expected to do ... and im allready waiting to do it again next year with a board this time and get the cert.

i also have signed up for two other courses on eDx .... computor programming part 1 and part 2 as i want to learn more about code these start in July .... and i will continue to look through eDx to see if i fancy any othe courses that come along

Hi Photolong,

Long time without reading you, and I'm glad you enjoy so much the course. I also liked a lot and didn't expected to learn that much also about programming, C and so on.

Now it's time to move on, to develop new skills, actually I'm programming on the insidiuos/difficult TM4C123 PWM modules: they are quite hard to program, so after reading nearly all PWM documentation and code with TM4C123 in Internet (they are not that much unfortunately for Keil, as it is for Arduino or even CSS or Code Composer Studio), I could manage yesterday night to compile sucessfully two PWM modules routine, and test in the board with different periods, with a Valvano's general example of course ;-) BTW It looks like it's not possible to simulate PWM modules in Keil. You can read a breifing of my adventure and the helpful hand from a Ti's worker in their E2E forum community here.

Now I'm modifying that code to handle duty cycle so I can manage some servos ;-)

Next will be to handle some Ultrasound and IR sensors, and finally building a robot with the EK-TM4C123GXL LaunchPad board as a proff of concept all together.

I would like to learn more about programming but focused on embedded systems. I think upgrading these examples we have seen in the course can be a good chance to do it. Which is your routine to debug? Do you use any test-step in special?

BTW, maybe you can help me with some errors I get when compiling together the PWM module with Lab 14, the aim: to control a servo with a potentiometer meanwhile reading the position (degrees) in the display ;-) If you preffer I can open an issue in the Piazza forum, or in the E2E forum community...

well i completed lab13 and its fully working ... very tricky lab but there was enough help on the forum to get me through it ....

looked at your link and sorry thats beyond me .... compiler errors are very difficult to figure out ... debug code thats a lot easier and i enjoy doing that.

will look at getting a board some time in the future as i would like to do the labs on the board and i think i would prefer to work with these boards rather than arduion boards so will see how that goes.

anyway off to learn some more might have a look at lab14 now ....

Congratulations for completing Lab13!

I think the forum had a big part on the sucess of this course. The forum was very useful and people answered very fast and to the point most of the time.

Lab 14 was not very difficult yet very interesting and useful from both ADC and display management. Also for Project Management.

However as you said issues with compiler are very hard. I'm trying to put together Lab14 and a PWM module that separate work together, and they don't use common pins, but the whole new project crash when compiling. I obtined up to 40 errors and warnings! :-D

So now I'm trying the other way: from the Lab 14 that works, trying to put together an independent PWM module...

I think the more we are exposed to this Keil environment the more we know how to handle it.

BTW, how do you debugg? Do you have any typical debugging routine?

Kind Regards and have a nice weekend!

nice one i see you got your cert ... well done .... and  great job getting the servos to work ... you should be capable of doing a lot with your board now..... are you going to attempt lab15 ??? ... I think ill give it a miss for a while and focus on other things.

anyway have most of lab14 done ... as there was 3 mains in the program code i opted to do the third one ....  might try another one which uses the mailbox when i get done ... but have got a couple of issues you might be able to help me with ... first off the convert number ..... in arduino this is simple with the map function ... but even from searching the web i couldnt find a suitable solution and eventually created a rather long way of getting it done and it converts the reading and maps  the  distance from 0cm to 2cm ...  but dose it correctly so thats good .. 

so would like to see how you did it as im sure there has to be a better way than the way i did it ... posted my way below ....

only thing im stuck on is the sysTick_Handler as i cannot figure out what goes in here ... thinking its something to interrupt the ADC between taking  readings for the distance so if you could give me some help on this id appreciate it.

will do up a post on debug and how i go about it but im pretty sure you will have used most of it every time you programm ...

my code for conver number ... lol dont laugh its long but works 


unsigned long Convert(unsigned long sample){

while (sample <=409){


Distance  = (sample-d)/2;

return Distance; 



while (sample >409 && sample <=859){ //859


Distance  = (sample/2)-d;

return Distance;



while (sample >859  && sample <=1269){  


Distance = ((sample-d)/2)-10;

return Distance;  



while (sample >1269  && sample <=1719){



Distance = ((sample-d)/2)-15;

return Distance;


while (sample >1719  && sample <=2129){


Distance = ((sample-d)/2)-20;

return Distance;


while (sample >2129  && sample <=2579){


Distance = ((sample-d)/2)-25;

return Distance;


while (sample >2579  && sample <=2989){


Distance = ((sample-d)/2)-30;

return Distance;


while (sample >2989  && sample <=3439){


Distance = ((sample-d)/2)-35;

return Distance;


while (sample >3439 && sample <=3849){


Distance = ((sample-d)/2)-40;

return Distance;


while (sample >3849 && sample <=4097){


Distance = ((sample-d)/2)-45;

return Distance;


  //return Distance;  // replace this line with real code





A BIT OF A CHANGE TO THE ABOVE CODE .......................

Had another look at the above code and the formula and got back out my excel and looked at the numbers and tried to see could i find another link between the numbers in one range being mapped to the other and i found one which gave me a new formula 


Distance = (sample/2-d);

return Distance;

yep those three lines can replace all the code above lol lol .... has 5 errors in it which i have to look at eg reading 2497 should convert to 1.220 cm but comes out as 1.639 cm .... on looking at it in excel it dosent round up 1219.929 ... where as others eg 1799.895 it rounds to 1780 giving 1.780 cm ... 

so not sure wheather i can use this code but will see if it passes grader if i get sysTick_Handler ever done.


Added a %check on number and if number ended in 9 i put in a if statement and added 1 to the number ...

worked now all readings are fine yeeeee



output = (sample/2-d);

out = output %10;         // reads number and gets the % modulo of the number if it has one 

if (out > 0){                   // if it has next line adds one to the number eg if 1399  adds one gets

                                     //1400 = 1.400 cm

Distance = output + 1;

return Distance;


else  Distance = output;

return Distance;