TM4C1294NCPDT: External peripheral interface framing signal

cb1_mobile said:

16 bit Port Extender (single chip) steals 2 bits (I2C) adds 16 - that's 14 ADDED - a good TEN beyond the SPI driven shifter...

While that's true the shift register

• can be expanded easily, theoretically indefinitely but limited by clock fanout. IIC is limited by assignable addresses of the expander (and any conflicts with other chips) and fanout limitations on SDA and SCL.
• uses considerably simpler software
• is faster

I find the 2 extra pins a more than fair tradeoff for the gain in simplicity of interface. The reduction in necessary bus error recovery alone is worth it.

Robert

Robert Adsett said:

theoretically indefinitely but limited by clock fanout.

And the clock fanout can be compensated for, addressing another unmentioned issue at the same time.

Robert

You have,  "Fired the first salvo in today's (actually this morning's),  "CHIP-WARS!"    

Time to "inventory each side's "dueling forces:"     Shift Register (SR) ... ... Port Extender (PE)

• shift register can be expanded easily, theoretically indefinitely

• ditto for Port Extender  - and just TWO "PEs" deliver 32 GPIO.     Four SRs would be required to match that capacity.

• SR uses considerably simpler software  ... Dispute!   Assume first, 16 bits GPIO required - SR demands TWO devices - when 32 bits required - software requires  modification

•  PE software proves simpler as it remains "16 bit based" - only the I2C Slave Address requires modification to access the 2nd PE chip.

• SR faster  ... Dispute!   In fact that proves true ONLY if the PE employs I2C!    SPI devices are equally available.    SRs demand 32 clocks to reach the "outbound 2 ICs"   (just 16 for PE)

• PE software may also employ SPI ... More importantly - bits 17-32 may be accessed w/only 16 SPI clocks - half the number of clocks required by the SR!     Fewer clocks = faster - does it not?

May it be noted that the battlefield is littered w/fallen, bloodied, SR chips - many in their "inverted" (dead bug) position.     

Buzzards/Vultures, (even)  "Khaleesi's Dragons" circle overhead...     (it is expected that the departing Dragon will, "Click LIKE.")

cb1_mobile said:

• shift register can be expanded easily, theoretically indefinitely

• ditto for Port Extender  - and just TWO "PEs" deliver 32 GPIO.     Four SRs would be required to match that capacity.

Except that doing so uses up IIC address space. Not sure that's big issue but given the historic divisions of that space it must be managed.

cb1_mobile said:

SR uses considerably simpler software  ... Dispute!

IIC requires support for various bus issues that simply don't exist in SPI. This is a considerable difference. I have seen experienced capable designers suggest that IIC devices should, as a matter of course, have power fets on their power supply so that they can be power cycled in the case of an unrecoverable bus error.

cb1_mobile said:

• Assume first, 16 bits GPIO required - SR demands TWO devices - when 32 bits required - software requires  modification

•  PE software proves simpler as it remains "16 bit based" - only the I2C Slave Address requires modification to access the 2nd PE chip.

The extension of a buffer, not exactly difficult, I'd say less so than catering to two different devices but not really significantly so. If the buffer size isn't a constant you've made a mistake that needs correcting in any case.

cb1_mobile said:

SR faster  ... Dispute!   In fact that proves true ONLY if the PE employs I2C!    SPI devices are equally available. 

Oh? Hmmm... Digikey shows a non-stocked Exar part. In quantity more than triple the price of 595s in low volume. A quick check of the command structure suggests they cannot be chained so extra chip selects are required beyond the first 16 bits. Writing 8 bits also requires an 8 bit command.

Aha! Microchip has an available part. Still the same price differential but available in small qtys. Similar command structure but enough different that it looks as if it maybe it can be chained, I'd need more time to be sure one way or the other.

Is there another you are thinking of?

cb1_mobile said:

PE software may also employ SPI ... More importantly - bits 17-32 may be accessed w/only 16 SPI clocks - half the number of clocks required by the SR!

Nope. Writing 16 bits on these devices requires two 8bit command + 8 bit data pairs (32 clocks). The shift register can write the entire 32 bits in that.

I contend that it is, in any case, good practice to update all of these outputs at once at the end of the control loop. You've already decided these outputs don't require instant update. There's usually a fair amount of output that falls into this category.

In summary

• I think we are agreed on the IIC complexity, speed and addressing limitations
• The SPI port expanders are single sourced and more expensive. The shift registers are multi-sourced jellybean parts
• The SPI port expanders have 50% overhead, the shift registers have 0% overhead. Both have chip select overhead.
• While the SPI port expanders are more complex, the additional complexity doesn't approach that of the IIC bus.

So cheaper, faster and multi-sourced. I still favour the shift registers for digital output.

Note the caveat. For something like switch inputs, I am increasingly drawn to the SPI based multi-input switch detect ICs. They scan the inputs (reducing power loss and current consumption), provide wetting current and work at interface voltages (24V and 12V).

Robert

Robert Adsett said:

So cheaper, faster and multi-sourced. I still favour the shift registers for digital output.

Aha - finally - a "baited trap" often,  "Lures  prey."    (one here - homonym challenged - would lure "pray.")

PE "Port Expander" is able - on a bit by bit basis - to  UNIQUELY operate as GPIO Output ... OR ... GPIO Input!    (Thunder crashes - Lightning flames!)     SR "Shift Register" is  "Output Only"  thus demanding ANOTHER IC when even a SINGLE (added) Input proves helpful!    ( "PISO" chip, "164")   

Indeed I was thinking of MChip's PE devices (I2C first - then SPI - should speed prove important) - both are offered!     (I2C: MCP23017,  SPI: MCP23S17)

Might you be so good as to provide the "maker/part ID" of such "Robert approved/known"  (Switch Detect) device(s)?

In summary - our poster may have been, "Lost in battle" - or accepted the sole (answer) marked,  "Suggested."    His silence fails to reveal if his requirement may be enhanced thru the use of "Multiple Outputs AND Inputs."

While I grant you the point that  "jelly-bean, 595s (SIPO)" are lower cost - they cannot match the FLEXIBILITY of the Port Extender "bi-di" (Bi-Directional) operation - and will require additional chips to (almost) match the capacity of a single, 16 bit Port Extender.

For the vast majority here - I would bet (many Vegas chips) that the added FLEXIBILITY provided by the Port Extender - overwhelms the (relatively) slight cost-savings offered up by the "Output ONLY" shifter.  

Few here (to include moi) will reach VOLUME production  (where such "savings" (potentially) may add-up, thus earn some (slight) recognition!)       (maybe)    

FAR MORE LIKELY -  the ADDITIONAL & FLEXIBLE  I/O - provided  (ONLY) by the Port Extender - will surely - at some point - SAVE a Board Spin!      And that yields  (VERY) REAL & PREDICTABLE ...  SAVINGS!

cb1_mobile said:

Robert Adsett

So cheaper, faster and multi-sourced. I still favour the shift registers for digital output.

Aha - finally - a "baited trap" often,  "Lures  prey."    (one here - homonym challenged - would lure "pray.")

PE "Port Expander" is able - on a bit by bit basis - to  UNIQUELY operate as GPIO Output ... OR ... GPIO Input!    (Thunder crashes - Lightning flames!)     SR "Shift Register" is  "Output Only"  thus demanding ANOTHER IC when even a SINGLE (added) Input proves helpful!    ( "PISO" chip, "164")   

I figured at some point bidirectionaity would be mentioned. I've never needed it.

It's the difference between a definite purpose I/O and an indefinite purpose I/O. For definite purpose I/O is almost always defined as input or output. That which actually requires bidirectional I/O also usually requires faster speed than a port expander delivers, at least in my experience.

So the bi-directional is only really useful if you are attempting to save cost (better to use the shift registers in that case) or are in need of extra I/O. In that second eventuality you do the same thing you do with a port extender. Use any left over I/O you have in the unlikely event it hasn't already been assigned or add another shifter register (just as you would a port extender).  It's really no more difficult with a shift register than with a port expander, although you do avoid the potential need to deal with mixed I/O in your data in the port expander case.

cb1_mobile said:

Might you be so good as to provide the "maker/part ID" of such "Robert approved/known"  (Switch Detect) device(s)?

I've not used yet. But I think they've become widespread enough to do so. I've been looking at the SN65HVS882 for my latest.

cb1_mobile said:

While I grant you the point that  "jelly-bean, 595s (SIPO)" are lower cost - they cannot match the FLEXIBILITY of the Port Extender

I'm not convinced that the addition of bidirectional pins in useful except in the narrow case where you are making a unit that you plug other boards onto. Even then a serial expansion bus might be superior.

For adding I/O while avoiding a board turn and you don't have unused I/O it's the same procedure you go through if you have the same issue using port expanders. Add another IC as required to the headers you with great foresight provided.

I'd say they match the flexibility of the port expanders with less overhead and modestly simpler S/W.

