SPI on beagle bone black and beagle bone black wireless

[Clayton Gulick]

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!

[Graham]

Clayton:

Thanks for taking the time to post this summary.

--- Graham

==

[William Hermans]

Why the repost ? Wasn't it you who alread posted this exact same information 2 days ago ?

--
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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e15aca05-5d5a-4c4c-8e48-5ed0a9ef0973%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Clayton Gulick]

Hi William, I got a weird error on my original post, and I couldn't find it anywhere, so I reposted it. If you can find the original, I'll delete one. Thanks!

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/RewjY34TPYE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORp3%3DAsXcvmtMREfRd1H4OKtnOyJQx8jgvB-_h7fayU3Tg%40mail.gmail.com.

[Robert Nelson]

On Dec 31, 2016 6:07 PM, "Clayton Gulick" <clayto...@gmail.com> wrote:

Hi William, I got a weird error on my original post, and I couldn't find it anywhere, so I reposted it. If you can find the original, I'll delete one. Thanks!

Switch from threads to list all in the Google groups interface. 

But it's email based on the back end, so you can't change what you already emailed it to thousands of subscribers. 

Regards,

[Greg]

Hi Clayton, what you have written is correct and the Device Tree is a significant barrier to entry.
The Universal IO is a good solution to this, and I've had good luck with it while keeping in mind my requirements to manipulate the Device Tree have been minimal.

The Beagleboard is driven by the community, and it is a wonder such a complex piece of technology is accessible at all!

The Linux kernel has something like 8000 developers contributing, making it perhaps the largest engineering project in human history.

The complexity of this technology is breathtaking!  I very much appreciate what the community has done and I have learned a great deal and also had fun.

In looking about, Github appears to be the de-facto standard for sharing information in electronic form, and the Beagleboard related stuff is there.

But not all of it, especially documentation, is located in several wiki pages.  These pages are not reliable.

So what I am getting at, is that Github is an accepted means of publishing documentation, and you can get a public account for free.
If you could tidy up your post, and put it in publishable form, I think it would be a good contribution to the community.
As far as what "publishable form" means, that could be as simple as Markdown, or better yet a PDF file, which Github can display in the browser.

Just a suggestion, good luck with your projects and please let us know how it is going.

Regards,

Greg

[William Hermans]

Just to be clear . . . The Hadron collider in Genva is the biggest engineering "feat" in the world . . .Involving over 10,000 scientists from over 100 countries, and I'm not sure how many engineers.

Passed that, it's not surprising the Beaglebone works at all. For instance, you do realize that most of the packages, that you, I, or anyone else uses from Debian, actually comes from the Debian team Repo's right ? Then all of the embedded subsystems such as spidev, and all that predate this specific hardware ?

So, the real surprise would be if the hardware DID NOT work.

Then you have many, many people, who are just part of this community, Or part of this community, as well as others. Of whom I'll refrain of trying to name anyone, least I forget someone. I can think of at least one person who is constantly working in this community, and probably at least 10 others who contribute a bit here and there, As needed.

Additionally, I've been thinking this the whole time after this post, but . . . the information given here. Isn't exactly the best. I wasn't going to say anything, but now that I'm already posting . .  However I can pretty much say with 99% certainty this is because of the lack of experience from the OP. spidev's been around, and I happen to know someone who is very familiar with Linux, and got it working in a matter of minutes, from nothing. That is, to say. He was also new to the Beaglebone black, at that time. So . . .

--

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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/42488410-1f08-42eb-8aa4-30d403225f30%40googlegroups.com.

[William Hermans]

By the way, for me the key to understanding device tree was not to read any of the garbage on the internet about it. But to actually go into several device tree files, then learning about each subsystem used. Experimenting, and all that. Plus I still don't know everything, but do know enough to at least create my own overlay based off of existing overlays.

[Greg]

Hi William, if you could point to an easily discoverable source which says that Universal IO is available in the latest images and encouraged to be used, then you could be correct.

Being able to successfully manipulate the SOC multiplexer is fundamental to getting a Beagleboard project off the ground.

