Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

Ursin Soler
Hello!

By this year (initial release 7/15) Maxim released the DS28E17 [1] which is in my oppinion a game changer. This is (to my knowledge) the first time a 1-wire slave has been released that allows to connect any micro-proc (like Arduino/AVR) in a generic and easy way. Even though the DS2408 [2] (1-Wire 8-Channel Addressable Switch) enables this as well I would not consider it as easy or simple.

The DS28E17 enables to implement any DIY slave imaginable for e.g. home automation like applications, segmentation and extension of networks, wireless connections/bridges, etc.

Therefore I would like to proppose to add support for the DS28E17:
1) generic interface as for any other chip supported by OWFS
2) bridge mode that allows to use a DS28E17 <-> DS2482-100 [3] combination to extend a 1-wire network (may be support DS2482-800 too)

I would like to open the discussion here and gather feedback, ideas and oppinions. Please contribute - thanks in advance!

[1] https://www.maximintegrated.com/en/products/interface/controllers-expanders/DS28E17.html
[2] https://www.maximintegrated.com/en/products/digital/memory-products/DS2408.html
[3] https://www.maximintegrated.com/en/products/interface/controllers-expanders/DS2482-100.html

Thanks and Greetings
Ursin Soler

Am 29. Dezember 2015 13:06:54 MEZ, schrieb [hidden email]:
Send Owfs-developers mailing list submissions to
[hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/owfs-developers
or, via email, send a message with subject or body 'help' to
[hidden email]

You can reach the person managing the list at
[hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Owfs-developers digest..."


Today's Topics:

1. Compiling OWFS for Ubuntu (Markus Gaugusch)
2. Re: Compiling OWFS for Ubuntu (Jan Kandziora)
3. Re: Compiling OWFS for Ubuntu (Matthias Urlichs)
4. Re: Compiling OWFS for Ubuntu (Markus Gaugusch)
5. Re: Compiling OWFS for Ubuntu (Iztok Jeras)





Message: 1
Date: Mon, 28 Dec 2015 23:19:21 +0100 (CET)
From: Markus Gaugusch <[hidden email]>
Subject: [Owfs-developers] Compiling OWFS for Ubuntu
To: "OWFS (One-wire file system) discussion and help"
<[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; format=flowed; charset=US-ASCII

Hi,

I'm using Ubuntu 15.10 and the included owfs (2.9p8) is quite old. I'd
like to build a current version, but all information I could find for
building on Ubuntu is quite outdated (based on 12.04 and cvs).

Best option for me would be to build .deb packages. I switched to Ubuntu
recently and I'm not yet used to building of deb packages. Can anybody
help me? :-)
(In former times I built RPM packages using an adapted spec file).

thanks!
Markus






Message: 2
Date: Tue, 29 Dec 2015 00:06:06 +0100
From: Jan Kandziora <[hidden email]>
Subject: Re: [Owfs-developers] Compiling OWFS for Ubuntu
To: "OWFS (One-wire file system) discussion and help"
<[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=windows-1252

Am 28.12.2015 um 23:19 schrieb Markus Gaugusch:
Hi,

I'm using Ubuntu 15.10 and the included owfs (2.9p8) is quite old. I'd
like to build a current version, but all information I could find for
building on Ubuntu is quite outdated (based on 12.04 and cvs).

Best option for me would be to build .deb packages. I switched to Ubuntu
recently and I'm not yet used to building of deb packages. Can anybody
help me? :-)
(In former times I built RPM packages using an adapted spec file).

quick&dirty solution:

For building "inofficial" packages, I most times use "checkinstall"
tool. Or you could build a new RPM with your existing spec file and then
convert it with the "alien" tool.

Kind regards

Jan






Message: 3
Date: Tue, 29 Dec 2015 10:34:37 +0100
From: Matthias Urlichs <[hidden email]>
Subject: Re: [Owfs-developers] Compiling OWFS for Ubuntu
To: [hidden email]
Message-ID: <n5tk3d$v7h$[hidden email]>
Content-Type: text/plain; charset=windows-1252

On 28.12.2015 23:19, Markus Gaugusch wrote:
Hi,

I'm using Ubuntu 15.10 and the included owfs (2.9p8) is quite old. I'd
like to build a current version, but all information I could find for
building on Ubuntu is quite outdated (based on 12.04 and cvs).

You could start with the "private" branch on
https://github.com/m-o-a-t/owfs
which I use for installing current OWFS on my Debian machines (i.e. all
of them). You might need to adjust a dependency or two, and I refuse to
build owperl and owphp because using owserver makes much more sense, but
otherwise it should just work.

------------------------------------------------------------------------------

_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

Jan Kandziora
Am 29.12.2015 um 16:39 schrieb Ursin Soler:

>
> By this year (initial release 7/15) Maxim released the DS28E17 [1]
> which is in my oppinion a game changer. This is (to my knowledge) the
> first time a 1-wire slave has been released that allows to connect
> any micro-proc (like Arduino/AVR) in a generic and easy way. Even
> though the DS2408 [2] (1-Wire 8-Channel Addressable Switch) enables
> this as well I would not consider it as easy or simple.
>
> The DS28E17 enables to implement any DIY slave imaginable for e.g.
> home automation like applications, segmentation and extension of
> networks, wireless connections/bridges, etc.
>
> Therefore I would like to proppose to add support for the DS28E17: 1)
> generic interface as for any other chip supported by OWFS 2) bridge
> mode that allows to use a DS28E17 <-> DS2482-100 [3] combination to
> extend a 1-wire network (may be support DS2482-800 too)
>
> I would like to open the discussion here and gather feedback, ideas
> and oppinions. Please contribute - thanks in advance!
>

