Searching \ for '16c73 questions' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16C
Search entire site for: '16c73 questions'.

Truncated match.
PICList Thread
'16c73 questions'
1996\06\18@143621 by Dwayne Reid

flavicon
face
I am about to do my first design using 16c73a parts.  All projects up til
now have used the '71 or '61 but I now need WAY more RAM.  Any gotchas that
I need to worry about?.  I will be multiplexing 64 analog inputs into RA0 &
RA1 (32 each) and bit-banging 4 spi type serial busses for digital i/o and
display.  I want to use the USART for a communications buss for inter-card
communications.  I really don't need the extra i/o pins that a '73a will
bring me but that is the smallest package that has the RAM and USART.  Each
of these cards can be used stand-alone or as part of a larger system where
each card operates more or less autonomously but can be interogated and
eeprom constants changed via modem.

The system configuration that I need to achieve is up to 30 or so of these
cards talking to a dedicatded communications controller (also another '73a).
I would like to tie both the TX and RX lines of the USART to a 1 wire (plus
gnd) buss.  This buss would use an open collector driver for TX and a
schmitt trigger for RX and a voltage swing of 15v to GND.  Using a 15v swing
would reduce the effect of ground loop induced common mode voltage.  An
advantage of a wired-OR arrangement is that whichever card is transmitting
data could also receive the trasmitted data and determine if a collision
occured by comparing the TX byte with the RX byte.  Another advantage is
that I could build in some decent protection against ESD and wiring error
damage - the pic pins are isolated from the outside world.

Obviously a 1 wire buss is a half duplex arrangement and I need to worry
about arbitration.  My first thought is that the communication card is the
master and originates all transfers.  It would poll each of the zone cards
for status and could also issue commands to the selected card.  I am
thinking that all the data packets would be quite small (5-30 bytes)and
include a CRC with some type of ack or nak following each packet.  I am
planning to use a slow data rate - 1200 baud or so.

I am in the planning stages for this and would appreciate constructive
critsism and suggestions.  In particular - are there existing communication
protocols that I can make use of?  I hate reinventing things!

Thanks!

Dwayne

1996\06\18@192806 by John Payson

flavicon
face
> I am about to do my first design using 16c73a parts.  All projects up til
> now have used the '71 or '61 but I now need WAY more RAM.  Any gotchas that
> I need to worry about?.  I will be multiplexing 64 analog inputs into RA0 &
> RA1 (32 each) and bit-banging 4 spi type serial busses for digital i/o and
> display.  I want to use the USART for a communications buss for inter-card
> communications.  I really don't need the extra i/o pins that a '73a will
> bring me but that is the smallest package that has the RAM and USART.

I would suggest considering a 16C622.  It does not have the USART, but it
does have more RAM than the older "small" devices: 128 bytes.  For half-
duplex communication, a USART may not really be needed anyway, especially
at 1200 baud!  You could either run a timer tick at 3600x/second or faster
(pref. 3600 or faster) and poll for serial receive, or use an edge-triggered
interrupt to start a 1200Hz timer.  Alternatively, you might decide to use
Manchester coding instead of NRZ (common name for "normal" serial communi-
cation).

> Obviously a 1 wire buss is a half duplex arrangement and I need to worry
> about arbitration.  My first thought is that the communication card is the
> master and originates all transfers.  It would poll each of the zone cards
> for status and could also issue commands to the selected card.  I am
> thinking that all the data packets would be quite small (5-30 bytes)and
> include a CRC with some type of ack or nak following each packet.  I am
> planning to use a slow data rate - 1200 baud or so.

Master/slave is a good idea whenever it can be worked.  It is much easier to
figure out the different things that can happen with m/s than with multi-
master arbitration schemes (one thing I think someone should produce would be
a simplified I2C with one master; designing for this would be much easier than
designing for "real" I2C)

> I am in the planning stages for this and would appreciate constructive
> critsism and suggestions.  In particular - are there existing communication
> protocols that I can make use of?  I hate reinventing things!

See above, or ask if you want more suggestions. :-)

1996\06\18@204946 by Prashant Bhandary

flavicon
picon face
At 12:35 PM 18/06/96 -0600, you wrote:
>I am in the planning stages for this and would appreciate constructive
>critsism and suggestions.  In particular - are there existing communication
>protocols that I can make use of?  I hate reinventing things!
>

Have you had a look at the CAN protocol? The complete implementation would
be overkill but it has a bus arbitration scheme you could use.

Briefly, it uses an open collector bus like you do. Each 'message type' has an
address instead of each chip. This may not be strictly relevant. To transmit
a message a unit does the following.
1. Check if the bus is idle.
2. If it is, put out the address bit by bit and read the bus. If it does not
  match the bit you output, give up and wait till the bus is idle before
  trying again.
3. If the address has been successfully read back, the bus is yours. Send your
  stuff and follow it with an end of transmission signal so that everyone else
  knows that the bus is now idle.
The lower addresses get priority assuming an active low bus. For example, if
two devices with addresses 0001 and 0011 try to check the bus at the same time
              ___       _._
Device 1(0001)    |_._._|
              ___     _._._
Device 2(0011)    |_._|
              ___       _._
Bus               |_._._|
                      ^  ^
                      |  |
                      |  +---- Device 1 gets the bus
                      +---- Device 2 gives up

