CAN breakthrough!

Post by **jsmcortina** » Sun Dec 23, 2007 7:08 pm

For the first time ever I've actually got CAN working.

Two MSes running MS2/Extra hooked up via CAN. Turn the pots on the stim connected to one Megasquirt and the Megatune gauges monitoring the other Megasquirt move.

In the end the code isn't really too difficult either - I simply didn't understand what it was doing until today. Now I am able to explain it to others.

James

Keithg · Post by **Keithg** » Sun Dec 23, 2007 8:49 pm

Could we use this to pass the appropriate variables to another processor for idle control? Does it have to be another MS2 chip?

KeithG

On Dec 23, 2007 8:08 PM, jsmcortina wrote:

For the first time ever I've actually got CAN working.

Two MSes running MS2/Extra hooked up via CAN. Turn the pots on the stim connected to one Megasquirt and the Megatune gauges monitoring the other Megasquirt move.

In the end the code isn't really too difficult either - I simply didn't understand what it was doing until today. Now I am able to explain it to others.

James

UnaClocker · Post by **UnaClocker** » Sun Dec 23, 2007 11:18 pm

Might be handy for twin engine boats.. Have the two MS's communicating with each other..
From what I can gather in the MSefi forum, looks like the GPIO is nearing completion, so it'll be handy that our CAN code is functioning when it comes out.

6040solder · Post by **6040solder** » Mon Dec 24, 2007 4:32 am

jsmcortina wrote:For the first time ever I've actually got CAN working.

:-) congratulations! you seem happy about it indeed.

Two MSes running MS2/Extra hooked up via CAN. Turn the pots on the stim connected to one Megasquirt and the Megatune gauges monitoring the other Megasquirt move.

cool, ms2extragpio on the horizon then i assume :-)

were you fiddling to make your ms2 based trans controller work with it?

Now I am able to explain it to others.

they say that you dont truly understand something until that is the case :-)

well done!

Post by **jsmcortina** » Mon Dec 24, 2007 5:33 am

Some more info on this.

MS2/Extra has all along had the same CAN code as MS2 2.6, 2.8 etc. however I had been testing it in pass-through mode previously.

In that mode Megatune talks to MS2 via serial and then MS2 talks to GPIO etc. via CAN. I am still unable to get that to work when testing realtime variables (the gauges.)

However, all along there has been a snippet of CAN test code there. Last night I setup the two MS2/Extras (one as CAN_ID0 and the other as CAN_ID1) and then tweaked Al's test code to read from one to the other. Once I'd figured out what I was typing in wrong - BINGO! Yes, I was very pleased...

So basically, the working MS2 to MS2 CAN code has been in MS2/Extra all along. That is all Al Grippo's work with a tiny bit of porting and re-structuring by Ken and I.

The pass through mode is still an issue. I _think_ this is a Megatune problem at the moment.

The lack of pass-through need not stop progress though. Months back I had already placed storage space in MS2/Extra for GPIO ADC values with the intention of having MS2/Extra grab the data from the GPIO and store it locally. This can work with existing Megatune 2.25 and is what I demonstrated last night.
This alone means you could log an additional 8 ADC channels that were hooked up to a remote MS2 or GPIO.

Yes, CAN could be used to control a remote PWM idle valve - the only concern is response time. This may be a non-issue, but the current CAN protocol has a fair bit of overhead.

When first considering the CAN extension for MS2/Extra I had envisaged most or all of the control remaining on the master chip with the secondary chip as simply an I/O port. This works to a degree, but it does depend on the communications speed. The other alternate model is to have the control code running on the second chip and grabbing any runtime data it needs (e.g. rpm) from the master chip. Depending on the application there can still be some latency concerns - although I might be greatly exaggerating them.

The CAN comms do not require the remote processors to be MS2, so long as they physically talk CAN 2.0 A/B and are written to understand Al's CAN protocol.

My next step will be to test again with the GPIO 1.041 code on the remote chip as I couldn't get that to work yesterday. Under BDM it kept jumping to an illegal address??!

James

6040solder · Post by **6040solder** » Mon Dec 24, 2007 5:44 am

jsmcortina wrote:Once I'd figured out what I was typing in wrong - BINGO! Yes, I was very pleased...

:-)

