Writing to the NanoPEB Serial Port in Assembler

[Stuart]

Has anyone got the NanoPEB serial port working in assembler? I can't get it to write a character. The relevant snippets of my test code are as follows:

 

CR9902B EQU >1340 CRU base address for RS-232 port on NanoPEB.

 

LI R12,>1300 Switch on serial interface on NanoPEB.
SBO 0

 

LI R12,CR9902B CRU base address of port.
SBO 31 Reset 9902.
LI R1,>6300 Control register: 2 stop bits, even parity, 8 data bits.
LDCR R1,8 Load control register.
SBZ 13 Disable loading of interval register.
LI R1,>001A 19200 Baud.
LDCR R1,12 Load transmit and receive data rate registers.

 

...

...

...

 

LI R12,CR9902B CRU base address of 9902.
XXX SBO 16 Set RTS on.

 

LDCR R2,8 ******* SEE COMMENT BELOW *******

LI R0,>FFFF
YYY DEC R0
JNE YYY
SBZ 16
LI R0,>FFFF
ZZZ DEC R0
JNE ZZZ
JMP XXX

 

With the "LDCR R2,8" line commented out, RTS is toggling on and off about once per second. With the "LDCR R2,8" line not commented, RTS is staying in a steady state.

 

Any ideas? The code works fine on my TM990 system. I've tried adding a LIMI 0 in the code but that doesn't seem to help.

 

[+mizapf]

I don't know how the nanoPEB implements the serial interface, but the original TI RS232 does not have a RTS. Or let me put it like this: it redefines it so that the interface becomes a DCE. See my problems I had in MESS in http://www.ninerpedia.org/index.php/MESS_Serial_connection#Line_mapper

[Stuart]

The NanoPEB routes the 9902 XOUT, RIN, /CTS and /RTS pins through a level shifter direct to the 9-way D-type connector.

[+InsaneMultitasker]

Here is an old snip of code I use to send a character via R3. The main difference from your code is that you are not testing the port status (and if the port is never ready, this piece of code will spin for all eternity). I do not recall if the port test is a pre-requisite to sending the character.

 

I am curious about your 8E2 configuration. Normally we would configure the port to 8N1 (8 data bits, No Parity, 1 stop bit) outside of a specific application. The rest of your setup looks good, including the interval register disable.

 

Lastly, you may need a delay loop inserted immediately after your 9902 reset. The chip may not be ready for you to immediately stuff the control register and baud. I'm guessing a simple DEC loop of 20-30 iterations would suffice.

 

SBO 0 ROM ON
SBO 7 LIGHT ON
AI R12,>40 OFFSET BASE ADDRESS TO PORT 1
SBO 16 XMITTER ON
PSEND1 TB 22 PORT BUSY?
JNE PSEND1 YES, TRY AGAIN
LDCR R3,8 NO, SEND IT
SBZ 16 XMITTER OFF
LI R12,>1300 RESET CRU ADDRESS SO WE CAN TURN
SBZ 7 LIGHT OFF
SBZ 0 ROM OFF
PSNDRT RT

]/code]

[+mizapf]

Is the /CTS input pin set to 0 (active)? The transmitter does not start until it gets the CTS.

 

Check the flow chart in the 9902 specification, page 16.

 

Also, check page 6, top of page:

 

Bit 16 (RTSON): Request-to-send ON. Writing a one to Bit 16 causes the /RTS output to become active (low). Writing a zero to Bit 16 causes /RTS to go to a logic one after the XSR and XBR are empty, and BRKON is reset. Thus, the /RTS output does not become inactive (high) until after character transmission has been completed.

[Stuart]

Is the /CTS input pin set to 0 (active)? The transmitter does not start until it gets the CTS.

 

Ah, yes, that the problem. I thought the state of /CTS could be sampled, but didn't realise it would it actually stop it transmitting.

 

Thanks folks.

[+mizapf]

Yes, the interesting thing is that RTS/CTS is a hardware-controlled handshake, while DSR/DTR allows for a software-controlled handshake (over the hardware lines, not to be confused with XON/XOFF).