Hello friends,
I could not figure out if there is a Windows device driver so that CAN messages can be read or broadcast. if yes, what else can be done through the driver? link to documentation?
Thanks a lot
Ali
Not sure you know what you are asking. There is no “windows driver” necessary. Windows recognizes it as a FTDI device and is available as soon as you plug it in.
Depending on what software you load into the arduino will determine what it can do. SocketCan and canutils are not something that are apart of windows. You will need software such as savvycan which is compatible with the canbus part of the M2. You CAN also access it through a serial terminal such as PUTTY as well. Doing anything else with it will pretty much require special software on a windows machine.
Not sure how to make linux see it as a socketcan device even though it is compatible with it.
If it can be connected to Linux as a socketcan device then you could use all of the normal canbus utilities but not under windows.
Yeah, you will need to load M2RET onto the M2 to make it able to send and receive CAN traffic. Then any serial port program like RealTerm or PuTTY can be used to communicate. Or SavvyCAN if you’re more partial to GUIs. But, there is no Windows driver to make it some sort of generic CAN device that you can use with other programs. Really, as Rod kind of alluded to, there is no such thing in Windows. There’s no standard interface for CAN. Every adapter has a different driver that talks a different way and programs have to include code to talk to all of the adapters they want to talk to. On linux there is a standard that all drivers can use and then any program that is socketcan compatible can use any adapter that is socketcan compatible. As luck would have it, M2RET supports that too. It is still serial on linux but there is serial socketcan and you can use it. Look up lawicel and socketcan and M2RET will present itself as a valid lawicel device on linux and support socketcan. So, if you are using linux and don’t want to use SavvyCAN (it’s available for linux too) then you can use most any other socketcan compatible program. There are LOTS of them out there - Caring Caribou, can-utils, etc.
Hey Collin, how do you connect to this via Linux to use canbus utils?
I assume it is reasonably easy?
Well, this is linux we’re talking about here. Easy is never the operative term. 
This link looks decent:
The general gist of it is that you need the slcand daemon to communicate with the M2 over serial and present itself as a socketcan device on the other side. This yields /dev/slcan0 which can then be used with socketcan tools like cangen and candump. When I get a chance I’ll see if I can dig up my old slcan script that did everything for me.
That would be great… Likely useful by a number of people. Can Lawicel 2.0 be supported through such an interface as well?
Since Lawicel 2.0 supports more than just canbus. I do understand that using the extended features of Lawicel 2.0 would need new software but at least would allow a common path for development beyond canbus.
Well, probably not. SLCAN just supports one CAN device per serial port. The hardware would have to expose multiple serial ports (theoretically possible) or SLCAN would have to be modified and those modifications up-streamed so that people can download the new version on whatever version of linux they’re using. That’s not terribly likely.
It’d be possible with a custom native driver (no serial in between, a socketcan driver hardware to CAN in one shot) to get three socketcan interfaces out of the M2: two CAN and one SWCAN. Then as soon as you plug it in you’d get can0, can1, can 2. This would lead to very high performance and better socketcan support than you get from SLCAN.
The value of Lawicel 2.0 is more in standardization of a serial interface. Right now nobody does the same thing as anyone else. GVRET doesn’t use the same serial protocol as cantact, etc. If we could get something like LAWICEL2 onto every device then people could code an application one time and then support a wide range of CAN capture devices. That could be a great boon for everyone. Then you wouldn’t be stuck using just a subset of the CAN programs. You could use nearly any of them even across platforms.
So if someone writes a “translator” that talks to the device directly then creates a Lawicel 2 interface we might be better off.
Since SWCAN is still a variation of CANBUS it would make sense to have 3 can ports. Allowing standard canbus software to work with all three. I am with you there. Since Lawicel 2.0 actually supports pretty much any protocol it certainly would make sense.
Might be cool to make such a beast for both Linux and Windows. My understanding is that socketCan is actually a network protocol. So it would be easy to build into the systems. Basically just adding a new type of network socket… Thus the name. When I was researching how to connect to SocketCAN it is as easy as using a raw network packet of type “can” So an expanded Lawicel likely would have to be called something else but guessing could be done the same way.
I really want to learn how to build both Linux and Windows drivers so maybe this could be a project I could do to learn them. I think there are some socketcan type driver software out there. Just not sure yet how to accomplish that same thing with Linux.
@CollinK, will you by chance be at GRRCON at the end of the month? If so maybe we could meet up for a few minutes and discus some options?
Rodney
Hello friends,
Thanks for your replies, I think I am not well versed in linux and tools mentioned. What I would like to do is to read and transmit CAN messages to/from matlab/simulink (automotive network toolbox) under windows. Vector hardware provides Windows driver to read/write messages by its software (canalyzer, …) through the hardware, same drivers can be used by matlab to read/write using same hardware. So my question boils down to if I can use macchina with matlab/simulink on Windows to ditch Vector hardware and software to read/write messages on the bus?
Thank you again for your help,
Ali
Well there’s a much more specific question. I like those. 
The answer is no, not really. You’d need a driver that conforms to the same API as the Vector tools. I very highly doubt that anyone is going to write such a thing. It’s technically possible to do but it’d be a lot of work, more so than people are likely to want to do. However, a Vector API based Windows driver for the Macchina M2 would really be something. It’s almost tempting enough that I feel like doing it. My biggest issue with doing it: Do I have matlab? No. Do I have CANalyzer? I wish. I don’t have any of the programs that would benefit from this and most people that do have those programs also have the expensive hardware already so I think the niche here is rather limited. If you can afford $28,000 for Matlab + plugins then you can probably afford a $1200 dongle too. If you’re like me and too broke to pay attention then you don’t have any of those cool programs nor any $1200 dongles and so you end up building your own stuff and/or getting cheaper hardware and software. So, I think the application domains just don’t intersect enough between the average M2 user and the average Matlab user. Feel free to try to convince me why this would be the awesomest thing since boxer briefs, raspberry jam, and sliced bread.
redheadedrod:
Yes, socketcan kind of lets a linux program just accept and send CAN through network sockets so it turns CAN into normal network programming which is a well trodden path in the UNIX world. I would be open to writing a native linux socketcan driver if enough people are interested. This would work for the three CAN buses. For the older buses people are pretty much going to be stuck writing other programs and having a non-standard way to access the data. The other buses are just too different from CAN to turn into socketcan devices coherently.
Sadly, I won’t be at GRRCON. I didn’t even remember it existed until you mentioned it. That happens to me a lot…
Every point made agreed. It is just that if it could do this, it would be as useful as devices 20 times more expensive. In that case not only enthusiast would buy it, but the whole automotive industry (or Vector would buy the company 
)
couple of more thoughts:
- Matlab/Simulink can be bought much cheaper by enthusiasts/students
- hardware support is not limited to Vector: Vehicle Network Toolbox supports CAN interface devices from Vector, Kvaser, PEAK-System, and National Instruments
- I am not sure if all others are using Vecor API, I assume there should be an easier way. Maybe worth to contact Mathworks on how it can be linked to Matlab
- I already submitted a request to support Macchina, but doubt they implement themselves
Thanks a lot
Ali
@CollinK I would like to learn how to write such a driver for linux myself. If I understand how to do it I could potentially do the same with other devices as well. Doing so for Windows would also provide for a more universal platform that could be used for other stuff as well. I have some other security stuff I can use the driver knowledge for.
Sorry to hear you won’t be at GrrCon. They are supposed to have a car hacking ‘village’ I will be checking out but hard to think it would be better than what I have sitting in my garage right now waiting on some parts which should be in today. Will be interesting to see what other labs look like and maybe get some ideas for my own.
I would atleast like to tinker with the idea of building a socketcan driver for Linux and Windows. I have researched building drivers before and providing a new socket based interface on both windows and linux might be a cool thing to accomplish. Would make is lawicel 2.0 compatible of course so it could support other than just CANBUS. Should still be compatible with standard canbus utilities that way.
I have some cool ideas for other devices that could help standardize some of the utilities out there too.
Rodney
@redheadedrod If you’d like to take a crack at a socketcan driver for M2 then here you go:
That’s a socketcan driver for the Microchip CAN Bus Explorer dongle. That’s the closest you’re likely to get and you could then modify that driver to work with the M2.
Looks promising based on the readme. It appears to be included with the Kernal now since 4.12.
Will have to insure my M2 is working correctly and go from there.
I would assume that with the M2 there should be 3 canbus ports since there is also the SWCAN.
Should be simple to have it work with other protocols as well.
.
While I am battling with my Lab I will work with this.
I am starting out with an online class that explains how the process works then will jump right into it.
Then I have to decide which direction to access the M2 with. Not sure if the M2RET will be the best solution or go another route. I will have to check into it more to see how it is structured to see if I should use the M2RET as the gateway or if something else makes more sense.
Will see how testing goes once I get to it.