Yes, I was intending on this being stored in eeprom on the slave device. I believe in most cases, the slave device will be soldered on a board with its support electronics for whatever task it is doing. As such, its task is not going to change.
I am NOT (currently) proposing that information such as where the sensor is located or what its monitoring the temperature of, for example, are stored...Just information as to what it is (its a temperature and light detector, for example) and how to get data from it. So, in my use case below, a hobbyist who doesn't have the microprocessor development kit / JTAG cable / etc, could take a chip that has been flashed with the "base", build his device, and plug it into a onewire bus. At that point it will show up, but only have one or so functions in OWFS: a "file" for firmware load that they can then cp the personality file to. That will transfer the personality to the chip. Once complete, the user then unplugs the OW device, then plugs it back in. When OWFS discovers the device, it will have more info in its "configuration" space that will tell OWFS 1) what address locations to read on the slave; 2) what type of value its reading (how long it is); and 3) what text description to call it in its directory tree. As such, this would allow OWFS to NOT need any special configuration for individual slaves. It would allow a completely flexible slave, even for hobbyists who don't know/want to get into the full microprocessor development. It would even allow such people to write/modify their own personalities (compiling with GCC, hopefully, or some other SDK freely downloadable) and upload them, or choose from a set of "standard" or "example" personalities provided by the open source project that's designing / producing the code for the chip. Of course, people wishing to commercialize this can sell chips pre-programmed with the base (or those who have sufficient microprocessor facilities can buy their own devices from the manufacturer and flash the base on them with JTAG/etc themselves). These individuals can even make their own personalities that are commercial/copyrighted and people can buy those from the individual/company. I'm sure individuals would also want to contract with an expert to write personalities for them, too. I do think its critically important that the core of the project be open source. Right now, the fact that the only slave devices available are commercial / closed source are a major damper on the hobbyist's and researcher/experimenter's ability to grow and use OW / OWFS for even cooler things. I know that I need custom work, and I'm not going to pay someone else to develop a custom chip that I'd then have to buy individually from them and not own the source code. I already have a staff of programmers here, and due to university policies and procedures, its very difficult if not impossible to pay for such services. --Jim On Sat, Feb 27, 2010 at 11:40 AM, Jerry Scharf <sch...@lagunawayconsulting.com> wrote: > 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 > ------------------------------------------------------------------------------ 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
