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: New StreamDevice version |
From: | Dirk Zimoch <[email protected]> |
To: | [email protected] |
Cc: | [email protected] |
Date: | Mon, 06 Dec 2010 16:26:04 +0100 |
Hi Dirk,
Thanks for that, I think the ability to consume arbitrary amounts of whitespace is useful as it does make the protocol files easier. At least for me, the backwards compatibly for me isn't a big deal as this is a new device I'm writing support for. btw, I like the new TIME feature, it neatly solves a problem I had with trying to set the time and date in my device.
I've ran into another problem with the latest snapshots though (both 20101203 and 20101129 but not in 20100615). I'm seeing a crash in StreamCore.cc. It doesn't seem to happen with a device emulator I have but does wit the real device which responds a bit slower (it's an RS-232 over Ethernet device) so it might be timing related. It looks like StreamDevice is getting stuck in a loop as the call stack is over 300 calls deep when it crashes. It's going between evalIn() and readCallback().
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0000000100686e08
[Switching to process 6213]
0x00000001000a0818 in StreamCore::readCallback (this=0x102008800, status=StreamIoTimeout, input=0x0, size=0) at ../StreamCore.cc:903
903 const void* input, long size)
(gdb) b
Breakpoint 1 at 0x1000a0818: file ../StreamCore.cc, line 903.
(gdb) bt #0 0x00000001000a0818 in StreamCore::readCallback (this=0x102008800, status=StreamIoTimeout, input=0x0, size=0) at ../StreamCore.cc:903
#1 0x000000010009e823 in StreamCore::evalIn (this=0x102008800) at ../StreamCore.cc:874
#2 0x00000001000a13e3 in StreamCore::readCallback (this=0x102008800, status=StreamIoTimeout, input=<value temporarily unavailable, due to optimizations>, size=0) at ../StreamCore.cc:1070
#3 0x000000010009e823 in StreamCore::evalIn (this=0x102008800) at ../StreamCore.cc:874
#4 0x00000001000a13e3 in StreamCore::readCallback (this=0x102008800, status=StreamIoTimeout, input=<value temporarily unavailable, due to optimizations>, size=0) at ../StreamCore.cc:1070
..
..
#311 0x000000010009e823 in StreamCore::evalIn (this=0x102008800) at ../StreamCore.cc:874
#312 0x00000001000a13e3 in StreamCore::readCallback (this=0x102008800, status=StreamIoTimeout, input=<value temporarily unavailable, due to optimizations>, size=0) at ../StreamCore.cc:1070
#313 0x0000000100089c5f in StreamBusInterface::readCallback () at /Users/has09e/src/askapsoft/3rdParty/EPICS/3.14.11/support/streamDevice/streamDevice-2-5/StreamDevice-2-5/src/StreamBusInterface.h:933
#314 0x0000000100089c5f in AsynDriverInterface::readHandler (this=0x1010039b0) at ../AsynDriverInterface.cc:933
#315 0x0000000100089eb8 in handleRequest (pasynUser=<value temporarily unavailable, due to optimizations>) at ../AsynDriverInterface.cc:1356
#316 0x000000010000dd0d in portThread (pport=0x100465f10) at ../../asyn/asynDriver/asynManager.c:828
#317 0x000000010028bbe2 in start_routine (arg=<value temporarily unavailable, due to optimizations>) at ../../../src/libCom/osi/os/posix/osdThread.c:282
#318 0x00007fff804cb536 in _pthread_start ()
#319 0x00007fff804cb3e9 in thread_start ()
The protocol looks like this
one command to send out the poll
get_flashNearN { out "A"; in "NEAR: N %f NE %*f E %*f SE %*f S %*f SW %*f W %*f NW %*f "; }
and 18 commands that are set as INTR/IO scan in the records
get_flashDistNW { in "DIST: N %*f NE %*f E %*f SE %*f S %*f SW %*f W %*f NW %f "; }
get_flashCloud { in "OVHD %*f CLOUD %f TOTAL %*f P %*2XH %*f C"; }
I've only tested this on the mac so far. If there is any debug trace I can get to help find the issue please let me know.
Regards
Craig
On 03/12/2010, at 9:59 PM, Dirk Zimoch wrote:
Hello Craig,
Thanks for testing it on Mac.
The effect you found is indeed an incompatibility. I think I better remove it again and look for something better. I was trying to be more compatible with the sscanf format strings, where a space consumes arbitrary amounts of whitespace (see: man sscanf). Thus in your case it is not the last %s but the spaces after the %s that consume the \r\n. I think I better remove that feature again to stay backward compatible. Maybe I better go for a special escape sequence for "arbitrary amount of white space".
Dirk
[email protected] wrote:Hi Dirk,
Thanks for the new release. I can confirm it builds OK on Snow Leopard 10.6.5. I've run into a difference with the previous snapshot though. I have a protocol as follows
InTerminator = "> "; OutTerminator = CR LF; ExtraInput = Ignore;
get_airTemp { out "R1"; in "R1\r\n%*s ,%*s ,%*s ,%*s ,%*s ,%*s ,%*s ,%*s ,%*s ,%*s ,%*s ,%*s ,%*s ,%*s ,%*s \r\n%*f,%*f,%*f,%f,%*f,%*f,%*f,%*f,%*f,%*f,%*f,%*f,%*f,%*f,%*f"; }
to handle the follow command & 3 line response from my device
R1R1 WS= ,WD= ,RH= ,AT= ,RG= ,SR= ,BP= ,S1= ,S2= ,BV= ,LC= ,SV= ,CC= ,9R= ,Ev= +000006.02,+000106.95,+000051.97,+000027.21,+000006.92,+000010.50,+000902.35,+000019.26,+000018.63,+000012.37,+000035.12,+000012.47,+000249.95,+000009.65,+000004.03 km/h ,Degrees,% ,Deg C ,mm ,W/m^2 ,hPa ,Deg C ,Deg C ,V ,mA ,V ,mA ,mm ,mm
The reason for using "> " for the input terminator is to handle a command prompt that the device sends without a CR LF. I then treat the 3 line response as a single line with "\r\n" in the format string. This worked quite well for the 20100615 snapshot but with the latest, I find that the last %*s before the \r\n also consumes the \r\n. So for the new snapshot I need to remove the 2nd "\r\n" in the format string. Not sure if this change was intentional or not. Other than that, works fine on Mac.
Regards
Craig
------------------------------------------------------- Craig Haskins Software Engineer Australia Telescope National Facility CSIRO Astronomy and Space Science P.O.Box 76, Epping NSW 1710, Australia Phone: +61 2 9372 4309 email: [email protected]
------------------------------------------------------- Craig Haskins Software Engineer Australia Telescope National Facility CSIRO Astronomy and Space Science P.O.Box 76, Epping NSW 1710, Australia Phone: +61 2 9372 4309 email: [email protected]