Lecturer: Sivan Toledo, Tel-Aviv University
Where and when: Sundays 16-19, Kaplun 205
I added a document with guidelines and ideas for projects. The link will be sent by email on December 4th.
Overall Scope of the Course
The course will focus on embedded systems, operating systems for embedded systems, and the Internet of Things (IoT), including IoT wireless protocols.
I have not worked out all the details yet, but the current plans for the course include (not a complete list):
- Microcontrollers and System on a Chip (SoC)
- Bare-metal programming (without an operating system)
- Programming with driver libraries
- Embedded operating systems; we will primarily use an operating system called TI-RTOS, but we will also discuss alternatives, such as Contiki and others
- Advanced software engineering for embedded systems (configuration and component systems)
- Fundamentals of hardware interfacing
- Internet of Things challenges: low-power design and communication protocols
We will meet of weekly lectures. Please plan to attend the lectures; not all the material will be available in presentations and books.
Homework will consist primarily of programming exercises on an IoT evaluation platform (see below for more details).
We plan two quizzes (בחנים) during lecture times, one in the middle of the course and a second towards the end. The weight of the quizzes in the final grades will be about 25% (total for the two quizzes).
The grade will be based mostly on quizzes and final projects, with grade deduction for incomplete homework submission and/or incomplete participation in lectures (without approval). Projects will consist of significant system development using the platform that will also be used for homework (it is expected that final-project system will include additional components, such as server code, mobile apps, etc).
The lectures will demonstrate many concepts using an evaluation platform called the CC2650 Launchpad by Texas Instruments; the same platform will also be used for homework exercises and as a component of final projects.
This platform includes a 3-core heterogenous processor called CC2650 as well as a 2.4GHz radio that supports several radio protocols including Bluethooth Low Energy (BLE) and Zigbee. The main processor in the CC2650 has an ARM Cortex-M3 CPU. The platform allows programming and debugging of the CC2650 through a USB connection.
We will loan a certain number of platforms to students who will solve homework exercises and develop their final project in university labs. These boards are made available through a donation by Texas Instruments.
Students can also purchase a platform for their exclusive use both at home and in university labs. The boards cost $29 and shipping to Israel costs another $7. If you can afford the board, we recommend that you purchase one.
We also expect that students will install Code Composer Studio, an Eclipse-based IDE that supports the CC2650 and its operating systems and communication stacks on their laptops or home computers. We may be able to install the software on some of the computers in university labs, but it will probably be easier to use your own computer.
- BLE Apps for phones/tablets:
- BLE Scanner by Bluepixel Technologies for Android
- LightBlue by Punch Through Design for iOS
- SensorTag by Texas Instruments (for both?)
- TI’s desktop software and downloadable communications stacks
- Code Composer Studio for SimpleLink Wireless devices (use version 6.2 or higher)
- BLE Stack (use version 2.20 or higher)
- SimpleLink Academy learning materials (use version 1.10 or higher; download link under “getting started”)
- Texas Instruments Cloud Tools. You will need to open a free account to use them. The most useful tools there are
- More resources
Exercise 1: Tools Setup and Warmup
Due date: November 6, 16:00.
The purpose of this exercise is to take you through the steps of installing the development environment and building and deploying a demo project, to make sure everything works. It is in principle a trivial exercise, and hopefully if you follow the instructions it will be trivial. But be prepared for some challenges (it was far from trivial to find the correct sequence of steps listed below). The difficulties may arise because there are several versions of the 3 development tools that you need to install and not all the versions are compatible with each other. Also, if you are installing on Linux or Mac, you may encounter some challenges that may complicate the procedure. At least on Linux, there should be a way to make this work (I am less certain about Macs).
Note that you must fill in an online lab form when you complete the assignment.
- Install CCS 6.2 or later for SimpleLink Wireless devices or later, free version. It defaults to installation in c:\ti; I usually install in c:\programs\ti. You only need to install support for CC2650 SimpleLink devices, but there is no harm in installing support for more devices (but it downloads and installs more software). Choose the TI compiler (again, no harm in installing GCC as well).
- Install BLE stack (must be installed in the same location as CCS).
Lior Raz noticed that the most recent version (from October 28) is not compatible with SimpleLink Academy version 1.10, so it is better to download version 2.2.0 of the BLE stack from the archive of old versions, http://www.ti.com/tool/BLE-STACK-ARCHIVE.
- Install SimpleLink Academy (same rule). I used version 1.10.
- Open the SimpleLink Academy (in CCS, use View -> Resource Explorer Classic and then expand SimpleLink Academy). Navigate to Bluetooth Low Energy -> Projects -> Project Zero and click on App CC2650 LaunchPad. Follow the instuctions, which tell you to import the project (it will also import the stack project that appears lower; it is necessary to import the stack by importing the app, not separately, otherwise the App won’t build), then build both projects, and download first the stack and then the app to the board.
- Click on the main SimpeLink Academy page (or the same on the web) scroll down to BLE Fundamentals, and click. Follow the remaining instructions from this lab guide to install an App on your phone (use either BLE Scanner or LightBlue) and to test it against the code that is running on the board. Make sure that you test turning on and off the LEDs (from the phone App) and that you subscribe to button-press notifications and that you get them.
- For extra credit or partial credit if you did not manage to perform the exercise as instructed above, do the same but using CCS cloud.
- Fill in the lab-report form (the link will be sent by email).
Exercise 2: TI-RTOS Scheduling
Due date: November 20, 16:00.
The purpose of this exercise is to learn and practice the threading and synchronization mechanisms of TI-RTOS.
- In Resource Explorer Classic, navigate to “TI-RTOS for CC13XX and CC26XX”, SimpleLink Wireless MCU, CC2650, CC2650 Launchpad, Driver Examples, TI Drivers Example, Pin Examples, Pin Interrupt and import the project into CCS.
- Read the code (all the relevant code is in pinInterrupt.c), make sure you understand what it is supposed to do and how it does this.
- Locate and read the API documentation of all the functions in the code that start with PIN_.
- Build the code, run it, and test that it performs exactly as you expected. If you did not predict the behavior of the code correctly, find out why you were wrong.
- The existing handler function in the code runs as an Hwi (I think). What Hwi priority doe it run in?
- We want to print a message using System_printf every time the user presses a button. Check whether this function can be called from an Hwi and whether it can be called from an Swi. (It can be called from a task; you do not have to check this). Answer by consulting the documentation, not by experimenting!
- Independently of what you found out in 6, create both an Swi and a task.
Use a semaphore to post the Swi from the Hwi, and use another semaphore to notify the task that a button was pressed.Post the Swi from the Hwi and use a semaphore to send a notification from the Swi to the task that the button was pressed. The task should print a message using System_printf, and the Swi should toggle the LEDs. The Hwi should only post the Swi semaphore. This is a normal structure for timing-sensitive code. You can handle both LEDs and switches in this part or just one.
- The CPUdelay in the code is used for switch debouncing. When a mechanical switch is toggled, it typically vibrates and opens and closes the connection a few times before it settles on the new state (open or close). This can take a few milliseconds. CPUdelay uses a loop to wait; this is inefficient, certainly in an interrupt service routine. Modify the code so that
- Waiting is done using a clock or a timer or a timestamp, not using a loop, and
- the actions (toggling the LED and printing the message) happen immediately when the button is pressed, not after the debounce period; the debounce period should be used for deciding whether to respond to the interrupt or whether it is part of a bounce (second event or later in a quick succession).
- Document your solution strategy for this part.
- Devise a mechanism that will
- allow you to test whether your debounce strategy actually works, and
- allow you to test whether the switch on the board actually bounces or not; document your solution to both parts.
- Fill in a lab report (link will be sent later).
Exercise 3: Power Consumption
Due date: November 27, 16:00.
This is a fairly easy exercise that require no programming, only inspection of code and documentation and analysis.
- In the pinInterrupt project, which clock is used when the buttons are not pressed? (hint: check the CCFG).
- Which clock is used when one of the buttons is pressed and the CPU is running?
- * Assuming that when a button is pressed, the CPU is running only to toggle the LED (on when the button is pressed and off when it is released), how much current does the system draws from a pair of AA batteries (assume they deliver 1.5V each or 3V together) when
- The buttons are not pressed and the LEDs are off,
- Immediately after a button is pressed, so the CPU is running, but the LEDs are still off, and
- When the red LED is on but the CPU is no longer running.
- For both a pair of AA alkaline batteries and for a CR2032 Lithium coin battery (use the data from http://data.energizer.com/ or equivalent), estimate how long
- the system can wait for a button press, assuming one never arrives,
- the system can light the red LED, assuming it is turned on once immediately after the system boots and is never turned off, and
- now many times one can toggle the LED on and off, assuming the LED is never turned on for a meaningful amount of time (that is, how many times the system can run the code that responds to the interrupt, assuming it does basically nothing).
- Explain how to measure the current in the three settings that you analyzed in part 3 of the question (marked with a *), assuming that you have a pair of AA batteries, resistors (any values that you need), a voltmeter, and for part 2 (measuring the current when the CPU is running), an oscilloscope (basically a voltmeter that produces a graph of voltage as a function of time, as opposed to the instantaneous voltage). The part with the oscilloscope is optional. Assume that the voltemeter can measure up to 10V and that its resolution is 1mV. Show how to configure the launchpad for these measurements.
Exercise 4: Temperature and Voltage Sensors
Due date: December 11, 16:00.
This exercise explores the temperature and battery-voltage sensors on the CC2650. The exercise also ties these sensors to power management and interrupt issues.
- Implement a program on the CC2650 that behaves as follows. The program should poll the BATMON module and record the temperature and battery voltage whenever new measurements are made. When the user presses a button, the program should print the latest temperature and voltage and also how long it has been operating (in seconds) and how often (on average) the BATMON module produces a new temperature measurement and a how often it produces a new voltage measurement. That is, the print statement should print 5 numbers (last temp, last voltage, time since boot, temp measurements/sec and voltage measurements/sec).
This program should run under TI-RTOS, but it should use direct register access or driverLib functions to interact with the BATMON module.
- Inspect the TRM (Technical Reference Manual) to determine whether you can configure the MCU to produce an interrupt every time BATMON generates a new measurement, to eliminate active polling. If the answer is yes, determine how to do this.
- (This part is optional). If your answer to the previous part is yes, implement an interrupt-based version of the program. It should not poll BATMON continuously but instead collect measurements in an Hwi. If your answer was no, implement a program that polls BATMON, but only every second, not continuously. In both cases, the program should respond to button presses in the same way as the first program.
- (This part is also optional). Let us assume that BATMON produces a temperature measurement 10 times a second (this is a completely made-up number; not use it in the previous parts of the problem) and that we want to report the maximum temperature only every 10s. Propose a power-efficient way to produce these maximum-over-10s reports on the CC2650.
Exercise 5: Using the SPI Flash
Due date: December 25, 16:00.
This exercise exposes you to the SPI inter-chip protocol and to the API of the flash chip that is installed on the CC2650 Launchpad. The flash chip uses a non-volatile memory technology called NOR flash.
- Implement a program that communicates with the flash chip (a MX25R8035F). The program should read the device’s identification using the commands RDID and REMS it should print out the results in a human-readable way.
- Read the description of the commands that the chip accepts and design a simple API that if implemented, will allow TI-RTOS to read, write, and erase data on this flash chip. The API should resemble the POSIX file-access API (open, read, write system calls) but with the appropriate extensions and restrictions that arise because the flash chip limits request sizes and alignments (its memory is divided into sectors and blocks that must be erased before they are re-written). The API need not include the OTP area and other special features. For each function in the API, state whether it can be called from Task context, Swi context, and Hwi context, and explain why.
Final Projects State 1: Proposals
Due date: December 18, 16:00.
Please fill in your project proposal on the web form. A link will be emailed to the mailing list.