error detection rate with crc-16 CCITT

http://dating-chatting143.blogspot.com/

http://dating-chatting143.blogspot.com/

http://dating-chatting143.blogspot.com/

http://dating-chatting143.blogspot.com/

http://dating-chatting143.blogspot.com/

Vladimir Vassilevsky wrote:
> 

> 
> * Having protocol logic in the Tx/Rx ISRs is a bad idea already.

Absolutely. Lower level comms drivers should always be transparent to
data. You build protocol layers on top of that.

Maybe i'm missing something, but I don't understand what all the fuss is
about in this thread. All this kind of thing has been done to death in
the past. It would help the op to have a look at one of the original
ddcmp protocol specs to see how it should be done, with message flow,
state transitions etc. Why keep on reinventing the wheel ?...

Regards,

Chris

On Tue, 29 Mar 2011 08:49:21 -0500, Vladimir Vassilevsky
<nospam@nowhere.com> wrote:

>
>
>Shane williams wrote:
>
>> On Mar 29, 6:03 pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
>> 
>>>For starters: for the efficient operation, the transmit and the receive
>>>chains should be buffered. In order to change the rate, you have to make
>>>sure the buffers are flushed. If you are planning switching the rate
>>>back and forth, that would incur significant penalty in efficiency.
>> 
>> The hardware handles the sending of a whole message at a time.  The
>> software gives the hardware a whole message to send and gets told when
>> a whole message has been received.  This is done by an interrupt
>> routine.  The interrupt routine will decide when to switch baud rates
>> or check when the other end is asking to switch so the only penalty is
>> a couple of extra messages and a short delay if the switch works.  If
>> the switch doesn't work there's a slightly bigger penalty but we won't
>> be switching often enough for it to matter.
>
>* Having protocol logic in the Tx/Rx ISRs is a bad idea already.
>* How a hub type device would work?
>* What if a node somehow missed the correct baud rate, receiving garbage 
>  and responding to it?
>* How would you verify, troubleshoot and prove the operation?

From the system point of view, including the end of frame detection
(and hence also autobauding) in the ISR makes a lot of sense, since it
reduces the number of times the RT tasks needs to be rescheduled.

Simon Clubley wrote:

> 
> No, but late 80s/early 90s was the start of my career and I was writing
> code for the PDP-11 before moving onto VAX then Alpha and taking in a
> range of other environments along the way.
> 
> It's quite possible you ran across me as part of that, especially if
> you attended the annual DECUS conferences.
> 
> Simon.
> 

I just thought the name sounded familiar. I too spent several years
doing systems engineering, programming macro and C on pdp and vax. Never
attended decus meetings,but was a member and still have some tapes. Worked
at dec park, racal, smiths and others during the good old 80's...

Regards,

Chris

upsidedown@downunder.com wrote:

> 
> From the system point of view, including the end of frame detection
> (and hence also autobauding) in the ISR makes a lot of sense, since it
> reduces the number of times the RT tasks needs to be rescheduled.
> 

There are arguments for and against and there are tradeoffs, different 
if, for example, you are running a state driven loop, rather than an 
rtos. One way to get round the problem is to have an incoming fifo big 
enough to handle data between polling, then a polling function within 
the fifo module that takes two args, start of frame and end of frame. 
The function just scans the fifo from time to time, skipping over 
duplicate sof until a complete frame is recognised, which is then passed 
to the deframer / protocol handler. The interrupt handler never needs to 
be disabled and in the unlikely event of fifo full, the data just wraps 
round, deleting the least recent byte. Acks, nacks, timeouts and retries 
at the next level up then keep the link reliable. You can drive this 
sort of thing in many ways, for example, from a timer callback. This is 
more or less how it's been done for decades...

Regards,

Chris

Hi Shane,