If there is no such info, which should be right at the top, then Clayton's post is a pretty good version 1.0 guide for newbies.

[Clayton Gulick]

That's a great idea Greg, I'll do that, thanks!

--

For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/RewjY34TPYE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.

[Clayton Gulick]

Ok, here's the first draft: https://github.com/claytongulick/beagle_bone_black_spi/blob/master/README.md

Corrections and additions are welcome!

[Greg]

Nice!  I will add this as a reference to my project documentation.

Regarding the fact that you have to run config-pin after each boot, you can add a section that the config-pin commands can be added

to whatever start-up configuration is most appropriate.

The way I am doing this currently is to simply list the commands in a text file like:

config-pin P8.30 pruout

config-pin P9.31 pruout

etc.

Then add this to the .bashrc file in the home directory:

source (path to the above file)

Then the configuration is done automatically!

Check this discussion for some other interesting info on Device Tree:

https://groups.google.com/forum/#!category-topic/beagleboard/1iFM1ywGQX4

The impression I have gotten, and I could be wrong, is that adding or subtracting overlays at the command

line is a not guaranteed to work operation.  The overlays should be reliably controlled via uEnv.txt and the eeprom.

[William Hermans]

On Sun, Jan 1, 2017 at 2:08 PM, Greg <soapy...@comcast.net> wrote:

Hi William, if you could point to an easily discoverable source which says that Universal IO is available in the latest images and encouraged to be used, then you could be correct.

Being able to successfully manipulate the SOC multiplexer is fundamental to getting a Beagleboard project off the ground.

If there is no such info, which should be right at the top, then Clayton's post is a pretty good version 1.0 guide for newbies.

Here is the thing.

The way things are right now, one could, but perhaps should not be editing the first stage environment file. That is to say: /uEnv.txt. Instead we could argue that "we" should be using /boot/uEnv.txt. In other words, optargs. So from that perspective, this is outdated information, which will definitely contribute to the confusion for new comers. Coming from a different angle, the first stage environment file is definitely not newb friendly and should be avoided. One simple typo, or mis-pressed key, and the system will no longer boot. In addition to the above.

So, after that, there are multiple ways to load an overlay file. One of which would be more consistent with using universal IO. Which is to use the universal IO script 'config-pin'. So . . .

$ config-pin overlay <overlay file name>

Which also means this could be loaded about 3 different ways at boot through rc.local, a cron job, or as a service.

Another thing of importance is that if your device tree overlay is not stock, it won't load at boot, through the second stage environment file. Robert wrote a script to remedy this issue. But basically you need to inject your overlay binary into the initramfs. This script makes an otherwise tedious job, very simple.

Anyway, if one were to examine the contents of /bootuEnv.txt, it would, or at least should become very clear how it is expected to load an overlay file at boot. There is an example for 3.8.x, and another for 4.x kernels.

As for me providing instructions as to how I believe this should be done properly. Well I have not exactly used SPI on this platform, or any embedded platform period. For this platform specifically because, in the case of a gpio multiplexer, SPI would be the furthest thing from my mind. Because it would tie up too many extra pins. Which if I'm using an expander / multiplexer . .. I must need pins. So, I would probably go for using one of the already used I2C buses .  . . Which I would say, at least from my own perspective. Is much easier to deal with than spidev. Also do keep in mind that I do have hands on with SPI, but only from a bare metal MCU perspective. I do however believe I could set SPI up on this platform no problem. Granted I do have ~4 years hands on with this platform . . .

So the point in short is this. While I do appreciate that Clayton was trying to help others like himself who may have problems getting SPI working on the beaglebone. In actuality the information provided by this post is not exactly correct. Even though it works. Which I think will in the end add the the confusion of beginners to the platform.

Maybe I'll write something up for 4.x myyself, as I get time, As I did buy myself a logic analyzer. But there would be no guarantee as to when, assuming even *if*.

[William Hermans]

