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

> 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

You just need to buy their other camera, which reboots at 2am, and run 
both next to each other :-)

Post a reply to this message

On 19/05/2016 09:49 AM, scott wrote:
>> 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
>
> You just need to buy their other camera, which reboots at 2am, and run
> both next to each other :-)

To be fair, the main point of the article in question was that the 
password to the camera's wire protocol was "12345". Hard-coded in 
firmware. Cannot change it. Both the camera and the control terminal 
have this hard-wired in firmware.

Then again, it was a dirt-cheap Chinese import.

(Presumably there are high-quality Chinese items somewhere... these are 
not the ones I'm talking about.)

Post a reply to this message