Paul, Yes that's the idea. That way multiple clients can use the same bus master without stepping on each others' toes too much.
I've emailed Jacob who wrote the EtherWeather driver (and built the boards) and he's happy for me to pick up where he left off. I like the protocol as it's really simple but seems to expose enough for things to work well. I'm not fond of HA7Net's wrapping of 1-Wire in pseudo-HTTP. What I propose is to take the EtherWeather driver as a starting point and fork it, adding the locking I require and fixing any other issues as I go along. Cheers, Chris On 19 Mar 2011, at 02:31, Paul Alfille wrote: > So basically you want to send a special "lock" and "unlock" messages > to your adapter? I guess there could be a stub locking routine for > each adapter. I'd love to see some patches. > > Etherweather may not be the best example implementation to use. It was > written by the etherweather creator, who seems to have stopped > development. As far as I know, it hasn't been tested for more than a > year and all the changes in the code were by inference to keep up with > other developments in OWFS. > > Paul Alfille > > > On Fri, Mar 18, 2011 at 6:15 PM, Chris Boot <[email protected]> wrote: >> Paul, >> >> Would you be receptive to patches to add a mechanism that other drivers >> can use too? I could add lock/unlock functions to interface_routines in >> ow_bus_routines.h that the code in ow_buslock.c could call into. That >> was HA7Net can use it if it wants to in future. >> >> I'm not sure what you mean about communicating with the other process. I >> imagine owfs will try to get a lock from the device (over IP) and if it >> fails it will wait for a little while and try again, or give up and >> error out. >> >> As for my bus driver, I was going to write my code with the EtherWeather >> driver as inspiration but with some changes to accommodate the locking >> and a few other little things. >> >> If that sounds like a good idea I'll get started and submit my patches >> in the next few weeks. >> >> Cheers, >> Chris >> >> On 18/03/2011 20:02, Paul Alfille wrote: >>> I would simply add your code to module/owlib/src/c/ow_buslock.c in >>> functions BUS-lock_in and BUS_unlock_in. If there are other 1-wire >>> buses you should add some text to make sure you only lock when the >>> correct bus is referenced. >>> >>> I don't know how you plan on communicating with the other process. >>> Perhaps a file lock? >>> >>> The code in HA7Net is interesting. The hardware has a lock function, >>> but it expires on it's own after 1 second. I made the assumption that >>> owfs would be used as the exclusive client and merely clear any >>> existing lock at the start. >>> >>> Paul Alfile >>> >>> On Fri, Mar 18, 2011 at 8:05 AM, Chris Boot<[email protected]> wrote: >>>> Hi folks, >>>> >>>> I'm currently building a microcontroller-based device which has a 1-wire >>>> bus and ethernet. This is intended to be a self-contained device for >>>> home automation or industrial control and will query 1-wire devices >>>> attached to it to gather temperature data and suchlike. Internally I use >>>> a DS2812-100 for my bus master. >>>> >>>> I really would like to write an owfs driver for the device so that its >>>> 1-wire attached devices can also be queried by owfs. The problem I have >>>> is as the bus needs to be shared between the controller's internal code >>>> and owfs, so I need to implement some sort of bus locking. It appears >>>> that owfs cannot do that - it has internal locking but can't seem to >>>> tell an external bus master to be locked. >>>> >>>> I looked at the source for the HA7NET controller and it seems to have a >>>> little code in there for locking, but that just releases a lock if it's >>>> acquired - and never tries to claim a lock. >>>> >>>> Can I do what I want without major owfs surgery? >>>> >>>> Thanks, >>>> Chris >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Colocation vs. Managed Hosting >>>> A question and answer guide to determining the best fit >>>> for your organization - today and in the future. >>>> http://p.sf.net/sfu/internap-sfd2d >>>> _______________________________________________ >>>> Owfs-developers mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers >>>> >>> ------------------------------------------------------------------------------ >>> Colocation vs. Managed Hosting >>> A question and answer guide to determining the best fit >>> for your organization - today and in the future. >>> http://p.sf.net/sfu/internap-sfd2d >>> _______________________________________________ >>> Owfs-developers mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/owfs-developers >> >> >> ------------------------------------------------------------------------------ >> Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit >> for your organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> _______________________________________________ >> Owfs-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/owfs-developers >> > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Owfs-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/owfs-developers -- Chris Boot [email protected] ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Owfs-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
