Problems with GPIO on Pi MusicBox

Pi MusicBox
#1

Can anyone offer a suggestion here? I’m having problems setting a GPIO output pin on my MusicBox

I have a Raspberry Pi 2 B, with a HiFiBerry DAC+, running Pi MusicBox 0.6 with python GPIO 0.5.11

As far as I can discover, the HiFiBerry DAC+ uses GPIO2-3 (and possibly 6) and 18-21, so I think I should be able to set GPIO25 (header pin 22) as an output, but the test case (below) does not work - I just get a list of messages like this:

root@BerryBox:/myProject# sudo python testcase.py
testcase.py:13: RuntimeWarning: This channel is already in use, continuing anyway.  Use GPIO.setwarnings(False) to disable warnings.
  GPIO.setup(outpin, GPIO.OUT)
should be 1, state=0
should be 0, state=0
should be 1, state=0
should be 0, state=0
should be 1, state=0
should be 0, state=0
should be 1, state=0
should be 0, state=0
...etc

Is there something in MusicBox or Mopidy that is already using this (and other) GPIO pins? I didn’t measure any signal on that pin with a multimeter so I tried reading the output after I had written it, shown in the python script below. The output simply never gets set to “1” - I tried removing the HiFiBerry DAC and it still didnt work, so is there something in MusicBox that is somehow using the pin? the “channel already in use” warning seemed to be pointing that way?

# test case: why is the output GPIO pin never set?

import RPi.GPIO as GPIO
import time

GPIO.setmode(GPIO.BOARD)
#GPIO.setwarnings(False)

#HiFiBerry uses GPIO2,3,6 and 18-21

outpin=22 # GPIO 25
GPIO.setup(outpin, GPIO.OUT)

while True:
  GPIO.output(outpin, True)
  print "should be 1, state=%d" % (GPIO.input(outpin))
  time.sleep(1)
  
  GPIO.output(outpin, False)
  print "should be 0, state=%d" % (GPIO.input(outpin))
  time.sleep(1)

I’ve tried this test case on another Pi which isn’t running MusicBox, and it works there, confirming that its OK to read an input from an output pin, as described here:
http://sourceforge.net/p/raspberry-gpio-python/wiki/Outputs/

So, I think it must be MusicBox/Mopidy getting in the way. I’m probably missing something really obvious. Can anyone see it?

Thanks

#2

As you setup that pin as output I don’t think you can read state. Maybe this is why you are getting always 0.
I would try to put a led in the GPIO to see if it’s working or not.
If you don’t have a led you could try this to check with the SD card access led.

#3

Thanks, but I started out with a LED and only resorted to the other stuff when that didn’t work.

It should be OK to read an input from an output pin, as described here:
http://sourceforge.net/p/raspberry-gpio-python/wiki/Outputs/

Good trick with the green LED, by the way, but it doesn’t really help here.

Thanks all the same.

#4

new information:

I commented-out the MusicBox startup in rc.local, and it still didn’t work, so its not Mopidy or the Musicbox s/w itself

I swapped SD card with another Pi that works, and my GPIO test case WORKED!! (with the HiFiBerry DAC+ still connected), so its not hardware problem.

So I think it is some software that isloaded during startup and distributed in the MusicBox 0.6 image.

Has anyone else succeeded in using GPIO pins with the MusicBox 0.6 image?

thanks

  • Graeme
#5

Don’t you need to load a kernel driver to control the gpio? We might
blacklist it, can’t remember. We also don’t use device tree overlays, so
check if you are relying on that to load your driver.

#6

That sounds very likely - exactly the sort of thing I’ve overlooked. I don’t know much about Linux drivers or overlays, but now is the time to find out. I’ll look into it over the next few days - thanks very much for the suggestion.

1 Like
#7

I’ve been using the GPIO pins to control an LED display:

But I have been seeing that same error code when the extension ttsgpio loads (and some problems getting it to work).

RuntimeWarning: This channel is already in use, continuing anyway.  Use GPIO.setwarnings(False) to disable warnings.

I’m very interested to see what you find, please keep me updated with any progress!

Let me know if I can help in any way.

Thanks!

#8

Nice LEDs, Lunz! Giving me ideas here…

Thanks for the offer of help; could you let me know what version of the MusicBox image you loaded onto your SD card (I have 0.6), the Pi model (I have a PI 2 B, with a HiFiBerry DAC+), and the drivers currently loaded (from the “lsmod” command). For comparison, here is what Iget:

Module                  Size  Used by
iptable_filter          1268  1
xt_REDIRECT             1917  1
xt_tcpudp               2132  2
iptable_nat             1843  1
nf_conntrack_ipv4      13435  1
nf_defrag_ipv4          1279  1 nf_conntrack_ipv4
nf_nat_ipv4             4935  1 iptable_nat
nf_nat                 12675  2 nf_nat_ipv4,xt_REDIRECT
nf_conntrack           78034  3 nf_nat,nf_nat_ipv4,nf_conntrack_ipv4
ip_tables              11526  2 iptable_filter,iptable_nat
x_tables               13674  4 ip_tables,xt_tcpudp,iptable_filter,xt_REDIRECT
snd_soc_hifiberry_dacplus     2737  0
ctr                     3709  2
ccm                     7771  2
bcm2708_wdog            2972  1
ipv6                  333229  28
snd_bcm2835            18850  0
arc4                    1745  2
rt2800usb              17898  0
rt2800lib              71839  1 rt2800usb
rt2x00usb               8764  1 rt2800usb
rt2x00lib              37292  3 rt2x00usb,rt2800lib,rt2800usb
snd_soc_bcm2708_i2s     6637  2
snd_soc_pcm512x_i2c     1689  1
snd_soc_wm8804          7354  0
snd_soc_tas5713         5006  0
snd_soc_pcm512x         6340  1 snd_soc_pcm512x_i2c
regmap_mmio             2961  1 snd_soc_bcm2708_i2s
mac80211              483934  3 rt2x00lib,rt2x00usb,rt2800lib
snd_soc_core          140285  5 snd_soc_pcm512x,snd_soc_wm8804,snd_soc_tas5713,snd_soc_hifiberry_dacplus,snd_soc_bcm2708_i2s
regmap_spi              1793  1 snd_soc_wm8804
snd_compress            7610  1 snd_soc_core
regmap_i2c              2354  3 snd_soc_wm8804,snd_soc_pcm512x_i2c,snd_soc_tas5713
snd_pcm_dmaengine       3359  1 snd_soc_core
snd_pcm                75388  5 snd_bcm2835,snd_soc_wm8804,snd_soc_core,snd_pcm_dmaengine
snd_seq                53078  0
cfg80211              395318  2 mac80211,rt2x00lib
snd_seq_device          5628  1 snd_seq
snd_timer              17784  2 snd_pcm,snd_seq
crc_ccitt               1153  1 rt2800lib
rfkill                 16651  2 cfg80211
snd                    51667  8 snd_bcm2835,snd_soc_core,snd_timer,snd_pcm,snd_seq,snd_seq_device,snd_compress
i2c_bcm2708             4990  0

There is no rush, as I will be too busy to tinker with this much for a few days.

Many thanks
Graeme

#9

Also, are you doing gpio.cleanup() at the end of your test script?

#10

Hi,

re: are you doing gpio.cleanup() at the end of your test script?

No; its an infinite loop so there is no normal way to cleanup on termination. I understand what you’re getting at, though - without this, the test script will always report “This channel is already in use” on the second and all subsequent times that it is run. However, it also reports it on the first time that it runs after a clean startup.

That gave me an idea; I modified the test script to display the result of GPIO.gpio_function() before trying to set it up as an output pin. After a clean boot, this reports GPIO.UNKNOWN, which seems to support your suggestion that perhaps the GPIO driver is not loaded, because the pin has not been initialised to its default function (GPOI.IN)

But… (and I have to admit, I don’t really know what I am doing here…)

I’ve tried loading various things that look like GPIO drivers using modprobe but that hasn’t worked so-far. Here’s what I’ve got… anyone got a suggestion?

root@BerryBox:/# # ---- this is whats running
root@BerryBox:/# uname -a
Linux BerryBox 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015 armv7l GNU/Linux

root@BerryBox:/# # ---- doesn't look like any driver is loaded
root@BerryBox:/# lsmod | grep gpio

root@BerryBox:/# # ---- I think I have these choices, but not sure how to load them
root@BerryBox:/# find /lib -iname "*gpio*"
/lib/modules/3.18.7+/kernel/drivers/w1/masters/w1-gpio.ko
/lib/modules/3.18.7+/kernel/drivers/gpio
/lib/modules/3.18.7+/kernel/drivers/gpio/gpio-arizona.ko
/lib/modules/3.18.7+/kernel/drivers/pps/clients/pps-gpio.ko
/lib/modules/3.18.7+/kernel/drivers/media/rc/gpio-ir-recv.ko
/lib/modules/3.18.7-v7+/kernel/drivers/w1/masters/w1-gpio.ko
/lib/modules/3.18.7-v7+/kernel/drivers/gpio
/lib/modules/3.18.7-v7+/kernel/drivers/gpio/gpio-arizona.ko
/lib/modules/3.18.7-v7+/kernel/drivers/pps/clients/pps-gpio.ko
/lib/modules/3.18.7-v7+/kernel/drivers/media/rc/gpio-ir-recv.ko
#11

Hi

I’ve tried and you can see my efforts at

https://github.com/matgallacher/Mopidy-Favourite-Buttons/blob/master/mopidy_favourite_buttons/frontend.py

It is flakey at best though some of this might be my lack of experience with the code and platform and some with the buttons I’m trying to read.

I also see the warnings on startup but it doesn’t seem to have any effect on it working.

FYI the LED code seems to work a whole lot better than the button stuff and although I started with the Musicbox image I’ve updated Mopidy to the latest version.

