CODEWITHSUNDEEP
beagleboneblack
jonathanH
jonathanH

Reputation: 11

BeagleBone Black P9 Pinout - I2C2 conflicts with SPI1 and UART1

Got a general question regarding the GPIOs on P9 of the beaglebone black. For instance, I would like to use the UART1 (RX and TX) for a R232 communication and use the I2C2 (SDA and SCL) for a sensor, using a C language application running on Linux. The problem is that the UART1 (RTS and CTS) signals are on those pins, can these features be deactivated (software)? and therefore use the UART1 and I2C2 at the same time?

PIN 19 : UART1_rtsn - I2C2_SCL

PIN 20 : UART1_Ctsn - I2C2_SDA

Next question, the same applies for SPI1 (CS0 and CS1), these pins are also on I2C2 (SDA and SCL).

PIN 19 : I2C2_SCL - spi1_cs1

PIN 20 : I2C2_SDA - spi1_cs0

So the general question : Can all 3 units, UART1-SPI1-I2C2 all run at the same time with no conflict on pins using the P9 header of the bbb?

Thank you very much for your answers JH

Upvotes: 0

Views: 1045

Answers (2)

makepeace
makepeace

Reputation: 11

I think the other answer misinterpreted the question, and addresses configuration of the pins to perform a function of the possible mappings available to that pin. Yes, this is easily possible and is largely the point of the design.

With regards to the actual question, the answer is that it's possible but it's going to be very difficult and is most likely not feasible. And only one communication protocol will be able to be used at a time. Additionally, the spi pins are chip select pins, which require either an asserted or de-asserted state, so any kind of i2c clock or data signal will render the chip select non functional.

For i2c/uart, it would require reconfiguration of the pins and software mappings on the fly, and it will only be able to perform one of the possible functions at a time. It will also require software on all sides of the busses to be able to understand what mode the pins are in ie i2c or uart, with mutually separate and smart protocols so that none of the devices on the bus react undesirably to the garbage that will be on the bus when the bus is being used for another operation mode.

Upvotes: 0

Mathieu L.
Mathieu L.

Reputation: 438

It is technically feasable although when you start foraging into custom pin assignements you have to deal with alot of complexities to get everything up and working. There are many tables around the internet with the references as to which pins can do what. My favorite so far are these two : http://exploringbeaglebone.com/wp-content/uploads/resources/BBBP8Header.pdf, http://exploringbeaglebone.com/wp-content/uploads/resources/BBBP9Header.pdf

If you read these, you can see that each pin can take multiple different functions depending on configuration. These are set to the defaults by the linux kernel at boot time but you can modify the defaults using device tree overlays. The whole process is a little envolved for a single answer here but in short, to do what you want, you would need to modify and recompile the device tree overlay that the kernel loads for the device you want to change the pin assignements off.

Although there are some limits, for example, the beaglebone images are all configured to use I2C2 for identifying capes. So you can theoretically change it's pin assignments but then you shouldn't expect capes to be identified and configured properly when you do. In your example above, the UART1 and I2C2 work without conflict using their default configuration (UART1 only has Rx & TX by default). The SPI1 is a little more work. It's default configuration shares pins with the sound card (HDMI) that must be disabled to get it to work athough it does not conflict with ether UART1 or I2C2 by default.

Notice that each of these pins can have multiple functions but can only by one at any one time. Therefore, if a pin is set to use a given module (say UART1) it will not be affected by another module that can theoretically output on that pin with a different function mode. The kernel will complain if you try to use a pin for 2 functions simultaneously so you can try to load the overlays and see if it conflicts by default. Basically, if the kernel accepts to load the tree overlay, you can generally assume that it does not conflict with any other that is already loaded.

Upvotes: 1

Related Questions