Why the repost ? Wasn't it you who alread posted this exact same information 2 days ago ?
On Sat, Dec 31, 2016 at 12:39 PM, Graham <gra...@flex-radio.com> wrote: > Clayton: > Thanks for taking the time to post this summary. > --- Graham > > == > > On Saturday, December 31, 2016 at 1:23:13 PM UTC-6, Clayton Gulick wrote: >> >> I'm posting this here hoping to save others some frustration/pain that >> I've gone through as a noobie trying to get SPI working on the beagle bone >> black wireless. >> >> The documentation for this is a shambles currently, with conflicting and >> out of date information all over the internet. >> >> So, for those who find this post via google, let me explain what's going >> on and how we got to here. SPI on the BBB is actually really easy, it just >> may not seem like it. >> >> Ok, for starters when you google this, you've probably found a bunch of >> information on dts, overlays, capemgr, slots, etc... >> >> I'll take a sec to explain the history of this first. >> >> So, linux traditionally used kernel modules (drivers) for every piece of >> hardware that you might want to use. This strategy didn't work very well >> when all these ARM devices like the beagle bone started showing up because >> there were so many devices with different configurations, and it really >> didn't make sense to add all that to the kernel. As a solution to this, >> Linus came up with this idea for a level of abstraction called a device >> tree. >> >> The device tree is basically a way to describe the mapping and purpose of >> physical hardware to the kernel. This is done via a 'dts' file, which is a >> source code file that lists the specific properties of the hardware. This >> source code file is compiled into a binary that the kernel can understand, >> a 'dtb' or 'dtbo' file. So, early on in beagle bone history, this was how >> things were done. There were lots of dts and dtbo files that were made for >> all sorts of different purposes, and you, as the user could swap these out >> depending on how you want pins configured. You can also create your own. >> This is where some of the older articles you see that have instructions >> about creating a dts file and compiling it to enable SPI come from. >> >> Well, that whole thing was pretty spiffy, but there were some drawbacks. >> One, it wasn't very approachable for new folks. You basically had to learn >> a new language and toolchain just to configure pins. While better than >> writing a kernel module, that still wasn't great. Also, all of this >> configuration happened at boot time, so every time you wanted to make a >> change you had to reboot. This really doesn't work well for a device where >> you want to be able to hot swap extension boards and reconfigure things at >> runtime. Third, this all happened in kernel space, which as an industry we >> try not to do. It's better to keep as much as possible in user space. >> >> To address those issues: enter the Cape Manager. The cape manager is a >> pretty fancy piece of kernel module software that has the ability to >> dynamically load and swap out device tree overlays, and the tools live in >> userspace. When you see instructions on the web about adding lines to >> uEnv.txt like: >> >> >> optargs=quiet drm.debug=7 capemgr.enable_partno=BB-SPIDEV0 >> >> This is telling the cape manager to load the SPI device tree overlay at >> boot time. Everywhere you look on the internet, this is the recommended >> solution for enabling SPI on 'current' devices. But, it doesn't work. >> >> Why? Well, to explain that requires one more step. >> Even though the cape manager is neat software from an engineering >> perspective, and really accomplished its goals well, it still leaves >> something to be desired from a new user perspective. Folks who are just >> getting into the whole maker scene are reasonably confused by all this. >> >> To address that, some new software was created (which is enormously >> fancy), called universal io. >> >> Basically what this is, is a device tree overlay that's loaded by the >> cape manager at boot time that has the ability to dynamically configure all >> of the pins at runtime using a tool called config-pin. >> >> You can see it and read more about it here: >> https://github.com/cdsteinkuehler/beaglebone-universal-io >> >> So, with this utility all of the pins that aren't reserved for HDMI can >> be hot configured by using the simple config-pin command, and this includes >> SPI! >> >> So, finally after that long bit of history, here's how you actually set >> up and use SPI on a new beagle bone black wireless with a current image: >> >> #data out >> config-pin P.18 spi >> #clock out >> config-pin P.22 spi >> >> Rinse, repeat if you need other pins like CS, or MISO. >> >> After days of learning all of the above, and figuring all this out, I'm >> finally able to see a beautiful output waveform on my oscope. >> >> I hope this helps someone else new to all this! >> >> >> -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/beagleboard/e15aca05-5d5a-4c4c-8e48-5ed0a9ef0973%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/e15aca05-5d5a-4c4c-8e48-5ed0a9ef0973%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORp3%3DAsXcvmtMREfRd1H4OKtnOyJQx8jgvB-_h7fayU3Tg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
