Beaglebone User LED's

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?

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!!

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

Thanks for the info! I moved on to find I can connect an LED to P8_3 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!!

Can anyone provide a little advice on these questions below? As an update:

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?

Charlie,

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

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

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?

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.

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.

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

I am definitley looking foward to the final Linux kernel!

Gerald

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...

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.

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.