After a reboot everything works fine. This was the result of many different tutorials about enabling periphery on beaglebone black. Propably it was not the right way, but I was glad that it finally worked
For jessie I found the dtb-rebuilder, but everything I tried to change did not work. New debian, no function - it’s very frustrating…
Can someone explain me, how to work with the dtb-rebuilder, so I can enable at least both can interfaces?
right now it’s called am335x-boneblack-custom.dts what would be a good name for it?
My guess is no, that is probably not a std config for most users. But I think the name is probably fine. I just had no noticed that file before, and it’s probably because you just committed it a couple hours ago.
However, what I was thinking since you said un-comment whatever you want working. Was that perhaps the file was already included, and people could just un-comment what they wanted to work. That I think might not be a bad idea. It would / could possibly help mitigate support needed to get some hardware peripherals working.
The includes for can0, can1 where in the repo prior, i just added back spi0, and the adc details…
and there wasn’t a real good non-overlay example, “am335x-boneblack-custom.dts” that users can enable what they want till today…
Ah, ok cool.
I was just wondering if some sort of GUI tool would be useful or not. And then if so, what level of device tree manipulation would be required for said tool to be of real use.
but it would be cooler to build the functionality into bone101, then user can edit it live thru nodejs and have it reboot with those changes…
You know you’re certifiable right ? hehe, but you’re also right, and I just happen to know it is possible. So what exactly is bone101 ? Just the web stuff, or does it include bonescript ?
I ask because I do not personally use bonescript, but am instead writing my own code that does what bonescript does( maybe more ). But is also much simpler in nature. Currently, I’m also try to attempt to do all this without including a bunch of NPM packages to reduce code bloat, and to help keep things understandable. So others can read through the code and instantly understand what is happening. As a bonus side effect, I’m hoping this means that in order to enable one thing, like say GPIO, or ADC, that the developer just need drop in a single file such as gpio.js, or adc.js, then just require that file.
Like you, I really dislike npm, but I suspect for maybe different reasons . . . code bloat, and application function clarity are two of my own main concerns.
*but it would be cooler to build the functionality into bone101, then user
can edit it live thru nodejs and have it reboot with those changes.. ;)*
You know you're certifiable right ? hehe, but you're also right, and I
just happen to know it is possible. So what exactly *is* bone101 ? Just the
web stuff, or does it include bonescript ?
I ask because I do not personally use bonescript, but am instead writing
my own code that does what bonescript does( maybe more ). But is also much
simpler in nature. Currently, I'm also try to attempt to do all this
without including a bunch of NPM packages to reduce code bloat, and to help
keep things understandable. So others can read through the code and
instantly understand what is happening. As a bonus side effect, I'm hoping
this means that in order to enable one thing, like say GPIO, or ADC, that
the developer just need drop in a single file such as gpio.js, or adc.js,
then just require that file.
Like you, I really dislike npm, but I suspect for maybe different reasons
. . . code bloat, and application function clarity are two of my own main
concerns.
npm and i get along now.
I've given up on "npm install xyz" in a deb package and now just pre-build
them:
it's an extra step before updating the *.deb package, requires a dedicated
bbg for pre-building the *.tar.xz, but my sanity has never been better!
it’s an extra step before updating the *.deb package, requires a dedicated bbg for pre-building the *.tar.xz, but my sanity has never been better!
So, I can tell you have not recently done anything like sudo npm install -g phantomjs . . . where phantomjs only has x86 / x86-64( maybe amd64 ) binaries. I have, and then spent 3 days trial and error compiling phantomjs on my rpi3 ( more memory, and more cores . . .), when i finally got it compiled, and installed locally. . . the flipping package that needed phantomjs still barfed on installation . . . as the other crap needed arm binaries too, and no way in hell I was going ot step into that huge pit.
It turns out that I only needed that package anyhow for a development dependency for some stupid other package that I do not need when deployed. . . . So I can write the code on an x86 machine, and just rip the needed source out for deployment onto the BBB . . .
So your sanity is different form mine in that you seem to have learned to just bypass the whole npm situation, where as a Nodejs developer - I can’t. Trust me though, I really wish I could, and it is partly why I’m writing my own Javascript wrapper for the BBB’s sysfs access to the peripherals.
So, if you ever looked at my G+ page, where it states “list bragging rights” and for my bragging rights I wrote " Having learned a good bit about javascript without losing my mind . . ."
The above, and situations like it are part of that meaning
it's an extra step before updating the *.deb package, requires a dedicated
bbg for pre-building the *.tar.xz, but my sanity has never been better!
So, I can tell you have not recently done anything like sudo npm install
-g phantomjs . . . where phantomjs only has x86 / x86-64( maybe amd64 )
binaries. I have, and then spent 3 days trial and error compiling phantomjs
on my rpi3 ( more memory, and more cores . . .), when i finally got it
compiled, and installed locally. . . the flipping package that needed
phantomjs *still* barfed on installation . . . as the other crap needed arm
binaries too, and no way in hell I was going ot step into that huge pit.
Yeah, that still happens for me too..
It turns out that I only needed that package anyhow for a development
dependency for some stupid other package that I do not need when deployed.
. . . So I can write the code on an x86 machine, and just rip the needed
source out for deployment onto the BBB . . .
So your sanity is different form mine in that you seem to have learned to
just bypass the whole npm situation, where as a Nodejs developer - I can't.
Trust me though, I really wish I could, and it is partly why I'm writing my
own Javascript wrapper for the BBB's sysfs access to the peripherals.
Yeah, my sanity is a little different..
Initially i was trying to have the deb package run "npm -g install xyz" and
update it on the user platform based on the version of nodejs..
I've changed that too:
I'm going to pre-build the package on jessie with nodejs v0.12.x and ship
it to the jessie users as is. (well the deb package has a hard
requirement of nodejs (>= 0.12.13))
I’m going to pre-build the package on jessie with nodejs v0.12.x and ship it to the jessie users as is. (well the deb package has a hard requirement of nodejs (>= 0.12.13))
Part of my own problem is that I am following a few different guides on technologies I do not know all that well. So I’m forced to use the packages these people are using until I understand things better. The problem being, many of these guides in using, the packages they mention require current versions of node. I tried using v0.12 / v0.10 version of node, and for the purpose of the guides I’m following - They failed( broken dependencies ).
I’m also still learning how things work package wise as for what exactly is really needed when you finish a project. It’s currently what I’m calling “dependency hell”. As in there is so much bloat / garbage, it’s hard to figure out what truly is needed in order for the application to work properly.
I got CAN0 working without a dtb file. But what i read so far, is that there will be conflicts with i2c when i try to enable CAN0 without pinmuxing it right…
If i take a look to the dts (am335x-boneblack-custom.dts) for beaglebone black (#include “am335x-bone-common-no-capemgr.dtsi”) and dts (am335x-bonegreen-wireless.dts) for beaglebone green (#include “am335x-bone-common.dtsi”) there is a big difference with the capemgr.
Is the am335x-boneblack-custom.dts compatible to beaglebone green?
I’m using the same BeagleBone image, but I’ve been unable to get the BeagleBone to boot after I followed your step-by-step instructions. Do you know if anything has changed in the dtb-rebuilder since you were successful in enabling can0?