Godb
From Wikipedia, the free encyclopedia
 |
This article may require cleanup to meet Wikipedia's quality standards. Please improve this article if you can. (May 2008) |
GoDB is a Lightweight Rapid Application Development (RAD [1]) Platform Developed by GoDBTech Private Limited based out of Chennai - India.
Apps developed in GoDB can Run on Disparate Processors and Operating systems.
Processors / SOC Supported X86,ARM7-Cortex,Mipsx,SHx,BlackFin, DSPs, VLIW processors etc.
Operating Systems Supported. Linux,ucLinux,Windows,WinCE,PocketPC,uITron RTOS Etc. GoDB has been ported to NULL OS environments with a simple I/O driver (Video and GPIO keyboard).
GoDB Consists of a RAD IDE hosted in Windows and a Lightweight (250-600k) Runtime on the target.
GoDB also has an optional provisioning Server to distribute code and data to the targets.
Design Goals of GoDB.
Simplicity - Easy to Program Basic Like Scripting language called GBasic.
Productivity - Less Code to do the same Work.
Reliability - Well tested functions across platforms.
Light-Weight - Runs acceptably on devices with 1 MB to >1GB RAM
Fast - Runs acceptably on devices from 33 MHz to >3Ghz
No-Dependency - Does not depend on runtime libraries like MFC / ATL / DirectFB / GTK / X etc, but can work with them.
GoDB Runtime Consists of.
1) Drawing Primitives (Lines to Rounded Gradient Rects) 2) Anti-Alaised font rendering engine. 3) Support for Unicode Fonts and Complex Languages (Like Hindi and Tamil). 4) Over 30 built in Transition effects. 5) Complete Widget Library from labels and edit boxes to trees and grids. 6) A GBasic Scripting Engine to tie it all together. 7) HTTP Stack and HAL
What GoDB Needs on the Target:
1) A VRAM ptr/API to copy the GoDB rendered screens to the Display.
2) Input functions to implement a event loop (GetKey/GetTouchPoint from IR,GPIO/Touchpad,mouse etc)
3) With GoDB you can develop a complete GUI app just from a base linux kernel with just frame buffer support. (NO DirectFB/X/GTK/QT Required). XLib versions of the runtime are also available
4) GoDB also can run on GUI frameworks like X, GTK ,Win32 , WinCE etc.
Why GoDB ?
1) Extremely fast and very Low footprint
2) Ported to almost all popular OS/Processor combinations. Including some unconventional DSP only targets.
3) Very easy to port to proprietary/emerging hardware architectures (GoDB written in Pure ANSI C).
Easy Development:
1) Develop Test and Debug MMI/GUI and Application state machines on a PC and then deploy to target.
2) Target middle ware can be easily simulated on the PC with stubs during development.
3) App development can be started even before the availability of the boards
4) You don't need as many boards/ice for development.
5) Enormous productivity gains - As development happens on the PC : Traditional development of painfully long build -> load -> debug/run cycles on the target can be eliminated.
6) Time to test out usability and more flexibility to change MMI based on inital feed back means a more institutive and feature rich product can be developed in much shorter time.
Protection of investment.
1) GoDB Apps are immune to hardware / OS changes. The same GoDB app will run without any changes/compiling on any hardware that has the GoDB Runtime ported.
2) The Same app can run on Linux/WinCE/RTOS.
Layered approach to building apps.
4) GoDB apps are built as layers. 1) At the lowest is the behavior written as GBasic scripts. 2) On top of this is the UI layout called forms which are XML files. This can be changed across product modes so that the UI layout (positions and ordering) looks different with out recoding the behavior. 3) On top of this are the Style sheets that allow changes in the color theme (FG/BG color. fonts etc)
This architecture allows changing of one with out affecting the other. So the same app can be used across multiple modes of devices.
As there is clear demarcation between the Coding for behavior (event handlers and state machines) and the coding for design (design, color and look & feel ) they can be handled concurrently by different teams.
The Forms Image and style sheets can be developed by graphic designers and the state machines etc can be coded by programmers in parallel.
Middleware Integration and Extensibility:
1) GoDB Supports Bindings to Native Libraries (so/dll) and Native function pointers (for RTOS). The middle ware APIs can be directly called from GoDB and the Middleware can Call the GoDB VM back synchronously and asynchronously. Ex: Media Player APIs
1) GoDB can be extended using Bindings to Native Libraries (so/dll) and Native function pointers (for RTOS). So anything that GoDB does not have can be added as a native function/library. Ex: DSP accelerated Image Transitions/Processing etc.
2) There is also a clear framework for threads in native libraries to post events and call GBasic functions, this allows for a clean and clear callback architecture.
GoDB App Development Lifecycle (Separation of Graphic Design from Coding).
Application Development Team (Development on PC).
1) Use IDE to develop the State Machines in GBasic.
2) Develop , Run and Debug from a PC in the simulator.(No need for the target.)
3) Use Middle ware Stubs in DLLs to simulate target functionality. (Ex: LoadFile, Play, Stop, Enumerate Hosts etc.)
4) Build the project to create a BDB (collection of Forms,Images,Stylesheets scripts etc of the project (like .tar) ) file.
Graphic Designer Team (Development on PC).
1) Create graphic assets in PhotoShop/Gimp Etc as Jpegs,PNG etc
2) Add the graphic assets to the GoDB Project in the PC IDE.
3) Use the Drag Drop Editor in the IDE to create forms (XML files) that determine the Widget Layouts and Look and feel.
4) Create Style Sheets for skin-able look and feel (Colors, Fonts etc)
Middleware Development Team (Development on PC+Target).
1) Implement Middle ware APIs that will do the actual functionality.
2) Run the GoDB VM on the target with the BDB, the VM will now map the simulator stubs to the real middleware apis.
3) No other development is required for GoDB on the target.
[edit] References
Multiplatform [2]
