Jim,
I like your idea.
I think your example needs to be more like:
create the filename "temperature"
read a 16 bit int at address x
push it through transform table q that outputs a float
output the float with the printf string %s.
This assumes that the transform is done on the OWFS side rather than the
slave. I believe that is how it is done now for the different
thermocouple types as an example.
Paul: Does this create any problems for the OWFS/owserver split?
Also, just because you don't think you want to store location
information in your implementation of things does not mean that ascii
strings should be ruled out. It's just a read/write a fixed length
string or 0 terminated string with max length at address x and put the
string in hierarchy location foo. How a given slave uses this it totally
up to them.
In this paradigm, loading new code looks like a fixed length string
write to a hierarchy name that corresponds to the second level program
address. Then you kick something to get it going, possibly a "start at
x" widget. If you do the start at x technique, you can always restart a
slave or jump back to the bootstrap by giving it the bootstrap start
address. This can be really handy when a slave locks up and I need to
hit it with a really hard hammer to get it back. [Perhaps I'm the only
one who sends things off into never never land. ;)]
This seems to simplify most of how things would need to work. The hard
thing left is that "transform table" functionality. How can we allow for
various transform mechanisms to be applied on the host side without
impacting the complexity and stability of OWFS very much?
If I go forward with defining this model, here are the pieces I see:
Are these the basic read/write types that we need to support?
8 bit
signed int
unsigned int
do we want to support bits and bit masks??
strings
char string fixed length
char string 0 term w/ max length
16 bit
signed int
unsigned int
32 bit
signed int
unsigned int
float
64 bit
signed int?
unsigned int?
double
Do we need to support both little and big endian data transfers? If so,
there either needs to be a known place to look to read a byte to flag
whether the machine is little or big endian.
I think that alignment is the problem of the slave. It should offer all
addresses so they are aligned as needed and not bother the upper level
about this at all.
hierarchy names
Is this a byte count and fixed length string or a 0 terminated string?
What is the max filename length? What limitations do we want for
hierarchy names (allow or disallow non-ascii, unicode...)? I assume the
name can include directories relative to the device root and that OWFS
will create all the necessary nodes to make it so.
What happens when a new name conflicts with an existing name that points
to a different address, transform,...?
transforms
Here is the hairy part of this mechanism IMO.
To display the thermocouple value connected to a battery sensor, I need
to read the main value, read the cold junction temperature, reverse look
up the cold junction tempurature in the table, subtract that from the
main value and then take the result and look it up in the forward table.
It may be that it needs a pair of functions rather than tables if we are
dealing with things like 32 bit values or interpolation tables.
display semantics
Being the old fart that I am, C style printf strings are my default. Is
this the right thing for the job? Is this overly complex?
Here are a couple more subtle things to add to the pot.
pseudo filenames
This may be a "Bad Idea" but I thought I would throw it out.
This means I need something in OWFS that is related to a device but not
represented on the device.
Let's say I now want all my temperatures to have a "converted at" time.
When I read a temperature, it shows when the conversion started. This
can make certain kinds of higher level operations easier. When I write
the simultaneous word for a bus, it needs to set the time for all the
appropriate slaves so it can be read back when I look at this.
Do we want to say no to this? Do we want to say it could be added but
not right now? Is this something that that slave tells OWFS about or is
it part of an OWFS config?
Saying maybe the slave can do this means more care in defining the specs
for name creation. For example, it would allow for a name without a
bound device address.
Capabilities
Do we want some standard bits that smart slaves set to tell OWFS things
about how to deal with it?
examples might be:
Does this slave honor simultaneous commands?
Is this device parasitic powered?
Do I support the OWFS name creation mechanism?
Since we're in there mucking with these things, it's just something to
look at. These could all be done with bit commands from the name
mechanism, but it might be cleaner for OWFS to have a standard block of
these available for allocation.
enough for now
jerry
Jim Kusznir wrote:
> This is my thought, yes. I was thinking something along the lines of
> "read an int at addres xxxx and call it "temperature" type commands.
>
> --Jim
>
> On Mon, Mar 8, 2010 at 10:13 AM, Paul Alfille <paul.alfi...@gmail.com> wrote:
>> So if I understand correctly, the firmware upload not only programs the
>> slave, it also contains information for OWFS to parse and create the
>> devices?
>>
>> On Mon, Mar 8, 2010 at 11:31 AM, Jim Kusznir <jkusz...@gmail.com> wrote:
>>> 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
>>>
>> ------------------------------------------------------------------------------
>> 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
