Multiple SPI buses, I²C buses and serial ports

[fivdi]

The specification doesn't appear to mention whether or not multiple SPI buses, I²C buses and serial ports are supported. Does this mean it's up to each implementation to decide whether or not this is possible?

[phoddie]

The underlying hardware determines what is possible. For example, if the hardware has two SPI buses, that is the fundamental constraint.

The implementation of the host chooses what to support. For example, a host for the hardware noted above may choose to support zero, one, or two of the SPI buses.

I have a sense that you are asking something more, however. If so, please expand on the original question.

[fivdi]

The implementation of the host chooses what to support. For example, a host for the hardware noted above may choose to support zero, one, or two of the SPI buses.

That's good to hear.

I have a sense that you are asking something more, however. If so, please expand on the original question.

Yes, I did have more to ask but before thinking about the topic I wanted to know if multiple SPI buses, I²C buses and serial ports were supported.

Here is what I was thinking:

An STM32H743VIT6 (LQFP100 package) has 4 x I2C, 6 x SPI, 4 x USART, 4 x UART and 1 x LPUART. The datasheet is available here.

The 4 x I2Cs are called I2C1, I2C2, I2C3 and I2C4.

Let's assume an MCP9808 temperature sensor should be connected to I2C4. On page 86, the datasheet reveals that pin 92 (PB6) can be configured as I2C4_SCL and pin 93 (PB7) can be configured as I2C4_SDA. However, the datasheet also reveals that the exact same two pins can be configured as I2C1_SCL and I2C1_SDA.

If an I2C instance is to be created to read the temperature from the MCP9808 sensor, how can it be told to use I2C4?

Before opening this issue, I didn't know how the I2C instance could be created. I thought it would be necessary to explicitly tell the I2C constructor to use I2C4 and that an new constructor option would be needed to achieve this.

Now, after thinking more about the topic, I realize that pin specifiers offer the flexibility required to achieve what's needed. In this case, the alternate functions needed to configure PB6 and PB7 as I2C4_SCL and I2C4_SDA could be encoded in the pin specifiers, for example, something like this for I2C4_SCL:

{port: "B", pin: 6, alternateFunction: 6}

and something like this for I2C4_SDA:

{port: "B", pin: 7, alternateFunction: 6}

[phoddie]

@fivdi, thanks for the additional details.

Short answer: yes, no problem.

Longer answer: The specification anticipates a different approach. I will try to explain.

If the ports are functionally equivalent, it may not matter which one is used. In that case, the host could assign an available port based on the pins. This does not work for all scenarios. Where it does work, it has the advantage of minimizing what the script needs to understand and manage.

The specification anticipates that host will specify the port in the options object passed to the I2C constructor:

let i2c = new I2C({(port: 1, address...});

...or even...

let i2c = new I2C({port: "I2C4", address...});

The Host Provider Instance's IO Bus Properties are designed to help with this. The allow a host to name IO buses in a way that encapsulates the configuration of that bus. The host on STM32H743VIT6 can provide four i2c bus configurations, and client code can use them as follows:

let i2c = new I2C({
   ...host.i2c.C1,
   address; 0x34,
   clock: 97,
   data: 98,
  ....
})

The value of host.i2c.C1 will look like the previous example ({port: "I2C4"1).

Often a development board has a default I2C bus as a consequence of its hardware design. In the case, the host could define a default I2C bus. This is insulates the developer from many details in common situations.

// host code
host.i2c.default = {
   ...host.i2c.C1,
   clock: 97,
   data: 98
};

// client code
let i2c = new I2C({
   ...host.i2c.default,
   address; 0x34,
  ....
})

And, of course, this is all conveniently moot in the case of simpler MCUs where the pins automatically select a port, such as the one and a half serial ports on an ESP8266.

[fivdi]

The Host Provider Instance's IO Bus Properties are designed to help with this.

Nice, this is far better than forcing people to become familiar with details of alternate function every time they need to use a pin specifier.

I think the initial question raised by this issue has been answered so I'll go ahead and close the issue.