Embedded beans encapsulate the initialization and functionality of embedded systems basic elements, such as CPU core, CPU on-chip peripherals (for details on categories of beans delivered with Processor Expert see chapter Bean categories), FPGAs, standalone peripherals, virtual devices and pure software algorithms.
These facilities are interfaced to the user via properties, methods and events. It is very similar to objects in Object Oriented Programming (OOP) concept.
Easy Initialization
A user can initialize beans by setting their initialization properties in the Bean Inspector. Processor Expert generates the initialization code for the peripherals according to the properties of the appropriate beans. User can decide whether the bean will be initialized automatically at startup or manually by calling the bean's Init method.
Easy On-chip Peripherals Management
Processor Expert knows exactly the relation between allocated peripherals and selected beans. When the user chooses a peripheral in the bean properties, Processor Expert proposes all the possible candidates but signals which peripherals are allocated already (with the icon of the bean allocating the peripheral) and also signalizes peripherals that are not compatible with current bean settings (with a red exclamation mark). In the case of an unrealizable allocation, an error is generated.
Unlike common libraries, Embedded Beans are implemented for all possible peripherals, with optimal code. The most important advantages of the generated modules for driving peripherals are that you can:
- Select any peripheral which supports bean function and change it whenever you want during design time.
- Be sure that the bean setting conforms to peripheral parameters.
- Choose the initialization state of the bean.
- Choose which methods you want to use in your code and which event you want to handle.
- Use several beans of the same type with optimal code for each bean.
The concept of the peripheral allocation generally does not enable sharing of peripherals because it would make the application design too complicated. The only way to share resources is through the beans and their methods and events. For example, it is possible to use the RTIshared bean for sharing periodic interrupt from timers.
Methods
Methods are interfacing bean functionality to user's code. All enabled methods are generated into appropriate bean modules during code generation process. All Methods of each bean inserted into the project are visible as a subtree of the beans in the Project panel.
You can use in your code all enabled methods. The easiest way to call any method from your code is to drag and drop the method from project panel into the editor. The complexity and number of methods depend on the bean's level of abstraction.
Events
Some beans allow handling the hardware or software events related to the bean. The user can specify the name on function invoked in the case of event occurrence. They are usually invoked from the internal interrupt service routines generated by Processor Expert. If the enabled event handling routine is not already present in the event module then the header and implementation files are updated and an "empty" function (without any code) is inserted. The user can write event handling code into this procedure and this code will not be changed during the next code generation.
All Methods and Events of each bean inserted into the project are visible as a subtree of beans in the Project panel.
Interrupt Subroutines
Some beans, especially the Low-level beans and Peripheral Initialization beans () allow to assign an interrupt service routine name to a specific interrupt vector setup.
The name of the Interrupt service is generated directly to the interrupt vector table and the user has to do all necessary control registers handling within his/her code.
ISRs items are listed in subtree of a bean in the Project panel.
|
|
Figure 1 - Example Of a Bean With Two ISRs |