Home  Products Tutorials Schematics Robotics Resources  Radio Stuff  Components Career  Download   Link Exchange   Sitemap

Add your Link (FREE)

Schematics and Circuits

Electronic Tutorials

Practical Experiments

More Resources

Computer Architectures - Complicating a simple Computer - Interrupts

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. 

timeon <interval>

        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

        ... 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. 

Software Architecture 

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):

     Makefile builds
     Sample runs of test_comintspack.lnx and tutor.lnx (both windows)

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



Home  Tutorials Schematics Robotics Resources  Radio Stuff  Components Career  Download   Link Exchange   Sitemap

Terms & Conditions  Privacy Policy and Disclaimer