• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
cifX drivers EtherCAT read/write performance with NetHat over STM32
#11
Ahh ... I see. Wel for your type of application calling the functions read/write like lRet = xChannelIORead(hChannel, 0, 0, sizeof(abRecvData), abRecvData, 10) with a timeout is bad.

This causes the function to call a standard msec timer when it waits for sychronization and indication that the requested data is available.

So call lRet = xChannelIORead(hChannel, 0, 0, sizeof(abRecvData), abRecvData, 0) instead and it will return immediately without waiting. Usually you get an error that no data is available right now ... but the function has started the "requesting for data" handshake ... and when you call the function again without timeout you will get then your data requested a call before.

Also I see you call the function with data amount of "sizeof(abRecvData) "... do you have really 3584 bytes of data the be requested? Or is your buffer adjusted according to the amount of bytes you wanna read/write?

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#12
I just tested with 0 timeout, I still have more or less the same latencies when there is no error, and it returns error most of the time.(if I wait enough time - couple msecs - no error)
abRecvData and abSendData are fixed 32 bytes
  Reply
#13
Well fact is you have to call it without timeout. Then there is definitively no waiting sequence in the function and it will return immediately after activating the handshake. Can you confirm?

If you want to have a look how the driver source code looks like visit this page: https://kb.hilscher.com/display/CIFXDRV/...NXDRV-TKIT. Feel free to look to the cifX_Functions.c source code in the zip file and cifXHWFunctions.c and the function DEV_WaitForBitState_Poll();
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#14
When I call with timeout = 0, whether it returns an error or not I have a latency between 300us to 1.5ms.
I'll look at the code, it is indeed weird if there is no waiting sequence to have latency. I have already tested my timer function and it accurately measures usleep calls so it shouldn't be erronous.
  Reply
#15
Well if I look to the source code again and in detail to the function xChannelIORead() I see that it is calling the function

DEV_IsRunning() first of all and this will definitively access the SPM for a read. Since this read triggers the HW SPM the time will be time equidistant.

Then it calls the function DEV_GetIOBitstate() which definitively accesses the SPM. This is also a read and will be time equidistant too.

If then the SPM indicates that the IO buffer contains not the latest data the function calls DEV_WaitForBitState() which in turn calls DEV_ReadHandshakeFlags() that accesses the SPM again, but this is still a read and time equidistant. If then the timeout = 0 the function returns.

To be honest I don't know how must time it costs to call 3 times the SPM accessing function. From what I know how the SPM works is that first you have to transfer to the SPM which offset you want to read and in a subsequent access you read the data then. So in the end there is really traffic over the SPM.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#16
I am back from homeoffice and had now a chance to make simple measurements myself with my netPI in the office about the typical latency time using the same nanosecond timer you use.

But first of all I must admit that I have no clue about using Linux real-time patch or similar. I am just using a standard Linux executeable created as a standard thread in Linux from the programming examples provided here https://registry.hub.docker.com/r/hilsch...-examples/. Since I have a Siemens PLC in the office I am using the PROFINET example but for runtime tests on Linux side this does not matter.

So what I see first is that the typical time calling xChannelIORead() is about 320usec on my Raspberry Pi 3B ... but after running a while I see values going up 2msecs and more. This sounds odd to me.

So I went back to a function that basically does nothing with the SPM over SPI ... it is the function xChannelGetMBXState(). It simply checks first if the netX device is "ready" reading from the SPM and reads then two times a 16bit value from the SPM to check if there are message packages pending and it neither writes anything to the SPM nor calls it additional data copy functions with it as  xChannelIORead() would do . So very straight. I measured about 320usec minimum time for this call ... but I see also values of 1msecs and more. This cannot be ... it must be my simple Linux thread that is interrupted by Linux scheduling between the xChannelGetMBXState call and the calls for the nanoseconds. Using xChannelGetMBXState() just communicates with the SPM hardware which operates always constant and the same, so the timing must be time equidistant.

Since you are using your thread under real-time conditions as you said you could propably repeat your test with this function too, to check your jitter.

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#17
Thanks for doing the measurements. From what I understand you seem to have similar results as me so this confirms that the performances I have aren't abnormal and not related to my configuration

