EDN Columnist: September 1, 1995
I do do embedded systems and find great joy bringing them to life. In this column, I plan to make good on a promise to discuss embedding a fuzzy-rule-based design (EDN, March 16, 1995, pg 133). What I hope you get from reading this column is that, for the most part, you use the same tricks and techniques to embed a fuzzy system as you would for a nonfuzzy system. (By the way, please read Jack Ganssle's embedded-system-design column, which runs in EDN every other issue. I read it and enjoy it very much.)
Of course, if your fuzzy development tool supports embedded-system development and you like the results, use it. Inform's fuzzyTECH does so, providing download, optimize, debug, and test capability for a number of target processors. Other fuzzy development tools provide partial support to embedded systems, primarily by generating C code of the developed fuzzy system. HyperLogic's CubiCalc, for which I gave a strong "buy this" recommendation last January, is an example. So far, none of the major players in embedded-systems development tools include fuzzy support as part of their package. I hope these tool manufacturers soon realize its market potential, and that the added capability will be well thought-out and designed.
For the remainder of this column, I'll detail an approach that's valid if your fuzzy tool supports embedded systems either partially or not at all. It's the approach I've used in 10 to 12 embedded fuzzy projects to date. For those of you with embedded-system- design experience, the steps in this approach will seem obvious—recall that there is nothing special about embedding a fuzzy design.
Let's get started. First, by the time I attempt to download a fuzzy module or subsystem to a target environment, I have guaranteed (as best I could) that the first cut of my fuzzy design has run, and run well, in a simulated environment. (Even the nonfuzzy world is beginning to accept the value of simulation as a means of verification.)
With a verified simulation, the first step in embedding the design is translation to a suitable language. I have always chosen C—so far, without resistance from clients. I am most comfortable with C; its embedded compilers are quite mature, and it interfaces well with assembly language, which, in my designs, is almost always necessary.
If your fuzzy development tool supports translation to a high-level (or assembly) language, and you are happy with the resulting code (be skeptical), translation is a "no-brainer." If your fuzzy tool does not generate code, or the code it generates is inadequate, you need to make your first decision: whether to write your own code or use a third-party translator.
I have done both. Writing your own, like writing embedded, multitasking kernels 15 years ago, is fun, educational, and not too difficult. But, it's cost-effective only if you have garnished the system with nonstandard structures. Everyone should write at least one fuzzy system from scratch, but probably not many more.
When using a translator, my preference is Byte Craft's Fuzz-C. Byte Craft's bread-and-butter products are compilers, and Fuzz-C's ability to generate optimized C is quite evident in the code it generates. I have been told that the new version, of which I do not yet have a copy, is better still. Of course, there is nothing to preclude using the translated code as a starting point from which to add your personality.
Now comes your second decision, which is whether to structure the fuzzy system as an interpreter or to use inline code. In an interpreted system, data tables represent membership functions and rules, and a generic fuzzy kernel evaluates rules by reading from these tables. With inline code, rules and membership functions are part of the code to be compiled; inline code has no tables or interpreting kernel.
In general, interpreted systems are slower but more memory-efficient, enhance the ability to make and test modifications with table changes rather than a modify/compile/link/ download sequence, and require a fuzzy kernel, which can be assembly-language-optimized for speed. Inline systems are typically faster, somewhat less memory-efficient, and are a bit more difficult to modify. If possible (that is, if there are no real timing restraints and no memory constraints), you may want to develop the system using an interpreter and have the final version compiled. Ultimately, the decision may be more a matter of style than of practicality.
Again, your tool choice may have already made this decision for you: CubiCalc generates interpreted code data structures, and Fuzz-C generates inline code. If you write your own code, the choice is yours.
Downloading to the target is identical to downloading a nonfuzzy system. How you do it depends on what embedded tool set you are using. Debugging the system is also the same, with one exception. You may opt to develop your own functions for displaying parameters of interest, membership functions, and rules in a window on the host or on a dumb terminal.
The choice of an embedded tool set is important. Memory-based development tools often have a command-line interpreter capable of accepting user-defined commands, allowing custom debugging functions to be called through the tool. Moreover, with an interpreted system, you can write custom functions that modify rules and membership functions on the fly while the system executes.
Finally, experience helps: experience in fuzzy systems, in embedded systems, and in embedding fuzzy systems. Experience is especially helpful in recognizing rules and membership functions from their C-based or assembly-language-based data structures.
In summary, note the following key points: