Thanks for your response. My comments are long in hopes that both my findings and responses will help someone in the future. Please correct any incorrect statements.
I did see that I have to enable Xgate when I set up the initial project. Code intended to run on the XGate has its own special file extension (.cxgate) whereas code intended for the processor maintains the standard extension (.c). You cannot call a function written for the Xgate from the S12XA and vice-versa as the code is not compatible between processors. There are a few app notes describing how to exchange data between the two processors.
If I understand you correctly, I can move my code over with minimal effort to start. The peripherial / memory mapping is not direct but I think those fix-ups are relatively quick. The peripherials are not exclusively mapped to the Xgate processor rather I have a choice between which processor (Xgate or S12XA) manipulates SCI, SPI, I2C, etc. depending upon my implementation.
I did see somewhere in the high-level documentation that I control which processor handles the peripherial interrupt(s). Again, I want to reiterate that am interested in just getting my exisiting application moved over quickly and then focus on using Xgate making the changes one peripherial at a time (i.e, SPI, SCI, I2C).
I think my approach, in general, is good especially if anyone feels a bit intimidated about Xgate in the beginning. This is true in whether migrating processors or coding from scratch. Do you see any flaw in this reasoning?
