> 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
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
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
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.