On 3/28/2011 3:28 AM, Shane williams wrote:
> On Mar 28, 6:23 pm, D Yuniskis<not.going.to...@seen.com>  wrote:
>> Regardless...  consider that if you twiddle with the baud rate
>> on any link, you will either need to make sure *all* links
>> "simultaneously" update their baud-rates (taking into
>> consideration any packets "in the pipe")
>>
>> -- or --
>>
>> you have to provide an elastic store in each node and some
>> smarts to decide what data that node can *drop* (since it's
>> outbound connection may not? be at the same rate as it's
>> inbound connection)
>>
>> [this last bit applies iff there is a real second channel
>> in each node like:
>>
>>    AAAA ----> BBBB ----> CCCC ----> DDDD
>>    AAAA       BBBB       CCCC       DDDD
>>    AAAA <---- BBBB <---- CCCC <---- DDDD
>
> It's physically a 2 wire half duplex ring with messages going in both
> directions around the ring to provide redundancy.  Say 8 nodes 1 to
> 8.  Node 1 talks to nodes 2 and 8, node 2 talks to nodes 1 and 3 etc.

Is this a synchronous protocol?  Or, are you just using a pair
of UARTs on each device to implement the CW & CCW links?

If that's the case, you have to remember to include all the
"overhead bit(-time)s" in your evaluation of the error rate
and your performance thereunder.

E.g., a start bit error is considerably different than a
*data* bit error (think about it).

> However we may end up with 3 ports per node making it a collection of
> rings or a mesh.  The loading at the slowest baud rate is approx 10%

[scratches head] then why are you worrying about running at
a higher rate?  Latency might be a reason -- assuming you
don't circulate messages effectively as they pass *through*
a node.  But, recall that you only have to pass through
32 nodes, worst case, to get *a* copy of a message to any
other node...

> for 64 nodes.  If we decide to allow mixed baud rates, each node will
> have the ability to tell its adjacent nodes to slow down when its
> message queue gets to a certain level, allowing it to cope with a
> brief surge in messages.

Depending on how you chose to allocate the Tx&Rx devices in each
link -- and, whether or not your baudrate generator allows
the Tx and Rx to run at different baudrates -- you have to:
* make sure your Tx FIFO (hardware and software) is empty before
   changing Tx baudrate
* make sure your "neighbor" isn't sending data to you when you
   change your Rx baudrate (!)

Consider that a link (a connection to *a* neighbor) that "gives you
problems" will probably (?) cause problems in all communications
with that neighbor (Tx & Rx).  So, you probably want to tie the
Tx and Rx channels of *one* device to that neighbor (vs. splitting
the Rx with the upstream and Tx with the downstream IN A GIVEN RING)

[this may seem intuitive -- or not!  For the *other* case, see end]

Now, when you change the Rx baudrate for the upstream CW neighbor,
you are also (?) changing the Tx baudrate for the downstream CCW
neighbor (the "neighbor" is the same physical node in each case).
Also, you have to consider if you will be changing the baudrate
for the "other" ring simultaneously (so you have to consider the
RTT in your switching calculations).

Chances are (bet dollars to donuts?), the two rings are in different
points of their message exchange (since the distance from message
originator to that particular node is different in the CW ring
vs. the CCW ring).  I.e., this may be a convenient time to change
the baudrate (thereby INTERRUPTING the flow of data around the ring)
for the CW ring -- but, probably *not* for the CCW ring.

[recall, changing baudrate is probably going to result in lots
of errors for the communications to/from the affected neighbor(s)]

So, you really have to wait for the entire ring to become idle
before you change baudrates -- and then must have all nodes do
so more or less concurrently (for that ring).  If you've split the
Tx and Rx like I described, then this must also happen on the
"other" ring at the same time.

Regarding the "other" way to split the Tx&Rx... have the Tx
always talk to the downstream neighbor and Rx the upstream
IN THE SAME RING.  In this case, changes to Tx+Rx baudrates
apply only to a certain ring.  So, you can change baudrate
when it is convenient (temporally) for that *ring*.

But, now the two rings are potentially operating at different
rates.  So, the "other" ring will eventually ALSO have to
have its baudrate adjusted to match (or, pass different traffic)

> Also to help the propagation delay, we might
> split long messages to a max of 50 bytes or so.

Hi Chris,

On 3/29/2011 8:01 AM, ChrisQ wrote:
> upsidedown@downunder.com wrote:
>
>> From the system point of view, including the end of frame detection
>> (and hence also autobauding) in the ISR makes a lot of sense, since it
>> reduces the number of times the RT tasks needs to be rescheduled.
>
> There are arguments for and against and there are tradeoffs, different
> if, for example, you are running a state driven loop, rather than an
> rtos. One way to get round the problem is to have an incoming fifo big
> enough to handle data between polling, then a polling function within
> the fifo module that takes two args, start of frame and end of frame.
> The function just scans the fifo from time to time, skipping over
> duplicate sof until a complete frame is recognised, which is then passed
> to the deframer / protocol handler. The interrupt handler never needs to
> be disabled and in the unlikely event of fifo full, the data just wraps
> round, deleting the least recent byte. Acks, nacks, timeouts and retries
> at the next level up then keep the link reliable. You can drive this
> sort of thing in many ways, for example, from a timer callback. This is
> more or less how it's been done for decades...

I think the OP is pretty much stuck with having logic in the ISR.
Consider, the upstream Rx IRQ has to push the received packet into
the downstream Rx FIFO to propagate the message around that ring.
At the very least, the Rx ISR needs to decide if the message
"looks" correct -- at least, "correct enough" to warrant passing
it along (presumably, you don't want to propagate errors that
were picked up locally -- since those errors can then become
UNerrors on the next op...)

If the Rx ISR had to require the intervention of user-land code
(or, any higher level of the protocol stack) to move the received
packet "out", then the time spent *in* the node would increase
dramatically which is reflected in the RTT of the entire ring(s).

D Yuniskis wrote:
> Hi Chris,
> 
> 
> I think the OP is pretty much stuck with having logic in the ISR.
> Consider, the upstream Rx IRQ has to push the received packet into
> the downstream Rx FIFO to propagate the message around that ring.
> At the very least, the Rx ISR needs to decide if the message
> "looks" correct -- at least, "correct enough" to warrant passing
> it along (presumably, you don't want to propagate errors that
> were picked up locally -- since those errors can then become
> UNerrors on the next op...)
> 
> If the Rx ISR had to require the intervention of user-land code
> (or, any higher level of the protocol stack) to move the received
> packet "out", then the time spent *in* the node would increase
> dramatically which is reflected in the RTT of the entire ring(s).

One could ask about the wisdom of using a ring topology, which will
always involve more latency than a multidrop network using some sort of
poll / select or request / response protocol. You must have more than one
comms link for redundancy, as any break in the ring isolates any node
past the fault. You need double the comms hardware, as each node needs
an rx and tx uart. In the presence of faults, a ring topology doesn't
degrade anything like as gracefully, as multidrop either. Finally, where
does ddcmp fit into the picture ?. Ddcmp is more than just a frame
format, it's a complete protocol spec with defined messages flows, state
transitions, error recovery etc...

Regards,

Chris

Hi Chris,

On 3/29/2011 10:39 AM, ChrisQ wrote:
> D Yuniskis wrote:
>
>> I think the OP is pretty much stuck with having logic in the ISR.
>> Consider, the upstream Rx IRQ has to push the received packet into
>> the downstream Rx FIFO to propagate the message around that ring.
>> At the very least, the Rx ISR needs to decide if the message
>> "looks" correct -- at least, "correct enough" to warrant passing
>> it along (presumably, you don't want to propagate errors that
>> were picked up locally -- since those errors can then become
>> UNerrors on the next op...)
>>
>> If the Rx ISR had to require the intervention of user-land code
>> (or, any higher level of the protocol stack) to move the received
>> packet "out", then the time spent *in* the node would increase
>> dramatically which is reflected in the RTT of the entire ring(s).
>
> One could ask about the wisdom of using a ring topology, which will
> always involve more latency than a multidrop network using some sort of
> poll / select or request / response protocol.

Yup.  I'm *guessing* this was just a "free" (hardware) approach.
You'd have to ask the OP for his specific reasons for this approach...

> You must have more than one
> comms link for redundancy, as any break in the ring isolates any node
> past the fault.

Hence the double ring approach -- with twice the "cost".

> You need double the comms hardware, as each node needs
> an rx and tx uart. In the presence of faults, a ring topology doesn't
> degrade anything like as gracefully, as multidrop either.

Well, to be fair, with a bus topology, anything that can
toast/busy the bus indefinitely will shutdown *all*
communications.  With a ring, one can at least talk to
one's neighbor (even if you can't get a reply).

