Beagler’s:
I just wrote up some notes on how to edit the device tree to change a GPIO into an LED.
It’s are rather involved process that requires understanding some deeper magic.
Let me know what you think.
–Mark
Well presented I like your approach at documentation I bet that comes from teaching
Yup, years for facing blank stares has taught me a few things.
This particular example touched on so many different things it could be a nice final exam.
–Mark
Good stuff, thank you Mark!
How are the triggers defined? They’re more or less self explanatory, I’m just curious how it works.
Ren:
Good question. I poked around the kernel source a bit hoping to create an example for my students.
But it was more complicated than what I wanted for my students.
–Mark
Very cool Mark.
A couple of notes:
-
It might be a good idea to put a note in there for the folks to back up their currently booted dts/dtb files before editing them.
-
Under “Finding which device tree to edit” I believe there is a typo:
Note: If you want to edit the source using cloud9 us the following trick …
Should be:
Note: If you want to edit the source using cloud9 use the following trick … -
When you run make, would it be best to just run it against the file that was edited rather than the whole folder?
Maybe the build script is smart enough to figure this out. -
Under “Adding our LED” there is the following without explaining the why. Was this intentional?
“How did I know to use gpio1 and 18?”
This is a nice series. Thanks for sharing.
Cheers,
Jon
Jon:
Thanks for the suggestions. I’ll address each in line…
–Mark
Hi Mark,
Nice tutorial. Wish I’d had that quite some time ago, I had to pull all those pieces together myself.
From having read a bunch of posts here, I have a few suggestions for your consideration.
-
User needs to be in the gpio group. This isn’t mentioned.
-
People often ignore parts of instructions. If your prompt included the current directory name, it would be slightly more obvious where each command is run.
-
It would be AMAZING if tutorials such as these included a description of what version of code this was developed/tested on. You could either mention the RCN release number or the kernel build, but it would be so great if this were a standard thing to mention. Consider how much things have changed with device trees over the past five (?) years. There’s tons of now-wrong notes on how to do things. (I know you mention a kernel in the compilation section, I guess it would be nice to spell this out up top, i.e. “This tutorial is applicable to Beaglebone release xxx”).
-
Not sure this comment is welcome, but a top level Tutorials page containing all the EBC## tutorials would be cool. I found the others by clicking on your ECE497 link, but that isn’t exactly obvious (to me). Those look like some great materials that I hadn’t come across before, for some reason.
Best,
Jim
> tutorials such as these included a description of what version of code this was developed/tested on.
This ^^^^^
As a beginner, it’s been quite frustrating to have to wade through all the tutorials referring to a cape manager that no longer exists.
Not only have I learnt how things work today, I’ve also had to learn how they used to work — which I could have done without.
Jim:
Thanks for the feedback. I like your suggestions. Responses below:
Hi Mark,
Nice tutorial. Wish I’d had that quite some time ago, I had to pull all those pieces together myself.
From having read a bunch of posts here, I have a few suggestions for your consideration.
- User needs to be in the gpio group. This isn’t mentioned.
The debian image has user debian in the gpio group by default. Though there are other use cases, I want to keep this focused on my students.
They are fighting too many alligators for me to add the group alligator.
- People often ignore parts of instructions. If your prompt included the current directory name, it would be slightly more obvious where each command is run.
Good suggestion. To keep the clutter down I just converted all paths to absolute. Does that work?
- It would be AMAZING if tutorials such as these included a description of what version of code this was developed/tested on. You could either mention the RCN release number or the kernel build, but it would be so great if this were a standard thing to mention. Consider how much things have changed with device trees over the past five (?) years. There’s tons of now-wrong notes on how to do things. (I know you mention a kernel in the compilation section, I guess it would be nice to spell this out up top, i.e. “This tutorial is applicable to Beaglebone release xxx”).
Great idea. Wiki pages age so quickly. I’ve added a footnote that displays the output of uname and cat /etc/dogtag. What do you think?
(https://elinux.org/EBC_Exercise_17_Switching_a_GPIO_to_an_LED)
- Not sure this comment is welcome, but a top level Tutorials page containing all the EBC## tutorials would be cool. I found the others by clicking on your ECE497 link, but that isn’t exactly obvious (to me). Those look like some great materials that I hadn’t come across before, for some reason.
Another good idea, but… I’m sticking with using the Category to collect all my pages. I hope my titles are descriptive enough that I can remember what’s in them.
Thanks again for the feedback.
–Mark
Mark,
I wish more tutorials looked like this. I should have started with congratulations on a great job. Thanks for considering my suggestions.
Best,
Jim
The output lines in a GPIO subsystem are limited to a maximum current of 6 mA. The users/students should know that they need a low power/current LED for your circuit.
The value of the current limiting resistor depends on the threshold voltage of the LED, which depends on the LED color. 220Ω is OK for a blue LED, but too small for ie. an orange LED with 1V65 threshold / 6mA. This may damage the LED, or - most likely - the output line in the GPIO subsystem (= the BB CPU).
Regards