Lab 5: Maestro RTX

The requirements for this week are:

• Convert to RTX Tiny. This will give you an opportunity to re-engineer your system to optimize the partition between the ISR's and housekeeping tasks. One of the main trade-offs that you will have to make is whether or not to have an ISR for the serial input. Here are the steps you need to follow to use the kernel:
  1. Build the Rtx51tny.lib library. Create a new project and add all of the assembly files (.a51) in this ZIP file to it.
  2. Under options for target->output, enable "create library" instead of "create executable".
  3. Edit the conf_tny.a51 file to configure the operating system for:
     • The tick and round-robin time slice that you want (the defaults it too slow, as discussed in class)
     • The register bank that operating system uses (its 1 by default, which is fine)
     • how much stack space you reserve for tasks: if you want to do the analysis later, start with a bigger number.
     • An assembly routine that the OS will run if the stack runs out of the room...no need to change this either.
     • oh....and you have to change the first line of the file to $DEBUG. I don't know why!!
  4. Compile the kernel...you should get a file called <projectname>.lib. Move this file to d:\keil\c51\lib\rtx51tny.lib. This file will be used by the linker when you compile your project.
• Here are some things you will have to do in your project:
  1. Under options for target->target, set operating system to RTX-51 Tiny
  2. In your source file, include <rtx51tny.h>.
  3. The kernel uses timer 0, so you will have change your code to use Timer 2 for tone generation, fortunately, Timer 2 also supports reload so that will be no problem.
  4. Get rid of main. Everything should happen in a task or in an ISR.
  5. The debugger has lots of good tools for using the kernel. One of the best is View->Periodic Window Update so that you can see variables changing while the simulator is running. You can also get a list of tasks and status.
  6. It is generally not a good idea for a task to use up a whole OS-time-slice in busy waiting. Consider this when you decide how to implement your serial interface.
• Implement streaming using a FIFO queue. Avoid sharing functions between tasks. There are some issues that we haven't covered in lecture yet. The queue is probably goes between the Serial task and the Music Task. Don't forget about critical sections and volatile variables. Test it with Adam's program (here is the source, compile under the Cygnus shell on NT using gcc) . This program sends an "s" on the serial port and then sends the rest of the bytes in the file, waiting for a byte to be received back from the serial port before sending the next byte (i.e. send one byte, receive one byte). Or you could try Josh's Windows Program, that gives more useful info for debugging.
• On Wednesday, we can have some in-class brainstorming about the best task decomposition to use.

Turn in:

• Demonstrate streaming.
• A description of your architecture (under one page). Describe each task and the partition between ISR and housekeeping tasks. Explain the design decisions that you made with respect to multi-threading and timing. Describe any significant problems that arose (aside from simple debugging stuff).
• Task diagram showing worst case for all task deadlines. The x-axis should be in machine cycles or milliseconds. Get times from the simulator, or hand calculate.
• Task diagram showing worst case interrupt latency for time critical operations. The x-axis should be in machine cycles or milliseconds. Get times from the simulator, or hand calculate.
• Source code (no assembly listing please)