BitFlow SDK Application Programming Interface
This SDK works with all of BitFlow's current frame grabber product familes. The SDK consists are five high level APIs:
The Road Runner and the R3 are so similar that they share the same API. The Raven has its own API. The Alta, Karbon, Neon, R64 and R64e all use the R64 API. The two generic high level APIs, called the Camera Interface API (Ci functions) and BufIn (Bi functions), which are designed to work with any of the BitFlow products. Applications calling the Ci or Bi layer need not worry about which type of board is installed.
API Layers
At the lowest level there is a common layer, called the BitFlow API (BF functions). Most applications can be written using only the high level APIs, however, occasionally low level access is needed, thus the BF API is available. The following figure illustrates the organization of these layers.
The concept is that each layer calls the layer below it and that some API works with one family of boards while other APIs work with all boards. However, the functionality available with each API is different. For example, if an R64 is installed in a system: Bi, Ci, R64 and BF APIs can all be used, but the R2 API can not (although there would be no need for this API). Writing a complete application using only the BF API would be extremely difficult, it's role is mainly as a low level foundation for the other functions to build upon. If a R64 is installed, you could use either the R64 API or the Ci API, the functionality is roughly equivalent. The Bi API can be used to add powerful buffer management. However, an application written with the R64 API will only work when R64 (Alta, Karbon and Neon) are installed, but an application written using the Ci or Bi APIs will work with any family of board in the system.
In addition, the R2, Rv and R64 layers are broken into separate tiers. Most applications can be written using only the highest level functions. However a mid-level function may be required to make a small tweak to the board setup. The lowest level is basically used for direct access to the memory and registers on the board. Some low level functions are duplicated between the R2 and Rv APIs and the BF API. For example there is a function R2RegPoke and a function BFRegPoke. These functions are equivalent, the R2 version of which is provided as a convenience.
Which API should I use?
There are also three independent display APIs provided to simplify the process of display images in a windows environment.
| Application | API | Example |
|---|---|---|
| The application will only use Road Runners or R3s. There are no plans to add different board families in future. The application only needs to acquire into one or two buffers. | R2 | R2VIew - single buffer Ping Pong - dual buffer |
| The application will only use Ravens. There are no plans to add different board families in future. The application only needs to acquire into one or two buffers. | Rv | RvView - single buffer RvProcess - dual buffer |
| The application will only use boards from the Alta, Neon, Karbon or R64 families. There are no plans to add different board families in future. The application only needs to acquire into one. | R64 | R64Simple - single buffer |
| The application must work with more than one board family, or the application requires one board family now, but may need to work with other board families in the future. The application only needs to acquire into one or two buffers. | Ci | CiView - generic viewing application. |
| The application needs to acquire into more than two buffers (either sequentially or continuously using a circular buffer set), without taxing the CPU. This API will work with all board families. | Bi | BiFlow - sequential capture Circ - continuous circular buffer capture |