Type 6 Expanded?

[KKING]

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

[JColvin]

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

[KKING]

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..

 

[JColvin]

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

[KKING]

Thanks,

Kevin

[JColvin]

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

[KKING]

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

[JColvin]

Hi @KKING,

We are in the process of updating the standard; I'll let you know once it goes through.

Thanks,
JColvin

[KKING]

Thank you very much for your consideration and work,

-Kevin

[n3rdx]

Wishful thinking:

just curious if the PMOD standards team can consider for 2021 the possibility of using high density pin connectors (there are umpteen options, pick one) if many GPIO (who doesn't need more than a few) I/O is desired, or mixed signal (analog/digital/differential) interfaces are desired. Perhaps a 20~30 pin multiple-row connector (or finer pitch connector) could be considered which would allow independent VARs to produce adapter cables (e.g., high density PMOD to standard PMOD) adapter cables for sale. .... It would save board space! 

But if that option can be discussed (please), then i would also ask why not float the concept of a FMC-very-light adapter standard where an I2C (or IIC) (or whatever-bus) chip with I/O banks could be supported as PMOD I/O fanout - save pins on the FPGA (good) and fan them out at the connector (excellent) and allow different operating voltages, or direct connections to opto-couplers. Yes, this could be a different product series - perhaps very useful for the industrial/academic applications of Digilent products.  I ran across recently products from a vendor Diodes, Inc., with a fairly low cost IO expanders - one of them allows 64 I/O on a two-wire dedicated bus (I2C/SMbus) at speed of upto 400 kHz.. What I am suggesting is that the PMOD adapter connector be utilized as multiple I2C bus (say, on a 6x2 conn. you would get about 5 such bus plus VCC, GND), each supporting 64 I/O in a mux/demux arrangement) interface to a captive I/O bus expander. Slight need for a software mux/demux but almost any code to read/write 16/32 bits at a time could be used.

[KKING]

Hello JColvin,

I know it is not high priority, but any updates to this?

-Kevin

 

[JColvin]

Hi @KKING,

I apologize for the delay. It was agreed that we can add in a new section for the expanded Type 6 (I2C). I have written the new wording for the documentation and am waiting to get feedback/approval from the interested parties.

Thank you,
JColvin

[KKING]

Thanks!

Do you need any other information from me?

-Kevin

[JColvin]

Hi @KKING,

Not at this time. For your own reference, this is the text that I proposed (with an additional blurb in the physical interface section towards the beginning of the topic) for the type 6A expanded I2C.

Quote

This interface conforms to the I2C specification, with an optional interrupt and reset pin plus some optional control signals. If these optional pins are not used, they will be no connects. The pull-up resistors used to provide the logic high level for SCL and SDA are provided on the modules and can be attached to or detached from the bus via onboard jumpers. Pull-ups on INT and RESET, if used, are also provided on the module and can be attached or detached from the bus via onboard jumpers to enable daisy chaining.

An optional passthrough female Pmod connector may be added to the Pmod opposite to the side with the male connector. This connector may be a six-pin or 12-pin connector, though it should be considered that extra control signals, such as those on the lower row on a 12-pin connector, may not be appropriate for a pass through connector due to the potential signal conflict if other modules in a daisy chain also used these control signals.

Thanks,
JColvin

[KKING]

Hello JColvin,

 

Any new on this update?  I would like to release some PMODs and MCU boards that use this.

 

Would be nice if I could say "Type 6A" rather than Type 6 + Type 1 in my documentation

 

Regards,

Kevin

 

[JColvin]

Hi @KKING,

I apologize. I had submitted the changes for review, but didn't receive feedback/changes on them so it slipped off the radar. I sent i to our content manager who handles formal documentation today and they said they should have the formal PDF version completed by early next week.

I will let you know as soon as I hear it is completed and uploaded to the site, though you realistically start saying it is formally complaint now and point any customer to this thread who asks for verification.

Thank you,
JColvin

[KKING]

Thanks.

Just FYI, I am about to release 9 PMODs and would like to officially call them Type 6A rather than Type 6 + Type 1 in the documents

Example 3D rendering attached.

-Kevin

[JColvin]

Hi @KKING,

I have updated the Pmod page with the new Pmod Interface Specification 1.3.0 that includes Type 6A. I'm also in the process of updating the individual Pmod pages to list which Digilent Pmods conform to 1.3.0.

Thanks,
JColvin

[KKING]

Thanks, I will download and adjust my documents as necessary,

-Kevin

PS if someone on the Digilent team would like a  PMOD or two from Renesas, please let me know.  We will have 9 new by end-of-year.

[KKING]

Hi JColvin,

 

Just read the update for Type 6A. Might be a minor cut and paste issue. Looks like some of the Expanded UART description snuck in.

 

-Kevin

 

[JColvin]

Hi @KKING,

So much for the review process on Digilent's end. I'll get it updated today.

Thank you,
JColvin

[KKING]

Hello JColvin,

We are about to release at least 10-12 PMODs with Renesas devices of various types, mostly sensors though.

Is there someone my boss can contact to talk about some kind of press release and/or partnership in producing these.

-Kevin

[JColvin]

Hi @KKING,

I reached out to our Marketing Manager about this and they said they would like some additional details. I have sent you a private message with their contact information.

Thanks,
JColvin