Thank you for your input. Upon further testing, my application is working
using Adafruit_BBIO. I must have forgotten a step when I was doing it
manually using python3.
On Fri, Jun 2, 2017 at 8:11 PM, Robert Nelson
wrote:
> On Thu, Jun 1, 2017 at 7:13 PM, Mary
On Thu, Jun 1, 2017 at 7:13 PM, Mary Metelko wrote:
> The Adafruit_BBIO code usage does work when the user is root.
The goal with the Stretch images is to fix that..
Right now the gpio's can be exported/etc by "debian or any user in
"gpio" group" pwm is close, but i
On Thu, Jun 1, 2017 at 5:13 PM, Mary Metelko wrote:
> The Adafruit_BBIO code usage does work when the user is root.
>
Then it's a matter of permissions. Which means you need to adjust
permission forr the user using those applications. Make udev rules for the
hardware
The Adafruit_BBIO code usage does work when the user is root.
Kindest regards,
Mary
> On Jun 1, 2017, at 6:25 PM, William Hermans wrote:
>
>
>
>> On Thu, Jun 1, 2017 at 2:26 PM, Metelko wrote:
>> I have updated my system starting with a base image
On Thu, Jun 1, 2017 at 2:26 PM, Metelko wrote:
> I have updated my system starting with a base image from:
> https://rcn-ee.com/rootfs/2017-04-07/elinux/ubuntu-16.
> 04.2-console-armhf-2017-04-07.tar.xz
> Then updating the kernel: Linux bbb-266a 4.9.30-ti-rt-r37 #1 SMP
I have updated my system starting with a base image from:
https://rcn-ee.com/rootfs/2017-04-07/elinux/ubuntu-16.04.2-console-armhf-2017-04-07.tar.xz
Then updating the kernel: Linux bbb-266a 4.9.30-ti-rt-r37 #1 SMP PREEMPT
RT Sun May 28 15:55:20 UTC 2017 armv7l armv7l armv7l GNU/Linux
I am
I used the following udev rule (similar to William Hermans, without the
pinmux/state changes using a new 'gpio' group).
udev rule:
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio
/sys/class/gpio; chmod -R 770 /sys/class/gpio; chown -R root:gpio
On Apr 27, 2017 9:17 PM, "William Hermans" wrote:
On Thu, Apr 27, 2017 at 7:07 PM, Robert Nelson
wrote:
>
> it's a pretty small patch:
>
> https://patchwork.kernel.org/patch/9177249/raw/
>
> Documentation/pwm.txt |6 --
>
On Thu, Apr 27, 2017 at 7:07 PM, Robert Nelson
wrote:
>
> it's a pretty small patch:
>
> https://patchwork.kernel.org/patch/9177249/raw/
>
> Documentation/pwm.txt |6 --
> drivers/pwm/sysfs.c | 15 ---
> 2 files changed, 16 insertions(+), 5
On Thu, Apr 27, 2017 at 7:16 PM, William Hermans wrote:
>
>
> On Thu, Apr 27, 2017 at 5:06 PM, Robert Nelson
> wrote:
>>
>> It's a little more then that, the first 0 comes from parent:
>>
>> /sys/class/pwm/pwmchip0/pwm-0:0
>>
>>
On Thu, Apr 27, 2017 at 5:06 PM, Robert Nelson
wrote:
> It's a little more then that, the first 0 comes from parent:
>
> /sys/class/pwm/pwmchip0/pwm-0:0
>
> /sys/class/pwm/pwmchipA/pwm-A:B
>
>
Right, with my implementation as it sits. pwm(x, y) where pwmchipx, ->
pwmy. x
On Thu, Apr 27, 2017 at 5:29 PM, William Hermans wrote:
>
>
> On Thu, Apr 27, 2017 at 3:22 PM, William Hermans wrote:
>>
>> It'll break bonejs too, but I can live with that. Just an additional two
>> characters in a string somewhere in my code. A few times .
On Thu, Apr 27, 2017 at 3:22 PM, William Hermans wrote:
> It'll break bonejs too, but I can live with that. Just an additional two
> characters in a string somewhere in my code. A few times . . .hehe
>
Actually, it won't break my implementation at all. Just need to change how
It'll break bonejs too, but I can live with that. Just an additional two
characters in a string somewhere in my code. A few times . . .hehe
On Thu, Apr 27, 2017 at 3:18 PM, Robert Nelson
wrote:
> On Thu, Apr 27, 2017 at 5:15 PM, William Hermans
>
On Thu, Apr 27, 2017 at 5:15 PM, William Hermans wrote:
>
>
> On Thu, Apr 27, 2017 at 3:12 PM, Robert Nelson
> wrote:
>>
>>
>> https://lkml.org/lkml/2016/6/14/967
>>
>
> Ouch, so sounds like a boot script hack is the only way right now ?
Yay! That
On Thu, Apr 27, 2017 at 3:15 PM, William Hermans wrote:
>
>
> On Thu, Apr 27, 2017 at 3:12 PM, Robert Nelson
> wrote:
>
>>
>> https://lkml.org/lkml/2016/6/14/967
>>
>>
> Ouch, so sounds like a boot script hack is the only way right now ?
>
Sorry, did
On Thu, Apr 27, 2017 at 5:08 PM, Robert Nelson wrote:
> On Thu, Apr 27, 2017 at 5:04 PM, William Hermans wrote:
>>
>>
>> On Thu, Apr 27, 2017 at 2:59 PM, William Hermans wrote:
>>>
>>>
>>>
>>> On Thu, Apr 27, 2017 at 2:56 PM, Robert
On Thu, Apr 27, 2017 at 5:04 PM, William Hermans wrote:
>
>
> On Thu, Apr 27, 2017 at 2:59 PM, William Hermans wrote:
>>
>>
>>
>> On Thu, Apr 27, 2017 at 2:56 PM, Robert Nelson
>> wrote:
>>>
>>> On Thu, Apr 27, 2017 at 4:55 PM,
On Thu, Apr 27, 2017 at 2:59 PM, William Hermans wrote:
>
>
> On Thu, Apr 27, 2017 at 2:56 PM, Robert Nelson
> wrote:
>
>> On Thu, Apr 27, 2017 at 4:55 PM, William Hermans
>> wrote:
>> > @Robert,
>>
>> it works for gpio... so i
On Thu, Apr 27, 2017 at 4:55 PM, William Hermans wrote:
> @Robert,
>
> I'm thinking at this point in time, that we may have to fall off the last
> creation of files in that path, and do single file permission changes, would
> would be tedious, and painful. So whatever the last
@Robert,
I'm thinking at this point in time, that we may have to fall off the last
creation of files in that path, and do single file permission changes,
would would be tedious, and painful. So whatever the last path to be
created, you run the udev rule off that, and just traverse down into the
On Thu, Apr 27, 2017 at 4:50 PM, William Hermans wrote:
>
> On Thu, Apr 27, 2017 at 2:46 PM, Robert Nelson
> wrote:
>>
>> On Thu, Apr 27, 2017 at 4:43 PM, William Hermans
>> wrote:
>> > Still having issues with PWM ?
>>
>> Yeah i
On Thu, Apr 27, 2017 at 4:46 PM, William Hermans wrote:
> By the way, I think the small amount I talked about udev, and permissions on
> my git for bonejs. I pretty much got most of that information from rPI
> content all over the web. I did have to make several modifications
On Thu, Apr 27, 2017 at 2:46 PM, Robert Nelson
wrote:
> On Thu, Apr 27, 2017 at 4:43 PM, William Hermans
> wrote:
> > Still having issues with PWM ?
>
> Yeah i took a break from that, PWM was too painful..
>
> Fixed an LCD and the
On Thu, Apr 27, 2017 at 4:43 PM, William Hermans wrote:
> Still having issues with PWM ?
Yeah i took a break from that, PWM was too painful..
Fixed an LCD and the v4.4.x-bone/v4.4.x-rt-bone u-boot overlay problem
some users where having..
So let's try the pwm with v4.9.x ;)
By the way, I think the small amount I talked about udev, and permissions
on my git for bonejs. I pretty much got most of that information from rPI
content all over the web. I did have to make several modifications though .
..
On Thu, Apr 27, 2017 at 2:43 PM, William Hermans
Still having issues with PWM ?
On Thu, Apr 27, 2017 at 2:41 PM, Robert Nelson
wrote:
> and inside one:
>
> debian@beaglebone:/sys/class/gpio/gpio2$ ls -lha
> total 0
> drwxrwxr-x 3 root gpio0 Apr 27 21:38 .
> drwxrwxr-x 16 root gpio0 Apr 27 21:38 ..
>
and inside one:
debian@beaglebone:/sys/class/gpio/gpio2$ ls -lha
total 0
drwxrwxr-x 3 root gpio0 Apr 27 21:38 .
drwxrwxr-x 16 root gpio0 Apr 27 21:38 ..
-rw-rw-r-- 1 root gpio 4.0K Apr 27 21:38 active_low
lrwxrwxrwx 1 root gpio0 Apr 27 21:38 device -> ../../../gpiochip0
-rw-rw-r--
On Thu, Apr 27, 2017 at 4:39 PM, William Hermans wrote:
> Wow, the Pine64 community is actually active ? hehe. . .
Yeah i stole that from them..
with cape-universal/u0boot overlays/4.9.25-ti-r31.2
all came up root:gpio
debian@beaglebone:/sys/class/gpio$ ls -lha
total 0
Wow, the Pine64 community is actually active ? hehe. . .
On Thu, Apr 27, 2017 at 2:35 PM, Robert Nelson
wrote:
> On Thu, Apr 27, 2017 at 4:27 PM, Metelko wrote:
> > I used the following udev rule (similar to William Hermans, without the
> >
On Thu, Apr 27, 2017 at 4:27 PM, Metelko wrote:
> I used the following udev rule (similar to William Hermans, without the
> pinmux/state changes using a new 'gpio' group).
>
> udev rule:
> SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio;
> chmod
This is what I had to do with the gpio pins, note the last two parts of the
rules.
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio
/sys/class/gpio; chmod -R 770 /sys/class/gpio;
chown -R root:gpio /sys/devices/platform/ocp/4000.gpio/gpio/;
chmod -R 770
This is what the analog.js application shows:
https://i.imgur.com/4ifEFBQ.png
if i manually do:
debian@test-bbb-2:/sys/class/pwm/pwmchip4$ sudo /bin/chown -R root:pwm ./pwm0/
debian@test-bbb-2:/sys/class/pwm/pwmchip4$ sudo /bin/chmod -R ug+rw ./pwm0/
debian@test-bbb-2:/sys/class/pwm/pwmchip4$
On Fri, Apr 21, 2017 at 7:18 PM, William Hermans wrote:
> Another thing that come to mind right off is that some files can only be
> read, while others still can only be written to. If you're attempting to
> change permissions to these files in a way that it's not meant to be
Another thing that come to mind right off is that some files can only be
read, while others still can only be written to. If you're attempting to
change permissions to these files in a way that it's not meant to be used.
It could potentially cause the whole rule to fail.
--
For more options,
On Fri, Apr 21, 2017 at 3:11 PM, Robert Nelson
wrote:
> On Fri, Apr 21, 2017 at 3:44 PM, Robert Nelson
> wrote:
> > On Fri, Apr 21, 2017 at 3:27 PM, Robert Nelson
> wrote:
> >> On Fri, Apr 21, 2017 at 1:39 PM, Robert
On Fri, Apr 21, 2017 at 3:44 PM, Robert Nelson wrote:
> On Fri, Apr 21, 2017 at 3:27 PM, Robert Nelson
> wrote:
>> On Fri, Apr 21, 2017 at 1:39 PM, Robert Nelson
>> wrote:
>>> On Fri, Apr 21, 2017 at 12:36 PM, Mark A.
On Fri, Apr 21, 2017 at 3:27 PM, Robert Nelson wrote:
> On Fri, Apr 21, 2017 at 1:39 PM, Robert Nelson
> wrote:
>> On Fri, Apr 21, 2017 at 12:36 PM, Mark A. Yoder
>> wrote:
>>> I'll grab the new image when I see it.
On Fri, Apr 21, 2017 at 1:39 PM, Robert Nelson wrote:
> On Fri, Apr 21, 2017 at 12:36 PM, Mark A. Yoder
> wrote:
>> I'll grab the new image when I see it. Does debian by default mean the bash
>> window has /home/debian as its home?
Okay it's
On Fri, Apr 21, 2017 at 12:36 PM, Mark A. Yoder wrote:
> I'll grab the new image when I see it. Does debian by default mean the bash
> window has /home/debian as its home?
Nope, need to figure out how to hide this:
https://i.imgur.com/CSchvbR.png
When, home is
I'll grab the new image when I see it. Does debian by default mean the
bash window has /home/debian as its home?
--Mark
On Friday, April 21, 2017 at 1:15:27 PM UTC-4, RobertCNelson wrote:
>
> On Fri, Apr 21, 2017 at 11:31 AM, Mark Yoder > wrote:
> > I fired up a fresh
On Fri, Apr 21, 2017 at 11:31 AM, Mark Yoder wrote:
> I fired up a fresh copy of the 4-18 image and noticed:
> debian@Bone:/var/lib/cloud9$ ls -ls
> total 24
> 4 drwxr-xr-x 2 root root 4096 Apr 18 20:34 autorun
> 4 drwxrwxr-x 6 root cloud9ide 4096 Apr 18 20:30
I fired up a fresh copy of the 4-18 image and noticed:
debian@Bone:/var/lib/cloud9$ *ls -ls*
total 24
4 drwxr-xr-x 2 root root 4096 Apr 18 20:34 autorun
4 drwxrwxr-x 6 root cloud9ide 4096 Apr 18 20:30 examples
12 -rw-rw-r-- 1 root cloud9ide 8808 Jun 27 2016 LICENSE
4 -rw-rw-r-- 1 root
On Tue, Apr 18, 2017 at 4:40 PM, Mark Yoder wrote:
> I'm not getting the gpio permissions to work. I think there are two methods
> posted here.
>
> Could you repost the one the works?
Just:
sudo apt update ; sudo apt upgrade
and
cd /opt/scripts/
git pull
sudo reboot
On Tue, Apr 18, 2017 at 4:31 PM, Mark Yoder wrote:
> Robert:
> I just edited /etc/default/cloud9 and changed HOME to
> HOME=/home/debian
>
> and now the default home for cloud9 is /home/debian.
>
> I don't know if I've broken anything.
As long as it doesn't ask you to
I'm not getting the gpio permissions to work. I think there are two
methods posted here.
Could you repost the one the works?
--Mark
On Tuesday, April 18, 2017 at 5:34:56 PM UTC-4, Mark Yoder wrote:
>
> The last URL should be:
>
>
>
The last URL should be:
https://github.com/rcn-ee/repos/blob/master/bb-customizations/suite/jessie/debian/80-gpio-noroot.rules
On Thursday, April 13, 2017 at 4:48:30 PM UTC-4, robert nelson wrote:
>
> On Thu, Apr 13, 2017 at 3:07 PM, Mark Yoder > wrote:
> > That was it.
Robert:
I just edited */etc/default/cloud9* and changed HOME to
*HOME=/home/debian*
and now the default home for cloud9 is* /home/debian*.
I don't know if I've broken anything.
--Mark
On Thursday, April 13, 2017 at 4:48:30 PM UTC-4, robert nelson wrote:
>
> On Thu, Apr 13, 2017 at 3:07 PM,
On Thu, Apr 13, 2017 at 3:07 PM, Mark Yoder wrote:
> That was it. gpio seems to be working now as debian. I'll keep playing...
Okay got gpio working and it's not locking up the serial port:
chown -R root:gpio /sys/class/gpio
chmod -R ug+rw /sys/class/gpio
That was it. gpio seems to be working now as debian. I'll keep playing...
--Mark
On Thursday, April 13, 2017 at 4:03:06 PM UTC-4, robert nelson wrote:
>
> On Thu, Apr 13, 2017 at 2:57 PM, Mark Yoder > wrote:
> > Yup, the chown/chmod fixed it, and the apt upgrade
On Thu, Apr 13, 2017 at 2:57 PM, Mark Yoder wrote:
> Yup, the chown/chmod fixed it, and the apt upgrade appears to have worked
> too.
>
> As for the udev rules, no. I still need to sudo to access the gpio pins.
> Looks like everything is still root:root.
>
> dmesg[1]
Hmmm nothing in */etc/udev/rules.d*. Looks like it didn't install.
--Mark
On Thursday, April 13, 2017 at 3:57:33 PM UTC-4, Mark Yoder wrote:
>
> Yup, the chown/chmod fixed it, and the apt upgrade appears to have worked
> too.
>
> As for the udev rules, no. I still need to sudo to access
Yup, the chown/chmod fixed it, and the apt upgrade appears to have worked
too.
As for the udev rules, no. I still need to sudo to access the gpio pins.
Looks like everything is still root:root.
dmesg[1] doesn't seem to show anything.
--Mark
[1] http://paste.debian.net/927517/
On
On Thu, Apr 13, 2017 at 2:35 PM, Robert Nelson wrote:
> On Thu, Apr 13, 2017 at 2:31 PM, Mark Yoder wrote:
>> Well, it's running. Here's a couple of things I notice:
>>
>> 1. The message "Failed to write to 'state.settings'. Access denied
>>
On Thu, Apr 13, 2017 at 2:31 PM, Mark Yoder wrote:
> Well, it's running. Here's a couple of things I notice:
>
> 1. The message "Failed to write to 'state.settings'. Access denied
> acccessing this file or folder." Keeps flashing in red above the edit
> window.
That's
Well, it's running. Here's a couple of things I notice:
1. The message "Failed to write to 'state.settings'. Access denied
acccessing this file or folder." Keeps flashing in red above the edit
window.
2. The terminal window starts in */var/lib/cloud9*. (A good place to
start.) Typing *cd
I'm flashing it now. Wow, things really download fast when you aren't
competing with 2000 students.
--Mark
On Thursday, April 13, 2017 at 2:32:32 PM UTC-4, robert nelson wrote:
>
> On Thu, Apr 13, 2017 at 12:44 PM, Mark Yoder > wrote:
> > I'll wait for the new image.
On Thu, Apr 13, 2017 at 12:44 PM, Mark Yoder wrote:
> I'll wait for the new image. It hasn't popped up yet.
Okay give this a shot:
https://rcn-ee.net/rootfs/bb.org/testing/2017-04-13/stretch-iot/
add 'User=debian' to the end of /lib/systemd/system/cloud9.service
and
On Thu, Apr 13, 2017 at 12:44 PM, Mark Yoder wrote:
> I'll wait for the new image. It hasn't popped up yet.
yeah, ran into a small problem of install order:
https://github.com/rcn-ee/repos/commit/2b52ed42fa6a33c2e25e42fe68dce582113ced4b
It's almost done. ;)
Regards,
I'll wait for the new image. It hasn't popped up yet.
--Mark
On Thursday, April 13, 2017 at 12:32:08 PM UTC-4, robert nelson wrote:
>
> On Thu, Apr 13, 2017 at 11:26 AM, Mark Yoder > wrote:
> > Robert:
> > Wow, that was quick. So then Cloud 9 runs a debian now and
On Thu, Apr 13, 2017 at 11:26 AM, Mark Yoder wrote:
> Robert:
> Wow, that was quick. So then Cloud 9 runs a debian now and the udev
> script sets all the gpio /sys/ files to be owned by debian.
No, it's still root by default.. It's a one line change to get Cloud9
Robert:
Wow, that was quick. So then Cloud 9 runs a debian now and the udev
script sets all the gpio /sys/ files to be owned by debian.
So do I need to grab next week's build to test it?
--Mark
On Thursday, April 13, 2017 at 10:40:14 AM UTC-4, robert nelson wrote:
>
> On Thu, Apr 13, 2017
> Still a few issues:
>
> https://i.imgur.com/amVHbaE.png
>
> Apr 13 14:34:29 beaglebone cloud9ide[528]: LISTEN_FDS = 1
> Apr 13 14:34:29 beaglebone cloud9ide[528]: Connect server listening at
> http://127.0.0.1:3000
> Apr 13 14:34:30 beaglebone cloud9ide[528]: CDN: version standalone
>
On Thu, Apr 13, 2017 at 9:13 AM, Mark Yoder wrote:
> Robert:
> Presently Cloud 9 runs as root. Would it be possible for it to run as
> debian instead? That would mean the examples would have to run with sudo.
>
> Seems like this would be much more secure.
With
64 matches
Mail list logo