With my code have you enabled a can broadcast from TS? By default my code doesn't do any requesting. Which arduino are you using?

edit: the seedstudio appears to be mostly identical to the sparkfun canbus shield.. d2 as interrupt, d10 as cs, stock spi pins. Not sure why my my code shouldn't work, serial is showing the can init?

Yeah, broadcast was enabled. I'm sure I screwed something up. Will try again tomorrow.

Weird.. I just ran the seedstudio library back to back with my code and both were able to pull data off the wire with the defaults (well, minus changing the chip select from 9 to 10).

Edit: I think I figured it out maybe.. add a SPI.transfer(0xC0); to reset and delay(100); to the beginning of setup()

and add

Serial.println(CANRead(CANCTRL), HEX);
Serial.println(CANRead(CNF1), HEX);
Serial.println(CANRead(CNF2), HEX);
Serial.println(CANRead(CNF3), HEX);

to the end. Both the sparkfun and seedstudio schematics are a little vague on their MCP2515 reset pin. If the CANread is printing 0x00, then MCP2515 isn't getting initted properly.

Finally getting somewhere!

Your code used an apparently deprecated version of "attachInterrupt"
New code:
attachInterrupt(digitalPinToInterrupt(INT_PIN), ISR_can, FALLING);


Now I'm reading data from MS3 and from the WB. Now to get rid of all your parsing routines and do a simple HEX dump....

@gooflophaze:
The data I'm reading using your code matches what I'm getting with the OBD2-reader!

I can see the actual data being stored in "databuffer". Where can I find the sender address?

Edit:
Of course the ultimate goal is to actually send data to the WB, reprogramming it.
Any chance you can help me with that?

Also: I have figured out part of the reason why the Seeed CAN library doesn't get any data. It seems to be the wrong initialization. Symptom: The MCP2515 doesn't pull the interrupt low after receiving from the WB. Using your code the interrupt pin gets pulled low. The RX line LED is flashing either way, so we know the transceiver is sending data to the 2515. But the 2515 can't do anything with the data when using the library. I'm using the same CNF registers as with your code, so the bitrate is set properly.

Huh, guess I'll need to push a quick update then. There's an easy way of making it non-intterupt, just do a quick if (digitalRead(int_pin) == LOW) { MSParse();} or something like that. Moving from the registers to can packet.. quick and dirty I can do real quick.

if ((B00001000 & SIDL) == 0) {
// standard (not extended) can frame
CANid = SIDH; // copy
CANid = CANid << 3; // shift left 3 bits into 16bit int
CANid = CANid + ( (SIDL & B11100000) >> 5); // copy 3 bits, shift them right
}

bewm, there's your 11 bit can ID. not as clean as pulling from a can library.

But I would encourage (now that it's verified the MCP2515 is working) getting the seed library working. I wrote my code trying as bare metal as possible to minimize memory. Plus it helps illustrate the Buffers vs Megasquirt ordering (if you use an ANSI terminal).

After confirmation that Arduino & MCP2515 are actually working, I hunted around Google for a bit and discovered a fixed CAN library here: https://github.com/coryjfowler/MCP_CAN_lib
Using that library I can read data and address from the WB with the Arduino.

Tomorrow I'll try and reprogram it to use 500kbps and standard frames.

Getting there!

bottom of MS3 Development Releases - Megasquirt EFI maybe?

Works in https://en.wikipedia.org/wiki/Public_domain would be "whose exclusive intellectual property rights have expired, have been forfeited, or are inapplicable."

MS is not public domain for sure. And while we are on this subject, MS is obviously not https://en.wikipedia.org/wiki/Open_source due to limitations under which they allow you to look at their source code. But they do show their source codes, at least some of them. Even if these are getting harder to find :)

As far as I know they don't claim to be open source in the traditional manner. They provide the source to people who purchase their products.

At that point we were actually talking about the TinyIOX module, which is made by Jbperf. I don't think they are officially part of B&G which I understand to be the owner of Megasquirt intellectual property. But in any case, I don't think their FW is PD or open source either.

I looked it up and turns out the attach isn't deprecated, it's just got a handy new helper macro to align pin numbers to interrupts.

I went back and read what you're trying to do with the packet - All you need to do to send that (with my code) is modify the MSRequest function.

81 81 29 01 00 00 03 (assuming these are all data bytes?). offset is pretty much the same as CanID, just need to disable setting the EID bit.

SIDL = (lowByte((offset << 5)) | B0001000); //set IDE bit change to
SIDL = lowByte((offset << 5));

and then

DLC = B00000011; < change to B00001000 since we're sending 8 bytes

and then start the data packets after DLC is transmitted
digitalWrite(CS_PIN,LOW);
SPI.transfer(0x40); // Push bits starting at 0x31 (TXB0SIDH)
SPI.transfer(SIDH); //0x31
SPI.transfer(SIDL); //0x32
SPI.transfer(EID8); //0x33
SPI.transfer(EID0); //0x34
SPI.transfer(DLC); //0x35
SPI.transfer(0x81);
SPI.transfer(0x81);
SPI.transfer(0x29);
SPI.transfer(0x01);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x03);
digitalWrite(CS_PIN,HIGH); // end write

