CANbus and Arduino - MSG_CMD data format
12-26-2021, 09:31 PM
#1
Newb
Thread Starter
Join Date: Dec 2021
Posts: 4
Total Cats: 0
CANbus and Arduino - MSG_CMD data format
I'm interested in building my own "CANbus GPIO board" using an Ardiuno. So far, I've managed to send ten-bit analog values to my Megasquirt (MSG_RSP) upon receiving an MSG_REQ from the Megasquirt. Next, I'd like to toggle GPIO pins on the Arduino when commanded by the Megasquirt.
Page 8 of the Megasquirt 29-bit CAN protocol describes MSG_CMD, but it's rather brief, and doesn't give any hints regarding how data is formatted in the CAN packet. I also haven't been able to notice a pattern when watching serial messages...
When I open Tuner Studio, browse to CAN Parameters, and enable Ports Polling, what is the format of the data packet sent to the remote device? Which bytes in the data packet correspond to what commands?
Page 8 of the Megasquirt 29-bit CAN protocol describes MSG_CMD, but it's rather brief, and doesn't give any hints regarding how data is formatted in the CAN packet. I also haven't been able to notice a pattern when watching serial messages...
When I open Tuner Studio, browse to CAN Parameters, and enable Ports Polling, what is the format of the data packet sent to the remote device? Which bytes in the data packet correspond to what commands?
Reply
0
0
12-27-2021, 08:18 AM
#2
There should be CANIO, 8 inputs and 16 outputs or something like that.
As I recall, they are handled the same exact way that your analog value was. Megasquirt asks for canin 0-8, and that corresponds to a one byte reply.
Outputs are done through can broadcasts, far as I can tell.
As I recall, they are handled the same exact way that your analog value was. Megasquirt asks for canin 0-8, and that corresponds to a one byte reply.
Outputs are done through can broadcasts, far as I can tell.
Reply
0
0
12-27-2021, 12:08 PM
#3
Newb
Thread Starter
Join Date: Dec 2021
Posts: 4
Total Cats: 0
I think its starting to come together for me.
It looks like the Megasquirt expects the digital ports to be a 3-byte table in the receiving device, with each bit in each byte corresponding to the state of an associated pin. It looks like the MS is hard-coded to expect the lower bytes in this table to be the "output" ports.
When I configure 3 input ports, the MS only sends MSG_REQ messages, asking for three bytes in my Remote Table Number. That number decreases as I turn up the number of output ports. Also, when I enable output ports, I start getting MSG_CMD messages from the MS. With one port enabled for output, I can see that toggling pins there causes the data to count up in binary.
I'll keep playing around with it. For some reason, the MSG_REQ messages seem... odd... With 3 inputs selected in TS, the MS asks for 3 bytes to be written to table 7 offset 166. This makes sense, that's the realtime data table. But when I change that to 2 inputes 1 output, suddenly the table changes to table 0 offset 24. I don't think input port data belongs in the CLT calibration table!
It looks like the Megasquirt expects the digital ports to be a 3-byte table in the receiving device, with each bit in each byte corresponding to the state of an associated pin. It looks like the MS is hard-coded to expect the lower bytes in this table to be the "output" ports.
When I configure 3 input ports, the MS only sends MSG_REQ messages, asking for three bytes in my Remote Table Number. That number decreases as I turn up the number of output ports. Also, when I enable output ports, I start getting MSG_CMD messages from the MS. With one port enabled for output, I can see that toggling pins there causes the data to count up in binary.
I'll keep playing around with it. For some reason, the MSG_REQ messages seem... odd... With 3 inputs selected in TS, the MS asks for 3 bytes to be written to table 7 offset 166. This makes sense, that's the realtime data table. But when I change that to 2 inputes 1 output, suddenly the table changes to table 0 offset 24. I don't think input port data belongs in the CLT calibration table!
Reply
0
0
12-27-2021, 06:47 PM
#4
The offset and table requested are configured in can parameters, you can make them whatever you want.
You can try pushing data to any table you want inside MS3, doesn't work. The MS3 needs to be configured to actually stuff that data into the table itself, canbus IO is essentially buffered to prevent table corruption. If the megasquirt requests table 0 offset 24, it's because you set it to ask for that "table" on the remote device. Megasquirt handles putting it back in it's own tables.
If I recall, the output ports are part of the request for the input ports or something like that, it's only two bytes max? Otherwise you can broadcast them. It's been a while, and I never actually used them outside testing, but this works.
You can try pushing data to any table you want inside MS3, doesn't work. The MS3 needs to be configured to actually stuff that data into the table itself, canbus IO is essentially buffered to prevent table corruption. If the megasquirt requests table 0 offset 24, it's because you set it to ask for that "table" on the remote device. Megasquirt handles putting it back in it's own tables.
If I recall, the output ports are part of the request for the input ports or something like that, it's only two bytes max? Otherwise you can broadcast them. It's been a while, and I never actually used them outside testing, but this works.
Spoiler
Reply
0
0
Thread
Thread Starter
Forum
Replies
Last Post
