Serial communication in Hexmon. Let's start from the bottom up: Look at putchar and getchar: putchar: LDAB SCSR ANDB #TDRE BEQ putchar STAA SCDR RTS getchar: LDAA SCSR ANDA #RDRF BEQ getchar LDAA SCDR ANDA #$7f RTS SCSR is $102E. Memory-mapped I/O and the serial port ======================================== The 68HC11 is a micro-controller: it contains several memories and a large amount of circuitry dedicated to I/O. There are many ``registers'' used to control I/O. Not in the CPU; see the manual for the addresses. Not available for general use. These peripherals and additional memory banks are also on the bus; the (data, address, R/W line) bus can be thought of as originating at the CPU and going to each of the memory and peripheral ICs. Consider the address bus. The higher bits determine which bank of memory or which peripheral IC is being accessed; the lower bits determine the actual address. These peripherals, as mentioned above, must be connected to the address and data bus and R/W line; they occupy specific addresses and respond only when those addresses appear on the bus. This is called memory-mapped I/O. The commands used for writing/reading from RAM, EEPROM are used to read/write to the registers controlling the I/O ports. The programmer can pretend that RAM, the registers, EEPROM are all one continuous memory, even though not all in the same bank and not all of the same technology. Now back to serial communication: ============================================ The serial port (SCI -- Serial Communications Interface): a UART (Universal Asynchronous Receiver-Transmitters)...a type of IC that controls serial asynchronous data transmission. In lecture: review of parallel versus serial communication; synchronous versus asynchronous serial communication. Serial data transmission: data transfer over a single wire. Asynchronous: the data is transmitted without an accompanying clock to synchronize it. RS232: The most common standard for serial communication signals. Describes the characteristics of the transmitter and receiver hardware, and the connections between them. idle start-bit data-bits stop-bit idle (1) (0) (1) (1) (So, the voltage on the line is logic 1 when the line is idle) Every character transmitted is introduced by a START bit (0). Data bits: LSbit closest to the START bit. Usually ascii (as for our system) One or two stop bits (1) follow the data bits (Baud rate: bits/second) Example: Transmit 'E'; Suppose we are using odd parity. (ascii E: _1000101) parity bit? 0 Recall: ***least significant bit is closest to the start bit*** <---- if transmitting in this direction: start bit parity bit & data stop 0 10100010 1 Example: following is a data stream, from the micro-p to the monitor. (<--- is the direction of transmission) 11100101000111010110000111001000011111 What characters are they? Is the parity even or odd? Describe the output on the monitor idle: 111 start bit: 0 (once you are idle, a 0 indicates start) 7 bits: 0101000 the least significant bit of the character is closest to the start bit, so this is the ascii code _0001010 (0A_16; LF_ascii) 1 parity bit: 1 (ok; 2 in LF + 1 parity: odd # of 1's) stop and idle bits: 11 start bit: 0 CR: 1011000 parity bit: 0 stop + idle: 111 start bit: 0 ASCII A: 0100001 parity:1 stop and idle:111 parity is odd; LF, CR, A sent to the monitor. Notes on Hexmon memory read/write code --------------------------------------- Key to the names: POV of the micro-processor: put: micro-processor to monitor get: monitor to micro-processor POV of the monitor: read: micro-processor to monitor write: monitor to micro-processor char: ascii byte: 8 bit hex number (not ascii) word: 16 bit hex number (not ascii) Some key parameter passing conventions: getword returns two hex bytes in register X getchar, putchar, getbyte use register A as the parameter Consider: cmd_write word Are the input values assumed to be hex or decimal? e.g.: z12540043 (writes the hex value 1254 to RAM location 0043) High-level algorithm? Read the data; save it on the stack Read the address; Store the data at the address cmd_write_word: JSR getword reg x<-word to write PSHX JSR getword reg x<-write address Now what? X contains the address; the data is on the top of the stack. PULY STY 0,X write word could PULD have been used? (no, there is no such command) PULA then PULB then STD? or PULB then PULA then STD? BRA cmd_loop Basic steps of getword? Monitor --> ascii characters--> micro-p. Simple: call getbyte twice We need to put the values in register X. Build up value in register D, then XGDX. D A B The first byte goes into A, the second into B. getword: JSR getbyte The first byte is in register A, as we want. But getbyte uses register A. PSHA JSR getbyte Where does this byte go? Register B. TAB The value that is supposed to be in A is on the stack PULA XGDX RTS cmd_read_word e.g.: q0053 the bytes stored at 0053 and 0054 are transferred over the serial port and displayed on the monitor getword: stores 0053 in X 0,X has the first byte 1,X has the second byte Each needs to be retrieved, and sent over the serial port; putbyte does the conversion and transfer. cmd_read_word: JSR getword LDAA 0,X JSR putbyte LDAA 1,X JSR putbyte BRA cmd_loop Putbyte: translate the hex byte in register A into two ascii values and send them over the serial port. putbyte: JSR Hex2Ascii Subroutine Hex2Ascii: converts byte in register A to its 2-char ASCII equivalent (output: MSN in register A, LSN in register B) Which do we want to display first? The MSN, which is in register A; putchar's parameter is in register A; so, why the PSHB? PSHB JSR putchar PULB Because we need the value in B, and putchar clobbers B's value. TBA JSR putchar RTS