|
In this
assignment you'll enhance a provided tutor program so that it can
handle timer and serial interrupts. You should examine carefully
the sample interrupt programs $pcex/timetest.c and typewr.c. Read
S&S Excerpts, Sec 7-4.
Here are the
new commands now in the supplied cmds.c, but they don't do anything
yet. Your job is to make them work as specified. None of these
commands need to be implemented for the UNIX version of tutor. We
will only build and test the SAPC version.
Have
the timer interrupt every <interval> seconds to display at the
console the number of such interrupts since timeon. The <interval>
is in full integer seconds, for simplicity. Thus every now and then
the
lines
(1)
(2)
... and so on will appear on the console, interspersed with
whatever work the tutor user is doing. (In a real system these
interrupts might display the real time of day in a separate window
rather than this obtrusive useless count.)
Turn off
the time on display, disable timer interrupts, reset time on counter
to 0.
spi <-f|-h> <on|off>
spi stands for "serial port
interrupt".
�spi -f on� enables interrupts on input from COM1 in full duplex
mode.
�spi -h on� enables interrupts on input from COM1 in half duplex
mode.
When an interrupt is detected your program should pass the character
received from the serial port through to COM2, our console. If the
mode is half duplex, your program should also echo the character
back to COM1.
�spi -h off" or �spi �f off� disables
the interrupts in either mode.
Note: In full duplex mode we assume
that the �host� on the far end will echo characters back to our
input terminal so that we can see what we are typing. In our case,
there is no remote host to do this echoing. Hence, in full duplex
mode, we should see our characters passed through to COM2, but will
not see them on the COM1 port where we are typing them. Half duplex
mode accommodates this case and echoes the characters back to the
terminal where they are being entered.
Finally, the
quit command needs enhancement:
q Quit: Go
back to regular Tutor.
Disable any interrupts that have been
left enabled. If you leave these interrupts enabled when you exit
your tutor, you or the next student using your SAPC may get caught
by unexpected interrupts occurring when the new downloaded code in
the SAPC does not have interrupt handler code in the locations where
the previously running version of tutor had them.
Think about how
you will test these new features. Write the usual discussion
describing how you tested your code and what interesting things you
discovered while doing so. Put your discussion in discussion.txt.
Include small portions of scripts showing output caused by the
interrupt handlers.
Note: You'll
need to add build rules for test_comintspack.lnx to the Makefile and
add dependencies/command parameters for tickpack.opc and
comintspack.opc to the build rule for tutor.lnx in the Makefile.
We will put the
code for the timer and comport �drivers� in their own source .c
files so that tutor code doesn�t need to know how they work. The
API to the drivers is provided in the corresponding .h files which
will be �included� in the tutor code.
We had a timer
package for mp3, but here we need a different one. Here's the API
for tickpack.c as provided in file tickpack.h:
void
init_ticks(int interval, const IntHandler *app_tick_callback);
void shutdown_ticks(void);
Here the timer
package arranges to call the "callback" function every interval.
Note that we will need to call this for integral multiples of
seconds, e.g. 2 secs = 2000000 usecs - much longer than the 55 msecs
max interrupt interval of timer 0. Thus you will need to count
timer interrupts between callbacks to the application for these
longer intervals. So we see there are two ideas of ticks here,
native timer ticks at 55 msecs and application intervals that are
longer than 55 msecs. Your code needs to provide a function pointer
to the callback function in the second argument. That�s how the
driver can find the code that the application wants executed every
time the timer interval expires.
mp3's
timepack_sapc.c has a lot of the code you need to implement the
tickpack service. All you need to do is "divide down" the too-fast
tick rate that the timer provides.
Note that we
are providing a "unit test" driver for tickpack, i.e., a program
that tests tickpack with as little dependence as possible with other
code. It is in test_tickpack.c. After testing, integrate it with
the tutor commands.
See
comintspack.h for the API to the COM1 port driver:
void
init_comints (int dev, int hdx_in); turn receiver interrupts on
void shutdown_comints (int dev); turn receiver
interrupts off
NOTE: You only
need to make these functions work for the value of dev = COM1.
(There's useful stuff in and around $pclibsrc. It pays to snoop
around.)
We did not
provide a test driver for comintspack. You need to write one and
call it test_comintspack.c. Like $pcex/typewr.c, test_comintspack.c
must set up interrupts, loop "almost forever", then shut down
interrupts. Unlike typewr.c, test_comintspack.c does this setup and
shutdown by using the comintspack API and the comintspack
irq4inthandc function reads the char signalled by the interrupt and
outputs it on the console device.
See
test_comintspack.script for a run of my test_comintspack.lnx run
with �ABCDEFGH...� being input on the COM1 line and passed through
to the COM2 port. You will need to provide input on the COM1 port
to create receiver interrupts. Login to a board numbered 5 or
higher. In a separate window, use the command �mtip �l /dev/remgdbn�
where n is the board number you are using. This is the same command
you�ve used for remote gdb. However, because you are using it to
provide input to your program, you will not be able to use it for
remote gdb at the same time. With one window for mtip using COM2 ("mtip
-b 5 �f ...lnx" in this case) and another with mtip attached to
COM1, you can do many experiments.
Each char you
type in the second window is sent down the line to COM1, and each
char sent out COM1 should show up in the first window (and in the
second window depending on the mode). Don't forget to actually
type something into the COM1 window when you want to produce COM1
interrupts -- mtip only sets up a communications channel to COM1 for
you. It doesn�t send any test data for you.
NOTE: Enter (or
carriage return) = control-m and line feed = control-j.
You need to type these separately when you want these actions to
occur.
If you reboot
an online PC and then first contact it from COM1 rather than the
usual COM2, it will set COM1 up as its console line and do Tutor
commands from COM1. So be careful to keep track of which line is
which! The way Tutor does this trick is to poll both COM lines and
answer up to the first one that receives a CR character. The Tutor
command "dd" will tell you which line it is using as the console
line. Note that you can't ~r from the COM1 connection, so it's
better to maintain the usual COM2-as-console arrangement.
After testing
comintspack.c with test_comintspack.c, integrate it with Tutor. You
should turn in typescript file(s): From your master source directory
(or your group�s directory):
tickpack.c
comintspack.c
test_comintspack.c
cmds.c
Makefile builds
Sample runs of test_comintspack.lnx and tutor.lnx (both
windows)
discussion.txt
In the event
that you are unable to correctly complete this assignment by the
due date, submit what you have done and do not remove the work you
were able to accomplish - partial credit is always better than none |