Months back I had already placed storage space in MS2/Extra for GPIO ADC values with the intention of having MS2/Extra grab the data from the GPIO and store it locally. This can work with existing Megatune 2.25 and is what I demonstrated last night.

smart thinking! :-)

This alone means you could log an additional 8 ADC channels that were hooked up to a remote MS2 or GPIO.

thats awesome in its self for multi egt, multi iat (pre post intercooler), multi map, etc. i cant wait.

keep up the awesome work!

and merry christmas :-)

Post by **jsmcortina** » Mon Dec 24, 2007 7:24 pm

The next beta will have the CAN polling code in it.

There's also a mode where you can use a remote MS2 chip (with MS2/Extra code) as GPIO. Presently this only gives access to the 8 ADC channels and sends the data over CAN. I did this mostly to confirm that my code works and also because it was so easy.

James

6040solder · Post by **6040solder** » Tue Dec 25, 2007 12:33 am

That was fast! :-)

Well done, James' special Christmas gift to the msextra community! Cool.

devojet · Post by **devojet** » Tue Dec 25, 2007 4:41 am

Hi james, Do you plan to add the CAN code to your Microsquirt transmission code to free up some of the IO ports? I'm still very keen to use your transmission code in my hot rod.

Cheers

Daniel.

Post by **jsmcortina** » Tue Dec 25, 2007 5:25 am

devojet wrote:Hi james, Do you plan to add the CAN code to your Microsquirt transmission code to free up some of the IO ports? I'm still very keen to use your transmission code in my hot rod.

Yes, I'll do that sometime soon as it should be pretty easy.

James

Post by **jsmcortina** » Tue Dec 25, 2007 5:47 pm

I wrote some documentation that complements that in the Megamanual.

http://www.msextra.com/ms2extra/can/ms2can.html

Hopefully this should clear some of the fog surrounding CAN. Comments welcome.

James

Post by **jsmcortina** » Tue Dec 25, 2007 7:30 pm

devojet wrote:Hi james, Do you plan to add the CAN code to your Microsquirt transmission code.

Done. Only took just over an hour and seems to work ok with MS2/Extra.
I've not released this new version yet.

James

6040solder · Post by **6040solder** » Wed Dec 26, 2007 3:38 am

jsmcortina wrote:Comments welcome.

you switched from saying "page 2 and page 6" to "block 2 and block 6" without explanation, its pretty obvious that they are the same thing, but probably best to be consistent.

otherwise good.

that protocol looks scary to me. is there a checksum value attached to packets in hardware to ensure they are ok? or could some electrical noise introduced onto the can lines corrupt a store memory address and screw the ms up on the fly? if that could happen, i'd be wanting to keep the two devices in the same case for sure.

thanks for writing that up.

Post by **jsmcortina** » Wed Dec 26, 2007 10:13 am

6040solder wrote:
jsmcortina wrote:Comments welcome.
you switched from saying "page 2 and page 6" to "block 2 and block 6" without explanation, its pretty obvious that they are the same thing, but probably best to be consistent.

OK, hopefully sorted that and added a few other notes.

The packet data I've shown is intentionally simplified. That data is actually encapsulated in a larger packet. However, the inherent protocol information was confusing me. To grasp CAN I ignored all of the underlying protocol as Al has already written the code for it and used his "CAN_TEST" example to expand my knowledge.
The explanation regarding the real packet framing is in the Megamanual CAN link, so I won't repeat that in my page.

If you are wishing to understand MS2-MS2 comms enough to use it in software, my page should be sufficient. If you want to extend CAN to a non-MS2 platform you have a steeper learning curve and need to understand all of the CAN protocol.

James

woh · Post by **woh** » Wed Dec 26, 2007 10:32 am

James,
This is valuable info. I am not at a point where I need this information now, so I'm thinking it would be helpful if this became a 'sticky' for ease of finding in the future.

Post by **jsmcortina** » Fri Jan 04, 2008 6:48 pm

devojet wrote:Hi James, it was Lance's trans code I was trying to use with MS2extra that didn't work. It doesn't worry me though as I plan to use MS2extra and your trans code plus I was probably doing something wrong. Just thought I would let you know that it didn't work for me.

Ah, yes.
The table layout in MS2/Extra is presently based on 2.870 code, but it got slightly altered in 2.871. Lance's code talks to the latest MS2. He has added a compatability feature which is nice and ought to allow his code to grab the data from MS2/Extra beta17.

