RT HAL Component using an externa library and API

More
14 Feb 2015 16:29 #55972 by Fuzzy_Mind
Dear All,


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.

More
14 Feb 2015 19:56 - 14 Feb 2015 21:40 #55974 by ArcEye
Hi

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
Last edit: 14 Feb 2015 21:40 by ArcEye.
The following user(s) said Thank You: mdurna, Fuzzy_Mind

Please Log in or Create an account to join the conversation.

More
16 Feb 2015 19:41 #56002 by Fuzzy_Mind
Hi ArcEye

Thanks for your illuminating reply. I did it as an userspace component and it works perfectly :lol: .

Best Regards

Please Log in or Create an account to join the conversation.

More
16 Feb 2015 23:09 #56013 by andypugh
A significant danger with using external modules inside realtime modules is that you have no way to know if the provided driver is thread-safe or realtime-safe.
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.
The following user(s) said Thank You: mdurna, Fuzzy_Mind

Please Log in or Create an account to join the conversation.

More
18 Feb 2015 17:31 - 18 Feb 2015 17:45 #56070 by mdurna
Dear Andy,

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
Last edit: 18 Feb 2015 17:45 by mdurna. Reason: more of correction

Please Log in or Create an account to join the conversation.

More
18 Feb 2015 19:25 #56073 by andypugh

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.
The following user(s) said Thank You: mdurna

Please Log in or Create an account to join the conversation.

More
19 Feb 2015 18:07 #56118 by mdurna
In fact we need a reliable, up-to date data. So, if your mesa_uart HAL component is functional, we would like to try it. Our sensor send out the sensor value as ASCII characters each for its digits (ie. '0', '7', '0', '3', 0x0D for 7.03mm, 0x0D being the packet delimiter). We can try to implement a HAL component to parse this array if we could read the packets from the mesa_hal component.
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.

More
19 Feb 2015 22:04 #56120 by andypugh

We can try to implement a HAL component to parse this array if we could read the packets from the mesa_hal component.

That sounds pretty easy. The framing byte is a big help.

Is your driver loads a UART protocol bitfile to MESA card?

No, that would be handled in the usual way, from the "loadrt hm2_pci" line in the HAL file.

Is there any high level protocol implemented or the mesa_uart component receives bytes in raw from the port?

Raw bytes, see git.linuxcnc.org/gitweb?p=hostmot2-firmw...1b72d4ceff6372#l1179

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 need a custom firmware, and that has to be compiled using the Xilinx compiler.
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
The following user(s) said Thank You: mdurna

Please Log in or Create an account to join the conversation.

More
19 Feb 2015 22:20 #56122 by andypugh
Here is an example uart driver file written in the "comp" language.
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.
The following user(s) said Thank You: mdurna

Please Log in or Create an account to join the conversation.

More
20 Feb 2015 12:12 - 20 Feb 2015 12:13 #56138 by PCW
If you tell me what pinout /FPGA card/daughtercards you are using, I can make bitfile
either tomorrow if I get a chance or by Monday.
Last edit: 20 Feb 2015 12:13 by PCW.
The following user(s) said Thank You: mdurna

Please Log in or Create an account to join the conversation.

Time to create page: 0.150 seconds
Powered by Kunena Forum