cb1_mobile said:

FAR MORE LIKELY -  the ADDITIONAL & FLEXIBLE  I/O - provided  (ONLY) by the Port Extender - will surely - at some point - SAVE a Board Spin!   

I don't see any reason that's more likely with a port expander than with a shift register.

cb1_mobile said:

Few here (to include moi) will reach VOLUME production  (where such "savings" (potentially) may add-up, thus earn some (slight) recognition!)  

It's actually the multiple source advantage that's larger I think. I suspect we've all been caught with allocation and lead time issues.

Robert

i am planning on using general purpose mode of EPI with external NOT(inverter) gate for FSS, RD, WR signals. will it work??

regards,

digvijay khambe

Robert Adsett said:

Ain't  dead  yet!  (refers to the (so) humble shift  register )

If not "dead" - surely on,  "Life Support."     (And what IS that gasping sound?)    

Time now for,  "Closing Arguments/Summation:"    (No "new evidence" allowed at this stage)     Again:  Shift Register    vs.     Port Expander

• "I figured at some point bidirectionaity would be mentioned.   I've never needed it."
• But many/most here DO!     Port Expanders provide "Bit-selectable I/O" - almost exactly as the MCU does.    Surely there are times when "one more input" is needed - shift registers fail badly here!

• "It's the difference between a definite purpose I/O and an indefinite purpose I/O."
• A better description of the Port Extender is "Selectable and/or Flexible I/O" - which provides a huge advantage.

• "So the bi-directional is only really useful if you are attempting to save cost..."
• No - many times we've (and others) needed an "extra input" - again ONLY the flexibility of the Port Extender enables.

• "not convinced that the addition of bi-di pins in useful - except in the narrow case where you are making a unit that you plug other boards onto.
• Our firm's (regular) use of such "Port Extenders" serves as an uber flexible, "Insurance Policy" - buffering our board against the unknown.    The Port Extender chip may be "filled" as/if needed.

• SAVE a Board Spin!   "I don't see any reason that's more likely with a port expander than with a shift register."
• Surely you do!    The Port Expander (PE) offers "MIXED I/O" - not just Output.    And it is never intended that the "PE" is utilized to "capacity" - enabling a "needed Input."

