Since I have not yet implemented any code changes by myself, I'll test the communication as soon as I get a chance (probably tomorrow).
sorry for posting this much, but following your instructions I was still unable to get a connection with the new 1.100 template firmware.
All I'm getting is a "firmware signature mismatch" error that I can't seen to resolve.
Make sure you have loaded the GPIO.INI file (for the mainController.INI if you are connecting by sserial, for the CAN device if you are using the serial on the engine controller). The INI is NOT the same as for the older project so you MUST acivate the newer INI (that will cause the firmware mismatch error).
On the other hand, I find that TunerStudio sometimes gives the 'firmwware mismach' error when setting up a new project. I always tell TS to 'connect anyways' if I am sure I selected the correct INI, and the next time I fire up TS everything works wothout errors, so I haven't worried about it.
If this was mine, I would try connecting directly to the GPIO's serial port first, the process is simpler for TS.
If you are using the pass-through and connecting the PC's serial port to the engine controller, be sure to activate CAN_COMMANDS in the setting for the GPIO - this is required.
You can be sure the INI and code work to enable the serial and CAN comms, since I have tried them here and they are fine.
I've managed to access the GPIO by serial connection while having it connected to my MS3 by CAN. I can play a little with my stim's inputs and it gets recognized by the GPIO (for example the RPM inputs).
However, I'm still unable to access it by CAN pass through. I've tried for hours but I can't get it to display anything by pass through connection even though I did everything as you described.
Could it be because I'm connecting to my MS3 by USB rather than by serial cable?
Something is definitely not right, and I am looking into it. Hopefully it won't take too long to find the problem.
I am still looking into this, it is probably something obvious, but I don't see it right now. Fresh eyes in the morning might help. I will post here when I have it fixed.
I have this fixed now (it turned out to be a simple but subtle issue in the INI that resulted from an accidental 'cut n paste' at some point). The CAN pass-through is working perfectly now. I will do a bit more testing and some clean-up, then post the project later today if all goes well. I will let you know once I have done that.
The updated 1.101 Template code is linked from this page: http://www.msgpio.com/manuals/iocode/code.htm
Compared to the 1.100 template code, this code:
- fixes a number of INI errors and omissions (some minor, some major),
- makes sure the inpram and in2ram structure sizes are multiple of 8 bytes (224 bytes and 24 bytes respectively in the base code). This may not be strictly necessary anymore, but at one time I found it crucial for the CAN pass-through comms (which internally handles 8 bytes at a time). This may have been changed to allow non-multiples of 8 (it was always supposed to be able to handle any number of bytes in theory, but didn't in practice), but I keep it this way because it is easy to do, and can't hurt. I generally try to keep outpc size a multiple of 8 if I can too (base is 56 bytes), though this has never been an issue (at least so far).
- fixes the delay counter function in the code.
It has been tested for both getting the outpc values from the engine controller over CAN, as well as using the engine controller to get outpc and set inpram values (and burn them using flash) over CAN (i.e. the 'CAN pass-through'). All testing was done with 2.920 code on the engine controller. The serial communications (directly to the GPIO board) have been tested and work fine too, of course.
There is an appropriate INI for the template code in the zip file. This INI can be used if connecting directly to the GPIO with a serial cable, or for CAN pass-through operations (be sure to set CAN_COMMANDS). For help setting up the CAN communications, see: http://www.msgpio.com/manuals/mshift/cpt.html