Q. What are the benefits in using the Staccato™ Software Design Method?

A. Customers benefit by more reliable and better performing products, designed to their requirements and specifications. Embedded Product developers benefit by having a consistent design method, which is easy for multiple software and hardware engineers to learn, use, and maintain (through good documentation) product software.
Top of Page...

Q. How difficult is it to learn and use Staccato™ for my next project?

A. Staccato™ is first a design method for embedded systems. That means proper documentation of Requirements and Designs, along with Test Plans and Validation and Verification. As part of this overall approach to good design practices, Staccato™ also provides the 'System Core' which requires your embedded system application to be properly partitioned into application tasks, each of which is designed as a Finite State Machine, which is directly coded into your modules. The Executive and System Calls pull it all together to give you excellent performance, and ease of maintenance. The concepts are easy to learn, and will provide a better understanding of how 'software' is nothing more than an extension and abstraction of the hardware. The Staccato™ Crossroads Software Development Kit (SDK) includes (2) IEEE CEU Certified courses, a Demo Project with C-source code and complete project documentation, all of which will provide you with all you need to start a new project.
Top of Page...

Q. What are the advantages to using Finite State Machines (FSMs) to design modules?

A. State Machines (FSMs) are the best way to describe the sequential behavior of a system component or attribute. State Diagrams can be used to convey the system's behavior in response to both internal and external events and conditions. The analysis of most source-code would reveal, to the knowing eye, the existence of some aspect of sequential operations. Unfortunately, this occurs more of a necessary artifact, as opposed to a direct design method, usually resulting in a poorly structured system that can be very difficult to maintain. The basic concept of a state machine is: if a specified event has not occurred, than nothing needs to be performed for this task. If it has occurred, then perform some action and transit to the next defined state, to continue the sequential process for this task. The Staccato™ Design Method is based almost entirely on 'direct coding' of these powerful State Diagrams. Their usage is what allows for excellent performance of your embedded software. For more information on this subject, check out the provided Staccato™ Tutorials here...
Top of Page...

Q. Is the Staccato™ Design Method appropriate for all embedded system platforms and development environments?

A. Yes. The Staccato™ Design Method is appropriate for all target platforms. The System Core is written in the 'C' language, although it's constructs can be encoded in any language that supports these constructs. No special 'tools' are needed other than a compiler/linker for your target processor. Staccato™ is appropriate for all embedded software systems: from 8-bit microcontrollers through embedded PC. Check the Products Page for device platforms currently offered for Staccato. No RTOS is required.
Top of Page...

Q. Is the Staccato™ Design Method appropriate for a 'multiprocessor/multicore' hardware platform?

A. The Staccato™ Design Method is based on a multiple processor architecture. Each 'application' task has it's own 'soft, virtual processor', which, along with the task's state machine process code, is analogous to a single processor system. In this manner, Staccato™  performs as a 'system of directly executed Finite State Machine (FSM)-encoded tasks'. Your entire set of application/FSM tasks can therefore be distributed across multiple processors. The only limitation to implementing such a design is the hardware architecture and software development tools. This approach works well with single processors as well.
Top of Page...

Q. How does Staccato™ handle device interrupts?

A. In addition to basic system timer interrupts, many systems provide hardware interrupts from a variety of devices, such as a serial communication device. Because of the excellent performance inherent in a system using Staccato™, your device Interrupt Service Routine (ISR) usually only needs to register, or flag the interrupt event to the device handler task, with minimal processing within the ISR. The corresponding task will be in a state where it can respond to this interrupt event appropriately. Because tasks are executed at such a high rate within the Staccato™ architecture, handling frequent device interrupts in this manner is recommended. However, for stricter timing requirements, there is no restriction on performing the necessary processing within the ISR.
Top of Page...

Q. How does the Staccato™ Software Architecture compare with UML 2.0 Statecharts?

A. The Staccato™ Software Architecture is based on a 'system of Finite State Machines (FSMs)', where, after proper partitioning, each software task is implemented as a Finite State Machine. Each state of a task's state machine is encoded as a single 'C' function, which is executed through completion by the Staccato™ Executive. UML 2.0 Statecharts is based on the work of David Harel, in which he describes a method for the 'visual formalism for complex systems'. StateCharts uses the concept of hierarchical state machines (HSMs), along with other concepts such as orthogonality, to provide the means to visually describe the behavior of an entire complex software system. Although intended as visualization method, products do exist that claim to translate StateChart representations into executable code. These methods typically assume that the resulting FSMs will be run on an RTOS/multihreaded platform, where events are captured and dispatched by the OS to an event queue for use by the appropriate tasks. In the Staccato™ Architecture, an RTOS is simply not needed, and each task performs its own event processing within its state machine code.
Top of Page...