I agree with most of this. After discussing this with a friend, we came to the conclusion that most uC implementations will support only what is actually implemented in their ROM image, and little else, so exposing all the functions is probably not helpful, but is still possible if desired.
I will probably add 2 fields: length and name Length is so owfs can skip unknown functions. Name is the obvious thing, as you pointed out. Cheers -tmk On Feb 24, 2010, at 11:41 AM, Jim Kusznir <[email protected]> wrote: > I've been thinking about this issue off and on for a couple years now, > and I like a large part of what I see so far, but also want to throw > in some thoughts. > > After reading some details on the BAE chip as well as talking to some > embedded designers and thinking about applications, I envisioned > something a bit different and simpler. I'm coming from the > perspective of a middleware designer, who's most recent "masterpiece" > was a setup where "simpler is better" was the focus, and the results > were pretty surprising (thesis in progress :) ). > > My thoughts were to build a sort of 2-stage microprocessor code (open > source so it can be adapted to different chips as needed). The > "bottom stage" or "boot loader" would contain the base OWFS > communication libraries (including the devices unique ID), and support > for the "fimrware load" function. The firmware load would allow one > to upload new firmware to the chip. This firmware is the "phase 2" > code, and would enable functions of the processor as desired. > > Specifically, EVERY USER would load a fimrware module that would > configure the remaining capabilities of the microprocessor they want > to use, do whatever control/computation work they want to do, and tell > the "phase 1" fimrware what types of data they're exposing. > > I believe this needs to be done in a memory mapped function, and > perhaps it could be as simple as a "configuration block" that OWFS can > read. This would provide information such as "memory address", > "size", "type", "read/write status", and "plaintext name". Using > this, OWFS can populate a directory with whatever capabilities that > chip has enabled. > > An important detail here is that the chip would NOT expose "all > possible I/O" by default. As was previously pointed out, there are > often different capabilities of a processor that share pins. They > can't all be available at all times, and what makes sense is going to > be highly dependent on how its wired. As such, it seems that its > reasonable to load "custom fimrware" to configure the microprocessor > to do what is needed. And I'd rather have that functionality. Even > if it isn't a 2-stage code for the microprocessor, but a framework > that I tweak for my application. That way, if I am just using the adc > as a thermocouple input, I can tell OWFS that its temperature, and I > can internally convert the reading as appropriate. > > I prefer to leave the naming, typing, etc. of data to the entity that > has the greatest authority as to what that data is. That's why I > belive this responsibility lies with the microprocessor, not OWFS. I > also try to think about as many of the different application as I can > think of, and then apply the various proposals of how to make it work. > Then, take the results and look at what result was "simplest" or > "most natural". Some of the more recent OWFS text-file configuration > and special module-loading sounds like making things overly > complicated...Why configure your device in two places and make sure to > keep them in sync when you can just do it in one and not have a > sync/config issue? > > --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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
