Searching \ for '%PIC Networking%' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'PIC Networking'.

_Sub string match.
PICList Thread
'PIC networking'
1997\01\27@105612 by ermott

flavicon
face
I haven't looked closely at what would be involved but perhaps
you could interface your PIC's through RS485 drivers.

-This is in response to Craig Houston's question about networking PIC's.

1997\01\27@120017 by John Dammeyer

flavicon
face
At 10:55 AM 27/01/1997 -0500, you wrote:
>I haven't looked closely at what would be involved but perhaps
>you could interface your PIC's through RS485 drivers.
>
>-This is in response to Craig Houston's question about networking PIC's.
>

Hi all,

I just finished a PIC Master/Slave interface.  Used RS485 devices two wire
1/2 duplex.  Master Polls slave and if slave address matches then slave
responds.  Network software had intercharacter timeouts and packet timeouts.
I used a LF character as a Start Of Packet (SOP) and a CR character as an
End Of PAcket (EOP).  Data was restricted to 7 bit ascii although some key
characters did have their eigth bit set.  Ie: data could never be confused
as SOP.  Any new unit appearing on the network synchronized itself by
waiting for the SOP.  If electrical noise simulated a SOP char (0x0A the
linefeed char) then the next char had to arrive within 5ms or else the
entire message was trashed until the next SOP.  If electrical noise
simulated an EOP then the rest of the message would be ignored because it
did not contain an SOP.  Receieved message length would be wrong, (fixed
size packets), as would checksum,  so this system was fairly robust.

John

1997\01\27@121040 by calladus

flavicon
face
I'm also interested in connecting PICS in a network environment.  I
would like to use a Hub based environment using the RS-422 protocol, but
I haven't found the protocol standard yet.  Anyone have any ideas on
where to find these protocols?  I've heard that they must be purchased.

 -calladus-


---------------
Andrew McDermott wrote:
>
> I haven't looked closely at what would be involved but perhaps
> you could interface your PIC's through RS485 drivers.
>
> -This is in response to Craig Houston's question about networking PIC's.

1997\01\28@090849 by Ben Allgor

flavicon
face
>calladus wrote:

> I'm also interested in connecting PICS in a network environment.  I
> would like to use a Hub based environment using the RS-422 protocol, but
> I haven't found the protocol standard yet.  Anyone have any ideas on
> where to find these protocols?  I've heard that they must be purchased.
>

RS-422 is an EIA standard for the " Electrical Characteistics of Balanced
Voltage Digital Interface Circuits".  A standard for the signal
levels, impedances, protection,  etc. It can be used with any
protocol or digital signal.   RS-449 may be more help to you  it
covers  37 pin and 9 pin connectors, pinouts and other interface
items for serial binary data.  If you want to get a copy it is available from,

The Electronic Industries Association
2001 Eye Street
Washington, D.C 20006

Ben
---
C. Ben Allgor, PE
Benjamin Engineering Consultants
http://members.aol.com/bengineers

1997\01\28@114925 by John Dammeyer

flavicon
face
At 09:12 AM 28/01/1997 +0000, you wrote:
>>calladus wrote:
>
>> I'm also interested in connecting PICS in a network environment.  I
>> would like to use a Hub based environment using the RS-422 protocol, but
>> I haven't found the protocol standard yet.  Anyone have any ideas on
>> where to find these protocols?  I've heard that they must be purchased.
>>
>
>RS-422 is an EIA standard for the " Electrical Characteistics of Balanced
>Voltage Digital Interface Circuits".  A standard for the signal
>levels, impedances, protection,  etc. It can be used with any
>protocol or digital signal.
>C. Ben Allgor, PE


The RS422 is full duplex in that you have four wires instead of two.  In a
master/slave you tend to have the master speak and slave listen,  then the
slave speak and the master - and perhaps all the slaves listen, then the
master again.  For most protocols there is no major advantage to going with
RS422.  This is why RS485 using the 75176B has become so popular.  As for a
given message protocol; what works for one project might be terribly
inefficient for another.  If you are interested in a family of messages you
might look at SECS/GEM used in the semiconductor industry for factory
automation.

