08-26-2020 08:40 AM
I have a project using the sbRIO-9651 SOM module with custom carrier board. I have added my according IO to the project with the CLIP generator and so far this seems to work quite fine. However when trying to add the NI provided I2C library to the project I came across some differences in the possible IO Items.
The CLIP generated IO items are all basic IO items that only support reading and writing the value actual value. For Read/Write Items the CLIP generator automatically adds an "In" item that can be read and an "Out" and "Enable" item that can be read. But the I2C example that I tried to incorporate uses IO Items that allow not only Read and Write access but also allow method access to "Set Output Enable". Obviously I can not select one of my simple CLIP generated IO Items for these functions. Obviously I can create a copy of these functions and modify them to access my specific IO items directly in order to get this working, but is there any way to actually create these more functional IO items myself and connect them to the FPGA fabric or does that require some NI super secret special stuff tool? Obviously for C DIO modules on normal cRIOs as well as the myRIO the IO items seem to be of that more functional type, so there needs to be a way to specify them, but how?
08-27-2020 04:56 AM
I'm not entirely sure from your text where the problem lies.
Is it the structure of the CLIP Interface, or just the naming of the terminals?
08-27-2020 07:20 AM - edited 08-27-2020 07:24 AM
It has something to do with the structure of the resources in the CLIP file. For a particular IO pin the CLIP generator creates 3 different IO items, 1 Readable item for the Input buffer of the IO pin, and two Write items for the Output Enable and the Output State item of that pin.
Other IO items for C modules and also for the myRIO template only have one IO Item per IO pin, but that item supports in addition to the Read and optionally Write method also an additional method for the "Set Output Enable" and "Set Output State" method.
It has to do with the Elemental IO object which can come in different flavors, supporting more or less methods per specific IO Item, but I see no way to generate the more functional IO Items ourselves and the CLIP generator does not seem to support creating them either. Obviously there has to be some vhdl code support for these items to map the different functions of a pin to different methods of the same IO item but considering that the myRIO does have such support and the Zync core on the sbRIO-9651 is basically the same chip as on the myRIO device it seems the actual code support should be present, but the CLIP generator simply doesn't support its use.
You can also see a difference in color for the IO Item in the project tree. LabVIEW "out of the box" IO items are colored, while the IO items generated by the Clip generator are B/W only. Not sure if this is part of the issue, or if the different icon is rather caused by the fact that these items are listed under the sbRIO-9651 Socket group rather than a normal virtual folder.
08-27-2020 09:05 AM
I'm not familiar with the differences you describe. Only ever been on Flex RIO.
I think it's a LV implementation which allows for the extra functionality.
I've long since started abstracting out ALL of my I/O on my FPGA targets to LVOOP. That way, I can utilise mock objects for testing. Having done this work, problems like this disappear (assuming the APIs are in some way compatible on a logical level).
08-27-2020
09:21 AM
- last edited on
03-11-2025
10:03 AM
by
Content Cleaner
Well the Elemental IO object, which are basically represented by the purple IO wires (one of many forms of those purple named references like VISA, IVI, IO Tags, IMAQdx and IMAQ Refnums, User Refnums and several others) are of course a LabVIEW feature but the actual implementation is directly tied to vhdl resources for FPGA and DLLs/shared libraries for RT and desktop platforms. Very little is documented about them, although I suspect that the cRIO-9951 Module Development Kit documentation might give a little more details about them as far as the FPGA implementation is concerned. Also they seem to be documented a little by the now discontinued LabVIEW Embedded Toolkit for ARM (and AD Blackfin) but here they tie to IO functions implemented in a custom shared library to allow to use the IOs from the RT program.
As far as I can see, there are no LabVIEW VIs involved for those more functional versions of the IO Items. It all boils down to some different definitions in the XML structure for these items and from that XML definition a reference to some form of NI provided, encrypted VHDL code for the myRIO case. But there is nowhere any documentation to be found about how the VHDL interface would need to be defined, in order for these extended Elemental IOs to access the different IO pin functions.
The problem isn't really on the LabVIEW VI side but much lower level, at the interface between the CLIP generated IO definition and the actual VHDL generation.