I meant to say I've not used SPI on any embedded Linux platform. I do have plenty of experience with SPI on bare metal MCU's.

--

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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/daacf5b9-572f-4fcb-b609-0d598dd2f0e7%40googlegroups.com.

[William Hermans]

So, if you think "ah this is confusing . . ." it does get worse.

The new future way( I suspect) to load overlays at boot will likely be through uboot. Robert has recently added this functionality into uboot, I've tested it, and it does seem to work great. But I think this is for 4.1.x kernels and above only. However, this pretty much renders the need to inject your overlays into the initramfs moot. It may also be a little faster, but I can not see it being hugely faster. It has been said however it will make other issues with various devices at boot - Better.

You can read about it some here: https://groups.google.com/forum/#!searchin/beagleboard/HERE$20THERE$20BE%7Csort:relevance/beagleboard/W0QPDee5u2s/c1cbhzN4FAAJ

[William Hermans]

Ok so here is the quick skinny( untested ) to setup spidev on kernel 4.x. By untested, I mean I have not actually tested the signal generated, or received by the device. I was reading however, there is a "spidev_test" bit of code you can use to test send / receive by shorting MISO to MOSI( I'm supposing at it's the only way that makes sense ). However I want to read more about this code, I've not seen yet. Information is rather sparse from my source. Here: http://elinux.org/BeagleBone_Black_Enable_SPIDEV

I will say however that the information was rather plain, and easy for me to understand anyway. But I also know there are already pre-made overlays included with most, if not all images  now days. Official images that is . . . But if you do need other pins than what's used in these overlays. You'd have to write your own overlay, and include it in /lib/firmware. With that said, I'm not exactly sure how that works, or technically if it's even possible. My understand of spidev is that it is a software only driver for SPI, but I'm not 100% sure if you need physical hardware to be used with spidev, or not. Anyway . . .

Test for already functioning spidev interfaces:
debian@beaglebone:~$ ls /dev |grep spi
Check which spidev overlays come with stock image:
debian@beaglebone:~$ ls /lib/firmware/ |grep SPI
BB-SPI0-MCP3008-00A0.dtbo
BB-SPIDEV0-00A0.dtbo
BB-SPIDEV1-00A0.dtbo
BB-SPIDEV1A1-00A0.dtbo

Edit /boot/uEnv.txt to load chosen overlay at boot:
##BeagleBone Black: HDMI (Audio/Video) disabled:
enable_uboot_overlays=1
dtb=am335x-boneblack-emmc-overlay.dtb
dtb_overlay=/lib/firmware/BB-SPIDEV0-00A0.dtbo

The above requires a little extra explanation. enable_uboot_overlays=1 is required to enable uboot loading of overlays. The line after that loads the device tree board file I want loaded at boot. It disables both forms of HDMI. Which strictly speaking I'm not sure is necessary for the given overlay im loading. But is something I personally always do. Since I never use HDMI. dtb_overlay=/lib/firmware/BB-SPIDEV0-00A0.dtbo loads the overlay I want through uboot, at boot.

Rebot required to take effect:
debian@beaglebone:~$ sudo reboot

Test again for functioning spidev interfaces:
debian@beaglebone:~$ ls /dev |grep spi
spidev1.0
spidev1.1

Profit !

Do keep in mind that this is the very newest way to load overlays at boot. However, with that said, this would also work nearly exactly the same with the previous method with one exception. Instead of using:

enable_uboot_overlays=1
dtb=am335x-boneblack-emmc-overlay.dtb
dtb_overlay=/lib/firmware/BB-SPIDEV0-00A0.dtbo

You would use
dtb=am335x-boneblack-emmc-overlay.dtb
. . .
##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0

Pretty straight forward, and it's been this way a while now. There is one caveat however. If you're loading a custom overlay( one not included with the stock image ), you need to inject it into the initramfs. This is done by. . .

debian@beaglebone:~$ cd /opt/scripts/tools/developers/
debian@beaglebone:/opt/scripts/tools/developers$ git pull
debian@beaglebone:/opt/scripts/tools/developers$ sudo ./update_initrd.sh

