> 2. If it's a "common" part, how easy or hard would it be to add a few more
> externally to a Rabbit development board, possibly on a daughter board
> attached with a ribbon cable?
>
> 3. If it's a unique component, I might be tempted to ignore it and just add
> (the equivalent of) 8 UARTS. How easy or hard would it be to add a second
> board to connect to the Rabbit's bus on the development board?
You can use the slaveport to do it. There are code samples that do it
in the dev kits.
wwww.rabbitsemiconductor.com
www.zworld.com
Reply by Norm Dresner●August 5, 20042004-08-05
"Robert Scott" <no-one@dont-mail-me.com> wrote in message
news:4111b0b5.492942@news.provide.net...
> On Wed, 04 Aug 2004 21:07:08 GMT, "Norm Dresner" <ndrez@att.net>
> wrote:
>
> >...I needed to connect the computer to 6 serial lines.
> >Since we only had a 33MHz '386 back then, I really didn't want the CPU to
be
> >interrupted at a rate of 6 x 9600 baud so I found something called an
ACL-II
> >board which was an embedded controller..
>
> I think with any modern PC running Windows or Linux, this job is very
> doable without relying on an embedded controller, as long as each port
> has at least a 16-byte FIFO.
Consider the following:
1. The current main computer, with a single ACL-II 8-port board, takes
up 15 of the 16 slots in our passive backplane. I don't have the space to
add local multi-port RS-232 boards.
2. Also, the time-line of this ~1GHz P-III is on the order of 75% full
already. Since an ISA interrupt forces the whole CPU to wait for on the
order of 2 uS for each interrupt from or communications with the external
board, that's going to eat into the CPU bandwidth budget rather quickly.
With the scheme I proposed -- using an external board connected via
Ethernet -- the NIC is integrated onto the CPU board's internal PCI bus and
would present much less loading on the bandwidth.
3. Unfortunately, this RS-232 communications is only a very small part
of what the overall computer does and much of it's time is spent doing
mathematical calculations using inputs from it's other sensors. We had a
very good reason to off-load the work originally and, considering that the
original program has expanded with the increasing CPU speed, I think there's
still good reason to off-load as much of the grunt work as possible.
Norm
Reply by Norm Dresner●August 5, 20042004-08-05
"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:fpeQc.1799$zS6.214167@news02.tsnz.net...
> Norm Dresner wrote:
> <snip>
> > Now I'd like to do this with the ACL-II card as well, using a separate
> > "computer" to do the serial communications and communicate whole
messages
> > with the main computer via Ethernet. I just got the newest Mouser
catalog
> > today and in skimming though it I stumbled onto the Rabbit pages. The
3xxx
> > series has 6 serial ports. Unfortunately, I need 8. So ... I have a
few
> > questions for anyone who has used them before:
> >
> > 1. What type of "UART" is used in the Rabbit core? Is it an
> > implementation of a common part or a totally unique component?
> >
> > 2. If it's a "common" part, how easy or hard would it be to add a few
more
> > externally to a Rabbit development board, possibly on a daughter board
> > attached with a ribbon cable?
> >
> > 3. If it's a unique component, I might be tempted to ignore it and just
add
> > (the equivalent of) 8 UARTS. How easy or hard would it be to add a
second
> > board to connect to the Rabbit's bus on the development board?
> >
> > 4. If it's unique and it's too hard to add peripherals to the
development
> > board, then I may drop the Rabbit. What other uC or uP are convenient
to
> > implement as a "computer" + arbitrary peripherals? [My main concern is
that
> > we don't have a very sophisticated PC board manufacturing capability and
any
> > second board would probably be wire-wrapped].
>
> Sounds expensive. - What about using TWO rabbit modules, coded to handle
> 4 downstream channels each ?
> -jg
>
It seems doable. It still keeps the coding in the main computer relatively
straightforward -- ports 1-4 connect to IPaddress#1 and ports 5-8 connect to
IPaddress#2. The advantage of this approach is that it's modular and can
expand (or contract) as needed.
Hmmm.....
Thanks
Norm
Reply by Glyn Davies●August 5, 20042004-08-05
In comp.arch.embedded Norm Dresner <ndrez@att.net> wrote:
<snip>
: I did this again in '94 and yet again in '96. But ACL-II boards are no
: longer available and one of the ongoing programs is seriously concerned
: about the impact of potential failures of 8-15 year old boards [this program
: has access to one spare]. There is a similar board currently being
: manufactured (DigiBoard) but it's not anywhere near a drop-in replacement.
: Along similar lines, another of the boards in the '96 system did video
: overlaying on an NTSC video stream; I don't remember the rationale now but
: we chose a Targa64+ board for that and it's no longer available either.
<snip>
We used to use Digiboards to talk to lots* of devices (20-30 maybe at peak)
I've also used Specialix <spelling?> boards to do similar
When you get above a certain number of ports, you simply switch to polling
instead of interrupt mode on the driver. This prevents the interrupt storms
you would otherwise get. Fine on 486 boards with low numbers (10 say)
No need for anything special really
Glyn
--
------------------------------------------------------------------------
Glyn Davies / gryn@plig.net / www.technobobbins.com / Insert quote here?
------------------------------------------------------------------------
Reply by Robert Scott●August 5, 20042004-08-05
On Wed, 04 Aug 2004 21:07:08 GMT, "Norm Dresner" <ndrez@att.net>
wrote:
>...I needed to connect the computer to 6 serial lines.
>Since we only had a 33MHz '386 back then, I really didn't want the CPU to be
>interrupted at a rate of 6 x 9600 baud so I found something called an ACL-II
>board which was an embedded controller..
I think with any modern PC running Windows or Linux, this job is very
doable without relying on an embedded controller, as long as each port
has at least a 16-byte FIFO.
-Robert Scott
Ypsilanti, Michigan
(Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)
Reply by Dave VanHorn●August 4, 20042004-08-04
> Personally, I maintain a 4 to 16 port serial concentrator
> that uses the Z80180. We use 1-4 Exar quad UARTs. Exar
> also has 8-port versions. A little pricey, but the one I
> use has a 128-byte Tx and Rx FIFO with adjustable thresholds
> that cuts down on the number of interrupts and avoids overruns
> (see http://www.exar.com/products.php?areaID=3#8-bit)
Cute! I use edgeports, USB serial ports that (so far) have been great.
I have 16 ports connected at the moment, no problems at all.
Reply by Jim Granville●August 4, 20042004-08-04
Norm Dresner wrote:
<snip>
> Now I'd like to do this with the ACL-II card as well, using a separate
> "computer" to do the serial communications and communicate whole messages
> with the main computer via Ethernet. I just got the newest Mouser catalog
> today and in skimming though it I stumbled onto the Rabbit pages. The 3xxx
> series has 6 serial ports. Unfortunately, I need 8. So ... I have a few
> questions for anyone who has used them before:
>
> 1. What type of "UART" is used in the Rabbit core? Is it an
> implementation of a common part or a totally unique component?
>
> 2. If it's a "common" part, how easy or hard would it be to add a few more
> externally to a Rabbit development board, possibly on a daughter board
> attached with a ribbon cable?
>
> 3. If it's a unique component, I might be tempted to ignore it and just add
> (the equivalent of) 8 UARTS. How easy or hard would it be to add a second
> board to connect to the Rabbit's bus on the development board?
>
> 4. If it's unique and it's too hard to add peripherals to the development
> board, then I may drop the Rabbit. What other uC or uP are convenient to
> implement as a "computer" + arbitrary peripherals? [My main concern is that
> we don't have a very sophisticated PC board manufacturing capability and any
> second board would probably be wire-wrapped].
Sounds expensive. - What about using TWO rabbit modules, coded to handle
4 downstream channels each ?
-jg
Reply by Tom Taylor●August 4, 20042004-08-04
Norm Dresner wrote:
<snip>..
>
> Now I'd like to do this with the ACL-II card as well, using a separate
> "computer" to do the serial communications and communicate whole messages
> with the main computer via Ethernet. I just got the newest Mouser catalog
> today and in skimming though it I stumbled onto the Rabbit pages. The 3xxx
> series has 6 serial ports. Unfortunately, I need 8. So ... I have a few
> questions for anyone who has used them before:
>
> 1. What type of "UART" is used in the Rabbit core? Is it an
> implementation of a common part or a totally unique component?
>
<snip>..
There is a very active user forum on the Rabbit. Go to
http://groups.yahoo.com/group/rabbit-semi/ and subscribe.
If you ask your questions there and/or scan the archives,
you should find an answer quickly.
IIRC, the Rabbit is a fast, extended version of a Z180.
The serial ports it refers to are internal ports similar
to the two supplied on the original Z180. However, many
users extend the Rabbit with custom components.
Personally, I maintain a 4 to 16 port serial concentrator
that uses the Z80180. We use 1-4 Exar quad UARTs. Exar
also has 8-port versions. A little pricey, but the one I
use has a 128-byte Tx and Rx FIFO with adjustable thresholds
that cuts down on the number of interrupts and avoids overruns
(see http://www.exar.com/products.php?areaID=3#8-bit)
I used to make a 20MHz 80186 octal serial port concentrator
and used the Cirrus Logic CL-CD1864. It was hard to keep up
with though since it didn't have very deep FIFOs. I think
someone bought out the Cirrus Logic UART line, though.
Tom Taylor
Reply by Norm Dresner●August 4, 20042004-08-04
Back in, oh, somewhere around '92 or so [yes, the Dark Ages], as part of an
embedded controller I designed [based in an x86 rack-mount box with a
16-slot ISA backplane], I needed to connect the computer to 6 serial lines.
Since we only had a 33MHz '386 back then, I really didn't want the CPU to be
interrupted at a rate of 6 x 9600 baud so I found something called an ACL-II
board which was an embedded controller on an ISA bus card with an on-board
80188. My plan was to have this CPU do the communications and only
interrupt the main processor when complete messages (~20-255) characters
were received -- and likewise accept complete messages for transmission.
Since the messages were sort-of fixed format, though not all the same, there
was no way I could use the manufacturer's drivers so I wrote my own program
to run on the 80188.
I did this again in '94 and yet again in '96. But ACL-II boards are no
longer available and one of the ongoing programs is seriously concerned
about the impact of potential failures of 8-15 year old boards [this program
has access to one spare]. There is a similar board currently being
manufactured (DigiBoard) but it's not anywhere near a drop-in replacement.
Along similar lines, another of the boards in the '96 system did video
overlaying on an NTSC video stream; I don't remember the rationale now but
we chose a Targa64+ board for that and it's no longer available either.
Two years ago when this program finally accepted the reality that we
couldn't continue to keep their program running in 640KB under DOS [with an
AMX-86 microkernel to make it a pre-emptive, multitasking system], they
allowed me to migrate the program to Real-Time Linux and as part of that
upgrade I moved the video overlay function out of that box into a separate
"computer" [actually just 4 slots on a 16-slot backplane that had been
electrically isolated from the other 12] on the theory that if the overlay
function needed to be completely redone because their Targa64+ board and
single spare both died, the impact to the main computer would be minimal.
To facilitate this, I created a high-level protocol for the main computer
and the video overlay computer (VO) to use that should be adaptable to
almost any other hardware in the future.
Now I'd like to do this with the ACL-II card as well, using a separate
"computer" to do the serial communications and communicate whole messages
with the main computer via Ethernet. I just got the newest Mouser catalog
today and in skimming though it I stumbled onto the Rabbit pages. The 3xxx
series has 6 serial ports. Unfortunately, I need 8. So ... I have a few
questions for anyone who has used them before:
1. What type of "UART" is used in the Rabbit core? Is it an
implementation of a common part or a totally unique component?
2. If it's a "common" part, how easy or hard would it be to add a few more
externally to a Rabbit development board, possibly on a daughter board
attached with a ribbon cable?
3. If it's a unique component, I might be tempted to ignore it and just add
(the equivalent of) 8 UARTS. How easy or hard would it be to add a second
board to connect to the Rabbit's bus on the development board?
4. If it's unique and it's too hard to add peripherals to the development
board, then I may drop the Rabbit. What other uC or uP are convenient to
implement as a "computer" + arbitrary peripherals? [My main concern is that
we don't have a very sophisticated PC board manufacturing capability and any
second board would probably be wire-wrapped]. For reference, our 12MHz
80188's CPU bandwidth is about 50% utilized on the current ACL-II board.
The program is almost completely written in C.
TIA
Norm