I don't get what you mean by "generic interface as for any other chip
supported by OWFS". Do you mean we should provide a framework for
bitbanging arbitrary data through the I²C interface, tunneled through
onewire?

I don't think that's too useful, as there are no I²C drivers working
that way. One had to write their own I²C driver for that special
application and tunneling framework. Sure, it works, but it's incredibly
awful and a lot of unnecessary work, too. There are lots of existing I²C
slave drivers in the kernel and frameworks above it and anyone should
make use of them.

Putting that effort into OWFS by implementing support for some
well-known I²C chips behind the DS28E17 bridge makes it a bit less
awkward to the user but is the same idea all the way.

As the DS28E17 is just another I²C interface tunneled through onewire, I
think it would be best to represent it through /dev/i2c- nodes, which
has to be done by the kernel I²C/w1 subsystems. OWFS integration can
then be done through the "external" mechanism. That may look like taking
the Michigan Left but in my view, to create something universally useful
with the fewest work possible, our efforts should go into the kernel
drivers.


Kind regards

        Jan

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

Jan Kandziora
In reply to this post by Ursin Soler
Am 29.12.2015 um 16:39 schrieb Ursin Soler:
>
> By this year (initial release 7/15) Maxim released the DS28E17 [1]
> which is in my oppinion a game changer.
>
I like to add, the DS28E17 is only available in a very tiny 16TQFN-EP
package, which is very hard to solder by hand (0.5mm pitch, no leads) so
I doubt anyone of us hobbyists is going to use that chip unless someone
sells it on a pinned 2.54mm pitch adapter board.

For me, I'd rather use Pascal Berten's BAE0911, which has I²C bridging
functionality, and implement the neccesary logic with the chip's
automation engine. Or do the same with Matthias' MOAT, I could use an
arbitrary Atmel AVR chip then.

Kind regards

        Jan





------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

CReese
I can see no reason for not using moat, aside from differences in failure state, if any.

C

> On Dec 29, 2015, at 10:43 AM, Jan Kandziora <[hidden email]> wrote:
>
>> Am 29.12.2015 um 16:39 schrieb Ursin Soler:
>>
>> By this year (initial release 7/15) Maxim released the DS28E17 [1]
>> which is in my oppinion a game changer.
> I like to add, the DS28E17 is only available in a very tiny 16TQFN-EP
> package, which is very hard to solder by hand (0.5mm pitch, no leads) so
> I doubt anyone of us hobbyists is going to use that chip unless someone
> sells it on a pinned 2.54mm pitch adapter board.
>
> For me, I'd rather use Pascal Berten's BAE0911, which has I²C bridging
> functionality, and implement the neccesary logic with the chip's
> automation engine. Or do the same with Matthias' MOAT, I could use an
> arbitrary Atmel AVR chip then.
>
> Kind regards
>
>    Jan
>
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

Jan Kandziora
In reply to this post by Jan Kandziora
Am 29.12.2015 um 19:43 schrieb Jan Kandziora:

> Am 29.12.2015 um 16:39 schrieb Ursin Soler:
>>
>> By this year (initial release 7/15) Maxim released the DS28E17 [1]
>> which is in my oppinion a game changer.
>>
> I like to add, the DS28E17 is only available in a very tiny 16TQFN-EP
> package, which is very hard to solder by hand (0.5mm pitch, no leads) so
> I doubt anyone of us hobbyists is going to use that chip unless someone
> sells it on a pinned 2.54mm pitch adapter board.
>
> For me, I'd rather use Pascal Berten's BAE0911, which has I²C bridging
> functionality, and implement the neccesary logic with the chip's
> automation engine. Or do the same with Matthias' MOAT, I could use an
> arbitrary Atmel AVR chip then.
>
Matthias,

is it possible to create a Onewire->I²C bridge with your MOAT? If
possible as a drop-in replacement of the DS28E17, at least from onewire
view?

If you can prepare something like that, I would try to create a pair of
linux kernel drivers which make the remote I²C available through
/dev/i2c- devices nodes.

what do you think?

Kind regards

        Jan



------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

Matthias Urlichs-3
On 30.12.2015 06:02, Jan Kandziora wrote:
> is it possible to create a Onewire->I²C bridge with your MOAT? If
> possible as a drop-in replacement of the DS28E17, at least from onewire
> view?

I see no immediate technical problem with either mimicing the 'E17 or
adding a I²C bus channel to the MoaT protocol (or more than one;
bit-banging an I²C master is not exactly rocket science). An I²C master
can be written without interrupt handling, so there are no timing issues
to be considered.

MoaT (the on-AVR part) needs an I²C master implementation anyway, to
talk to environment sensors, port extenders, etc.

Personally I'd rather use the MoaT mode, for legal reasons --
Maxim probably doesn't like us to mimic in-production ICs.

Disclaimer: I haven't yet looked at the data sheet.

--
-- Matthias Urlichs


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

Jan Kandziora
Am 30.12.2015 um 06:37 schrieb Matthias Urlichs:

> On 30.12.2015 06:02, Jan Kandziora wrote:
>> is it possible to create a Onewire->I²C bridge with your MOAT? If
>> possible as a drop-in replacement of the DS28E17, at least from onewire
>> view?
>
> I see no immediate technical problem with either mimicing the 'E17 or
> adding a I²C bus channel to the MoaT protocol (or more than one;
> bit-banging an I²C master is not exactly rocket science). An I²C master
> can be written without interrupt handling, so there are no timing issues
> to be considered.
>
> MoaT (the on-AVR part) needs an I²C master implementation anyway, to
> talk to environment sensors, port extenders, etc.
>
Fine. That would justify it for me to create the driver pair.


> Personally I'd rather use the MoaT mode, for legal reasons --
> Maxim probably doesn't like us to mimic in-production ICs.
>
I don't think there is a problem, as the DS28E17 clearly targets a
professional audience, and the MOAT targets hobbyists. We are out of
their focus completely. If I had to justify my decisions as a developer
(a burden I struggled free from years ago) I'd stick to the Maxim
product *always*, because they give short and exact figures, while the
MOAT requires me to build up more extensive knowlegde about its
workings, which my successor won't have.


Maxim needs to have some Linux kernel driver anyway for the DS28E17,
given it will soon be built into battery packs and the like. So creating
that one for them should keep them clear from rocking the boat.


But okay, as soon the I²C tunneling framework is done, it should be easy
to support both the MOAT and the DS28E17.


Kind regards

        Jan



------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

Ursin Soler
In reply to this post by Ursin Soler
Hello

Thanks for your participation and hints.

> I don't get what you mean by "generic interface as for any other chip
> supported by OWFS". Do you mean we should provide a framework for
> bitbanging arbitrary data through the I?C interface, tunneled through
> onewire?

What I think of is an interface that allows to address I2C chips and
issue a read/write operation. This works byte-wise, not bit-wise. As
I see it, the DS28E17 is the solution not to have to bitbang the I2C
protocoll.
So this I think is similar to tunneling I2C through 1wire, correct.

I am actually more thinking about the vice-versa scheme; tunneling 1wire
through I2C (my proposal 2) which would allow to use an xbee to have 1wire
through the air (wireless) as well.

