Ok the DS1WM preliminary version is in the git repository.
https://sourceforge.net/p/owfs/code/ci/master/tree/
1. I assume a 10MHz clock (not sure what to do with this option -- I guess
we could have it a command line option but that's messy for users).
2. The tunable parameters (long-line and pulse presence) aren't yet exposed.
3. Untested -- no hardware.
4. Assumes registers mapped and interrupt pin not wired up.
5. Conservative timing choices and little polling to reduce CPU overhead.
Incidentally, I'm suspicious of the w1 kernel module support for the DS1WM.
They don't even have the datasheet pinouts correct in the code.
Paul Alfille
On Tue, Feb 24, 2015 at 7:17 AM, Paul Alfille <paul.alfi...@gmail.com>
wrote:
> Just about done, but I'm not sure how to handle the clock divisor in the
> DS1WM. It needs the actual clock speed input to the DS1WM. Is that standard
> or must I ask the use to supply it.
>
> I thought of self-discovery -- trying different divisors and timing the
> actual reset pulse produced.
>
> Paul
>
> On Mon, Feb 23, 2015 at 2:25 PM, Martin Rapavy <martin.rap...@kistler.com>
> wrote:
>
>> I agree, it would make much more sense to fork your implementation of
>> ds1wm. Could you estimate how long would it take you? I'm quite in a hurry
>> with my project. Or could you perhaps answer the question how OWFS handles
>> updates on that master structures. I suppose this will be essential to
>> extend you DS1WM implementation to match my bus master (which is basically
>> DS1WM with output multiplexer supporting multiple channels/buses).
>> Is there any preliminary codebase I could start working on?
>>
>> Thank you for your support.
>>
>> Best regards,
>> Martin
>> ------------------------------
>> *From:* Paul Alfille [paul.alfi...@gmail.com]
>> *Sent:* Monday, February 23, 2015 7:18 PM
>>
>> *To:* owfs-developers
>> *Subject:* Re: [Owfs-developers] Add support for additional hardware bus
>> master
>>
>> I'm working on the ds1wm support. Just got example code from Maxim.
>> How about basing you modifications from that.
>>
>> Paul
>> On Feb 23, 2015 10:46 AM, "Martin Rapavy" <martin.rap...@kistler.com>
>> wrote:
>>
>>> Hello Paul,
>>>
>>>
>>>
>>> so far I came to following conclusions about the parts of owlib which
>>> need to be extended in order to support new bus master type:
>>>
>>> · Write new module (.c file) which exports a detect function (
>>> K1WM_detect in my case)
>>>
>>> o I suppose this is the configuration/connection function you
>>> mentioned earlier
>>>
>>> o it creates mmap for the bus master device
>>>
>>> o it sets following pointers to functions inside interface_routines
>>> structure
>>>
>>> · Add new “master structure“ (master_uio) into ow_master.h
>>> which holds context of my bus master (active channel, base address of
>>> mentioned 6 registers, pointer to mmap) and add that structure into
>>> master_union
>>>
>>> · Add some command line / configuration file parameters (up to
>>> now not sure where exactly, but I also didn’t pay much attention to it yet)
>>>
>>>
>>>
>>> As for the funtions which are pointed from interface_routines structure
>>> I implemented following:
>>>
>>> · detect (K1WM_detect)
>>>
>>> · reset – this resets the 1wire bus identified by channel
>>> stored in my master_uio structure
>>>
>>> · next_both – hardware assisted search rom (do you call this
>>> function repeatedly untill it returns search_done? So one execution of the
>>> function should set return one ROM in the device_search structure?)
>>>
>>> · sendback_data – transmit/receive of data pointed by its
>>> parameters
>>>
>>> · close – destroys memory mapping to the bus master
>>>
>>> Is that enough or should I implement more functions from that interface?
>>> What exactly is redetect supposed to do (I guess it’s different from
>>> close/detect combo)?
>>>
>>> I’m also not sure how to setup the flags attribute of interface_routines
>>> and bundling_length.
>>>
>>>
>>>
>>> As I said I expect the context of each call (like active channel,
>>> pointer to device memory map, etc.) to be stored in my master_uio
>>> structure. I suppose OWFS needs to know how to setup the context before
>>> calling functions from my module – could you please explain me how this
>>> should be done?
>>>
>>>
>>>
>>> Thanks in advance,
>>>
>>> Martin
>>>
>>>
>>>
>>>
>>>
>>> *From:* Paul Alfille [mailto:paul.alfi...@gmail.com]
>>> *Sent:* Friday, February 20, 2015 3:32 PM
>>> *To:* OWFS (One-wire file system) discussion and help
>>> *Subject:* Re: [Owfs-developers] Add support for additional hardware
>>> bus master
>>>
>>>
>>>
>>> Optimally the number of channels should be auto-discovered. I like to
>>> make the configuration as automatic as possible.
>>>
>>>
>>>
>>> So if the hardware can be safely probed for the number of channels, or
>>> announces the number of channels, that would be best.
>>>
>>>
>>>
>>> Otherwise a command line option would work.Perhaps:
>>>
>>>
>>>
>>> --rapavybus=0xf0000000:6
>>>
>>>
>>>
>>> The syntax i fairly arbitrary, but it should be relatively intuitive or
>>> consistent.
>>>
>>>
>>>
>>> Paul
>>>
>>>
>>>
>>> On Fri, Feb 20, 2015 at 7:47 AM, Martin Rapavy <
>>> martin.rap...@kistler.com> wrote:
>>>
>>> Yes, 6 registers in consecutive memory locations (offests 0 .. 5).
>>> I suppose we need to pass the base address as command line / configuration
>>> file parameter.
>>>
>>>
>>>
>>> How does owfs treat channels? Do we need to pass number of channels as
>>> command line / configuration file parameter as well?
>>>
>>>
>>>
>>> Thanks,
>>> Martin
>>>
>>>
>>>
>>> *From:* Paul Alfille [mailto:paul.alfi...@gmail.com]
>>> *Sent:* Friday, February 20, 2015 1:43 PM
>>> *To:* owfs-developers
>>> *Subject:* Re: [Owfs-developers] Add support for additional hardware
>>> bus master
>>>
>>>
>>>
>>> Do you map the 6 control registers to consecutive memory locations?
>>> Would we pass that location in a command line option?
>>>
>>> On Feb 19, 2015 12:16 PM, "Jan Kandziora" <j...@gmx.de> wrote:
>>>
>>> Am 19.02.2015 um 08:59 schrieb Martin Rapavy:
>>> > Hi Paul,
>>> >
>>> > thanks for briefing me on the architecture of OWFS. My master chip
>>> > has almost exactly the same register interface as Dallas DS1WM
>>> > (http://datasheets.maximintegrated.com/en/ds/DS1WM.pdf). It only
>>> > differs in one register: Clock divisor register (0x04) is missing and
>>> > instead there’s Output Channel Multiplexer register on the same
>>> > address (0x04). This register is used to enable handling of multiple
>>> > channels (1wire busses) by single chip.
>>> >
>>> Ohh, maybe we get native support for DS1WM? Sweeeet!
>>>
>>> Kind regards
>>>
>>> Jan
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
