Hi Mark, On 11/05/2011 09:25 AM, Mark Richards wrote:
> Hello Eloy, > > A few thoughts. > > OWFS already provides data in a single-file-format, such as branch.ALL, > volt.ALL... > > These .ALL registers appear to be grouped by a logical and common > purpose. If future device support were to be fashioned against what may > be considered an existing "standard", grouping dissimilar data in a > single register would be a departure. Agreed. >This would mean that an exception > exists within an otherwise consistent interface. I would caution that > one exception quickly leads to another and typically does not end well. Agreed. > One of the beauties of OWFS is that a structure information is provided > to give us the layout for each One Wire device and their data format. If > a single file contains several disparate elements, how will this be > reflected in the structure? By using a file name that gives an idea of what one would get by accessing that file? For example, "environment" or "environmental_data"? > I have, many times, chased after problems that did not exist. These > learning experiences are valuable, but some can be expensive. So > considering the problem can we assume that it is believed a performance > issue exists (reading three files rather than one)? It would be helpful > to know if the difference will be meaningful enough to justify the efforts. In my particular case I was mostly thinking along the lines of "easier to implement on the microcontroller and in less space". Performance-wise I am sure there is a tiny advantage of doing an N-byte data transfer than N 1-byte transfers, especially since each 1-byte transfer requires sending to the device different function commands. As you say, however, I am not sure it is worth the departure from what seems to be the "standard" so far. Thanks for the insightful thoughts. Cheers, Eloy Paris.- > On 11/5/2011 07:41, Eloy Paris wrote: >> Hello developers, >> >> I am working on a 1-Wire device that provides multi-sensor data, i.e. >> temperature, humidity, luminosity. I'd like to be able to have an OWFS >> file that allows me to do this: >> >> $ cat /owfs2/uncached/99.010203040506/environs; echo >> temp=25.2 RH=48% light=252 >> >> This would allow for easy parsing of environmental data without having >> to access different files, i.e. one file for temperature, another for >> humidity, etc. >> >> I am not sure about how to best set up the struct filetype entry to >> accomplish this. In particular, what should I use for the suglen and >> format fields? >> >> In looking at the possibilities, it seems to me like ft_vascii for the >> format is something that could work, but then I am not sure about what >> to use for the suglen field (I guess I could use the largest length that >> could be produced). >> >> Any thoughts on the approach I am considering or if there is a better >> way to do this? >> >> Thanks in advance. >> >> Cheers, >> >> Eloy Paris.- ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Owfs-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
