Gee, I have been working with an 85230 on an IPAC interface through a
carrier card (PCI interface) to a PC, and I would have loved to have this
flexibility. It takes me almost 600nS to do a write, and about 900nS to do a
read, and as the man said, accessing any register except RR0, WR0, or Data
takes two accesses. I have to stay in the interrupt handler until all
channels I am monitoring are “happy” (tx queues filled, rx queues empty).
The carrier card I am using didn’t allow for DMA (you lucky dog you). I did
the whole thing interrupt driven. I had to go back and forth with the
manufacture to get the IPAC access times down to the point where I could
support two full duplex SDLC channels at 1.22Mbps, but it is working now
(under QNX 6).
I guess the part about this whole discussion that I am confused about is …
do you need to reply, or timestamp the data at start/end of message? If not,
a big DMA buffer would look to your app like huge fifos, but you would only
get DATA, no on-chip CRC check information, or detection of breaks/aborts,
etc…
The 85230 does have a 10 “frame” fifo for SDLC that you can set up. That
will keep track of individual frame byte counts, crc check bits, etc.. As
long as you don’t make your DMA buffer longer than say 9 frames will fit in,
you can read it out when you get the terminal count interrupt from your DMA
transfer, and know that all your CRC’s for the frames you DMA’d over are
good. I wasn’t able to do this because I need to do real time timestamps on
each received character, and notify upstream threads when a new “frame” is
ready.
You do have the option of doing the CRC check in software from the DMA data,
but this will take valuable cpu time that it sounds like you don’t want to
give up.
Another thing to consider, is that you need to add a timeout interrupt to
your system in case the data stops coming in. If you are strictly driven by
terminal count on a large (or small) buffer transfer, you will loose the
last few messages in the buffer if the line goes silent (say get’s
unplugged). A timeout interrupt that just keeps track of whether you had a
DMA TC interrupt or not would let you scavenge the last few messages, and
flag someone upstream that the data wasn’t coming in anymore.
ALSO… you mention using 1Mbps and having to feed seperate clock lines
across along with the 422 data signals… WHY WOULD YOU WANT TO DO THAT??
Use the built in DPLL circuit in the 85230 to re-build your clock, and use
the FM0 encoding mode for bit encoding (both sides of the link need to be
capable of doing this). You will need to feed a clock that is 16X your bit
rate into RTXC pin, and set up DPLL to use RTXC as input, and TX and RX to
use DPLL output as their clock, but this will work reliably. The 85230 comes
in ratings up to 20MHz, but the 16MHz and 20MHz parts can take a RTXC clock
rate of up to twice the PCLK rate, up to 32MHz if needed.
There is a slight gottcha attached to timing this way… If you want to use
other speeds, the baud rate generator’s minimum divider is 4. You can run
RTXC to BRG to DPLL to TX and RX, but you need to feed in 64 X your bit rate
to use the chain listed above (16X for DPLL, 4X for BRG). In my case RTXC is
exactly 16X our max data rate, so I use RTXC to DPLL to TX+RX for that, and
RTXC to BRG to DPLL to TX+RX for anything lower than that, but there is a
gap in the baud rates I can generate due to the minimum divider of 4 in the
BRG. Zilog has a new series of chips out that have fixed this limitation and
go from the 8/4 fifos to 32/32 fifos, as well as having on board DMA
controllers(16c32 for example). Unfortunately, it is too late for me to use
them in this project. If you are looking for a quick upgrade, going from an
85230 to an 80230 gives you a flat register map instead of having to write a
pointer register to access registers 1 to 15.
I am forced to operate in FM1 mode, and that has a consequence with this
chip of having the DPLL be (possibly) out of phase on the first message
received, since it takes 4 ‘0’ bits in a row to reliably re-sync the DPLL in
FM1 mode, and the filler character is 0x7E (only two 0’s in a row). In FM0
mode, you need 4 ‘1’ bits in a row to re-sync, and the 0x7E filler/sync/flag
character is just fine for that, it has 6 of them.
Good luck on your project.
Jeddy
“Rod Dore” <rod@connecttech.com> wrote in message
news:aeqcmh$9lu$1@inn.qnx.com…
“Tomas Högström” <> tomas@scandicraft.se> > wrote in message
news:> 3D05D028.409A15D2@scandicraft.se> …
I am looking for a PC/104 board for synchoronus SDLC RS422
communication. It will receive data at 1.06Mbit/s, externally clocked.
I am concerned about system performance, so I think a board with large
enough FIFOS, say 128 bytes or larger, is needed. The data source will
send
32 bytes packets at 400 times per second.
Any recommendations of boards? Drivers and/or QNX6 code examples
is required.
Connect Tech has a new board, ComSync104, but that board seems to be
DMA based instead of using deep buffers. I am concerned about the amount
of IRQ:s it will generate given the setup above.
Cheers / Tom
Dear QNX/SDLC devotee’s,
I have just caught wind of this discussion, here’s some information on the
DMA and IRQ implementation and other info for the Connect Tech ComSync-104
card, straight from the hardware designer :
The 2 channels of the ESCC (85230) are each “wired” to a pair of DMA
channels. When the card is powered up (or the PC104 bus is reset) the DMA
mechanisms are disabled. Each channel of the ESCC has a pair of pins which
are used to initiate DMA transfers (DTR/REQA and WAIT/REQA). These pins
serve 2 functions each, so if DMA is used then the other pin function is
not
available (there is I/O on the card which replaces some of the lost pin
functionality, if the DMA is used). Here’s how they are “wired” to DMA
channels.
--------------------|------------------|----------------------|-----------
-------------|-----------------------|---------------------------------|
DMA Channel | ESCC pin | ESCC channel | ESCC register
bit
| DMA enable bit | Function |
--------------------|------------------|----------------------|-----------
-------------|-----------------------|---------------------------------|
DRQ0/DACK#0 | DTR/REQA | A | WR14.2=1
| I/O(Offset 4).7 | Transmit DMA |
--------------------|------------------|----------------------|-----------
-------------|-----------------------|---------------------------------|
DRQ1/DACK#1 | WAIT/REQA | A | WR1.6=1
| I/O(Offset 4).7 | Receive or Transmit DMA |
--------------------|------------------|----------------------|-----------
-------------|-----------------------|---------------------------------|
DRQ2/DACK#2 | DTR/REQB | B | WR14.2=1
| I/O(Offset 4).6 | Transmit DMA |
--------------------|------------------|----------------------|-----------
-------------|-----------------------|---------------------------------|
DRQ3/DACK#3 | WAIT/REQB | B | WR1.6=1
| I/O(Offset 4).6 | Receive or Transmit DMA |
--------------------|------------------|----------------------|-----------
-------------|-----------------------|---------------------------------|
The I/O of the card allows the DMA to be enabled and disabled for each
channel of the ESCC (DMA enable bit, shown in the above table). The
registers of the ESCC need to be programmed first to set up the DMA
mode(s)
of operation and then the Enable bit should be turned on. This causes the
card to un-tristate and drive the DRQ signal inactive. After this, the DMA
controller (8237 style) is programmed with the desired transfer (this
could
occur in respose to an interrupt). When the ESCC signals a DMA request the
card will activate the DRQ signal. DRQ will stay active until the PC104
bus
responds with a DACK# cycle (read or write). The DRQ signal is then
deactivated by the card. The process repeats again when the ESCC requests
another transfer. When the transfer is complete, the TC signal (on the
PC104
bus) is activated on the last byte transfered. The card captures this
situation and generates an interrupt. This interrupt indicates, to the
driver, that the DMA transfer has completed. The TC interrupt is cleared
by
the driver by writing to an I/O address.
Another method is to setup the DMA controller and the card/85230 before
any
receive data arrives. Then when data arrives it goes straight into memory
without any CPU intervention. Then when the TC signal occurs, an interrupt
will be generated by the card which signals that N bytes have placed into
memory. The value of N will be the count value which was programmed into
the
DMA controller.
The ESCC inself has an 8 byte receive fifo and a 4 byte transmit fifo.
Receive interrupts can occur when either 1 or 4 bytes have been loaded
into
the fifo. The transmit interrupt always occurs when the fifo is empty.
Zilog publication “UM95SCC0100” tells all about the ESCC, chapter 2.5.2
contains lots of details about the DMA process (from the 85230 point of
view).
Other features of the card worth noting (minor sales pitch coming… just
an
emphasis of the technical features which actually help)
-
Enhanced I/O operations which allow ESCC registers to be read/written
in
one PC104 I/O cycle. If you know the ESCC (85230), then you know that a
register read or write actually takes 2 bus cycles. One to select the
register and the second to read/write a value from/to that register. The
hardware of the ComSync-104 card provides a linear address region which
maps
into all the ECSS registers. In this way software can directly read/write
each ESCC register with ONE PC104 bus cycle. This is especially helpful
when
the software has pre-emptive (ISR) code sequences which both access the
ESCC.
-
ESCC Register Bit Cloning. When various registers of the ESCC are
written, the card keeps a copy of certain bits, so that the mode of
operation of the card can “track” the setting of the ESCC. Seven bits from
4
different registers are “cloned” to implement various card settings. This
simplifies the setup of the card and eliminates jumpers and switches. In
fact, there is only one switch, to set the I/O address of the card, ALL
other functions are software programmable.
-
Software programmable interrupt selection with a master enable bit and
support for the DMA-TC (terminal count) interrupt.
-
Security feature allows a customer to “lock” his software to the use of
the this card. Works like a simplified security dongle. The security
function implemented can be customer specific (within the limits of the
implementation).
-
Software programmable Line Interface supports many electical standards,
RS232, RS422, V.35 and others which are combinations of the 3 basic
electrical interfaces, EIA-530(A), X.21, RS449.
I will watch this news group for any other postings. Or, if you have
specific questions, please email me.
–
Regards…Rod.
Rod Doré > rod@connecttech.com > Voice: 519-836-1291 Fax:
519-836-4878
Connect Tech Inc. 42 Arrow Road, Guelph, Ontario, Canada, N1K1S6
