I want to make a CAN bus sniffer for 250 kbit/s using my computer. After some research I've found that MCP2551 is some kind of voltage level regulator for CAN's physical layer. Keeping that in mind, I'm wondering if this setup could work. I just want to record the exchanged messages for automated test purposes, not be a part of communication:
PC <-> USB-UART (perhaps CP2102, bacause I already have one) <-> MCP2551 <-> CAN bus
If not, what kind of signals have to enter MCP2551 in order to make me be a part of the bus?
Four answers:
1. You can do that, but what you'll get on your CAN bus will be UART using CAN voltage levels. You have to supply the MCP2551 with CAN protocol messages if you want to communicate with CAN devices on your bus. Same for listening: CAN messages are so different from the UART format that the UART won't know what to do with them. You'll have at least frame errors all the time, and you won't get at the message's content.
This image shows the structure of a CAN message:
There's plenty microcontrollers around that have a CAN interface, sans the transceiver. It's for these that the MCP2551 was designed. In the past we've used the NXP LPC2294, which has 4 CAN interfaces. Each of them needs an MCP2551 to connect to a CAN bus. More recent controllers from NXP include the LPC1800 family, of which all members support CAN.
2. I have made a USB/CAN interface using FT2232H in MPSSE mode (forget UART), MCP2515 and MCP2551. MCP2515 is the key piece you're missing here. Study well what it does. It's the actual CAN controller that does framing, ACKs, checksum generation and verification, message filtering and other less obvious things that a CAN node is required to do by the standard. If you want a sniffer, MCP2515 has a listen only mode which guarantees no transmissions on the bus. MCP2551 is simply a dumb physical layer adapter, similar to a MAX232 for RS-232 or ADM485 for RS-485.
Now this architecture is far from perfect as FTDI MPSSE technology has essentially no support for interrupts (I believe it only uses bulk USB transfers behind the scenes), so I have to poll the controller frequently for new messages. This places a lot of load on the USB host controller but still doesn't guarantee that no messages are lost (MCP2515 can store up to 2 received messages internally if you enable "overflow mode", only one if you don't). A far better solution would be a proper microcontroller with builtin CAN and USB peripherals such as STM32F105 (103 can't use USB and CAN at the same time). See this project for a working implementation of exactly this idea. LPC18xx as suggested by stevenh will work too, but LPC17xx are probably cheaper and easier to find.
3. Since you want to listen in on a existing CAN bus as I understand the question, you really can't use a UART at all. CAN and UART siganlling are totally different.
You could in theory look at the CAN receive line coming out of the MCP2551 and decode the CAN traffic. That won't be easy, but it is theoretically possible. Without specialized CAN hardware, you'll have to sample a few times faster than the CAN bit rate and decode that bit stream in software later. You'll probably need to record at about 1 Mbit/s to decode 250 kbit/s CAN.
Using a microcontroller will be far easier. The PIC 18F2580 and other similar processors have a CAN peripheral built in. The hardware does all the bit level decoding and receives whole CAN frames. The processor can then send on received CAN frames via its UART to your PC.
4.Looking for a solution close to yours I did find this maybe it is useful
http://www.edcbase.com/product/showproduct.php?lang=en&id=74