Is it possible to configure an AON GPIO in such a way that while SPE MCU listens a pin as an incoming interrupt pin (like in gpio-app.c example code) at the same time the pin can be (re)set by the Linux application code via /dev/gpiochip…? This could enable easy way to sync events between these two.
There is also lightly documented “IVC” communication channel for SPE and Linux comminication but I dont’ know how laggy or jittery it would be. Not sure if this is available for NX though, example seems to be only for AGX and TX2.
Hello, teemu1: Is it possible to configure an AON GPIO in such a way that while SPE MCU listens a pin as an incoming interrupt pin (like in gpio-app.c example code) at the same time the pin can be (re)set by the Linux application code via /dev/gpiochip…?
I’m not sure about your use case. It seems that you just want to setup a data channel between CCPLEX (Linux) and SPE R5 (FreeRTOS). I think IVC should be good enough. Even with GPIO interrupt triggered, you still need data exchange, which cannot implemented by GPIO, right?
There is also lightly documented “IVC” communication channel for SPE and Linux comminication but I dont’ know how laggy or jittery it would be.
You can check the code in SPE firmware and Linux driver. Generally, the mechanism underline is implemented by HSP which is interrupt-driven, and it’s wrapped by more friendly APIs. From SPE R5 side, the jitter should be good. But for Linux side, the message is wrapped by mailbox, and it’s hard to predict.
Not sure if this is available for NX though, example seems to be only for AGX and TX2.
Xavier NX shares the same chip as Xaver AGX, and TX2 NX shares the same chip as TX2. So from chip level, they are the same. Anyway, you may still have to check the module datasheet to confirm whether the desires modules’ pins are exported. That may be different by different modules.
Even with GPIO interrupt triggered, you still need data exchange, which cannot implemented by GPIO, right
Correct, after interrupt data exhange is needed and IVC would work for that purpose. However using GPIO would reduce lag and unpredictable jitter on event sync.
In case it’s not possible to configure a single GPIO for “dual role” we can also use two separate GPIO’s and short them on PCB. In any case we’ll try first with IVC messages first and see if timing tolerances are acceptable for the use case.