*AFTER* You make sure your custom overlay is located in /lib/firmware

[Greg]

Hi William, great inputs and perhaps we can ask Clayton to push these additional details to the repository.

There should be a clear delimiter between the current and experimental improvements.

I wonder if there is going to be a distinct cut-over to the revised Uboot process?  Maybe too soon to determine.

Another thing:

1.  dtb-rebuilder

https://github.com/RobertCNelson/dtb-rebuilder

2.  bb.org-overlays

https://github.com/RobertCNelson/bb.org-overlays

Perhaps not a newbie concern, as I think 1 and 2 above are at the intermediate level. 

I think these should at least be mentioned as they are important bits for dealing with the Beagleboard Device Tree ecosystem.

Regards,

Greg

[lorriane...@yahoo.com]

--------------------------------------------
On Mon, 1/2/17, Greg <soapy...@comcast.net> wrote:

Subject: Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless
To: "BeagleBoard" <beagl...@googlegroups.com>
Date: Monday, January 2, 2017, 3:10 PM

Hi William, great
inputs and perhaps we can ask Clayton to push these
additional details to the repository.
There should be a clear delimiter between the current
and experimental improvements.
I wonder if there is going to be a distinct cut-over to
the revised Uboot process?  Maybe too soon to
determine.
Another thing:
1.
 dtb-rebuilderhttps://github.com/RobertCNelson/dtb-rebuilder
2.

 bb.org-overlayshttps://github.com/RobertCNelson/bb.org-overlays

Perhaps not a newbie concern, as I think 1 and 2
above are at the intermediate level. I think
these should at least be mentioned as they are important
bits for dealing with the Beagleboard Device Tree
ecosystem.
Regards,Greg

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/d7035e17-09a1-4839-b287-cfcecc60576d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

oldova opozitia fata de politica domnitorului Mihail Sturdza s-a at la 27 martie 7 aprilie intr-o Adunare populara desfasurata la Hotelul rg din lasi. Adunarea a fost condusa de Grigore Cuza. Protestand gimului lui Mihail Sturdza Adunarea ce cuprindea reprezentanti ai irtelor sociale si politice a numit o comisie care sa redacteze un de revendicari. Un rol important in elaborarea sa l-a avut Vasile n documentul Petitiunea-proclamatiune apartinand boierilor si moldoveni. El cuprindea 35 de puncte si avea aparent un caracter incercand sa se pastreze in limitele legalitatii politice datorita temerii de Rus de aceea la primul punct se proclama Sfanta pazire a untului Organic in tot cuprinsul sau si fara nici o rastalmacire Aceasta iur o prevedere ce urma sa atenueze o posibila reactie a Rusiei tariste ii moderat reiese si din abordarea problemei agrare solicitandu-se doargrabnica imbunatatire a starii locuitorilor sateni . Erau prevazute si revendicari cu caracter democratic modern precum eliberarea detinutilor politici o reforma a sistemului de invatamant siguranta persoanei desfiintarea cenzurii.

[William Hermans]

Yeah, I dont know. For me, it's all a moot point. The biggest hurdle to understanding devices on the beaglebone, is first understanding the hardware period. Then you need to understand the subsystems for each device type - On Linux. After that, device trees, and device tree overlays all start to make sense. Device tree files after all are only hardware descriptions.

Anyway, to answer your question, about universal IO. No I don't have a problem with it at all. But at some point, you'll realize that universal IO is a generic set of device tree overlays, with a tool(config-pin) to make pix muxing much simplier. e.g. an abstraction layer. At some point, you may actually find yourself not wanting to use it. For me, part of my nature is that I *have* to understand how things work, after which sometimes things may become redundant. . .

--
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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/d7035e17-09a1-4839-b287-cfcecc60576d%40googlegroups.com.

[justin.l...@gmail.com]

I have configured the pins for SPI 0 using the config-pin using the universal cape overlay, however I do not see any spi devices within my /dev/ folder. How do I access spi after I have muxed these pins at runtime?

