I am concerned about this too, I was just about to order a few Black’s but it sounds like I am going to have to rewrite my code. Seriously, this is not “Backwards Compatible” if this is the case… You should say, does the same thing, a whole new way.
Could one of the actual Beagle people chime in on this?
Thanks,
Gregg
A new way as dictated by the Linux gurus, of which we have no control. Some guy name Linus I do believe. I suppose we could drop back to 3.2 and stay there. Sure would save on a lot of future SW development that is for sure!
Gerald
Gerald,
Please forgive me if I suggested you guys are doing a bad job. Rereading my statement I sound like a jerk.
I guess I should ask a question that is useful.
Is there any documentation on current practices for muxing the pins with the new Kernel (because that jerk Linus that gave us Linux) and current version of Angstrom? I used the old system pretty extensively to enable my platform. However, I like the overall design of the BeagleBone Black for my project. I would like to migrate to it, but am having some trouble seeing the migration path.
Gerald, you have answered a great number of my questions in the past, and I thank you for that!
Cheers Mate!
Gregg
Not that I know of. The SW folks I don’t think have done any of this that I have seen. All of of this is new, and shaky at best. It is new to everyone. Supposedly it will make life easier, but it appears there is some pain to be endured along the way, like breaking something that currently works. Hopefully the SW folks will chime in at some point.
You might try the IRC channel and see if anyone is hanging out there.
http://beagleboard.org/Community/Live%20Chat
Gerald
Hi Gregg,
If you really need to get your UARTS working quickly - check out this thread a few down in the list titled
Where are the serial ttyO1,2,3,4?
I haven’t got mine working totally - but one user has. I don’t know if links work here or not - but here it is.
As Gerald said - it looks like the latest version of the kernel is moving towards using Device Trees. I didn’t like it much either, but after looking at it a bit - it does make sense to me .
Has anyone setup a Soft or Virtual cape definition file, that successfully configured their BBB to have maybe 2 UARTS working?
I also started down the line of trying to build one. I used the guides that were mentioned in the thread you linked to. I installed Ubuntu on main machine (Dual boot now), downloaded the tools, which did not work, Then through the read me files figured out I needed to do some sudo apt-get… of some more components (like 32 bit support). I then built the boot directory and did the stuff to build the kernel… Now looking at the voodoo that is in the capes support of the kernel.
As I mentioned, sure would be nice if someone had a .dtsi file that defined this along with some additional instructions on how to build them and what other files that need to be edited. I am trying to follow the instructions that others have posted including:
http://hipstercircuits.com/adding-beaglebone-cape-support-to-a-kernel-with-device-tree-in-ubuntu/
What is also unclear to me so far, is for example if I wish to enable /dev/ttyO1, do I simply need to define the IO pins for UART1_RXC and UART1_TXC, do I also need to define the pins for RTS and CTS, even though I don’t need them. Also if these pins are defined will the ttyO1 object be automatically created or do I need to define this some place else?
I am hoping this is not their end solution, that is assuming this works, having everyone who wants to use a serial port of having to download all of this stuff to build the patch files is a bit difficult. At a minimum it would be nice if it were possible for someone to build a file, that others could copy to the appropriate place on their BBB and maybe simply edit of something like the /boot/uEnv.txt file.
Kurt