On Sun, Jan 1, 2017 at 2:08 PM, Greg <soapy-sm...@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*. -- 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/CALHSORpHUdXpaX59%3DBx4oX_Lgjgth7JVgA2rHYgTY59rdWyR8g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
