First time here? Check out the FAQ!
1

I2C problem with remote Raspberry pi

I am running WingIDE6.0 remotely connected to a Raspberry Pi. I can run a normal program no problem so I know it works. I have a program that imports smbus for I2C access. The program runs fine from the RPi console but,when I run it using Wing IDE I get an error which is:

IOError: [Errno 13] Permission denied.

Now, I can see that is it a permissions issue - but why? I have added the user to the i2c group but that didn't change things. The Wing IDE connection is SSH with keys (is no password) and it is the same user as the RPi login so there should not be a problem with permissions.The actual instruction that fails is:

 self._bus = smbus.SMBus(twi)

If this is a restriction for some reason then I'm stuck as I do a lot of native I/O on the RPi.

dgoadby's avatar
46
dgoadby
asked 2017-03-05 20:41:00 -0500
Wingware Support's avatar
4.1k
Wingware Support
updated 2019-03-13 10:20:46 -0500
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

4 Answers

0

My guess is when you're logged into the Raspberry Pi you are running the code with sudo and this is not being done by Wing's remote agent.  Probably the solution is setting access permissions so the user can access it without sudo.  The selected answer for http://stackoverflow.com/questions/34... and the document it links to may be what you need.

Wingware Support's avatar
4.1k
Wingware Support
answered 2017-03-05 21:03:00 -0500
edit flag offensive 0 remove flag delete link

Comments

add a comment see more comments
0

Actually I'm not running as sudo. Earlier i2c implementations did require sudo or equivalent but I'm just running the program using: python test-prog.py as per normal. It's 3am in the UK so I'm off top bed now but, when I return to the problem later today I will just check the permissions. 

The article you referenced is dated 12/2015 and that referred to a 2012 article so it is probably before the later smbus implementation but I will check and report back.

Thanks for a speedy reply BTW.

David

dgoadby's avatar
46
dgoadby
answered 2017-03-05 22:05:00 -0500
Wingware Admin's avatar
231
Wingware Admin
updated 2019-03-07 07:02:18 -0500
edit flag offensive 0 remove flag delete link

Comments

add a comment see more comments
1

Ok, now were are sorted! And permissions is the problem. A quick fix is to change the permissions of /dev/i2c-1  or /dev/i2c-0  (depends on rpi model) with the command:

sudo chmod a+rw /dev/i2c-*

This is temporary and is lost at next boot so, to fix it permanently you need to do the following:

Edit the file /etc/udev/rules.d/99-com.rules

If this line exists:

SUBSYSTEM=="ic2-dev", GROUP="i2c", MODE="0660"

then change the MODE to "0666".

If it does not exist then add it with the MODE="0666" and also note the "==".

Reboot.

NOTE: My system is RPi3. For other variants the file in /etc/udev/rules.d may have a different name so check them all to find the one with the entry you need to change.  Also, the entry may say KERNEL instead of SUBSYSTEM depending on you Debian version. The important thing to find is the line with "i2c-dev" in it. After making the above changes you can use WingIDE on RPi with i2c devices actually working natively. For debugging it's worth every penny.

Following on from my experiences with i2c, the situation is much the same for GPIO, and the fix much the same.The "quick fix" is: sudo chmod a+rw /dev/gpiomemFor the permanent fix the entry will be something like SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660".  As before change the MODE to "0666".That's it, i2c and GPIO working with WingIDE.

If you happen to need the spi bus then, assuming you have enabled it using sudo raspi-config, you will need to make the same changes to the entry with "spidev" in it.

David

dgoadby's avatar
46
dgoadby
answered 2017-03-06 13:06:00 -0500
Wingware Admin's avatar
231
Wingware Admin
updated 2019-03-07 07:03:56 -0500
edit flag offensive 0 remove flag delete link

Comments

Thanks for posting this!  You may want to select this answer as the accepted answer for this question.

Wingware Support's avatar Wingware Support (2017-03-07 14:35:00 -0500) edit
add a comment see more comments
0

When the current user lacks the necessary permissions to access a file or directory. To resolve this issue, you can check the file or directory permissions, ensuring that the user has appropriate read, write, or execute permissions. Verify ownership, making sure the user is the owner or belongs to a group with sufficient permissions. If accessing system files, run the program or script with administrative privileges. Check if the file is currently in use by another process and close any applications that might have it locked. Ensure that the parent directory allows write access if you are creating or modifying a file within it. Antivirus or security software can also restrict access, so temporarily disable or configure it accordingly.

ronaldgevern's avatar
1
ronaldgevern
answered 2023-06-07 01:02:17 -0500
edit flag offensive 0 remove flag delete link

Comments

add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer