Jerry & others: I was thinking that a personality could be loaded into the chip via owfs (just as a memory write, basically). While I haven't worked on this enough to know the size, I also envision this being an infrequent task (when you first set up a new device, or when you do a major re-purpose of the device, connecting it to different hardware, etc). Of course, for larger or more complicated processors, this could always be done offline (typical microprocessor load such as USB/JTAG, etc). I wasn't saying that all these devices need to be done via 1-wire, or even that it is a requirement; I was just thinking of an easy way for people to change the personality of the chip without having to invest in a microprocessor programming environment. This isn't strictly required, but it appeared to be fairly doable, and thus I proposed it :) In a production environment, one might want to have a second OW network for testing and programming the chip.
--Jim On Fri, Feb 26, 2010 at 8:51 AM, Jerry Scharf <sch...@lagunawayconsulting.com> wrote: > Jim, > > You are closer to my view of control systems. I generally want > susbsystems to be able to act autonomously with the brains doing the > more complex work. So it's more like a hierarchy than a pure mesh. I > also think about redundancy. Just because 1wire is low cost doesn't mean > it can't be used in more demanding control systems. > > I have lots of sensors, but use multiple masters to help with the > isolation and bandwidth problems. > > One of the big down sides for this approach is the debugging environment > on the uC side is far poorer and harder to do. I think this is where > people get to wanting to buy something that someone else has worked out. > > One question I have is about the bootstrapping. It seems like this is > outside the scope of OWFS. I love the design you propose, but I am > wondering if it lives next to OWFS rather than within it. Are you saying > that we would use OWFS to do the bootstrapping at the user level? It > seems like that could really saturate the bus for a more complex device. > > jerry > > Jim Kusznir wrote: >> 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. >> >> We found that often, we ran into OW bus saturation issues. Something >> as simple as alarming on the 2450 not working almost took down our >> bus, as we had to poll it. Now, not only are we wasting a lot of bus >> bandwidth (which was delaying other devices and messing with our >> project in a negative sense), but we were also not getting our analog >> data as timely and precisely as we wanted. >> >> We're also looking at other activities, such as a OW-based >> thermostat/heating control system. For this, we definitely want a >> local thermostat, as if the OW system goes down, so does heat...Out >> here, that can mean frozen / broken pipes. Combine that with people >> living in the space who are not familiar with the innards of the >> technology (i.e., not able to restart/diagnose the OW system), and >> you've got a fixed requirement for local backup control. >> >> We're also looking at some new motion sensors (our primary OW device >> is a motion sensor equipped with an DS2406), that would need a fair >> bit more processing and would be producing a much "richer" data >> format. For us, its important that 1) the device identify that it is >> a "rev xx motion sensor" and provide the richer data in such a way as >> to not saturate our bus. This requires local pre-processing and >> decisions on when to "raise the alarm". >> >> 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. >> >> So, for us it would be wonderful to have a microprocessor which we >> could configure to do any preprocessing we want it to, put in some id >> string that the OW master can read, and support "custom data types", >> ideally including the scaling and precision type settings in the chip. >> >> 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. >> >> That said, I think there's still a commercial market for devices >> pre-programmed. While we're perfectly happy with buying stock >> microcontrollers and flashing them with custom code, many people won't >> be. While we can write our own functions and such, some people would >> want to select from "x channel A2D" or "pwm controller", etc. Some >> people may even want to pay someone to program custom modules for >> their application. However, if we end up with another closed-source >> solution where groups like us can't get the source and modify it for >> our custom applications, I think its doing a disservice to the OW >> community. By opening up the source, I think we'll quickly see a wide >> variety of new applications and functionalities that were not >> previously thought of, or exceed the resources of an individual to >> develop and commercialize. >> >> So, to answer tmk's thoughts on "why not just do it in a PC", that's >> an appropriate answer for some applications, but not all. And even if >> you're doing it in the PC, you're probably going to need devices for >> input or control that Dallas doesn't make. Rather than try and make >> the "one microprocessor that does it all", I think everyone will >> benefit from being able to configure the microprocessor with certain >> "personalities" to do what you need it to. In essence, its the linux >> vs windows way: make a heavyweight system that tries to be a jack of >> all trades (but masters none), or be able to make small, >> single-purpose devices that do exactly what is needed and nothing >> more. My experiences to date, especially with OWFS has found great >> power in the latter. Even if specific program logic or decisions are >> not loaded onto the devices, having a device that does only what it >> needs to will still improve reliability and such overall. >> >> --Jim >> >> On Fri, Feb 26, 2010 at 12:47 AM, <nufan_...@comcast.net> wrote: >>>> From a users perspective I want more flexible slave devices which are >>>> capable of making decisions themselves. >>>> With the host (OWFS) providing a means of configuration and >>>> supervision only. At this stage I do not care about what >>>> hardware platform the slaves takes on however I am >>>> more interested in the control functionality that new slaves can offer >>>> then look at what can facilitate the functions requirements. >>> I think there is a lot of power in having little systems that do their >>> thing without much intervention. There is a fine line between a device that >>> can make simple decisions and a mesh of controllers. >>> >>> In my projects so far, i've wavered between a central server that has some >>> daemon making all the decisions, vs a uC which is basically autonomous, and >>> is itself is a 1w master able to make all sorts of decisions. >>> >>> I am currently leaning towards the former, but the reliability and >>> forgetability you propose may pull me back just a bit. >>> >>> Most of the below comments are my internal pro/con reasoning for my stance, >>> and not meant to be a dismissal of your proposals. >>> >>>> Making a “User” go into the uC and program there own code >>>> satisfies a small portion of the users of 1wire. I would suggest >>>> creating “functions” could be more viable to the mass’s. >>> If one was going to package and sell such a device (i'm not interested >>> really), there are direct USB bootloaders for the AVR stuff which makes >>> flashing code as easy as a usb connection. (serial also) >>> >>> I believe Pascal even has reflashing via 1-wire working! >>> >>> So uploading a 'personality' is not a big deal, and for an extra $0.50 i'm >>> sure anyone making these devices could pre-program it. If one wanted to >>> package all the personalities in, then it would cost a small amount (extra >>> $1-2?) for a device with more storage/eeprom space. >>> >>>> Timed Output Slave: >>>> >>>> Function : Control up to 4 outputs based upon a set of preset >>>> time-of-day triggers. Enable up to 4 push buttons to manually control >>>> each output. >>> I was thinking of just such a device. I am sick of shelling out for >>> sprinkler controller systems! I have 3 separate ones and none really offer >>> me the programmability i want. Same for my home thermostat. Needs to be a >>> button by the door that says 'i'll be out for 2 hours'.. None of this going >>> to the hallway business! :) >>> >>> Unfortunately, most uC's that i have dealt with don't have RTC, and they >>> are relatively expensive. I am also way too lazy to cobble one on, when i >>> have a perfectly good computer (with a working clock) already attached via >>> 1-wire. >>> >>>> Configuration: Let the user assign up to 32 trigger points each >>>> trigger having a PIO mask to either turn ON or OFF the outputs. >>> No need for a limit with computer control, really, and you could do much >>> more complex decision making. >>> >>>> Slave hardware requirements : A uC with 4 DIO ADC for buttons and a >>>> I2C interface to a battery backed RTC module. >>> Manual control buttons need not be logic based (analog!), but certainly >>> could do. >>> >>> Already up to 2 busses: i2c+1-wire.. >>> >>> >>>> Analog Input Slave: >>>> >>>> Function: Provide ~4 ADC inputs with a resolution better than 8 bits! >>>> The device will provide scaling and signal conditioning and conversion >>>> to engineering units directly within the device. >>> I am not to familliar with a lot of the lower-level details of ADC, but i >>> believe a scaler almost always has to be an external hardware component >>> (therefore out of scope?), or the uC has to have a flexible reference >>> voltage larger than the range of the input. (in other words, scaling to < >>> Vcc has some hardware support, but detecting higher voltages maybe not?) >>> >>> If it's externally scaled, then (as you suggest) just a multiplier could be >>> applied >>> >>> AVRs seem to have 10bit adc, is 12 common? Just curious >>> >>>> Configuration: Let the user assign both scaling etc coupled with 4 >>>> alarm level per ADC. A number of available PIO pins can be assigned >>>> to set an output based upon alarm levels. >>> Why stop there? any feature of the uC should be triggerable based on an >>> alarm, eg change pwm freq, tick counter, calculate time spent in state.. >>> easier to add the logic via computer. >>> >>>> Would also be great to >>>> download a 20 point x,y characterization curve that could be applied >>>> to the measured variable. Used for measuring level or volume in a >>>> sphere or as in my case a tank which has not got parallel sides. >>> Transformation is dead simple on full-strength hardware, and can use full >>> equations if desired. >>> >>>> Analog Controller Slave: >>>> >>>> Function: Provide a controller that has the ability to compare a >>>> scaled reading to a user defined setpoint and perform an output action >>>> via PIO . >>> This is straight where i am headed, and may be the most useful bit.. >>> temperature controller for heating/cooling. However i may end up doing some >>> zoning type stuff and have sensors/control in every room. I think that >>> might be a bit much to calculate on a single uC, and having dedicated ones >>> might cause the systems to oscillate. >>> >>> Also, there are full-featured controller programs (diy-zoning, mango, etc) >>> that already do this sort of stuff. >>> >>>> PID Control , Where a DAC output is set according to the error between >>>> Measured variable and setpoint with an output value modulated via a >>>> PID algorithm >>> Another great use for a uC. I think this should be implemented. DAC not >>> necessarily the only output, but certainly a primary one. 'killer app' for >>> smart sensors. >>> >>>> process. The Analog_slave I described above does fit my analog >>>> faceplates created on my web site. I also have defined control >>>> faceplates as well. www.rjconway.homeip.net Thus we could create a >>>> matching GUI for each function. >>> Some nice stuff there, very cleanly done. congrats >>> >>> -tmk >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> >> >> ------------------------------------------------------------------------------ >> 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 > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
