Searching \ for 'Pick a PIC that can CAN' 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=pic
Search entire site for: 'Pick a PIC that can CAN'.

Truncated match.
PICList Thread
'Pick a PIC that can CAN'
1996\08\12@214851 by Prashant Bhandary

flavicon
picon face
At 10:01 AM 7/08/96 -0400, you wrote:
>A list of texts, web sites, and ASIC manufactures that make
>products for these standards would be of great aid, not only
>for myself, but I would think also for the members of the
>this list as well.

Details can be found at http://www.omegas.co.uk/CAN/canworks.html and
a few other sites. Quite a few CAN chips are avialble including one built
around an HC05. I looked at CAN a while ago for an app I had in mind and
was pretty impressed.

I found the following features quite appealing though not necessarily
relevant.
1. It use two wires. It can work if one of these wires is open, shorted
  to ground or vcc or if the two wires are shorted together.
2. It's got a great arbitration protocol which uses collision avoidance
  instead of detection. This should improve bandwidth considerably.
3. It uses message based addresses instead of device addresses. As a
  model railroader, my one-track mind(sorry) can think of ways to use
  this. Detecting the presence of a train in a zone can be sent out
  not as device A just had its pin 1 change state but as train in zone X
  detected. Other devices react directly to this - level crossing Y slams
  shut, signals Z change colour... This eliminates some of the need for a
  master unit.
4. It is peer to peer. There isn't a master device on the bus. Each device
  has its own priority level so you can make more important messages shout
  louder.

Comms guys probably find this quite routine but to me it looks close to
ideal. I do look forward to seeing it on a PIC. I hope the implementation
is water-tight(I've heard a few rumbles about the I2C), the frequency can be
adjusted(you can compensate for distance by dropping frequency) and it is
built around a 16C84(I've studiously avoided 5X and EPROM based PICs).

Some other web references are
       www.hitex.com:80/automation/docs/canintro/
       http://www.docs.uu.se/~ken/CAN.html

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\08\13@190356 by Robert Lunn

flavicon
face
> I found the following features quite appealing though not necessarily
> relevant.

       list of really great features snipped...

> adjusted(you can compensate for distance by dropping frequency) and it is
> built around a 16C84(I've studiously avoided 5X and EPROM based PICs).

       Please, no.  The 'C84 is not sufficiently secure.

___Bob

1996\08\13@191434 by Mark K Sullivan

flavicon
face
>        list of really great features snipped...
>
>> adjusted(you can compensate for distance by dropping frequency) and it is
>> built around a 16C84(I've studiously avoided 5X and EPROM based PICs).
>
>        Please, no.  The 'C84 is not sufficiently secure.
>
>___Bob
>

EEPROM program memory is also too slow.  I am always pushing the full 20 MHz
with something.  (Today I was generating audio via software PWM, receiving async
data at 9600 bps, and transmitting HDLC at 1200 bps concurrently in a 'C57).

- Mark Sullivan -

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