• 0
KKING

Type 6 Expanded?

Question

We are using the type 6, but we want a second row to add “proprietary functions” for some I2C sensors (i.e. power control / enable, BUSY#, etc…).

Right now we are calling it Type 6 + Type 1 in second row.

Much like there is a type 2 SPI and a type 2A Expanded SPI, it would be nice to have Type 6A Expanded I2C.

What are the possibilities of adding a type 6A Expanded I2C where the second row is all GPIO?

How do I put in an official request to Digilent Engineering?

PMOD_example.bmp

Share this post


Link to post
Share on other sites

6 answers to this question

Recommended Posts

  • 0

Hi @KKING,

I can put in the request for you. So I understand your question correctly, is this a request for this description to be formally added so that you can develop modules that conform to the Pmod Standard?

Otherwise the Digilent system boards with the two row Pmod headers are GPIO based so that they can readily support a variety of protocols.

Thank you,
JColvin

Share this post


Link to post
Share on other sites
  • 0

Yes, would desire that a Type 6A be added.  We are in process of designing some Sensor modules that need a couple of extra GPIO on the second row.  We can control our own MCU board designs, but would like to say we use a "PMOD standard" that is in the specification.   Seems like there are a couple of "Expanded" standards, so hopefully this fits the flow of the specification.

I understand that the dual row are GPIO, but it does not guaranteed SCL and SDA on the correct pins for I2C (aside from bit-banging which is painful).  Am I correct?  

Thanks for your consideration in this matter..

 

Share this post


Link to post
Share on other sites
  • 0

Hi @KKING,

I have formally put in the request for you. I hope to hear feedback regarding this change (though I can't imagine why this change would not be incorporated) in the next couple of days.

Thanks,
JColvin

Share this post


Link to post
Share on other sites
  • 0

Hi @KKING,

I believe we are on board with adding a Type 6A to the standard, though we do have a couple of questions/points that we would like your (or anybody reading this thread) feedback on as a customer.

The main drawback against creating a Type 6A at the moment is that if pre-defined GPIO lines are added (I presume you are needing more than two of these GPIO lines since the standard as it currently stands allows for two alternate signals, such as an interrupt and a reset line, to be used in place of the No Connects on pins 1 and 2 on the Pmod header) the ability to daisy chain different I2C modules will become difficult. In principle, if all of the extra GPIO signals were only used on the bottom row of the Pmod header, you could still daisy chain I2C modules by treating the top header row as just Type 6, though that isn't necessarily following the spirit of being able to daisy-chain multiple modules together if you ignore half of the pins. Do you (or anybody else that happens to be reading this thread) have an opinion on this?

Additionally, do you think the pass-through pins on header pins 1 and 2 would still be needed on the Type 6A, for the top row or to be included on the bottom row?

Thank you,
JColvin

Share this post


Link to post
Share on other sites
  • 0

Hello JColvin,

Tell the team, thanks for considering,

I hope I can answer to your satisfaction.

In first ROW, we are already using RESET and INT, the alternate signals in Type 6.

First, I am not sure we should define the second row with anything but GPIO, but if you are planning on defining alternate signals, I have 3 desired..  

Second, the currently planned signals may apply to other vendors of I2C devices.  Right now, the 3 I need are:

BUSY# - Wired ORed, low true so tells the MCU someone on the I2C chain is Busy. You can poll the status of certain sensor without making a lot of digital noise on the I2C bus. Might keep the board a little "quieter" while AD conversions are going on.  Might be good for any I2C ADC boards as well (sensor of sorts).

ENABLE (have not decided if it low true or high true, but leaning toward high true so just a pull-up enables if no one drivers that GPIO and the sensor default to ENABLED).

POWER_ENABLE for Sensor without RESET where the I2C bus can be hung up by noise.  Leaning toward high true for same reason as ENABLE. If no one drives it low, the device is on by default.

Finally, we are documenting our 12 pin (Type 6 + Type 1) such that if you want to daisy chain type 6 (6 pin), which we plan to do, you would put it on the end of the chain.  Currently we are only planning to Daisy chain 2-4 mix of I2C based sensors which make "logic system solutions".

We would have a mix of devices that have INT#, and BUSY# at this point.

Regards,

Kevin

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now