Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #27974

Re: DDCMP and 68302

From Chris <xxx.syseng.yyy@gfsys.co.uk>
Newsgroups comp.arch.embedded
Subject Re: DDCMP and 68302
Date 2018-08-17 13:57 +0100
Organization Aioe.org NNTP Server
Message-ID <pl6gn3$b2u$1@gioia.aioe.org> (permalink)
References <4cd9203f-09d8-46e9-b93f-e3a61f1fc20a@googlegroups.com> <pl319g$p7b$1@gioia.aioe.org> <cad54445-e2c0-4e5d-aa98-fb335d04ae74@googlegroups.com>

Show all headers | View raw


On 08/16/18 12:30, gp.kiwi@gmail.com wrote:
> On Thursday, August 16, 2018 at 5:15:32 PM UTC+12, Chris wrote:
>> The spec (or a version of it) appears to be here:
>>
>> http://decnet.ipv7.net/docs/dundas/aa-d599a-tc.pdf
>>
>> Page 34 talks about framing the packets on an asynchronous links. The
>> general gist is that once the start character is found (SOH, ENQ, DLE)
>> is found the packet will follow a fixed format.
>>
>> If you find a start character the middle of a packet (for example), then
>> the CRC will fail and you're required to follow the protocol and request
>> a retransmit or other remedy to resynchronise.
>>
>> This should be relatively straight forward to implement with almost any
>> async serial interface.
>
> ok, thanks.

I would probably implement that as a simple state machine. Scan for a
start of frame and start again if you see another within the frame.
However, depending on the frame format, controls such as sof are
often escaped if they appear within the data portion of the frame...

Chris

Back to comp.arch.embedded | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

DDCMP and 68302 gp.kiwi@gmail.com - 2018-08-15 17:32 -0700
  Re: DDCMP and 68302 Chris <c@b.a> - 2018-08-16 15:15 +1000
    Re: DDCMP and 68302 gp.kiwi@gmail.com - 2018-08-16 04:30 -0700
      Re: DDCMP and 68302 Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-08-17 13:57 +0100

csiph-web