68360 in UART mode

68360 in UART mode

Post by Ken Goldm » Thu, 31 Aug 1995 04:00:00



Two specific questions:

1 - I don't know in advance the length of packets received by the UART.
I think that what I'd like to do is interrupt after each character
is received, like a typical hardware UART.  Would I program the buffer
descriptor for a length of one byte.  Is there something clever I missed?

2 - The 68340 has an automatic RTS flow control on the receiver.
When the UART FIFO becomes nearly full, it negates RTS.  It would
surprise me if the 68360, with all it's features, did not have this
one, but I can't find it anywhere.

One general question:

The manual seems pretty good, and I intended to just dive in and
start programming.  But I got advice from one person recently that
this would be a disaster and that I should take a course from
Motorola first.  Opinions?

 
 
 

68360 in UART mode

Post by Eric Smi » Fri, 01 Sep 1995 04:00:00



> 1 - I don't know in advance the length of packets received by the UART.
> I think that what I'd like to do is interrupt after each character
> is received, like a typical hardware UART.  Would I program the buffer
> descriptor for a length of one byte.  Is there something clever I missed?

Yes, one byte BDs will work fine for this, but this will probably impose an
upper limit on the baud rate you can support for two reasons:

1.  There isn't enough dual port RAM in the '360 for a huge number of buffer
    descriptors.

2.  The SCC takes some time and bus cycles to close a BD and open the next one.
    It has hardware FIFOs to deal with this switchover, but at high baud rates
    it may not be able to do this for every recieved character.  I haven't even
    tried to characterize the limits on this.  Perhaps someone from Motorola
    can comment?

There is another way to do this if you just want some quick and dirty I/O
routines.  I did this when I was first bringing up our hardware before I wrote
some real drivers.  You can set the Receive Control Character mask and
registers so that all characters are matched and generate interrupts.  You
don't even need BDs for this, but you don't get any buffering.  I used
the TOSEQ register similarly in order to transmit single characters.

There are at least three ways to deal with the UART if you don't know how much
data you are expecting, but you don't want an interrupt on each character.

1.  Use the Receive Control Character stuff described above to match just a
    particular character (such as carriage return) and automatically close the
    Rx BD.  You can control whether or not the matched character goes into the
    buffer.

2.  The '360 SCC in UART mode has a MAX_IDL parameter that can be used to
    automatically close Rx BDs after a certain amount of idle time is detected
    on the line.  It is described on the bottom of page 7-148 and the top of
    page 7-159 in the manual.

3.  Periodically issue a Close Rx BD command (described at the bottom of
    page 7-151).  I've had reasonable results doing this every 5 mS.  If
    anything has been recieved into the current BD, it will close the BD (and
    generate an interrupt if you've enabled it).

Of course you can use combinations of these three methods.

Quote:> 2 - The 68340 has an automatic RTS flow control on the receiver.
> When the UART FIFO becomes nearly full, it negates RTS.  It would
> surprise me if the 68360, with all it's features, did not have this
> one, but I can't find it anywhere.

The '360 SCC doesn't really have any easy way to know how much buffer space it
has left, because it can't look ahead to see how many buffers of what sizes
you have supplied.  When you get buffer received interrupts you should check
whether you have enough empty buffers queued, and assert or deassert RTS based
on that.  If you set the buffer sizes appropriately you only have to check
for one empty buffer.

Quote:> The manual seems pretty good, and I intended to just dive in and
> start programming.  But I got advice from one person recently that
> this would be a disaster and that I should take a course from
> Motorola first.  Opinions?

I didn't have too much trouble by following the examples in the manual.  Make
sure you have the manual errata sheet *AND* the chip errata sheet, although the
C mask revision isn't supposed to have many bugs.

I did most of the early development of the startup code and device drivers for
the NetBlazer LS using printf style debugging, and an HP 16500A logic analyzer
for the tough problems.

For example, the logic analyzer was necessary to find out that one should
program the memory controller CS0 base register *before* the CS0 option
register, which is backwards from how it should be done for all the others.
Normally the base register should be programmed after the option register in
order to set the valid bit last, but in the case of CS0 the Global Boot
Chip Select feature turns off as soon as you program the option register.
Motorola should have had it turn off when you turn on the valid bit in the CS0
base register, or just on the first write to the CS0 base register.

Also, be careful to avoid race conditions when dealing with event registers.
I had problems when I tried to clear events at non-interrupt time, so now I
only clear them in interrupt handlers.  And remember that when you write to
event registers you should write ones for bits that you want to clear, and
zeros for bits that should remain unchanged.  They don't work like normal
read/write registers.  On the other hand, you can clear all pending events by
reading the event register and writing it back.

The first program that I brought up on our target platform was BOOTP, so that
we can do most of our development without burning EPROMs or fiddling with
ROM emulators.  We do most of our debugging with GDB, which we modified to
work over Ethernet (over UDP/IP).

For really tough problems I now use an Applied Microsystems EL 3200 in circuit
emulator.  I'm fairly happy with it, although I think I need a second 20 inch
monitor so that I can keep all my windows better organized.  Unfortunately the
only supported host platforms seem to be Sun workstations and PCs running
Windows.  I really wish they supported Linux.  The newest version of their
software can load a.out files directly, which will be a big win for us since
previously we had to convert all of our a.out files to S-records.

Cheers,
Eric

 
 
 

1. 68360 UART mode performance

Hi there,

I have been using the UART mode of the SCCs on the '360 for a few weeks now.  I am finding that when I get to data rates of > 500 kbps or so, the RISC starts having problems keeping up with this quantity of data on the receive end.  (ie. I start getting frame errors or overrun errors).

The performance data in Appendix B of the 360 manual claims the UART mode is good up to 625 kbps.

Have you had any success/failure with higher rates??  Is there any performance difference between different SCCs?

Thanks kindly,

Trevor.

2. Lancity Uncapper!... Trojan or Joke?..

3. Preformance of 68360 CPM in UART mode

4. Client32 for Windows 95 v2.20

5. 68360 SMC2 UART Problem

6. Upgrading my 386 Computer

7. Prefered UART for 68360 board

8. ShowMeTV avi conversion?

9. 68360 UART with variable length messages

10. 68360 UART

11. 68360 SCC UART sample code

12. MC68360's SCC4 - async UART mode

13. '360 SCC UART mode