There is a file which I can cat in linux, and it tells me the state of a pin based on the new device tree overlay. Using C++, I can stream the pin state to it when I configure it as an output. But if I fopen and read from the file, it gives me a character, then a newline I think, then an end of file, I think. So basically, whatever the software is doing to deliver me some reading as reading from a file, it only delivers it once per file open.

The pin reading I assume is a field-effect transistor with a bunch of resistors in there or something, to tell me if there is more than 2 volts on it relative to its ground. So of course I want to know when this changes every few microseconds (without a USART middleman).

But opening files takes a lot of time, and I have other things to do apart from go into the linux source code and find out why. So I need to read from this file, this device-as-a-file over and over, without it taking 300 microseconds to close and reopen the file so that the device gives me a new character. Reading from an open file takes a few microseconds max.  But it won't give me the new state value unless I close and reopen it.

So I am looking into using fcntl or freopen or something. What can I do?

They say in Unix "everything is a file." So I assume this is some sort of interface by which various drivers try to behave like a file. But really this is annoying if I have to open them like a file it is crazy and I can't imagine they ran a phone system in New Jersey that way.

Just a dumb Mac user here... but is there any way to:

1. find out what process is writing to this file and either change process or pipe it's output to that file to your process;

2. have the OS notify you if this file changes and then trigger a read;

3. have the OS automagically pipe any writes to that file to your process?

I would try t4a's nr 3 first.

There is also inotify in C++ to monitor file change events (t4a option nr 2) , but I don't think you can get the content:
http://www.thegeekstuff.com/2010/04/ino ... m-example/

Whether #2 or #3 is best depends on the nature of the process that writes to the file. If the write process is running on a clock and potentially writing the same value over and over, then #3 is probably better than #2. If the write process only writes to the file if there's been a change, then either #2 or #3 would work.

A couple of issues to think about:

2. If pin state flips from TRUE to FALSE and back to TRUE in a very short period of time, is it crucial that you know that a change occurred or is it OK if your process sees TRUE,TRUE during two successive reads? (This might push you to solution #3)

2. Is there a chance that you'll miss state changes if you have the file open and a change occurs? If the write process is blocked by you having the file open, does the write fail or is it buffered until you close the file? And if it's buffered until you close the file what happens if a second attempted write occurs? (This might push you to solution #3)

3. What is the total latency between the physical state change and you getting the new value (and do you care about that)?

I would try t4a's nr 3 first.

There is also inotify in C++ to monitor file change events (t4a option nr 2) , but I don't think you can get the content:
http://www.thegeekstuff.com/2010/04/ino ... m-example/

No, it just tells you when something changed, you have to manually open the files yourself.
Farmer, is this hardware register at a fixed (physical) memory location? mmap might be useful if you do atomic reads.
http://stackoverflow.com/questions/1282 ... user-space