I think your project is a prime candidate to use the PRU Cortex-M that is
included in the BBB for this type of stuff. While I have worked on many
Cortex-Ms over the years, I haven't yet tried to use the PRU so you will
need to search this board for help setting that up.
They do have the new free toolchain option for it.
On Friday, October 12, 2018 at 7:38:45 PM UTC-5, Sergey Manucharian wrote:
>
> Thanks, Bill, that definitely works (see the loop below), however, I think
> it's not really effective from the CPU resources consumption standpoint.
> Maybe it has to be done at the kernel level...
>
> char res[2];
> ....
> // check for value 0 i.e. 0x30
> while (res[0] != 0x30) {
> lseek(fd, 0, SEEK_SET);
> read(fd, res, 2);
> }
>
> On Friday, October 12, 2018 at 4:37:52 PM UTC-6, Bill Fleming wrote:
>>
>> I'm pretty sure that you can just always read the "value" inside the GPIO
>> tree using a file read command.
>> So for example if you try to set the pin a certain way and it didn't
>> change (strong pull or short) the value read still reflects the actual
>> state.
>>
>> So just write a C program using fopen and fread to read the value from
>> the "file".
>> http://www.cplusplus.com/reference/cstdio/fread/
>>
>> Put the read function in its own separate thread in a loop with a task
>> delay resolution to match the baud rate.
>>
>> Then you are done, assuming the output pin read does actually work that
>> way.
>> If not you can try setting input mode, read the value, then set output
>> mode right after you are done reading.
>>
>> Bill
>>
>> On Friday, October 12, 2018 at 11:06:36 AM UTC-5, Sergey Manucharian
>> wrote:
>>>
>>> What's the best way to detect a change in value on a GPIO configured as
>>> OUT?
>>> It may sound really weird why one may need that. I have a custom cape
>>> and cannot make changes to its hardware, but I need to improve certain
>>> functionality.
>>> poll(2) on /sys/class/gpio/gpioXY/value exits with timeout.
>>>
>>> To avoid any XY-problem I'll explain the actual situation:
>>> The BBB's native RS-485 mode works fine with omap_serial driver,
>>> however, I cannot use actual hardware pins for RTS (RE/DE) because the
>>> above mentioned cape consumes all possibilities.
>>> So, I assigned an unconnected GPIO to be the RTS and want to detect its
>>> state changes in a timing-critical application (tcdrain() takes too long).
>>>
>>> Thanks for advises!
>>> Sergey
>>>
>>>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/bf0e9db1-cfc7-4d68-922d-1e4a21519124%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
