April-15th-2021, 12:53 PM
Well Tad,
I have never tested it myself how fast the communication over SPI and the netX serial port memory really is but a customer did.
He did the tests with our netHAT module, which is using the same netX51/52 chip type as netPI but is used on top of standard Raspberry PI and also communicates over SPI.
This is the forum where he posted his results: https://forum.hilscher.com/thread-603.html.
He expected latencies < 1msec, but this did not become true in this tests. He was becoming much more jitter. He did a lot of tests ... and finally he used a simple python script to measure the raw Linux SPI function by echoing the SPI-MISO signal to SPI-MOSI signal via a hardware bridge. This excludes the netX chip and its delay since he reads back what is writing by hardware.
His result was
So just the raw Linux SPI functions he is using like spi.xfer and spi.readbytes function alone causing such a jitter. And now imagine that for a communication with netX chip (no HW mirroring any more) further jitter is added since netX has to interpret the written SPI command in its processor ... and put the SPI response command back. This is causing additional jitter. So finally as he said in his very first statement he lands in jitter values of 4-5msec.
Thx
Armin
I have never tested it myself how fast the communication over SPI and the netX serial port memory really is but a customer did.
He did the tests with our netHAT module, which is using the same netX51/52 chip type as netPI but is used on top of standard Raspberry PI and also communicates over SPI.
This is the forum where he posted his results: https://forum.hilscher.com/thread-603.html.
He expected latencies < 1msec, but this did not become true in this tests. He was becoming much more jitter. He did a lot of tests ... and finally he used a simple python script to measure the raw Linux SPI function by echoing the SPI-MISO signal to SPI-MOSI signal via a hardware bridge. This excludes the netX chip and its delay since he reads back what is writing by hardware.
His result was
Quote:This code measure the time of writing and reading 32 bytes through the spi.
And I obtain results between 640us and 1.3ms
So just the raw Linux SPI functions he is using like spi.xfer and spi.readbytes function alone causing such a jitter. And now imagine that for a communication with netX chip (no HW mirroring any more) further jitter is added since netX has to interpret the written SPI command in its processor ... and put the SPI response command back. This is causing additional jitter. So finally as he said in his very first statement he lands in jitter values of 4-5msec.
Thx
Armin
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
