http://qs1969.pair.com?node_id=11125067


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

"I have found a review on Amazon that says it is Plug-and-Play and implies that it 'just works'. Although I have it plugged into a Windows 10 laptop which recognises it correctly but doesn't give me any clues other than it is successfully configured using a generic driver utilising input.inf which is a start but not very helpful."

Amazon reviews are the most gamed reviews on the planet, and are generally worthless when it comes to anything technical. Plug and Play could mean many things, depending on who is doing what with whatever. I agree with what stevieb has said, this is a lot easier with off the shelf microcontrollers, and you can bet that someone has already done exactly what you want, in a way that is fairly easy to adapt or build upon (like the methods I previously linked to). If you want to jump in and get your hands dirty with rolling your own, this is of course fine, but don't use Amazon reviews as a substitute for actual research, and expect to have to do a lot of that, research.

Replies are listed 'Best First'.
Re^9: Controlling USB on Raspberry Pi
by Bod (Curate) on Dec 12, 2020 at 19:39 UTC

    If you want to jump in and get your hands dirty with rolling your own, this is of course fine, but don't use Amazon reviews as a substitute for actual research, and expect to have to do a lot of that, research.

    Oh you of little faith 😜

    I have found this on GitHub which has been installed and allows the USB module to be controlled from the command line. Meanwhile, installing HiPi and RPi::WiringPi has taken 6 hours so far and is still going...lots of dependencies and some warnings about casting between types that look very C'ish to me...

      Meanwhile, installing HiPi and RPi::WiringPi has taken 6 hours so far and is still going

      You don't need any of that for slow GPIO. Writing to files below /sys/class/gpio/ is completely sufficient. See Re: Controlling USB on Raspberry Pi and https://pinout.xyz/ for GPIO numbers.

      Alexander

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

        Thanks afoken - that article was very, very useful and has moved me forward a long way. Probably far enough to complete the project.

        I am slightly stuck on the "best way" for a Perl program to interact with the underlying system. I have written a test script that works but not how I originally intended.

        #!usr/bin/perl use strict; open my $export, '>', "/sys/class/gpio/export" || die "Unable to open +export"; print $export "20"; close $export; open my $direction, '>', "/sys/class/gpio/gpio20/direction" || die "Un +able to open direction"; print $direction "out\n"; close $direction; open (my $value, '>', "/sys/class/gpio/gpio20/value") || die "Unable t +o open value"; sleep(1); print $value "0"; print "ON\n"; sleep(1); print $value "1"; print "OFF\n"; close $value;

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

        The relay on GPIO 20 switches on when the script starts. 1s later "ON" is written to STD and then a further 1s later, "OFF" is printed and the relay switches off. 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;. Strangely, it is necessary to set the direction even though it is already set before the script starts and remains set afterwards and the act of setting the direction switches on the relay.

        So I have looked at the source code for HiPi which uses a combination of system calls to echo and sysopen. I've also looked at RPi::WiringPi which again uses system but this time calls the RPi utility gpio and also uses `echo.

        I've been led to believe that system should not really be necessary in Perl if it is calling something like echo and I would rather implement a more Perlish solution. So some guidance would be very welcome.

        If I were to use sysopen instead of open and therefore interact with the filesystem at a lower level, is it likely that I would be able to set the direction without changing the state of the relay at the same time?

        You don't need any of that for slow GPIO

        I wasn't paying attention it seems...
        Now to do some reading!

      This isn't a question of faith. Had you researched this, you'd have know about this before buying the kit and asking questions here, or being confused by reviews on Amazon, and telling us that a datasheet didn't show up with the device, even though that's almost never going to happen.