that should write the packet you're looking for assuming I'm parsing the details correctly.

Edit: DLC should be B00000111 since we're sending 7 bytes. And if I wasn't clear before - MS's offset var is the same byte manipulation required to create an 11 bit can id. It's been a long day and my brain is fried.

Well, I just tried sending the data package from the Seeed CAN library, using

unsigned char stmp[8] = {0x81, 0x81, 0x29, 0x01, 0x00, 0x00, 0x00, 0x03};
u32 address = 0x1FFFFFFF;
CAN0.sendMsgBuf(address, 1, 8, stmp);

And it worked, since I can see it showing up on the monitor in between the data from the WB, but it didn't actually reprogram the WB....

I will try your addition/change to your code next.

Edit: This is the output I get with the monitor:

3 0FF00 01 33 5B FC FF 85 9A 0A 00
6 0F00E 01 FF FF 33 5B BA EA FF FF
7 1FFFF FF 81 81 29 01 00 00 00 03
3 0FF00 01 33 5B FC FF 85 9A 0A 00
3 0FF00 01 33 5B FC FF 85 9A 0A 00
7 1FFFF FF 81 81 29 01 00 00 00 03
3 0FF00 01 33 5B FC FF 85 9A 0A 00
3 0FF00 01 33 5B FC FF 85 9A 0A 00
7 1FFFF FF 81 81 29 01 00 00 00 03
3 0FF00 01 33 5B FC FF 85 9A 0A 00
6 0F00E 01 FF FF 33 5B BA EA FF FF
3 0FF00 01 33 5B FC FF 85 9A 0A 00
7 1FFFF FF 81 81 29 01 00 00 00 03
3 0FF00 01 33 5B FC FF 85 9A 0A 00
3 0FF00 01 33 5B FC FF 85 9A 0A 00
7 1FFFF FF 81 81 29 01 00 00 00 03

The "7 1FFFF FF" packets are my attempt at reprogramming.

So I have rewritten your MSrequest routine like this:
but what parameters to use for block, offset and reqbytes?

That's a function I ripped out of another program - so you can pass offset(can id), and ignore block and req_bytes (well, not ignore - you'll have to pass data but it won't do anything since EID* bits are ignored in a standard frame).

SIDH declaration is missing.

SIDH = lowByte(offset >> 3);


And we're sending 7 bytes, not 8 - so DLC = 0x07

quickcheck - no, i'm counting wrong.. it needs 8 bytes. DLC = 0x08, and you need another SPI.transfer.

Code is now changed to
called with
MSwrite(0x7ff,0x00,0x00);

Still can't see anything showing up on the bus....

You've filled the buffer, but you still need to trigger it. RTS == request to send.

// RTS - Send this buffer down the wire
digitalWrite(CS_PIN,LOW);
SPI.transfer(B10000001);
digitalWrite(CS_PIN,HIGH);

CANWrite(CANINTF,0x00);

Still no data on the bus -sorry to be such a pain...

Salright, I've been awake for 24 hours now so I'm starting to see crosseyed. MSWrite needs some of the values transposed, I think..

MSwrite(0x7ff,0x00,0x00);

should be MSwrite(0x00, 0x7ff, 0x00);

and the RTS is at the end of MSwrite right?

Progress!

data is showing up on the bus, but it looks like standard frames- not extended....
dump from sniffer: