QfileSystemWatcher works until I set the M4 with GPIO (different port , only same bank)

AndreaSc

Dear all,

I used a QFileSystemWatcher on a Colibri Imx7 (A7 side) to check 5 files which gave me the Gpio button indication with Linux SysFs.
Every works, but when my M4 side change some gpio settings which have different number, two of 5 buttons doesn't send signal anymore.
I double checked that I have no Spike or something strange with Oscilloscope and files are still changing their internal number (from 0 to 1 if I press them).

Do you have any idea or Suggestion?
Below the code which I used.

A7 side:

QStringList gpioValueList = {gpioPathUp,gpioPathDown,gpioPathLeft,gpioPathRight,gpioPathOk};
   auto gpioButtonMonitor = new QFileSystemWatcher{gpioValueList, this};
   connect(gpioButtonMonitor, SIGNAL(fileChanged(const QString &)), this, SLOT(fileChanged(const QString &)));

M4 side, just init GPIO:
   GPIO_Init(BOARD_GPIO_AD1_CS->base,    &gpioInit_AD1_CS);
   GPIO_Init(BOARD_GPIO_AD2_CS->base,    &gpioInit_AD2_CS);

KroMignon

@AndreaSc Hello and welcome to Qt Forum.

I think, this has nothing to do with Qt itself but depends on how the GPIO driver works.
Does those IOs support "edge"? ==> https://www.kernel.org/doc/Documentation/gpio/sysfs.txt

AndreaSc

@KroMignon,
thanks for reply, but I know the kernel link page.

Does those IOs support "edge"?
SysFs works before and after SPI GPIO settings M4 side (different CPU on different O.S.).
I can always read all the files /sys/class/gpio<xxx>/value with the correct changed value and I have no spike on oscylloscope.

I didn't get your point.
Gpio's files are always updated properly and I have no clue that they have issue... Instead as I explained I didn't understand why QfileSystemWatcher after SPI settings on M4 doesn't work on some gpio files(not all) only after a different settings of a different O.S..

E.g: I read on /sys/class/gpio108/value : 1. I press button and I read 0 (with a simple cat). Before an SPI settings on gpio port 5, but different pin QFileSystemWatcher works and send me a signal. After I can still read the same change, but QFileSystemWatcher only on the Gpio of port 5 doesn't sen me signal anymore.

This is only a very strange behavior about QfileSystemWatcher. Files update works as before, but I don't see anymore the fileSystem trigger....

jeremy_k

There are a few debug messages that can be written to the qt.core.filesystemwatcher logging category. Monitoring for them might be informative.

KroMignon

@AndreaSc said in QfileSystemWatcher works until I set the M4 with GPIO (different port , only same bank):

This is only a very strange behavior about QfileSystemWatcher. Files update works as before, but I don't see anymore the fileSystem trigger....

I don't think so.
GPIO uses SysFS, which is a virtual file system.
You want QFileSystemWatcher to raise signal on I/O state changes, but that is only possible when Linux itself is aware about I/O changes.
Therefore, I/O must be able to trigger an interrupt, and that is only possible for IOs which have an edge virtual file.

Otherwise, you have to check per polling if IO state has changed!

AndreaSc

@KroMignon said in QfileSystemWatcher works until I set the M4 with GPIO (different port , only same bank):

You want QFileSystemWatcher to raise signal on I/O state changes, but that is only possible when Linux itself is aware about I/O changes.
Therefore, I/O must be able to trigger an interrupt, and that is only possible for IOs which have an edge virtual file.

Edge was already setted properly and the Linux is aware about I/O changes. I checked them before the issue and when QfileSystemWatcher stop to work (only in 3 on 5 Gpio) through the cat files. That GPIO files are still updated.

KroMignon

@AndreaSc said in QfileSystemWatcher works until I set the M4 with GPIO (different port , only same bank):

That GPIO files are still updated.

Which files do you talking about?
value is an virtual file, so it content is generated at reading time. So if you can read it, it only means that kernel can read IO state, it does not mean state changes have been reported to kernel.

AndreaSc

@KroMignon, thank you. I got your point and fixed issue

it does not mean state changes have been reported to kernel.
Right, the issue was the interrupt kernel which stopped to work.