| ↑ Real Time Systems: Restricted Home |
The following is a preliminary list of the planned lab exercises and programming assignments for this course, not necessarily in order. I expect to make some changes as I fill in details.
| Description | How | |
|---|---|---|
| 1 | periodic task execution to control gizmo | individuals or pairs |
| 2 | measurement of execution times, applied to worst-case computational load of solutions to the above assignment | individuals or pairs |
| 3 | revise your gizmo controller design to use one thread per logical activity | individuals or pairs |
| 4 | (grad students) write a simulation experiment to evaluate a scheduling algorithm | individuals or pairs |
Some of the assignments may be broken into installments, each due several days to a week apart. For example, control of the gizmo may be broken into: (a) measuring the natural period; (b) controlling the motion; (c) adding the display of characters. Each part will be collected and assessed separately.
The details of each assignment will evolve, at least up to the point the previous assignment is due. Please pay attention to e-mails and try to use the on-line versions of the assignment statements, rather than print-outs. If you rely on print-outs made earlier in the term you may miss additions and corrections.
Students are responsible for scheduling, no later than the time of class on the due date, a time to demonstrate programs to the instructor. In general, there will not be time for all students to do the demonstrations exactly on the due date.
I will be spending some time (maybe a lot) in and out of class explaining what you are to do on the projects, along with some background information and theory. The information I provide in class will augment what is written on the Web about the assignment.
The detailed specification of an assignment may evolve, through in-class discussions, e-mails, and updates to what is posted on the web. Please keep up to date.
If you find an apparent contradiction between something said in class, what I send you in e-mails, and what is on the web, please communicate it to me and I will resolve it. If I am not able to respond in time, you should assume that written statements take precedence over oral statements, and that more recent written statements (e.g., e-mails and updates to web pages) take precedence over earlier written statements.
At the start of the term I will post some links to information on the References page that provide information about RTLinux, Linux, and the data acquisition device you will be using on the projects. I expect to post more references for your use on the projects as the term progresses.
It is good to seek out other references, including information on the Web, and if you find something you think is especially good, please communicate it to me so that I may inform the whole class. (The preceding statement is intended primarily to apply to information, not code. You may also use and share code that you find on the Web, provided that you follow the rules in the Syllabus about individual work, intellectual property, and plagiarism. That means you cannot use code you find on the web without permission from the copyright holder, clear demarcation of the the boundaries of what is reused, and a reference to the place you found it.
To do the programming assignments you will require "root" privilege on a Linux system, and access to some special hardware "gizmos". While you are using one of the systems it will not be safe for anyone else to use it. Even at that, there are many ways that a person operating as "root" can clobber files belonging to other users of a system.
You will not have direct access to any file server, so you are responsible for backing up your own files. This is really important! It is very possible that you or another user will trash the disk. The available backup media are floppy disks (small and slow) and sftp to one of the systems where you have other storage.
Ideally, each student should have his/her own dedicated system for this kind of course. However, we will have a limited number of Linux systems (probably ten) in the lab available for use by students in this course, and a more limited number of gizmose (six).
For the assignments that do not requir special equipment, you can use a computer of your own, provided you are able to install on it the Linux kernel version we are using for the course, and provided you can arrange to have the machine on campus for demonstrations.
You will be responsible for coordinating with the other users of your system, to make sure you do not do anything to interfere with them, and that you schedule your lab usage in a fair way. If you have any problems that you cannot resolve amicably, please let me know. I will try to arbitrate.
Because you will be able to read all the files on the system where you have root privilege, you will be on your honor not to read or copy the code of other users of that machine. (Students who are distrustful may run their systems in single-user mode and use sftp or floppy disks to hold their code while they are not logged in at the console.)
Since there are only six gizmos, some of you will need to form teams (pairs) for the assignments that use the gizmos.
It is essential that teams be of people whose schedules permit working together. It is also good to have people with approximately levels of programming skill and ambition. However, differences in specific knowledge can be complementary.
For most of the tasks you will be doing you will need to be physically in the lab, sitting in front of the system assigned to you. If you lock up or badly crash a system (which will happen routinely when you are programming with kernel modules) there will generally be no way to reboot without pushing the reset button (please, not the power switch!). Also, when you are working with the gizmos, you will need to be able to see and touch the gizmo.
The times you can access your system will not just be limited by the other students who share your system. There will be some class meetings (of other courses) scheduled in the lab. You are allowed to work in the lab during those classes, provide you can do so quietly, in a way that does not interfere with the class that is being taught there. In particular, you should not talk or move about in the lab during the class.
The lab is sometimes very cold, due to a problem with the A/C system controls. You may need to wear a sweater or jacket.
It may be possible to work remotely, to a limited extent. That is, there is a way to log into the lab machines remotely, using ssh and a proxy host, but if you lock up or badly crash the system you will be stuck until you can walk into the room and hit the reset switch (or telephone someone who is there to do it for you).
There is also a way to use one machine to reboot another, using a special hardware device connected to the reset switch. I have constructed one of these, and may be able to obtain materials to construct some more if there are students who volunteer to do the assembly. This method requires that the machines be set up as master-slave pairs, where the master is able to reboot the slave, so we can only use this when we are working as teams, with more than one machine per team.
| T. P. Baker. ($Id$) |