BeagleBone RED

That's nice! I was going for  green or yellow (since I already had them) but I aborted when I saw the resistors. I may go ahead, since you got good results without replacing them.

By the way, how did you stop the program that flashes the user LEDs seemingly randomly? (I guess this must be obvious, but I couldn't find it : )

I was trying to use the LEDs for another purpose but I couldn't see in the usual places (rc3.d etc) where that default  resides.

and the objects of loathing

Now where did I put the hammer

shabaz wrote:

By the way, how did you stop the program that flashes the user LEDs seemingly randomly? (I guess this must be obvious, but I couldn't find it : )

Well it is, and isn't, obvious. It's not really a program that flashes the leds, it's the kernel.  There was a file called /etc/default/leds and some systemd nonesense, but killing those doesn't actually help.

Look in your device tree source files and you'll find the actual built-in defaults. So you can change the dtb to do something else and it'll stay that way until you upgrade.

See post 109 of http://www.element14.com/community/message/75911#75911/l/re-have-a-question-about-the-next-gen-beaglebone-ask-it-here for how I modded the device tree defaults

After the system's booted you can change the value of /sys/class/leds/beaglebone:green:usr[0-3]/trigger  and no, no idea why the name has green in there. I'd have just used use[0-3] and missed out the whole beaglebone:green: bit altogether

So to take the photo I just set them all to default-on with echo default-on > /sys/class/leds/beaglebone\:green\:usr0/trigger

I didn't look in depth at the options yet, but one of them is gpio and I'm hoping that lets you effectively disable the led-class driver and control the led yourself, if not it'll either be back to trying to disable it in device tree or a recompile to make the driver a module

I may go ahead, since you got good results without replacing them.

the ones I used are only 15mcd and supposedly have a diffused lens, although it's hard to be sure when they are so small. It does seem to make a difference compared to the usually clear lensed blue ones though.

Lead free solder, tiny device, very close together certainly makes it tricky to swap them. I didn't quite have to reach for the hot air tools and tweezers, but close..

You guys are no fun!  You're going to lose all your street cred by not liking Vega-luminosity blue LEDs!

Don't you know that retinal evaporation is just the price to be paid for blind peergroup reinforcement?  And the adjective is there for a reason.

Like, er, being used literally.

Thanks, that's really helpful. I'd missed seeing that bunch of posts.

I've been working with the device tree again last night for another purpose, and I am amazed at the complexity. Makes sense for a cape ecosystem, but not so easy for those that want to directly use the pins. The aim was to get the modes changed on some pins, and I am currently trying to create a separate dtbo that will get loaded from the main dtb.

I have fairly thin solder (26swg) which is ok-ish on 0603 but I do need to go thinner.

Morgaine Dinova wrote:

 

You guys are no fun!  You're going to lose all your street cred by not liking Vega-luminosity blue LEDs!

Sorry, I value my eyesight more.  Blue leds should come with a health warning and a pair of eyesight protection goggles.

There's actually a good issue raised by this wonderful topic, pointing to some extra work that needs doing.  The fact that it wasn't possible to configure your requirements (or at least not easy to figure out how) despite these LEDs being programmable suggests that something is lacking.

Maybe it just requires better documentation, but it could also be that the drivers need more functionality, or better utilities, or better coordinated access to shared resources (not only LEDs) so that in-kernel uses like activity monitoring are under better control from user-space.  And er, duty-cycle luminance control of course.

Be that as it may, I must say I've thoroughly enjoyed this.

BeagleBone Red being watched by R-Pi

The kernels led subsystem is actually quite good and reasonably documented. It has hooks to all sorts of things, For example you can make a led flash on particular firewall activity.

There are also the controls available for brightness - haven't checked if that's available for gpio leds, ISTR reading something somewhere about needing an led controller chip for that.

Unfortunately I don't think it will ever be able to make a blue led turn red

The more usual problem is finding where the distro have hidden the controls - even when you know where /sys/class/leds is, you still need to find out where the distro is overriding your settings.

For a primer on where the whole configuration of resources is going with device tree and overlays, there's a good post over on lkml here http://permalink.gmane.org/gmane.linux.kernel/1389017 and it seems to be largely driven by the needs of beaglebone capes.

The interesting bit that's mentioned is the possibility of the user to override everything at run time without a reboot. That's exactly the sort of thing I'm looking for, and anyone with a breadboard cape that has no eeprom will likely want too..  However I've yet to track down any details of exactly how to do it.

None of that stuff has actually made it into the kernel.org kernel just yet, so we're getting a first look at it on BeagleBone-Red now. I suspect it will evolve into something more useable as it progresses.

selsinork wrote:

 

BeagleBone Red being watched by R-Pi

For the Booker prize as well, make your BeagleBone RED be watched by RED Pi .