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

The blending of external memory areas (Dual Port RAM) of a PCI card into the address room of the application and kernels takes place like:

err = KS_mapPhysMem(
        &pAppPtr,                // Application address
        &pSysPtr,                // System address of memory
        externalPhysAddr,        // physical address
        externalSize,            // Length of memory area
        KSF_PCI_BUS);            // Flags, here PCI bus

The allocating of internal memory areas of the PC RAM for access by external hardware takes place like:

err = KS_allocPhysMem(
        &pAppPtr,                // Application address
        &pSysPtr,                // System addresss of memory
        &externalPhysAddr,       // physical address
        externalSize,            // Length of memory area
        KSF_PCI_BUS);            // Flags, here PCI-Bus

The physical address can be delivered to the hardware to get access to the memory via PCI bus.

Both methods come to the conclusion, that application, the kernel and the external hardware are able to get directly access (withput emulation or copying operations) to the same memory.

Assuming, the following callback function configurated as interrupt handler:

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

If you want to create callback objects with the flag KSF_DIRECT_EXEC , please note Kernel Module.

If you want to announce an interrupt handler, you have to detect the resource information at first :

KSResourceInfoEx info;
err = KS_getResourceInfoEx(
        "PCI\\VEN_10ec&DEV_8139",// Hardware-ID of PCI card
        &info);                  // To filling info structure

Therewith you can announce the Interrupt handler:

err = KS_createDeviceInterrupt(
        &hInterrupt,             // Address of handle
        &info,                   // Info structure
        hCallBack,               // Callback handle
        KSF_ACCEPT_PENDING |
          KSF_PCI_INTERRUPT);    // Flags, here PCI

You can announce multiple handler for the same IRQ, e.g. a callback function for the kernel level and one further within the application context.