ServoMotorbyPWM_and_TM4C123.zip (612252Bytes)
ServoMotorbyPWMADCpotentiomenter.zip (1360976Bytes)
Do you want to learn real robotics from inside? (Updated 2015-course)
UPDATE 22-Jan-2015: Course has just started!
So today we started the new course 2015.
We know now what the differences are from past year, I saw the videos that mostly are the same, excepting the one we know explaining the diferences.
After comparing the schedule with last course, it is the same but they included an extra last lab on Internet of Things:
- Suggested schedule
- By Friday 1/30: Finish Chapters C1 and C2 (install Keil, TExaS)
- By Friday 2/6: Finish Chapters C3 and C4 (electronics and digital logic)
- By Friday 2/13: Finish Chapter C5 (C programming)
- By Friday 2/20: Finish Chapter C6 (I/O ports)
- By Friday 2/27: Finish Chapter C7 (Design)
- By Friday 3/6: Finish Chapter C8 (Interfacing switches and LEDs), ready Feb 1
- By Friday 3/13: Finish Chapter C9 (How to debug), ready Feb 1
- By Friday 3/20: Finish Chapter C10 (Finite state machine), ready Feb 1
- By Friday 3/27: Finish Chapter C11 (Serial port interface), ready Feb 1
- By Friday 4/3: Finish Chapter C12 (Interrupts), ready Feb 1
- By Friday 4/10: Finish Chapter C13 (DAC and sound), ready Feb 1
- By Friday 4/17: Finish Chapter C14 (ADC and measurements), ready Feb 1
- By Friday 4/24: Start Chapter C15 (Hand-held game), ready March 1
- By Friday 5/1: Finish Chapter C15 (Hand-held game), ready March 1
- By Friday 5/8: Finish Chapter C16 (wifi and IoT), ready March 1 (NEW!)
- Course closes Wednesday 5/13
So, if you did the course last year, will you do the whole course again? Let's chat here ;-)
UPDATE 14-Jan-2015: So what's new embedded systems course for 2015?
Today we have received a new email from the Embedded Systems course people, as we'll start in one week time!
You can also download already the software for testing here, but they recommend to wait until course starts so anyone could ask fo issues in the useful forum.
In this email there is a video with the "what's new" for this course, you can watch to the video in Youtube, but here is my review about it. Besides passing 7 out of any 13 lectures to gain the certification, the important differences are:
- More details and explanations on Finite State Machines, as many people found it hard.
- More on how to read a datasheet, as it is very useful to develop by oneself.
- As debugging is an important part on developing good solutions they included lot of materials on debugging.
- As we saw before there will be +1 chapted on wireless communications and the internet of Things. We'll use a CC3100 Boosterpack to connect to Internet.
- CC3100 Wi-Fi Network Processor in QFN package
- Industry’s first devices to be Wi-Fi CERTIFIED™ at the chip level by the Wi-Fi Alliance™
- 2 20-pin stackable connectors (BoosterPack headers) to connect to TI LaunchPads and other BoosterPacks
- On-board chip antenna with option for U.FL-based testing
- Power from on-board LDO using USB OR 3.3V from MCU LaunchPad
- 2 push buttons
- 4 LEDs
- Jumper with 0.1 Ohm resistor for current measurement
- 0.8 megabit serial flash
- 40 MHz crystal, 32 KHz crystal and oscillator
- U.FL and chip antenna
- USB
- 4 Layer PCB with 6 mm spacing and track width
The first thing we see is that the CC3100 Boosterpack is packed full of features, but then it's bigger and much more expensive against most WiFi modules available around like the ESP8266 ($20 vs $4). Yes ESP8266 modules are not pin-compatible with the Tiva C TM4C123G board, but as Tiva has UART port and the ESP8266 too, we can solve it fast!
The "only" reasons to use the CC3100 Boosterpack are:
- it is pin to pin compatible with the Tiva C board
- chapter will be focused on how to handle this CC3100 Boosterpack. If you want to do your own experiment they wont support nor count it for points and certification.
- CC3100 Boosterpack is much more powerful, maybe you'll want it for your own projects.
A final drawback about the CC3100 Boosterpack is that you need the CC31XXEMUBOOST to flash the firmware directly to this board (!), also to have emulation with it. It adds up $20 more... yes Ti sells a bundle "discount" pack of both CC3100BOOST-CC31XXEMUBOOST (you save 4,3% from list price), but with a $41 final price the whole thing is still much more expensive that other solutions if you just want a regular IoT device...
So in my case, I'll wait some weeks until we start the course in order to ask about it. What will you do?
UPDATE 17-Dec-2014: new embedded systems course for 2015 is comming!
As many of you asked: there will be a new course available from these guys?
Yes! They have prepared a new one, very similar to the one we did already, but:
- They will include additional teaching material for Finite State Machines, how to use a data sheet, how to debug,
- and an additional chapter on wireless communication and the Internet of Things.
- In Spring 2014, there were 11 sequential labs and students had to finish eight of them to obtain certification. This time, there will be 13 labs and students will be allowed to choose and complete any seven of them to achieve certification.
You can check the whole new course description here.
So it looks they have updated the couse with some new interesting topics for our robotics experiments. If you are not interested on doing the whole course, you can audit only the parts you are interested on, it's free! ;-) Will you do the course now?
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):
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’ employee: Amit 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:
- A linear slide potentiometer converts distance into resistance (0 ≤ R ≤ 10 kΩ).
- Your software will use the 12-bit ADC built into the microcontroller.
- The ADC will be sampled at 40 Hz using SysTick interrupts.
- You will write a C function that converts the ADC sample into distance, with units of 0.001 cm.
- 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.
- 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:
- an introduction to sampling analog signals using the ADC interface;
- the development of an ADC device driver;
- learning data conversion and calibration techniques;
- the use of fixed-point numbers, which are integers used to represent non-integer values;
- the development of an interrupt-driven real-time sampling device driver;
- the development of a software system involving multiple files; and
- 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
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 ;-)
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.
- 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.
- You will convert the digital output signals to an analog output using a simple resistor network.
- During the static testing phase, you will connect the DAC analog output to the voltmeter and measure resolution, range, precision, and accuracy.
- During the dynamic testing phase, you will connect the DAC output to the scope to see the waveform verses time.
- 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."
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.
This figure shows a data flow graph for this digital piano
Calculating in MS for Samples for DAC synthesis
Tone table for 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."
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:
- Everything is off: both switch and speaker.
- Press switch once and speaker generates a 440Hz sound.
- Press switch again and speaker gets silent.
It looks easy but it’s actually difficult because:
- It is a real-time process: at the moment you press the button the system has to react.
- 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.
- 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:
- 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.
- get that sampled values from the board to the PC through the USB and a virtual COM port with an UART operation.
- 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:
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!
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:
//------------UART_OutString------------
// Output String (NULL termination)
// Input: pointer to a NULL-terminated string to be transferred
or:
//-----------------------UART_ConvertUDec-----------------------
// 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:
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:
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:
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:
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:
- If both PF4 and PF0 switch (main two switches) are not pressed, the PF1 (Red LED) output should be low.
- If either PF4 or PF0 switches is pressed, the output toggles at 10 Hz (±10%).
- Information collected in the Data array matches the I/O on PortF.
- 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.
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:
- 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.
- 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.
- third you have to toggle the LED when PF4 or PF0 switches is pressed. Easy.
- 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:
- design procedures in a high level way (top-down engineering),
- then define routines to perform those functions,
- design the software and debug in emulation (only PC).
- 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:
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
And 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:
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:
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:
- 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).
- The system starts with the LED ON (make PF2 =1).
- Delay for about 100 ms
- If the switch is pressed (PF4 is 0), then toggle the LED once, else turn the LED ON.
- 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:
- First, we activate the clock for the port.
- Second, we unlock the port; unlocking is needed only for pins PC3-0, PD7, PF0 on the LM4F and TM4C.
- Third, we disable the analog function of the pin, because we will be using the pin for digital I/O.
- Fourth, we clear bits in the PCTL (Table 6.1) to select regular digital function.
- Fifth, we set its direction register.
- Sixth, we clear bits in the alternate function register,
- 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:
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:
I 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:
https://courses.edx.org/courses/UTAustinX/UT.6.01x/1T2014/info
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 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:
- What you want to accomplish: the target for the programmed system, a funny or useful robot for example.
- Logic mind: if you can read, write and sum up, then you have more than half of what you need.
- 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
So I let you here the course’s introduction that is in its website, and I see you there besides that here in https://www.robotshop.com/letsmakerobots
(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.
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 | ||
Specs | 80MHz | 24x Timer/Capture/Compare/PWMs |
| 256KB Flash | 3x Analog comparators | |
| 32KB RAM | x SPI/SSI, 6x I2C, 8x UART | |
| 2-KB EEPROM | USB Host/Device/OTG | |
| 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 | EK-TM4C123GXL | |
Featured Microcontroller | TM4C123GH6PM |
