Add CAN api filter support and LPC11CXX CAN implementation

[omdathetkan]

Add CAN->filter function and modify CAN->read definition to allow reading specific messages.
Add bitfields definition to LPC11XX target generated from UM10398
Implemented most of the CAN functionality for LPC11CXX target

[matthewelse]

Nice to see that you've got the CAN done Joris :)
On Oct 22, 2013 7:07 PM, "jorisa" [email protected] wrote:

Add CAN->filter function and modify CAN->read definition to allow reading
specific messages.
Add bitfields definition to LPC11XX target generated from UM10398

Implemented most of the CAN functionality for LPC11CXX target

You can merge this Pull Request by running

git pull https://github.com/jorisa/mbed master

Or view, comment on, or merge it at:

#91
Commit Summary

• Add CAN->filter to API and add placeholders to hal's
• Add bitfields definition to LPC11XX target
• Add can_api hal implementation to LPC11CXX target

File Changes

• M libraries/mbed/api/CAN.hhttps://github.com/Add CAN api filter support and LPC11CXX CAN implementation #91/files#diff-0(16)
• M libraries/mbed/api/can_helper.hhttps://github.com/Add CAN api filter support and LPC11CXX CAN implementation #91/files#diff-1(3)
• M libraries/mbed/common/CAN.cpphttps://github.com/Add CAN api filter support and LPC11CXX CAN implementation #91/files#diff-2(30)
• M libraries/mbed/hal/can_api.hhttps://github.com/Add CAN api filter support and LPC11CXX CAN implementation #91/files#diff-3(3)
• A
  libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11XX_11CXX/bitfields.hhttps://github.com/Add CAN api filter support and LPC11CXX CAN implementation #91/files#diff-4(1768)
• M
  libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11XX_11CXX/cmsis.hhttps://github.com/Add CAN api filter support and LPC11CXX CAN implementation #91/files#diff-5(1)
• A
  libraries/mbed/targets/hal/TARGET_NXP/TARGET_LPC11XX_11CXX/TARGET_LPC11CXX/can_api.chttps://github.com/Add CAN api filter support and LPC11CXX CAN implementation #91/files#diff-6(411)
• M libraries/mbed/targets/hal/TARGET_NXP/TARGET_LPC176X/can_api.chttps://github.com/Add CAN api filter support and LPC11CXX CAN implementation #91/files#diff-7(9)
• M libraries/mbed/targets/hal/TARGET_NXP/TARGET_LPC23XX/can_api.chttps://github.com/Add CAN api filter support and LPC11CXX CAN implementation #91/files#diff-8(10)
• M libraries/mbed/targets/hal/TARGET_NXP/TARGET_LPC408X/can_api.chttps://github.com/Add CAN api filter support and LPC11CXX CAN implementation #91/files#diff-9(6)

Patch Links:

• https://github.com/mbedmicro/mbed/pull/91.patch
• https://github.com/mbedmicro/mbed/pull/91.diff

[bogdanm]

Could you please explain a bit the usage of "handle" in this context (both in read and filter functions) ? Do you think that this "handle" mechanism is generic enough to implement CAN message filtering on all platforms with a CAN transceiver?

[omdathetkan]

For the LPC11CXX the handle is the message object index (1-32). 32 is used for transmitting message and 1 is used by default as the accept-all mailbox, so by overriding it you disable acceptance of any message.
If there are no more mailboxes available the function will return 0.

Now that I think of it it might be better to make 31 the defailt object for accept-all, as messages are accepted and prioritized by the message boxes in order. This way you can make sure you don't loose the message you're interested in while still receiving any other message as well assuming you can read fast enough.

I think it should be relatively easy to implement the same scheme using the Acceptance Filter Mode on the LPC17XX. Everytime you call can->filter you add it to the identifier table, where handle returns the index in that table.

Here's a typical usage scenario:

int h1,h2;
can->reset(); // reset and clear all filters (accept all messages)
h1 = can->filter(0x100, 0x700, CANStandard); // Accept standard messages with id 0x100-0x1FF
h2 = can->filter(0x200, 0x7FF, CANStandard); // Accept standard message 0x200 as well
[...]
h2 = can->filter(0x300, 0x7FF, CANStandard, h2); // Accept standard message 0x300, overwrite 0x200

CANMessage msg = CANMessage();
int r = can.read(msg, h1); // Should only return messages with id 0x100-0x1FF
int r = can.read(msg, h2); // Should only return messages with id 0x300
int r = can.read(msg);     // Returns 0x100-0x1FF if pending, otherwise 0x300, otherwise any message

[bogdanm]

Thanks for the detailed comment. I'm not at all that familiar with CAN, so I'd like to think a bit more if this method is really universal enough. The problem is not really in the HAL, but can_api.h (below) also uses an "int handle" and that has to be good enough for all platforms/CAN transceivers.

[omdathetkan]

What do you mean by "can_api.h also uses an int handle"?

Here's someone who implemented filtering for the LPC1768:
http://mbed.org/users/ym1784/code/CAN_MONITOR/file/fe1f886dff76/main.cpp

Here cnt1 would be the handle. If I understand the datasheet correctly the can peripheral can also automatically move the received message from the buffer to RAM. Calling can->read can then return the requested message from RAM

[bogdanm]

I mean that the type of the handle in api/CAN.h (read and filter) is an int and I'm not sure if this is generic enough. Thanks for the link, I'll take a closer look at the LPC1768 implementation.

[emilmont]

Yes, we like the API change. It works very well with the common concept of CAN bus "mailboxes".

Having it defaulted to 0 makes it compatible with all the existing code.

Thanks for your contribution.