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 Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
