Beaglebone User LED's
Charlie Fullerton
What are the default uses for the 4 User LED's? in blinkled.js it uses
USR3 as it's led... but then usr0 is a one second blip and usr1 seems to
be a read/write to the filesystem led.. Am I correct on this?
Can I modify blinkled.js to use USR2 to blink another led to show how to
simply modify the code to work a little different?
Thanks for a great product! I'm really having fun with it!!
Koen Kooi
Op 7 dec. 2011, om 15:43 heeft Charlie Fullerton het volgende geschreven:
> Greetings!!
>
> What are the default uses for the 4 User LED's? in blinkled.js it uses USR3 as it's led... but then usr0 is a one second blip and usr1 seems to be a read/write to the filesystem led.. Am I correct on this?
Almost:
root@beaglebone:~# for i in /sys/class/leds/*/trigger ; do echo "$i: $(cat $i)" ; done
/sys/class/leds/beaglebone::usr0/trigger: none mmc0 timer [heartbeat] backlight gpio default-on
/sys/class/leds/beaglebone::usr1/trigger: none [mmc0] timer heartbeat backlight gpio default-on
/sys/class/leds/beaglebone::usr2/trigger: [none] mmc0 timer heartbeat backlight gpio default-on
/sys/class/leds/beaglebone::usr3/trigger: [none] mmc0 timer heartbeat backlight gpio default-on
So usr0 is using the heartbeat trigger and usr1 lights up when the sd card is accessed.
> Can I modify blinkled.js to use USR2 to blink another led to show how to simply modify the code to work a little different?
Yes
Charlie Fullerton
and have it blink with it... However, when I try to add more LED's to
other pins and add the code, it doesn't work.. I'm modifying the Cloud9
scripts. I'm thinking that my arduino experience might be getting in
the way here. I want to connect 8 LED's and modify the sequence on how
they blink. I set it up on P8 pins 3-10. Pins 8_4 and 8_8 stay
lit... Pin 8_3 Blinks per the code..
In reading the SRM doc, I see the some of the pins I've used are for the
"timer". must I use only the GPIO pins for led's?
I'm trying to understand the pin layout and how they are used. Any help
is always appreciated!!
Charlie Fullerton
I've attempted changing to all GPIO pins and updated my code as well.
to no avail..
What am I doing wrong? Shall I update my code as well?
colinfp
This is an incomplete advice stub... but it might help you on your
debug efforts.
I think this has something to do with the mux33xx.c file in the
kernel's /arch/arm/mach-omap2/ folder. I mounted the debugfs by
typing "mkdir /debugs" then "mount -t debugfs none /debugfs" If you
look in the /debugfs/omapmux/ folder you will see all the pin outputs
and their pinmux modes. I.e. "cat /debugfs/omapmux/gpmc_ad6" This
should display that the pin mode for gpmc_ad6, which is port 8 pin 3,
is configured as a gpio. (And would explain why you can blink it...)
(pair the operation mode in the SRM and those listed in the debug
file) The rest of the pins that you described in your post aren't
listed as gpio's by the debugfs. Instead they are type (.null) This
doesn't necessarily mean that they aren't set to the gpio
functionality... but in any case the mux33xx.c file should be updated
to include all the possible mux pin settings.
I would recommend looking into the am33xx datasheet to see what the
pin mux mode settings are. I.e. is Mode 7 gpio? I have an odd
feeling that mode 7 is usually gpio but you should check.
-Colin
On Dec 7, 3:46 pm, Charlie Fullerton <cwfullerton21...@gmail.com>
wrote:
Charlie Fullerton
root@beaglebone:/debugfs/omap_mux# cat /debugfs/omap_mux/gpmc_ad7
name: gpmc_ad7.(null) (0x44e1081c/0x81c = 0x0007), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE7
signals: gpmc_ad7 | mmc1_dat7 | NA | NA | NA | NA | NA | NA
root@beaglebone:/debugfs/omap_mux# cat /debugfs/omap_mux/gpmc_ad6
name: gpmc_ad6.gpio1_6 (0x44e10818/0x818 = 0x0037), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE7
signals: gpmc_ad6 | mmc1_dat6 | NA | NA | NA | NA | NA | gpio1_6
If I'm interpreting this correctly the "signals" line shows the setting
for each mode. According to the SRM doc, gpmc_ad7 is mapped to pin
8_4. Mode 7 should be set to "gpio1[7]" however as you can see above
it's set to "NA" Not sure how this happened as I didn't change this
from when I got it...
Is it normal to edit these files to set it back to the configuration as
per the SRM doc? Can these be manipulated via Cloud9 and the
javascript? What's the preferred way to do this?
Jason Kridner
<cwfuller...@gmail.com> wrote:
> Thanks for the help... here's what I found on my bone..
>
> root@beaglebone:/debugfs/omap_mux# cat /debugfs/omap_mux/gpmc_ad7
> name: gpmc_ad7.(null) (0x44e1081c/0x81c = 0x0007), b NA, t NA
> mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE7
> signals: gpmc_ad7 | mmc1_dat7 | NA | NA | NA | NA | NA | NA
Note the NA in the last column along with OMAP_MUX_MODE7. This pin is
in GPIO mode, but it just seems there is something missing in the data
structure to let the debugfs entry know what to display for mode 7.
I'd like to look around the kernel sources so I can figure out what
needs to be completed here. We'll see if it reaches the top of my
to-do list before someone else fixes it.
> --
> You received this message because you are subscribed to the Google Groups
> "Beagle Board" group.
> To post to this group, send email to beagl...@googlegroups.com.
> To unsubscribe from this group, send email to
> beagleboard...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/beagleboard?hl=en.
>
Jason Kridner
> On Wed, Dec 7, 2011 at 11:42 PM, Charlie Fullerton
> <cwfuller...@gmail.com> wrote:
>> Thanks for the help... here's what I found on my bone..
>>
>> root@beaglebone:/debugfs/omap_mux# cat /debugfs/omap_mux/gpmc_ad7
>> name: gpmc_ad7.(null) (0x44e1081c/0x81c = 0x0007), b NA, t NA
>> mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE7
>> signals: gpmc_ad7 | mmc1_dat7 | NA | NA | NA | NA | NA | NA
>
> Note the NA in the last column along with OMAP_MUX_MODE7. This pin is
> in GPIO mode, but it just seems there is something missing in the data
> structure to let the debugfs entry know what to display for mode 7.
>
> I'd like to look around the kernel sources so I can figure out what
> needs to be completed here. We'll see if it reaches the top of my
> to-do list before someone else fixes it.
>
>>
>> root@beaglebone:/debugfs/omap_mux# cat /debugfs/omap_mux/gpmc_ad6
>> name: gpmc_ad6.gpio1_6 (0x44e10818/0x818 = 0x0037), b NA, t NA
>> mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE7
>> signals: gpmc_ad6 | mmc1_dat6 | NA | NA | NA | NA | NA | gpio1_6
>>
>> If I'm interpreting this correctly the "signals" line shows the setting for
>> each mode. According to the SRM doc, gpmc_ad7 is mapped to pin 8_4. Mode 7
>> should be set to "gpio1[7]" however as you can see above it's set to "NA"
>> Not sure how this happened as I didn't change this from when I got it...
>>
>> Is it normal to edit these files to set it back to the configuration as per
>> the SRM doc?
The initial u-boot/kernel aren't setting it to the configuration per
the SRM, but the next release should have them set to match.
>> Can these be manipulated via Cloud9 and the javascript?
Yes.
>> What's
>> the preferred way to do this?
If you use bonescript, it will perform a reconfiguration of the mux
into GPIO mode. Currently, bonescript only knows how to use pins in
GPIO mode, but it will eventually use I2C, SPI, serial, etc. ports.
Most documentation on the net will currently show you how to
manipulate the pinmux settings at run-time from user-space using
devmem2 (though the more clean transitions are currently done just in
the kernel while the kernel pinmux interface is evolving).
What I do is use the debugfs entry for the pin and just feed a "7" to
it to get the pin into GPIO mode. You can find that in the "Ensure
the pin is in GPIO mode" section of bonescript/index.js.
Koen Kooi
Op 8 dec. 2011, om 14:55 heeft Jason Kridner het volgende geschreven:
> On Wed, Dec 7, 2011 at 11:42 PM, Charlie Fullerton
> <cwfuller...@gmail.com> wrote:
>> Thanks for the help... here's what I found on my bone..
>>
>> root@beaglebone:/debugfs/omap_mux# cat /debugfs/omap_mux/gpmc_ad7
>> name: gpmc_ad7.(null) (0x44e1081c/0x81c = 0x0007), b NA, t NA
>> mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE7
>> signals: gpmc_ad7 | mmc1_dat7 | NA | NA | NA | NA | NA | NA
>
> Note the NA in the last column along with OMAP_MUX_MODE7. This pin is
> in GPIO mode, but it just seems there is something missing in the data
> structure to let the debugfs entry know what to display for mode 7.
>
> I'd like to look around the kernel sources so I can figure out what
> needs to be completed here. We'll see if it reaches the top of my
> to-do list before someone else fixes it.
About 70% of the mux modes aren't filled in in the kernel. I still can't work up the motivation to add all entries since we won't be using this kernel for long (I hope).
regards,
Koen
Gerald Coley
Charlie Fullerton
update and opkg upgrade and it installed the kernel 3.0 on my beaglebone...
Jason Kridner
<cwfuller...@gmail.com> wrote:
> Gee, could this be part of the problem I'm having? I did the opkg update
> and opkg upgrade and it installed the kernel 3.0 on my beaglebone...
While there might be a 3.0 kernel installed, that won't be what it is
booting. The boot is currently from the uImage in the FAT partition,
which is not updated by opkg upgrade.
Again, the issue is that not all of the fields are populated in the kernel.
>
>
> On 12/8/2011 10:00 AM, Gerald Coley wrote:
>>
>> I am definitley looking foward to the final Linux kernel!
Indeed. Some patches went into the staging area for the mainline
kernel for AM335x just today. BeagleBone support will probably be
solid upstream sometime around perhaps 3.4.
>> Gerald