Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re^12: Controlling USB on Raspberry Pi

by afoken (Chancellor)
on Dec 13, 2020 at 14:32 UTC ( [id://11125110]=note: print w/replies, xml ) Need Help??


in reply to Re^11: Controlling USB on Raspberry Pi
in thread Controlling USB on Raspberry Pi

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; }

Alexander

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

Replies are listed 'Best First'.
Re^13: Controlling USB on Raspberry Pi
by afoken (Chancellor) on Dec 13, 2020 at 16:10 UTC
    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". ;-)
Re^13: Controlling USB on Raspberry Pi
by Bod (Parson) on Dec 13, 2020 at 16:31 UTC
    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; }
    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". ;-)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11125110]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others sharing their wisdom with the Monastery: (6)
As of 2024-03-28 22:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found