This scheme does not result in destructive collisions nor does it result
in unnecessary bus idling. This utilises the bandwidth better. The CAN
bus has several other interesting features. Details can be found at
http://www.omegas.co.uk/CAN/canworks.html and other sites.

Regards

Prashant
+----------------+  -------------------------------------------------
|                |    Prashant Bhandary
|   +---+        |    Spatial Information Systems Section
|   |   |        |    Roads and Traffic Authority
|   |   |        |    Rosebery NSW 2018, AUSTRALIA
|   |   |        |    Tel:  +61-2-662 5299
|   |   +----+   |    Fax:  +61-2-662 5348
|   |        |   |    Email: spam_OUTprashbTakeThisOuTspamrta.nsw.gov.au
|   +--------+   |
| Still a newbie |    "2b|!2b" - William Shakespeare
+----------------+  -------------------------------------------------

1996\06\18@213421 by Steve Hardy

flavicon
face
> From: Dwayne Reid <.....dwaynerKILLspamspam@spam@PLANET.EON.NET>
> [cut]
> Obviously a 1 wire buss is a half duplex arrangement and I need to worry
> about arbitration.  My first thought is that the communication card is the
> master and originates all transfers.  It would poll each of the zone cards
> for status and could also issue commands to the selected card.  I am
> thinking that all the data packets would be quite small (5-30 bytes)and
> include a CRC with some type of ack or nak following each packet.  I am
> planning to use a slow data rate - 1200 baud or so.

If you are using a 1-wire bus why don't you consider using the method
developed by Dallas Semiconductor.  This uses an O/C driver in much the
same manner as you propose.  A bus master may address multidropped
devices, and devices may also send 'unsolicited' messages.  The DS
protocol even includes an 8-bit CRC.

>
> I am in the planning stages for this and would appreciate constructive
> critsism and suggestions.  In particular - are there existing communication
> protocols that I can make use of?  I hate reinventing things!
>
> Thanks!
>
> Dwayne
>

Regards,
SJH
Canberra, Australia

1996\06\19@075423 by terogers
flavicon
face
Dwayne Reid wrote:

> I am in the planning stages for this and would appreciate constructive
> critsism and suggestions.  In particular - are there existing
>communication protocols that I can make use of?  I hate reinventing
>things!

Dwayne:

Forget the old industrial logic voltage swings and use cheap simple
RS485 tranceivers instead. Get the National Semiconductor data book,
which contains all you need to know about the electrical protocol. You
won't need to tie the transmit to the receive at the chip (it happens on
the bus if you choose the correct tranceiver chip); you can get very low
power cmos LTC versions cheap and easy from Digi Key. If you truly want
isolation you can couple the tranciever to the bus with a suitable pulse
transformer. Pulse transformers made for serial communications at
specific ranges of baud rates are available from many sources; check the
EEM (Electronic Engineering Master).

Several years ago we demonstrated a bus (built as described above)
operating quite happily at 230K baud while a 60W 110V light bulb
operated from a dimmer over the two bus lines. (Not recommended in
actual practice.)

-- Tom Rogers  VP - R&D  Time Tech Inc.

1996\06\20@054134 by Jattie van der Linde

flavicon
face
>
> Several years ago we demonstrated a bus (built as described above)
> operating quite happily at 230K baud while a 60W 110V light bulb
> operated from a dimmer over the two bus lines. (Not recommended in
> actual practice.)
>
> -- Tom Rogers  VP - R&D  Time Tech Inc.

> operated from a dimmer over the two bus lines. (Not recommended in
> actual practice.)

Why not. ?

1996\06\27@083245 by terogers

flavicon
face
Jattie van der Linde wrote:

> > Several years ago we demonstrated a bus (built as described above)
> > operating quite happily at 230K baud while a 60W 110V light bulb
> > operated from a dimmer over the two bus lines. (Not recommended in
> > actual practice.)
> >
> > -- Tom Rogers  VP - R&D  Time Tech Inc.
>
> Why not. ?

Sorry about the delay; I've been busy at being busy...

The why not is this: I don't want to ever have people connecting
equipment I've designed to a live power circuit except under very
special circumstances. The fact that you can specify standard power
connectors and such in no way should lure you into disrespect for the
qualitative properties of this stuff: at the very least if something
disasterous happens you can assume the comforting mantle of common
practice. In most cases, if you stick to approved connectors and
assembly practices you can be assured of good legal standing when the
sparks fly.

So: when you want to connect your com line to a hot circuit, the
following dilemma arises: if you use approved connectors, you end up
with something people will plug into the wall by accident; if you use
any other connectors, you get live voltages on connectors not meant for
them, and in unusual places (like on what looks like a com line.. )

This problem is really the biggie when it comes to the question of
sharing power lines with data. In the case of the rs-485 stuff, there's
the additional problem of needing to use proper twisted pair for any
high speed communication. The appropriate cable isn't rated for
delivering power.

It always seems to come back to some vaguely legal consideration when
you intend to sell something, doesn't it? Oh, well.

--TR

1996\06\27@114150 by Newfound Electronics

flavicon
face
{Quote hidden}

Thanks Tom. I'm glad I'm not the only "bush lawyer" on the PICLIST.
This is the point I tried to make in regard to production
standard programming some time ago. The only difference is that your
"common practice" must be replaced with "manufacturer's standard."
Sometimes the purely practical aspects must take a back seat.


-Jim

More... (looser matching)
- Last day of these posts
- In 1996 , 1997 only
- Today
- New search...