The heart of the CANcrusher is the Freescale MK20DX256 ARM Cortex M4 running at 96MHz. It has 256KB of Flash, 64K of RAM, and 2K of EEPROM that make this a more-than-capable processor to handle the job. While my development is all in Eclipse using the ARM gcc compiler and a makefile, the libraries and support for the processor is all relying on Paul Stoffregen's Teensyduino library of files which allow me to quickly develop the service and application layer functionality without having to reinvent a SPI, USART, or GPIO driver.
My original thought was to use the built-in CAN peripheral of the processor and did build a prototype which uses it, but for the CANcrusher to be useful for hacking and development of a variety of vehicles and applications, it needed multiple flavors of stand-alone CAN channels. For this I turned to the Microchip MCP2515 CAN processor which fully implements the CAN 2.0B standard and communicates with the main controller via a SPI bus at 10MHz.
For USB communication, I really like Paul's RawHID driver and the fact that it can enumerate on a host machine without the need for any complicated driver installation. Unless I bump up against a bandwidth limitation, the RawHID driver will continue to be the main pipe to get data to and from the user. On the computer-side, I've written (and am writing) a variety of tools to support the device in Java using the Java HID API which is a JNI wrapper around a C/C++ implementation of the driver. (https://code.google.com/p/javahidapi/)
While USB is the main COM protocol for in-the-car analysis and hacking, I wanted a couple other channels to work with so I added a GSM module from IteadStudio (Model: IM141125004) for remote access and an RN42 Bluetooth radio which allows data rates up to 1Mbit and beyond. (Note on Bluetooth: Why didn't I choose a BTLE radio that would allow easy support for iPhones and iPad app development? BTLE doesn't allow the bandwidth of the RN42. While BTLE struggle to achieve even 1Kb/s, the RN42 will allow up to 300kb/s using it's built-in SPP protocol. So, for now, I've limited the CANcrusher to Android. Although iOS doesn't support SPP, OSX on my Macbook is able to communicate with the CANcrusher just fine.)
The GSM radio is based on the SIM808 which also includes GPS. This saves me the trouble of incorporating a standalone GPS module and so far, works very well. I chose the SIM808, like I choose the Teensy 3.1, because there is a ton of information out there on how to use it.
- 3 independent CAN channels supporting DW-CAN, SW-CAN, and LSFT CAN based on the MCP2515 CAN controller.
- 1 LIN/KLINE channel
- Bluetooth radio (RN42) with built-in SPP (acts like a serial port)
- SIM808 GSM / GPS Radio
- SD Datalogging using Bill Greiman's SDfat library for up to 64GB cards
- Real time clock using the DS3231 high precision RTC
- Teensy 3.1 (ARM Cortex M4) running @ 96MHz
- 8 Multi-purpose Inputs and Outputs for directly interfacing with the vehicle (outputs are open collector negative outputs with optional pull-up resistors.)
- LED Indicators (4 LEDs)
The firmware, as discussed, is Arduino compatible and uses many of the libraries people know and love/hate. Planning to use the GNU General Public License on the firmware and any software created.
On the computer-side, the initial software will be developed in Java with some of the following goals (some early versions of these features is done already):
- USB or Bluetooth communication with the CANcrusher
- CAN bus monitor allowing sending and receiving data, processing, reverse engineering, etc...
- Accepts CAN databases (*.dbc) format
- Imports and exports log files in Vector and Intrepid Controls Systems format
As an embedded engineer in the automotive world, I have used the high $$$$ systems and they're great! But they're expensive... There were times that I wanted to have a low-cost system that I could code myself and was inexpensive enough that I could leave in a customer's trunk to monitor my product and report in wirelessly without worrying about ever getting it back. I can't do that with a commercial device that costs $5k-$10k. My goal is to get as many of these built and out to other automotive and hacking enthusiasts as possible in the hopes that the firmware base and the support tools can approach the same usefulness and quality as the closed source commercial tools.