I would expect the relay to switch on at the same time as "ON" is printed - in other words 1s later than it does. Doing a bit of experimenting shows that it actually switches on not at print $value "0"; but when the direction is set to out at close $direction;.

The files in /sys/ are actually kernel drivers, much like in /proc/. Those file-based drivers are rather simple-minded and desigend to use by shell scripts, where each echo foo > /proc/some/magic/file ends in calling open(2), write(2), and close(2). So you should simulate that behaviour.

At work, I had a client project where a Raspi was involved, running a daemon for a different purpose. Some more I/Os were needed, and so I added a tiny C module that implemented functions to configure and functions to set pins. Both just simulated a shell echo, i.e. called open, write, close. I/O switching was fast enough not to see a delay with the naked eye, so probably below 100 msec.

Rewriting your code like this should help:

#!/usr/bin/perl 

# untested!

use strict;
use warnings;
use feature "say";

sub write_file
{
    my ($fn,$content)=@_;
    open my $f,'>',$fn or die "Could not open $fn: $!";
    say $f $content;
    close $f;
}

sub export
{
    my $number=shift;
    write_file("/sys/class/gpio/export",$number);
}

sub direction
{
    my ($number,$dir)=@_;
    write_file("/sys/class/gpio/gpio$number/direction",$dir);
}

sub write_value
{
    my ($number,$level)=@_;
    write_file("/sys/class/gpio/gpio$number/value",$level);
}

sub read_file # unused
{
    open my $f,'<',$fn or die "Could not open $fn: $!";
    my $line=<$f>;
    close $f;
    chomp $line;
    return $line;
}

sub read_value # unused
{
    my $number=shift;
    return read_file("/sys/class/gpio/gpio$number/value");
}

# all of the functions above could move to a module 

export(20);
direction(20,"out");

while (1) {
    write_value(20,0);
    say "on";
    sleep 1;
    write_value(20,1);
    say "off";
    sleep 1;
}
[download]

Alexander

The files in /sys/ are actually kernel drivers, much like in /proc/. Those file-based drivers are rather simple-minded and desigend to use by shell scripts, where each echo foo > /proc/some/magic/file ends in calling open(2), write(2), and close(2). So you should simulate that behaviour.

I completely forgot to mention that perl and/or the C library try to AVOID writing files, because writing files is slow (compared to writing to RAM). So, there is at least one layer of caching between your program and the kernel drivers. That cache needs to be flushed for the kernel drivers to see your program writing to the virtual files. Simply closing the file handle is the easiest way to do that. $| (autoflush) would probably also work. But as shown, just closing the file also avoids having unused file handles lingering around.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Rewriting your code like this should help

Thank you...
That has given me confidence that I am going in the right direction :)

There's a definition issue on read_file but that is unused so I have commented it out to test it. As I expected, but cannot explain, your code works as expected provided the GPIO is already exported. Your export code doesn't work and fails with Could not open /sys/class/gpio/gpio20/direction: Permission denied at afoken.pl line 12.

The module I am creating has the same issue. In it's constructor I am exporting the two GPIO pins - except I cannot do it by writing to the psuedo files. The only way I have found thus far is a system call to the gpio utility.

package Curtains::Control;

use strict;

my $path  = '/sys/class/gpio';
my $o_pin = 20;
my $c_pin = 21;

sub new {
#    open my $export, '>', "$path/export" or die("Unable to export the
+ control pins");
#    print $export "$o_pin\n";
#    print $export "$c_pin\n";
#    close $export;

    system("gpio export $o_pin high");
    system("gpio export $c_pin high");
    
    my $state = {
        STATE => 'UNKNOWN',
    };
    
    return bless $state;
}
[download]

If I uncomment the four lines at the start of sub new, then it works if the GPIO pins are already exported. This bit of code does not export them although I do not get an error here. I get an error further down the line when I try to change them. Making the system calls works well because I can initialise the state at the same time but I was still wanting to avoid system if I could...
Perhaps that will be a later update to the software!

There's a definition issue on read_file but that is unused so I have commented it out to test it.

Yes, it's missing my $fn=shift; as the first line of read_file(). As I wrote: untested.

As I expected, but cannot explain, your code works as expected provided the GPIO is already exported. Your export code doesn't work and fails with Could not open /sys/class/gpio/gpio20/direction: Permission denied at afoken.pl line 12.

I have burried my spare Raspi unter tons of stuff, so I can't reproduce that at the moment. But I have two ideas why that happens:

• You are using a non-privileged account (i.e. not root), but /sys/class/gpio/*/* is writable only by root. Either run as root (bad) or change the permissions on sysfs. It seems the way to do so is udev (see https://unix.stackexchange.com/questions/68897/ and https://unix.stackexchange.com/questions/20125/). For tests, you also could work as root. But sooner or later, you will need to address the permission issue. On the other hand, if the Raspi just gets its time via NTP and does nothing else on the network, running as root is not that big issue.
• There may be a delay between export and actually creating the files in the sysfs filesystem, so your code may be too fast. Sleep for a few milliseconds after exporting and before accessing the new export.

I just had a look at the source code of the daemon mentioned in Re^12: Controlling USB on Raspberry Pi. It runs as root, so permission checks are effectively off. The source code does write a lot of debug output, so there is definitively a delay between exporting and setting direction.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

" I've also looked at RPi::WiringPi which again uses system but this time calls the RPi utility gpio and also uses `echo`".

The *only* place RPi::WiringPi shells out with system is where there is no other API call that can perform the tasks. Note that where you see system calls is only when operating the disk I/O LED and power LED, and in a couple of pieces of functionality to manually exporting and un-exporting pins. These calls are very, very rarely used in normal operation, and are literally for functionality I use to have, but removed it from public use, so realistically, they are now developer only functions.

All GPIO functions, including interrupts and PWM are direct C calls that manipulate the hardware registers directly. This provides a vast increase in speed and performance, especially when dealing with more time sensitive operations.

Just wanted to clear that up.

RPi::WiringPi is a distribution that manages a couple dozen other distributions. The GPIO pin functionality is found in RPi::Pin. Almost all of the core functionality that performs tasks on the Pi itself are run through my WiringPi::API C/C++ library. The only functionality that's within the main RPi::WiringPi distribution are board-level functions, utility and helper functions, and code to load up all of the other various distributions for pins, ICs, devices etc. Have a look at the RPi:: distributions in my CPAN directory to get a bit better understanding of what I mean.

Way too much file system work.

use warnings;
use strict;

use RPi::Pin;
use RPi::Const qw(:all);

my $curtain_relay_pin = 5;
 
my $pin = RPi::Pin->new($curtain_relay_pin);
 
$pin->mode(OUTPUT);

if (...) {
    $pin->write(LOW);  
}
elsif ($pin->read == LOW) {
    $pin->write(HIGH);
}
[download]

Done. That assumes an active low relay. No need for super user access whatsoever. No touching of the file system whatsoever. Executed in fast C code that has access directly to the GPIO registers. No need for the entire RPi::WiringPi either. However, you don't get the pin security and cleanup that's provided by the encompassing distribution, but I digress.

The RPi::Pin module provides access to all related GPIO pin functionality... pull up/down resistors, PWM, interrupts, setting of alternate pin modes etc.

"The relay is designed such that it switches ON when the GPIO pin is taken low."

For your information, when a device is on/enabled when the GPIO goes LOW, that's called "Active Low", so the relay is known to be an "active low relay". "Active High" is exactly the opposite.