>  Em 4/7/2010 05:23, solarwind escreveu:
> > I don't really know much about writing protocols or implementing them,
> > but I had the following idea. I don't really know if it's the "right"
> > way to go about it, so please comment on it.
> >
> > I'm trying to design a multi master protocol for RS485 networks
> > (specifically working on how the microcontroller will handle the data
> > at this point).
> >
> > The MCU will have an ISR as follows, which will be called every time a
> > byte is received:
> >
> > ISR() {
> >     if buffer not full
> >         push byte into a FIFO buffer
> >     start(processing_thread)
> > }
> >
> > processing_thread() {
> >     if frame complete (if we have a full, complete frame in the buffer)
> >         process_frame() (process the frame, handle the message, whateve=
r)
> >     stop(processing_thread)
> > }
> >
> > Pastebin link for those who have trouble reading the above formatted
> > text: http://pastebin.com/Z8YRt69k
> >
> >
> > In this way, the ISR stays relatively free most of the time. It only
> > executes some short code when a byte is received. So, even if the
> > processing of the message data takes a long time (for whatever
> > reason), the ISR is free to continue pushing data into the buffer.
> > Meanwhile, the processing thread runs "in the background" to handle
> > the received data.
> >
> > I would imagine that using an interrupt (rather than consistently
> > polling for data) is far more efficient. Is this the way it's usually
> > done in the microcontroller world? Or have I totally missed something?
> =

> Your idea is fine. It all depends on how you implement it.
> =


As others have said you can handle the frame decoding in the ISR itself and =

only call the processing_thread when you have a complete frame in order to =

increase efficiency.

Another thing I havn't seen mentioned here yet is the potential problem wit=
h =

collitions which have to be addressed since you are planning on making a =

multimaster protocol. A collition will happen if two masters tries to initi=
ate =

a message at roughly the same time. If you are planning to use standard RS4=
85 =

tranciever chips the masters themselves may not even notice the collition e=
ven =

if you read back the transmitted data since they actively drive the line to =

both polarities.

This can be solved with a bus that is only actively driven to one polarity =
and =

passively pulled to the other. This is how a CAN bus works.

If you don't want a bus that is only actively driven to one polarity (it wi=
ll =

be more succeptible to noise in the passive state) there are other methods =
to =

try to minimize the chance of a collition between masters to a low enough =

probability that it can be acceptable. One such way is to wait a random tim=
e =

after the bus has become quiet until the master starts to transmitt the nex=
t =

frame. In the unlikely event that two masters still will transmitt at the s=
ame =

time and not notice each other, the message will be messed up anyway and th=
e =

checksum/crc will catch the faulty message. Of course, you will need some s=
ort =

of ACK mechanism so the master knows that the message has not been received=
 for =

this to work. Instead of using a random backoff time, you could use a time =

based on the unique identifier address (which most likely exists anyway) fo=
r =

the master. This could give masters with a lower address a higher priority.

Good luck / Ruben
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
Ruben J=F6nsson
AB Liros Electronic
Box 9124, 200 39 Malm=F6, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
ruben@pp.sbbs.se
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

-- =

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist