Searching \ for '[EE] My RS485 Protocol - Please Evaluate' 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/io/serials.htm?key=rs485
Search entire site for: 'My RS485 Protocol - Please Evaluate'.

Exact match. Not showing close matches.
PICList Thread
'[EE] My RS485 Protocol - Please Evaluate'
2009\05\17@003307 by solarwind

picon face
After hours of research, I was unable to find a suitable realtime,
multi-master/peer-to-peer network protocol for RS485. So I made my
own. Please evaluate it and comment on it.

The protocol is designed to work over RS485, using an RS485
transceiver hooked up to a PIC's UART pins. 8 bit, no parity, 1 stop
bit. Maximum length of data segment of packet is 0xFF bytes long, but
since most midrange controllers don't have that much, I'll stick with
26 bytes.

The protocol has a token bus type topology (or at least that's what I
think it's called), so it's deterministic, collision free and real
time.

The packet looks like this:

<preamble> <destination> <source> <flags> <length of following data>
<data> ... <data> <checksum>

<preamble>: 1 byte. Start of packet. 0xAA.
<destination>, <source>: 1 byte each. 0x01 - 0xFE. 0x00 represents the
bus owner, configuration node or hub (unimplimented for now). 0xFF is
broadcast, for all nodes.
<flags>: 1 byte <0, 1, 2, 3, 4, 5, 6, 7>
0 - ACK - acknowledge
1 - NACK - no acknowledge (could not use the packet, for some reason)
2 - ACK_REQ - when sending, request an acknowledgement from target node
3 - ID_REQ - request identification information from the target node
4 - TYPE - is the data segment a special command type or a normal data type?
5 - TOKEN - this packet is a token and contains data of zero length;
all other flag bits must be zero
6 - not used/application specific
7 - not used/application specific
<length>: the length (in bytes) of the data segment that follows
<data>: the data (or command) segment itself
<checksum>: the 8 bit polynomial checksum

Notes:

The lowest ID on the bus has voice (starts with token). If it has a
message to send, it can send up to 4 packets. Then it MUST give up its
voice and give the token to the next node. -> The 5th (or less if it
has less or even no data to send) packet must be a token that it
passes to the next node. If the node has no data to send, it will pass
the token to the next node in the bus, which is it's own ID + 1.

IDs are static on the bus and are assigned incrementally (I want to
make them dynamic, though).

When a byte is received, it is buffered in memory in the "interrupt on
RX" function.

After the last byte (checksum) has been received, the packet is
checked, validated and used. It is discarded if the packet does not
belong to the node.

The packets shall be examined as CPU time permits.

One question to you all though: since this type of network requires
the constant examining of packets, I assume it takes a lot of CPU
time. If I have other things to do, how do I create "tasks" so that
the real tasks such as getting data from sensors, turning off the
lights, and so on is done on a high priority basis? I know that an
RTOS can do this, so do any of you know of any free RTOS that will run
on PIC16Fs? I also googled and found some info on multitasking using
PICs.

Please comment and leave your opinions on this protocol. Thank you!

-- [ solarwind ] -- http://solar-blogg.blogspot.com/

2009\05\17@014551 by Vitaliy

flavicon
face
solarwind wrote:
> The protocol has a token bus type topology (or at least that's what I
> think it's called), so it's deterministic, collision free and real
> time.
>
> The packet looks like this:
>
> <preamble> <destination> <source> <flags> <length of following data>
> <data> ... <data> <checksum>
>
> <preamble>: 1 byte. Start of packet. 0xAA.

Why do you need the preamble? Why not skip it, and start transmitting the
<destination> byte?


{Quote hidden}

I'm not clear about the whole packet-passing mechanism. How does the "lowest
ID on the bus" know it's the lowest ID? How does the token get handed over
to the next node? What happens if the token is lost?

Finally, why do you feel you need a token-based network?

Vitaliy

2009\05\17@023856 by solarwind

picon face
On Sun, May 17, 2009 at 1:45 AM, Vitaliy <spam_OUTspamTakeThisOuTspammaksimov.org> wrote:
> Why do you need the preamble? Why not skip it, and start transmitting the
> <destination> byte?

Good idea.

> I'm not clear about the whole packet-passing mechanism. How does the "lowest
> ID on the bus" know it's the lowest ID?

It's static for now. 0x01 is the lowest.

> How does the token get handed over
> to the next node?

Send it to the next id.

> What happens if the token is lost?

I don't know. Why would it get lost?

> Finally, why do you feel you need a token-based network?

Got any other ideas?

2009\05\17@025911 by cdb

flavicon
face
As you want multimasters, how about a slight amendment to your scheme?

Masters have an ID from 0x100 , slaves  0x01 - 0xFE or similar.

If nodes are predetermined to be Masters, then to be dynamic you could
have them check to see if they are the only Master online at switch
on, if it is, it assigns itself 0x100, if it searches and finds a node
within the 0x100 + range it assigns itself the highest master node
plus 1 address.

If they aren't then maybe a hardwire jumper scheme could force one
node to be a Master master and go from there.

I wonder if the DMX protocol might be of help for your purposes? Look
up DMX 256 and MIDI.

Colin

--
cdb, .....colinKILLspamspam@spam@btech-online.co.uk on 17/05/2009

Web presence: http://www.btech-online.co.uk  

Hosted by:  http://www.1and1.co.uk/?k_id=7988359

We cannot become what we need to be by remaining what we are. (Max de
Pree)


2009\05\17@040452 by Russell McMahon

face
flavicon
face
[[ Ken and John want to look at the EMC machine control stuff]].

> Please comment and leave your opinions on this protocol. Thank you!

1. Consider variable length packets.

2. Notwithstanding your commendable (really) research so far, there is
almost certainly something available already that does 80% of what you want
and 102% of what you really need.. Implementing something that already
exists allows you to stand on the shoulders of mutant pigmies* (or better).
You get the benefit of their pain and their experience. Depends muchly on
whether you want a tool or an experience.

This may be useful
uLan is message oriented multi-master communication protocol for
microcontrollers. It uses 9-bit character format for addressing and link
control and RS-485 physical layer. More RS-485 cards, converters for PC
RS-232 ports and embedded MCUs are supported


   http://sourceforge.net/projects/ulan/
   http://www.ohloh.net/p/ulan
   http://ulan.wiki.sourceforge.net/space/about
   http://ulan.sourceforge.net/


As might this

   swik.net/EMC-Enhanced-Machine-Controller
   https://launchpad.net/emc
   http://sourceforge.net/projects/emc
   www.isd.mel.nist.gov/projects/rcslib/emc_links.html
   emc-usersspamKILLspamlists.sourceforge.net/">http://www.mail-archive.com/.....emc-usersKILLspamspam.....lists.sourceforge.net/

or not :-).





  Russell

_RS485 _RS422 _uLan _emc



* No racist under or overtones implied here, figure of speech, these are not
the ones you want, move along, ...


2009\05\17@053110 by Russell McMahon

face
flavicon
face
- Tokens get lost. Murphy steals them.

- Collision detectionnon-token rule based transmit systems (CSMA/CD and
friends ) MAY have lower latency and/or higher throughput than token,
deep-ending on various factors.Under heavy loading token is liable to be
better.

 R

2009\05\17@054644 by Peter Onion

flavicon
face
On Sun, 2009-05-17 at 02:38 -0400, solarwind wrote:

> > What happens if the token is lost?
>
> I don't know. Why would it get lost?

That's a naive question.   Guess what .... Sh1t happens!

Consider what would happen if a node crashed while it was holding the
token.

PeterO


2009\05\17@063314 by Dario Greggio

face picon face
Peter Onion ha scritto:
> On Sun, 2009-05-17 at 02:38 -0400, solarwind wrote:
>
>> I don't know. Why would it get lost?
>
> That's a naive question.   Guess what .... Sh1t happens!

LOL :)

2009\05\17@100642 by olin piclist

face picon face
solarwind wrote:
> <preamble>: 1 byte. Start of packet. 0xAA.

Pointless.  All nodes should know where the start of packets are, else you
will have other problems anyway.  A signature byte doesn't guarantee start
of packet unless you guarantee it can never occur in the rest of the packet.
This can be done if necessary, usually by using a escape byte.  I wouldn't
do that here though.

> <checksum>: the 8 bit polynomial checksum

8 bits is very small for the size packets you are talking about.  It may be
good enough for your purposes if you don't really expect errors, which might
be applicable in your case.

> If the node has no data to send, it will pass
> the token to the next node in the bus, which is it's own ID + 1.

What happens when there is no node at this address or it went down or
doesn't respond for some other reason?  Somewhere you need to have a timeout
that allows recovering from dead node that has the token.  In your kind of
peer to peer network, it gets very tricky deciding how to recover.  Things
get somewhat easier if you have a single bus master that interrogates the
slaves in turn and handles the timeouts.

You also need to think about timeouts when a ACK is not received.  Think
carefully about what happens when the ACK itself is lost.  The receiving
node got the command, executed it, and sent the ACK.  The transmitting node
has to assume the receiver never got the command.  Most likely it will
resend after a timeout, but you have to think carefully about what the
receiving node might do if it receives two separate valid commands.  A
sequence number is the usual way around this, but there are other
strategies.

This is a bit of a aside, but you should go read the RFC for TCP.  I know
you're not trying to implement TCP, but it is a quite readable document that
deals with a lot of the same issues you have created for yourself.  You will
see that people have thought about and solved these problems long before you
were born.

> The packets shall be examined as CPU time permits.
>
> One question to you all though: since this type of network requires
> the constant examining of packets, I assume it takes a lot of CPU
> time.

Not really.  The bigger problem with small systems like PICs is the buffer
space to hold packets.  The checksum forces storing the whole packet before
acting on any of it.  You may want to limit the maximum packet size for this
reason alone.  For example, you have pretty much made it impossible for a
16F or lower to participate in this protocol.

However, the cycles for validating and interpreting a packet are pretty
minimal.  Think how many cycles you have per bus byte.  At 115.2Kbaud each
byte takes 87uS.  That's 434 instruction cycles per byte assuming a 20MHz
PIC, and it takes a few bytes at least for a packet.  Even with short
packets you have a couple of 1000 instructions to spend.  The packet
processing overhead will be a tiny fraction of that.  Of course it may take
more to perform the command itself, but that is up to how you define the
commands.

> If I have other things to do, how do I create "tasks" so that
> the real tasks such as getting data from sensors, turning off the
> lights, and so on is done on a high priority basis?

You don't need priorities, since you've got plenty of CPU time to go around.
A simple round robin task manager should be just fine for this.  Each task
does whatever it can do immediately, then calls TASK_YIELD to let all other
tasks run once.  When a task is waiting on a external event, it sits in a
loop checking the event and calling TASK_YIELD until the event condition
occurs.

Take a look at my QQQ_TASK.ASPIC template source module.  It implements just
such a simple task manager for a PIC 18.  I've used it a bunch of times when
it is convenient to have several independent threads each doing a simple
task.

This kind of firmware architecture is often useful when dealing with
asynchronous input streams.  Input streams usually need some sort of state
machine to interpret them.  A conventional state machine is cumbersome, but
a task written such that the PC becomes the state variable often makes the
code work out nicely.  It's often a very useful abstraction to have the
input processing code appear to go and get the next input byte even though
the input byte comes in when it comes in.  A task is a easy way to get this
abstraction.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\17@101628 by olin piclist

face picon face
Russell McMahon wrote:
> 1. Consider variable length packets.

He did.  I distinctly remember a length byte.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\17@102138 by olin piclist

face picon face
solarwind wrote:
>> What happens if the token is lost?
>
> I don't know. Why would it get lost?

Wrong question.  Stuff happens.  Packets will get garbled and lost.  Nodes
will go down.  The right question is what to do about it when it happens.
As I understand it now, your network will freeze indefinitely when a node
goes down and is passed this token.  It *will* happen, whether you can
imagine the mechanism or not.

For one thing, every last bit you transmit will not make it.  You are using
dedicated wires over relatively short distances.  Your bit error rate will
be low, but never zero.  All it takes is the refrigerator kicking in sending
a short broad spectrum pulse thru all the house wiring.  There are many
other mechanisms for bit errors I'm not going to try listing.  Know it will
happen and plan accordingly.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\17@121558 by Dr Skip

picon face
solarwind wrote:
> I don't know. Why would it get lost?

I haven't followed this thread, other than a casual look at random posts, but
this statement caught my eye as being so antithetical to engineering
methodology that it deserved a response. Don't bother wondering about the
genesis of all the mechanisms that may ruin your design approach, other than to
identify test cases. First, simulate (on paper, on the bench, etc) every
combination of disaster that might occur. Lost nodes, noise, lines pulled high,
pulled low, and so on, even if you don't think it will ever happen. This is
especially important in architecture or protocol design.

Many a recall has occurred because the designer didn't think a certain pattern
of environmental effects would or could happen. Many others have become just
failed products.

The best way is to start big - lost nodes, non responding nodes, nodes that
have freq. drift, etc. If possible, given that you have software involved, have
'the other end' try to determine the problem or set an error code. This will
help in problem solving later. Some failures may be so big later on that you
may need to look at everyone's error codes to get a picture of the whole
system! Figure out what the system looks like if the one producing the error
code goes bad... Bad events can trigger worse events, so it isn't necessarily a
static exercise.

If you think about it, most people who have experience building things in the
physical realm out of wood, steel, etc have a sense about this and do it. They
reinforce critical parts, even more so if a life could be lost, and they
purchase stronger materials for other areas that might fail if, all by looking
at failure modes.... It just takes a more structured and meticulous approach in
the EE realm because we can't 'see' what's going on directly. It's just a giant
maze where the electrons will play, and we need to know what will happen if
they all end up on one side of our maze, or such. ;)

AFTER taking all the cases into consideration and accounting for them, THEN
look at the 'why', especially for the more disastrous cases. THEN you can
implement things that would reduce the chance of that happening. You'll never
reduce it to zero though, but then you'll have a multi-level protection against
such happening.

Your engineering skill and experience will also come into play. There WILL be
cases you'll miss. If you approached it in the beginning without trying to
counter everything, you won't have any cognitive feedback loop to develop your
engineering skills. IF you do try, then you can slap your forehead and say "how
could I have missed that one!". This gives you an opportunity to develop your
thinking as well.

-Skip

2009\05\17@131123 by solarwind

picon face
I very much appreciate all of your suggestions and responses. Since  I
can not target just one or two emails, I will post without a quote.

I have found a site which discusses all the different types of
protocols: http://www.ece.cmu.edu/~koopman/protsrvy/protsrvy.html

I think that for my purposes, the token bus type works very well
because each node is guaranteed voice every x milliseconds (depending
on the number of nodes on the bus).

However, the CSMA/CD seems to be tempting as it is simple to implement
and it works most of the time. However, the problem there is "how to
detect collisions". My idea was to listen to your own transmission and
ensure they are equal (by enabling the receiver and driver of the
RS485 chip), but multiple people said this is not a good way to detect
collisions. I don't know how else to do it.

I also looked at uLan. What kind of network is it?

And the polling type of network seems to be another cool choice where
the bus owner polls the devices to see if anyone wants to talk. What
happens when the bus owner goes down?

Similarly, I could attach a bus owner node to my network as described
in the first post, to act as a registrar. It would keep track of the
token, and if it gets lost, reboot the network. Would that work?

-- [ solarwind ] -- http://solar-blogg.blogspot.com/

2009\05\17@185345 by solarwind

picon face
Wrote blog post about this:
http://solar-blogg.blogspot.com/2009/05/my-rs485-network-protocol.html

At the bottom of the blog post, after the "Further:" heading, I tried
to think of some possible solutions.

Can you guys please view that and post what you think? I can't post
directly on the list because of the formatting (I tried to use point
form so it's easier to understand).

2009\05\18@001408 by Byron Jeff

flavicon
face
On Sun, May 17, 2009 at 01:11:03PM -0400, solarwind wrote:
> I very much appreciate all of your suggestions and responses. Since  I
> can not target just one or two emails, I will post without a quote.

Good idea.

>
> I have found a site which discusses all the different types of
> protocols: http://www.ece.cmu.edu/~koopman/protsrvy/protsrvy.html

Interesting read.

> I think that for my purposes, the token bus type works very well
> because each node is guaranteed voice every x milliseconds (depending
> on the number of nodes on the bus).

As stated in other posts, the biggest issue is managing a lost token. Any
token mechanism trusts each node to do their job properly. If any node
screws it up, the network locks up permanently.

> However, the CSMA/CD seems to be tempting as it is simple to implement
> and it works most of the time. However, the problem there is "how to
> detect collisions". My idea was to listen to your own transmission and
> ensure they are equal (by enabling the receiver and driver of the
> RS485 chip), but multiple people said this is not a good way to detect
> collisions. I don't know how else to do it.

There's no effective way to do it with async transmissions. Two nodes
driving the line asyncronously can cause all types of funky effects.

The best way to manage collisions is simply not to have them.

> I also looked at uLan. What kind of network is it?

>From first glance it's a rotating reservation slot system that uses the
break character to seize the line and manage line arbitration. Slot
reservation based on the previous master makes it pseudo token passing when
all nodes are busy. Not a bad design overall.


> And the polling type of network seems to be another cool choice where
> the bus owner polls the devices to see if anyone wants to talk. What
> happens when the bus owner goes down?

You have to have some sort of election of a new bus owner. You rejected the
polling solution a while ago when someone suggested a single master. That's
what a polling system is.

> Similarly, I could attach a bus owner node to my network as described in
> the first post, to act as a registrar. It would keep track of the token,
> and if it gets lost, reboot the network. Would that work?

Still gives a single point of failure, which is why some type of slot
reservation system seem to be inherently better even if it's just to
reestablish the token. The nice thing about token passing is that you don't
have to wait for a timeout to occur in order to select the bus, because the
receiver of the token is automatically granted bus ownership. But if the
token holder dies or the token is corrupted, then regaining control with a
slot reservation system gives a much more robust chance to rebuild the
token network than pinning the responibility on a single node. The one
thing about any token passing system is that the network will be busy at
all times, even if nothing is happening other than passing the token. So if
the network goes idle, then the token is lost. Every node has a idle
network timeout of ID+some delay characters (say 10 for the sake of
argument). So for node #1 if the network is idle for 11 character slots,
then it will start to rebuild the token network. The problem is that #1
doesn't know who's the next to pass the token. So #1 broadcasts their ID
and then removes itself from participating in the rebuild. So on the next
timeout, the next lowest node will pick up the stick and so forth. It's
slow sledding to get the token net rebuilt, but it can be done and be done
even in the face of some nodes bring down.

uLan seems to be a good compromise allowing for line arbitration at any
time. But there's a cost for non deterministic arbitration.

BAJ

2009\05\18@003011 by Vitaliy

flavicon
face
solarwind wrote:
>> Finally, why do you feel you need a token-based network?
>
> Got any other ideas?

I work with automotive protocols a lot, and the J1850 approach to avoiding
collisions sounds like it would work in your case.

There are two states: dominant and recessive. Let's say you have weak
pull-ups on your bus, and each node can only drive the bus down. So positive
level is your recessive state, and "ground" potential on the bus is your
dominant state.

Let's say now that two nodes start transmitting at the same time. While they
are transmitting, they are also monitoring the state of the bus. If a node
transmits a recessive bit, but reads it back as a dominant, it knows it lost
arbitration, and has to wait for idle bus again. The second node continues
transmitting as if nothing had happened.

Same thing happens behind the scenes, on CAN.

I don't see any advantage to a token-based network, unless your events are
very time-critical, and your bandwidth is very limited.

Vitaliy

2009\05\18@003819 by Vitaliy

flavicon
face
Dr Skip wrote:
> I haven't followed this thread, other than a casual look at random posts,
> but
> this statement caught my eye as being so antithetical to engineering
> methodology that it deserved a response. Don't bother wondering about the
> genesis of all the mechanisms that may ruin your design approach, other
> than to
> identify test cases. First, simulate (on paper, on the bench, etc) every
> combination of disaster that might occur. Lost nodes, noise, lines pulled
> high,
> pulled low, and so on, even if you don't think it will ever happen. This
> is
> especially important in architecture or protocol design.

While I agree that this approach has merit, I think it may be overwhelming
for someone who is just starting out. My advice would be to start with an
off-the-shelf protocol (many people suggested CAN). As you put it together,
you will find yourself saying "aha!" when you start realizing why things are
done a certain way. This is way better than finding yourself saying "doh!"
when you begin to understand the reasons why your experimental system
doesn't work.

This sort of approach works for many things. It is often easier to take a
working system, and tweak it until it does what you want, instead of writing
one from scratch. Even if you end up rewriting it from scratch anyway.

Vitaliy

2009\05\18@004436 by Xiaofan Chen

face picon face
On Mon, May 18, 2009 at 12:37 PM, Vitaliy <EraseMEspamspam_OUTspamTakeThisOuTmaksimov.org> wrote:

> This sort of approach works for many things. It is often easier to take a
> working system, and tweak it until it does what you want, instead of writing
> one from scratch. Even if you end up rewriting it from scratch anyway.
>

On the other hand, I think what Solarwind has done is really remarkable
for his age.

And sometimes it is good to start from scratch and really get innovative.
In this case he does not have time to market issues and thus he
can have more choices.

--
Xiaofan http://mcuee.blogspot.com

2009\05\18@010256 by Vitaliy

flavicon
face
Xiaofan Chen wrote:
>> This sort of approach works for many things. It is often easier to take a
>> working system, and tweak it until it does what you want, instead of
>> writing
>> one from scratch. Even if you end up rewriting it from scratch anyway.
>>
>
> On the other hand, I think what Solarwind has done is really remarkable
> for his age.

True. Although I wish he was a wee bit less overconfident. :)

BTW, why "on the other hand"? I don't think that what you said, contradicts
what I wrote above.


> And sometimes it is good to start from scratch and really get innovative.
> In this case he does not have time to market issues and thus he
> can have more choices.

The danger here is that even seasoned engineers get frustrated and bored
with their hobby projects. There's no better way to boost one's motivation,
than to actually complete a project. There are few things worse than having
people remind you about that calculator project you started a year ago.

Using an off-the-shelf solution does not mean you can't start from scratch
and "really get innovative." It means you'll learn new things, have a better
chance of successfully completing your project, and have more fun doing it.

Vitaliy

2009\05\18@011110 by Vitaliy

flavicon
face
Olin Lathrop wrote:
>> <checksum>: the 8 bit polynomial checksum
>
> 8 bits is very small for the size packets you are talking about.  It may
> be
> good enough for your purposes if you don't really expect errors, which
> might
> be applicable in your case.

I disagree. An 8-bit CRC is used in automotive protocols (including CAN),
which were specifically designed for noisy environments.


> You also need to think about timeouts when a ACK is not received.  Think
> carefully about what happens when the ACK itself is lost.  The receiving
> node got the command, executed it, and sent the ACK.  The transmitting
> node
> has to assume the receiver never got the command.  Most likely it will
> resend after a timeout, but you have to think carefully about what the
> receiving node might do if it receives two separate valid commands.  A
> sequence number is the usual way around this, but there are other
> strategies.

- Avoid "vague" commands ("toggle") in favor of more specific ones ("turn
off")
- Have the transmitter request the status before issuing the command again


{Quote hidden}

I'm curious, why do you think a task manager would be useful in this case?

Vitaliy

2009\05\18@012854 by solarwind

picon face
On Mon, May 18, 2009 at 1:10 AM, Vitaliy <spamspamspam_OUTmaksimov.org> wrote:
> I'm curious, why do you think a task manager would be useful in this case?

I've worked with QNX tasks before and I still have that "make it into
a task" mentality. So I just thought that I might make a task to
handle the protocol, since all that the interrupt on RX does is buffer
the bytes in memory. We need a task to take care of the protocol. Is
this a bad idea? How does one in the professional engineering world go
about it?

2009\05\18@072418 by Dave Tweed

face
flavicon
face
Vitaliy wrote:
> Olin Lathrop wrote:
> > ... you have to think carefully about what the receiving node might
> > do if it receives two separate valid commands. A sequence number is
> > the usual way around this, but there are other strategies.
>
> - Avoid "vague" commands ("toggle") in favor of more specific ones
>   ("turn off")

Specifically, look up the term "idempotent", especially as it applies to
computer networks.

-- Dave Tweed

2009\05\18@082341 by olin piclist

face picon face
part 1 1577 bytes content-type:text/plain; (decoded 7bit)

solarwind wrote:
> I think that for my purposes, the token bus type works very well
> because each node is guaranteed voice every x milliseconds (depending
> on the number of nodes on the bus).

There are other ways to guarantee this.  I think the vast majority of RS-485
networks use a bus master system.  This simplifies a lot of stuff.  I did
one a while back where the master addressed each slave in turn.  If the
slave had nothing to send, it responded with a NACK so that the master would
know to go on to the next slave.

In my system, the configuration wasn't known up front, but the maximum
number of slaves was limited to 15.  The bus master kept track of which
slave addresses were in use to avoid the timeout for the unused ones each
time thru the list of slaves.  If a slave timed out three times in a row, it
got crossed off the list.  Once per loop, the master would try one unused
address.  If a slave responded, it would be added to the active list.  This
allowed hot-swapping and powering slaves up and down, which was important
for this particular system.

This was done 10 years ago on hardware that was designed before that.  The
biggest bestest PIC at the time was the 16F877.  CAN hardware wasn't that
readily available yet.  A few years later and I definitely would have argued
for using CAN instead.

This project is long dead, so I can give more details on it.  I have
attached the protocol document.

As I have said consistantly though, I still think you're better off using
CAN and a 18F4580 or similar.


part 2 13699 bytes content-type:text/plain;
(decoded 7bit)

      FliteSim Embedded System Serial Bus Protocol, Version 4.2

This document gives a brief overview of how the embedded system serial
bus fits into the overall architecture, then describes the protocol
used on that bus.


Revision History

 Only the latest revision of this specification is valid.  This
 section is provided for convenience only to point out important
 changes.

 All revisions are classified as either minor or major.  Major
 revisions change the rules such that a previously compliant master or
 slave may need to be updated.  Major version numbers go up by one for
 each major revision.  Minor revisions do not change any rules such
 that a previously compliant master or slave would need to be
 modified.  These revisions might clarify ambiguities, provide more
 background, fix typos or formatting, etc.  Minor version numbers
 start at zero and go up by one within each major version.

 Version 1.0, 20 Jan 1999

      Original version.  Checksum algorithm not specified.

 Version 1.1, 22 Jan 1999

      Typo fix.

 Version 2.0, 3 Feb 1999

      Added "Bus Turnaround" section.  Specifies wait time after
      receive to transmit bus interface reversal.

 Version 2.1, 4 Feb 1999

      Checksum algorithm specified.

 Version 3.0, 5 Feb 1999

      Slave device now returns configuration data in HELLO ACK
      packet.

 Version 4.0, 9 Feb 1999

      Added sender address to packet header.

 Version 4.1, 27 April 1999

      Decreased packet and response timeouts from 10 to 5
      milliseconds.

 Version 4.2, 23 September 1999

      Fixed version number in title and typos.  No substantive
      changes.


System Overview

 The overall flight simulator system contains three main computers,
 called the IOS, visual, and cockpit.

 The IOS computer is the main system controller.  It is a PC running
 Windows NT.  This is where the flight model is computed, and where
 the instructor interacts with the simulator.

 The visual computer produces the out-the-window view presented to the
 pilot.  This is a PC running a standalone program on Windows 95 or
 98.  The visual database is on this computer, and it receives
 information from the IOS computer that mostly indicates the plane's
 position and orientation within the visual world.  The link to the
 IOS computer is currently an RS-232 serial line, and may be changed
 to ethernet in the future.

 The cockpit computer is where all the cockpit instruments are
 directly connected.  This is an Intel Pentium processor on an STD
 bus.  Most of the cockpit instruments are connected to the STD bus
 via various digital I/O, A/D, and D/A cards.  The main job of the
 cockpit computer is to drive these devices.  Device values are
 communicated to/from the IOS computer once every flight model frame
 time, which is currently 20 milliseconds.  The link to the IOS
 computer is 10Mb/Sec ethernet.

 The cockpit computer also communicates with some devices via an
 RS-232 port.  This is converted, using an external adapter, to an
 RS-485 serial bus.  This is the "embedded system serial bus" referred
 to above.


Serial Bus

 The main purpose of the serial bus is to reduce the number of
 individual wires that would otherwise need to be connected to the
 digital I/O cards on the STD bus.  In particular, the serial bus is
 intended for I/O to the simulated cockpit radios.  Each radio (or
 other clump of devices) is presented as one device on the serial
 bus.  Each serial bus device is implemented with a Microchip PIC
 processor running custom firmware for this purpose.  Each PIC is
 directly connected to whatever specific devices it drives, and
 communicates the device values to the cockpit computer via a common
 protocol over the serial bus.


Serial Bus Protocol

 The RS-485 standard is electrical only, and does not address
 collision avoidance or flow control.  The purpose of this protocol is
 to provide collision prevention, flow control, and reliability over a
 serial connection which is assumed to have a small but non-zero bit
 error rate.

 Each device on the serial bus is assigned a unique 4 bit address,
 from 0 to 15.  Device 0 is the bus master, and the remaining devices
 are slaves.  All bus activity is initiated by the master.  Slaves
 never write data to the bus without having been told to do so by the
 master.  The cockpit computer is the bus master, and each of the PICs
 is a separate slave with a separate bus address in the 1-15 range.


Packet Format

 All communication on the serial bus is encapsulated in packets.  All
 packets adhere to the following format:

   byte 0:      opcode and target address
   byte 1:      source address
   byte 2:      N (number of data bytes, 0-255)
   byte 3:      first data byte, if N >= 1
    ...
   byte N + 2:  last data byte, if N >= 2
   byte N + 3:  checksum low
   byte N + 4:  checksum high

 This format allows all bus devices to know when a packet starts and
 ends, without having to know the meaning of the data bytes.  Each
 packet therefore has five overhead bytes beyond the raw data bytes
 being transferred.  The following descriptions give more detail on
 each of the five control bytes.

   Opcode and Target Address

        This is the first byte in a packet, and contains two fields.
        The low nibble is the target device bus address, and the high
        nibble is an opcode.  The opcode describes the overall purpose
        of the packet.  The list of opcodes and their meaning is given
        later.

        Only the addressed target device should act on the packet.
        Other devices on the bus must only determine when the packet
        has ended.  The next byte on the bus is then again interpreted
        as the first byte of a new packet.

   Source Address

        The sender's bus address is in the low 4 bits.  The upper 4
        bits are reserved and should be set to 0 by senders and
        ignored by receivers.

   Number of Data Bytes

        This indicates the number of data bytes immediately
        following.  Note that this could be zero.

   Checksum Bytes

        A 16 bit checksum is computed on all preceding bytes of the
        packet.  The exact method of computing the checksum is
        decribed later in the section titled "Checksum Algorithm".

        A packet is only considered valid and possibly acted upon when
        the received checksum matches the checksum computed by the
        receiver based on the previous bytes of the packet.  IF THE
        CHECKSUM DOES NOT MATCH, THE PACKET MUST BE COMPLETELY
        IGNORED.

        Note that all parts of the packet, including the length byte,
        are suspect on a checksum error.  This means the receivers may
        be out of sync with the transmitter.  The error recovery
        strategy is discussed in "Error Recovery", later in this
        document.

 Opcodes

   The high nibble of the first byte of each packet is an opcode that
   describes the overall purpose of the packet.  The meaning of each
   of the opcodes is described below.  All opcodes not described here
   are reserved and should not be sent.  Receivers should ignore all
   packets with unrecognized opcodes.

   The opcodes are:

     0 - HELLO

          This is always sent by the master to a slave address.  The
          reciever must respond with a HELLO ACK packet to the
          master.  This is used by the master to determine whether a
          slave exists at that address.  The data bytes are not used.

     1 - HELLO ACK

          This is sent by a slave to the master in response to a HELLO
          packet.  The slave sends configuration info as data bytes.
          These data bytes are:

          byte 0  -  Maximum output bytes slave can possibly accept.

          byte 1  -  Maximum input bytes slave will ever send.

          byte 2  -  Name length.  Number of bytes in device name
               string to follow.

          bytes 3-N  -  Device name string.  The string length must be
               exactly the number of bytes as indicated by data byte
               2.

          The slave input and output size is used by the master to
          reduce unecessary data transfers.  A "lazy" slave can simply
          report 255 for both values without causing any
          malfunctions.  The name string is not required, but may aid
          in debugging.  A lazy slave can just set the name length
          byte to 0, which requires no following string bytes.

     2 - OUT AND REQ

          Transfers data from the master to the slave, and requests
          return data.  The slave must respond with an IN packet.

     3 - IN

          Transfers data from a slave to the master.  This packet must
          only be sent when requested.

 Checksum Algorithm

   A 16 bit checksum is computed on all bytes of a packet except the
   checksum bytes themselves.  The resulting value is then sent as the
   checksum for outgoing packets, or compared with the packet checksum
   bytes for incoming packets.  All incoming packets must be ignored
   if the checksum from the packet does not match the expected
   checksum exactly.

   Before any packet bytes are processed, the checksum is initialized
   to 5555h.  The following procedure is then applied for each packet
   byte that is included in the checksum, in packet order:

     1)   The current accumulated checksum is rotated one bit left.
          This means bits 14:0 are moved to bits 15:1 and bit 15 is
          moved to bit 0.

     2)   The byte value is added to the accumulated checksum.  The
          carry, if any, is lost.

     3)   The ones compliment of the byte is added to the high byte of
          the accumulated checksum.  The carry, if any, is lost.

   The accumulated checksum is the packet checksum value once this
   process is completed for all the applicable packet bytes.


Bus Turnaround

 When there is no bus activity, the master is driving the bus, and the
 slaves are receiving.  When the master tells a slave to send data,
 both the master and slave must switch their bus interfaces to the
 opposite transmit/receive mode, and again when the slave has finished
 transmitting.  The new transmitter must not send data until the new
 receiver has finised reversing its bus interface.  To guarantee this,
 both devices must reverse their bus interfaces as soon as possible,
 but the new transmitter must delay sending.  The transmitter must
 wait a minimum time after receiving the last input byte before
 sending the first output byte.  This timeout is currently set to 1
 millisecond.


Error Recovery

 It is important that bus data errors can be recovered from within a
 short time.  To accomplish this, all receivers on the bus must follow
 these rules:

   1)   IGNORE ON ERROR.  All packets with checksum errors, unexpected
        source, or other inconsistancies or errors must be completely
        ignored.  This means an entire packet is either lost or is
        received whole.  Note that the transmitter has no direct way
        to determine whether a packet was received or not.

   2)   PACKET TIMEOUT.  Any partially transmitted packet must be
        assumed to have ended when no new characters are recieved for
        the timeout interval.  This interval is currently set to 5
        milliseconds.

   3)   RESPONSE TIMEOUT.  If a response was expected from a slave to
        the master, no valid response packet was received, and no
        bytes at all are received for the timeout interval, then the
        master gives up waiting for the response.  The master may then
        retry the request, continue on, or whatever.  This prevents a
        lost packet in a request/response sequence from hanging the
        bus for a long time.  Note that this puts constraints on the
        slaves for a maximum turnaround time from request to
        response.  This timeout is currently set to 5 milliseconds.


Data Organization

 Each slave maintains up to 255 input and output data bytes, for a
 total of up to 510 data bytes.  "Input" and "output" are from the
 point of view of the master.  Therefore, output data is transferred
 from master to slave, and input data from slave to master.  The
 meaning of these data bytes is specific to the particular slave
 implementation and the hardware it is connected to.

 Data within a packet is transferred starting with byte 0.

 Output data packets may contain more bytes or less bytes than
 maintained by the slave.  Additional bytes are ignored and unsent
 bytes retain their old value.  For example, suppose a slave maintains
 7 output bytes.  If the master sends 10, then all 7 bytes are updated
 and 3 are ignored.  If the master sends 5, then only the first 5
 bytes are updated and the remaining two are unaltered.

 Slaves may respond with any number of input bytes.  There is no
 requirement that all maintained input bytes be sent, only that a
 frame is sent when requested.  The master will assume any unsent
 input bytes have not changed.

 The cockpit computer will make little or no assumptions about the
 meaning of any data bytes.  It will simply maintain 255 input and
 output data bytes for each slave.  These can be referenced in the
 FSIMIO.DEV file on the IOS computer by the slave device number
 (1-15), in or out, and the data byte address (0-254).


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2009\05\18@082427 by Isaac Marino Bavaresco

flavicon
face
Dave Tweed escreveu:
> Vitaliy wrote:
>  
>> Olin Lathrop wrote:
>>    
>>> ... you have to think carefully about what the receiving node might
>>> do if it receives two separate valid commands. A sequence number is
>>> the usual way around this, but there are other strategies.
>>>      
>> - Avoid "vague" commands ("toggle") in favor of more specific ones
>>   ("turn off")
>>    
>
> Specifically, look up the term "idempotent", especially as it applies to
> computer networks.
>
> -- Dave Tweed
>  

I use two sequence numbers, one for the packet and other for the command
itself. It is useful for networks with routing where the packets may
arrive out of order or multiple times due to routing problems.

If the sequence number of the arriving packet if less or equal to the
last received one, just ignore it. If it is newer (inside a
predetermined window), check the command sequence number. If the command
sequence number is exactly equal to the last one, just resend the last
answer but don't execute anything. If the command sequence number is
newer (inside a window limit), execute it, send the answer and store the
answer.

There must be provision for a synchronization packet which is not
sequenced itself.

Regards,

Isaac


__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\05\18@082519 by olin piclist

face picon face
solarwind wrote:
> And the polling type of network seems to be another cool choice where
> the bus owner polls the devices to see if anyone wants to talk. What
> happens when the bus owner goes down?

You're screwed.  But think about it.  What useful function can the system
perform without the central controller anyway?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\18@082811 by olin piclist

face picon face
solarwind wrote:
> Wrote blog post about this:
> http://solar-blogg.blogspot.com/2009/05/my-rs485-network-protocol.html
>
> At the bottom of the blog post, after the "Further:" heading, I tried
> to think of some possible solutions.
>
> Can you guys please view that and post what you think?

No.  I'm not going to chase down some blog.  If you can't be bothered to
write a succinct question and format it properly to post here, then I'm not
going to bother either.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\18@083308 by sergio masci

flavicon
face


On Sun, 17 May 2009, Vitaliy wrote:

{Quote hidden}

This implies that comms between two nodes is "serial" i.e. commands and
responses must ping pong back and fore between two nodes (say A and B)
before comms between other nodes can be accepted by either A or B
otherwise things start getting really hairy.

The other thing to consider is what happens if the "turn off" command is
sent before the "turn on" command but arrives AFTER the "turn on" command.
Here "toggle" actually is an advantage. Yes packet sequence numbers are
definiately very useful for deciding what to do here.

Regards
Sergio Masci

2009\05\18@084844 by Dario Greggio

face picon face
Isaac Marino Bavaresco ha scritto:
> I use two sequence numbers, one for the packet and other for the command
> itself. It is useful for networks with routing where the packets may
> arrive out of order or multiple times due to routing problems.

interesting...

> If the sequence number of the arriving packet if less or equal to the
> last received one, just ignore it. If it is newer (inside a
> predetermined window), check the command sequence number. If the command
> sequence number is exactly equal to the last one, just resend the last
> answer but don't execute anything. If the command sequence number is
> newer (inside a window limit), execute it, send the answer and store the
> answer.

...worth investigating more. I agree on the second part, but why having two?

> There must be provision for a synchronization packet which is not
> sequenced itself.

could you explain more this one?

2009\05\18@084916 by Marechiare

picon face
> ...It is often easier to take a working system, and tweak
> it until it does what you want, instead of writing one from
> scratch. Even if you end up rewriting it from scratch anyway.

I agree, BTW.

2009\05\18@085944 by Isaac Marino Bavaresco

flavicon
face
Isaac Marino Bavaresco escreveu:
{Quote hidden}

Forgot to comment the sender side behavior:

When sending a new command, just pick the next packet sequence number
and the next command sequence number.
If didn't get response and need to resend the command, pick the next
packet number but use the same command number. This way the receiver
will never execute the same command more than once, even if the sender
needs to resend it several times.

After resending a command a predetermined number of times without
success, assume an out-of-synch condition and enter a re-synching mode.
If the sender only sends a command after receiving the answer for the
previous, the commands will always be executed in the correct order,
even with a lot of retransmissions and misrouted packets, although with
some delay.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\05\18@094059 by olin piclist

face picon face
Marechiare wrote:
>> ...It is often easier to take a working system, and tweak
>> it until it does what you want, instead of writing one from
>> scratch. Even if you end up rewriting it from scratch anyway.
>
> I agree, BTW.

Easier, sometimes (not as often as people seem to think), but that is not
always the objective.  Trying to implement something yourself based only on
seeing other things work can be a real eye opener.  The educational value of
running into the same problem others faced, then realizing that's why that
other system has a particular quirk is way better than having it told to
you.

I remember learning way more about operating systems in general by writing
one from scratch in assembler on a small minicomputer.  I missed a few
things, like a tree structured file system, but I also got a few things
right and actually came up with a some clever ideas of my own (dynamic
relocatable linking for example) because I had the advantage of not knowing
the "right" way to do something.  The end result was a lot better than the
poor excuse for a operating system this computer had before, and my OS was
still in regular use 4 years later when I left there.

The point is that it wasn't any kind of super operating system, but by going
thru the design process I came face to face with tradeoffs other operating
system designers encountered, and a lot of seemingly arbitrary quirks in
other systems suddenly made a lot more sense.  It also made it easy to
absorb subsequent information about operating system architecture which
probably would have gotten partially lost without the special insight from
having been there myself.

You can't of course do everything yourself.  You have to pick what you will
use as a tool and what you want to accomplish and what your end goal is.
This is one point Solarwind still needs to learn.  It's not clear what he
really wants to accomplish and what he wants to get out of it, which is
partly why the responses he's getting are all over the place.  Does he want
to learn about low cost light-weight networking and the problems associated
with corruption, flow control, guaranteed delivery, response time, etc?  If
so, implementing his own RS-485 network from scratch is a great way to go.
Is his real objective to get a house monitoring and energy management system
up and running and explore the higher level control algorithms?  In that
case just use the CAN hardware already and stop making things so complicated
and don't worry about trying to use a PIC 16 at all.

I also take issue with the statement that it's often easier to take a
working system and tweak it.  Most of the time I've taken someone else's
code and tried to integrate it into a embedded system it was more trouble
than it was worth.  The other code is rarely well written, and of course
never fits into the philosophy of how my particular system is structured.  I
can't think of a single PIC system where in hindsight I wouldn't have been
better off creating the subsystem myself.

The only bright spot I remember about using existing code were the JPEG
image routines that I integrated into my own imaging library.  The routines
I found for free on the net from the from the Independent JPEG Group just
worked, and the interface fit well enough into my image file driver
architecture.  Of course this was PC code, not PIC code.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\18@100906 by Isaac Marino Bavaresco

flavicon
face
Dario Greggio escreveu:
{Quote hidden}

I just sent a post that may explain better it.

>> There must be provision for a synchronization packet which is not
>> sequenced itself.
>>    
>
> could you explain more this one?
>  

If the nodes lose connection for too long the sequence numbers may get
very far apart (the sender is using number 2000 and the receiver
received only up to number 100 e.g.).

The window I mentioned, is the maximum difference between the sequence
numbers of two consecutive packets or commands. If a packet arrives with
a sequence number that is 256 (for instance, this is the value I use)
over the previous, it is discarded and the node keeps the sequence
number it had before.

If this happens, the nodes stop sending regular packets and start
sending special packets telling what numbers it is using and asking for
synching. The other node will always respond to these packets, saying it
received the request and providing a challenge (also a sequence number).
After receiving this packet, the sender node answers to the challenge
and assume they are synched again. When the receiver node receives the
correct answer to the challenge, it also assumes they are synched again.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\05\18@113424 by olin piclist

face picon face
Isaac Marino Bavaresco wrote:
> If the nodes lose connection for too long the sequence numbers may get
> very far apart

You are making this way too complicated.  This is a simple network where
it's not even clear true peer to peer is needed.  The simply shouldn't send
the next command until it receives a ACK for the previous.  There is no need
for packets to ever get out of order.  There is no router.  Everything is on
a single segment.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\18@113452 by M. Adam Davis

face picon face
On Sun, May 17, 2009 at 12:32 AM, solarwind <@spam@x.solarwind.xKILLspamspamgmail.com> wrote:
> After hours of research, I was unable to find a suitable realtime,
> multi-master/peer-to-peer network protocol for RS485. So I made my
> own.

Cool!  Networking is a lot of fun, with frequent bouts of frustration.

1. Don't be scared of implementing a collision sensing network
(CSMA/CD) - though many preach against it, it's very cheap and easy to
implement, and extraordinarliy robust for peer-to-peer networks.  It
has downsides, such as poor utilisation (without time slicing you
generally only get 80-90% network utilization) and interesting
difficulties once you get into very large or long networks.  But it's
worth investigating and considering, given that the vast majority of
today's computers use it in the form of ethernet, and cars in the form
of CAN.  I think it's funny that it's one of the more popular methods,
but so many are against it.  Cheap & robust generally wins over
"technically ideal" solutions.  You can run realtime over such a
network (CAN does it, ethernet can do hard realtime if all the devices
agree to certain terms of use, and there is a realtime ethernet
standard).  It depends on what exactly you mean by realtime - in
general it simply means guaranteed latency, and you can get that with
a properly designed CSMA/CD network.

2. Whatever you do, partition it from your program using a very well
defined programming interface (API) of functions (initialize network
functions, run network task, read packet, write packet, etc).  This
will enable you to A) rip out the network and drop in another network
type without reprogramming your code and B) use your network code in
any project.  This will be important as you go along, especially if
you plan to incorporate other media (radio, powerline, etc)

3. You say you haven't found a "suitable" network protocol but there
is absolutely _nothing_ unique about the protocol you have designed.
Reinventing the wheel is a fun pasttime, but is that really what you
want to be spending your time on?  If so, great, keep going.  If not,
take another hard look at existing solutions and incorporate one of
them.  If you still find it lacking you can always rip it out and put
your own in later.

-Adam

2009\05\18@114747 by Dr Skip

picon face
Vitaliy wrote:

> This sort of approach works for many things. It is often easier to take a
> working system, and tweak it until it does what you want, instead of writing
> one from scratch. Even if you end up rewriting it from scratch anyway.

Even for a student, starting from scratch is a great exercise. To do it right,
you'll still have to analyze what happens when things go wrong, the list is no
shorter, and if it's your own creation, you'll probably have more accurate
'simulations' in your head than trying to imitate the intricacies of some other
protocol and/or design. That doesn't say one shouldn't become familiar with
other designs in advance, but by digging and thinking deeper, one can decide
what subset or superset or combination of protocols might work for this given
case.

Having done much teaching, I can attest to the value of having to thoroughly
think through the system in the early part of one's education. You not only
have real world effects later on, but the protocol has to implemented in some
hardware and software, with their interfaces, et al. Problems will happen.

I suggest, as a general rule, to first look at what's out there for designs
(protocols) and learn what you can on what they do and why. Then create a list
of your specs. Have a bare minimum required list and a 'that would be nice to
have' list. Design and simulate in your head, with state diagrams, etc. Refine
until the bare minimum list works in all scenarios, and the failure cases have
acceptable or recognizable modes. Then build and test it. Then start adding on
the nicer features.

This makes it a good educational exercise while not trying to conquer the world
with rev 1. You become familiar with other work, you think about your
particular needs and how they could be implemented, you end up with a design
that you are intimate with, rather than trying to figure out why someone else's
isn't working, you have a quicker implementation, and a base to grow from
(which is also easier to debug).

I've seen a lot of students just pick up something like a protocol and
implement it, only to spend multitudes of more time trying to debug it in their
implementation (they missed something in hardware or interface or code that was
needed in their case but they didn't take the time to understand that or think
they needed to). Then, when they go to tweak it, because they aren't totally
familiar with the 'black box' they decided to use, they alter a part that is
necessary in other non-obvious ways and are in deeper doo-doo as far as getting
it to work goes. Not having spent the thinking time in advance puts them in
even deeper over their head. Thinking it through also develops good engineering
skills and an ability to find ways to save time later on.

-Skip

2009\05\18@121320 by Isaac Marino Bavaresco

flavicon
face
Olin Lathrop escreveu:
> Isaac Marino Bavaresco wrote:
>  
>> If the nodes lose connection for too long the sequence numbers may get
>> very far apart
>>    
>
> You are making this way too complicated.  This is a simple network where
> it's not even clear true peer to peer is needed.  The simply shouldn't send
> the next command until it receives a ACK for the previous.  There is no need
> for packets to ever get out of order.  There is no router.  Everything is on
> a single segment.
>  

As I told in my first post, my approach is for routed networks (I use
TCP/IP over Ethernet).
There was an ongoing discussion about command sequencing and I added my
solution for the problem. Perhaps not exactly what the OP needs but may
interest somebody (as it did).

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\05\18@122234 by Alan B. Pearce

face picon face
>On Sun, May 17, 2009 at 12:32 AM, solarwind <KILLspamx.solarwind.xKILLspamspamgmail.com>
>wrote:
>> After hours of research, I was unable to find a suitable realtime,
>> multi-master/peer-to-peer network protocol for RS485. So I made my
>> own.
...
{Quote hidden}

In fact getting the project going by starting with an already existing
protocol/transport layer will often show if the 'assumptions' that were made
in deciding you really needed to design a new network system are actually
valid. Hence doing the partitioning in the way that Adam suggests is valid,
and carries on into the mail that Dr Skip sent just after Adams.

2009\05\18@123655 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: RemoveMEpiclist-bouncesTakeThisOuTspammit.edu [spamBeGonepiclist-bouncesspamBeGonespammit.edu] On
Behalf
> Of solarwind
> Sent: 17 May 2009 05:32
> To: Microcontroller discussion list - Public.
> Subject: [EE] My RS485 Protocol - Please Evaluate
>
> After hours of research, I was unable to find a suitable realtime,
> multi-master/peer-to-peer network protocol for RS485

Did you check out SNAP? http://www.hth.com/snap/
Or YASP? http://yaspnet.sourceforge.net/

Regards

Mike


=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2009\05\18@124444 by solarwind

picon face
On Mon, May 18, 2009 at 12:36 PM, Michael Rigby-Jones
<TakeThisOuTMichael.Rigby-JonesEraseMEspamspam_OUToclaro.com> wrote:
> Did you check out SNAP? http://www.hth.com/snap/
> Or YASP? http://yaspnet.sourceforge.net/

Thanks! I swear I never saw those. Those look really useful.

2009\05\18@124842 by solarwind

picon face
@ those wondering why I want to dive into this:

My answer: for fun. CAN is cool and all, but what's the fun in hooking
up a few modules and reading a manual? I want to implement my own.
It's not _THAT_ hard and it's pretty fun.

2009\05\18@125658 by Vitaliy

flavicon
face
solarwind wrote:
>> I'm curious, why do you think a task manager would be useful in this
>> case?
>
> I've worked with QNX tasks before and I still have that "make it into
> a task" mentality. So I just thought that I might make a task to
> handle the protocol, since all that the interrupt on RX does is buffer
> the bytes in memory. We need a task to take care of the protocol. Is
> this a bad idea? How does one in the professional engineering world go
> about it?

Typically one starts with a simple loop. For instance, you could have:


RunMainLoop()
{
   GetMessage();
   if (message)
       ProcessMessage();
   UpdateLights();
   ReadTemperature();
}

Adding a task manager would increase complexity and overhead. There are
cases when it is warranted, but personally I would start with a simple loop
and switch to using a task manager when I saw the need for it.

Vitaliy

2009\05\18@130357 by solarwind

picon face
On Mon, May 18, 2009 at 12:56 PM, Vitaliy <RemoveMEspamspamTakeThisOuTmaksimov.org> wrote:
> Typically one starts with a simple loop. For instance, you could have:
>
>
> RunMainLoop()
> {
>    GetMessage();
>    if (message)
>        ProcessMessage();
>    UpdateLights();
>    ReadTemperature();
> }
>
> Adding a task manager would increase complexity and overhead. There are
> cases when it is warranted, but personally I would start with a simple loop
> and switch to using a task manager when I saw the need for it.
>
> Vitaliy

I was thinking of doing it this way initially and returning out of
each "task" as quickly as possible so that there is CPU time to spare
for all tasks.

2009\05\18@134133 by Vitaliy

flavicon
face
Dave Tweed wrote:
>> > ... you have to think carefully about what the receiving node might
>> > do if it receives two separate valid commands. A sequence number is
>> > the usual way around this, but there are other strategies.
>>
>> - Avoid "vague" commands ("toggle") in favor of more specific ones
>>   ("turn off")
>
> Specifically, look up the term "idempotent", especially as it applies to
> computer networks.

Thanks, Dave. I had to google it. :)

Vitaliy

2009\05\18@134356 by Vitaliy

flavicon
face
sergio masci wrote:
>> - Avoid "vague" commands ("toggle") in favor of more specific ones ("turn
>> off")
>> - Have the transmitter request the status before issuing the command
>> again
>
> This implies that comms between two nodes is "serial" i.e. commands and
> responses must ping pong back and fore between two nodes (say A and B)
> before comms between other nodes can be accepted by either A or B
> otherwise things start getting really hairy.
>
> The other thing to consider is what happens if the "turn off" command is
> sent before the "turn on" command but arrives AFTER the "turn on" command.
> Here "toggle" actually is an advantage. Yes packet sequence numbers are
> definiately very useful for deciding what to do here.

Well, yes. We weren't talking about some abstract protocol where you could
get messages out of sequence.

Vitaliy

2009\05\18@134948 by Vitaliy

flavicon
face
solarwind wrote:
>@ those wondering why I want to dive into this:
>
> My answer: for fun. CAN is cool and all, but what's the fun in hooking
> up a few modules and reading a manual? I want to implement my own.
> It's not _THAT_ hard and it's pretty fun.

SW, in case you were wondering why I said you're overconfident, this is a
perfect example. :-)

I would be very surprised if you could "hook up a few modules and read a
manual" and get a working CAN system in less than a week.

Having never done this before, how in the world can you know that
implementing a custom protocol is "not _THAT_ hard"?

Doing something pointless "for fun" gets old rather quickly.

Vitaliy

2009\05\18@140227 by Dr Skip

picon face


Vitaliy wrote:
> Doing something pointless "for fun" gets old rather quickly.

The world is full of folks who do just that their whole lives and are content
with it.... AND, it's not pointless if he learns from it and enjoys learning.

Remember, the journey is the reward.

2009\05\18@141013 by olin piclist

face picon face
M. Adam Davis wrote:
> But it's [collision detection network]
> worth investigating and considering, given that the vast majority of
> today's computers use it in the form of ethernet, and cars in the form
> of CAN.  I think it's funny that it's one of the more popular methods,
> but so many are against it.

Then you haven't given it much thought.  Both ethernet and CAN do the
collision detection in hardware.  That's rather different than doing it
youself with RS-485, especially since some quick timing is needed.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\18@142053 by solarwind

picon face
On Mon, May 18, 2009 at 2:11 PM, Olin Lathrop <olin_piclistEraseMEspam.....embedinc.com> wrote:
> Then you haven't given it much thought.  Both ethernet and CAN do the
> collision detection in hardware.  That's rather different than doing it
> youself with RS-485, especially since some quick timing is needed.

That's the key there. I don't want to burden the CPU with too much of
the protocol details. That's why I need the simplest type of protocol.
Token bus is awesome because it guarantees that there will never be a
collision. Also, the master polling system that you have mentioned
before is also awesome. If this doesn't work out, I'm going to do it
that way.

The time slot system is also cool but I need a way to get the time
slot mechanism working and I have no idea how to do that. CSMA/CD is
cool too, but now we have to detect collisions. I think that's too
complicated for me.

2009\05\18@144604 by Vitaliy

flavicon
face
solarwind wrote:
> Then you haven't given it much thought. Both ethernet and CAN do the
> collision detection in hardware. That's rather different than doing it
> youself with RS-485, especially since some quick timing is needed.

That's the key there. I don't want to burden the CPU with too much of
the protocol details. That's why I need the simplest type of protocol.
Token bus is awesome because it guarantees that there will never be a
collision. Also, the master polling system that you have mentioned
before is also awesome. If this doesn't work out, I'm going to do it
that way.

The time slot system is also cool but I need a way to get the time
slot mechanism working and I have no idea how to do that. CSMA/CD is
cool too, but now we have to detect collisions. I think that's too
complicated for me.
------------

IMO, detecting and dealing with collisions is waaay easier than dealing with
tokens.

I described the way it's done in J1850. What's difficult about it?

Vitaliy

2009\05\18@144937 by Vitaliy

flavicon
face
Dr Skip wrote:
>> Doing something pointless "for fun" gets old rather quickly.
>
> The world is full of folks who do just that their whole lives and are
> content
> with it.... AND, it's not pointless if he learns from it and enjoys
> learning.
>
> Remember, the journey is the reward.

You may be right... but personally, I think it's more fun to spend my time
and resources on something that would be useful to myself or other people.

Vitaliy

2009\05\18@151750 by Isaac Marino Bavaresco

flavicon
face
solarwind escreveu:
> On Mon, May 18, 2009 at 2:11 PM, Olin Lathrop <EraseMEolin_piclistspamembedinc.com> wrote:
>  
>> Then you haven't given it much thought.  Both ethernet and CAN do the
>> collision detection in hardware.  That's rather different than doing it
>> youself with RS-485, especially since some quick timing is needed.
>>    
>
> That's the key there. I don't want to burden the CPU with too much of
> the protocol details. That's why I need the simplest type of protocol.
> Token bus is awesome because it guarantees that there will never be a
> collision. Also, the master polling system that you have mentioned
> before is also awesome. If this doesn't work out, I'm going to do it
> that way.
>
> The time slot system is also cool but I need a way to get the time
> slot mechanism working and I have no idea how to do that. CSMA/CD is
> cool too, but now we have to detect collisions. I think that's too
> complicated for me.
>  

Collisions usually happen within a narrow window after the beginning of
the packet. If you turn on the reception when you start transmitting and
let an interrupt routine to check if what you are receiving is the same
as you are transmitting, then you may be able to detect collisions.

After the critical window ends, just turn off reception until you send
the last byte, so you will not be burdened by checking every byte you send.

If you detect a collision within the collision window, stop sending the
packet and send a predetermined sequence to help other nodes to detect
the collision also.

Then back-off a random time and try transmitting the packet again.

If a collision happens outside the collision window, then bad luck, but
it should be rare.

This is approx. how Ethernet handles collision, and I think there is no
reason it won't work for other protocols/encodings/modulations.


It appears somebody found that a node always sees the data it is
transmitting, even when there is another node transmitting. If so, then
it may be not possible to detect collisions at all.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\05\18@152447 by sergio masci

flavicon
face


On Mon, 18 May 2009, Vitaliy wrote:

{Quote hidden}

But it's easy to end up with a protocol where messages can be delivered
out of sequence. Consider a protocol that requires a node to ack a
successful packet delivery before the next packet can be sent. Node A
sends a packet to node B. Node B receives the packet does a little
processing on it then sends an ack or nack back. During this turn around
time node A cannot send anything else to node B (and probably wont be able
to send anything else to any other node depending on the exact protocol).
So this throttles the bandwidth. Now consider that the lag may become
large depending on the workload of the node being talked to.

Node A might actually be running several tasks each of which might need to
talk to a different node. It makes sense to be able to send out as many
packets as you can without waiting for any particular node to reply (the
task waiting for the reply could simply sleep in this case).

This is where out of order packets creeps in. Node A sends several packets
to node B (say 4 packets). One of the packets (say packet 2) arrives
corrupt. Node B sends back ACKs for packets 1, 3 and 4 and nothing for
packet 2 (times out packet 2). Node A then resends packet 2 which is now
out of order.

Regards
Sergio Masci

2009\05\18@154838 by solarwind

picon face
On Mon, May 18, 2009 at 3:17 PM, Isaac Marino Bavaresco
<RemoveMEisaacbavarescoEraseMEspamEraseMEyahoo.com.br> wrote:
> It appears somebody found that a node always sees the data it is
> transmitting, even when there is another node transmitting. If so, then
> it may be not possible to detect collisions at all.

How is this possible?

2009\05\18@154913 by olin piclist

face picon face
Vitaliy wrote:
> You may be right... but personally, I think it's more fun to spend my
> time and resources on something that would be useful to myself or
> other people.

All good EEs I've ever met tinkered with electronics from at least late
grade school on.  This is a necessary step in becomming a good engineer.
Conversely, for those people doing that *is* fun.  I remember a number of
"pointless" and "dumb" experiments I tried with electronics, often ending up
with fried parts but always learning something and ending with the desire to
try new things and learn more.

I think around freshman year in high school I thought of the idea of a
regulated power supply, but couldn't quite come up with the right concept.
I never did create a regulated power supply in high school, but having
thought about them made it instantly obvious when exposed to them for real
in college.  Others that hadn't gone thru that process seemed to struggle
with that and anything else there were supposed to design.

Another example was I often tried to make ways to boost a audio signal, even
at a preamp level.  I could get high gain, but things would often oscillate,
and even when they didn't the result didn't sound good.  Even though most of
my audio amplifiers in high school were failures, I learned a lot and did
enjoy trying to make them.  Eventually I learned about things like negative
feedback and power supply decoupling.  Those instantly made sense because I
had experience with the symptoms of not taking them into account, despite
not knowing that at the time.  When we had to do something with audio in a
college EE lab and we got "motor boating", I right away suspected unintended
feedback thru the power supply, which turned out to be right.  Others just
sat there stumped while our group got the thing working because I had been
there and done that before.  It turns out we were supposed to be stumped and
learn about power supply decoupling, and the TA came around and told us to
keep our mouth shut when we proudly told him what we found and how we got it
working.  He did quietly give us extra credit though.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\18@155839 by Peter Onion

flavicon
face
On Mon, 2009-05-18 at 10:48 -0700, Vitaliy wrote:

> I would be very surprised if you could "hook up a few modules and read a
> manual" and get a working CAN system in less than a week.

Too True !

PeterO


2009\05\18@162857 by M. Adam Davis

face picon face
On Mon, May 18, 2009 at 2:11 PM, Olin Lathrop <RemoveMEolin_piclistspam_OUTspamKILLspamembedinc.com> wrote:
> M. Adam Davis wrote:
>> But it's [collision detection network]
>> worth investigating and considering, given that the vast majority of
>> today's computers use it in the form of ethernet, and cars in the form
>> of CAN.  I think it's funny that it's one of the more popular methods,
>> but so many are against it.
>
> Then you haven't given it much thought.  Both ethernet and CAN do the
> collision detection in hardware.  That's rather different than doing it
> youself with RS-485, especially since some quick timing is needed.

It's non-trivial in terms of programming, but it only requires one
quick compare, and a physical medium that is only driven in one state
(the other state is the bus default, recessive).  You set up the
rs-485 receiver so it's always receiving, and if any byte you receive
while sending is not the byte you just sent, then you call it a
collision, announce it on the bus (usually a break on the bus which is
seen by the rx as a frame error), and everyone backs off according to
whatever algorithm you chose (generally random backoff and retry).
It's not hard or particularly tricky to implement well in a device
with a standard UART, such as a PIC.

Yes, it's nice to have collisions detection in hardware, but that's
hardly required.  It's nice to have quick timing so the bus can
recover quickly and you don't lose as much bandwidth on it, but quick
timing is not required.  In a good design with a normal UART you lose
about 3 bytes of bus time, assuming the collisions is detected based
on the first byte.  One byte for the first transmission.  The second
byte is being sent while the first one is being compared with what
should have been sent, and the third byte to push a break onto the
bus.  All quick timing and hardware sensing gives you is bit level
comparision and instant bus announcement at the first bad bit.

The extra comparison isn't any more work than the effort needed to,
for instance, catch, release, restart, etc a token - it's just time
spent at a different point in the network protocol.

Each method has it's own host of things that have to be carefully
considered to succeed.  I'm not saying the CSMA/CD is better or easier
to do, I'm saying it's not as hard as people make it out to be, and
one should not be afraid of it simply because so many people preach
against it.

So far there's nothing about his network requirements or skills that
would lead me to believe he couldn't or shouldn't implement it.  Nor
is there any reason to particularly avoid any other method we've
discussed so far.

But so many people seem to be cautioning him against CSMA/CD that it
makes me wonder, did ethernet bite them when they were kids?

;-D

-Adam

2009\05\18@163946 by solarwind

picon face
On Mon, May 18, 2009 at 4:28 PM, M. Adam Davis <RemoveMEstienmanTakeThisOuTspamspamgmail.com> wrote:
> But so many people seem to be cautioning him against CSMA/CD that it
> makes me wonder, did ethernet bite them when they were kids?

I would implement CSMA/CD right now if I knew how to detect
collisions. The protocol seems easy to implement, but I don't know how
to detect collisions.

2009\05\18@164422 by Dario Greggio

face picon face
solarwind ha scritto:
> On Mon, May 18, 2009 at 3:17 PM, Isaac Marino Bavaresco
> <EraseMEisaacbavarescospamspamspamBeGoneyahoo.com.br> wrote:
>> It appears somebody found that a node always sees the data it is
>> transmitting, even when there is another node transmitting. If so, then
>> it may be not possible to detect collisions at all.
>
> How is this possible?


From my experience, standard RS485 drivers such as SN75176 or ADM485
are *really* sensitive to differential voltage. So, then can "read" a
voltage even if the A-B lines are short circuited, say, 1 meter past
their inputs. Or if another station on the net is transmitting, but is
more than some meters apart.

So, a theoretical simple and good approach - listen back to what you say
- does not work on the fiels.

Dario

2009\05\18@164634 by Dario Greggio

face picon face
Isaac Marino Bavaresco ha scritto:
> If this happens, the nodes stop sending regular packets and start
> sending special packets telling what numbers it is using and asking for
> synching. The other node will always respond to these packets, saying it
> [...]

I see, I get it. Thank you Isaac!

Dario

PS: I read Olin's reply, and I guess that "on the average" I agree with him.

2009\05\18@164657 by Dario Greggio

face picon face
Olin Lathrop ha scritto:
> All good EEs I've ever met tinkered with electronics from at least late
> grade school on.  This is a necessary step in becomming a good engineer.
> Conversely, for those people doing that *is* fun.  I remember a number of
> "pointless" and "dumb" experiments I tried with electronics, often ending up
> with fried parts but always learning something and ending with the desire to
> try new things and learn more.

definitely agreed :)

2009\05\18@171709 by solarwind

picon face
On Mon, May 18, 2009 at 4:44 PM, Dario Greggio <RemoveMEadpm.toKILLspamspaminwind.it> wrote:
> So, a theoretical simple and good approach - listen back to what you say
> - does not work on the fiels.

What do you mean by that? Could you clarify why it does not work on the "fiels"?

2009\05\18@171956 by Dario Greggio

face picon face
solarwind ha scritto:
> On Mon, May 18, 2009 at 4:28 PM, M. Adam Davis <stienmanSTOPspamspamspam_OUTgmail.com> wrote:
>> But so many people seem to be cautioning him against CSMA/CD that it
>> makes me wonder, did ethernet bite them when they were kids?
>
> I would implement CSMA/CD right now if I knew how to detect
> collisions. The protocol seems easy to implement, but I don't know how
> to detect collisions.

:) been explained in some posts.

As per replying to Adam, the real issue is that Ethernet does use High
Frequency carrier(s) that can be used "better" in order to detect
collisions. The simple "1" and "0" states have not proven this good for
the purpose.

2009\05\18@172704 by solarwind

picon face
On Mon, May 18, 2009 at 5:19 PM, Dario Greggio <spamBeGoneadpm.toSTOPspamspamEraseMEinwind.it> wrote:
> :) been explained in some posts.

Yeah, well, I'm confused. People say listen to your own transmission.
Then they say it wont work. What do I do?

2009\05\18@173453 by Ruben Jönsson

flavicon
face
> On Mon, May 18, 2009 at 3:17 PM, Isaac Marino Bavaresco
> <KILLspamisaacbavarescospamBeGonespamyahoo.com.br> wrote:
> > It appears somebody found that a node always sees the data it is
> > transmitting, even when there is another node transmitting. If so, then
> > it may be not possible to detect collisions at all.
>
> How is this possible?
> --

Not always but if the two colliding transmitters are some distance apart from
each other you have some resistance in the cable between them. If you also have
some transient suppression components or fuses on the board (between the
transmitter chip and the terminals for the bus cable) it may add some more
resistance. The terminals themselves also adds some resistance, especially if
there are two on each board, one for input and one for output (even if they are
connected in parallell). Multiply the terminal resistance with as many nodes
(boards) there are between the two colliding transmitters. The total resistance
may not add upp to more than a couple of tens of ohms but this may be enogh.

A RS485 transmitter used in a standard RS485 way means that the transmitter
outputs drives actively in both directions for both 1 and 0 state of the bus.
And they can drive relatively high currents.

The receivers also only needs a couple of hundred mV difference between the two
inputs to detect a valid 1 or 0 level.

All this together with the fact that the receiver that is going to detect a
collision is located on the same chip as the transmitter, with the resistance
between it and the other transmitter and no resistance between it and the
transmitter on the same chip, means that the receivers may very well detect the
level that the transmitter on the same chip is transmitting and thus not
detecting a collision.

To get around this you need to change the behavior of the bus so a 1 level is
much weaker than a 0 level (or the other way around) which means that the 0
level (the dominant level) always wins over a 1 level (the recessive level),
even with the resistance in the cable and terminals. This can easily be done
with a RS485 transmitter chip by modulating the transmit enable input instead
of the data input with the transmitted data and having resistors to pull the
bus to the weak level. Compare this to an open collector OR wired bus with a
single pull up resistor. The transistor can only actively drive to ground while
the resistor passively pulls the bus to the high level. The bus is only high
when no transistors are active (switched on).

/Ruben
==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
EraseMErubenspamEraseMEpp.sbbs.se
==============================

2009\05\18@174826 by Dario Greggio

face picon face
Ruben Jönsson ha scritto:

> To get around this you need to change the behavior of the bus so a 1 level is
> much weaker than a 0 level (or the other way around) which means that the 0
> level (the dominant level) always wins over a 1 level (the recessive level),
>[...]


thank you Ruben, very good explanation :)

Dario

2009\05\18@175557 by Bob Blick

face
flavicon
face
On Mon, 18 May 2009 17:26:43 -0400, "solarwind"
<@spam@x.solarwind.x@spam@spamspam_OUTgmail.com> said:

> Yeah, well, I'm confused. People say listen to your own transmission.
> Then they say it wont work. What do I do?

It depends how you drive the bus. With RS-485, when you enable the
transmitter, both levels (1 and 0) are actively driven onto the bus. So
it's basically impossible for a local receiver to detect if a remote
transmitter is colliding. But in buses where one of the levels is
passively driven(with a resistor), the local receiver can read the bus
accurately at all times. The disadvantage to this system is the bus can
only be made as fast as the passive transistion time.

There are more nuances to it, but that's the basic idea behind what
people have said. There are also busses that have the best of both
worlds.

Cheers,

Bob

--
http://www.fastmail.fm - Access your email from home and the web

2009\05\18@181340 by solarwind

picon face
On Mon, May 18, 2009 at 5:55 PM, Bob Blick <spamBeGonebobblickspamKILLspamftml.net> wrote:
> It depends how you drive the bus. With RS-485, when you enable the
> transmitter, both levels (1 and 0) are actively driven onto the bus. So
> it's basically impossible for a local receiver to detect if a remote
> transmitter is colliding. But in buses where one of the levels is
> passively driven(with a resistor), the local receiver can read the bus
> accurately at all times. The disadvantage to this system is the bus can
> only be made as fast as the passive transistion time.
>
> There are more nuances to it, but that's the basic idea behind what
> people have said. There are also busses that have the best of both
> worlds.

Thank you. I get it now.

2009\05\18@192152 by Vitaliy

flavicon
face
solarwind wrote:
>> :) been explained in some posts.
>
> Yeah, well, I'm confused. People say listen to your own transmission.
> Then they say it wont work. What do I do?

People who say you can't listen to your own transmission, are trying to
confuse you. :) Yes, it can be a problem, but for now assume that you can
tell a "1" from a "0".

So, how do you detect a collision*? Like this:

- Assume that "1" is recessive, and "0" is dominant. When both are
transmitted, "0" always wins.
- Transmit a "1"
- Wait a short time (say, 1/10 of a bit)
- Read the output (the assumption here is that your Rx pin is connected to
your Tx pin).
- If the output is "0", you lost arbitration. Stop transmitting, and wait
until the bus is idle again.

Vitaliy

*In this case, there really is no collision, we just say that you "lost
arbitration". A collision implies that the message is destroyed (like it is
in Ethernet, for example).

2009\05\18@193336 by Vitaliy

flavicon
face
Dario Greggio wrote:
>> All good EEs I've ever met tinkered with electronics from at least late
>> grade school on.  This is a necessary step in becomming a good engineer.
>> Conversely, for those people doing that *is* fun.  I remember a number of
>> "pointless" and "dumb" experiments I tried with electronics, often ending
>> up
>> with fried parts but always learning something and ending with the desire
>> to
>> try new things and learn more.
>
> definitely agreed :)

I understand what you guys are saying. I also got involved in electronics as
a pre-teen.

However, I still stand by my assertion that having a real purpose helps one
stay motivated. And I found over the years that at least for me, it is a lot
more fun in the beginning to follow a cookbook recipe, and then branch out
once I understand the workings of a system. I don't consider being
frustrated part of fun, frustration is only good in small doses. :)

Vitaliy

2009\05\18@194841 by sergio masci

flavicon
face


On Mon, 18 May 2009, Vitaliy wrote:

{Quote hidden}

don't you actually mean "*kind* of like this" and not "*exactly* like
this"

Sorry to be pedantic but if you're going to give examples shouldn't they
either be bullet proof or explain that they are simplifications.

Vitaliy's example works for one bit but it does not address the problem
that several nodes may be doing exactly the same thing at the same time
and each will think it has won. What you actually need to do is check each
bit of each byte. However just checking the bit 1/10 of the way in is not
going to guarentee that another node has not started transmiting 2/10 of a
bit period after you.

Regards
Sergio Masci

2009\05\18@195733 by Isaac Marino Bavaresco

flavicon
face
solarwind escreveu:
> On Mon, May 18, 2009 at 5:55 PM, Bob Blick <.....bobblickspam_OUTspamftml.net> wrote:
>  
>> It depends how you drive the bus. With RS-485, when you enable the
>> transmitter, both levels (1 and 0) are actively driven onto the bus. So
>> it's basically impossible for a local receiver to detect if a remote
>> transmitter is colliding. But in buses where one of the levels is
>> passively driven(with a resistor), the local receiver can read the bus
>> accurately at all times. The disadvantage to this system is the bus can
>> only be made as fast as the passive transistion time.
>>    

But certainly tens of thousands of bps are possible. I use 19.2 kbps
with a "passivated" RS-232 network (every transmitter have a diode in
series with the TX pin and the line is pulled down to -12V with a 3k3
resistor) over 100m long.

I have installed systems with up to six nodes distributed along the line.

I use 19.2 kbps because of system convenience but in tests it worked up
to 57.6kbps.

For RS-485, I think much higher speeds are possible, even with a
passively pulled state.

Regards,

Isaac


>> There are more nuances to it, but that's the basic idea behind what
>> people have said. There are also busses that have the best of both
>> worlds.
>>    
>
> Thank you. I get it now.
>  

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\05\18@200458 by olin piclist

face picon face
Vitaliy wrote:
> And I found over the years that at least for me, it
> is a lot more fun in the beginning to follow a cookbook recipe,

It was always completely opposite for me.  There was no fun in duplicating
something someone else did.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\18@203537 by Vitaliy

flavicon
face
sergio masci wrote:
> Sorry to be pedantic but if you're going to give examples shouldn't they
> either be bullet proof or explain that they are simplifications.

It was not my intent to write a complete protocol spec for SW. Sorry if this
was not obvious. :)


> Vitaliy's example works for one bit but it does not address the problem
> that several nodes may be doing exactly the same thing at the same time
> and each will think it has won. What you actually need to do is check each
> bit of each byte.

I thought this was implied?


> However just checking the bit 1/10 of the way in is not
> going to guarentee that another node has not started transmiting 2/10 of a
> bit period after you.

Check it 1/2 of the way in, or keep checking it in a loop, until you're done
transmitting the bit. :)  It really depends on how out of sync the nodes can
be. Technically, the other node would not start transmitting if it saw a
start of frame (dominant bit), so the situation you describe is impossible
(node transmissions cannot be "late"), unless we're talking about really
long transmission lines where propagation speed begins to matter, and very
high baud rates.

Of course, ideally you would want to either use a self-synchronizing
protocol like PWM so you can detect idle bus and resyncronize every bit
time, or use bit stuffing like CAN does. Otherwise a string of 1s will not
look any different from idle bus.

This is exactly why I'm saying that an off-the-shelf protocol would be best
in this situation. There are too many "what if"s. There are plenty of
unknowns in any OTS protocol that SW picks, to make them challenging.

Vitaliy

2009\05\18@204119 by Dr Skip

picon face
Olin Lathrop wrote:
> It was always completely opposite for me.  There was no fun in duplicating
> something someone else did.

Exactly!
There's a lot of subtlety, especially in hardware design, that goes unlearned
and unappreciated by just copying. Thinking it through makes one intimate with
the requirements, the parts, the process, and the success. Learning someone
else's design to the level you'd know your own probably takes the same order of
magnitude in time. Learn less by not delving deeply and just copying and you've
left goods on the table you could have benefited from... The 'why' is as
important as the 'how'. Not to mention, it hones your cognitive processes as
well, having decided some component will work there and then finding it won't
and figuring out why it won't and why you thought so in the first place.

Used often, it may bring new and interesting ideas or inventions. If you end up
designing something (like a protocol) that has been done before, you've made
the same journey few others have, and will be able to offer insights and
perspective only few can.

That doesn't say copying is universally bad, but it isn't a good educational
activity either. After becoming experienced in thinking it through, you're
better able to select something to copy and/or modify, and you can tell a good
example from a bad one. We haven't even discussed the negative side of learning
from bad examples while thinking they're good ones. ;)

2009\05\18@204612 by Vitaliy

flavicon
face
Olin Lathrop wrote:
>> And I found over the years that at least for me, it
>> is a lot more fun in the beginning to follow a cookbook recipe,
>
> It was always completely opposite for me.  There was no fun in duplicating
> something someone else did.

Didn't you just describe how you "invented" a switching power supply, and
power supply decoupling? This sounds an awful lot like reinventing the
wheel.

What I said was that you can build upon what others have already done, and
as a result build something new. Various people at various times called it
"standing on the shoulders of giants", "learning from other people's
experience", etc.

Vitaliy

2009\05\18@205909 by Vitaliy

flavicon
face
Dr Skip wrote:
> Used often, it may bring new and interesting ideas or inventions. If you
> end up
> designing something (like a protocol) that has been done before, you've
> made
> the same journey few others have, and will be able to offer insights and
> perspective only few can.

Why don't you smelt your own iron, then? Very few people have done it, so
you'll have a very unique perspective.

You can then proceed to cutting your own wafers. :)


> That doesn't say copying is universally bad, but it isn't a good
> educational
> activity either. After becoming experienced in thinking it through, you're
> better able to select something to copy and/or modify, and you can tell a
> good
> example from a bad one. We haven't even discussed the negative side of
> learning
> from bad examples while thinking they're good ones. ;)

You can learn more by exposing yourself to many different options, instead
of limiting yourself to what you yourself can come up with. Note that I
never used the word "copy". It implies exactly what you describe: using
someone else's work without understanding.

Vitaliy

2009\05\18@214723 by John Chung

picon face

I always look at a circuit and explain all that I can using my knowledge. Once awhile go back to my books to identify subjects of interest while going through the circuit. Still theory is first for me. No point looking at something I have no clue.

John

--- On Tue, 5/19/09, Olin Lathrop <TakeThisOuTolin_piclist.....spamTakeThisOuTembedinc.com> wrote:

{Quote hidden}

> -

2009\05\19@044305 by Alan B. Pearce

face picon face
>Consider a protocol that requires a node to ack a
>successful packet delivery before the next packet can be sent.

I remember some colleagues of mine being involved with a Sperry system,
which had a fancy protocol for talking to peripherals, where it was possible
to include the ACK/NACK with the next data message that was being returned,
as a way of cutting down on the dead time on the network, due to turnarounds
for a minimalist message that an ACK/NACK is.

Unfortunately I never dug into the details of the protocol, so cannot
explain further.

2009\05\19@050900 by Wouter van Ooijen

face picon face
> I remember some colleagues of mine being involved with a Sperry system,
> which had a fancy protocol for talking to peripherals, where it was possible
> to include the ACK/NACK with the next data message that was being returned,
> as a way of cutting down on the dead time on the network, due to turnarounds
> for a minimalist message that an ACK/NACK is.

That technique is very common, you can find it for instance in TCP/IP.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2009\05\19@054635 by Alan B. Pearce

face picon face
>But certainly tens of thousands of bps are possible. I use 19.2 kbps
>with a "passivated" RS-232 network (every transmitter have a diode in
>series with the TX pin and the line is pulled down to -12V with a 3k3
>resistor) over 100m long.
>
>I have installed systems with up to six nodes distributed along the line.

I used to service a similar system, which could run at up to 38.4k, and have
up to 31 terminals on it, using a similar 'passive RS232' with open
collector drivers.

2009\05\19@080143 by olin piclist

face picon face
Vitaliy wrote:
> Didn't you just describe how you "invented" a switching power supply,
> and power supply decoupling? This sounds an awful lot like
> reinventing the wheel.

Actually I was talking about how I didn't quite figure out how to make a
regulated power supply in high school, and also how my audio amps didn't
work as intended because I didn't know about power supply decoupling and
negative feedback.

But yes, if I had succeeded that would have been reinventing the wheel.
That's the point.  Reinventing something, meaning you only start with a idea
or only knowing something exists and having to figure out how to make that
happen is extremely educational.  You learn a lot more by discovering
problems and making design tradeoffs yourself than by having someone tell
you the "right" way to do it.  After you've tried it, whether you were
really successful or not, then you are in a great position to learn how
others solved the same problems.  You'll be at the edge of your seat paying
attention with some aha moments.  Much of that would have been lost if you
didn't first put yourself in the other designer's position.

The fact that you say reinventing the wheel like it's bad means you are
thinking of results more than education.  I thought it was clear the context
was educational value.

> What I said was that you can build upon what others have already
> done, and as a result build something new. Various people at various
> times called it "standing on the shoulders of giants", "learning from
> other people's experience", etc.

That's for when you're trying to develop something totally new.  Which is a
different purpose altogether.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\19@080158 by Isaac Marino Bavaresco

flavicon
face
Vitaliy escreveu:
{Quote hidden}

It is a waste of CPU time to check each bit individually.
Let the USART receiver receive the whole byte and check at the end, it's
ten times more efficient.
If the received character is not what you had transmitted or if you get
a framing error then there was a collision.

Remember that the transmitters may be a fraction of a bit off-step.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\05\19@083112 by olin piclist

face picon face
Vitaliy wrote:
> Dr Skip wrote:
>> Used often, it may bring new and interesting ideas or inventions. If
>> you end up
>> designing something (like a protocol) that has been done before,
>> you've made
>> the same journey few others have, and will be able to offer insights
>> and perspective only few can.
>
> Why don't you smelt your own iron, then? Very few people have done
> it, so you'll have a very unique perspective.

If you really wanted to learn about ore processing and maybe metallurgy,
that might actually be a good idea.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\19@083400 by sergio masci

flavicon
face


On Mon, 18 May 2009, Vitaliy wrote:

{Quote hidden}

Don't get me wrong I'm not jumping on you here but although I could infer
this because of my experience I could see that someone that needs to ask
all these questions probably could not (infer it).

>
{Quote hidden}

I'm confused. Is these a way to check the status of a PIC USART to see it
it has started to receive data?

Please clarify what would happen if node A has just started to send the
first byte of a message which is 0x02 and node B starts to transmite
while node A is starting to shift out bit 1 (which is a low to high
transition of data from node A). How does node B know that there has
already been some (as yet unflagged) activity on the bus? It's attempt to
send the start bit will succead but will correspond to data bit 1 of node
A.

Perhaps a solution would be to use interrupt on change of one of the PORTB
inputs and tie that to Rx of the USART? You could maybe enable this only
at the end of a packet and disable it after the first date byte is
received?

Regards
Sergio Masci

2009\05\19@083801 by olin piclist

face picon face
Alan B. Pearce wrote:
> I remember some colleagues of mine being involved with a Sperry
> system, which had a fancy protocol for talking to peripherals, where
> it was possible to include the ACK/NACK with the next data message
> that was being returned, as a way of cutting down on the dead time on
> the network, due to turnarounds for a minimalist message that an
> ACK/NACK is.

TCP also works this way.  You can ACK the previously received packet while
sending new data in the same packet.

As I said before the RFC for TCP is good reading for anyone that is
interested in networks at this level.  It is a quite readable document, and
you can see how a lot of contingencies were thought about and addressed in a
very successful protocol.  If I were teaching a college course on networks
at that level I'd make it required reading.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\19@085054 by olin piclist

face picon face
Isaac Marino Bavaresco wrote:
> It is a waste of CPU time to check each bit individually.
> Let the USART receiver receive the whole byte and check at the end,
> it's
> ten times more efficient.
> If the received character is not what you had transmitted or if you
> get
> a framing error then there was a collision.

It's not that simple.  I'm assuming we're using the dominant/recessive type
of bus signalling like CAN.  A sender needs to back off immediately on
seeing the bus in dominant state when sending recessive.  That lets the
dominant sender win while not corrupting his future bits.  Both (or
multiple) senders continue until they differ in bit state, at which time the
recessive will back off.

This doesn't work if you look at results in 8 bit chunks or the like.  If
the two senders disagreed about two different bits but each with opposite
polarity, you can't tell which one should back off and which one may
continue.  Let's say the disagreements were bits 4 and 2 of the byte.
Sender A sees only a error in bit 4 since that is where it was recessive and
B was dominant, and B likewise sees only the error in bit 2.  Neither knows
whether any other sender sees a error in a earlier bit and therefore the
other sender should back off, or if its error bit is the first collision and
it should back of itself.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\19@092635 by Dario Greggio

face picon face
Olin Lathrop ha scritto:
> Alan B. Pearce wrote:
>> I remember some colleagues of mine being involved with a Sperry
>> system, which had a fancy protocol for talking to peripherals, where
>> it was possible to include the ACK/NACK with the next data message
>> that was being returned, as a way of cutting down on the dead time on
>> the network, due to turnarounds for a minimalist message that an
>> ACK/NACK is.
>
> TCP also works this way.  You can ACK the previously received packet while
> sending new data in the same packet.


Hmmm, i guessed I had read that RFC but I missed this one!
interesting...

Dario

2009\05\19@094935 by olin piclist

face picon face
Dario Greggio wrote:
>> TCP also works this way.  You can ACK the previously received packet
>> while sending new data in the same packet.
>
> Hmmm, i guessed I had read that RFC but I missed this one!
> interesting...

Each TCP packet contains the flags byte and the full ACK sequence number.
Any packet can, and usually does, ACK whatever the the sender thinks it has
successfully received.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\19@100311 by Dario Greggio

face picon face
Olin Lathrop ha scritto:
> Dario Greggio wrote:
>>> TCP also works this way.  You can ACK the previously received packet
>>> while sending new data in the same packet.
>> Hmmm, i guessed I had read that RFC but I missed this one!
>> interesting...
>
> Each TCP packet contains the flags byte and the full ACK sequence number.
> Any packet can, and usually does, ACK whatever the the sender thinks it has
> successfully received.

Thank you Olin, that's ok.

Maybe one day I'll rethink my "skynet" :)

Dario

2009\05\19@100723 by Alan B. Pearce

face picon face
>> it was possible to include the ACK/NACK with the next data message
>
> TCP also works this way.  You can ACK the previously received packet
> while sending new data in the same packet.

Thanks for the pointer, haven't ever gone chasing through those documents,
so hadn't picked up on that.

2009\05\19@100807 by Isaac Marino Bavaresco

flavicon
face
Olin Lathrop escreveu:
> Isaac Marino Bavaresco wrote:
>  
>> It is a waste of CPU time to check each bit individually.
>> Let the USART receiver receive the whole byte and check at the end,
>> it's
>> ten times more efficient.
>> If the received character is not what you had transmitted or if you
>> get
>> a framing error then there was a collision.
>>    
>
> It's not that simple.  I'm assuming we're using the dominant/recessive type
> of bus signalling like CAN.  A sender needs to back off immediately on
>  

I assumed using UART, something CSMA/CD like, with collision detection,
back-off and retransmission.

It would be really time consuming or even impossible to deal at the bit
level without hardware support, unless the rate is really low.
I think it is simpler to deal with retransmissions than with bus
arbitration, it works well for Ethernet. The bandwidth degradation due
to collisions should be manageable.

{Quote hidden}

Then both will back off, and if they wait a random delay then the next
transmission probably will pass OK.


You forgot to mention my last line : "Remember that the transmitters may
be a fraction of a bit off-step."
This adds another layer of complexity, unless you use a clock-stretching
protocol (I2C e.g.) or CAN.

Note that CAN uses sub-bit timing, so you need to react very fast : use
hardware support or very low speeds.

If the OP wanted to use CAN with hardware support, then he would not
need to write his own protocol. Without hardware support, a simpler and
viable approach is to deal with collisions.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\05\19@101315 by Isaac Marino Bavaresco

flavicon
face
Olin Lathrop escreveu:
> Isaac Marino Bavaresco wrote:
>  
>> It is a waste of CPU time to check each bit individually.
>> Let the USART receiver receive the whole byte and check at the end,
>> it's
>> ten times more efficient.
>> If the received character is not what you had transmitted or if you
>> get
>> a framing error then there was a collision.
>>    
>
> It's not that simple.  I'm assuming we're using the dominant/recessive type
> of bus signalling like CAN.  A sender needs to back off immediately on
>  

I assumed using UART, something CSMA/CD like, with collision detection,
back-off and retransmission.

It would be really time consuming or even impossible to deal at the bit
level without hardware support, unless the rate is really low.
I think it is simpler to deal with retransmissions than with bus
arbitration, it works well for Ethernet. The bandwidth degradation due
to collisions should be manageable.

{Quote hidden}

Then both will back off, and if they wait a random delay then the next
transmission probably will pass OK.


You forgot to mention my last line : "Remember that the transmitters may
be a fraction of a bit off-step."
This adds another layer of complexity, unless you use a clock-stretching
protocol (I2C e.g.) or CAN.

Note that CAN uses sub-bit timing, so you need to react very fast : use
hardware support or very low speeds.

If the OP wanted to use CAN with hardware support, then he would not
need to write his own protocol. Without hardware support, a simpler and
viable approach is to deal with collisions.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\05\19@102048 by Dario Greggio

face picon face
Isaac Marino Bavaresco ha scritto:
>
> Note that CAN uses sub-bit timing, so you need to react very fast : use
> hardware support or very low speeds.
>
> If the OP wanted to use CAN with hardware support, then he would not
> need to write his own protocol. Without hardware support, a simpler and
> viable approach is to deal with collisions.

I agree in that, if bit-level handling (collisions etc) is needed, then
better to go with real CAN.

What we (you, me and others) are discussing now, is something that can
work "well enough" - byte-level as an example.

Dario

2009\05\19@104601 by Dave Tweed

face
flavicon
face
Isaac Marino Bavaresco wrote:
> Vitaliy escreveu:
> > *In this case, there really is no collision, we just say that you "lost
> > arbitration". A collision implies that the message is destroyed (like it
> > is in Ethernet, for example).
>
> It is a waste of CPU time to check each bit individually.
> Let the USART receiver receive the whole byte and check at the end, it's
> ten times more efficient.
> If the received character is not what you had transmitted or if you get
> a framing error then there was a collision.

But as Vitaliy said, that destroys both messages, requiring both senders
to retransmit, hopefully at different times. If you want to guarantee
throughput, as CAN does, the first sender to detect a bit-level collision
must back off immediately, in order to let the other sender succeed.

I guess you have to decide whether CPU bandwidth or bus bandwidth is more
precious in your system. Nost designers prefer to spend the CPU cycles in
order to keep the bus running as efficiently as possible.

-- Dave Tweed

2009\05\19@110850 by olin piclist

face picon face
Isaac Marino Bavaresco wrote:
{Quote hidden}

Why are you going to such great lengths to avoid CAN when it has all this in
hardware that comes built into a PIC?  You are going thru a lot of trouble
just to get something not quite as good.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\19@114642 by Isaac Marino Bavaresco

flavicon
face
Olin Lathrop escreveu:
{Quote hidden}

We are discussing the OP's ideas, in a theoretical level.

But I like the possibility of having a simple network structure (and I
have use for it), where several very simple and  heterogeneous devices
can communicate in an inexpensive way over a limited area (home
automation e.g.).

I could even reprogram my old multi-drop RS-232 devices to use the new
protocol, this would open new uses for them.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\05\19@123715 by Marechiare

picon face
> I remember a number of "pointless" and "dumb"
> experiments I tried with electronics, often ending
> up with fried parts but always learning something
> and ending with the desire
> to try new things and learn more.

"to fry new things" not  "to try new things" :-)

Good thing you were not a newbie sushi cook :-)

2009\05\19@153444 by Vitaliy

flavicon
face
Isaac Marino Bavaresco wrote:
>It is a waste of CPU time to check each bit individually.
Let the USART receiver receive the whole byte and check at the end, it's
ten times more efficient.
If the received character is not what you had transmitted or if you get
a framing error then there was a collision.

Remember that the transmitters may be a fraction of a bit off-step.<


See Olin's response, he explains the reasons very clearly.

2009\05\19@153817 by Vitaliy

flavicon
face
sergio masci wrote:
> Don't get me wrong I'm not jumping on you here but although I could infer
> this because of my experience I could see that someone that needs to ask
> all these questions probably could not (infer it).

In my earlier post, I described how this is done in J1850, on a byte level.


{Quote hidden}

No, this assumes bit-banging. You can't use the UART because it deals with
one bit at a time.


{Quote hidden}

Again, what I said assumes that you are manually shifting the bits out, and
checking the bus after each one. It also assumes that the first bit sent is
a dominant, and that somehow you ensure that there is a transition from
recessive to dominant state every so many bits (or every bit).

Vitaliy

2009\05\19@162424 by Isaac Marino Bavaresco

flavicon
face
Vitaliy escreveu:
> Isaac Marino Bavaresco wrote:
>  
>> It is a waste of CPU time to check each bit individually.
>>    
> Let the USART receiver receive the whole byte and check at the end, it's
> ten times more efficient.
> If the received character is not what you had transmitted or if you get
> a framing error then there was a collision.
>
> Remember that the transmitters may be a fraction of a bit off-step.<
>
>
> See Olin's response, he explains the reasons very clearly.
>  

I know why, but the whole point is that bit banging the protocol will
only allow a too slow data rate.

It may be better to pump the rate up and let the UART receive/transmit.
The collisions will be more than compensated by the much higher data
rate and the CPU will spend much less time dealing with
transmission/reception.

Regards,

Isaac


__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\05\19@165445 by solarwind

picon face
On Tue, May 19, 2009 at 11:46 AM, Isaac Marino Bavaresco
<RemoveMEisaacbavarescospamspamBeGoneyahoo.com.br> wrote:
> We are discussing the OP's ideas, in a theoretical level.
>
> But I like the possibility of having a simple network structure (and I
> have use for it), where several very simple and  heterogeneous devices
> can communicate in an inexpensive way over a limited area (home
> automation e.g.).
>
> I could even reprogram my old multi-drop RS-232 devices to use the new
> protocol, this would open new uses for them.

Exactly.

Remember the "old" days where a computer programmer actually had to
use his brain to think of a way to optimize code? (To write a game in
vector graphics for example.) Now any noob can simply throw in a high
end graphics card and use OpenGL and DirectX without thought. Trust
me. I did it. Without thought.

For the same reasons, I want to avoid the additional cost and hassle
of CAN for now. Obviously, I can understand that mission critical
projects require time-tested and reliable networks such as the CAN
bus. But for someone like me who wants to keep things as simple as
possible (just a PIC + RS485 transceiver will do), a home-made
protocol will be more than enough. Also, this way, I understand
exactly what's going on at the bit level.

Besides, I think the token bus system is a great idea and I've already
done writing half the code for it. The receiving functions and the
network shell is complete. Now I just have to write the transmitting
functions. In this type of network, I don't need to worry about
collisions since there will never be any. Also, if I ever want to have
a bit of (more) fun, I can replace the UART pins with some infra-red
diodes and a photo transistor and hook up some fiber optic cable (I
have some). It would be fun to see what speeds I can achieve across my
house. (Optoelectronics is fun!)

All in all. I very much appreciate all the help that you guys have
given me. Really, I do. You've all thoroughly discussed this topic and
I have learned a lot from it. I've improved my token bus protocol and
I'm ready to finish the transmitter part (after I finish my exam this
week). Due to this exercise, I've also gotten familiar with RTOS' like
Salvo which are really cool and fun to experiment with.

I'll keep my old laptop running continuously to monitor and log the
network traffic and see where problems occur. I'll also program in the
functionality to detect lost tokens or crashed nodes. I'll now also
enable the watchdog timer (never have used it before in my life) so it
will more or less guarantee that the nodes wont go down and lose the
token. (Does the watchdog erase the RAM if it is not cleared? That is,
will I lose the Has_Token flag if the watchdog resets the system?)

Anyway, I'll post my progress and see how this goes.

Thanks again!

2009\05\19@170004 by solarwind

picon face
Also, if I create a bus with passive/dominant states (with a pullup
resistor, for example), does it require "bitbanging" the code, or will
the normal UART suffice? I mean, is the hardware UART low impedance on
both high and low? Or is there a state where it is low impedance? If
it is low impedance in both states, how is it possible to drive the
bus in a passive state? (with a pullup resistor, that is)

2009\05\20@073855 by olin piclist

face picon face
solarwind wrote:
>> The watchdog reset preserves the RAM and most of the SFRs.
>> But it sets the NOT_TO (STATUS reg. for PIC16 or RCON reg. for PIC18)
>> bit to zero, so you can test it at startup to see if a watch dog
>> reset happened.
>
> Thanks. That's exactly what I need to prevent my nodes from crashing.

No, it's not.  The watchdog only resets the PIC after the firmware has
already wedged.  It is essentially a controlled crash.

Watchdogs are overrated.  They don't prevent faults, only trade one type of
fault for another.  They can be useful in just the right circumstances, but
overall I've seen them cause more trouble than they fixed.  The watchdog can
recover from a particular type of firmware bug if restarting the processor
can be considered recovery.  However, they open the possibility for other
types of firmware bugs, so it's very system dependent whether the result is
better or worse.

> Well, either that, or I really need to stop using microsoft. ; )

I don't know what Microsoft has to do with any of this.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\20@154549 by M. Adam Davis

face picon face
On Tue, May 19, 2009 at 4:54 PM, solarwind <spamBeGonex.solarwind.x@spam@spamspam_OUTgmail.com> wrote:
> Does the watchdog erase the RAM if it is not cleared? That is,
> will I lose the Has_Token flag if the watchdog resets the system?

The microcontroller won't reset the RAM, but some C compilers
automatically zero ram at boot, so you'll want to do a few tests.
This is not a fool-proof way to keep the token, but it's one good
method to restart it sooner than someone timing out, assuming nothing
else is preventing the node from restarting correctly.

On Tue, May 19, 2009 at 4:59 PM, solarwind <TakeThisOuTx.solarwind.xspamspamgmail.com> wrote:
> Also, if I create a bus with passive/dominant states (with a pullup
> resistor, for example), does it require "bitbanging" the code, or will
> the normal UART suffice? I mean, is the hardware UART low impedance on
> both high and low? Or is there a state where it is low impedance? If
> it is low impedance in both states, how is it possible to drive the
> bus in a passive state? (with a pullup resistor, that is)

The key here is whether the UART drives the bus to high and low, or
just one state.  In a dominant/recessive system the UART would drive
only one (dominant) state, but the bus would float back to the
recessive state when it stops driving the dominant state.

The hardware UART on the PIC drives both high and low.  You cannot
configure it to do otherwise, and so external circuitry is needed to
make this work.

If you're running an RS-485 network though, it's not difficult to do
this.  Instead of having the UART connect to the TX of the rs-485
transmitter, connect it to the low-enable pin of the transmitter.  The
tie the TX pin high (or low, depending on which bus state you want to
have dominant)

You then terminate the bus with resistors and a power supply that give
the recessive state when nothing is driving the bus.

This was explained in an earlier post in this thread, though since
you're running a token ring I don't see a reason to do this.  Check
out the thread to find the earlier post for more info if this isn't
clear.

-Adam

2009\05\22@164409 by Isaac Marino Bavaresco

flavicon
face
Gerhard Fiedler escreveu:
{Quote hidden}

OK, WDT reset doesn't preserve "most" of the SFRs, but it do preserves a
lot of them.

The SFRs that are set are the ones that control peripherals, and need to
be shut down on *every* reset. Other SFRs are not affected.

For instance the LATx , FSRn, PRODx, TMRn, TnCON, STATUS, ADRESx,
CCPRnx, SSPnBUF, TXREGn registers are completely preserved. There are
registers that have some bits preserved.

I use this feature to implement a "core dump" when the PIC crashes. At
reset my init code tests to see if the reset was not normal and (if so)
copy all the RAM, SFRs and hardware stack to the Ethernet frame buffer
(I use the PIC18F87J60).
The application code, before initializing the Ethernet module, checks to
see if there is a core dump. If so, it copies the Ethernet frame buffer
to the file system (SPI FLASH memory, my own file system), and after
initializing the Ethernet, it transmits the file to a PC.

It helped me a lot to find obscure bugs in the application and RTOS.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

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