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, bruce...@gmail.com 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
> cha...@steinkuehler.net
>
--
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/6b44a7a0-65eb-47c8-83b5-87b57f043d9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
