Regarding 24 I/O Triggering in TM4C123/TM4C129 MCU

Aravind .R said:

Is it possible to trigger 24I/O's at a time in TM4C controller,

I don't believe this can be done natively (directly) with this vendor's (nor most other's) ARM MCUs.

Long past - when 8 bit MCUs ruled the land - we latched data from a single port - and after (3) such port writes - 24 stable bits resulted.

Now each 8 bit write was clocked into a unique latch by 1 of 3 (additional) GPIOs.   And - most always - a "write strobe" was required to "pass" that 24 bit data to its target.  Thus - you have a 2 Port commitment from your MCU.   (one for 8 bit data, & 2nd port: 3 for latch strobes, 1 for 24 bit data ready strobe)

It may be possible to save one latch - and apply the GPIO port itself to one of the printer's 8 bit data inputs.  In that case - that data would be the last loaded - just prior to the generation of the 24 bit data strobe.

As a reduced chip count solution - small CPLD or FPGA - often serves such data need...

While our firm works w/many ARM MCUs - many vendors - we've not used that brand.  (yet)

Our experience is that most "normal" Ports output up to 16 bits (although just 8 bits, here) so 24 bit data (in one gulp) seems unusual.   Suspect that parts w/such capability would be physically larger - more expensive - and introduce other issues.  

Unstated - your posting - is any performance requirement.  Harvesting 24 bits in one go should "win that war" - yet the simplicity afforded by this vendor's TM4C123 - and your find (and use) of modern device (similar to past 8255 (port expander)) seems in best compliance with KISS.

Use of vendor's inexpensive eval board & creation of separate, Port Expander board - for test/verification - is my recommendation...

Use of any external bus adds multiple, new complications - may not (truly) be best if regulatory requirements must be met.

Your silent as to memory, processing and other performance requirements.  Any serious design requires those considerations - does it not?

24 bit data suggests some "memory requirement" demand.  If you move to external bus design you'll have to insure that you avoid conflict between memory and printer access - and that your (unstated) printer bus connection does not (unduly) load that external bus...