On Fri, Feb 26, 2010 at 9:13 AM, Pascal Baerten <pascal.baer...@gmail.com> wrote: > my thoughts within the text... > > > 2010/2/26 Jim Kusznir <jkusz...@gmail.com> >> >> A PC is definitely more powerful, and its programming paradigms are >> easier to address, true. However, we've played those games in our OW >> setup, and have been going back to the "do-it-on-hardware" side. For >> us, we have a large network of OW devices (often 50+), a PC software >> suite written by a couple different people that needs to collect all >> the data, and we're looking at control. Of course, timeliness is also >> an issue. >> > I consider that 1wire slaves should have autonomous capabilities where > master play the role of orchestrator giving consigns to slaves and getting > reports from them.
Our approach is slightly different. We want the devices to tell the master what they are, eliminating any site-specific custom configuration for the OWFS master software. For example, I do NOT want to have to type in a list of OW serial numbers and that this device is handled this way, etc. Instead, I want the OW device to tell the OW master what type of device it is (specifically), so then the OW master knows how to handle it (the standard way all devices of type/configuration X are). I realize some people have smaller networks and/or don't care, but there are larger networks, especially when more people are involved, where it makes more sense to make the devices able to identify themselves a bit better. >> In addition, auto-identifying systems is important for us. We have >> several of these large-ish deployments, and often have limited time to >> set them up. We take great lengths to try and make the system as >> automated as possible, especially in the setup phase. To this end, we >> use the EEPROM in the 2406's to burn in a device type ID to further >> distinguish between the various devices we have that use 2406's. If >> we go to a microprocessor model to replace or provide input types not >> available in dallas chips, it would also be critical that the chip >> identify its function to the system. That was a major headache we >> have with the 2450 presently...We don't know how to treat its values >> (we see we have 4 analog readouts now, but what are they? Some we >> only have A hooked up, we don't even care about B, C, or D...Others >> have ranges on the various pins that mean different things and in some >> cases we have to change how we read certain pins for precision, etc). >> To us, hard-coding this at the PC is an absolute mess of a hack that >> we wish to avoid. > > I proposed to Paul during development of BAE0910 to have the chip itself > publishing field mapping to dynamically present fixed/configured features to > owfs. But currently owfs don't support dynamic properties. I'm not exactly sure on what 'dynamic properties' entails in this case. To be clear, I am NOT proposing the devices' properties change while it is online. I envision a situation where when the device discovery is run, it finds a serial number with family code, say, 99. OWFS knows that means its run with chip driver "uC", and that driver knows to go read memory address xxxxx, parse the output, and then pass on to OWFS the list of fields that are valid. As long as that device serial number remains on the network, that's all it exposes. If one wants to reconfigure it, the device goes offline, then gets re-discovered and re-enumerated. In my vision of this, the devices do NOT change personality very often. In fact, I envision many devices never changing personality...but they can. The more important aspect to me is that I can load custom personalities on the device, and I can keep one device on hand, and use that for many different applications, including designing new hardware devices and prototyping. It may also note that I don't intend on OWFS to support doing conversions in the software (aka map this 0-5VDC number into a temperature using this formula)...To me, that's part of a chip's personality and job. However, the chip can tell the OWFS driver that 'memory address xxxxx should be exposed as "Temperature1" and is read-only; memory address yyyy is "heat_setpoint" and is read/write.' >> >> To this end, it seems to me that a wonderful solution would be a >> microprocessor with a "base" code (USB flashed, etc) that would have >> its OW ID and a basic "bootloader" code in it. I could then select a >> code function (either supplied by others or written by myself), and >> "cat" it to the right OWFS "file" to program that personality. I've >> spoken to some local ATMEL experts, and they say that's very doable >> with the atmel line of chips. >> >> I would also like to suggest that the code is available open source. >> I've already encountered a few other commercial projects similar to >> the BAE which have about 70% of what we need for a project or >> experiment. But, as the source is closed, our only option is to use >> it as is, or pay them to develop what we want. We already have the >> programmers on staff who are more connected with the problem and have >> the proper environment to test, so it doesn't make sense to pay for >> their development services. Much of what we do will be highly custom, >> so source access is very important to us. > > BAE chip are already able to receive AE script to embed your specific logic. The problem with this is: 1) the chip is not the right chip for me (as far as I/O is concerned). If I had the code, I could adapt it to a more appropriate microprocessor for my needs 2) the code is too rigid for my needs and misses other things I need (such as a "RAM" field or similar to simply put in a free-form ID that my software will use to identify what role this device is serving". 3) the "swiss army knife" design of the BAE chip violates several aspects of the project's core goals (simplify, simplify, simplify), and would be difficult/confusing to implement in our code (do we access this chip via the pwm, or do we do a2d on it? I don't know, the chip supports it both, and via OWFS, simultaneously...). If we were to use the BAE, we'd have to decide what function it would serve, and never use it for anything else. That's why I'm stressing the configurability of the chips...We can only put in support for the function we need, and the other functions the microprocessor might be capable of wouldn't even show up in OWFS nor would there be any device code to use them on that device. --Jim ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
