|
|
What
are the benefits in using the Staccatotm Software Design Method? How difficult is it to learn and use Staccatotm for my next project? What are the advantages to using Finite State Machines (FSMs) to design modules? Is the Staccatotm Design Method appropriate for a 'multiprocessor/multicore' hardware platform? How does StaccatoTM handle device interrupts? How does the Staccatotm Software Architecture compare with UML 2.0 StateCharts? |
|||||||
|
Q. What are the benefits in using the Staccatotm 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 Staccatotm for my next project? A. Staccatotm 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, Staccatotm 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 StaccatoTM 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 Staccatotm 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 Staccatotm Tutorials here... Top of Page... Q. Is the Staccatotm Design Method appropriate for all embedded system platforms and development environments? A. Yes. The Staccatotm 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. Staccatotm 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 Staccatotm Design Method appropriate for a 'multiprocessor/multicore' hardware platform? A. The Staccatotm Design Method is based on a multiple virtual processor architecture. Each 'application' task has it's own 'soft, virtual processor', which, along with the task's state machine process code, emulates a single processor system. In this manner, Staccatotm 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 StaccatoTM 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 StaccatoTM, 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 StaccatoTM 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 Staccatotm Software Architecture compare with UML 2.0 StateCharts? A. The Staccatotm 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 Staccatotm 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 Staccatotm Architecture, an RTOS is simply not needed, and each task performs its own event processing within its state machine code. Top of Page...
|