Questions/Answers: What's run-time binding?

In short, run-time binding describes how we pass the address of a subroutines (app_xmit and app_recev subroutines) from application module to the SCI module (or from any module to another module in run-time, i.e. as the program is running on the CPU), allowing the sci module to call the subroutines defined in the application module implicitly/indirectly by loading the address of the subroutine and the jsr'ing to that subroutine. This is as opposed to a link-time binding, where you declare sci_init subroutine as extern in the application module and use the linker to bind them, thus, allowing for the application to explicitly/directly call the sci_init even though sci_init was defined in sci module (using jsr sci_init).
Generally, run-time binding provides more flexibility, and provides more separation or decoupling of modules.

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.

Modularization in HC11

Here is a short video describing modularization in HC11:

queue.asm file is the queue module
And testQMod.asm is an example test program that uses queue module.

Also note the comments, and code style (no magic numbers) in queue.asm for the reference. 

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.