Bitwise shift between two different port bases.

Believe (now) that what you seek cannot be achieved via a bitwise shift across 2 ports.  From long, personal experience - and review of function, GPIOPinWrite() - my belief is that only a single, 8 bit port may be output via that function.  Review of gpio.c w/in driverlib - especially the (apparent), single port constraint enforced by "GPIOBaseValid" is my rationale.  (note that other ARM MCUs may escape this 8 bit limitation - as may more advanced of this & past MCUs here - especially (and likely, only) those w/ external bus capability.)

In addition - two items disturb & deserve quick comment:

a) "GPIOPinWrite (GPIO_PORTC_BASE, GPIO_PIN_7, 1);    //Sel3"  Use of "1" here - to generate a logic high from that port pin - will surely fail!  (and, of course, has past worked for most every code implementation known to man!) But not Stellaris/rebrandWare.  The middle parameter w/in GPIOPinWrite() is a mask - exposing any/all pins so listed - to the possibility of impact by parameter 3. To set bit 7 - as you seek - you must encode param. 3 with bit 7's value which is 128.  (or 0x80)  Bit 6 requires 64, etc.  StellarisWare refers to this as, "bit-packed representation of the pin(s)."  You are not alone in this bit output stumble...

b) "GPIOPinWrite (GPIO_PORTF_BASE | GPIO_PORTC_BASE, GPIO_PIN_4|GPIO_PIN_4|GPIO_PIN_5|GPIO_PIN_6|GPIO_PIN_7, vCh[cCh]<<5);" You seek here to perform a bit shift - and you must exercise extreme caution when performing any operation upon Port C - which may impact PC0-PC3.  (those are the JTAG pins - and are "resistant" to any "modification," i.e. they must first be "unlocked" to repurpose - and this usually results in your being, "locked out" from any further MCU access)

In subsequent post (below) an outline of an alternate method is provided.

These MCUs are quite wonderful - as is Stellaris/rebrandWare - but do demand great attention to detail & compliance w/their (sometimes unique) operational constraints.   

Continued... I'm unsure [update: now highly doubtful] that your "multi-port" construct (3rd GPIOPinWrite(), above) will succeed.  You can confirm via experimentation or review of gpio.c found w/in driverlib.  Again - I'd stay far from Port C - during this process.

Might it benefit your effort to employ several SPI based, "port expanders" which would escape the requirement for your bit-shifts and multi-port blending?  These would reside, "off-board" - may warrant consideration.  IIRC - you may be able to harvest several such SPI modules from your base, MCU board.... 

And - in the "pre-flash MCU" days past - we all employed 74xx373/573 style HW latches - to create added outputs when the MCUs were pin constricted.  A data mux should enable you to route 4 - same port bits - into first the low - then high - 4bits of such latch.  (only then would you clock the latch)  W/in reason - or via single, cpld/fpga - this provides another solution for your port/pin command/control...

Agreed on expansion.  Common in my use has been 74x595 for ouput expansion via SPI.  Fast and simple.

One thought on the selx lines.  If they are distinct (i.e. only one on at a time) then another fruitful approach would be to use a 3 to 8 decoder which would free up two of your lines fairly quickly.  I suspect that's not the way your external device works.

This appears to be an SPI based device so I'd be inclined to use the '595 as the selector then you only need two selection bits.  One selects the '595 when you load an address into it.  The other selects your device (and uses the output from the '595 for the sel and maybe other lines).  You could get away with a single line but I like to have an option of neither selected.

One thing missing from your discussion is any discussion of speed requirements.

Robert

@ Robert/interested others,

Yes - your 74xx595 is quite a step-up from earlier, "SIPO" (serial in, parallel out) devices which, "walked" their output bits during the input clocking.  (albeit - the 595 "eats" inputs - 4 or 5 iirc - but enables all outputs to sync in unison)

And - along w/your "missing speed requirements" - response is not setting too many speed records...

I count 3 inputs as required. A chip select, data and clock.  Data and clock are, of course, shared with other SPI peripherals so if the AFE device is indeed SPI as it would appear then there need only be 2 lines used above the SPI clock and data lines, one to select the AFE and one to select the '595.  One line if you are willing to leave one device always selected.

The rest of the inputs on the '595 can be dealt with in hardware. 

These additional inputs can optionally be used to provide a parallel reset and tristated outputs. These can be useful for ensuring safe (or at least defined) outputs to external hardware.  Not needed for this application as described so far.

Original poster has probably been moved to a different high priority project.  I have some replies to posts outstanding here for that reason myself.  Hopefully I will get back to those soon and do them justice.

Robert

cb1_mobile said:

albeit - the 595 "eats" inputs - 4 or 5 iirc

My point - the 595 - unlike most all, earlier SIPO devices - may present its shifted outputs in unison - upon a distinct signal input.  (i.e. after all of the input shifting has completed)  That was not the case with earlier devices - which "rattled" their bits directly to the outputs - often causing unwanted effects...  That "output sync" gain does come at the cost of another signalling pin - when the 595 is in play.  (as opposed to simpler device...)

Thank you both for your extensive help! I will take a look at the 74AHC595 if I get a negative on my question I posted on this thread: http://e2e.ti.com/support/low_power_rf/f/851/t/305421.aspx

Thanks once again! :)