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,
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
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&theaterMy 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..
Regards,
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.
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
<yyrkoon@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.
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.
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”.
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.