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 dscussion and greetings! Ursin Solèr ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
