With the LibStart() call inserted (or using OW_init without the program name as
a first argument), I can now step into the connection process. Unfortunately
it fails in COM_write_once during a write() call. It is trying to write 50
bytes, and the write of the first pipe causes a SIGPIPE exception if I’m
stepping through the code. If I let it run past it still fails somewhere with
a failure to talk to the enet device.
> On Nov 10, 2017, at 11:00 AM, Andrew Brownsword
> <andrew.e.brownsw...@gmail.com> wrote:
>
> I noticed that OW_init_args() doesn’t appear to call LibStart(NULL), while
> OW_init() does. Is this by design? By inserting the LibStart(NULL) call
> things proceed much further, and although it is still having issues
> communicating with my enet device, at least now it is trying!
>
>
>> On Nov 10, 2017, at 9:38 AM, Andrew Brownsword
>> <andrew.e.brownsw...@gmail.com <mailto:andrew.e.brownsw...@gmail.com>> wrote:
>>
>> Thanks Justin and Jan, your replies help enormously. I can now step into
>> the libowcapi code, at least, and therefore can make forward progress.
>> Might I suggest that the libowcapi man page(s) be supplemented to contain
>> this information as well? I couldn’t find it.
>>
>> The first thing I discovered was that the reason my program had no bus.0/
>> entry was because I neglected to include a first argument that is the
>> program name. My —enet= option got eaten and ignored as a result… a bit
>> surprising but easily fixed. So now my program and the test program fail in
>> the same way.
>>
>> The second thing noticed (and I’ve only started to dive deeper) is it
>> doesn’t appear that a thread was spawned during the init and the OW_get sees
>> a NULL pin pointer, sets a badthread flag and basically bails at that point.
>> Can anyone illuminate where the thread is supposed to get spawned?
>>
>>
>>> On Nov 8, 2017, at 4:37 PM, Justin Brewer <justin.bre...@vertivco.com
>>> <mailto:justin.bre...@vertivco.com>> wrote:
>>>
>>> On Wed, Nov 08, 2017 at 01:51:49PM -0800, Andrew Brownsword wrote:
>>>> Nothing but crickets — is anyone out there?
>>>>
>>>> I’ve been poking at the code to try and figure out how to enable my
>>>> debugger to step into the libowcapi/libow code, but the make process is
>>>> obscure enough that some advice would be welcome...
>>>
>>> If you're working from a clean git clone, I use this for working with just
>>> owcapi:
>>>
>>> $ autoreconf -i
>>> $ ./configure CFLAGS='-g -O0' --prefix=$HOME/opt/owfs
>>> --disable-{zero,ow{perl,python,php,tcl}}
>>> $ make
>>> $ make -k install
>>>
>>> This lets me ignore most of the language binding dependencies, and ignore
>>> some hardcoded install paths.
>>>
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On Oct 31, 2017, at 3:11 PM, Andrew Brownsword
>>>>> <andrew.e.brownsw...@gmail.com <mailto:andrew.e.brownsw...@gmail.com>>
>>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I have an EDS ETH-OWSERVER v2, and I am trying to talk to it using the
>>>>> owcapi library. The init with arts function returns success but when I
>>>>> try to OW_get, I don’t see any buses or sensors (just the meta
>>>>> directories). If I run owserver, it sees the enet device and it’s 3
>>>>> buses and 22 sensors just fine. I ran a simple owcapi test program and
>>>>> it sees one bus and zero sensors.
>>>>>
>>>>> My program is multi-threaded and the OW_get will be called from a
>>>>> different thread than the init (but correctly ordered). As for the test
>>>>> program, it is just the init and then a get of root.
>>>>>
>>>>> I’m using the latest release and running on either an Ubuntu ARM host or
>>>>> on OSX... same behavior either way.
>>>
>>> I have been working on some issues I've found in libow, and have seen
>>> similair symptoms. There's some race conditions that, if it doesn't
>>> outright crash, causes random failures elsewhere. I have a patch that
>>> resolves these issues here:
>>>
>>> https://gitlab.com/justinbrewer/owfs/commit/0234a2cecb56d0b6ca4d20a6100a2d2b2ba6bffb.patch
>>>
>>> <https://gitlab.com/justinbrewer/owfs/commit/0234a2cecb56d0b6ca4d20a6100a2d2b2ba6bffb.patch>
>>>
>>> I was planning on submitting a pull request in the next day or so, but I
>>> think this patch help you.
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org <http://slashdot.org/>!
>>> http://sdm.link/slashdot <http://sdm.link/slashdot>
>>> _______________________________________________
>>> Owfs-developers mailing list
>>> Owfs-developers@lists.sourceforge.net
>>> <mailto:Owfs-developers@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>> <https://lists.sourceforge.net/lists/listinfo/owfs-developers>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
