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. pascal.baer...@pbae.be. >> 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 Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