It was designed for RS232 single unit to single unit but there are some good
and bad ideas there and I've always felt that I can learn more from someone
elses bad ideas than from studying a good idea.

Regards,

John




Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc.      Ph. 1-250-544-4950
PO Box 20002                  Fax 1-250-544-4954
Sidney, BC CANADA V8L 5C9

1997\01\29@090415 by Alexey Vladimirov

flavicon
face
27 Jan 97, Craig Houston writes to All:

P> I was wondering if anyone out there had any information on hooking up
P> PICs in a network like structure.

P> My plan is to have a bunch of PICs controlling various things, at
P> different locations throughout the house, and wanted to link them all
P> up - short of using a master PIC with all Tx / Rx lines from each PIC
P> going into it, I thought a network topology would be best.

What speed is necessary for your application ? For low-speed technology
(till 1200 baud) we made one interesting solution:

All local controllers connected via 2-wire line and powered from the same
wires. Controllers number depends from their supply current and
in most cases could be in range 50...500. Total wire length could be up to
one kilometer (about 100 baud in this case). Total supply current for all
controllers should not exceed 300...800 mA.

System consist from one master controller and till 500 slave controllers.
Master controller power all slave controllers and transfer data to all
slave simultaneously by switching line polarity. Slave can transfer answer
to master requests by short-time line shortenings.

We install some working netwoks, based on this technology in various
applications: guard systems, home gas and water counters, sensor networks, etc.

I plan to made some kind of application note available in near future.

Alexey Vladimirov  spam_OUTavladTakeThisOuTspammail.ormix.riga.lv

http://www.ormix.riga.lv/eng/mchip/mchip.htm
more than 300 PIC-related Net resources now...


'PIC Networking'
1998\12\28@091058 by Darkness
flavicon
face
Hello ,
     I am about to start a project where i would like to network two or
three PICs together, all the pics will be on the same circuit board.
Does anyone have any information or links to implementing RS-232, I2C
and RS-485 ??? (on PIC16F84)

Thanx
 Tim

1998\12\28@130028 by Andy Kunz

flavicon
face
>      I am about to start a project where i would like to network two or
>three PICs together, all the pics will be on the same circuit board.
>Does anyone have any information or links to implementing RS-232, I2C
>and RS-485 ??? (on PIC16F84)

Are they going to share the same pins?  Then either I2C or RS-485 is
appropriate.  Since you aren't using comm hardware, it really doesn't make
much difference.  You want an address-based protocol (which is your software).

Don't you have a real name yet?  Sure, we see "Tim" in the sig, but why not
in the "from"?!?!

It's just a pet peeve...

Andy

==================================================================
 Andy Kunz - Montana Design - http://www.users.fast.net/~montana
==================================================================

1998\12\28@131059 by Gerhard Fiedler

picon face
At 21:31 12/28/98 +1100, Darkness wrote:
>      I am about to start a project where i would like to network two or
>three PICs together, all the pics will be on the same circuit board.
>Does anyone have any information or links to implementing RS-232, I2C
>and RS-485 ??? (on PIC16F84)

you don't need rs232 or rs485 levels if you stay on the board with the
signal. i2c is nice because it allows every pic to be master or slave, but
it takes a bit more software than simple asynchronous serial com. you find
most of this (i2c master/slave, serial rx/tx) in microchip app notes.

ge


'On topic for a change: PIC Networking'
1999\03\13@011604 by Bob Drzyzgula
flavicon
face
I'd like to pick y'all's brains for a minute if it's
not too much trouble. I'm working on an application to
provide instrumentation to a wide variety of computer,
storage and communications systems in a data center
environment. (* see footnote below if you want more info
on exactly what.) I want to keep tabs on temperatures,
current loads, fan status, and such.  I also want to pick
up whatever external signals the systems *do* give me and
feed them back to a monitoring server (E.g. Kingston RAID
enclosures have headers in them that will close if there's
been various sorts of failures).  In addition, I want to
put relays on e.g. ATX soft power on/off and reset headers,
so that I can toggle those things remotely.