> awful and a lot of unnecessary work, too. There are lots of existing I?C
> slave drivers in the kernel and frameworks above it and anyone should
> make use of them.

> As the DS28E17 is just another I?C interface tunneled through onewire, I
> think it would be best to represent it through /dev/i2c- nodes, which
> has to be done by the kernel I?C/w1 subsystems. OWFS integration can
> then be done through the "external" mechanism. That may look like taking

Can you explain this to me please? How are I2C kernel driver related to OWFS?
Or better; how does the external mechanism work in this case?

>> By this year (initial release 7/15) Maxim released the DS28E17 [1]
>> which is in my oppinion a game changer.
>
> I like to add, the DS28E17 is only available in a very tiny 16TQFN-EP
> package, which is very hard to solder by hand (0.5mm pitch, no leads) so
> I doubt anyone of us hobbyists is going to use that chip unless someone
> sells it on a pinned 2.54mm pitch adapter board.

This is true but not a show stopper, you can use a small oven may be even a heat
gun (with some experience) to solder it to a break-out board. But yes; it needs some
equipment and/or experience.

> For me, I'd rather use Pascal Berten's BAE0911, which has I?C bridging
> functionality, and implement the neccesary logic with the chip's
> automation engine. Or do the same with Matthias' MOAT, I could use an
> arbitrary Atmel AVR chip then.

This is very interesting to me as I know of this chip/board but I was not able to
find a single distributor! Where do you buy/order them? http://www.brain4home.eu/
is down since months... :(

> I can see no reason for not using moat, aside from differences in failure state, if any.

I do agree here as well, but I have to ask for a simple MOAT example, beginners guide,
how to tutorial that explains how to get started with MOAT (set it up from bare metal).
I did not had the time to look into MOAT yet - can you tell me how complex the code is?
Is it simple to add stuff or modify parts?

>>> is it possible to create a Onewire->I?C bridge with your MOAT? If
>>> possible as a drop-in replacement of the DS28E17, at least from onewire
>>> view?
>>
>> I see no immediate technical problem with either mimicing the 'E17 or
>> adding a I?C bus channel to the MoaT protocol (or more than one;
>> bit-banging an I?C master is not exactly rocket science). An I?C master
>> can be written without interrupt handling, so there are no timing issues
>> to be considered.
>>
>> MoaT (the on-AVR part) needs an I?C master implementation anyway, to
>> talk to environment sensors, port extenders, etc.
>>
> Fine. That would justify it for me to create the driver pair.

That are good news! Looking forward to see this implemented. Great!

>> Personally I'd rather use the MoaT mode, for legal reasons --
>> Maxim probably doesn't like us to mimic in-production ICs.
>>
> I don't think there is a problem, as the DS28E17 clearly targets a
> professional audience, and the MOAT targets hobbyists. We are out of
> their focus completely. If I had to justify my decisions as a developer
> (a burden I struggled free from years ago) I'd stick to the Maxim
> product *always*, because they give short and exact figures, while the
> MOAT requires me to build up more extensive knowlegde about its
> workings, which my successor won't have.

I agree with the answer. Although I don't get the initial argument; having
a MOAT 1-wire slave with I2C master IS mimicking an in-production IC.
Why do you think it is not? (just curious about your argument, not the
legal stuff ;)

> Maxim needs to have some Linux kernel driver anyway for the DS28E17,
> given it will soon be built into battery packs and the like. So creating
> that one for them should keep them clear from rocking the boat.

I have not too much experience with Maxim, except for requesting the
DS1WM FPGA IP core which was painless. Are they that fair? (they don't
intervene as long as they get kernel drivers for free? would be cool.)
I read a lot in the past about fears to mimic chips, but never ever anything
about a complaint of someone having real issues with that. Is that correct?

> But okay, as soon the I?C tunneling framework is done, it should be easy
> to support both the MOAT and the DS28E17.

What about my second proposal to have a DS28E17 <-> DS2482-100 mode
that just expands the MicroLAN, e.g. the devices are listed as on the main
bus [A]. I think of something like:

1wire [A] ---> DS28E17 <---i2c---> DS2482-100 ---> 1wire [B]

of course both chips can be replaced as e.g.

1wire [A] ---> MOAT <---i2c---> MicroProc (e.g. AVR/Arduino) ---> 1wire [B]

That would be more like tunneling 1wire through I2C. The main or default bus
is [A] and OWFS should access, handle and list all devices on [B] as if they
would be connected to [A] directly. The I2C part could then be enhanced by
a xbee/wireless e.g.
What do you think about that?

Thanks a lot for the discussion and greetings!
Ursin Solèr
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

Jan Kandziora
Am 02.01.2016 um 01:08 schrieb Solèr  Ursin:
Am 01.01.2016 um 14:25 schrieb Solèr Ursin:

> Hello
>
> Thanks for your participation and hints.
>
>> I don't get what you mean by "generic interface as for any other
>> chip supported by OWFS". Do you mean we should provide a framework
>> for bitbanging arbitrary data through the I?C interface, tunneled
>> through onewire?
>
> What I think of is an interface that allows to address I2C chips and
> issue a read/write operation. This works byte-wise, not bit-wise. As
> I see it, the DS28E17 is the solution not to have to bitbang the I2C
> protocoll. So this I think is similar to tunneling I2C through 1wire,
> correct.
>
I meant owfs should just pass-through preformatted data, not give it
any meaning. It's like bitbanging on the owfs level. Take bytes, pass
on.

I don't think this is too useful because one had to rewrite every
single needed I²C slave driver out there for this crude interface and
of course the tools, too. These drivers and tools do exist. Why
reinvent the wheel?


> I am actually more thinking about the vice-versa scheme; tunneling
> 1wire through I2C (my proposal 2)
>
If we do it in the kernel driver, we get 2) as a free gift, because as
soon as the kernel can show the DS28E17 I²C port as /dev/i2c-..., one can
connect a DS2482-800 to it and run another owserver on top of that
I²C interface. You get any existing I²C kernel driver as a free gift.
That's why I strongly recommend to write a w1 kernel driver for the
DS28E17 and a second generic kernel driver for the I²C on w1 tunnel.


>
> Can you explain this to me please? How are I2C kernel driver related
> to OWFS? Or better; how does the external mechanism work in this
> case?
>
Implementing a kernel driver for the DS28E17 would mean that chip does
appear in the owfs device listing but it has no special properties.
We could provide a link to the /dec/i2c-... device node for proper
addressing. Access to the connected I²C chips is solely done by the
kernel. It would be the same as for any other I²C device you can connect
to your e.g. Raspi hardware. They are I²C, not onewire, so they arent
available to owfs automatically.

But OWFS has a mechanism built into it which makes owserver (or a language
binding) include such local sensors into the owfs device tree. They just
appear as ordinary onewire devices, with admin-chosen names. On my Raspi
I/O extender modules, I have an owfs.conf reading similar to this:

external
SENSOR: "gpio@term2", "GPIO", "GPIO", "GPIO",
SCRIPT: "indicator", "GPIO", y, 1, v, /usr/bin/owgpio, /usr/bin/owgpio,
"gpio4", "unused",
SCRIPT: "switch0", "GPIO", y, 1, v, /usr/bin/owgpio, /usr/bin/owgpio,
"gpio17", "unused",
SCRIPT: "switch1", "GPIO", y, 1, v, /usr/bin/owgpio, /usr/bin/owgpio,
"gpio18", "unused",

with /usr/bin/owgpio reading like this

#!/bin/sh
RW=$4
GPIO=$8

case "$RW" in
read) cat /sys/class/gpio/$GPIO/value ;;
write) cat >/sys/class/gpio/$GPIO/value ;;
esac

With this owfs.conf, the owserver on that Raspi has access to three GPIO
outputs, which connect to some hardware on my homebrewn piggyback interface
board. The properties of I²C chips connected to the DS28E17 can be put into
the OWFS tree the same way as GPIOs. A single line in owfs.conf, a simple
shell script, done. It's all abstracted on kernel level.


>>
>> I like to add, the DS28E17 is only available in a very tiny
>> 16TQFN-EP package, which is very hard to solder by hand (0.5mm
>> pitch, no leads) so I doubt anyone of us hobbyists is going to use
>> that chip unless someone sells it on a pinned 2.54mm pitch adapter
>> board.
>
> This is true but not a show stopper, you can use a small oven may be
> even a heat gun (with some experience) to solder it to a break-out
> board. But yes; it needs some equipment and/or experience.
>
As I know how much problems the *professional* PCB assembly companies
I use for my pre-production boards have with these sand grains, I
seriously doubt that. Please try with good old leaded solder paste only.

