OK, thru tracing hardware for now, so let's look at overlays for a second. Here is a link to what looks like the cleanest (if not official) code base for gpio configuration.
https://github.com/beagleboard/bb.org-overlays How this code base set up is traditionally, with a "make file". To build these, you usually just type "make all" or just "make". This is A correct way to distribute this code. But what I wanted to talk about is universala, more precisely: *cape-universala-00A0.dts* Now in researching this issue, you'll come across this file over and over again (its like the uEnv file). Here is what I'm suggesting you do in figuring out these DTS files (overlay or cape manager files) is you download the zip of the above github link and look at the files in it manually first. If you go to /src/arm within the ZIP file, you will come across all of your available overlays. Look for cape-universala-00A0.dts and open it in a text editor (I'm doing it in Windows so I'm using my EditLite). There is an important reason why I'm suggesting this. Look at the contents conceptually first OK? Its easy to figure out how the commenting out works (its similar or identical to C's commenting out). What you notice is that "universala" is obviously set up for using a BBB in the Cloud-9y, stand-alone way (i.e. using a lot of the pins for HDMI output and the like). Now this is NOT how I use my Beagle. I use it like a tiny UN*X host and telnet (SSH) into it and I want to use all of my GPIO pins as UARTs, SPI's and I2C's (as I'm using it as kind of a controller for a project with a lot of sensors and actuators and stuff). So I want to find an overlay that satisfies my requirements. So what I did was I started reading through the overlays available. I immediately was attracted to *BB-UART1-00A0.dts *. Now I was "surprised" when I manually read this file (I say this for teaching effect) because there is only the overlay for activating UART1 in it and it ignores all the other pins completely. This is very different from cape-universala-00A0.dts in that this file seems to be VERY preoccupied with every pin on the board. My working theory at this point is that they are...of course...overlays. In other words there is some procedure, some approach that allows you to overlay a bunch of these files in such a way that it ends up configuring the pins exactly how you want. But in typical UNIX tradition the reasoning is dense, commenting sparse and the code difficult to sift through. So that's my working theory right now is I have to determine conceptually HOW these overlays are actually overlaid over top each other. (Thoughts? to the group...conceptually...in plain english, no code what is the overlay process?) On Thursday, March 9, 2017 at 5:17:59 AM UTC-7, woody stanford wrote: > > OK, I want to get to the bottom of this whole GPIO issue on the BBB, so > I'm opening up this thread as a "documenter" whereby which I can take notes > based on my research into how you consistently, stably and SOLIDLY > programatically access the GPIO pins on a BBB. I've already done a lot of > the footwork so I'm not entirely unknowledgeable, but I want to get to the > heart of this issue and solve the mental block people have with this. A > private hope. > > Either way, probably a good mess of processed links, articles and > information where you can start. > -- 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/d7ddfd56-e197-4373-987a-b72c416b9ab4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
