• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Communication between BCM2837 and netX51 on netPI RTE 3
The interface between the Raspberry CPU (BCM2837) and netX (netX51 on netPI RTE 3) is a serial dual-port memory interface (SPM) provided by netX as described here. Any communication across this connection is initiated by the BCM chip while netX is always passive and just returns the data beeing requested.The clock speed of the SPI interface is configured to 25 Mhz by the driver. This limit comes from netX's SPI driven serial dual-port memory (SPM) that can be clocked just up to 33Mhz in maximum.

Basis of the SPM is a synchronous peripheral interface (SPI) bus interconnected between BCM and netX. Physically the following signals are connected to each other


Under Linux the SPI0 of the BCM chip is assigned to the device /dev/spidev0.0. So whenever any communication between the BCM2837 chip and netX51 is ongoing this happens through this Linux device. There can only be one source under Linux making use of this device. There is no support for multiple users.

A linux driver for the SPM is available here. Once you have installed it it provides you also a library that you can link to your GNU compiled applications. This library offers you a common API that we call "cifX API" (Communication InterFace for netX based devices) which is described here. It lets you send and receive acyclic messages to and from netX and also exchange you cyclic IO data of the current protocol that is running within netX.

Remark concerning interrupt event support:

The netX SPM interrupt signal SPM_DIRQ is physically connected to Raspberrys pin GPIO24 as stated above. Across this pin netX does indeed raise a signal whenever it has to "tell" the host processor something has changed in the SPM handshake cell and to trigger the host to read and to examine the handshake cell. By this read action the interrupt will be released automatically by netX.

Precondition in doing so is that the host driver listens to GPIO24 in interrupt driven mode. Far more important is that the GPIO24 is configured by default to "Level detect" mode instead of "Edge detect" mode in register GPHENn as described here in the BCM chip's manual in order not to miss any interrupts of the SPM in case netX raises signals on SPM_DIRQ in very quick succession.

Unfortunately the current implementation of Raspberrys GPIO driver in the Raspberrys official Linux kernel that is also basis of netPI does not support configuring a GPIO to level detection mode but to edge detection only. By this fact we couldn't get the SPM communication between BCM and netX to run in interrupt driven mode stable. So polling is the only mode to drive the SPM interface today. The issue could get solved only in changing the kernel module responsible for the GPIO interface, but there is no intention from Hilscher in changing it at the current time.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

Possibly Related Threads...
Thread Author Replies Views Last Post
  Problems with the communication of the RS485 interface PeterL. 9 44 April-28th-2020, 02:53 PM
Last Post: Armin@netPI

Forum Jump:

Users browsing this thread: 1 Guest(s)