In the GPIO they seem to be grouped as PT1, 2, 3, and 4 outputs and PT5, 6, 7, and 0 inputs I believe these are the VR inputs.
If so, I will have to review the spreadsheet and see if there is another configuration that might work. A couple of possibilities come to mind. The first cuts off functionality by stealing one of the gear position output display lines (LED). This is probably the easiest to implement but will hose the digital display. Short term it may be the most sensible solution.
The second is to look and see if there is a possibility of diverting a block of these VR inputs into outputs, Obviously if a smaller block of two could be diverted that becomes more feasible, but even if 4 is the number it could be possible. I just looked at the assignments and note the following:
-PT7 is currently assigned as Spare Output 1 -clutch 2 - SL2. An Output.
-PT5 is the input shaft speed sensor. Not required.
-PT0 is the output shaft speed sensor. This could come in on PEO/VR4 couldn't it? This circuit presently adds no functionality and is redundant.
If we can pull that off, we actually would add two surplus outputs, which could turn out to be of great benefit in the newer transmissions.
I have no intention of derailing where you're going with this.
I sat down and chewed away on this problem at a logic level and I hope this is a quick work-around.
If i use 4 LED drivers or four solenoid drivers, and if i can generate 16 unique binary numbers with those 4 lines, I can demultiplex the data and have 16 unique commands numbered 0-15.
So, I sat down with the shift strategy for the solenoids and a truth table for 4-16 demultiplex chip and for the princely sum of approximately 'lunch-money' I may have a work around.
The 4-16 demultiplexer chip uses 4 inputs numbered A0-A3 and outputs a single 'low' on one of the outputs Y0-Y15
SL1 and SL2 are in almost all of the shift patterns and in fifth, they are both used. I applied A3 to SL1 and A2 to SL2. I can then use a 3 input OR gate to develop the logic for SL3, SL4, and SL5 with the demultiplexed triggers.
I then select an option for A1 without A2 or A3 activated ( to ignore S1 and S2 ) and use an OR gate to Grab SL4 for the unique Reverse requirement.
So my thoughts are 74HC154 ( now obsolete in a DIP package) and a 74HC/HCT4075 Triple 3-input OR gate and driver transistors on the outputs.
attached are a couple of images so you can have a look at the logic.
The beauty of this Jekyl and Hyde pseudo-multiplexed system is it should give us access to the 10 speed transmissions without further major revision. I have a few lines left in the tables above.
But I can see where an add on would have appeal. If you could take the standard build, demux the LED outputs and provide the additional drivers along with the necessary logic for the shift trigger solenoid as an add-on that would have appeal, and like you say it could be expanded to add other outputs if needed. Actually I rather like the idea. Done correctly we could take the standard build Megashift and change nothing other than to enable 8 speed operation. (I'm not sure how you would expand that to a 10 speed, it sounds like that would take software revisions)
I'm quite interested in seeing what your meeting today results in.
Now as to the current state of my efforts, Huang describes, on page 186, assigning port direction stating, "The user can configure a few pins of an I/O port for input and the remaining pins for output."
The most common reading of this statement would be that 2 or 3 pins can be configured as input and 5 or 6 as output. So far I have found nothing in this book to negate that translation. However he doesn't expand on that statement, but only gives an example of alternating pin configuration: movb #$55,DDRB
In the GPIO the pins PT0-PT7 are grouped in fours, PT1-4 as outputs and PT5-0 as inputs. The code for that would be different.
I am not yet familiar enough with the code to decipher this. If instead we wanted to configure pins 5 and 0 as inputs and the remainer as outputs, what would the code look like that would be required to do this? And would it work?
At some point a view was expressed that the pins of a port had to be configured in groups of four. I do not know if this has ever been confirmed but the answer affects us here, and honestly I'm not even sure how to get that question answered.
I also do not know if the -128 reference manual (above) is an acceptable reference for this microcontroller, though I would expect that in the same family the port addresses should be much the same. Says it covers:
Covers also MC9S12P-Family
So I'll need to find out again which one this is and see. I also have the:
Edit: The memory locations for port T are identical in this manual.
I'm a bit confused by all the numbers.