But even if you get it done right, I still doubt anyone else here (me
included) gets it working.


>> For me, I'd rather use Pascal Berten's BAE0911, which has I?C
>> bridging functionality, and implement the neccesary logic with the
>> chip's automation engine. Or do the same with Matthias' MOAT, I
>> could use an arbitrary Atmel AVR chip then.
>
> This is very interesting to me as I know of this chip/board but I was
> not able to find a single distributor! Where do you buy/order them?
> http://www.brain4home.eu/ is down since months... :(
>
It's a homebrewn chip. You can ask Pascal by email. [hidden email].


>> I can see no reason for not using moat, aside from differences in
>> failure state, if any.
>
> I do agree here as well, but I have to ask for a simple MOAT example,
> beginners guide, how to tutorial that explains how to get started
> with MOAT (set it up from bare metal). I did not had the time to look
> into MOAT yet - can you tell me how complex the code is? Is it simple
> to add stuff or modify parts?
>
Yes, documentation is really something Matthias needs to improve. Badly.


>>> to talk to environment sensors, port extenders, etc.
>>>
>> Fine. That would justify it for me to create the driver pair.
>
> That are good news! Looking forward to see this implemented. Great!
>
Have to read and try a lot there. If you manage to put the DS28E17
on a breakout board and send it to me, I could spare the cost for the
evaluation kit. Where are you located?


>
>> Maxim needs to have some Linux kernel driver anyway for the
>> DS28E17, given it will soon be built into battery packs and the
>> like. So creating that one for them should keep them clear from
>> rocking the boat.
>
> I have not too much experience with Maxim, except for requesting the
> DS1WM FPGA IP core which was painless. Are they that fair? (they
> don't intervene as long as they get kernel drivers for free? would be
> cool.) I read a lot in the past about fears to mimic chips, but never
> ever anything about a complaint of someone having real issues with
> that. Is that correct?
>
I think my above statement works for any company. It doesn't require
fairness, it only requires a minimum of common sense. Hounding hobbyists
with a bunch of lawyers doesn't help to generate revenue, it however
does help to generate bad press. That's a logic even corporate lawyers
can understand.

Now the patent has expired, you don't require a license to build slave
chips. They had to present evidence you stole their intellectual
property. Hardly possible if they documented the interface you mimiced
in some publicly available data sheet.

The most horrifing thing that would happen in real life is they send
Matthias and/or me a letter we should stop it. And that's when I, in all
kindness, would ask "Are you serious? But you do understand you got the
Linux driver for your chip for free just because we did this."


>> But okay, as soon the I?C tunneling framework is done, it should be
>> easy to support both the MOAT and the DS28E17.
>
> What about my second proposal to have a DS28E17 <-> DS2482-100 mode
> that just expands the MicroLAN, e.g. the devices are listed as on the
> main bus [A]. I think of something like:
>
> 1wire [A] ---> DS28E17 <---i2c---> DS2482-100 ---> 1wire [B]
>
> of course both chips can be replaced as e.g.
>
> 1wire [A] ---> MOAT <---i2c---> MicroProc (e.g. AVR/Arduino) --->
> 1wire [B]
>
> That would be more like tunneling 1wire through I2C. The main or
> default bus is [A] and OWFS should access, handle and list all
> devices on [B] as if they would be connected to [A] directly. The I2C
> part could then be enhanced by a xbee/wireless e.g. What do you think
> about that?
>
As written above, you get that as a free gift as soon the kernel driver
creates an /dev/i2c-... device for the DS28E17 I²C interface.


Kind regards

        Jan

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

Ursin Soler
In reply to this post by Ursin Soler
>> I do agree here as well, but I have to ask for a simple MOAT example, beginners guide,
>> how to tutorial that explains how to get started with MOAT (set it up from bare metal).
>> I did not had the time to look into MOAT yet - can you tell me how complex the code is?
>> Is it simple to add stuff or modify parts?
>
> Writing more documentation is on my radar.

Cool!

> needs to be updated (as long as you have three of them). Also, I want a
> system that makes adding code written in whatever language you want as
> simple as possible. Thus, everything will go through the messaging bus

