Lab 5: Code

Click here to get a copy of code for lab 5. This should cover most of the lab. Note, that queue.asm was re-written to provide a more reusable module; so that you can use the same code both for xmit and receive queues. 

An important note about Lab 5

Looking at the code issues of one of the students, I noticed a mystic issue with the simulator, so in sci_isr if you check TDRE bit first, even though the transmission interrupts gets disabled it looks like it doesn't actually clear the interrupts! However if you check for RDRF bit (see below) this issue doesn't happen

LDAA SCSR

BITA #RDRF
BNE SCI_RDRF

BITA #TDRE
BNE SCI_TDRE


Time permits, I'll try to further investigate to see what's the source of the problem; there may be a reasonable explanation for this(!), meanwhile please adjust your code as per above.

There was also a minor issue in the queue.asm code; sec/clc (setting/clearing the carry bit) must be called close to RTS, ensuring that other instructions will not alter the carry bit after it; here is the updated code: queue.asm

Question and answers regarding Read_str on Assignment 5

Question:When the Read_str subroutine encounters CR is that CR generated by user input or by the program where it would be stored at the second last byte in the string?

Answer: CR is generated by the user.


Question: wouldn't you only call Read_str once to initialize the interrupts and then if anything is put into the terminal a interrupt would happen echoing the character and loading it into the string?

Answer: No, you can call Read_str at anytime, so as an example, you may call after 1 min, at which time 40 characters have been received, so during this time, your sci_isr in addition to app_recv should keep storing the incoming bytes in a location in memory (e.g. in a buffer or queue)


Question: is it the main application requesting the string generated by read_str?

Answer: The main program requests the string by calling subroutine Read_str, and Read_str essentially reads from the received bytes till it hits the end of the received bytes, or it hits CR, or it hits the limit 253 bytes.


Question: do we need to save the string to memory or just transmit it?

Answer: Read_str's main purpose is to write the received bytes into IX (that is pointing to an array);
so as an example, if you do the following:
ldx #recvstr
jsr read_str

;; read_str should have at this point filled the recvstr memory with the previously received bytes

;; where recvstr is define like:
recvstr ds !255

So in short, read_str reads from received bytes that have been previously stored (perhaps in a buffer or queue) as they are received using sci_isr & app_recv subroutines.

Now, in addition to the above this question also asks for the bytes to be echoed as they are received (perhaps in the app_recv subroutine[?]), and this can be done by calling write_str with two bytes string, where the first byte is the character to send and the second byte is NUL, does that make sense? So one could write an additional subroutine called write_ch that essentially takes one byte and creates a nul-terminated string and pass it to write_str, which will echo it to screen.

Laboratory 5 – Device Interrupts and Terminal I/O

Click here to get a copy of Laboratory 5 – Device Interrupts and Terminal I/O.

The assignment was updated (to remove question 5 of the original document, i.e. write_ch subroutine)

Laboratory 4 - Device Polling using Serial Communication and Terminal I/O

Click here to get a copy of the  Laboratory 4 - Device Polling using Serial Communication and Terminal I/O.

In order to be better prepared for this lab, read Chapter 4, sections 2 and 3, of the textbook before attempting any of the exercises in either the pre-lab or the lab.

Update: You are asked to have done the prelab before the lab as preparation, but you are not required to submit it before the lab; you'll submit the full report, including the prelab on the lab due date. 

Laboratory 3 – Assembly Language Programming (2)

Click here to get a copy of Laboratory 3 – Assembly Language Programming (2)

Laboratory 2 – Assembly Language Programming

Here you can find a copy of Laboratory 2 – Assembly Language Programming

More supporting material will be providing in the class and here on the course website. Please review the document before the lab time. 

MiniIDE

Here you can download MiniIDE program for windows: I've tested it and it works for windows 7 as well. Using MiniIDE you can assemble your assembly code, but doesn't seem to have a linker!
So that means that you can't have separate modules unless you use $include directive; we'll further discuss this in the class:

http://www.mgtek.com/miniide/resources/hc11.aspx

Please note that you may have to go to Build menu > Options > Select the Tools tab > and change the Assembler from asm12.exe to asm11.exe in order to ensure you are using Assembler for HC11 not HC12. 

Laboratory 1: Introduction to MC68HC11EVB

Click here to get a copy of the first laboratory assignment: Introduction to MC68HC11EVB
If you would like to get a copy of the Simulator program click here.
Note: You must email your grouping info prior to laboratory session.