Thank you for this response. It's good to know that I can indeed use other pins for the I2C1. I'm still new to the BBB and to Linux, so I need to look into how to 'load the universal cape'. Is there a reference explaining this ? I played around with config-pin some but am not sure what it's really doing nor when it applies. For ex. I can tell a pin to be GPIO or I2C. If that is so, is config-pin changing just the electrical nature of the pins, like IN vs OUT, slew rate, etc. or is it also connecting it to a different I/O subsystem ? And if it's connecting it to a different I?O subsystem like GPIO or I2C then is it also enabling and/or configuring that as well ? When I first got the BBB I breezed over the provided docs on the unit and various sites, and bought Malloy's book (outdated). Perhaps there was something in the provided doc's that I didn't realize would help me with this. I'll have to take another look. I come from an electronics background and understand what the hardware is doing, generally. Usually I program device access and application code in C or assembler, but on simpler systems like a standalone micro-controller (i.e. not an SOC). But the layers that Linux has, especially when it keeps changing, adds a huge amount of complexity and detail that I'm still getting used to. I want to use node.js to to a lot of this work. I'm taking an online course about embedded Linux to help with it all. I betting that it'll pay off later, though.
On Tuesday, February 19, 2019 at 8:38:20 AM UTC-5, Charles Steinkuehler wrote: > > On 2/18/2019 9:21 PM, [email protected] <javascript:> wrote: > > It's unclear to me so far why so many I/O pins are shared, creating > > exclusions, yet so many other I/O pins are left as simple GPIO. I mean, > > can't we have both two I2C and 2 SPI at the same time, all on different > > pins ? > > Use the I2C1 pins on P9.24 and P9.26 and you won't conflict with any > SPI pins. Load the universal cape and use config-pin to set the pins > to i2c mode. > > The core chip on the BBB (and just about _every_ non-trivial SoC) has > a lot of pin multiplexing to enable more features. The BBB suffers > slightly in addition due to the fact that not all pins are available > on the P8/P9 headers, further limiting options. A good reference for > the pin multiplexing is this spreadsheet (forked from selsinork, I > added details on pin usage for various CNC capes): > > > https://github.com/cdsteinkuehler/beaglebone-black-pinmux/blob/hal_pru_generic/pinmux.ods > > > ...and of course the AM335x data-sheet and TRM from TI. > > It can be frustrating trying to work through the various pin > multiplexing options, but it would be a *LOT* more frustrating not > having _any_ pinmux options! :) > > -- > Charles Steinkuehler > [email protected] <javascript:> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/6b44a7a0-65eb-47c8-83b5-87b57f043d9b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