(June-4th-2020, 07:41 AM)Armin@netPI Wrote: So very straight. I measured about 320usec minimum time for this call ... but I see also values of 1msecs and more. This cannot be ... it must be my simple Linux thread that is interrupted by Linux scheduling between the xChannelGetMBXState call and the calls for the nanoseconds. 


I have tested the xChannelGetMBXState and I have between 700us and 1.5 ms.
I don't believe Linux scheduling could cause such regular and large latencies. It may  cause a big jitter of msecs every once in a while but in this case the msec latencies are quiet regular at least in my case and also the values are repeating. Plus in my case my Linux is pretty light (no gui), and I'm only running this test at high rt thread.
  Reply
#18
I involved the netX support team and asked if they have ever made a performance test about xChannelIORead/Write() functions on an embedded system that is not running Linux as OS and just makes straight and direct accesses to the netX51/netX52 chips over SPM/SPI. I am waiting for a reply and will be back to you.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#19
I received an answer from the netX team and they have measured the values already for the function xChannelIORead/Write() in an embedded host environment that is of type non-Linux.

They say reading 10 input bytes for example from SPM memory across xChannelIORead() is about 47,85usecs while the SPI was clocked at 27Mhz. This of course includes that the embedded host system was pushing one SPI byte after the other with no bit delay in between during this test. The measured time was more or less constant and has nearly no jitter as I expected it. So it is an ideal case. I further asked if they were running a fieldbus stack inside netX or just a fake application that is providing the data handshake as fast as possible. They owe me an answer and I am waiting for it.

I also asked the netX chip developer about the SPM and he confirmed the SPM works with no processor at all and is implemented in hardware and produces by the very nature of design no jitter and is only host clock SPI speed dependent and how fast the host is providing the SPI bytes. So in the end the jitter it is all about the "software" on the host side and also on the "software" on netX side when it comes to providing the handshake bits in the common handshake cells. He said also that whenver the netX chip writes to the SPM host handshake cell the host gets an interrupt and whenever the host writes to the SPM netX handshake cell the netX gets an interrupt. In the netX chip we have an interrupt mode driven software active reacting on this internal interrupt and scheduling the event in the netX OS in case there was an interrupt. But his interrupt is then triggering the protocol stack to update the requested data ... and this may vary.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#20
For my personal interest I studied the Raspberry Pi processor manual https://www.raspberrypi.org/wp-content/u...herals.pdf and read the SPI chapter

I recognized that the SPI interface indicates an empty TX buffer by a software interrupt. In turn this means each byte transmitted across this SPI interface will cause in the end software getting triggered when the next byte shall be sent across SPI.

To be honest I do not know what really happens when your program triggers the netX API functions and these our driver that talks to /dev/spidev0.0 physically. Especially I do not know the priority the device /dev/spidev0.0 this is running at and the interrupt service routine that are retriggering the TX data stream. I hardly can imagine that the device /dev/spidev0.0 is getting the priority of the caller thread.

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Using Powerlink firmware with netHAT and config nxd thp9 3 537 August-25th-2020, 01:49 PM
Last Post: Armin@netPI
  NetHAT SPI configuration thp9 1 766 June-10th-2020, 02:05 PM
Last Post: Armin@netPI
  How can i set a EtherCAT node in netHAT 52-RTE? JGLee 6 919 June-9th-2020, 12:38 PM
Last Post: Armin@netPI
  netHAT as Ethernet/IP Adapter with Codesys lstiegler 11 1,147 May-26th-2020, 06:40 PM
Last Post: Armin@netPI
  netHat configuration via config packets pitau 6 766 May-25th-2020, 02:21 PM
Last Post: Armin@netPI
  NetHAT temperature question thp9 1 712 May-14th-2020, 09:21 PM
Last Post: Armin@netPI
  Ethercat Master TwinCATversion? MGharat 1 179 September-19th-2019, 06:38 AM
Last Post: Armin@netPI
  Using netHAT drivers with custom linux (not Raspbian) FrankS 5 807 September-11th-2019, 06:16 AM
Last Post: Armin@netPI
  Use netPi firmware on netHAT zz_zesys 1 1,032 September-30th-2018, 08:04 PM
Last Post: Armin@netPI
  NetHat Labview richielfc 1 850 August-10th-2018, 12:08 PM
Last Post: Simon@netHAT

Forum Jump:


Users browsing this thread: 1 Guest(s)