Now, most of the design aspects of this are straightforward
and I don't have much trouble with that. I expect to
have little PIC-based probes in each monitored device,
reporting back to (and taking commands from) a two-tier
(distributed probe managers and the top-level management
server) hiearchy of Unix (probably Linux) monitoring
and control severs.  But there is one part of this that
I'm having trouble seeing which way to go, and that's
networking the the PIC-based probes.

To some extent, the answer seems obvious to me: RS-485 (I
suppose that I2C would also be an option). But my problem
with that is that all this gives me is the electrical
connection. I need a protocol to place on the net,
and I would much rather not re-invent the wheel if at
all avoidable. Optimal, in my mind, would be if there
was a library package that I could simply call from my
application code, or which called my application code.
I've been putting off dealing with this in hopes that it
would become obvious to me (in case you couldn't tell,
this is an in-house application and I don't really have
a deadline for it, it will just make our jobs easier if
I can make it work, and I suppose I could look into
some pre-fab DIN rail sensor network, but that wouldn't
be any damned fun) but unfortunately this answer hasn't
yet jumped out at me; I suppose that I'm just thick.

One other complicating factor is that, in some circumstances,
I'd like to be able to put a probe in a "streaming mode",
where I could set up a "virtual circuit" of sorts that
would allow the PIC-based probe to dump a whole bunch of
data down the pipe without the risk of being interrupted
by another station. This would be useful if, for example,
there was a few KB of data on a monitored system that the
PIC needed to forward on to the management station; clearly
the PIC can't buffer all that much data without resorting
to external RAM or eeprom; but it could shovel it from
one side to the other without much difficulty.

I've dug and dug on the web and at websites, but I'm not
having a lot of luck. It seems as if, when it comes to
RS-485, most people just roll their own protocol. (Possible
here, but a lot of work for just this one application,
and potentially a major source of code revision). CAN
seems as if it would fit, but it isn't clear how far
this has gotten out of Microchips marketing department
and into the engineering labs... see the link (**) below;
first quarter is almost up, guys... (I did note a PICLIST
discussion on Microchip's CAN products from last December,
the conclusion mostly being that CAN is potentially cool
but expensive and limiting, and most people who responded
were more inclined to roll their own).

emWare's EMIT stack (http://www.emware.com) seems another
likely kind of thing, and in fact it seems pretty darned
intriguing; the EMIT SDK is only about $350, which seems
quite affordable.  However, the words on  PIC support seem
pretty darned squishy; it seems as if they had version 2.5
of EMIT running on a PIC16C74 about a year or so ago,
but that the support for that chip hasn't been carried
through to the new 3.0 version of the EMIT SDK. (Anybody
know anything about this?) The other problem I have with
this is that master end of EMIT is at best Windows NT;
I would much, much rather have a Unix-based control
stations (mostly because of my 15 years of using Unix
and the fact that Windows isn't multi-user in the same
way).

I've seen other packages advertised with various levels
of apparent relevance, but I've had trouble finding one
that held up under close examination.

So I guess the question I have for y'all is: Can you
make any suggestions here? What would you use? If the
answer is "my own protocol", do you sell it? :-) I'm
not necessarily looking for a free solution here,
just one that will work and save me a bunch of time.

Basically, what I'm looking for is a serial network/
protocol architecture with packaged software that
would support things such as the following:

* Stringing several PICs together in a bus network;
 across several buses, maybe 200-400 probes would
 need to be supported.