May it be mentioned that Port Expanders  may  "Interrupt" the MCU - when (only) a single bit "change" occurs!     Such is HUGE - for example - frees one from "Constant Scanning of a Keypad!"    (i.e. the keypad's rows or columns are all "driven" - thus "ANY" key depression will change the state of the "undriven" rows or columns - and (only then) is keypad scanning launched!

Indeed both shift registers AND Port Expanders have their place.     If you know - without ANY doubt - that your "board requirements will never change" - then a shift register (may) succeed.

May I (ever gently) protest the claim that  "more meaningful feedback" has, "yet to arrive."

No case whatsoever has been made to "lock down" - use and only the use - of the EPI.

Multiple alternative methods - answering most any use case - have been presented - and presented in high detail.    Thus - (some) slight (perhaps even "meaningful") feedback HAS ARRIVED!

Exclusive use of the EPI appears "second best" - especially when such limited data transfer is attempted!     That's meaningful - is it not?

Not "all" client desires prove "proper and/or efficient" -  sometimes such recognition IS "meaningful!"

digvijay khambe said:

i am planning on using general purpose mode of EPI with external NOT(inverter) gate for FSS, RD, WR signals. will it work??

Let me join with the others and request that you provide a few details on what you are trying to achieve. You've told us how you want to achieve it but not what.

Robert

cb1_mobile said:

• "I figured at some point bidirectionaity would be mentioned.   I've never needed it."
• But many/most here DO!  

I don't think so. There are very few cases where it is needed. Simulating a data bus is one. Making a one-wire connection can benefit as well but there are not many others.

cb1_mobile said:

Port Expanders provide "Bit-selectable I/O" - almost exactly as the MCU does.    Surely there are times when "one more input" is needed - shift registers fail badly here!

Port expanders and shift registers have the same expandability. Compared to some port expanders (perhaps not all) shift registers are actually easier to extend. If you want one more input and you input chain has space you can add it. If you want one more input and your port expander is full you cannot. The same limitations apply.

cb1_mobile said:

• "It's the difference between a definite purpose I/O and an indefinite purpose I/O."
• A better description of the Port Extender is "Selectable and/or Flexible I/O" - which provides a huge advantage.

Nope: Definite purpose I/O is that for which a purpose has been defined. For non-generic modules that's the majority if not the exclusive set of I/O. Indefinite purpose I/O is that which does not have a defined purpose, the spare or expansion I/O that has not yet been assigned.

For definite purpose I/O the extra flexibility of having to init the I/O direction and address in chunks is just extra overhead.

cb1_mobile said:

• "not convinced that the addition of bi-di pins in useful - except in the narrow case where you are making a unit that you plug other boards onto.
• Our firm's (regular) use of such "Port Extenders" serves as an uber flexible, "Insurance Policy" - buffering our board against the unknown.  

That insurance can be equally provided by shift registers. Still not convinced.

cb1_mobile said:

• SAVE a Board Spin!   "I don't see any reason that's more likely with a port expander than with a shift register."
• Surely you do!  

Nope

cb1_mobile said:

May it be mentioned that Port Expanders  may  "Interrupt" the MCU - when (only) a single bit "change" occurs!

Yep, if you need an interrupt based on such then the port expander provides it but most cases I've seen for that the interrupt is unneeded. And in many cases it's more a liability than a help. The common justification is that it saves time, that is nonsense. In a real-time system your time budget is driven by the worst case. If you've got time to scan after an interrupt you've got time to scan regularly. And regular scanning considerably simplifies the code.

Interrupts are about latency not time saving. And you've already committed to longer latency if you are using a port expander, even more so than using a shift register and neither of them have low latency.

cb1_mobile said:

Such is HUGE - for example - frees one from "Constant Scanning of a Keypad!"    (i.e. the keypad's rows or columns are all "driven" - thus "ANY" key depression will change the state of the "undriven" rows or columns - and (only then) is keypad scanning launched!

As I was saying. Seriously I did write the above before reading this. Yeah, yeah suuuure I did. The only place I see this being an advantage is in low power apps where everything is asleep most of the time. I'm not sure port expanders have the right power footprint for that but it's one place where an interrupt could make sense.

Shift registers are cheaper, faster, simpler, and multi-sourced. Flexibility is a wash. Interrupts go to a port expander but then only for small number of cases that need it (key scanning isn't one). Port expanders may also be preferable where a smaller footprint is needed.

I do agree there's a place for both (and I hope anyone who hasn't zoned out following us has a better idea of the tradeoffs) but I also think that shift registers cover a wider range of problems and are more flexible than you appear to give them credit for.

Robert

respected sir,

As i told i m designing PLC. I can only use general purpose mode of EPI.  pins epi0s0 to epi0s7 are given to A1 to A8 of 74lvt245. epi0s29(RD) is given to DIR pin of 74lvt245 and epi0s30(frame) is given to OE. But OE and RD of 74lvt245 are active low. Hence i m planning on Inverting the FRAME(epi0s30) and RD(epi0s29) of uC and giving it to the OE and DIR pin of 74lvt245. Will it work??

Until poster Robert arrives/responds ... do note that the '245 is a transceiver - has NO latch capability - thus its use - as you now outline - appears "questionable." (to be kind)

It is unlikely that you'd ever seek to "read back" the address which, "you yourself - have just "fed to the '245" - is that not so?

It is suspected that an 8 bit "latch" ('373 as example) will better meet (any) requirement for, "more persistent" 8-bit, address data - likely to be presented to (another) device.

Unanswered remains, "Why you believe the EPI" is required?      What features/functions - provided uniquely by the EPI - lead you to seek its use?

Multiple (other) means have been suggested - even detailed.     Depending upon your (real) need - these may  prove far faster & easier to implement...

digvijay khambe said:

As i told i m designing PLC.

That's a start, but only a start. The SPI I/Os we've mentioned are well suited to PLC type operation. The shift registers and switch inputs in particular.

digvijay khambe said:

I can only use general purpose mode of EPI.

Why? What justification is there for restricting yourself so?

digvijay khambe said:

pins epi0s0 to epi0s7 are given to A1 to A8 of 74lvt245

Why are you doing this? As cb1 mentioned the 245 is a buffer. What's on the other side? What is the end goal you are trying to achieve?

Your stated goal (albeit a very vaguely stated goal) doesn't appear to match what you are trying to do.

Robert

Is it "usual" for "pulling teeth" to yield smoke?      (staff/I smell smoke...)

Robert Adsett said:

The smoke is hiding the mirrors.

If - and when - crack staff ever,   "stop laughing" ...  a border-penetrating,  staff-programmed drone - carries our bill for,  "Lost Productivity."

(you're to pay  (absolutely) "No Attention" - to the fact that  "today's output"  deviates  (just slightly)  from,  "staff norm.")