Oscar Software Framework Manual Description
The Oscar (open source camera) software framework serves the purpose of abstracting the hardware for leanXcam and indXcam platform to applications. It provides an easy-to-use set of methods and hides the complexity of the hardware interfaces. Further the framework provides usefull operations which are not bound to a certain hardware, but commenly used for a smart vision application. It was designed to run on the Linux operating system. The actual functionality of the framework is grouped into loadable modules. There is for example a module to configure and capture pictures with the on-board CMOS sensor, and another one to read out GPIOs http://en.wikipedia.org/wiki/GPIO. The hardware independent modules include for example an image processing library, or a group of functions to load and store pictures from the file system.
The application only loads the modules it needs, which in turn will automatically load the modules they depend on. Since the framework is compiled into static libraries being linked with the application during compile-time, only the object files of the modules actually used are linked into the executable. This reduces its size and prevents unnecessary overhead of unused functions.
The framework can be compiled for two architectures: target and host. The implementation of most modules differs for these platforms. The target implementation depends on the hardware, respectively drivers of the operating system and makes use of their services. On the host on the other side, the underlying mechanisms are being emulated up to a certain point. For example, instead of telling the camera sensor to capture a new image, the picture may instead be loaded from hard disk. The idea behind this duality is that the same application code runs on both a standard PC and on the DSP. This allows rapid prototyping and easy testing on the host PC, with a subsequent fast migration to the target platform.
When being compiled for the target, the cross-compiler for the Blackfin processor is used and libosc_target.a is created; for the host the normal gcc compiler is used to compile libosc_host_host.a.
The framework can only be instantiated once per process. It is possible though that a task is split over several processes, all instantiating a framework. The only condition for this is that modules accessing an unshareable hardware resource are only loaded by one of the processes; for all other processes the module load will fail. Some definitions and macros used internally are made public to the user. One example of this is the type redefinitions (e.g. uint32), which may be assigned differently depending on the platform.
Go to Oscar Software Framework Manual for a detailed description of the available modules and their functionality.