Throughout our twenty-year history we have grown as the software industry as it has grown. Twenty years ago the industry largely regarded the development of end-user software to be an entirely different pursuit than that of an embedded controller application. The main reason being because the operating environments were vastly different. Firmware generally was associated with tight processing constraints in minimally capable hardware environments (and, of course, was burned into ROM).
In recent years, however because of the proliferation of low cost, abundantly capable microprocessors and support hardware, the difference between the embedded firmware operating environment and that of the typical end user application has become almost insignificant.
It is not at all unusual to find embedded systems with a multitasking operating system, a full network protocol stack, a relational SQL database server, a multi-user graphical user interface server and more.
Visit our list of Environment Element Components page to see a catalog of some of the many processors, protocols, languages, libraries, and facilities we have worked with over the years.
In this age, almost every device we encounter that is electrical has some kind of electronic automation. Microprocessor controllers play a part in everything from devices as simple as home appliances to complex computer peripherals. Over the years, we've produced firmware for a wide spectrum of these fascinating devices.
In every firmware development process there are frequently trouble spots which engineers encounter. Our experience in these areas allows us to help insure a development effort will remains on schedule, and within budget. Some specific areas include:
Our end-user application development experience started with an interactive text editor built for a port of Unix back in the early 1980's. Since then, we've garnered praise from numerous customers (Western Digital, Sorrento Electronics, Warner Bros. Studio Stores, and many more) for the demonstration of our ability to define application user interfaces that present information in a clear, concise, and efficient format which is intuitive and productive for the user.
In software engineering circles, it's an odd fact of lift that many of the most talented developers have an aversion to both the Software Quality Assurance (SQA) and the documentation processes. It has been our experience that one of the most expensive mistakes a company can make is to short-change the SQA process.
No amount of effort will turn up all possible software problems (indeed, any given module only functions within its specification in a tightly controlled context). However, the key to achieving stellar results from SQA efforts lies in understanding how a given software environment works and what must be done to methodically examine each possible failure point.
Writing high quality, comprehensive documentation (whether it's a requirement specification or an end-user document) and designing an efficient software algorithm are very similar exercises. In both cases it takes skill and dexterity at defining a problem to be solved, organizing just the right pieces of information into the optimal order so that everything is presented as it is needed, and carefully presenting all that is necessary and nothing more.
Designing a good documentation set can be almost as complicated as a good systems design (and every bit as important). However, many of the technical writer staff (while highly qualified authors) have a poor grasp of the documentation tools and the ramifications of how to design a system that can live and breath in an engineering department over the years without quickly becoming unmanageable and obsolete. We've solved this problem, and have the know-how to do it again with the next generation of tools.
Follow the link to our Customers Page
for a partial list of our customers, their projects and a
description of some of our roll in those projects.