Jim, Is this going into EEPROM? I was thinking you were saying this happened each time the slave came up.
jerry Jim Kusznir wrote: > 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 ------------------------------------------------------------------------------ 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
