BitFlow, Inc. BitFlow SDK Version 5.00 2008-02-20 SDK Change history (please put word wrap on to view in your text editor) Version 5.000 - 2008-02-20 --- SDK NEW FUNCTIONALITY --- * First non-beta release for the Karbon family. * First non-beta release for the Neon family. * First non-beta release for the Alta family. * First non-beta 64-bit SDK. * The direct draw display surface is not longer supported * CiView now only supports one display mode, DispSurf (DIBSection) * There have been many enhancements to the high level BufIn example applications, Circ and BiFlow. These applications now have consolodated option dialogs, and also support many more acquisition options. * Many enhancements have been made to CamEd, support for Analog cameras, support for PoCL cameras * All dependencies of Microsofts MFC class have been removed from all DLLs. The example applications still depend on them however. * When saving image sequences to disk, the user prompted if they wish to overwrite an existing file. * The SDK now ships with an uber-solution, "\BitFlow SDk X.XX\Examples\BitflowExamples.sln", which can be use to build/debug/test all of the example applications at one time. * This release, all of the DLLs, the driver, the libraries and examples are all built using Microsoft's Visual Studio 2005. This compiler is highly recommened for use with this release. * A new function, CiSysBoardFindSWConnector(), has been introduced which makes open the desired board much easier. This function takes a switch setting (for cases where there are multiple boards) and a connector number as in input and returns pEntry structure for the correct board. This function is very handy when one or more boards are installed which might have one or more virtual frame grabbers. The example "CiCimple.c" illustrate usage of this function. --- API CHANGES --- * The following functions are new (see latest SDK documentation for more details): BFDLL BFRC BFCAPI BFBuildNumber(PBFU32 pBuildNumber); BFDLL BFRC BFCAPI BFGetNumCLBrds(PBFU32 pNumCLBrds); BFDLL BFRC BFCAPI CiSysBoardFindSWConnector(BFU32 Type, BFU32 Switch, BFU32 Connector, PCiENTRY pEntry); BFDLL BFBOOL BFCAPI BFIsPLDA(Bd Board); BFDLL BFBOOL BFCAPI BFIsKbn(Bd Board); BFDLL BFBOOL BFCAPI BFIsKbn4(Bd Board); BFDLL BFBOOL BFCAPI BFIsKbn2(Bd Board); BFDLL BFBOOL BFCAPI BFIsKbnBase(Bd Board); BFDLL BFBOOL BFCAPI BFIsKbnFull(Bd Board); BFDLL BFBOOL BFCAPI BFIsNeon(Bd Board); BFDLL BFBOOL BFCAPI BFIsNeonBase(Bd Board); BFDLL BFBOOL BFCAPI BFIsAlta(Bd Board); BFDLL BFBOOL BFCAPI BFIsAlta1(Bd Board); BFDLL BFBOOL BFCAPI BFIsAlta2(Bd Board); BFDLL BFBOOL BFCAPI BFIsAlta4(Bd Board); BFDLL BFBOOL BFCAPI BFIsSlave(Bd Board); BFDLL BFRC BFCAPI BiBufferAssign(Bd Board, PBIBA pBufArray, PBFU32 *pMemArray, BFU32 NumBuffers); BFDLL BFRC BFCAPI BiBufferFree(Bd Board, PBIBA pBufArray); BFDLL BFRC BFCAPI BiBufferQueueSize(Bd Board, PBIBA pBufArray, PBFU32 NumFrames); BFDLL BFRC BFCAPI BiBufferAllocAlignedCam(Bd Board, PBIBA pBufArray, BFU32 NumBuffers, BFSIZET Alignment); BFDLL BFRC BFCAPI BiBufferAllocAligned(Bd Board, PBIBA pBufArray, BFU32 XSize, BFU32 YSize, BFU32 PixDepth * The following function has changed is name for clarity New: BFDLL BFBOOL BFCAPI BFIsR3(Bd Board); Old: BFDLL BFBOOL BFCAPI BFIsRev3(Bd Board); * The following API functions have changed to support 64-bit operatings systems and associated security changes (the new prototypes are listed below): BFDLL BFRC BFCAPI BFStructItemGet(Bd Board, PBFCNF pBase, BFU32 ID, BFU32 Indx, PBFVOID pVal1, PBFVOID pVal2, PBFU32 pDisp, BFSIZET DestSize, PBFSIZET pASize); BFDLL BFRC BFCAPI BFStructItemSet(Bd Board, PBFCNF pBase, BFU32 ID, BFU32 Indx, PBFVOID pVal1, PBFVOID pVal2, BFSIZET SourceSize); BFDLL BFRC BFCAPI BFGetBoardStrings(BFU32 DeviceId, BFU32 Revision, BFU32 InfoHi, BFU32 InfoLo, BFU32 SubVendorId, PBFCHAR pModelSt, BFU32 ModelStLen, PBFCHAR pFamilySt, BFU32 FamilyStLen, PBFU32 pFamilyIndex, PBFU32 pCiFamily); BFDLL BFBOOL BFCAPI DisplayErrorDialog(BFS32 ErrorCode, PBFCHAR ErrorSource, BFU32 ErrorLine, PBFCHAR ErrorMess, PBFUPTR pDisposition); BFDLL BFUPTR BFCAPI DoBrdOpenDialog(BFU32 Options, BFU32 FamilyFilter, PBFU32 pFamily, PBFU32 pBrdNum, PBFU32 pDoInit,PBFU32 pSerPortNum); BFDLL BFBOOL BFCAPI WaitDialogOpen(PBFCHAR Msg, HWND *pHandle); BFDLL BFBOOL BFCAPI WaitDialogClose(HWND Handle); BFDLL BFBOOL BFCAPI DisplayQuestionDialog(PBFCHAR Question,PBFCHAR Answer,BFSIZET AnswerSize); BFDLL BFU32 BFCAPI BFIOSaveDlg(BFBOOL SingleFrame, char* FileName, BFSIZET FileNameSize); BFDLL BFU32 BFCAPI BFIOOpenDlg(char* FileName, BFSIZET FileNameSize); BIDLL BIRC BICAPI BiDiskBufWrite(Bd Board, PBIBA pBufArray, BFU32 FirstBufNumber, BFU32 NumBufs, PBFCHAR FileName, BFSIZET FileNameSize, BFU32 Options); * There have been some small changes to some little used type defines. Please see the file "BFDef.h" for the latest type definitions. * The following functions have been depreciated and support will be dropped in the next release The entire Raven API (Rv functions) * The following functions are no longer supported R2AqDispCleanUp R2AqDispSetup R2PhysQTabWritePart CiPhysQTabWritePart RvPhysQTabWritePart R2AqProgress R64AqProgress RvAqProgress CiAqProgress --- NEON FIRMWARE NEW FUNCTIONALITY --- --- KARBON FIRMWARE NEW FUNCTIONALITY --- * The problem: "For the Alta/Karbon/Neon host buffers must be allocated on 128 byte bounderies. Microsoft provides an aligned alloc function which makes this very easy. We are currently working with our PCI interface manufacturer and hope to have a solution soon after this release. The solution will be field upgradable by distribution of new firmware." has been corrected. --- R64 FIRMWARE NEW FUNCTIONALITY --- * Under certain situations, the VCOUNT register would not read back correctly. This problem has been corrected. --- R3 FIRMWARE NEW FUNCTIONALITY --- --- RAVEN FIRMWARE NEW FUNCTIONALITY --- --- ROAD RUNNER FIRMWARE NEW FUNCTIONALITY --- --- SDK CORRECTIONS --- * CiSimple.c - problem that caused a crash when use a 10-bit (or more camera) when USE_DISPLAY was defined has been corrected. * The installer no longer effects IEEE 1394 devices that are installed on the target computer. * The problem, CamEd adds bogus VRESET column in R64 camera files, has been corrected. * The problem, CamEd does not handle Sensor > BGR button for RCL files, has been corrected. * The problem, wrong behavior on R64 of VCOUNT (LAL = 1) in SS mode, has been corrected. * The problem, wait dialog box not closing in BiFlow and other applications, has been corrected. * The problem, VerCheck reports incorrect camera file, has been corrected. * The problem, BiFlow crashes on playback when used with CA-D6, has been corrected. * The problem, CiConHTrigModeGet returns wrong values when use with an R64, has been corrected. --- NEON FIRMWARE CORRECTIONS --- --- KARBON FIRMWARE CORRECTIONS --- --- R64 FIRMWARE CORRECTIONS --- --- R3 FIRMWARE CORRECTIONS --- --- RAVEN FIRMWARE CORRECTIONS --- --- ROAD RUNNER FIRMWARE CORRECTIONS --- Version 4.908 - 2007-05-15 - Build 207 --- SDK NEW FUNCTIONALITY --- * Download now works for Karbon. * System now checks to make sure slave VFG camera files are compatible with firmware downloaded by master. * CamEd now works with 10-bit camera files used on Bayer R64 boards. * Error messages have been improved when requesting firmware for R64 not capable of using it. --- API CHANGES --- * The following functions are new * The following functions have been depreciated and support will be dropped in the next release * The following functions are no longer supported --- NEON FIRMWARE NEW FUNCTIONALITY --- * Bug that caused the operating systems to see two Neon devices when only one was installed has been fixed. * Acquisition anomilies have been corrected. --- KARBON FIRMWARE NEW FUNCTIONALITY --- * First release of Karbon firmware. --- R64 FIRMWARE NEW FUNCTIONALITY --- --- R3 FIRMWARE NEW FUNCTIONALITY --- --- RAVEN FIRMWARE NEW FUNCTIONALITY --- --- ROAD RUNNER FIRMWARE NEW FUNCTIONALITY --- --- SDK CORRECTIONS --- * The installer no longer effects IEEE 1394 devices that are installed on the target computer. --- NEON FIRMWARE CORRECTIONS --- --- KARBON FIRMWARE CORRECTIONS --- --- R64 FIRMWARE CORRECTIONS --- --- R3 FIRMWARE CORRECTIONS --- --- RAVEN FIRMWARE CORRECTIONS --- --- ROAD RUNNER FIRMWARE CORRECTIONS --- Version 4.905 - 2007-05-15 - Build 203 --- SDK NEW FUNCTIONALITY --- * Beta release for the new Karbon product line. * Beta release to support the new Neon product line. * This release now ships will libraries and project files for Microsoft Visual Studio 2005. We strongly recommend using this compiler on all BitFlow applications. You must use this version of the compiler to build 64-bit applications. * 64-bit support is now offered for the PLDA based frame grabbers (Karbon and Neon). * The 64-bit version of this release ONLY supports 64-bit frame grabbers (R64, R64e, Karbon and Neon). 64-bit OS support for 32-bit boards (Road Runner/R3/Raven) will not be offered. * CamEd now supports PoCL cameras. --- API CHANGES --- * The following functions are new * The following functions have been depreciated and support will be dropped in the next release * The following functions are no longer supported R2DLL R2RC R2CAPI R2AqDispCleanUp(RdRn Board); R2DLL R2RC R2CAPI R2AqDispSetup(RdRn Board, RQTabHeadPtr pDispQTab, BFU32 DestType, BFU8 QuadBank, BFBOOL FirstBank); R2RC R2CAPI R2PhysQTabWritePart(RdRn Board, RQTabHeadPtr pRelQTabHead, BFU32 Offset, PBFU32 StartQuadNum, BFU32 NumToWrite); BFDLL BFRC BFCAPI CiPhysQTabWritePart(Bd Board, RQTabHeadPtr pRelQTabHead, BFU32 Offset, PBFU32 StartQuadNum, BFU32 NumToWrite); RVDLL RVRC RVCAPI RvPhysQTabWritePart(Raven Board, RQTabHeadPtr pRelQTabHead, BFU32 Offset, PBFU32 StartQuadNum, BFU32 NumToWrite); --- R64 FIRMWARE NEW FUNCTIONALITY --- * Many fixes to the "DCC.fsh" firmware that effection acquisition in start/stop mode. This includes accuract VCOUNT (when LAL=1) read back in all situations. All correct handling of software trigger assert and de-assert. A problem seen in Luggage mode has been corrected. --- R3 FIRMWARE NEW FUNCTIONALITY --- --- RAVEN FIRMWARE NEW FUNCTIONALITY --- --- ROAD RUNNER FIRMWARE NEW FUNCTIONALITY --- --- SDK CORRECTIONS --- * Fixed problem causing SysReg to crash when MRU cams in registry gets corrupted. * Fixed problem in 64-bit OS version where negative stride did not work * Corrected issue in function CiHTrigModeGet when used with R64 * Increased the maximum number of display surfaces available per process from 5 to 25 * Updated support for newer camera tap formats in R64AqFrameSize * Fixed problem in driver where AqSetup would fail on very large images on 64-bit OSs. This was caused by incorrect calculation of maximum buffer size that could be covered by a single MDL. THe maximum size is much smaller on 64-bit OSs. * The Camera Link serial communications middleware, "clallserial.dll", is now install and working correctly on 64-bit operating systems. --- R64 FIRMWARE CORRECTIONS --- --- R3 FIRMWARE CORRECTIONS --- * When acquiring the full bit depth from some 10 and 12 bit cameras, extra pixels were acquired on the end of each line (causing images to looked skewed). This has been corrected. --- RAVEN FIRMWARE CORRECTIONS --- --- ROAD RUNNER FIRMWARE CORRECTIONS --- Version 4.80 - 2006-06-28 --- SDK NEW FUNCTIONALITY --- * Beta release for 64-bit operating systems * This release only supports BitFlow's 64-bit boards (R64, R64e). The final release may or may not support our 32-bit boards. * The following API functions have changed to support 64-bit operatings systems and associated security changes (the new prototypes are listed below): BFDLL BFRC BFCAPI BFStructItemGet(Bd Board, PBFCNF pBase, BFU32 ID, BFU32 Indx, PBFVOID pVal1, PBFVOID pVal2, PBFU32 pDisp, BFSIZET DestSize, PBFSIZET pASize); BFDLL BFRC BFCAPI BFStructItemSet(Bd Board, PBFCNF pBase, BFU32 ID, BFU32 Indx, PBFVOID pVal1, PBFVOID pVal2, BFSIZET SourceSize); BFDLL BFRC BFCAPI BFGetBoardStrings(BFU32 DeviceId, BFU32 Revision, BFU32 InfoHi, BFU32 InfoLo, BFU32 SubVendorId, PBFCHAR pModelSt, BFU32 ModelStLen, PBFCHAR pFamilySt, BFU32 FamilyStLen, PBFU32 pFamilyIndex, PBFU32 pCiFamily); BFDLL BFBOOL BFCAPI DisplayErrorDialog(BFS32 ErrorCode, PBFCHAR ErrorSource, BFU32 ErrorLine, PBFCHAR ErrorMess, PBFUPTR pDisposition); BFDLL BFUPTR BFCAPI DoBrdOpenDialog(BFU32 Options, BFU32 FamilyFilter, PBFU32 pFamily, PBFU32 pBrdNum, PBFU32 pDoInit,PBFU32 pSerPortNum); BFDLL BFBOOL BFCAPI WaitDialogOpen(PBFCHAR Msg, HWND *pHandle); BFDLL BFBOOL BFCAPI WaitDialogClose(HWND Handle); BFDLL BFBOOL BFCAPI DisplayQuestionDialog(PBFCHAR Question,PBFCHAR Answer,BFSIZET AnswerSize); BFDLL BFU32 BFCAPI BFIOSaveDlg(BFBOOL SingleFrame, char* FileName, BFSIZET FileNameSize); BFDLL BFU32 BFCAPI BFIOOpenDlg(char* FileName, BFSIZET FileNameSize); BIDLL BIRC BICAPI BiDiskBufWrite(Bd Board, PBIBA pBufArray, BFU32 FirstBufNumber, BFU32 NumBufs, PBFCHAR FileName, BFSIZET FileNameSize, BFU32 Options); * There have been some small changes to some little used type defines. Please see the file "BFDef.h" for the latest type definitions. --- R64 FIRMWARE NEW FUNCTIONALITY --- --- R3 FIRMWARE NEW FUNCTIONALITY --- --- RAVEN FIRMWARE NEW FUNCTIONALITY --- --- ROAD RUNNER FIRMWARE NEW FUNCTIONALITY --- --- SDK CORRECTIONS --- --- R64 FIRMWARE CORRECTIONS --- --- R3 FIRMWARE CORRECTIONS --- --- RAVEN FIRMWARE CORRECTIONS --- --- ROAD RUNNER FIRMWARE CORRECTIONS --- Version 4.50 - 2005-09-01 --- SDK NEW FUNCTIONALITY --- * This release supports the new R64e board. * The driver in this release has an improved plug and play architecture. This should help with compatibility problems on some systems. * There is a new C++ class that encapsulates the BufIn API (Bi functions). Anybody familiar with C++ and who wants to use the SDK's highest and simplest to use API should use this class. Documentation can be found on Installation CD-ROM as well as on BitFlow's web site. The examples Circ, BiFlow and CircClassExample are all built on top of this class. * This release is fully compatible with the Camera Link API specification 1.1. * This release includes a new utility, R64PortSwitch, that lets the user switch which CL connector is connected to the UART on the R64 boards. THe R64 has two CL connectors. The dual mode boards these two connectors are designed to be used with two cameras. There is only one UART for serial communications no the board. The UART can be connected to either of the two CL connectors, but only one at a time. By running R64PortSwitch, the user can change which CL connector is active. BFCom already provides this facility, but other 3rd part Camera Control applications do not. R64PortSwitch can be run simultaneously with a camera control application, letting the user program each camera in turn. R64PortSwitch also includes two "lights" that indicate when data is be sent or received. * The BufIn Circular acquisition functions now support adding buffers to a "hold" list on the fly. Buffers on the hold list will not be acquired into, and their contents will remain untouched. This allows applications time do off-line processing of certain buffers. When the off-line process is complete the buffer can be return to the normal list of buffers used for acquisition. See the on-line SDK documentation for more information. * Starting with this release, all board specific applications (e.g. R2View, RvView, R2Bench) will not be installed, either in executable format or in source code form. All installed applications will be built either on the Ci API or the Bi API. There is at least one Ci or Bi example that has the same functionality and features as any of the old example applications. The Bi and Ci APIs work with all of our current boards and future boards. It is good practice to use them, as it will keep your application compatible with future hardware product releases from BitFlow. In the future, BitFlow may drop support for the board specific APIs (R2 API, Rv API, etc.). * The BFD library now supports a high-resolution time stamp function. * The BufIn (Bid.dll) allows the user to make use of the high-resolution time stamp. * The camera configuration file format has been slightly modified to handle the larger line sizes the R64 is capable of acquiring. Previously camera files could only be made handle line sizes of up to 32K (pixels) with taps each no farther than 32K from and other tap. This limited has been extended to handle line sizes of up 256K and each tap can up to 256K from any other tap. This new functionality is available for the R64, R3 and Road Runners. * CamEd now displays the current acquisition frame rate in the title of the display window. * Added the following functions for controlling the encoder (horizontal trigger) * CiView now displays the camera's frame rate in the main windows information bar. * VerCheck now has more debugging information. * BayView now has a software trigger facility. * BayView now supports 10 and 12 bit Bayer camera when used with the R64 IP2 version (hardware bayer decoder). * Circ now has a software trigger facility, along with the ability to save image on the fly and the ability to turn the displaying of image to the screen on and off. * This release uses Setup Factory Version 7.0, which has many improvements, is faster, and is much smaller in size. * The executables in the release were built with Microsoft Visual Studio .NET 2003. This is essential version 7.0 of the Microsoft compiler. All examples included with this SDK will build with any version of Microsoft’s compiler from version 6.00 up. Project files are included for Microsoft Visual C++ version 6.00, however these can be opened all later version of the Microsoft C++ environments. * The OEM install tools have been removed from this release. The reason is that the installer now supports silent (i.e. no user interaction required) installation of the binary components of this SDK (for more information see the next item). An OEM's installer can call our SDK installer in silent mode. This will install all of the components necessary for an OEM application to run on the target computer. * Support had been added for silent installation and un-installation. The silent uninstall will only install the binary components. In other words, will install the same components that are installed when the regular installer is run with the serial number 0. To run the installer in silent mode, add the "/S" parameter on the command line. For example: BitFlowSDk450.exe /S Note that this may display a dialog at the end of the installation which tell the user they must reboot the computer before they can use the BitFlow driver. If you do not want this dialog to be displayed, you can use the NOREBOOTMSG parameter. The syntax is: BitFlowSDk450.exe /S /NOREBOOTMSG Note that in either case the system must still be reboot before the BitFlow drivers can be used. To run the installer in silent mode, again use the "/S" parameter. For example: C:\WINDOWS\SDK\uninstall.exe /U:"C:\BitFlow SDK 4.50\Uninstall\irunin.xml" /S The executable "uninstall.exe" is the uninstaller program and is copied into the windows folder when the installer is first run. * The following functions have been added. See the latest SDK manual for more information (available at www.bitflow.com). BFDLL BFRC BFCAPI CiConHTrigModeSet(Bd Board, BFU32 EncMode, BFU32 EncPolarity, BFU32 EncSelect); BFDLL BFRC BFCAPI CiConHTrigModeGet(Bd Board,PBFU32 EncMode, PBFU32 EncPolarity, PBFU32 EncSelect); BFDLL BFU32 BFCAPI BFHiResTimeStampInit(PBFTime pStartTime); BFDLL BFU32 BFCAPI BFHiResTimeStamp(BFTime StartTime, PBFTime pCurTime); BIDLL BIRC BICAPI BiBufferClear(Bd Board, PBIBA pBufArray); BIDLL BIRC BICAPI BiCirBufferStatusSet(Bd Board, PBIBA pBufArray, BFU32 BufferNumber, BFU32 Status); BIDLL BIRC BICAPI BiCirBufferStatusGet(Bd Board, PBIBA pBufArray, BFU32 BufferNumber, PBFU32 Status); BIDLL BIRC BICAPI BiErrorTextGet(Bd Board, BIRC ErrorNum, PBFCHAR ErrorText, PBFU32 ErrorTextSize); BIDLL BIRC BICAPI BiErrorList(); BFDLL BFRC BFCAPI CiAqROISet(Bd Board, BFU32 XOffset, BFU32 YOffset, BFU32 XSize, BFU32 YSize, BFU32 AqEngine); BFDLL BOOL BFCAPI DispSurfFormatBlit(BFS32 DspSurfHandle, PBFU32 pBuffer, BFU32 PixDepth, BFU32 options); R2DLL R2RC R2CAPI R2AqROISet(RdRn Board, BFU32 XSize, BFU32 YSize, BFU32 XOffset, BFU32 YOffset); R2DLL R2RC R2CAPI R2ConGPOutSet(RdRn Board, BFU32 Mask, BFU32 Value); R2DLL R2RC R2CAPI R2ConGPOutGet(RdRn Board, PBFU32 Value); R2DLL R2RC R2CAPI R2ConHTrigModeSet(RdRn Board, BFU32 EncMode, BFU32 EncPolarity, BFU32 EncSelect); R2DLL R2RC R2CAPI R2ConHTrigModeGet(RdRn Board, PBFU32 EncMode, PBFU32 EncPolarity, PBFU32 EncSelect); R64DLL R64RC R64CAPI R64AqROISet(R64 Board, BFU32 XOffset, BFU32 YOffset, BFU32 XSize, BFU32 YSize); R64DLL R64RC R64CAPI R64ConGPOutGet(R64 Board, PBFU32 Value); R64DLL R64RC R64CAPI R64LutPoke(R64 Board, BFU8 Mode, BFU8 Bank, BFU8 Lane, BFU32 Addr, BFU32 Value); - requires special firmware R64DLL BFU32 R64CAPI R64LutPeek(R64 Board, BFU8 Mode, BFU8 Bank, BFU8 Lane, BFU32 Addr); - requires special firmware R64DLL R64RC R64CAPI R64ConHTrigModeSet(R64 Board, BFU32 EncMode, BFU32 EncPolarity, BFU32 EncSelect); R64DLL R64RC R64CAPI R64ConHTrigModeGet(R64 Board, PBFU32 EncMode, PBFU32 EncPolarity, PBFU32 EncSelect); RVDLL RVRC RVCAPI RvAqROISet(Raven Board, BFU32 XOffset, BFU32 YOffset, BFU32 XSize, BFU32 YSize, BFU32 AqEngine); RVDLL RVRC RVCAPI RvConGPOutSet(Raven Board, BFU32 Mask, BFU32 Value); RVDLL RVRC RVCAPI RvConGPOutGet(Raven Board, PBFU32 Value); * The function DoBrdOpenDialog has changed. The prototype is as follows: BFU32 BFCAPI DoBrdOpenDialog(BFU32 Options, BFU32 FamilyFilter, PBFU32 pFamily, PBFU32 pBrdNum, PBFU32 pDoInit, PBFU32 pSerPortNum) Note that the only change is the function type. This function will not return one of the following values: BRD_DLG_OK - A board was selected and the user clicked the Init or Just open button, or there is only one board installed and the dialog was not displayed. BRD_DLG_NO_BOARDS - There are no boards installed in the system. BRD_DLG_USER_CANCEL - The user clicked the Cancel button (this define is backwards compatible with the old return value of IDCANCEL). BRD_DLG_MALLOC_ERROR - There was an error allocating resouces for the dialog BRD_DLG_DRIVER_ERROR - There was an error communicating with the driver BRD_DLG_OTHER_ERROR - There was an internal error creating the dialog * BiBufferAssign assign previously did not allow the user to allocate non-sequential buffers in memory. The requirement for sequential buffers has been removed from this function. --- R64 FIRMWARE NEW FUNCTIONALITY --- --- R3 FIRMWARE NEW FUNCTIONALITY --- * A new bit has been added, FEN_IS_TRIG (CON8[8]). When this bit is set to one, the FVAL (FEN) signal coming into the board on the CL connector is internally routed to TRIGGERA. The reason is so that the FVAL signal can act as a trigger when using a line scan Camera Link Camera. * A new bit has been added, FEN_SIZE (CON8[14]). When this bit is set the board uses the FEN signal as the VAW. In this mode, the CTabs are not use to control the VAW, and can run independently. This mode allows for overlapping of acquisition and exposure when in one-shot mode (for cameras that support this mode). --- RAVEN FIRMWARE NEW FUNCTIONALITY --- --- ROAD RUNNER FIRMWARE NEW FUNCTIONALITY --- --- SDK CORRECTIONS --- * SysReg now checks if the driver is started and if the driver is the correct version before display the main dialog. If these tests fail and error dialog is displayed. Previous version simply did not run. * CamEd reported errors when editing a Camera Link camera file. This has been corrected. * SysReg would crash if too many camera files were attached to one board. The code has been modified so that an error message is dislpayed when this situation occurs, and the list will automatically be truncated to an acceptable size. Also the total number of camera files that can be attached has been increased. * In some siturations (usually when the frame size was very small and the amount of memory allocated was large) applications like BiFlow would crash. This situation has been corrected. * BFCom could hang, and the system could become unresponsive, under the following conditions: 1. BFCom is run but not data are sent or recieved, 2. CiView or other BitFlow application is opened for the same board as BFCom is opened for, 3. The system has a single non Hyperthreaded CPU. This anomolly has been corrected. --- R64 FIRMWARE CORRECTIONS --- * A correction has been made so that the CTAB columns output the correct values (i.e. the values they have at location 0) when VCOUNT = 0. The only exception is VSTART which is a hidden state that faciliates not losing lines between frames (i.e. VSTART can be at 0, when VCOUNT=0 and the board is not yet in the VAW, until the trigger comes in, this is needed for luggage mode). * A correction has been made so that when VCNT_RST=3 (i.e. reset VCOUNT on FEN assert). The board now correctly acquires in thsi mode. * In some cases, the Vertical CTab counter would go beyond the point that it should have been reset, this anomoly has been corrected. * The Loss Of Sync (LOW) detection system has been improved. Previously the LOS system issues an interrupt as soon as the LOS condition was detected. This caused problem with the software as it tried to reset and restart the board as soon as the interrupt occurred. The new firmware now issues the LOS interrupt (shows up as the HW interrupt) only when the frame is complete. This method delays the interrupt until such time as the software can correct for the situation. --- R3 FIRMWARE CORRECTIONS --- * R3C-PCI-13 and R3C-PCI-23, start stop mode did not work correctly with either software or hardware triggering. This has been corrected. --- RAVEN FIRMWARE CORRECTIONS --- --- ROAD RUNNER FIRMWARE CORRECTIONS --- Version 4.030 * This is release is a wrap up of all the changes required to fully support the new R64e product. Version 4.023 * Modified the R64 initialization code to program the QL's Prefetch bits, this improves DMA performance. Version 4.022 * Modified the R64 initialization code to program the QL's MAX_RETRIES bit, needed for newer motherboards. Version 4.021 * Update the Camera Link API, implemented the functions clFlushPort and clGetNumBytesAvail. Version 4.020 * Update the Camera Link API to be compliant with the Camera Link Specification Version 1.1 * Fixes to VerCheck, now shows correct range of DLLs Version 4.016 * Added functions to support 32-bit boards on operating system running in PAE mode. These new function provide that ability to allocate memory that will be accessible to 32-bit DMA devices. Essentially this means the the memory will be allocated below four gigabytes. The two new functions are: BFDLL PBFVOID BFCAPI BFmallocBelow4G(Bd Board, size_t Size); Allocates memory of the give size that will be acessable to 32-bit boards. The memory is allocated below four gigabytes. The memory must be freed with the function BFfreeBelow4G. BFDLL BFRC BFCAPI BFfreeBelow4G(Bd Board, PBFVOID pBuf); Frees memory that has been allocated by the function BFmallocBelow4G. Version 4.015 * Fixed VTap support that was broken in 4.014 Version 4.014 * Added support for the R64 boards running on operating systems in PAE mode (36-bit addressing) Version 4.013 * Bumped the priority of the Circular working thread in BufIn to THREAD_PRIORITY_HIGHEST Version 4.012 * Support for the IP2 image processing board. * BayView has been update to work with the IP2 board running Bayer decoder software. * Registers have been added to CON21 which control the Bayer decoder algorithm. Version 4.011 * On some systems acquiring while receiving large amounts of data on the serial port could the driver to stop responding to interrupts. This would result in acquisition timing out and/or loss of serial data. This problem has been corrected by changing how the driver connects to the operating system interrupts. * clSerialRead would lose characters when called with a short buffers size and high data rate. This problem has been corrected. * Both clSerialRead and clBFSerialRead could return with number of characters read = 0. This occured when reading characters at a high data rate. This has been corrected. * The firmware "Mux_4TS.fsh" has been updated. * The firmware "R3Mux24_T2T3.fsh" has been added. * The document "MucCodes.pdf" has been updated. * Poking the RST_HVCOUNT on the R64 could occasionally cause the VCOUNT register to not function correctly. This has been corrected. Version 4.009 * Fixed problem in "clSerBitFlow.dll" which cause it do function incorrectly on the R64. * Installer now installs on Windows Server 2003. * Some firmware upgrades. Version 4.008 * Fixed bug in function R2AqConAq mode when used with 30 bit cameras, TG1AQW was being incorrectly programmed * BiFlow did not correctly determine the display pixel depth when used with a 30 bit camera, this has been corrected Version 4.007 * Replaced incorrect firmware file added in 4.006 Version 4.006 * Fixed low probability race condition which could cause an interrupt to be delayed at the user level. This problem would only occur on SMP computers, when the board was emitting more than one interrupt and when the interrupts came very close together in time (but not concurrent). The solutions was to synchronize the IntComplete and SignalHandler functions in the kernel. Also the DPC function is always scheduled, even it there is no SignalWaiting. * Fixed a problem intruduced in 4.005 when we added support for 10 tap camera acquired into the DPM and interleaved 4K boundaries. The problem was the the size of the VQTabHead and the RQTabHead were no longer equivialent. The solution was to delete the old RQTabHead structure and use the new VQTabHead structure in all code, even when using Relative QTabs. The VQTabHead structure was update to provide a pointer to RQuads as well as VQuads. Version 4.005 * Modification to how kernel driver claims the board's interrupt. This improves compatibility on some systems. * Added support for DPM memory interleaving on 4K boundaries. This is mainly need to support cameras with long lines and many taps (e.g. 10 taps) * Added function to QTAB dialog to help search for interrupt quads. * Fixed bug in CamVert that restricted the maximum number of QTAB model parameters to 9. The upper limit is now 10. Version 4.004 * Modifcations to BufIn and associated example to support 36,42 and 48 bit color Version 4.003 * CamEd modified to support 36, 42 and 48 bit color for R64. Version 4.002 * "R64D.dll" modified to support 30, 36, 42 and 48-bit color cameras Version 4.001 * CamEd showing errors on some CL camera files, this has been corrected. Version 4.00 - 2003-04-15 --- SDK ENHANCEMENTS AND IMPROVEMENTS --- * First release to support the R64. * Firmware for the R64 is automatically select and downloaded based on the attached camera configuration file. There is no need to run SysReg for the R64 in order to change between various firmware options. * The firmware file "bitflow.gat" has grown excessively large with the addition of the R64. To eliminate this problem, the single firmware file has been broken down into separate flash files, one for each component on the board. The files are stored in the "BitFlowFlash" folder under the drivers folder. All other operations with the firmware, from the users point of view, remain the same. However, when building systems that use the BitFlow SDK care must be taken to install the "BitFlowFlash" folder on the target computers. This is a change from previous version where only the "bitflow.gat" file need to be installed. * The camera files are now sorted into separate folder for each configuration type. To keep backwards compatibility with existing installations, if the API can not find the camera file in the appropriate subfolder, the root configuration folder is also searched. CamVert and SysReg, however, will default to looking in the correct subfolder. * The kernel driver in this release has been reworked to improve system stability in the event of an application crashing. In the previous release if an application crashed while a board was DMAing, there was a chance the entire system would be taken down (BSOD). Improvements to this version have made the kernel robust enough so that applications crashes will not cause system crashes. * BayView has been completely re-written. The application can now open 8-bit grey images from disk and convert them to color using the same color correction parameters and algorithms as are used for the live Bayer display. The application is now more Windows compliant in how it handles document windows. It works similar to R2View and RvView. There is a live preview for the Bayer processed images. These images can be captured to the MDI window and save to disk. Color correction work on both the live display as well as the MDI documents. Once a document's image has been successfully color corrected, it can be locked, to prevent further color correction. The application only reads in 8 bit images, and only writes out 32 bit color images. Finally, the application is now built on the BufIn API, and works for all products. * New applications: CiBench - PCI bus bandwidth benchmark, works with all boards. Display min and max data rates. CiView - Generic video viewer, works with all boards. BiProcess - Generic continuous process applications. Works with all boards. Based on the BufIn API. Demonstrates similar functionality to PingPong and RvProcess. R64Simple - simple console based application demonstrating the R64 API. DiskIOSimple.exe - Example console application demonstrating the new disk IO functions. * The following applications have been updated to support the R64: BiFlow Circ BFCom The Ci API The Buffin API The Camera Link Serial API SysReg CamVert CamEd BayView BFTest PCIWalk * An new API was added for reading and writing images to and from disk. * The installer now automatically installs the "bitflow.inf" file. This INF file tells the operating system about the BitFlow camera interfaces. Thus when a system is first boot after a new BitFlow board is installed, the New Hardware Found Wizard will automatically now about BitFlow Camera Interfaces. There is now way to prevent the New Hardware Wizard from popping up when a new board is put in the system. However, with this release, the Wizard does not have to be directed to the location of the "bitflow.inf" file. The Wizard can now be running using the default actions, and the BitFlow system will be correctly configured. * Bufin's disk IO functions parameters have changed to char* from char [80]. * Bufin's disk IO functions were updated using the new BFIO calls. Refer to the Bufin user manual for new return values. * Reading raw data formats are no longer supported by the Bufin API. The user must know the XSize, YSize and bit depth in order to read in raw data. * Added new WriteSimple.c and ReadSimple.c to demonstrate the usage of the BFDiskIO library. * The display surface has been updated to be consistent with the bitmap format. With this change saving to a bitmap, displaying in a bitmap and displaying in a display surface all have the same format. What this means for developers is that there is no longer the need to use a negative stride in the AqSetup function. And there is no need to invert the image data before displaying and/or saving. NOTE: because of this change, existing applications may need to be updated to view the image right side up. * CamEd New features - Support added for Make/Model/Mode fields on CL boards and Name field on differential boards. Support added for Comment field on all models. Support for packed 24 bit data camera files. * The names of some constants have been changed for clarity. The following list shows the old and new names. The old names will still work. However, it is recommend that the new names are used whenever possible. Old name = new name BFIntTypeQuadDone = BFIntTypeEOD R2IntTypeQuadDone = R2IntTypeEOD RvIntTypeQuadDone = RvIntTypeEOD * VerCheck now reports more detailed information and the output can be save to a text file. * The following functions have been renames in order to make their use more obvious. These functions are not documented and are usually only used by internel functions. CiRegRMW -> CiRegIndxRMW CiRegSupported ->CiRegIndxSupported CiRegName -> CiRegIndxName CiRegFlags -> CiRegIndxFlags CiRegShift -> CiRegIndxShift CiRegMask -> CiRegIndxMask CiRegObjectId-> CiRegIndxObjectId CiRegPoke -> CiRegIndxPoke CiRegPeek -> CiRegIndxPeek --- BFCom Improvements --- * The application has been completely re-written at the lowest level to improve interactive performance. * The text interface now supports full scrolling and panning. Lines can be as wide as 1024 characters. Number of lines is limited only by PC memory. * The current session can be saved to a text file. * Normally BFCom sends a CR when the user ends the line by hitting the Enter key. Certain cameras, however, require a CR LF sequence at the end of a line. The new version has an option to automatically append the LF to the CR at end of every line. * All commands entered by the user are saved in a stack. The commands can be recalled by using the up and down arrow keys. This facility works much like the command line in a DOS box or console window. --- The Serial DLL, "clserbitflow.dll", Improvements ---- * The function clSerialRead has been re-written. The specification for this function could be interpreted more than one way. The function has be rewritten to follow the interpretation that will be used in the forth coming revision 2 specification. The old function returned when any of the three following conditions were met: when the UART buffer was empty, when the host buffer was full or when the time out period had expired. The new function returns when any of the two following conditions were met: when the host buffer was full or when the time out period had expired. * Changes to the DLL have been made to support the new revision specification. When it is finally ratified, the DLL can be easily and quickly updated to support this new specification. --- FIRMWARE ENHANCEMENTS - R3 --- * This firmware supports reversing the output from cameras that have mirrored taps. Up to 16-bit pixels are supported. This mode is only needed on R3-PCI-CL models (differential models already have line reversing circuitry). This functionality requires other support files. Contact BitFlow for complete details. * The firmware "Special 8 bit camera modes" has been added to the list available for the R3-PCI-DIF. --- FIRMWARE ENHANCEMENTS - ROAD RUNNER --- * In continuous data mode (TRIGCON = 2), you can now have a data trigger and a data qualifier. Previously this mode always acquired data when TRIGGERA was asserted. However, if LENSIZE = 1, data is acquired only when both LEN and TRIGGERA are asserted. In this mode the TRIGGERA input can be used a general data trigger, and LEN can be used as a data valid signal or data qualifier. If LENSIZE = 0, the mode is the same as before. --- FIRMWARE ENHANCEMENTS - RAVEN --- * The FIPOL register now controls the polarity if the field signal when the system is in crystal mode. This is required for some cameras when they are being driver by the Raven. --- BUG FIXES - ALL PRODUCTS --- * In CamEd, changes to the pixel depth were not inserted back into the configuration file. This problem has been corrected. * On certain operating systems (Windows XP Embedded) the installer was overwriting some of the system DLLs with older versions. This has been corrected with this version of the installer. --- BUG FIXES - ROAD RUNNER --- * The number of QTAB model parameters was artificially limited to four for the Road Runner. This has been corrected and the current number of QTAB model parameters is now limited to 50. --- BUG FIXES - RAVEN --- --- BUG FIXES - R3 --- --- FIRMWARE UPDATES - ROAD RUNNER --- * When the serial port was being read at the same time the board was DMAing data, occasionally the board would emit a hardware exception interrupt. This anomaly has been corrected. * On the Camera Link version, MUXA = 3 (2x12 shifted down by 4 for display) did not work correctly. This problem has been corrected. * For R2-PCI-xx models, the board now acquires correctly from line scan cameras running at very low line rates. * For the Camera Link models when using an encoder, the board's line rate did not correspond to the encoder frequency. This has been corrected. * For Dif boards, under very specific set of LEN and PCLK timings, the board could would not acquire correctly. This has been corrected. * For CL boards, the encoder was not working correctly. This has been fixed. --- FIRMWARE UPDATES - RAVEN --- --- FIRMWARE UPDATES - R3 --- * When the serial port was being read at the same time the board was DMAing data, occasionally the board would emit a hardware exception interrupt. This anomaly has been corrected. * The trigger interrupt did not work correctly. This interrupt, which should occur when TRIGINT = 1, appears on the CTAB interrupt bit (and associated CTAB signal). The firmware has been modified to correct this problem. * For R3-PCI-CL13 models, acquisition now works correctly with odd/even 8-bit pixel cameras. This problem also affected 10-bit and 12-bit single tap cameras. * For R3-PCI-DIF models, the board now correctly handles downshifting 12-bit pixels for 8-bit display. * For the Camera Link models when using an encoder, the board's line rate did not correspond to the encoder frequency. This has been corrected. * For CL boards, the system could hang when the accessing the serial port on a board in a 64 bit PCI slot. This anomaly has been corrected. * For all boards, system could change when board was plugged into a 64-bit PCI slot. This has been fixed. * For CL boards, the encoder input did not work correctly. This has been fixed. * Under certain circumstances, the board would emit a random hardware exception interrupt. This has been corrected. * For Dif boards, the trigger interrupt did not work as documented. This has been fixed and now works like the Road Runner. * For Dif boards, under certain circumstances the trigger interrupt would occur continuously. This has been corrected. * For all boards, when running a line scan camera at very low line rate, the board would occasionally lose sync. This has been fixed. * For Dif boards, when the force abort bit was set, a hardware exception interrupt would be emitted. This has been corrected. * For Dif boards, when TRIGPOL = 1, VSTOP = 1, TRIGON = 0, the board did not trigger correctly. This has been corrected. * For Dif boards, under very specific set of LEN and PCLK timings, the board could would not acquire correctly. This has been corrected. * For Dif boards, at very high line rates with very short HB, the board occasionally emitted a hardware exception. This has been corrected. * For all boards, the LEN is size functionality did not work correctly. This has been fixed. * For CL boards, register on some boards would read back incorrectly for a short time after initialization. This anomoly has be corrected. * For CL boards, the HCTAB_X16 bit (HCTAB Counter increments every 16 pixel clocks) was not functioning. This has been corrected. * For R3-PCI-DIF boards, if the HSTICK bit is set and HCOUNT reached the stick point, when LEN asserted HCOUNT would "miss" one HCTAB location. This has been corrected. --- NEW REGISTERS - R3/ROAD RUNNER --- CON5 14 TRIG_FILTER - filters electrical spikes on trigger input, introduces small delay CON8 8 ENC_FILTER - filters electrical spikes on encoder input, introduces small delay --- NEW REGISTERS - R3/ROAD RUNNER CL--- CON4 14 FORCEABORT - allows DMA engine to abort if no data in FIFO CON10 [14..12] REG_HTRIM - trims horizontal timing with relation ship to LEN when passing data through the firmware stack. --- NEW REGISTERS - RAVEN --- Version 3.00 - 15 February 2002 --- SDK ENHANCEMENTS AND IMPROVEMENTS --- * This is the first SDK release that supports the new R3 boards. * This the first release of the new interactive camera configuration file editor CameEd. * This is the first release of the buffer management API, Buffin. For more documentation see the file Buffin Software Reference Manual. There are two new application built on top of this API: BiFlow and Circ. The application demonstrate the APIs capabilities in detail. There are also a number of console based applications show each component of Buffin in a simple example. The source code for all of these applications is included. * The Camera Link Terminal emulation application, BFCom, has been modified to work with cameras that do not support regular text commands. This application now has a hexadecimal and a decimal mode. This allows binary commands to be send and received from Camera Link cameras. Also, a programmable send delay has been added for cameras that cannot keep up with rapid sequential commands. Finally, the application settings are stored in the registry, for persistence between execution. * A new application, BayView, is now part of this release. This application displays color images from Bayer CCD based cameras. This application has been available previously from BitFlow, but has been completely overhauled for this release. There are now three different Bayer to RGB algorithms to choose from. The algorithms differ in the area of speed vs. quality. The nearest neighbor algorithm is the fastest but produces the lowest quality image. Continuous Hue produces the high quality image, but takes the longest to process. The color correction dialog is now more intuitive, and the auto color correct mode now works much better. * The serial port read function is now based on an interrupt from the boards UART (Camera Link boards only). This reduces the amount of CPU activity required when reading from the serial port. * This release contains the documentation for all the latest alternate MUX codes for the Road Runner and R3 products. Previously this information was in the hardware manuals. However, because this information is updated so often, it has been moved to a separate document, "C:\BitFlowSDK.XXX\Docs\MuxCodes.pdf". * All reliance Microsoft's MFC library has been removed from BitFlow's core DLLs. In previous releases "BFEr.dll" made calls to the DLL "MFC42.dll". This caused problems for some user in some environments. BitFlow's core DLLs now one use native Win32 calls. A side consequence of this is OEMs who redistribute the BitFlow DLL now no longer need to redistribute the Microsoft DLLs (unless their own application requires these components). Please note the almost all of the BitFlow applications, plus the display DLLs, still rely on the MFC DLLs. * This release contains the new User Manual, which describes how all of the BitFlow applications work in detail. * There have been some slight modification to the user interface part of most of the BitFlow applications. Some icons have been modified, Windows compliant "flat" buttons are now used through out, radio buttons are now all standardize, etc. * The sequence capture application, Flow, now has a preview mode. This functionality provides live video in the preview window without capture to the sequence buffers. This is useful for camera and lighting setup before sequence capture. * See also "NewSDKFunctions.txt" for new functions added this release. * This is the first release to require a serial number for installation. Serial numbers for new customers come with the SDK CD. Serial numbers for customers upgrading to the release must be obtained from BitFlow support. The installation will proceed with out a serial number (use 0), but only the binary components and drivers will be installed. This facilitates user who are using a third party application, or OEMs who wish to ship their application that is built with the BitFlow SDK. OEMs can use the same installer with the 0 serial number to install the redistributable components on customer computers. --- FIRMWARE ENHANCEMENTS - ROAD RUNNER --- * New firmware has been add for line scan camera that will allow exposure to overlap with readout when using a camera that has this ability. A new bit has been added, LEN_SIZE, that when set changes how the board reacts to the LEN signal. Ordinarily LEN cause the HCTAB counter to jump to 0x800, and the horizontal window is programmed at this point using HSTART and HEND. When LEN_SIZE = 1, the LEN signal has no effect on the HCTAB. In this case, the board begins acquiring pixels when LEN is asserted and stops when LEN is de-asserted. The HCTAB can then be used exclusively for controlling exposure based on an encoder signal. * Fixed a problem that caused erratic encoder behavior when HCTAB_X16 = 1. * The trigger delay circuitry now works with all trigger modes. Previously the delay only worked in start-stop mode (variable length image). * The FORCEABORT bit was added to all CL boards. --- FIRMWARE ENHANCEMENTS - RAVEN --- --- BUG FIXES - ALL PRODUCTS --- * Fixed a bug in CamVert when using the File > Attach Current File To Board menu command. This command did not would fail if "Hide file extensions for know file types" was enable in the Windows Explorer. This command now works regardless of this setting. * The function CiAqFrameSize would fail for certain common line scan camera (when VSTART segment 0 = 0). This function will now work for all basic camera types. --- BUG FIXES - ROAD RUNNER --- * When using a 10 bit or greater camera with the Road Runner CL, the software did not properly program the TGAQW register. This has been fixed. * SysReg could inadvertently exit when closing the Board Details dialog that was opened for a Road Runner CL board. This has been fixed. * CiAqFrameSize used with a Road Runner and R2AqFrameSize would not function correctly if the vertical active window in the CTABs started at location 0. This has been fixed. * The release version of "clserbitflow.dll" has a bug in the function clSerialSettings if you call it with stopBits = StopBits_2, in this case the function will return and error code. However, the UART will be successfully programmed and will still work correctly. This problem has been corrected. * The resource file was missing from the source code director for the DDrawSurf Project. This has been added to this release. * In previous version, the kernel level start stop reset code (SIP) did not function correctly when the Road Runner was in luggage mode (TRIG_FREE = 1). This has been fixed in this release. --- BUG FIXES - RAVEN --- --- NEW REGISTERS - ROAD RUNNER --- CON0 15 PROGFIFO - Used to program FIFOs on R3. CON1 23 FI_CON - Interlace field input control. CON3 0 VF_MRST - Master FIFO reset (only used at power up). 1 SEN - 2 FWSI - 3 LD_FIFO - Used to program FIFOs. 10 CLKDRVSEL - Clock output drivers (RS422/LVDS) only on R3. CON10 10 LEN_SIZE - Put board in LENSIZE mode, useful for decoupling camera control and acquisition. For example, exposure control can overlap readout. HCOUNT does not jump to 0x800 when LEN asserts. Pixels acquired whenever LEN is asserted. HSTART, HEND only used for resetting HCOUNT. --- NEW REGISTERS - ROAD RUNNER CL --- CON3 10 CLKDRVSEL - Clock output drivers (RS422/LVDS) only on R3. CON4 9 VFRESET - rename of old bit field VF_PRST. 15 FORCEABORT - allows the current DMA operation to be aborted, even when the FIFO is empty. CON6 14 RANDOM_FEN - Puts board in Random FEN mode. In this mode, when FEN asserts HCOUNT is reset to zero. --- NEW REGISTERS - RAVEN --- CON30 30 FIPOL - Polarity of interlaced field input. 31 SELFI - Select interlaced field source. ________________________________________________________________________ Version 2.50 - March 30, 2000 --- SDK ENHANCEMENTS AND IMPROVEMENTS --- * This is the first release to support the Road Runner Camera Link product. This release supports model 13,13-L,23 and 23-L. Because the Road Runner CL is very similar to the Road Runner, we have been able to take advantage of the existing Road Runner API. This API will work with both Road Runners and Road Runner CL boards. * This release includes support for the Camera Link DLL Serial Interface specification. This is a standard named DLL which contains a standard API for talking to the serial port on the Road Runner Camera Link product. We have enhanced this API by adding one function to modify the serial port settings. Please see "NewSDKFunctions.txt" for complete details. * New examples have been added to this release to demonstrate using the serial port on the Road Runner Camera Link board. * A HyperTerminal like applications is included with this release to allow simple and easy serial communications with cameras attached to Road Runner Camera Link boards. * The firmware file now contains individual version information for each component's firmware on all boards. Also, version information is retained for alternate firmware files for each component. This information is dumped to a text file when the system is booting. This information will greatly assist debugging firmware problems in the field. * New size changing functions have been introduced for all products. --- NEW FUNCTIONS --- BFDLL BFRC BFCAPI BFErrorDefaults(Bd Board); BFDLL BFBOOL BFCAPI BFIsCL(Bd Board); R2DLL R2RC R2CAPI R2AqFrameSize(RdRn Board,BFU32 XSize,BFU32 YSize); RVDLL RVRC RVCAPI RvAqFrameSize(Raven Board, BFU32 XSize, BFU32 YSize, BFU32 AqEngine); BFDLL BFRC BFCAPI CiAqLastLine(Bd Board, PBFU32 pCurLine, BFU32 AqEngine); BFDLL BFRC BFCAPI CiAqFrameSize(Bd Board, BFU32 XSize, BFU32 YSize, BFU32 AqEngine); Camera Link DLL Serial Interface API clSerialInit(unsigned long serialIndex, void** serialRefPtr); clSerialRead(void* serialRef, char* buffer, unsigned long* bufferSize,unsigned long serialTimeout); clSerialWrite(void* serialRef, char* buffer, unsigned long* bufferSize,unsigned long serialTimeout); clSerialSettings(void* serialRef, unsigned long baudRate,unsigned long dataBits,unsigned long parity,unsigned long stopBits); clSerialClose(void* serialRef); --- FIRMWARE ENHANCEMENTS - ROAD RUNNER --- * A new bit has been added, TRIGINT, that when set, changes to source of the CTAB interrupt from the IRQ column in the CTABs to the TRIGGERA input. When this bit is set, the CTAB interrupt occurs every time the TRIGGERA signal changes state (i.e. both rising and falling edges). You can find out which transition occurred by peeking the TRIGSTAT bit. If this bit is one then TRIGGERA went high, if it is zero then it went low. Both the TRIGSTAT register and this new trigger interrupt only work when the trigger is internally disabled on the board (i.e. when ENXTRIG = 0). If the trigger is enabled, it works as with previous releases. * TRIGSTAT now reflects that level of the trigger, regardless of whether the extern trigger input is enable or not (i.e. ENXTRIG = 0 or ENXTRIG = 1). In the previous release it only worked when the external trigger was disabled. However, the trigger interrupt, enable when TRIGINT = 1, only works when the external trigger is disabled (i.e. ENXTRIG = 0). * A new bit had been added, FENHRESET. When this bit is set, the horizontal CTAB counter is reset when FEN is asserted. Normally the assertion of FEN causes the vertical CTAB counter to load to 0x1000, the horizontal timing is unaffected. However, setting this bit will synchronize both the horizontal counter and the vertical counter (the horizontal counter will reset to zero and the vertical will load 0x1000). This new functionality is useful in situations where there is no LEN present. * The firmware "Special Amber Camera Mode" has been renamed "Special 16 bit infrared camera modes". Also the codes cont ian with these files now agrees with the codes in the manual. * The FI input bit on the main connector can now be used as a general purpose input. The level of this bit can be read from REG_FI_CON register. To read this bit REG_FISEL but be set to 0. The existing register FI, behaves as in previous releases. --- FIRMWARE ENHANCEMENTS - RAVEN --- * Four new registers have been added: HPERIOD - CON10[29..16] HLOW - CON11[29..16] VPERIOD - CON12[29..16] VLOW - CON13[29..16] These are only available when using the special firmware "Lbc_xy.ttf". This firmware implements a programmable generic XY generator. This generator can generate horizontal and vertical syncs of any frequency. The new registers above control the frequency duty cycle of both the HSYNC and VSYNC outputs. * The standard firmware for both RS170 and CCIR cameras now uses host based QTABs. In previous releases the standard firmware used board QTABs. --- BUG FIXES - ROAD RUNNER --- * A bug was introduced in the SDK v2.10 firmware that could occasionally cause an application to think it had acquired very small frames. This would only happen when the board was in start-stop mode (TRIGCON = 3, TRIGSTOPA = 1, VSTOP = 1) and if the application was sampling the VCOUNT register to examine the size of the current frame (when LAL = 1). This bug has been fixed. * A bug has been fixed in SysReg that would cause it to occasionally crash. The MRU list for camera configuration files was being corrupted. This problem has been corrected. * A bug that disabled the slider dialog in R2View has been fixed. * A bug that could occasionally prevent R2View from dieing when closed on SMP machines has been fixed. * The display surface window did not, by default, have a title. This has been fixed. --- BUG FIXES - RAVEN --- * Previous release had a problem when acquiring from line scan cameras at low pixel clock frequencies. The images would appear to lose horizontal synchronization. This problem has been fixed. * The example application "RvsimpleOneShot.c" used calls to the Road Runner DLL instead of the Raven DLL. This has been fixed. * A bug that could occasionally prevent RvView from dieing when closed on SMP machines has been fixed. ________________________________________________________________________ Version 2.10 - October 18, 2000 --- SDK ENHANCEMENTS AND IMPROVEMENTS --- * Newly introduced in this release is the ability to reset the DMA engine, when the board is in start-stop mode, in the kernel level interrupt service routine. This is best possible method of making sure the board is reset and setup for the next frame before the next trigger comes in. This new functionality uses is enable/disable with the two new functions R2ChainSIPEnable and R2ChainSIPDisable. This functionality only works in host QTAB mode, and only when the board is in start-stop mode. See the example Flow for usage. * The example program Flow.exe can now display images while capturing. In the Capture Settings dialog there is now a check box for display while capturing. Checking this box will cause the application to send the latest image to the display surface while it is capturing sequences to memory. Clearly, this extra copying of images will lower that maximum data rate that the application can capture, so there may be certain systems and cameras where the displaying of image while capturing causes the application to lose frames. The display thread does have a lower priority than the capture thread, but this does not guarantee that the capture thread will have the full bandwidth when displaying. * The firmware file BitFlow.gat is now located in the system drivers directory (usually c:\WinNT\System32\drivers). This file previously loaded from the configuration directory, was moved to be compliant with Windows 2000. * In SysReg the Board Dialog now has a Recent button. This button calls up a menu of most recently used camera configuration files. This menu can be used to attach configuration files rather than using Open File dialog. * On the Road Runner, when capturing from a line scan camera that has reverse read out taps, half lines were dropped, once per frame, when using continuous line capture mode. This was caused by the fact that the circuitry used to reversed the tap introduced a one line delay. This release fixes this problem. A special flag has been added to the QTAB model parameters (set in CamVert) that tells the system to build QTAB that do not drop the half line. In order to use this new flag, edit your file in CamVert. Then modify the QTAB parameters, for every tap that has the mirror flag checked, also check the continuous flag. NOTE 1: this flag should not be checked for one shot mode cameras configurations or for area scan cameras. NOTE 2: One side effect of this new method is that you must reset the acquisition system between acquisition commands. The acquisition is reset by calling R2AqCommand(,R2ConReset,,). This command must be called each time (except the first) before issuing a grab command (i.e. R2AqCommand(,R2ConGrab,,). NOTE 3: This technique is designed for continuous grabbing only, you cannot use the snap command. NOTE 4: When a freeze command is issued during grabbing, the last frame may not be completely DMAed. If you are waiting for a QuadDone signal, it may never occur as the FIFOs will not be complete emptied. This only effects the last frame after a freeze command. During the grab no data is last. --- NEW FUNCTIONS --- Please see the "NewSDKFunctions.txt" file for more details. Also the source code for all these functions is included in this release. The following list shows the major function groups: * BFDrvReady * R2ChainSIPEnable * R2ChainSIPDisable --- FIRMWARE ENHANCEMENTS - ROAD RUNNER --- * A new register has been added, TRIGSTAT, that indicates the level of the TRIGGERA input. If TRIGGERA is high, then this bit is a one, if TRIGGERA is low then this is a zero. This register only works when the trigger is not enabled (ENXTRIG = 0). * A new bit has been added to extend the size of the line that the Road Runner can handle. Previously the maximum line size was 32K pixels (actually 25% less if you are using a LEN signal). The new firmware implements a new mode where the maximum line size is 512K pixels (again less if you are using LEN). This new mode is enable by setting the new bit, HCTAB_X16 , to one. This should be done in the camera configuration file as the CTABs will also have to be modified for this new mode. --- FIRMWARE ENHANCEMENTS - RAVEN --- --- BUG FIXES - ROAD RUNNER --- * In the previous release, cameras that do not output a LEN signal when waiting for a trigger, would not work in one shot mode. This has been fixed by a firmware change. * In the 2.00 release, the TRIGPOL bit did not correctly invert the polarity of the trigger in start-stop mode. This has been fixed by a firmware change. * In the 2.00 release, luggage mode did not work correctly (TRIG_FREE = 1). The board would continue to acquire until the end of the frame instead of stopping immediately then the trigger de-asserted. This has been fixed by a firmware change. * R2Bench is not working on all boards. The application was updated to use BFSetHostQTabMode which correctly handled old and new model Road Runners. * DispSurf, palette menu function does not work in 24 and 32 bit mode. Solution: disable menu items if pix bit depth is not 8. * R2AqWaitDone sometimes returns prematurely because of "bounce" in the AQSTAT bits. Solution: Check AQSTAT twice. * Flow does not save sequential file to disk correctly, the file names do not end up being sequential.Solution: formatted string that creates file name to use leading 0's. * In Flow, playback of large images at default frame rates can hang application. Solution: Don't boost process and thread priority by default (users still can). * On some systems, a bug in the driver would cause the Road Runner, which was previous visible in SysReg, to no longer be available for the SDK to open. * In some foreign language versions of NT and versions of NT that used large fonts, the bit field names did not line up correctly in the Register dialog in CamVert. This has been fixed. * In flow, when using CAD6 decoding and a camera with greater than 8 bits, the application would crash. This has been fixed. * The OEM installation program Postboot, previously required a header file that was not part of the release. This header file is now included in the release. * The OEM installation program Postboot, would not run on some systems because it was run before the BitFlow driver was started. This has been fixed by calling the new function, BFDrvReady. This function forces the program to wait until the driver has started. * Camera with reverse readout out taps larger than 2048 pixels could crash the computer. * Fixed the function R2AqReengage. --- BUG FIXES - RAVEN --- * RvBench is not working with all model boards. Updated benchmark camera file by changing CON11 from using LM1881-0 sync source to Internal sync source. * Host QTAB mode did not work correctly in the previous release. This now works for all types of analog cameras. ________________________________________________________________________ Version 2.00 - April 27, 2000 --- SDK ENHANCEMENTS AND IMPROVEMENTS --- * This is the second release of the BitFlow SDK and fully supports both Road Runner and Ravens. From this release forward the Road Runner SDK will not be supported as separate product. The BitFlow SDK has all of the functionality of the Road Runner SDK plus much more. * This release introduces new firmware that allows the Road Runner and the Raven to use scatter/gather DMA tables (QTABs) that are located in the host memory (instead of being located on the board). The advantage to QTABs on the host is that there is virtually no limit to the size of images that can be DMAed. On boards QTABs limited the boards to a maximum image size of 32 megabytes. Images or image sequences greater than this could be DMAed, but the host CPU was required to update the QTABs on the fly. With host QTAB, scatter gather tables can be built as big as memory allows. This technique works both with very large image sizes or large sequences of images. This functionality is enable by calling the function BFQtabModeRequest(). The Road Runners firmware can handle both host and board QTABs in one chip. The Raven firmware cannot, therefore different firmware must be download for host and board QTABs (this is done in SysReg). Once host QTABs are enable, all other API calls that need to be made are the same as with previous releases. * This release contains a new set of functions for sequence capture that allows the user to chain together individual QTABs. Once a chain is built, the board can then automatically DMA the whole sequence directly to memory without any CPU intervention. These functions are demonstrated in the Flow application. * The common camera interface library (Ci) has been added. This allows developers to uses a single API to acquire data from both Road Runners and Raven. * This release contains a new application, called Flow, which will capture sequences of images to memory. Sequences are captured in real time, that is, every frame that camera puts out is capture to memory. This application works with both the Road Runner and the Raven. It can play back sequences to a display surface. It can save sequences to disk (in Raw, Bmp, or AVI). Complete source code is included. This version of Flow has been improved substantially from the pre-release versions. * CamVert has been modified so that camera configuration files can be modified without a Raven or Road Runner installed in the system. * PCI Walk will run without a Road Runner or Raven Installed. * Non - uniform QTABs can now be built for the Road Runner. This capability allows for acquisition from devices that have more than one line size. * The firmware file, BitFlow.gat, now contains its build date plus a comment field that contains release information. Both of these items are sent to the Event Viewer when ever the firmware is downloaded. * The Direct Draw display surface now support 16, 24, and 32 bit VGA color modes. However, the color mode must match the pixel bit depth of the current camera. * SysReg now has a browse button that can be used to pick the configuration file directory. * The display applications R2View and RvView now handles captured images differently. Each time an image is capture, and new document is created in the main application window. This technique make it very simple to capture multiple images. Also, when acquire variable size images, this technique allows each capture image to be the exact size of the captured image, instead of the maximum size set in the camera file. * The display surface has a menu to let the user change the display palette. An inverse palette is available, as well as a selection of pseudo color palettes. * For 10, 12, and 14 bit cameras, using special firmware, R2View provides as slider dialog that allows the user to select which 256 levels out of 1024, 2048, or 4096 possible levels are displayed. * CamVert now has a few new menu items, allowing the opening of currently attached camera for the Road Runner and the Raven. Another item attached the camera file currently being edited to the board. * A new application, RvBench, is now included. This application is similar R2bench, is performs a benchmark test of the computer maximum PCI throughput. * The software now supports the Road Runner Model 11. * The numerical value of the error returns has been changed. The defines for a particular function remain unchanged. For example R2_AQ_NOT_SETUP is still a possible return value from R2AqSetup, However, in this release is it defines as 16469, where as in release 1.20, it was defined as 604. * The function R2DmaSetup is no longer available. Its functionality now consists of a few separate function calls. This changes assists in handling the new host based QTABs cleanly. Please see the source code for R2AqSetup for example usage * If Model 11 is installed in the computer, R2AqSetup, will automatically set the NORLUTS bit correctly. * The driver will release all resources in the event of a crash of the user level application. This makes debug a Road Runner application that allocates big chunks of memory much easier. This is because if the application, even if image buffers are still locked down, the driver will unlock all buffers and free all resources when the application dies. * Both the function R2BrdOpen and RvBrdOpen take a Mode parameter. This parameter can be ORed ("|") with the new flag "BFSysNoOpenErrorMess". This will suppress all error pop-up dialogs that can occur in these functions. These two functions are the only ones in the SDK that will actually pop-up a error dialog. The reason for this is that when these functions fail, there is no board handle returned which could then be passed to the other functions to get the error information. Therefore, these functions normally pop-up an error dialog to report any problems. This is usually acceptable behavior because errors that occur in these function are catastrophic, and the application cannot proceed. This is contrasted with runtime errors, which are often handle by the calling application. However, in the event that the user wants all error pop-ups to be suppressed, this new flag is available. * New tools for OEM who need to install the BitFlow SDK on target system. See the OEM folder (Usually "BitFlowSDK.200\OEM"). * The function R2ConDMASetup has been remove. It has been replaced by the functions R2PhysQTabWrite,R2PhysQTabEngage and R2ConDMACommand in sequence. Please see the examples for new usage. This change was necessary in order to accommodate Host QTABs. NOTE: this change will only effect users who are calling low level functions. User calling the high level functions (e.g. R2AqSetup) are effected by this change. --- New Functions --- Please see the "NewSDKFunctions.txt" file for more details. Also the source code for all these functions is included in this release. The following list shows the major function groups: * QTAB engage functions * Host QTAB mode * QTAB chaining functions * R2LastLine * Common Camera Interface Library (Ci) --- FIRMWARE ENHANCEMENTS - ROAD RUNNER --- * Host QTABs * The VCOUNT register is now latched and protected from being updated during host reads. What this means is that the VCOUNT register can be read realizably at all times. Previously the register could read back incorrectly if it was read while it was being updated by the board. * New bit LAL, CON8[9], has been added. This bit changes the meaning of the VCOUNT register. When this bit is set to zero, the VCOUNT register reads as in previous versions. When this bit is set to 1, the VCOUNT register returns the value of VCOUNT when the VRESET occurred. In other words, in this mode, the VCOUNT register returns the maximum line number acquired during the last frame. While this is not very interesting for fixed size images, it is very useful for variable sized images. Previously the only way to get the size of a variable sized image was by examining the DMA engine, then walking the QTAB to find the corresponding destination address, then calculating the line number of that address. This new method is much quicker and more reliable. Also this method give the application considerably more time to read the VCOUNT register as it will hold the last active line value until the end of the next frame. The LAL register is R/W and can be used to toggle the meaning of the VCOUNT register at any time. * New bit TRIG_FREE, CON8[10], has been added. When this bit is set to one, and the board is in one shot mode (VSTOP = 1), and the vertical active window start at the beginning of the VCTAB (VSTART segment 0 = 0), the board will continue to acquire as long as the external trigger is asserted. Previously, the board would only acquire one frame when the trigger was asserted. Essentially this bit change the trigger input from edge triggered mode to level triggered mode. Please not that if this bit is set to zero, everything works as with previous releases. Please also note that this new mode only works when all the conditions mentioned above are met. Finally this mode also works in start-stop mode (TRIGCON = 3). * The method the board uses to determine the first active line has been changed slightly. This change only effects start-stop mode (TRIGCON = 3, TRIGASTOP = 1) and one shot mode (VSTOP = 1). Previously, in this mode the CTABS were set up so that the active region start when VCOUNT = 1 (i.e. VSTART, segment 0, = 1). With this new firmware, if active region starts when VCOUNT = 0, the first full line after the trigger asserts will be acquired. Previous firmware discarded the first line, because typically the trigger was not synchronous to the LEN. However, in the case where the trigger is guaranteed to occur synchronous to or between the lines, then the first line will now be acquired. There is no bit to enable this mode, the registers must be set as above, and the CTABs must be programmed so that the active vertical region starts at 0. * A trigger delay has been added to the board. This delay is programmable by the TRIG_DELAY register (CON9[9..0]). This register will delay any activity on the trigger input line by the programmed amount. The delay units are in terms of line times, however, in order to get an acceptable range, a multiplier is used. The delay amount (line times) = 8 x N + 3, where N is value programmed into TRIG_DELAY. This delay functionality is enable by setting the EN_TRIG_DELAY = 1 (this is also a new register). * The following registers, and their associated functionality are not longer available: DX,SX,DY and SY. These registers controlled the second timing generator, which has been of limited functionality. If this functionality is required for your application, previous firmware is still available. See SysReg->Configure->Configure->CTAB->Second Timing Generator (old ctab.ttf). * The timing generator no longer supports subsampling by 1:2, i.e. zoom by 1/2 (TG1AQW = 3). Again, this functionality is available through use of the previous firmware, see previous bullet. --- FIRMWARE ENHANCEMENTS - RAVEN --- * Dual acquisition engines. * Loss of sync interrupt now works. * The VSIZE register is now 16 bits. --- BUG FIXES - ROAD RUNNER --- * R2View now handles the situation where multiple camera files are attached to the board and images are captured from the camera 1,2,etc. * Road Runner model 11 compatibly problems have now been fixed, R2BrdOpen now correctly checks for Model 11 compatibility with the current camera file. --- BUG FIXES - RAVEN --- * SysReg now correctly handles very large numbers of Raven camera files. * In R2View and RvView, an error message now pops when trying to use the File->Open command. These applications do not read files from disk. ________________________________________________________________________ Version 1.263 - August 23, 1999 - Maintenance release --- SDK ENHANCEMENTS AND IMPROVEMENTS --- * Rebuilt all Libraries and DLLs from Microsoft Visual C++ 5.0 compatibility ________________________________________________________________________ Version 1.262 - July 29, 1999 - Maintenance release --- SDK ENHANCEMENTS AND IMPROVEMENTS --- * Fixed bug in function R2PhysQtabWritePart that did not work on multi-processor computers. ________________________________________________________________________ Version 1.261 - July 15, 1999 - Maintenance release --- SDK ENHANCEMENTS AND IMPROVEMENTS --- * This release contains the latest camera configuration files. * Two new functions, R2PhysQTabWritePart and RvPhysQTabWritePart, have been provided to facilitate controlled downloading of QTABs on the fly. * The driver will now support 8192 physical QTABs created and ready for use simultaneously. --- FIRMWARE ENHANCEMENTS - RAVEN --- * The Raven's EOC bit (in the quads) now work like on the Road Runner. * Some small tweaks have been added for capturing video from VCRs. * The VSIZE register is for line scan camera is now 14 bits ________________________________________________________________________ Version 1.26 - April 16, 1999 --- SDK ENHANCEMENTS AND IMPROVEMENTS --- * This is the first release of any SDK to support the Raven. * This is the first release of the BitFlow SDK, BitFlow's first multi product SDK. * SysReg, CamVert, PCIWalk, and VerCheck have all been revamped to handle both Road Runners and Ravens. * CamVert has File open command that opens the currently attach camera file. * Importing and Export text files is now more logical in CamVert. * CamVert now provides a register editor for DISPCON0 (this is the version of CON0 used for display). * The CTAB editor in CamVert now use HEND and VEND instead of HSTOP and VSTOP, this is consistent with the manual. --- FIRMWARE ENHANCEMENTS - ROAD RUNNER --- * A bug in the firmware that caused a loss of sync (often seen as a hardware exception interrupt) to occurred when using both QTABs banks, has been fixed. * In Start-Stop triggered mode (TRIGCON = 3, TRIGASTOP = 1) the TRIGPOL bit now works correctly and indicates whether TRIGGERA is asserted high or low. --- BUG FIXES - ROAD RUNNER --- * With some PCI chipsets, an error was put in the event log whenever the Road Runner SDK tried to set the DMA latency. This would happen whenever R2BrdOpen() was called. There is now a check box in SysReg that allows you to turn off the DMA latency write. * Calling R2CTabFill would some times corrupt the LUTs. This has now been fixed. * The TRIMP4 bit, implemented in a previous release, was missing from CamVert. * When the board is initialized, the CTx outputs are tristated until the initialization is complete. This reduces the chances that a camera will get "confused" by spurious signals on the CTx lines. ________________________________________________________________________ Version 1.21 - March 23, 1998 - Maintenance release --- SDK ENHANCEMENTS AND IMPROVEMENTS --- * The kernel driver has been modified to more efficiently allocate QTAB entries (scatter-gather entries). This means that DMAing of larger images can now be supported. Support of acquisition of up to two 16 megabyte images (in ping-pong mode) or one 32 megabyte image in single bank mode. * R2view now supports the new continuous data interrupt. --- FIRMWARE ENHANCEMENTS --- * When the board is in continuous data mode (see TRIGCON bits) the board now issues an interrupt on the following or rising edge (see CONTINTPOL bit) of the TriggerA input. The TRIGGERA input, in continuous data mode, tells the board to acquire on not acquire data, depending on its level. This new enhancement tells the board to send an interrupt (it appears as a CTAB interrupt) when the TRIGGERA input starts or stops the data. * New CONTINPOL bit, which will send an interrupt to the host on the following or rising edge of TRIGGERA when the board is in continuous data mode. If CONTINTPOL = 1, CTAB interrupt is asserted on falling edge of TRIGGERA, if CONTINTPOL = 0, CTAB interrupt is asserted on rising edge of TRIGGERA. --- BUG FIXES --- * The CTABHOLD bit now functions correctly. In previous releases, the CT[0..2] outputs would change states when the host was writing to the CTABs. Now, the CT[0..2] are frozen, regardless of CTAB activity. * The CTCONx bits now work correctly. ________________________________________________________________________ Version 1.2 - December 16, 1997 --- SDK ENHANCEMENTS AND IMPROVEMENTS --- * The system will now handle multiple firmware files, see the "Firmware Details" button in SysReg. * The system now supports cameras that output multi-tap data serially. For example, cameras that output color pixels as three consecutive 8 bit words. * Driver now optimizes Quad allocations to handle larger images. * Driver automatically calculates delay needed to download the firmware to board. * The SDK automatically program Intel's 430 series PCI controller chipsets for optimal PCI DMA performance. * The function "R2CamInquire()" now accept many more parameters. Please see the file "NewSDKFunctions.txt" for more information. * The driver automatically closes any board handles that are left open from an application that crashed or otherwise does not terminates normally (i.e. R2BrdClose() does not get called). This means that the application "R2Reset.exe" does not need to be called after a application crashed and the function R2_OpenStatus() does not need to be called to reset the open counts. Therefore, "R2Reset.exe" is no longer needed and not included in this release. * All of the function calls in the API are now type "_stdcall". This allows for easier interfacing with non "C" based languages and applications. * The number of required header files has been substantially reduced and simplified. In some cased you will need to change the files that you include in source code that you have written with version 1.0 of the Road Runner SDK. While BitFlow attempts to minimize the impact of upgrading existing applications to new releases, it was felt that the greater simplicity of this new header file scheme out weighed potential problems created change header file naming. --- NEW FUNCTIONS --- Please see the "NewSDKFunctions.txt" file for more details. Also the source code for all these functions is included in this release. Exposure/Rate Functions R2RC R2CamLineScanTimingOneShotGet(RdRn Board,BFU32 PixelClockFrequency, PBFU32 pExposureTime); R2RC R2CamLineScanTimingOneShotSet(RdRn Board,BFU32 PixelClockFrequency, PBFU32 pExposureTime); R2RC R2CamLineScanTimingOneShotGetRange(RdRn Board,BFU32 PixelClockFrequency, PBFU32 pMinExposureTime,PBFU32 pMaxExposureTime); R2RC R2CamLineScanTimingFreeRunGet(RdRn Board,BFU32 PixelClockFrequency, PBFU32 pExposureTime,PBFU32 pLineRate); R2RC R2CamLineScanTimingFreeRunSet(RdRn Board,BFU32 PixelClockFrequency, PBFU32 pExposureTime,PBFU32 pLineRate,BFU32 Priority); R2RC R2CamLineScanTimingFreeRunGetRange(RdRn Board,BFU32 PixelClockFrequency, PBFU32 pMinExposureTime,PBFU32 pMaxExposureTime,PBFU32 pMinLineRate,PBFU32 pMaxLineRate); Display and Physical memory QTAB building functions R2RC R2DispQtabCreate(RdRn Board,PQTABHEAD pRelQtabHead); R2RC R2DispQtabFree(RdRn Board,PQTABHEAD pRelQtabHead); R2RC R2RelDisplayQtabCreate(RdRn Board,PR2CAM pCam,PBFVOID pDest,BFU32 BufferSize,BFS32 Stride,PQTABHEAD pRelQtabHead,BFU32 DestType,BFU32 LutBank,BFU32 LutMode, BFU32 Options,BFU32 SrcX,BFU32 SrcY,BFU32 SrcDX,BFU32 SrcDY,BFU32 DestX,BFU32 DestY); DirectDraw Display Functions BOOL DDrawSurfCreate(PBFS32 ddrawsurfhandle,BFU32 dx,BFU32 dy,BFU32 pixdepth,HWND hwndOwner); BOOL DDrawSurfCreateFull(PBFS32 ddrawsurfhandle,BFU32 dx,BFU32 dy,BFU32 pixdepth,HWND hwndOwner,RdRn hBoard); BOOL DDrawSurfTop(BFS32 ddrawsurfhandle); BOOL DDrawSurfClose(BFS32 ddrawsurfhandle); BOOL DDrawSurfBlit(BFS32 ddrawsurfhandle); BOOL DDrawSurfChangeSize(BFS32 ddrawsurfhandle,BFU32 dx,BFU32 dy,BFU32 pixdepth); BOOL DDrawSurfGetBitmap(BFS32 ddrawsurfhandle, PBFVOID *pBitmap, PBFS32 pPitch, PBFU32 pSCreenX, PBFU32 pScreenY); BOOL DDrawSurfGetLut(BFS32 ddrawsurfhandle, PBFU8 pLut); BOOL DDrawSurfVersion(PBFU32 pMajorVersion,PBFU32 pMinorVersion); BOOL DDrawSurfGetDisplayQtab(BFS32 ddrawsurfhandle, PQTABHEAD *pDispQtabHead); BOOL DDrawSurfIsOpen(BFS32 ddrawsurfhandle); BitFlow Direct Display Functions BOOL BitDirectSurfCreate(PBFS32 bitdirectsurfhandle,BFU32 dx,BFU32 dy,BFU32 pixdepth,HWND hwndOwner,RdRn hBoard); BOOL BitDirectSurfTop(BFS32 bitdirectsurfhandle); BOOL BitDirectSurfClose(BFS32 bitdirectsurfhandle); BOOL BitDirectSurfGetLut(BFS32 bitdirectsurfhandle, PBFU8 pLut); BOOL BitDirectSurfVersion(PBFU32 pMajorVersion,PBFU32 pMinorVersion); BOOL BitDirectSurfGetDisplayQtab(BFS32 bitdirectsurfhandle, PQTABHEAD *pDispQtabHead); BOOL BitDirectIsOpen(BFS32 bitdirectsurfhandle); New Error Reptoring Control Functions R2RC R2ErrorEnableEvent(RdRn Board, BFU32 Filter) R2RC R2ErrorDisableEvent(RdRn Board, BFU32 Filter) R2RC R2ErrorEnableDebugger(RdRn Board, BFU32 Filter) R2RC R2ErrorDisableDebugger(RdRn Board, BFU32 Filter) R2RC R2ErrorEnableDialog(RdRn Board, BFU32 Filter) R2RC R2ErrorDisableDialog(RdRn Board, BFU32 Filter) R2RC R2ErrorEnableFile(RdRn Board, BFU32 Filter) R2RC R2ErrorDisableFile(RdRn Board, BFU32 Filter) R2RC R2ErrorEnableBreakUser(RdRn Board, BFU32 Filter) R2RC R2ErrorDisableBreakUser(RdRn Board, BFU32 Filter) Timeout functions R2RC R2CAPI R2CamAqTimeoutSet(RdRn Board,PR2CAM pCam, BFU32 Timeout) R2RC R2CAPI R2BrdAqTimeoutSet(RdRn Board, BFU32 Timeout) Accesser functions R2RC R2CAPI R2BrdCamGetCur(RdRn Board, PR2CAM *pCam) R2RC R2CAPI R2BrdCamSetCur(RdRn Board, PR2CAM pCam, BFU32 Mode) R2RC R2CAPI R2BrdQtabSetCur(RdRn Board, PBFVOID pQuad, BFU32 QuadBank) R2RC R2CAPI R2BrdQtabGetCur(RdRn Board, PBFVOID *pQuad, BFU32 QuadBank) R2RC R2CAPI R2BrdAqSigSetCur(RdRn Board, PBFVOID pAqSig) R2RC R2CAPI R2BrdAqSigGetCur(RdRn Board, PBFVOID *pAqSig) --- FIRMWARE ENHANCEMENTS --- * Please see the file "NewBits.txt" for more details. * New TRIMP4 bit which provide more flexible timing between LEN and first valid pixel. * New trigger mode, triggered-termination, which allows TRIGGERA to start acquisition and TRIGGERB to terminate acquisition, especially designed for line scan cameras and variable sized images. * New TRIGASTOP bit, which modifies triggered-termination mode so that TRIGGERA rising edge starts acquisition and falling edge of TRIGGERA terminates acquisition. * New ONEQTAB bit, which causes the boards to combine both QTAB banks into one large bank, thus allowing for acquisition of larger images. * The Hardware Exception interrupt now correctly detects loss of sync. --- EXAMPLE APPLICATION ENHANCEMENTS --- R2View * Saves snapped images to disk in Windows Bitmap format (BMP), 8 or 24 bit images only. * Includes simple image processing example. * Supports two new display methods: Microsoft's DirectDraw and BitFlow's BitDirect. * Includes support for continuous data acquisition with a software triggering button in the R2View GUI. * Includes support for both new triggered-termination mode with a software triggering button in the R2View GUI. * Support loss-of-sync detection and recovery. * A Dialog will pop-up, if there if there is more than one board in the system, asking the user which board to open. * A Dialog will pop-up, if there if there is more than camera configured for the current board, asking the user which camera to configure the board for. PingPong * Now support continuous data. R2Simple * New version now supports triggering and one shot cameras. * New version now supports image saving to disk. --- Display Libraries --- This release includes three different display methods. Each method has certain advantages and features as compared to the other methods. R2View uses all three methods, you can choose which method you wish to use with the Preview | Set Preview Method menu command. Listed below are the three methods and how they compare. DispSurf * Uses WIN32 DIBSection * Can be placed behind other windows * Support software zoom 10% - 400% * Support copying of image to another host buffer * Works in any VGA color mode (8 bit color - 32 bit color) * Works on any VGA * Uses the most CPU cycles * Slowest image update rate DDrawSurf * Uses Microsoft Direct Draw Technology * Can be placed behind other windows * Supported by most VGAs * Uses minimal CPU cycles * Image can be copy to host buffer * Requires VGA to have enough off screen memory to hold complete image * Only works in 256 (8 bit) color mode BitDirectSurf * Uses BitFlow's Direct to VGA technology * Fastest image update rate * Requires no CPU cycles * Requires no off screen VGA memory * Display window must be on top * Image cannot be copied to host * Frozen image cannot be panned or scrolled * Only works in 256 (8 bit) color mode * Only supported on VGAs that have PCI addressable image memory --- OTHER ENHANCEMENTS --- * Image Pro Plus 3.x driver is included in this release. * A WinVFG driver is included in this release. * Optimas 6.2 (and higher) is supported by this release through the WinVFG driver. --- BUG FIXES --- * The following problems have been fixed in this release: * Opening a board with the exclusive option doesn't work correctly. * Opening more than one board in a single process fails. * R2WaitDone() always returns an error. * Overflow recovery can leave pixels scrambled. * R2View can hang computer trying to recover from multiple continuous overflows. ________________________________________________________________________ Version 1.00 - November 1, 1996 First Release