Q: What is the Storyboard Embedded Engine?
It's a highly optimized graphics runtime that interprets a data file that describes the visual content and screen flow of an application. Each engine is optimized for a particular target configuration composed of operating system, CPU hardware and rendering system. The deployment bundle, interpreted by the runtime, contains the generic instructions for driving the target configuration.
Q: What platforms are supported by the Embedded Engine?
The Embeded Engine has a highly portable and very modular design. To port the engine to a new operating system configuration that provides a standard ANSI C compiler and modern OS primitives (timers, tasks/threads) is very little effort, measured in days rather than weeks. Leveraging a new rendering system is a simple matter of writing a render plugin to map the Storyboard Engine API to the native rendering system.
See the Embedded Engine technical specifications tab for the currrent matrix of supported OS, CPU, and Rendering Engine technologies.
Q: How do I specify where the runtime plugins are located?
There's a single environment variable, GRE_PLUGINS, that can contain a list of plugins filenames to load (: separated on unix, ; on windows) or can point to a directory to scan for plugins. When loading plugins from a directory, the plugins must have -plugin- as part of their filename.
Q: Something isn't working correctly; can I get more verbose output from sbengine?
Absolutely. By specifying one or more -v options to the sbengine executable, you'll get an increasingly verbose output from the Embedded Engine with regard to what it's doing. In general, four (4) v's tends to be a sweet spot between too much and too little verbosity for standard development.
Q: Do I have to use sbengine to interpret the deployment bundle? I want to use my own application.
The sbengine application that's provided as part of the Crank Storyboard Suite is intended to be a sample application to demonstrate how the Engine API is used to load, interpret, and run a deployment bundle. In many cases, it's sufficient for you to simply use or modify the sbengine application directly; however, the complete source to sbengine is provided to serve as an example of how you can use the Engine API.
Q: How should I interface my application with other parts of my embedded system?
In general, the interface with the rest of the embedded system is done using the Storyboard I/O library which provides a transport agnostic message communication channel. This allows named events with custom data payloads to be injected into the application. At that point the application can extract and work with the event data using custom action handlers.
If the Storyboard I/O library does not provide a suitable interface, then a custom interface can be created using the Storyboard Plugin API which is a C/C++ programming interface. The Plugin API provides a comprehensive interface to the Embedded Engine's internal operation and can be used to implement a variety of scripting interfaces.
Q: Do I have to program my application in C? Can I use a scripting language to interface to my application?
Embedded Engine provides support for Lua as a general scripting language through the Lua plugin (libgre-plugin-lua.so). Lua is a small, fast, and efficient scripting language that is well suited for use in embedded systems. It's easy to introduce custom functionality that ties into the embedded system using its C/C++ interface.
While Lua is provided as the default scripting language, it's not the only possibility. The Plugin API provides all of the hooks required to integrate any scripting control language so it should be relatively straightforward to integrate other scripting languages such as Perl, Python, TCL, Ruby, or Javascript.
Q: How big is Embedded Engine?
The size of Embedded Engine core depends entirely on the choice of platform configuration; OS, CPU, and rendering technology. The core is responsible for the maintenance of the application model's data structures, the dispatching of events, and invocation of actions. All of the event generation, action handlers and renderers are provided by plugins.
This modular approach to application design allows for a highly configurable system where the size of the application is entirely dictated by the desired functionality and can be tuned to fit nearly any constrained system.
Do you have questions? We enjoy talking tech. Please call us at +1.613.595.1999. Or email us at info@cranksoftware.com.