On further thought though, I need to update MS2/Extra's code to bring it in line with other CAN changes in the latest MS2 codes, so soon the tables will match up with MS2 2.871+

James

Post by **jsmcortina** » Sun Jan 13, 2008 5:00 am

The code in CVS is now closer to MS2 base. "outpc" is at block 7.

I also succeeded in getting pass-through CAN working as well. I was able to "tune" my trans code running on a Microsquirt while my laptop was connected to the MS2/V2 running MS2/Extra - all comms were going via CAN.

This required a day of debugging resolving bugs and missing code at both ends. Most of this code was almost certainly there in MS2 base in the first place, but during the initial port to MS2/Extra and the conversion to assembler some of it must have got mangled.

I posted some more stuff about it on MSEFI: http://www.msefi.com/viewtopic.php?p=187782#187782
EDIT: Skip that, it will be automatically deleted soon.

James

devojet · Post by **devojet** » Tue Jan 15, 2008 3:35 am

I have done some bench testing using James's Transmission Code and modified MS2 extra code. After some more bug fixes it now works perfecty for me as well. It's great being able to tune multiple devices from the one serial port.

Cheers

Daniel

Post by **jsmcortina** » Sat Jan 19, 2008 5:18 am

Here's the stuff I posted on MSEFI, reposting here because it has been moved and will be automatically deleted in a few days.

On the topic of CAN-passthrough.

I have managed to get it working today using Megatune 2.25 and MS2/Extra.

After fixing the omissions in my code, I was able to get Megatune to talk to a remote Microsquirt running trans code via an MS2/V3.

MT2.25 can work ok. To workaround the "blocking factor", I extended the MS2/Extra firmware to allow CAN pass-through reads of greater than 8 bytes and it seems to work fine - it makes multiple <=8 byte requests over CAN to fulfill the larger request over serial.
I hopefully prevented multi-byte writes by disabling the chunkwrite command.

I don't have an answer for pass-through reading simultaneously from two different CAN devices. The functional workaround I've implemented in MS2/Extra is to allocate space in outpc and have the MS2 grab the data from GPIO and populate that structure. Megatune then collects it by serial like normal.

I also added "Signature" as table id 14.

For fun I then wrote a simple CANbus scanner on my (linux) PC.

Code:
Scanning CAN bus..
0x0: Format: MS2Extra Rev2.0b18b. : Title: MS2/Extra pre2.0 beta 20080113 00:31GMT (c) KC/JSM ***MS2..
0x1: -- no device --
0x2: -- no device --
0x3: -- no device --
0x4: -- no device --
0x5: -- no device --
0x6: -- no device --
0x7: Format: Trans 00002 . : Title: Trans controller 0.002 20080112 21:12GMT (c) JSM **********
0x8: -- no device --
0x9: -- no device --
0xa: -- no device --
0xb: -- no device --
0xc: -- no device --
0xd: -- no device --
0xe: -- no device --
0xf: Format: Trans 00002 . : Title: Trans controller 0.002 20080112 21:12GMT (c) JSM **********

(NB, yes there's a bug in there somewhere - there's only one "trans" box.)
EDIT: That's not actually a bug - the code implements CANid 0xf as a broadcast address and all targets respond to it.

James

JeroenBosma · Post by **JeroenBosma** » Thu Jan 24, 2008 2:16 pm

I don't get the function.

Is it a pure (and expensive ?) dataloging feature or is it possible to share signals between two Megasquirts. I'd like to copy RPM, MAP, CLT, IAT and TPS from one MS to the other to have a master / slave setup running two megasquirts per engine. One for every bank.

Would CAN be able to unlock this ? If they copy their inputs but execute on their own variables you'll get two units providing their own signals but still running in sync. This would unlock 8cil COP or in my case odd fire COP for the odd-fire V6. It also leaves you 4 ignition outputs. Could lead to bizar staged injection setups ?

I guess it sounds rather odd. But I know Cummins Diesel engines work this way, BMW V12 did it like this and perhaps many more I am not aware of. I think it would make a brilliant system. The megasquirts are rather cheap. So 2 units are affordable in one car. Giving it features and numers of outputs like no other MMS. Correct me if I am wrong, or if it is impossible.

Megasquirt Support Forum (MSEXTRA)