Does anyone know anything about DDCMP and the 68302 chip. We have some software that uses it in asynchronous mode over RS485 and we want to see if we can emulate the DDCMP behaviour on another product without the 68302 micro so that we can communicate with the existing product but from a new device with a different microprocessor. The 68302 manual says that in asynch mode when it's looking for the start of a message that it looks for one of SOH, ENQ or DLE characters. Since these characters can occur within a message, merely searching for one of these characters isn't sufficient and it must be using a timeout as well but the 68000 manual doesn't say anything about that. Does anyone know if it's possible to emulate DDCMP on a micro using an ordinary uart?
DDCMP and 68302
Started by ●August 15, 2018
Reply by ●August 16, 20182018-08-16
On 16/08/2018 10:32 am, gp.kiwi@gmail.com wrote:> Does anyone know anything about DDCMP and the 68302 chip. We have some software that uses it in asynchronous mode over RS485 and we want to see if we can emulate the DDCMP behaviour on another product without the 68302 micro so that we can communicate with the existing product but from a new device with a different microprocessor. > > The 68302 manual says that in asynch mode when it's looking for the start of a message that it looks for one of SOH, ENQ or DLE characters. Since these characters can occur within a message, merely searching for one of these characters isn't sufficient and it must be using a timeout as well but the 68000 manual doesn't say anything about that. > > Does anyone know if it's possible to emulate DDCMP on a micro using an ordinary uart? >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. -- Cheers, Chris.
Reply by ●August 16, 20182018-08-16
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.
Reply by ●August 17, 20182018-08-17
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
