CAN Communication between LPC1766 and LPC11C24

Why does "different microcontrollers" matter here?

Don't you think that anyone who implements CAN for use in a vehicle has to communicate with "different microcontrollers"?

Wouldn't it be quite silly if CAN required all nodes to use identical controllers? Why would controller A need to know the brand and model of controller B? Would that change the contents of the frames?

Thanks for your reply

You are right.But I want to know how do you communicate between those two microcontrollers?

I have sample codings and I want to know how to send a mesaage from LPC1766 to LPC11C24.

If you have usable sample code, then you use it. Just decide what frame identifiers you want to use for the messages you send and have the other side listen for them.

If you have initialized the CAN controller, it's enough to fill the transmit buffer with the frames you want to send. The CAN controller takes care of bus arbitration and makes sure the frames gets sent. And the CAN controller on the other side can pick them up as long as it is configured for the same bus transfer speeds and you haven't put in a filter to ignore these frame identifiers.

Thankyou

It would be nice if you can show a sample code on how to send the message from one microcontroller to another

But my sample code would look quite similar to the sample code you can already find.

Have you looked at the code bundles available? For some reason, I get an extremely strong feeling that you are doing your best to not spend time with the source code that your chip manufacturer have published specifically to help their customers get up and running with the NXP processors.

You are right.

So you say, but you rather obviously don't have the knowledge to make such a statement. Because if you did, you wouldn't ask the following:

But I want to know how do you communicate between those two microcontrollers?

Which part of "it doesn't matter which microcontrollers are involved" did you fail to get?

The important thing here is that the LPC1766 has two CAN interfaces.

So it's possible to write a program that communicates between these two interfaces. It is very common to create initial software by using this kind of loopback trick, because it allows the same debugger to both debug transmit code and the corresponding receive code.

It should then be possible to change the cable to instead interface with some other processor - of any make and model. The LPC1766 does not need to know what it communicates with, as long as the two chips supports the same bus timing, and you don't send messages at a faster burst rate than what the receiving end can support.

So the available sample code for LPC17xx are enough to get that side of the communication working. And while I haven't looked, it's quite likely to exist similar code for the other processor - at least assuming that the processor does support CAN.

Software development is all about breaking things down into small enough puzzle pieces that each piece can be 100% fully understood. Implement enough of these small pieces and then merge them to form more complex solutions. When talking about hardware, it's a bit like thinking about an onion - new layers of code on top of each other to supply more and more complex solutions. The bottom layer just knows how to send and receive. The top layer decides when to send, and what to send. Somewhere in between, there might be layers to figure out if there are needs for acknowledge and resend in case a message gets dropped.

The same code bundles does contain - together with the processor user manuals - enough to get the bottom layer code up and running. How to send a CAN frame. How to receive a CAN frame. The chip manufacturer have invested time and money to supply that information just so the customers will be able to make use of the chips. People who do know how to send/receive with the chip had to get their knowledge from somewhere - why don't you consider using the same sources?

OK

Thanks a lot for your help at the right time