PiFaceCAD with PiFaceRelayPlus

[SailingGreg]

I've been looking at adding relays to a system that uses a PiFaceCAD and a B+ board. I thought the RelayPlus would be suitable as it is HAT compatible and the CAD can be attached on the top keeping basically the same form factor which is nice and compact.

I can access both the PiFaceCAD the RelayPlus in isolation but when I initiatlise them in the same python app the call back on the CAD buttons stop working. It leaves the CAD is an inconsistent state and it needs power cycle to reset it

Any thoughts/comments?

[tompreston]

Hey,
I can't seem to get interrupts working either now. See: piface/pifacecad#16 (comment)

The problem appears to be with epoll and not the SPI driver (which appears to be working fine since I can talk to my board).

Do you interrupts work with the latest software (apt-get update/upgrade)? I'm afraid I won't be able to help with this issue until interrupts are fixed in general.

[SailingGreg]

Thomas, that is the sort of behavior I was seeing before I sorted the SPI
driver out on the latest kernel (after a apt-get update/upgrade cycle) - I
could still talk to the board as the display updated when the python code
ran but none of the keys worked. What appeared to happen is the state was
held and if I interrupted and reran the programme it appear to get a key
press and the display would update. I addressed this via dtoverlay in the
/boot/config.txt and then the interrupts worked.

Have you check which version of the spi driver you are running - dmesg|grep
spi - see http://forum.kodi.tv/showthread.php?pid=2016570 and the following

2015-05-30 14:19
Post: #950
http://forum.kodi.tv/showthread.php?tid=224025&pid=2016551#pid2016551
No idea either why SPI is built into the kernel in OpenELEC. I also think
having both SPI drivers built as modules makes more sense and IMHO that
should be safe.

The last 2 days I did various tests with my cirrus OpenELEC build having
SPI drivers built as modules and haven't noticed any issues.

Just did another test with the cirrus dtoverlay removed from config.txt so
it's very near to your build:

With dtparam=spi=on /dev/spidev0.{0,1} show up fine and lsmod/dmesg show
that the new driver is used
Code:
OpenELEC:~ # lsmod | grep spi
spi_bcm2835 3659 0
OpenELEC:~ # dmesg | grep -i spi
[ 5.608210] spi spi0.0: setting up native-CS0 as GPIO 8
[ 5.618668] spi spi0.1: setting up native-CS1 as GPIO 7

When also adding dtoverlay=spi-bcm2708 to use the old driver the device
nodes show up fine again and lsmod/dmesg output is also as expected
Code:
OpenELEC:~ # lsmod | grep -i spi
spi_bcm2708 4682 0
OpenELEC:~ # dmesg | grep spi
[ 5.563134] bcm2708_spi 3f204000.spi: master is unqueued, this is
deprecated
[ 5.605692] bcm2708_spi 3f204000.spi: SPI Controller at 0x3f204000 (irq
80)

I think you should be safe switching to modules in you next regular
testbuild, don't think we'll need another intermediate build.

so long,

Hias

On 8 September 2015 at 15:09, Thomas Preston [email protected]
wrote:

Hey,
I can't seem to get interrupts working either now. See: piface/pifacecad#16
(comment)
piface/pifacecad#16 (comment)

The problem appears to be with epoll and not the SPI driver (which appears
to be working fine since I can talk to my board).

Do you interrupts work with the latest software (apt-get update/upgrade)?
I'm afraid I won't be able to help with this issue until interrupts are
fixed in general.

—
Reply to this email directly or view it on GitHub
#1 (comment)
.

[SailingGreg]

Thomas, I've checked my code https://github.com/SailingGreg/startTimer and
startTimer.py works. The key presses update the display, but if I setup
gpio25 along the following lines and query it I don't see any transitions

Bring GPIO25 into userspace and check it's value:

$ echo 25 > /sys/class/gpio/export
$ more /sys/class/gpio/gpio25/value
1

Now check its value after pressing switch 0:

$ more /sys/class/gpio/gpio25/value
0

On 8 September 2015 at 17:35, Greg Brougham [email protected] wrote:

Thomas, that is the sort of behavior I was seeing before I sorted the SPI
driver out on the latest kernel (after a apt-get update/upgrade cycle) - I
could still talk to the board as the display updated when the python code
ran but none of the keys worked. What appeared to happen is the state was
held and if I interrupted and reran the programme it appear to get a key
press and the display would update. I addressed this via dtoverlay in the
/boot/config.txt and then the interrupts worked.

Have you check which version of the spi driver you are running -
dmesg|grep spi - see http://forum.kodi.tv/showthread.php?pid=2016570 and
the following

2015-05-30 14:19
Post: #950
http://forum.kodi.tv/showthread.php?tid=224025&pid=2016551#pid2016551
No idea either why SPI is built into the kernel in OpenELEC. I also think
having both SPI drivers built as modules makes more sense and IMHO that
should be safe.

The last 2 days I did various tests with my cirrus OpenELEC build having
SPI drivers built as modules and haven't noticed any issues.

Just did another test with the cirrus dtoverlay removed from config.txt so
it's very near to your build:

With dtparam=spi=on /dev/spidev0.{0,1} show up fine and lsmod/dmesg show
that the new driver is used
Code:
OpenELEC:~ # lsmod | grep spi
spi_bcm2835 3659 0
OpenELEC:~ # dmesg | grep -i spi
[ 5.608210] spi spi0.0: setting up native-CS0 as GPIO 8
[ 5.618668] spi spi0.1: setting up native-CS1 as GPIO 7

When also adding dtoverlay=spi-bcm2708 to use the old driver the device
nodes show up fine again and lsmod/dmesg output is also as expected
Code:
OpenELEC:~ # lsmod | grep -i spi
spi_bcm2708 4682 0
OpenELEC:~ # dmesg | grep spi
[ 5.563134] bcm2708_spi 3f204000.spi: master is unqueued, this is
deprecated
[ 5.605692] bcm2708_spi 3f204000.spi: SPI Controller at 0x3f204000 (irq
80)

I think you should be safe switching to modules in you next regular
testbuild, don't think we'll need another intermediate build.

so long,

Hias

On 8 September 2015 at 15:09, Thomas Preston [email protected]
wrote:

Hey,
I can't seem to get interrupts working either now. See: piface/pifacecad#16
(comment)
piface/pifacecad#16 (comment)

The problem appears to be with epoll and not the SPI driver (which
appears to be working fine since I can talk to my board).

Do you interrupts work with the latest software (apt-get update/upgrade)?
I'm afraid I won't be able to help with this issue until interrupts are
fixed in general.

—
Reply to this email directly or view it on GitHub
#1 (comment)
.

[SailingGreg]

I've gone back and taken the dtoverlay out of /boot/config.txt and rerun
the tests and the interrupts still work. In the program works and in
python3 the bin() operations are okay which is consistent with your view
that it is not the spi driver. I may need to do a clean install

On 8 September 2015 at 18:19, Greg Brougham [email protected] wrote:

Thomas, I've checked my code https://github.com/SailingGreg/startTimer
and startTimer.py works. The key presses update the display, but if I setup
gpio25 along the following lines and query it I don't see any transitions

Bring GPIO25 into userspace and check it's value:

$ echo 25 > /sys/class/gpio/export
$ more /sys/class/gpio/gpio25/value
1

Now check its value after pressing switch 0:

$ more /sys/class/gpio/gpio25/value
0

On 8 September 2015 at 17:35, Greg Brougham [email protected]
wrote:

Thomas, that is the sort of behavior I was seeing before I sorted the SPI
driver out on the latest kernel (after a apt-get update/upgrade cycle) - I
could still talk to the board as the display updated when the python code
ran but none of the keys worked. What appeared to happen is the state was
held and if I interrupted and reran the programme it appear to get a key
press and the display would update. I addressed this via dtoverlay in the
/boot/config.txt and then the interrupts worked.

Have you check which version of the spi driver you are running -
dmesg|grep spi - see http://forum.kodi.tv/showthread.php?pid=2016570 and
the following

2015-05-30 14:19
Post: #950
http://forum.kodi.tv/showthread.php?tid=224025&pid=2016551#pid2016551
No idea either why SPI is built into the kernel in OpenELEC. I also think
having both SPI drivers built as modules makes more sense and IMHO that
should be safe.

