Kithara »USB Toolkit«

The Base Module provides multiple functions, e.g. shared memory for data exchange between application and kernel:

err = KS_createSharedMem(
        &pAppPtr,                // Application address
        &pSysPtr,                // System address of memory
        "MySharedMem",           // Globally valid name
        40 * MegaBytes,          // Length in bytes
        0);                      // Flags, here 0

For the simplification of periodical data exchange is it ideal to use a data pipe, which is also based on shared memory:

err = KS_createPipe(
        &hPipe,                  // Address of pipe handle
        "MyValuePipe",           // Name of pipe
        2,                       // Data size (e.g. measurement values)
        1000000,                 // max. number of data elements
        NULL,                    // reserved
        0);                      // Flags, here 0

Now you can deposit the measured values in the pipe:

err = KS_putPipe(
        hPipe,                   // Pipe handle
        valueBuffer,             // Pointer to data buffer
        valueCount,              // Number of values
        NULL,                    // Not used here
        0);                      // Flags, here 0

Application can read measured values from the pipe:

err = KS_getPipe(
        hPipe,                   // Pipe handle
        buffer,                  // Pointer to data buffer
        bufferSize,              // max. number of values
        &filledSize,             // How many values read?
        0);                      // Flags, here 0

Variable-length data (e.g. messages) can be best handled with a message pipe. The usage is similar to the above mentioned way.

Assuming that your callback-function for the real-time timer looks like that:

int __stdcall myTimerCallback(
        void* pArgs,             // Address of reference data
        void* pContext);         // Address of context data

There are two ways to get the user code to the kernel level:

err = KS_createCallBack(
        &hCallBack,              // Address of handle
        myTimerCallback,         // Address of function
        pSysAddrOfMyData,        // Reference parameter
        KSF_KERNEL_EXEC,         // on the kernel level!
        0);                      // Application priority, here 0

This way a function is loaded into the kernel memory.

Alternativly, you load a whole DDL into the kernel:

err = KS_loadKernel(
        &hKernel,                // Address of handle
        "mykernel.dll",          // File name of kernel DLL
        "myInitFunction",        // Name of init routine
        pArgs,                   // Reference parameter
        KSF_KERNEL_EXEC);        // Flags, load into kernel

If it is once loaded in the kernel, you can create a kernel callback:

err = KS_createKernelCallBack(
        &hCallBack,              // Address of handle
        hKernel,                 // Kernel Handle
        "myTimerCallback",       // Name of function
        pSysAddrOfMyData,        // Reference parameter
        KSF_KERNEL_EXEC,         // on the kernel level!
        0);                      // Application priority, here 0

The callback handles can now be used as timer or interrupt handlers or to a real-time signalization for incoming Ethernet frames.

Hint:Complete Projects, for applications in languages like C++, C# or Delphi and also DDLs, which are loaded into kernel in C++ or Delphi, are components of every software delivery.

The Clock Module provides two mechanisms – time measuring and short-time delay.

The most used function to time measuring delivers 100 ns units since system start:

UInt64 time;
err = KS_getClock(
        &time,                   // Address of variable
        KS_CLOCK_MACHINE_TIME);  // 100 ns since system start

For processing , converting into 64-bit-values:

__int64 time64 = time.hi;
time64 <<= 32;
time64 += time.lo;
printf("%Ld Mikrosekunden seit dem Systemstart.\n", time64 / 10);

You also can get the absolute point of time since 1.1.1601 :

err = KS_getClock(
        &time,                   // Address of variable
        KS_CLOCK_ABSOLUTE_TIME); // 100-ns seit 1.1.1601

If you want to process with the received value you can easily use Windows functions.

The short-time delay realizes high precision delays, programmable in 100 ns steps with a difference in a few nanoseconds (on kernel level):

err = KS_microDelay(
        38);                     // here 3,8 microseconds

Thats frequently usefull for access to hardware, if you have to keep in time conditions.

For the realization of a "virtual COM port" you can create different callback rountines for the following events CREATE, CLOSE, READ, WRITE and CONTROL. E.g. for CONTROL:

int __stdcall myControlCallback(
        void* pArgs,             // Address of reference data
        void* pContext)          // Address of context data
{ ...
  if (pContext->controlCode == SERIAL_SET_BAUD_RATE)
    ...

Callback objekts will be created for all routines:

err = KS_createCallBack(
        &functions.hOnControl,   // Address of handle
        myControlCallback,       // Address of function
        pSysAddrOfMyData,        // Reference parameter
        KSF_DIRECT_EXEC,         // on kernel level!
        0);                      // Application priority , here 0

Afterwards, "virtual COM ports" can be created:

err = KS_createDevice(
        &pAppPtr->hDevice_,      // Address of handle
        "COM77",                 // Device name
        &functions,              // Structure with callback handle
        KSF_SERIAL_PORT);        // Flags, "virtual COM port"

Therewith are other applications for another serial interfaces under the name "COM77" available, which can not be differenced to "real" interfaces. You also can operate with existing application and you dont have to programm they new.

Use the following function to list up all USB devices:

err = KS_enumDevices(
        "USB",                   // Searching USB devices
        i,                       // Counter, starting with 0
        deviceNameBuf,           // Puffer for device name
        0);                      // Flags, here 0

The received name allows you yo detect the config descriptor to e.g. search for a special HID device type:

err = KS_execUsbCommand(
        deviceNameBuf,           // Device name
        KS_USB_GET_CONFIG_DESCRIPTOR,
        0,                       // Index of descriptors
        pBuf,                    // Puffer
        64000,                   // Puffer size
        KSF_ALTERNATIVE);        // Flags

An existing driver can be replaced:

strcpy(infPath+GetSystemDirectory(infPath,256),"\\Kdemo.inf");
err = KS_updateDriver(
        deviceNameBuf,           // Device name
        infPath,                 // INF-file
        0);                      // Flags, here 0

The founded device can be openend. If it is known, you can directly declare it as the device name:

err = KS_openUsbDevice(
        &hDevice,                // Address of handle
        "USB\\VID_10CF&PID_5500",// Device name
        0);                      // Flags, here 0

The essentially communication takes place via so-called Endpoints. There are up to 15 send and 15 receive endpoints for every device:

err = KS_getUsbPort(
        hDevice,                 // Device handle
        &hPort,                  // Address of handle
        endpointAddress,         // Number of Endpoints
        KSF_INTERRUPT_TRANSFER); // Flags: transfer mode

The communication takes place like the serial communication in the Serial Module.