I.e., a node can say "the bozo upstream from me is spouting
endless gibberish" (or, "hasn't said anything in *DAYS*")
and, therefore, you can hope folks downstream from you propagate
this and, as a result, know that they should move to a safe/secure
state *and* know where the fault likely lies.

In a bus topology, everyone has to monitor the bus's health
independently and there is *no* communication in the event of
a failure.

I know of at least one such design in which the "master(s)" had
the ability to impress a high voltage on the bus with the
intent that a malfunctioning node wouldn't be smart enough to
galvanically isolate itself from the bus during this event
(this would blow fuses that would, thereafter, isolate the
offending node  :> ).

No idea how well this worked, in practice. Amusing idea, though!
If only *all* problems could be solved with a suitably high
voltage  ;)

> Finally, where
> does ddcmp fit into the picture ?. Ddcmp is more than just a frame
> format, it's a complete protocol spec with defined messages flows, state
> transitions, error recovery etc...

D Yuniskis wrote:
> Hi Chris,
> 
> Well, to be fair, with a bus topology, anything that can
> toast/busy the bus indefinitely will shutdown *all*
> communications.  With a ring, one can at least talk to
> one's neighbor (even if you can't get a reply).
>

That's true, say with an line turnaround after tx that doesn't, thereby
pulling the line down. It's still a lower cost solution than the ring
approach. Of course, ethernet fixes that problem, but at the cost of
increased software complexity, so there really is no free lunch.

> In a bus topology, everyone has to monitor the bus's health
> independently and there is *no* communication in the event of
> a failure.

You often need a keep alive packet for ongoing health check,
which would fail to get an ack on a hardware failure, but that's still
less hw in the path than ring topology, so better mtbf (in theory) to
start with.

> 
> I know of at least one such design in which the "master(s)" had
> the ability to impress a high voltage on the bus with the
> intent that a malfunctioning node wouldn't be smart enough to
> galvanically isolate itself from the bus during this event
> (this would blow fuses that would, thereafter, isolate the
> offending node  :> ).

Horrifying, though I guess you could implement that using zener diodes and
limiting r on each node for protection, placed after, say, 50mA fuses,
which would be easy to open circuit. Sounds a bit extreme though...

Regards,

Chris