The last 2 days I did various tests with my cirrus OpenELEC build having
SPI drivers built as modules and haven't noticed any issues.

Just did another test with the cirrus dtoverlay removed from config.txt
so it's very near to your build:

With dtparam=spi=on /dev/spidev0.{0,1} show up fine and lsmod/dmesg show
that the new driver is used
Code:
OpenELEC:~ # lsmod | grep spi
spi_bcm2835 3659 0
OpenELEC:~ # dmesg | grep -i spi
[ 5.608210] spi spi0.0: setting up native-CS0 as GPIO 8
[ 5.618668] spi spi0.1: setting up native-CS1 as GPIO 7

When also adding dtoverlay=spi-bcm2708 to use the old driver the device
nodes show up fine again and lsmod/dmesg output is also as expected
Code:
OpenELEC:~ # lsmod | grep -i spi
spi_bcm2708 4682 0
OpenELEC:~ # dmesg | grep spi
[ 5.563134] bcm2708_spi 3f204000.spi: master is unqueued, this is
deprecated
[ 5.605692] bcm2708_spi 3f204000.spi: SPI Controller at 0x3f204000
(irq 80)

I think you should be safe switching to modules in you next regular
testbuild, don't think we'll need another intermediate build.

so long,

Hias

On 8 September 2015 at 15:09, Thomas Preston [email protected]
wrote:

Hey,
I can't seem to get interrupts working either now. See: piface/pifacecad#16
(comment)
piface/pifacecad#16 (comment)

The problem appears to be with epoll and not the SPI driver (which
appears to be working fine since I can talk to my board).

Do you interrupts work with the latest software (apt-get
update/upgrade)? I'm afraid I won't be able to help with this issue until
interrupts are fixed in general.

—
Reply to this email directly or view it on GitHub
#1 (comment)
.

[SailingGreg]

Thomas, noticed that init_epoll(void) in libmcp23s17.c, line 226 you open
the file readonly and nonblocking

gpio_pin_fd = open(gpio_pin_filename, O_RDONLY | O_NONBLOCK);

In the code fragment you used you do not specify not blocking on the open
or change the file control

gpio25 = open('/sys/class/gpio/gpio25/value', 'r')

On 8 September 2015 at 15:09, Thomas Preston [email protected]
wrote:

Hey,
I can't seem to get interrupts working either now. See: piface/pifacecad#16
(comment)
piface/pifacecad#16 (comment)

The problem appears to be with epoll and not the SPI driver (which appears
to be working fine since I can talk to my board).

Do you interrupts work with the latest software (apt-get update/upgrade)?
I'm afraid I won't be able to help with this issue until interrupts are
fixed in general.

—
Reply to this email directly or view it on GitHub
#1 (comment)
.

[SailingGreg]

Thomas, just checking to see if there has been any progress. Are there any
updates?

Regards

Greg.

On 8 September 2015 at 15:09, Thomas Preston [email protected]
wrote:

Hey,
I can't seem to get interrupts working either now. See: piface/pifacecad#16
(comment)
piface/pifacecad#16 (comment)

The problem appears to be with epoll and not the SPI driver (which appears
to be working fine since I can talk to my board).

Do you interrupts work with the latest software (apt-get update/upgrade)?
I'm afraid I won't be able to help with this issue until interrupts are
fixed in general.

—
Reply to this email directly or view it on GitHub
#1 (comment)
.

[tompreston]

I'm afraid not. It looks like some people have had some success with root in that other thread which suggests that this is a permissions issue but I haven't checked over it myself. My post in that thread was an information dump of everything I've got at the minute - until I can get epoll to return then this issue is stuck.

[SailingGreg]

Have you had a chance to look at the permissions/group ownership?

On 28 September 2015 at 13:58, Thomas Preston [email protected]
wrote:

I'm afraid not. It looks like some people have had some success with root
in that other thread
piface/pifacecad#16 (comment)
which suggests that this is a permissions issue but I haven't checked over
it myself. My post in that thread was an information dump of everything
I've got at the minute - until I can get epoll to return then this issue is
stuck.

—
Reply to this email directly or view it on GitHub
#1 (comment)
.