Thanks

[nuno....@gmail.com]

Hi,

Definitely a must read about SPI, however with the IoT image ( Debian 9.2 2017-10-10 4GB SD IoT ) as is I was not able to configure the pins. what I did and what I get:

$config-pin P9.18 spi
P9_18 pinmux file not found!
bash: /sys/devices/platform/ocp/ocp*P9_18_pinmux/state: No such file or directory
Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_18_pinmux/state

Can anyone know how to solve this issue?

Best regards

Nuno F.

[Robert Nelson]

On Wed, Oct 25, 2017 at 12:05 PM, <nuno....@gmail.com> wrote:
> Hi,
>
> Definitely a must read about SPI, however with the IoT image ( Debian 9.2
> 2017-10-10 4GB SD IoT ) as is I was not able to configure the pins. what I
> did and what I get:
>
> $config-pin P9.18 spi
> P9_18 pinmux file not found!
> bash: /sys/devices/platform/ocp/ocp*P9_18_pinmux/state: No such file or
> directory
> Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_18_pinmux/state
>
> Can anyone know how to solve this issue?

P9_18 is allocated for i2c2, i haven't provided a way to bring this out..

You'll need to use the dtb-rebuilder and carve out that pin..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[clay....@healthelt.com]

So, this is what so (fun?) about the BB ecosystem.

I'm updating to the most recent image, trying to run code that has been working great for a good long time now, and it fails utterly with the same issue Nuno is experiencing.

I understand William Herman's point of view - for him, this is blaringly obvious. Why so hard? I'm sure he wonders. I'm willing to bet that William is an expert at embedded linux, and perhaps does it as a day job. That's admirable, and I think it would be fun to do that too.

But I don't.

I like making blinky lights. https://www.facebook.com/claytongulick/videos/pcb.10155266610164779/10155266622269779/?type=3&theater

My point here, is that if the BB community expects folks like me to stick around and not just use a raspberry pi for everything, we need to make this stuff easier.

I'm using the same documented SPI pins that Nuno is using, and on the latest image, it just doesn't work. Not only that, but the commands in uEnv.txt have changed. 

Where is the documentation on this? How are we expected to figure this out?

And now, according to Robert, I just simply can't use the pins I was using before without using something called dtb-rebuilder? 

Look guys, I know this stuff is like breathing to you and not a big deal. But changes like this without clear documentation are going to lose the hobbyist/maker community.

Sorry for the rant, I'm a bit frustrated, it's midnight and I've been working on this for hours without success, just to get SPI working the same way it used to.

For now, I'm going to revert to an older image. I'd love to update my github doc with some clear instructions on how to get SPI up and going on all of the documented SPI pins if someone can point me to a place where I can figure it out.

Thanks!

-Clay

[Robert Nelson]

On Fri, Dec 8, 2017 at 11:57 PM, <clay....@healthelt.com> wrote:
> So, this is what so (fun?) about the BB ecosystem.
>
> I'm updating to the most recent image, trying to run code that has been
> working great for a good long time now, and it fails utterly with the same
> issue Nuno is experiencing.
>
> I understand William Herman's point of view - for him, this is blaringly
> obvious. Why so hard? I'm sure he wonders. I'm willing to bet that William
> is an expert at embedded linux, and perhaps does it as a day job. That's
> admirable, and I think it would be fun to do that too.
>
> But I don't.
>
> I like making blinky lights.
> https://www.facebook.com/claytongulick/videos/pcb.10155266610164779/10155266622269779/?type=3&theater
>
> My point here, is that if the BB community expects folks like me to stick
> around and not just use a raspberry pi for everything, we need to make this
> stuff easier.
>
> I'm using the same documented SPI pins that Nuno is using, and on the latest
> image, it just doesn't work. Not only that, but the commands in uEnv.txt
> have changed.
>
> Where is the documentation on this? How are we expected to figure this out?

First line of /boot/uEnv.txt shows:

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

Did you go to that link

> And now, according to Robert, I just simply can't use the pins I was using
> before without using something called dtb-rebuilder?

