Digital IO

  • Hello


    I have been reading through a lot of topics on using the digital IO on PicoCom4 but I need to get more information to understand how it works. There are a lot of setting that can be made in the registry DIGITALIO but there does not seem to be any good documentation as to why or what to set up.


    First I need to set Port 2 IO pin 20 to an output. Could someone detail what needs to be set up in the DIGITAILIO registry to do this.


    Also is there any document that explains clearly what each line in the registry is for and how to set it up. I.e. the line UseAsIO has 6 bytes but why? If there are only 8 bits that can be toggled in Port 2. It seems a bit of a black art at the moment to get the required information.


    I hope this does not sound too negative but when you are working to tight deadlines trying to get information from the forum is very difficult hence being straight to the point. Sometimes replying with questions after a week can be a bit frustrating.


    Thanks
    Rod

  • Hello Rod,

    Quote

    First I need to set Port 2 IO pin 20 to an output. Could someone detail what needs to be set up in the DIGITAILIO registry to do this.

    Code
    1. reg open \drivers\builtin\digitalio
    2. REM use port2 pin20 as IO -> set bit bit 4 in byte 2 (see IO table)
    3. reg set value UseAsIO hex 00,00,10,00,00,00
    4. reg set value DataDir hex 00,00,10,00,00,00
    5. reg set value DataInit hex 00,00,00,00,00,00
    6. reg save

    I did not test it ;(
    But if you set the "DataInit" bit for your IO to "1" the pin shloud be high after boot.


    Quote

    Also is there any document that explains clearly what each line in the registry is for and how to set it up. I.e. the line UseAsIO has 6 bytes but why? If there are only 8 bits that can be toggled in Port 2. It seems a bit of a black art at the moment to get the required information.

    We have seven ports with max. eight bits, refer the IO tabel in the device driver document -> 2.1.2 Configuration example.

    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.

  • Basically it's 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.


    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 8 I/O lines in one go. 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 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 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.


    This scheme 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.


    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.