Chameleon MT 
=========================

Introduction
------------

Chameleon is the new module test git repository for Synaptics BPD next generation (AKA Nassau) finger printer sensors.
Chameleon is consisted by 1 main git repository and 3 sub modules repository:
    
    *   /git/biometrics/mt/chameleon.git
    *   /git/biometrics/mt/cmlFpSensorEngine.git 
    *   /git/biometrics/mt/cmlFpTestEngine.git
    *   /git/biometrics/mt/cmlFpTestApp.git

The main chameleon repository has the following folder structure:

    chameleon\ -- cmlFpSensorEngine\     # the folder for cmlFpSensorEngine.git
                  cmlFpTestEngine\       # the folder for cmlFpTestEngine.git
                  cmlFpTestApp\          # the folder for cmlFpTestApp.git
                  include\               # contains the head files used by all 3 submodules.
                  package\               # contains the third party packages, like gtest, glog.
                  patch\                 # contains the test patch source code, like open short patch. 
                  Win32\                 # this folder is automatically generated by msvc (Visual Studio) after the projects are successfully compiled. 
                  xxxx.sln               # the visual studio solution files, we suggest to put the solution files here. And this can be customized by each programmer. 

We put all projects in the submodule, here is the list for each submodule:

    cmlFpSensorEnigne\ -- FpBridge\     # this project acts as the API for MT devices like MPC04 and M5, like PowerOn(), GetCurrent().
                          FpModule\     # this project contains the module level API like FpGetVer(), FpTidleSet(). 
                          libM5Drv\     # the FTDI driver for M5.
                          Logging\      # the logging functions in "DEBUG" mode. The debug log is output to "ChameleonMT.log" in the "logs" folder of the application folder.

    cmlFpTestEnigne\ -- DutUtils\           # the utility functions to parse the MTconfig, holding the Exceptions, Bincodes and holding the test data. 
                        FpImageProcessing\  # the image processing and test library, like SNR, bubble test, should be put in here.
                        FpTestStep\         # include all the test steps and test step factory.
                        FpTestEngine\       # the test engine to create and execute the test steps.
                        NativeTestEngine\   # the customized and wrapped Cpp test engine for customer.
                        DotNetTestEngine\   # the customized and wrapped .Net test engine for customer.

    cmlFpTestApp\ --  ChameleonQt\          # the demo MT GUI written in Cpp Qt.
                      ChameleonSharp\       # the demo MT GUI written in C#.net.
                      MTConfigGenerator\    # the MT config generator.
                      cmlLogParser\         # the test log parser and analysis tool. 
                      BravoDebugTool\       # the tool to debug the Nassau sensors, display image, read IOTA, etc.

Project
-------

Right now we are still using Visual Studio 2013, so in each project, there is a "msvc" folder contains the Visual Studio *.vcsproj files. In the future, we will migrate to CMAKE.
The folder structure for each project:

    project\ -- including\      # the header files         
                src\            # the source files
                test\           # the test files
                msvc\           # Visual Stuio project files

Normally, there is 2 projects in msvc folder, for example, the "FpBridge" project, one is "FpBridge.vcsproj" to compile the code in "src" and the other is "FpBridgeTest.vcsproj" to run the code in "test".
And all output files (exe, lib or dll) will be output to "Win32" folder.
When we want to add a new project, we need follow this structure.


Unit Test
---------
We use gtest as the unit test library. The test code is put in each project's "test" folder, and there is "main.cpp" as the entrance of the test.
Ideally, every API we write in the low level project need be tested in unit test.
For example, the FpBridge project has a API called "SetVoltage()", so in the FpBridgeTest project, there is unit test called "TEST_F(M5, SetVoltage)" to test this API.
Usually we use a test fixture for each object, so for FpBride object, we create a M5 fixture or MPC04 fixture. So the test function is "TEST_F()" with fixture. 
We can still use "TEST()" as a signal test function but not recommended.


Logging
-------
The "Logging" only functions in "DEBUG" mode, once we include the "Logging" projects, and we can write message to the log file. 
The usage as follow:

        #include "Logging.h"

        rc = Init();
        if(0!=rc)
            Logging::GetLogger()->Log("FpBridge Init() Failed %x", rc);


Packages
--------
Here are some tools and third party packages we used in Chameleon MT.

    * Qt5.5     # the Qt C++ framework. Can be download at "http://download.qt.io/official_releases/", this is just for demo GUI.
    * gtest     # the google unit test framework. All test code is written in gtest. 
    * glog      # the google log library.
    * Cppcheck   # we use Cppcheck to check the issues and performance of code. 

For gtest and glog, are already contain in the "package" folder. 
For Qt, If the GUI is not needed, we don't need to install Qt.
For Cppcheck, it's recommended to check the code before pushing to git repository.


Version control
---------------

We use git as the version control tool, and we use "git-submodule" to control the 3 different modules used in Chameleon.
So it's very important to realize which "module" you are working on when you want to push your code.
When you try to fix the bugs in FpModule, so actually you are working on the "cmlFpSensorEngine" module, so when code is pushed, it's pushed to the "cmlFpSensorEngine" repository.
This is very important for us to separate the works to individuals.
In the main git, the "chameleon.git", it only has links to the submodule (with the specific hash code).  

Here are some recommend rules for us to easily merge code:
 
    * We used the .gitignore to ignore the local files. Please do not change it.
    * Recommend to create a branch "develop/your_inital", and push the code to remote branch.
    * Please do not push the code directly to master branch.
    * Please do not push the "temp" branch to remote server.
    * Since there is no "pull request" function in Synaptics's git server, please submit JIRA or send mail to Qiling when you want to merge the code into master.
    * The release will be only applied in master branch with the tag "Release v1.0.0", please do not tag like this in your own branch. 
    * Recommend to create JIRA to track and fix bugs and create branch with name like "JIRA_XXX".