* At least 10kbps (~9600 baud) bandwidth per supported
 probe; 56kbps or more would be ideal. I imagine
 having only one transmitter and one reciever at
 a time, so the maximum data rate on the net itself
 doesn't have to be all that high. Although being
 able to interleave several virtual circuits at
 the same time would be real useful; this would
 be more a matter of maintaning state information
 rather than dealing with CSMA/CD type overhead;
 limiting this so that, say, all open current
 virtual circuits had to have the same master
 would probably be reasonable. Thus, if the
 master was a Unix system, you could have multiple
 users and processes pulling data from multiple
 sensors...
* Streaming support to pull large blocks of data off
 a single probe in a single transaction. (~10KB,
 say... a few seconds worth, anyway)
* Only one bus master at a time would be required,
 but it would be nice if a probe could just up and
 transmit a message onto a quiet bus without having
 to wait to be polled.
* Only short distances need to be handled, maybe 10-15
 meters at most, but this would be passing through
 EMI hell.
* Unix, especially Linux/X86, support is all but
 mandatory (as a target networked platform; I can
 deal with Windows as a develoment platform -- I
 don't like it, but I can deal with it).
* The bus master must be able to send control requests
 downstream to the probes. (Duh).

Thanks for any ideas or assistance that you can
offer, and sorry for being so long-winded.

--Bob

(*) We currently have about 25 40U (70") 19" machine racks
and will have an addtional 10 by mid-year; there will
be hundreds of devices to monitor, for example dozens
of UltraSPARC Unix servers, RAID storage enclosures,
Gigabit Ethernet switches, NT servers, etc. Most of
these devices are being integrated in-house, so we're not
talking RAS-enhanced Compaqs or anything like that. And
while many devices have integrated monitoring capabilities
(LM75s and the like), many do not and the ones that do have
widely varying interfaces, and in most cases can only be
monitored in-band with the operating system (not much good
if the system hangs up -- how do you remotely reset a dead
server over the network?). Most of these systems fall into
the mission-critical category, and we spend altogether
too much time in reactive mode, running down to the data
center to examine a sick system. I want to build in as
much early warning as is possible on things like fan
failures and A/C circuits pushing their limit. We also
have trouble with systems that have designed-in redundancy
(dual power supplies, or RAID-5 systems with multiple hot
spares) and the we don't get notified when the redundancy
is lost so that we can effect repairs before the system
fails altogether. I need to detect, if possible, when
these things happen.


(**) Microchip CAN press release:
http://www.microchip.com/10/Edit/pRelease/PR89/index.htm

--
============================================================
Bob Drzyzgula                             It's not a problem
.....bobKILLspamspam@spam@drzyzgula.org                until something bad happens
============================================================


'PIC Networking.'
2000\02\11@124114 by Russell Farnhill
flavicon
face
Hi all,

I want to build a 12 channel R/C Servo controller for a
six legged hexapod robot.

The controller needs to have positional feedback using
potentiometers, and current monitoring feedback to detect
obstacles and jams etc. The controller must be able to receive
commands from a master controller that deals with higher level
functions and also be able to send back information on the state
and position of each leg.

Each leg needs:
2 PWM signals for servos.
2 ADC channels for position feed back (Swing/Lift).
2 ADC channels for monitoring current e.g. jammed leg, obstacle, etc.

I thought of using one pic or micro controller to do the whole thing,
but maybe a modular approach would be better and have a pic controller
for each leg and network them all together. I was also thinking of having
a master supervisor pic that handles all the network traffic commands/info
from the main controller to the leg pic modules.

Also the controller would need some scope for future expansion as each leg
has currently got 2 servos giving a leg two degrees of freedom vert/horz,
but
I would like the option to add a third servo to each leg bringing the total
to 18 servos, This is why I thought a modular approach would be better.

My questions are:

Is this type of networking possible,easy,hard ?

What type of pic(s) would be suitable for the job of leg controller
and master controller ?

Does the whole architecture sound ok or is there better ways of
doing this ?


Cheers,

Russell.


'PIC Networking ideas ?'
2000\03\01@060317 by Russell Farnhill
flavicon
face
Hi all,

I want to build a 12 channel R/C Servo controller for a
six legged hexapod robot.

The controller needs to have positional feedback using
potentiometers, and current monitoring feedback to detect
obstacles and jams etc. The controller must be able to receive
commands from a master controller that deals with higher level
functions and also be able to send back information on the state
and position of each leg.

Each leg needs:
2 PWM signals for servos.
2 ADC channels for position feed back (Swing/Lift).
2 ADC channels for monitoring current e.g. jammed leg, obstacle, etc.

I thought of using one pic or micro controller to do the whole thing,
but maybe a modular approach would be better and have a pic controller
for each leg and network them all together. I was also thinking of having
a master supervisor pic that handles all the network traffic commands/info
from the main controller to the leg pic modules.

Also the controller would need some scope for future expansion as each leg
has currently got 2 servos giving a leg two degrees of freedom vert/horz,
but
I would like the option to add a third servo to each leg bringing the total
to 18 servos, This is why I thought a modular approach would be better.

My questions are:

Is this type of networking possible,easy,hard ?

What type of pic(s) would be suitable for the job of leg controller
and master controller ?

Does the whole architecture sound ok or is there better ways of
doing this ?


Cheers,

Russell.

2000\03\02@053547 by paulb

flavicon
face
Russell Farnhill wrote:

> The controller needs to have positional feedback using potentiometers,
> and current monitoring feedback to detect obstacles and jams etc.

 This sounds like duplication to me.  While it is nice to have current
feedback, surely an overload situation is detected when you command a
given movement and the positional feedback indicates it has not been
achieved in a reasonable time?

 If in fact you are using servos, these *already* have positional
feedback.  You could alternately use current monitoring and not position
indication and simply say that if the current is not excessive, the
servo *must* be in the position to which it was commanded.

 Three levels of current detection would probably suffice - stopped, in
motion, and blocked.  There are time sequences to be considered - it is
OK if the motor briefly flashes a "blocked" pulse as it starts, as long
as this settles.  Similarly it should stop sooner or later.

 Finally - I have some BG Micro servo assemblies - potentiometer, motor
but no logic.  Could be controlled by an H-bridge and one ADC channel.
Two PWM steps should suffice.  If you know how hard you are driving the
motor, its load is deduced from its rate of position change; if you are
driving it and it isn't moving at all, then it's obviously blocked.
There is the option to briefly power it up to full; if it still doesn't
move, then shut down.

 All-in-all, I think three control ports per FOM is something of a
luxury.  In fact, you have to decide how you *will* use the reduplicated
functions.  If for example, you are driving for a certain position as
indicated by the position sensors, how do you know what value to command
the servo so that it moves to that position, and only to that position?

> The controller must be able to receive commands from a master
> controller that deals with higher level functions and also be able to
> send back information on the state and position of each leg.

> I thought of using one pic or micro controller to do the whole thing,
> but maybe a modular approach would be better and have a pic controller
> for each leg and network them all together.

 By what protocol?  IÓC?  Serial bytes (as RS-232 but using 5V bus)?
SPI?  You may well use a lot of processing power of a small chip just to
perform the communication protocol - that is my biggest concern about
"distributed processing".

> I was also thinking of having a master supervisor pic that handles all
> the network traffic commands/info from the main controller to the leg
> pic modules.

 Elucidate?

> Also the controller would need some scope for future expansion as each
> leg has currently got 2 servos giving a leg two degrees of freedom
> vert/horz, but I would like the option to add a third servo to each
> leg bringing the total to 18 servos, This is why I thought a modular
> approach would be better.

 It does sound neat, and could for example use a serial (UART) bus,
split into "up" and "down" paths with leg controllers answering to polls
from the master.

 Consider also "segments" where a PIC controls two opposite legs, so
you have four PICs rather than seven.  Is one PIC16F87x cheaper than
two 16F84s (plus ADCs)?

> Is this type of networking possible,easy,hard ?

 I suspect the high-level part (movement command language) is
relatively easy, the low-level (simultaneous communication *and* servo
pulse generation) part, tricky.

> What type of pic(s) would be suitable for the job of leg controller
> and master controller ?

 Preferably ones with UARTs and/ or PWM hardware and ADC inputs if you
really want position sensing.  Like a PIC16F87x.

> Does the whole architecture sound ok or is there better ways of
> doing this ?

 Sounds like fun.  I'd think the simplest way to start would be either
the BG Micro servo core with H-bridges and DAC, or standard servos with
quad comparators (LM324 variant) registering a servo current threshold
or perhaps two thresholds.
--
 Cheers,
       Paul B.

2000\03\02@075038 by Russell Farnhill

flavicon
face
Hi Paul,

Thanks for the reply !

I have alaborated on a few points.


>   If in fact you are using servos, these *already* have positional
> feedback.  You could alternately use current monitoring and
> not position
> indication and simply say that if the current is not excessive, the
> servo *must* be in the position to which it was commanded.

I am using HI-Tech R/C servos and was thinking of tapping the position from
the
internal pot inside the unit. I think just current feedback will probably be
enough as you point out..

> > The controller must be able to receive commands from a master
> > controller that deals with higher level functions and also
> be able to
> > send back information on the state and position of each leg.

The master controller is a HANDYBOARD (68HC11 with 32K Ram) which
I built some time ago. Comms would preferably be TTL Serial line.

{Quote hidden}

Not sure on what protocol to use but something simple to program and
impliment
as I am only just starting out on PIC's

>
> > I was also thinking of having a master supervisor pic that
> handles all
> > the network traffic commands/info from the main controller
> to the leg
> > pic modules.
>
>   Elucidate?

Some kind of middle man pic which sits inbetween the pic leg modules and the
main
controller (HANDYBOARD). So the handyboard can say move forward 10 steps and
the middle
man can dish out all the relevent commands and step sequences to the leg
modules. This
would save the handy board having to send separate comands to each leg
module, well
thats the idea anyway.

{Quote hidden}

What do you mean by "up" n "down" paths ?

>
>   Consider also "segments" where a PIC controls two opposite legs, so
> you have four PICs rather than seven.  Is one PIC16F87x cheaper than
> two 16F84s (plus ADCs)?

I was guessing on one pic per leg as I was not sure if one pic could handle
the timing
of more than 2 PWM signal for each leg, but it would be nice to control to
legs with one
pic.

{Quote hidden}

Are the comparitors replacing ADC for current sensing ?
I thought ADC would be easier to calibrate in software rather than a
external hardware solution ?

> --
>   Cheers,
>         Paul B.
>

Thanks,

Russ.

2000\03\03@100954 by Jeffrey D Spears

flavicon
face
Hi Russell;
Funny you should mention all this--sitting here on the scratchpad
next to me is a quick little 'proof-of-concept' doodle of what
you are talking about.

At first I was thinking that a 12C6xx on each pin communicating
with a central cpu (16f876 on my drawing) via i2c. External
sensors (bumpers/IR/ultrasonics etc) communicate directly with
the 876. Without working out the details, it seems that 400Khz
I2C ought to work well for this type of application.

Am new to R/C servos. The information I see calls for a pulse
that ranges from 1ms to 2ms proportional to the desired
position every 10 to 20ms. When I think of using PWM's for
this, the every 10 to 20ms gets in the way. If you set the
PWM period to say 20ms, and then want to vary the duty cycle
to provide 1 to 2ms, the resolution seems to get pretty small.
On the other hand, if the PWM period were set to 2ms, then
the duty cycle could be varied between 50 and 100percent
with much better resolution--but how to seperate those
pulses by 10 to 20ms? Do you see the stumble here?

Therefore I figured that some little pics set up with timers and
interrupts could generate the desired signals fairly easily. The
documentation on the lynxmotion web-page says that two micro's
are generally used in this application.
What say you?

I have not considered using feedback pots or shaft encoders
since the servos handle the position feedback internally.

Have not ordered a Hexapod yet--still contemplating the idea.
Do you have one? Is it worth the price?

If I decide to purchase one, care to work together via the net?
Sometimes it is very nice having another to politely argue with over
issues that arrise.

I am an EE student on spring break. Will not have time to fool around
with fun things until end of April when school gets out.

ok..jef

On Wed, 1 Mar 2000, Russell Farnhill wrote:

{Quote hidden}

Jeffrey D. Spears
University of Michigan
College of Engineering

``Double-E, can't spell gEEk without it!''
                       -Captain Gerald M. Bloomfield II, USMC
                        (my brother)

2000\03\17@070704 by paulb

flavicon
face
Russell Farnhill wrote (some while ago - I realise):

> The master controller is a HANDYBOARD (68HC11 with 32K Ram) which
> I built some time ago.  Comms would preferably be TTL Serial line.

 The overall problem is in regard to having a *basic* PIC receive
serial data and generate pulses in software at the same time.  It just
doesn't add up.  If you have a UART, even without buffering, things get
much easier.  But... a solution is suggested.

> Not sure on what protocol to use but something simple to program and
> impliment as I am only just starting out on PIC's

 Serial comms will do, on an open-collector bus.

> Some kind of middle man pic which sits inbetween the pic leg modules
> and the main controller (HANDYBOARD).  So the handyboard can say move
> forward 10 steps and the middle man can dish out all the relevent
> commands and step sequences to the leg modules.  This would save the
> handy board having to send separate comands to each leg module, well
> thats the idea anyway.

 But it may not then have much left to do!  Otherwise, fair enough.

> What do you mean by "up" n "down" paths ?

 Generally, you have a path from master to slaves, and one from slaves
to master, the latter is always open-collector so any slave may drive
it.  However, you can use a single open-collector bus for both
directions.

 I would visualise a protocol where commands were sent in ten-character
(fixed-length, as will be seen) packets at 9600 baud (or 10 kbaud, or
9766 baud if that suits your crystals better) occupying 10 ms each.  In
the following 8 or 10 ms, the slave PICs would issue a 1 to 2 ms pulse
to each of three servos, or perhaps command packets could be six
characters followed by pulses to six servos with two legs per PIC.

 In either case, the PIC would recognise the end of the command stream
by a convention, and proceed to issue the pulses safe in the "knowledge"
that no more commands would be issued until it was ready again.

 If an answer was requested from a slave, this would be sent in the
next communication "slot" and all other PICs would use this instead as
the prompt for the next round of pulses.  Overall, this cycle would be
20 ms or shorter, the nominal PRR for the servos.

> I was guessing on one pic per leg as I was not sure if one pic could
> handle the timing of more than 2 PWM signal for each leg, but it would
> be nice to control two legs with one pic.

 It's more a matter of the above timing.  Most implementations of a PIC
(serial) servo controller seem to target about 8 servos maximum.

> Are the comparitors replacing ADC for current sensing?

 Yes.

> I thought ADC would be easier to calibrate in software rather than a
> external hardware solution ?

 Maybe, but 16F84s don't have them, and they're easiest to use.  If you
use an ADC, you still have to amplify the current shunt so it's either a
quad op-amp or a quad comparator.  I should have thought that for a
given servo unit, calibration would be a "test once and copy" matter for
detection of servo jam/ endstop detection, and the possible extension to
two bits for "easy/ difficult" motion, likewise.

 Anyway, there's my suggestion; a six- to ten-character packet protocol
should be oodles to implement a network with up to 8 or 16 slaves,
command/ poll and 16 or 8 alternate commands, all the foregoing coded by
the first character, the others being arguments.  What think ye?
--
 Cheers,
       Paul B.

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