#12

If you did want some cleanup code to run at the end then you can implement on_stop.

#13

Thanks Mat. I won’t get the chance to try again based on your example for a week or so, but I’ll let you know how I get on.

#14

OK, so I think I have got it working, but I’m not sure why. It does appear to have been some problem with the GPIO driver, which seems to have wanted to use device trees although other posts on this discussion seem to make clear that we don’t want use device trees for the MusicBox.

I edited /boot/config.txt and commented-OUT this line:

device_tree=

and UN-commented this line:

#dtoverlay=hifiberry-dacplus

And now my python test case works (I presume the signals come out of the pins, but I haven’t checked yet!), and so does the MusicBox.

Basically, (I think) I have enabled device trees despite advice to the contrary, everything seems to work, but have I missed something or created some new problem that I haven’t discovered yet?

Thanks for your help by the way (Mat, kingosticks)

#15

You can enable it if you want. But it’s not compatible with the way we
switch between soundcards in settings.ini and that’s why we disable it. In
the future we’ll have to address this we’re not there yet.
GMac https://discourse.mopidy.com/users/gmac
July 31

OK, so I think I have got it working, but I’m not sure why. It does appear
to have been some problem with the GPIO driver, which seems to have wanted
to use device trees although other posts on this discussion seem to make
clear that we don’t want use device trees for the MusicBox.

I edited /boot/config.txt and commented-OUT this line:

device_tree=

and UN-commented this line:

#dtoverlay=hifiberry-dacplus

And now my python test case works (I presume the signals come out of the
pins, but I haven’t checked yet!), and so does the MusicBox.

Basically, (I think) I have enabled device trees despite advice to the
contrary, everything seems to work, but have I missed something or created
some new problem that I haven’t discovered yet?

Thanks for your help by the way (Mat, kingosticks)

#16

Hi Gmac,

RPi 2 running musicbox 0.6

here is my lsmod output:

   Module                  Size  Used by
    iptable_filter          1268  1
    xt_REDIRECT             1917  1
    xt_tcpudp               2132  2
    iptable_nat             1843  1
    nf_conntrack_ipv4      13435  1
    nf_defrag_ipv4          1279  1 nf_conntrack_ipv4
    nf_nat_ipv4             4935  1 iptable_nat
    nf_nat                 12675  2 nf_nat_ipv4,xt_REDIRECT
    nf_conntrack           78034  3 nf_nat,nf_nat_ipv4,nf_conntrack_ipv4
    ip_tables              11526  2 iptable_filter,iptable_nat
    x_tables               13674  4 ip_tables,xt_tcpudp,iptable_filter,xt_REDIRECT
    bnep                   10206  2
    rfcomm                 34707  0
    rtc_ds1307              9658  0
    i2c_dev                 6027  0
    bcm2708_wdog            2972  1
    ipv6                  333229  30
    snd_bcm2835            18850  1
    snd_soc_wm8804          7354  0
    snd_soc_pcm512x_i2c     1689  0
    snd_soc_tas5713         5006  0
    regmap_spi              1793  1 snd_soc_wm8804
    snd_soc_pcm512x         6340  1 snd_soc_pcm512x_i2c
    regmap_i2c              2354  3 snd_soc_wm8804,snd_soc_pcm512x_i2c,snd_soc_tas57                                                                             13
    snd_soc_bcm2708_i2s     6637  0
    regmap_mmio             2961  1 snd_soc_bcm2708_i2s
    snd_soc_core          140285  4 snd_soc_pcm512x,snd_soc_wm8804,snd_soc_tas5713,s                                                                             nd_soc_bcm2708_i2s
    snd_compress            7610  1 snd_soc_core
    snd_pcm_dmaengine       3359  1 snd_soc_core
    snd_pcm                75388  5 snd_bcm2835,snd_soc_wm8804,snd_soc_core,snd_pcm_                                                                             dmaengine
    snd_seq                53078  0
    snd_seq_device          5628  1 snd_seq
    snd_timer              17784  2 snd_pcm,snd_seq
    ecb                     2027  0
    btusb                  20357  0
    snd                    51667  8 snd_bcm2835,snd_soc_core,snd_timer,snd_pcm,snd_s                                                                             eq,snd_seq_device,snd_compress
    bluetooth             287443  11 bnep,btusb,rfcomm
    rfkill                 16651  2 bluetooth
    i2c_bcm2708             4990  0
#17

Hey GMac,

Sorry for my time off the project. Just wanted to say that commenting out device_tree= is letting my GPIO pins work a lot better. I’m not using a soundcard FYI.

I’m not sure what repercussions will occur, but right now things are running smooth.

Thanks,
Lunz

#18

HI Lunz,

yes, it was the (lack of) device tree that was causing the problems all along. I got mine mine working after some more searching found this:

http://www.airspayce.com/mikem/bcm2835/
“For this library to work correctly on RPI2, you MUST have the device tree support enabled in the kernel”

take care
G