As far as tools go, no you are not likely to find anything. Luckily the CAN protocol is relatively simple and you can gather a lot of information through your good friends at google.
ex: First 3 links when googling CAN Protocol:
http://www.ni.com/white-paper/2732/en/
http://en.wikipedia.org/wiki/CAN_bus
http://www.ti.com/lit/an/sloa101a/sloa101a.pdf
One thing that you will need if you are trying to implement CAN comms is what is called a CAN transceiver. Check out the MCP2551 IC, I have had luck with it in the past (provided that your MCU has 5V IO levels).
3.3V CAN Transciever
http://www.ti.com/lit/ds/symlink/sn65hvd233-ht.pdf
MCP 2551
http://www.microchip.com/MCP2551
In order to communicate with the PC you will need some kind of interface that will connect to your PC anc interpret the CAN messages. There are multiple ways that this can be done. There are USB transcievers as you see here: http://www.amazon.com/USB-CAN-Converter-Adapter-Support-64-bit/dp/B009SG6OL6
There are also CAN cards that will attach to your PCI-X slots on your motherboard.
In regards to existing examples, look for examples that are not specific to your platform. While the implementation may be slightly different, the concept and protocols are the same.
Also...it looks like most of the information that you would need is provided in the links that you posted. Take your time, read through the datasheets and try to write some simple CAN communications that you can debug with a scope or better yet, logic probe!
If there is anything else that needs to be added to make his as an accepted answer, please let me know!
Sounds like either a baud rate mismatch or a start bit detection problem. Characters between 255 and 193 mean bits 7 and 6 are always set (0b11000000==192), as well as some lower bit (which are earlier in the serial sequence). Remarkably the receiver idles with RXD high while the transmitter should be inactive with TXD low; this combination could cause unexpected behaviour of the start bit, as the AVR transmitter will idle high. Not being familiar with the IrDA signaling standards, I would probably take an oscilloscope to the signal to examine if RXD is simply inverted from TXD.
If we do have inverted polarity behaviour, we expect a transmission like ...1111110dddddddd111111... to turn into ...111111xx0DDDDD00...0001111..., with the first 0 lost as no transmission, the 0 detected as start bit matching the least significant 1 of the transmitted byte, but the stop bit 1 would be inverted marking the framing error. At a later point, the 0 would be detected as a start bit, and eventually the transmitter times out, causing the appearance of a byte with a pattern 11...00 which does not have the frame error detected. All the data bits that are received are inverted and in the wrong position. The xes represent transmitted 0s which go undetected as the transmitter switches from not sending due to too long pulse to not sending because the value is 0. If this is the behaviour, a logic inverter on TXD should solve it.
Atmel's application note AVR1303, Use and configuration of IR
communication module, covers a peripheral meant to talk to this type of transceiver. It should show what sort of signaling is normally used. By the looks of it, the format used is one pulse per 0 bit only, so direct connection to the USART is not the way to go.
Best Answer
The CAN controller handles the actual CAN traffic, including bus arbitration, synchronization, CRC calculation etc etc. It is the brain of the communication, so to speak.
The CAN transceiver only handles the physical signal levels: voltage levels and the translation to/from differential signals. It also contains a lot of protection circuits against transients, ESD, brown-outs, short-circuits etc. These are very rugged circuits that can take quite a beating.
As a simplification, we can think of the CAN transceiver as layer 1 of the OSI model and the controller as layer 2.
That being said, using external CAN controllers is mostly a thing of the past, unless you have very specific requirements. For the past 20 years or so, the CAN controller is most often integrated in the MCU. The benefits of this are many: less error-prone, easier to work with, faster real-time access, cheaper, less board space needed.
So do yourself a big favour and forget about your LPC2148, but instead pick a MCU with CAN controller on-chip. NXP for example, have plenty of those to pick from, like LPC11C or Kinetis. As a bonus, you get an upgrade from legacy ARM7 to Cortex M.