scott <sco### [at] scottcom> wrote:
> On my pi I'm running raspbian, and have a process running as root to
> read a pin on the GPIO (connected to a PIR). Only root can read the GPIO
> pins, but obviously I don't want large, complex programs running as root
> just because they need to read a pin on the GPIO.
>
> What's the best way for this root process to "broadcast" to other
> (non-root) processes when that pin goes high? It will only happen at
> maximum frequency of about every 2 seconds, but any delay between the
> pin going high and the other processes seeing it should be minimal.
>
> I did think about using a file, that was write permission only for root,
> but readable by everyone, that seems like a lot of overhead though (and
> what if root tries to write to it as someone else is reading it?). In
> Windows I might consider using a broadcast message with the PostMessage
> API function, is there something similar for Linux?

PIGPIO and GPIOZERO don't need root anymore, the user just needs to be in the
gpio group

Regards
Aydan

Post a reply to this message

> PIGPIO and GPIOZERO don't need root anymore, the user just needs to be in the
> gpio group

Yes I did read that (and tried following the instructions to update), 
but either it doesn't work or (more likely) I didn't update properly 
everything that needs updating. If it worked, it would obviously be the 
most trivial solution to implement.

I might just get another SD card and put the latest version of raspbian 
on there, if that works OK then I'll copy over all necessary files from 
the old one.

Post a reply to this message

Le 17/05/2016 17:48, scott a écrit :
>> PIGPIO and GPIOZERO don't need root anymore, the user just needs to be in the
>> gpio group
> 
> Yes I did read that (and tried following the instructions to update), but either it
doesn't work or (more likely) I didn't update properly everything that needs updating.
If it worked, it would obviously be the most trivial solution to implement.
> 
> I might just get another SD card and put the latest version of raspbian on there, if
that works OK then I'll copy over all necessary files from the old one.
> 

If the current user is added to a group, it must relog to see the effect (current
session is not updated when such change occurs)

Post a reply to this message

On Tue, 17 May 2016 11:44:03 +0100, scott wrote:

>> ... or you might look to see if the Raspbian kernel has "capabilities"
>> functionality that would let you grant a non-
>> root user access to the GPIO pins.
> 
> I did look this up previously, and the solution seemed to be to change
> the permissions of the entire memory map, so that non-root users could
> access it. I don't like the sound of that either :)

Yeah, that sounds like overkill to me. I haven't done a lot with 
capabilities myself (it's been a few years, too, when I was contracting 
for a company that did a lot of work in Linux kernel process and resource 
management - some pretty cool tech that unfortunately is now defunct 
because the company went out of business - the kernel mods were OSS, but 
the control daemons were all proprietary).

Jim

-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message

Am 17.05.2016 um 09:18 schrieb scott:
> On 16/05/2016 18:21, Orchid Win7 v1 wrote:
>> On 16/05/2016 01:47 PM, scott wrote:
>>> What's the best way for this root process to "broadcast" to other
>>> (non-root) processes when that pin goes high? It will only happen at
>>> maximum frequency of about every 2 seconds, but any delay between the
>>> pin going high and the other processes seeing it should be minimal.
>>
>> So you're mostly worried about latency. (?)
> 
> Yes, but we're talking a tenth of a second being fine here, microseconds
> are not needed!

In that case, by all means do pick whatever method you find easiest to
wrap your head around. Tenths of a second, that's an eternity even for a
Raspi.

Alternatively, pick whatever method you most like to learn more about.

Dbus and MPI are certainly overpowered for your purpose; from what I
know, dbus is primarily geared towards high-performance bulk data
transfer (real-time audio signals would be a showcase example), and MPI
is actually a high-level interface standard to other inter-process comm
technology such as TCP/IP, dbus, or whatever.

Post a reply to this message

On 17/05/2016 08:18 AM, scott wrote:
> Thanks for the ideas everyone.

No problem. I enjoy interesting problems. ;-)

> Just looked up named pipes - it seems you can only have a single
> "reader"? I need more than one process to be able to see the signal.

Yeah, you would need one named pipe per process.

> Sockets should work ok, or as you state, just create/delete an empty
> file somewhere. I'll have to experiment.

Good luck. ;-)

> I guess at some point I might
> want to expand the signal to more than one pin, so being able to
> communicate an "int" rather than a "bool" would actually be more scalable.

Sure thing. I can certainly understand that. Putting the contents into a 
small file seems the simplest way. (I'm not 100% sure of the semantics 
of multiple processes accessing a file concurrently - unless it's via 
mmap...)

Post a reply to this message

>>> PIGPIO and GPIOZERO don't need root anymore, the user just needs to be in the
>>> gpio group
>>
>> Yes I did read that (and tried following the instructions to update), but either it
doesn't work or (more likely) I didn't update properly everything that needs updating.
If it worked, it would obviously be the most trivial solution to implement.
>>
>> I might just get another SD card and put the latest version of raspbian on there,
if that works OK then I'll copy over all necessary files from the old one.
>>
>
> If the current user is added to a group, it must relog to see the effect (current
session is not updated when such change occurs)

I'm pretty sure I did that, but anyway there are some issues with the pi 
camera (it stops responding after anywhere between 100000 - 400000 
photos being taken and needs a power cycle) so a newer build hopefully 
fixes that too.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> [snip]
> I'm pretty sure I did that, but anyway there are some issues with the pi
> camera (it stops responding after anywhere between 100000 - 400000
> photos being taken and needs a power cycle) so a newer build hopefully
> fixes that too.

Regarding the camera stopping, theres been a bug exposed lately with the V2
camera, concerning the I2C control bus of the camera. There's a fix in the
pipeline. https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=147744

Regarding you IPC problem, generally I'd go for unix domain sockets. They behave
like network sockets, but are located in the file system.

Regards
Aydan

Post a reply to this message

> Regarding the camera stopping, theres been a bug exposed lately with the V2
> camera, concerning the I2C control bus of the camera. There's a fix in the
> pipeline. https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=147744

Glad to know it's an actual bug that's been worked on. Took me a long 
time to figure out it was the camera just not responding rather than an 
error I had made in my code. I currently have it set up to reboot itself 
every day at 2am which has fixed it, a bit of a bodge though.

Post a reply to this message

On 18/05/2016 09:26 AM, scott wrote:
> Glad to know it's an actual bug that's been worked on. Took me a long
> time to figure out it was the camera just not responding rather than an
> error I had made in my code. I currently have it set up to reboot itself
> every day at 2am which has fixed it, a bit of a bodge though.

I recently read about a similar firmware bug in a security camera. It 
reboots itself every night at midnight.

I can't *imagine* how a security camera temporarily turning itself off 
at a predictable moment every single night could *possibly* be a 
problem... :-P

Post a reply to this message