1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 <2024> | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 <2024> |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: StreamDevice+regex for escaping and unescaping HEX messages |
From: | Sebastian Eckert via Tech-talk <tech-talk at aps.anl.gov> |
To: | Zimoch Dirk <dirk.zimoch at psi.ch> |
Cc: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Mon, 8 Jan 2024 09:57:13 +0100 |
Dear Dirk,
Sorry for the delayed response!
I just tested [^], which causes an error at "startup _main_ missing terminating ] for character class after "[^]\J"".
[\^] causes the same wrong behavior as before (it just replaces the 0x5E by 0x11).
Best regards,
Sebastian
Does [^] work? DirkAm 23.12.2023 um 15:20 schrieb Sebastian Eckert <sebastian.eckert at helmholtz-berlin.de>: Hi Dirk, Thanks for replying while you are on vacation! \^ yields the same behavior. I would be happy if you could test this when you are back at work. Happy Holidays! SebastianAm 23.12.2023 um 09:44 schrieb Zimoch Dirk <dirk.zimoch at psi.ch>: Hi Sebastian, I am currently on vacation and thus cannot test anything. But you may try to escape the problematic byte as \^ DirkAm 22.12.2023 um 20:16 schrieb Sebastian Eckert via Tech-talk <tech-talk at aps.anl.gov>:Dear StreamDevice+regex experts, I am trying to communicate with a device with a communication protocol, where messages contain: - 0x0D (Start of a message) - a source and a destination byte (to assign replies to requests) - 0x04 or 0x05 or 0x08 (read, write, data) - address of the register to access (can be multiple bytes) - data (can be multiple bytes, depending on data type, little endian) - CRC16 xmodem checksum (without leading 0x0D) - 0x0A Before dressing the message with 0x0D and 0x0A, special characters need to be escaped by adding a 0x5E byte before the corresponding byte and increasing the decimal value of the byte by 64 (0x0A to 0x5E 0x4A, 0x0D to 0x5E 0x4D, 0x11 to 0x5E 0x51, 0x13 to 0x5E 0x53, 0x40 to 0x5E 0x80, 0x5E to 0x5E 0x9E). When a message is received, the message (without the leading 0x0D and 0x0A in the end) needs to be un-escaped in the same fashion. An example for reading a gain value (0x88 0x13 0x00 0x00, signed 32bit integer, escaped: 0x88 0x5E 0x53 0x00 0x00, dec: 5000) is: out: 0x0D 0xFF 0x03 0x04 0x01 0x03 0x07 0x02 0x74 0xA6 0x0A in: 0x0D 0x03 0x42 0x08 0x01 0x88 0x5E 0x53 0x00 0x00 0x90 0xA1 0x0A Here 0x01 0x03 0x07 0x02 is the address of the register we want to read. In the reply only the first byte of the register (0x01), which was read, is mentioned. Below is the protocol file, in which I escape and unescape the messages with regular expressions. It works correct for sending commands to the device. The received messages are not un-escaped correctly. In the example above, it just replaces the 0x5E by 0x11. My guess is that the 0x5E (^) creates the biggest problems due to its distinct role in regex. The outcome of the byte transformation also drastically depends on the order in which the individual un-escape regex-expressions are applied. I would appreciate any idea of what could by the problem with the expressions. Best regards! Sebastian ---------proto file--------------------- Terminator = LF; preo = 0x0D,0xFF,0x03; prei = 0x0D,0x03,0x42; get = 0x04; write = 0x05; gain = 0x01,0x03,0x07,0x02; esco = "%#/\x5E/\x5E\x9E/" "%#/\x11/\x5E\x51/" "%#/\x13/\x5E\x53/" "%#/\x40/\x5E\x80/" "%#/(?<!^)\x0D/\x5E\x4D/" "%#/\x0A/\x5E\x4A/"; unesci = "%#/\x5E\x4A/\x0A/" "%#/\x5E\x51/\x11/" "%#/\x5E\x80/\x40/" "%#/\x5E\x4D/\x0D/" "%#/\x5E\x53/\x13/" "%#/\x5E\x9E/\x5E/"; getGain{ out $preo $get $gain "%1.0<xmodem>" $esco; in $unesci $prei BS 0x01 "%#4r" "%1.0<xmodem>"; } setGain{ out $preo $write $gain "%#4.4r%1.0<xmodem>" $esco; in $unesci $prei ETX $write 0x01 "%1.0<xmodem>"; @init{ out $preo $get $gain "%1.0<xmodem>" $esco; in $unesci $prei BS 0x01 "%#4r%1.0<xmodem>"; } } ----------db file--------------------- record (longin,"$(P):gain") { field (DTYP, "stream") field (INP, "@syncroStream.proto getGain $(PORT)") field (PINI,"YES") } record (longout,"$(P):gain_set") { field (DTYP, "stream") field (OUT, "@syncroStream.proto setGain $(PORT)") } -- Sebastian Eckert Helmholtz-Zentrum Berlin für Materialien und Energie BESSY II - PS-ISRR Albert-Einstein-Str. 15 12489 Berlin Germany E-mail: sebastian.eckert at helmholtz-berlin.de Tel.: +49 30 8062 14465
-- Sebastian Eckert Helmholtz-Zentrum Berlin für Materialien und Energie BESSY II - PS-ISRR Albert-Einstein-Str. 15 12489 Berlin Germany E-mail: sebastian.eckert at helmholtz-berlin.de Tel.: +49 30 8062 14465