RT HAL Component using an externa library and API
- Fuzzy_Mind
- Offline
- New Member
-
- Posts: 6
- Thank you received: 0
I am currently trying to develop a Real Time HAL component for a USB hardware device. This component is required to receive the USB packets in Real Time and deliver them to the LinuxCNC application program.
The USB hardware device is a serial to USB converter boards based on FTDI chip ( www.ftdichip.com/Products/ICs/FT232R.htm) . The serial (RS232) side of this board is a laser distance sensor which continually outputting the measured distance as UART packets. FDTI FT232R board converts them to USB protocol. The FT232R is supplied with its Virtual COM Port drivers and also with relevant C libraries and API functions (they call D2XX API functions).
In the process, I have prepared a HAL component as it is described in the HAL manual. Put my C function code with necessary API calls and FTDI library definitions in the component’s funtion definition part and compiled it with HAL’s “comp” function. The compiler gave fatal error: “ftd2xx.h No such a file or directory.”
The PROBLEM is:
How can i use an external library (such as ftd2xx.h library for the USB device in my case) to create a REAL TIME HAL component (like encoder component) ?
Thanks & Regards
Please Log in or Create an account to join the conversation.
I am currently trying to develop a Real Time HAL component for a USB hardware device.
I am not familiar with the FTDI boards and drivers, but it appears that whilst the ftdi_sio module is a kernel module, the libraries to access the virtual com port it creates, are shared object userspace libraries.
So it looks like the kernel module already exists, you need to use the API to communicate with it.
Real time components are kernel modules.
The hardware access they have is limited and low level, they operate in different memory space to user programs and you cannot link them to userspace libraries.
I recently submitted a patch to the comp / halcompile program, so that you can more easily link to external libraries, without having to build from C source code, but that only works for userspace components.
www.linuxcnc.org/docs/devel/html/hal/comp.html#_options
option extra_link_args "…"
I have used USB/Serial links from userspace components quite a few times and they generally work well.
What you will not be able to rely upon is low latency in the USB port, it is fine for passing data, but trying to pass pulse streams to drive steppers etc will not be reliable.
That is why there are no USB driver boards like SmoothStepper in use with Linuxcnc.
Put my C function code with necessary API calls and FTDI library definitions in the component’s funtion definition part and compiled it with HAL’s “comp” function. The compiler gave fatal error: “ftd2xx.h No such a file or directory.”
ftd2xx.h is a header file not a library.
If it was in the same directory as the source, or in one of the standard paths pointed to in the include pathspec. it would be found
As far as I can tell the library is libftd2xx.so
Assuming you have installed it, you could include that into the link of a userspace component, with the extra link option
option extra_link_args "L/somedir -lftd2xx"
regards
Please Log in or Create an account to join the conversation.
- Fuzzy_Mind
- Offline
- New Member
-
- Posts: 6
- Thank you received: 0
Thanks for your illuminating reply. I did it as an userspace component and it works perfectly
![:lol: :lol:](/media/kunena/emoticons/grin.png)
Best Regards
Please Log in or Create an account to join the conversation.
LinuxCNC realtime modules should only really be written using functions provided by the rtapi libraries. This actually includes basic things like mathematical functions and printing.
The bottom of www.linuxcnc.org/docs/html/ lists many of the rtapi commands available, note that there are even special versions of inp and outb.
Not included there are the rtapi_math functions:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...77808f436dd87ceb5d69
There are also bitops and other things provided:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...77808f436dd87ceb5d69
Anything else should used with extreme suspicion. An external library might think nothing of blocking to wait for a result for more than a servo period, for example.
Please Log in or Create an account to join the conversation.
We appreciate for your valuable info shared with us.
As we understand from your e-mail, it is not strongly recommended to use third-party libraries to create real-time HAL components in kernel space. Instead it is more feasible to use a user-space (which is managable by real-time kernel not to compromise the reliability of the real-time processes such as servo-loop etc.) for such components containing third-party ingredients.
As we look through the links that you have send which lists the RTAPI functions, we have seen some HOSTMOT2 functions and Mesa_UART HAL components for UART connectivity. Specifically, the hm2_uart_xxx functions that you have authored.
We have some sensors which continuously send the sensor values from their RS422/232 ports to the host (our PC with LinuxCNC application). We would like to capture those data with some real time HAL components (preferably in kernel space) since we really need to precisely pair them with encoder readings. That is, if the sensor value read is not correctly paired with the actual position data (i.e. encoder value), the results of the computation depending on those data pairs become unreliable/inaccurate.
The question is, are those HOSTMOT2 API calls and the Mesa_UART HAL components that you have created are Real Time kernel components? Can we use them? and How can we use them? Do you have any example for this?
Note: On our system, we use MESA 5i23 board and some other 7i33 and 7i37 boards for servos and encoder captures with digital input outputs.
Thanks for your helps,
Best regards,
Mehmet DURNA
Please Log in or Create an account to join the conversation.
As we understand from your e-mail, it is not strongly recommended to use third-party libraries to create real-time HAL components in kernel space. Instead it is more feasible to use a user-space (which is managable by real-time kernel not to compromise the reliability of the real-time processes such as servo-loop etc.) for such components containing third-party ingredients.
If you can inspect the code of the third-party code, or have confirmation from the supplier that it is thread-safe and runs in deterministic time then it should be OK to use in realtime. Typically none of these conditions is met so userspace is safer. However realtime components have no guarantee of the "freshness" of data from Userspace.
The question is, are those HOSTMOT2 API calls and the Mesa_UART HAL components that you have created are Real Time kernel components? Can we use them? and How can we use them? Do you have any example for this?
Yes, the UART driver for Mesa cards runs in real-time. I have used it to communicate between an Arduino and a Mesa card, but unfortunately I lost the code.
At the moment the UART driver is not easy to use, you need to write a HAL component (using comp) to interpret the data.
If I was writing the UART driver again I would make it match the BiSS and SSI encoder scheme where the bit-field is interpreted to HAL pins following a config string. I might even be persuaded to do that as I don't _think_ that anyone is using the current driver.
One puzzle that I don't know how to solve is maintaining byte-synch with multi-byte packets.
Please Log in or Create an account to join the conversation.
Is your driver loads a UART protocol bitfile to MESA card? Is there any high level protocol implemented or the mesa_uart component receives bytes in raw from the port? Also, can we assign any pins of the 5i23 to UART Rx Tx? How can we do this? Should we use an FPGA configurator such as XILINX ISE for that?
Best regards,
Mehmet
Please Log in or Create an account to join the conversation.
That sounds pretty easy. The framing byte is a big help.We can try to implement a HAL component to parse this array if we could read the packets from the mesa_hal component.
No, that would be handled in the usual way, from the "loadrt hm2_pci" line in the HAL file.Is your driver loads a UART protocol bitfile to MESA card?
Raw bytes, see git.linuxcnc.org/gitweb?p=hostmot2-firmw...1b72d4ceff6372#l1179Is there any high level protocol implemented or the mesa_uart component receives bytes in raw from the port?
You need a custom firmware, and that has to be compiled using the Xilinx compiler.It is Also, can we assign any pins of the 5i23 to UART Rx Tx? How can we do this? Should we use an FPGA configurator such as XILINX ISE for that?
You can do that yourself, or I could probably do it for you.
You might well find that there is a firmware called "Andy1" somewhere on your system that is set up for 2 x 7i39 + 1x 7i44 + 1 channel of UART on the last pins of header 1. based on this pin description file:
git.linuxcnc.org/gitweb?p=hostmot2-firmw...9d6b451b72d4ceff6372
There are instructions on creating custom bitfiles here: wiki.linuxcnc.org/cgi-bin/wiki.pl?Editing_MESA_Bitfiles
Please Log in or Create an account to join the conversation.
Depending on your LinuxCNC version this can be compiled with "comp" or "halcompile" (the name of the command was changed)
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...f31531ba247d07868ba7
You can use this component as-is for testing. I think it is even compiled by default, so you can loadrt it.
For your application you would need to delete the "send" function and re-write the receive to be a state machine that sets a pin on seeing the framing value, and adds the digits together on subsequent bytes.
Please Log in or Create an account to join the conversation.
either tomorrow if I get a chance or by Monday.
Please Log in or Create an account to join the conversation.