>Message: 2
>Date: Sat, 2 Jan 2016 01:58:17 +0100
>From: Jan Kandziora <j...@gmx.de>
>Subject: Re: [Owfs-developers] Introduce support for DS28E17
> (1-Wire-to-I2C Master Bridge)
>To: "OWFS (One-wire file system) discussion and help"
> <owfs-developers@lists.sourceforge.net>
>Message-ID: <568720a9.2050...@gmx.de>
>Content-Type: text/plain; charset=windows-1252
>
>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 totally agree, as long as you want to teach me or point me to a good tutorial
on how to use this weel... ;)
>> 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.
Ok, that sounds very nice and useful.
>>
>> 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 think I got th idea - very nice again - but I would need more
docu/tutorial/background about this. I never used I2C chips this way (used them
the "arduino" way) - sounds extremely useful! :)
>>>
>>> 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.
Ball-grid arrays are quite common today so I have to ask what you consider a
*professional* company? ;) What was the issue? Did the use a reflow oven? What
about vapour phase soldering? Given that Maxim released this package only I
would guess they are quite confident about this. BUT I agree it is not optimal.
(ps: solder = leaded solder ... what else?! ;))
>But even if you get it done right, I still doubt anyone else here (me
>included) gets it working.
Agreed - this is a nasty task.
>>> 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.
>pascal.baer...@pbae.be.
Thanks for the hint!
>>> 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?
Switzerland. Actually here everything is expensive, but I would be willing to
spend the money (about 50€) if you give me your address.
>>> 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."
This is intressting... Do you know of anybody that happened to?
I know the story of dvddecrypter only - but I guess this is not comparable
since its software...
>>> 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.
Honestly I think that would be REALLY cool! Wireless 1wire for short distances
only would allow to cross glass windows and go outside (weather station, etc.)
without any issue... ;)
Greetings and all the best
Ursin Soler
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
