Explanation of DIO registry configuration

  • The configuration of the registry entries for the Digital IO Driver (DIO) still seems to be a miracle for some users. So here is a description that should clarify some things. We already had this description as an answer to a question in the PicoMOD4 sub-forum, but we think it makes sense to have it also here at a more central place.


    I/O Pins
    Basically configuring DIO is rather simple. First you have to say which pins to use as digital I/O (UseAsIO). Then you have to say which of these pins are inputs and which pins are outputs (DataDir) and for all outputs you have to say whether they should start with a high or a low signal (DataInit). This setting is done for all I/O pins of the board in one go. Each bit of the entries corresponds to one I/O line.


    In earlier days, our boards like the NetDCU had about 20 to 25 I/Os. There a DWORD was enough for each of these settings, one bit of the DWORD for one I/O line. So you had to set one DWORD UseAsIO, one DWORD DataDir and one DWORD DataInit. Then came boards that had a few more pins than 32. So as a first step we added a second DWORD for all of these three settings and appended A and B. Newer boards like the PicoMOD had still more I/O pins. Therefore we again added more DWORDs and appended C and D and so on. So to define the meaning of all I/O pins, you had to set four DWORDS UseAsIOA, UseAsIOB, UseAsIOC, UseAsIOD to define the basic I/O function of all possible I/O lines, you had to set four DWORDS DataDirA, DataDirB, DataDirC, DataDirD to define the I/O direction and you had to set four DWORDS DataInitA, DataInitB, DataInitC, DataInitD to define the initial value of the outputs. This concept proved to be rather confusing, especially as there is also the concept of ports.


    Ports
    What is a port? There are DeviceIOControl calls that can handle one I/O pin at a time. However sometimes you want to set or read more than one I/O pin in one go. This was the reason why always 8 I/O pins were grouped together to so-called "ports". Such a group can be accessed with the ReadFile() and WriteFile() functions and other, port-oriented DeviceIOControls. Each bit of the written or read byte determines the state of one I/O line. So you can access up to 8 I/O lines with one function call. Switching the active port is done with the SetFilePointer() function. All following DeviceIOControl(), ReadFile() and WriteFile() functions will access the 8 lines of the port previously set with SetFilePointer(). The default port that is used when the system starts can be configured with the registry entry Port. So this entry does *not* say that you configure some specific port with these settings. You always configure *all* ports with the registry settings and this entry just tells the default port that is accessed with DeviceIOControl(), ReadFile() and WriteFile() after the system starts. A call to SetFilePointer() will always override the value of the Port registry entry.


    So we had 32 bit configuration entries in the registry on one side and 8 bit ports when accessing the data at runtime on the other side. So which bit in the registry configures which bit of which port? This mapping was more and more confusing. Therefore at some point in the past we started a completely new scheme to define the digital I/O settings in the registry. This new scheme now uses multi-byte sequences instead of DWORDs. So now each byte corresponds directly to a port. For example the first byte in UseAsIO corresponds to the 8 I/O lines of Port 0, the second byte corresponds to the 8 I/O lines of port 1, and so on. The same for DataDir and DataInit. So to define the meaning of all I/O pins of a PicoMOD board with 10 ports (0..9), you now only have to set one multi-byte entry UseAsIO, one multi-byte entry DataDir and one multi-byte entry DataInit, each of them with 10 bytes of data for the 10 possible ports. That's all. We recommend using this new scheme, even if the old scheme (with A/B/C/D DWORDs) is still accepted for compatibility reasons. Maybe in the future new boards will only support the new scheme.


    This concept of configuring DIO is the same for each of our newer boards, PicoCOM, PicoMOD, QBliss, armStone, etc. The difference is the number of available I/O lines (and hence ports and therefore the number of bytes in each multi-byte entry) and the mapping from connector pins to port bits. There you have to take a look into the device driver documentation and check the appropriate table for your specific board.


    Interrupts
    One thing remains to be explained: the IRQCfg entries. Pins that are configured as inputs can sometimes also trigger interrupts. But it is not as simple as to say "interrupt yes or no", which would be again just one bit of information. An interrupt can be triggered by a low signal, by a high signal, by a falling edge, by a rising edge, or even by both, a falling and rising edge. This provides for a set of possibilities that must be encoded with 3 bits.


    Code
    1. IRQCfg2 IRQCfg1 IRQCfg0 Function
    2. 0 0 0 Interrupt Disabled
    3. 0 0 1 Rising Edge Enabled
    4. 0 1 0 Falling Edge Enabled
    5. 0 1 1 Rising and Falling Edge Enabled
    6. 1 0 0 Interrupts Disabled
    7. 1 0 1 High Level Enabled
    8. 1 1 0 Low Level Enabled


    Nonetheless we wanted to keep the system that one specific bit in a multi-byte entry is responsible for the configuration of one specific I/O line of a port. So you have to set three registry values IRQCfg0, IRQCfg1 and IRQCfg2 for the interrupt configuration, where each entry represents one of the three bits of the interrupt type encoding. Here the advantage of the new naming scheme is apparent, because the old scheme would need to set IRQCfg0A/B/C/D, IRQCfg1A/B/C/D and IRQCfg2A/B/C/D, or no less than 12 DWORD variables to just configure the interrupt type. With the new scheme you just have to set three multi-byte entries.


    Your F&S Support Team

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.