That was two months ago, it's been fixed..

> Look guys, I know this stuff is like breathing to you and not a big deal.
> But changes like this without clear documentation are going to lose the
> hobbyist/maker community.
>
> Sorry for the rant, I'm a bit frustrated, it's midnight and I've been
> working on this for hours without success, just to get SPI working the same
> way it used to.
>
> For now, I'm going to revert to an older image. I'd love to update my github
> doc with some clear instructions on how to get SPI up and going on all of
> the documented SPI pins if someone can point me to a place where I can
> figure it out.

sudo /opt/scripts/tools/version.sh

Most likely your version of U-Boot in the eMMC is too old thus
breaking U-Boot overlays.

Otherwise for spi and config-pin, due to some pin's having MISO/MOSI
and CS and SCLK, I split them up like shown:

config-pin PXYZ spi ->

config-pin PXYZ spi
config-pin PXYZ spi_cs
config-pin PXYZ spi_sclk

So now it's even more configurable..

[William Hermans]

On Fri, Dec 8, 2017 at 10:57 PM, <clay....@healthelt.com> wrote:

So, this is what so (fun?) about the BB ecosystem.

I'm updating to the most recent image, trying to run code that has been working great for a good long time now, and it fails utterly with the same issue Nuno is experiencing.

I understand William Herman's point of view - for him, this is blaringly obvious. Why so hard? I'm sure he wonders. I'm willing to bet that William is an expert at embedded linux, and perhaps does it as a day job. That's admirable, and I think it would be fun to do that too.

But I don't.

I like making blinky lights. https://www.facebook.com/claytongulick/videos/pcb.10155266610164779/10155266622269779/?type=3&theater

My point here, is that if the BB community expects folks like me to stick around and not just use a raspberry pi for everything, we need to make this stuff easier.

I'm using the same documented SPI pins that Nuno is using, and on the latest image, it just doesn't work. Not only that, but the commands in uEnv.txt have changed. 

Where is the documentation on this? How are we expected to figure this out?

And now, according to Robert, I just simply can't use the pins I was using before without using something called dtb-rebuilder? 

Look guys, I know this stuff is like breathing to you and not a big deal. But changes like this without clear documentation are going to lose the hobbyist/maker community.

Sorry for the rant, I'm a bit frustrated, it's midnight and I've been working on this for hours without success, just to get SPI working the same way it used to.

For now, I'm going to revert to an older image. I'd love to update my github doc with some clear instructions on how to get SPI up and going on all of the documented SPI pins if someone can point me to a place where I can figure it out.

You need to slow down, and learn things. Seriously, when I first had a BBB in hand, I knew nothing about embedded Linux, and had to learn everything from the ground up. Since this was also when the beaglebone black first came out, there were no articles on the web. However, what I did not understand at the time, was the BBW was pretty much the same hardware from an embedded linux users standpoint. There were a lot of article out there . . .

Additionally, you should understand no one here gets paid to help anyone. So this comment "if you guys want to keep me . . ." comment is going to fall on deaf ears. The embedded Linux community is huge, but no one wakes up early morning thinking "gee, I hope there are a bunch of questions to answer today . . ."

Anyway, you probably have a lot to learn, just so you can form a proper question. Which by the way, was how it was with me a little under 5 years ago.

[Dennis Lee Bieber]

The following is just my viewpoint, and is not meant to be an attack on
any person. I've not done enough with the BBB (other than running a nasty
benchmark on it and an RPi3 -- and I think the benchmark wore out the
original RPi3 SD card, before I obtained a small USB hard drive for swap)

On Sat, 9 Dec 2017 12:10:23 -0700, William Hermans
<yyr...@gmail.com> declaimed the following:

>
>You need to slow down, and learn things. Seriously, when I first had a BBB
>in hand, I knew nothing about embedded Linux, and had to learn everything
>from the ground up. Since this was also when the beaglebone black first
>came out, there were no articles on the web. However, what I did not
>understand at the time, was the BBW was pretty much the same hardware from
>an embedded linux users standpoint. There were a lot of article out there .

The biggest hindrance currently is that practically everything that IS
"out there' for the BBB is based upon cape-manager and run-time device tree
overlays. There doesn't seem to be anything that firmly lays out how to
convert a cape-manager/overlay example into the u-Boot overlay scheme
(would be nice if such example actually used some major documentation --
say a side-by-side of Molloy's lessons).

Consider how many questions over the last few months have had answers
on the order of "... no longer create a separate FAT partition" or "... now
use u-Boot overlays". Neither of which actually explain how to go from some
now-outdated guide to equivalent functionality. Heck, I've even seen images
vary from auto-mounting an SD card (when booting from eMMC) to requiring
one to figure out how to perform a mount, and to some intermediate
condition.
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

[William Hermans]

This just tells me that either a) the person asking the question isn't willing to look, or doesn't know where to look. Both of the examples youve given above are explained on the elinux documentation pages. Of whcih I'm assuming wrote those guides. Robert at least links to them all the time, for question asked here. Not to mention in the case of uboot overlays, it's clearly mentioned, and linked to in the uEnv.txt file for every image I've seen to date.

As for the rest, yeah, IDK maybe it's just me( I doubt it ) but very seldom do I have issues following an older guide, and converting to a modern file system arrangement. I'd say, that perhaps more time needs to be invested in order to "get it" ?

Adapting overlays, source, etc is a matter of experience, and perhaps those who do not understand them should study, and experiment more ? Worked for me.

[clay....@healthelt.com]

William, just some feedback here. Since my original post, where I clearly explained that I was a noobie to BBB, I haven't found your responses to be helpful. 

> This just tells me that either a) the person asking the question isn't willing to look, or doesn't know where to look.

> As for the rest, yeah, IDK maybe it's just me( I doubt it ) but very seldom do I have issues following an older guide, and converting to a modern file system arrangement. I'd say, that perhaps more time needs to be invested in order to "get it" ?

Maybe you don't realize that statements like that are abrasive? 

I'm a noob to the BB, but not a noob to embedded systems or development. I've been doing it over 20 years, have built systems designed to support tens of millions of users, and feel comfortable coding directly in AVR asm, or x86 asm, C, or umteen other languages, platforms and backends. So when I point out frustration with the BB documentation and change process, it's not from the perspective of a sparkle pony, it's from the perspective of someone who has been doing this stuff for a really long time, and sees issues.

My criticism, which I think is entirely on point, is that the BB ecosystem has a problem with cohesiveness in documentation and approachability for makers and hobbyists.

From what I've seen, this is a reputation that the BB has earned throughout the maker community. I'm a member of the Dallas makerspace, the largest makerspace in the country - and the general consensus from the folks I've talked to there is "yeah, the BB hardware is great, but the documentation is terrible, if you want to be productive, use a Pi."

I volunteered to help out with this, especially as it relates to SPI, which is a pretty common use case for an embedded platform. Far from being constructive and helpful like Robert, after reading your responses, my general feeling is "why bother? I'll just go use the Pi". 

I'm sorry if it seems like I'm attacking you here, it's not my intent. I honestly want to give you feedback that from my perspective, and I think those like me, the tone and content of your posts serves to frustrate and alienate rather than community build and improve.

If we want to build the BB community and platform, our responses to newcomers, (especially those willing to volunteer to help!) should be welcoming and encouraging. Not a paraphrase of "RTFM" or "Well I figured it out, kid, so should you".

[William Hermans]

Clay, a bit of advice for you. Stop worrying about how you perceive someone over the internet, whom by the way doesn't know you, and you do not know them yourself. I'm not here to hand hold anyone, and I do answer question for those who ask questions in a way that makes sense to me. But if you've got a problem with how I say something. You know what, keep it to yourself. You're not paying me, or anyone else to help you for that matter. So ask your questions, then maybe they'll get answered. Otherwise, keep the personal opinion( which is wrong by the way ) out of it.