I guess this "adding code written in whatever language" does not affect the slaves, right?
I guess an e.g. AVR type of 1wire slave will be some C/C++ derivate or ASM, correct?
Naively asking: It won't be possible to add python code to a 1wire slave, right?

Greetings
Ursin Solèr
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

Matthias Urlichs-3
On 04.01.2016 09:36, Solèr  Ursin wrote:
> I guess this "adding code written in whatever language" does not affect the slaves, right?

Nope. This is about code that interfaces with OWserver (or KNX or …).

> I guess an e.g. AVR type of 1wire slave will be some C/C++ derivate or ASM, correct?

Right.

> Naively asking: It won't be possible to add python code to a 1wire slave, right?

Definitely not.

--
-- Matthias Urlichs


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

Jan Kandziora
In reply to this post by Ursin Soler
Am 29.12.2015 um 16:39 schrieb Ursin Soler:
>
> By this year (initial release 7/15) Maxim released the DS28E17 [1]
> which is in my oppinion a game changer. This is (to my knowledge) the
> first time a 1-wire slave has been released that allows to connect
> any micro-proc (like Arduino/AVR) in a generic and easy way. Even
> though the DS2408 [2] (1-Wire 8-Channel Addressable Switch) enables
> this as well I would not consider it as easy or simple.
>
I'm happy to announce I recently had a a free week to write a kernel
driver for this chip, doing exactly what I had proposed.

        https://github.com/ianka/w1_ds28e17

Please see the README file for further information. Feel free to ask
anything about it.

Kind regards

        Jan


------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

Rainer Dorsch
Hi Jan,

On Sunday 10 July 2016 03:21:13 Jan Kandziora wrote:

> Am 29.12.2015 um 16:39 schrieb Ursin Soler:
> >
> > By this year (initial release 7/15) Maxim released the DS28E17 [1]
> > which is in my oppinion a game changer. This is (to my knowledge) the
> > first time a 1-wire slave has been released that allows to connect
> > any micro-proc (like Arduino/AVR) in a generic and easy way. Even
> > though the DS2408 [2] (1-Wire 8-Channel Addressable Switch) enables
> > this as well I would not consider it as easy or simple.
> >
> I'm happy to announce I recently had a a free week to write a kernel
> driver for this chip, doing exactly what I had proposed.
>
> https://github.com/ianka/w1_ds28e17
>
> Please see the README file for further information. Feel free to ask
> anything about it.

That is wonderful work, many thanks for that.

Do you have any plans to upstream it? I think if you do, many more people benefit from it...

Thanks
Rainer

--
Rainer Dorsch
http://bokomoko.de/

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

Jan Kandziora
Am 07.10.2016 um 23:05 schrieb Rainer Dorsch:
>
> Do you have any plans to upstream it? I think if you do, many more people benefit from it...
>
http://patchwork.ozlabs.org/patch/678037/
http://patchwork.ozlabs.org/patch/678038/

Kind regards

        Jan

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

Rainer Dorsch

Hi Jan,

 

the state of the patches is still new, does that mean they are far away from being integrated in mainline? If yes, do you have any experience or estimate how long it takes to see your nice patches in mainline?

 

Many thanks for the patches

Rainer

 

On Saturday 08 October 2016 00:03:54 Jan Kandziora wrote:

> Am 07.10.2016 um 23:05 schrieb Rainer Dorsch:

> >

> > Do you have any plans to upstream it? I think if you do, many more people benefit from it...

> >

> http://patchwork.ozlabs.org/patch/678037/

> http://patchwork.ozlabs.org/patch/678038/

>

> Kind regards

>

> Jan

>

> ------------------------------------------------------------------------------

> 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

> [hidden email]

> https://lists.sourceforge.net/lists/listinfo/owfs-developers

 

--

Rainer Dorsch

Lärchenstr. 6

72135 Dettenhausen

07157/734133

 

 


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

Jan Kandziora
Am 04.12.2016 um 10:19 schrieb Rainer Dorsch:
> Hi Jan,
>
> the state of the patches is still new, does that mean they are far
> away from being integrated in mainline? If yes, do you have any
> experience or estimate how long it takes to see your nice patches in
> mainline?
>
You have to ask Wolfram Sang on the linux-i2c mailing list to get an
answer on that. Last time I asked for comments he gave me some but then
said it's a lot of other patches to apply.

Kind regards

        Jan

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers