Kithara »Serial 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.

If you want to use direct I/O port access, you have to enable the I/O area for the direct access:

err = KS_enableIoRange(
        myBaseAddress,           // Basis addresses of hardware
        8,                       // Number of I/O register
        KSF_SIZE_8_BIT);         // Flags, here byte-wise

Now, you can address the enabled hardware-register:

byte value = KS_inpb(
        myBaseAddress + 2);      // Address, 1 byte read
...                              // Byte analyse
KS_outpb(
        myBaseAddress + 4,       // Address, 1 byte write
        value);                  // Byte write

If the I/O basis address of a PCI card is dynamical allocated from the Plug&Play-Manager, is it easy to trace by either all PCI assemblies will be browsed till the the vendor and device id is founded:

err = KS_getBusData(
        &pciData,                // Address of PCI-structure
        busNumber,               // Bus-number
        slotNumber,              // Device number and function
        0);                      // Flags, here 0
if (pciData.vendorID == XXXX && pciData.deviceID == YYYY)
  ...

Or immediatly browsed by the desired id combination:

err = KS_getRessourceInfo(
        "PCI\\VENxxxx&DEVyyyy",  // ID combination
        &resourceInfo);          // Address of resource info

The received data structures containing all necessary information about interrupt lines and used I/O or memory basis addresses.

Use the following function to list up all COM ports:

err = KS_enumDevices(
        "COM",                   // Searching COM ports 
        i,                       // Counter, strating with 0 
        portNameBuf,             // Puffer for COM port names
        0);                      // Flags, here 0

The interfaces can be opened like the following:

KSResourceInfoEx info;
err = KS_openSerialPort(
        &hPort,                  // Address of handle
        portNameBuf,             // Name of ports (e.g. "COM1")
        "9600,n,8,1",            // Initialising
        KSF_KERNEL_EXEC);        // Kernel implementation

Thats how we send data, e.g. a measuring request to a device:

err = KS_xmitPort(
        hPort,                   // Port handle
        NULL,                    // Signalisation (Post Mode)
        message,                 // Puffer address
        0,                       // Length, to send (auto)
        NULL,                    // Length, sent
        KSF_DONT_WAIT);          // Flags: without blocking

Anytime, you can detect the number of received characters:

err = KS_getPortState(
        hPort,                   // Port handle
        &state,                  // Address of state structure
        0);                      // Flags: here 0
printf("%d characters received.\n", state.recvAvail);

The receiving looks like the following (in Wait Mode on application level):

err = KS_recvPort(
        hPort,                   // Port handle
        NULL,                    // Signalisation (Wait Mode)
        pBuffer,                 // Address of  data puffer
        state.recvAvail,         // Length, to receive
        &received,               // Length, received
        KSF_USE_TIMEOUTS);       // Flags: time out monitoring