I am finally getting around to modifications of drvAscii.
One change is to allow one to specify the octal and hexidecimal escape
sequences so that one can embed non-ASCII bytes into prompts and
respones (to/fro remotely connected devices). This is to allow use
of drvAscii with devices that use some for of a minimal protocol.
My intent is to parse the sequences as standard C formats. My concern
is that some site(s) may currently use a device which uses those
sequences in it's command stream. With the modifications it will
require that those sequences be modified with an additional '\'.
That is, if a device currently has commands of the form '\034' or
'\x469' or '\789' then those commands, within drvAscii record parm
field specifications, would need to have a '\' prepended.
Will this be a problem for anyone? If so please speak up.
Other modifications will be:
- to fix minor bugs that people have discovered over the years;
- (hopefully) correct the "%c" prompt behavior which is
not currently what one would expect (sprintf into "%c"
is done via a char pointer, which is incorrect)
- provide a way to allow analog rval processing to be
bypassed on a record-by-record or link-specific basis (note
that one must currently use the 'slope' record to affect all
analog values on a given link);
- allow "%e" format strings;
- correct for loss of synchronization which may occur if a
response is lost or mangled (i.e. attempt to resynch auto-
matically for the flurries of 'semTake failed' messages that
occur during miscomms);
- allow one to specify an input and/or output framing routine
which can handle more complex protocols or checksums.
In regards to the user-defined framing routines, be aware that drvAscii
still inherently uses sprintf and sscanf so the streams that the
drvAscii functions process must not have embedded NUL characters, or
whitespace other than as expected per the parm field specifications.
All modifications, other than the '\' escape sequence handling described
above, will not affect existing drvAscii database records that use the
current baseline driver as taken from the Keck ftp site.
If anyone has any other potential mods please yell back.
- Navigate by Date:
RE: Cross compiler source and patch file for gcc-2.7.2 on Linux dht
making sense of peculiar ifShow report Matthieu Bec
- Navigate by Thread:
epics 3.14.0Base1 build problem Peter Kurpis
drvAscii Allan Honey