LPC MicrocontrollersのトピックLPC1549 and CAN

LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:09 GMT

Content originally posted in LPCWare by TravisT on Wed Apr 16 10:53:20 MST 2014
Hello,

I am really interested in the LPC1549 because of the switch matrix and its many peripherals. One down side is it is still so new, and finding libraries for some of its features has proven to be hard.

My main concern really is the CAN library. It appears that both MBED and LPCopen do not have libraries for CAN. The ROM API is my next step but I am not that strong at lower level programming so I am not sure how fast I will be able to move forward with just the ROM API.

Does anybody know more about the status of a CAN library or could provide help with using the device with ROM or CMSIS to communicate (ideally J1939 compliant)

Thanks

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:10 GMT

Content originally posted in LPCWare by TravisT on Wed Apr 16 13:38:11 MST 2014
Thanks for the quick reply. I reviewed the other thread and it at least offers more than I have found anywhere else.

It does seem like a pretty important thing, so I am a little surprised that neither group has developed anything, especially since it should have a similar implementation as past processors. Unfortunately I am still a little new to the ARM world and lower level programming.

I was wondering if you got any further than the sample code you posted that you could share.

Anyways I hope that this gets resolved soon.

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:11 GMT

Content originally posted in LPCWare by R2D2 on Wed Apr 16 15:00:41 MST 2014

Quote: TravisT
It does seem like a pretty important thing...

Obviously not for NXP. I'm sure there are samples already, at least something easy to test. After this weeks of silence we decided not to migrate to LPC15 and not to start new projects with LPC15. So I don't do their job and write CAN and CAN-ROM samples. (And then all over sudden official samples are released). After a lot of years experience with NXP M0-3 we've seen a lot surprises and I've learned to be more pragmatic: there are other manufacturer out there...

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:11 GMT

Content originally posted in LPCWare by starblue on Thu Apr 17 00:48:44 MST 2014
Since it is a C_CAN you could try to adapt examples for LPC11Cxx or LPC43xx, which use the same peripheral. Note though that they don't have ROM routines for CAN.

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:12 GMT

Content originally posted in LPCWare by nxpsupport on Thu Apr 17 08:37:00 MST 2014
Hello Gentlemen,

Our sincere apologies for not getting a CAN example released in conjunction with the LPC15xx MCU release. Too many priorities, but we will endeavor to provide complete example packages on initial releases in the future.

We will post CAN examples for the LPC15xx in May.

Again, we apologize for the delay.
-NXP Support

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:12 GMT

Content originally posted in LPCWare by TravisT on Wed May 07 01:05:51 MST 2014
Hello,

I was wondering if there are any updates to this issue. This processor is a lot less useful without a supported CAN library.

Thanks

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:13 GMT

Content originally posted in LPCWare by Tiggr on Thu May 22 03:54:09 MST 2014
Do we have a release date yet for the promised 15xx CAN Example? Am new to this chip set and I am looking for some help on implementing the CANopen functions

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:14 GMT

Content originally posted in LPCWare by R2D2 on Thu May 22 03:57:20 MST 2014

Quote: Tiggr
Do we have a release date yet for the promised 15xx CAN Example? Am new to this chip set and I am looking for some help on implementing the CANopen functions

Quote: nxpsupport
Hello Gentlemen,

Our sincere apologies for not getting a CAN example released in conjunction with the LPC15xx MCU release. Too many priorities, but we will endeavor to provide complete example packages on initial releases in the future.

We will post CAN examples for the LPC15xx in[color=#f00] May[/color].

Again, we apologize for the delay.
-NXP Support

Not sure if that's May 2014 or 2015 :)

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:14 GMT

Content originally posted in LPCWare by Tiggr on Thu May 22 04:03:08 MST 2014

Quote: R2D2

Quote: Tiggr
Do we have a release date yet for the promised 15xx CAN Example? Am new to this chip set and I am looking for some help on implementing the CANopen functions

Not sure if that's May 2014 or 2015 :)

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:15 GMT

Content originally posted in LPCWare by R2D2 on Thu May 22 04:11:13 MST 2014
Not sure if you are using LPC11Cxx. But LPCOpen for LPCXpresso LPC11C24:

http://www.lpcware.com/content/nxpfile/lpcopen-software-development-platform-lpc11xx-packages-0

should look very similar and could help to understand the basic things (and keep us busy at least :) ).

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:17 GMT

Content originally posted in LPCWare by R2D2 on Sun Jun 01 03:11:39 MST 2014
96 days after official 'release of the LPC1500 microcontroller series',

45 days after last sign of life ("We will post CAN examples for the LPC15xx in May.") there's still no CAN sample :(

Not sure if that's not embarrassing enough and if there's a daily reminder required?

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:18 GMT

Content originally posted in LPCWare by NXP_Support on Mon Jun 02 08:42:00 MST 2014
Hi R2D2 and others,

Yes, it is more than embarrassing enough. Our struggle for resources vs priorities has thrown a wrench into SW development schedules. A simple LPC15xx CAN example is being worked on and I hope to post a first cut to this forum 'soon'. I wish I could provide a more definitive answer, but resource and priority conflicts have made such forecasts hollow. Your posts have kept this issue alive, and though progress has been slow it is being addressed. We very much appreciate our forum members and apologize for these repeated delays.

-NXP Support

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:19 GMT

Content originally posted in LPCWare by LabRat on Wed Jun 04 03:26:24 MST 2014
99 days, leaving the two-digit range soon...

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:22 GMT

Content originally posted in LPCWare by R2D2 on Thu Jun 05 14:56:54 MST 2014
And at the end of the day, it's day 100...

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:22 GMT

Content originally posted in LPCWare by NXP_Support on Thu Jun 05 16:04:00 MST 2014
Here is a very basic routine for straight CAN output.

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:23 GMT

Content originally posted in LPCWare by R2D2 on Thu Jun 05 19:25:48 MST 2014
Notes:

This is a LQFP64 sample, LQFP48 requires different pin settings:

#ifdef LQFP48
//CAN signal muxing LQFP48
 Chip_IOCON_PinMuxSet(LPC_IOCON, 0, 18, (IOCON_MODE_INACT | IOCON_DIGMODE_EN));
 Chip_IOCON_PinMuxSet(LPC_IOCON, 0, 13, (IOCON_MODE_INACT | IOCON_DIGMODE_EN));
 Chip_SWM_MovablePortPinAssign(SWM_CAN_TD1_O , 0, 18);
 Chip_SWM_MovablePortPinAssign(SWM_CAN_RD1_I,  0, 13);
#endif
#ifdef LQFP64
 /* Assign the pins rx 0[11] and tx 0[31] @ LQFP64 */
 Chip_IOCON_PinMuxSet(LPC_IOCON, 0, 11, (IOCON_MODE_INACT | IOCON_DIGMODE_EN));
 Chip_IOCON_PinMuxSet(LPC_IOCON, 0, 31, (IOCON_MODE_INACT | IOCON_DIGMODE_EN));
 Chip_SWM_MovablePinAssign(SWM_CAN_RD1_I, 11);/* Rx P0.11 */
 Chip_SWM_MovablePinAssign(SWM_CAN_TD1_O, 31);/* Tx P0.31 */
#endif

Since project wizard is generating wrong interrupt names it's required to change startup files as described in:

http://www.lpcware.com/content/forum/updated-lpc15xx-startup-files-lpcopen-compatibility

or just change

void CAN_IRQHandler(void)

void CAN[color=#f00]0[/color]_IRQHandler(void)

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:24 GMT

Content originally posted in LPCWare by NXP_Support on Fri Jun 06 16:45:00 MST 2014
Very good explanation - Thank you R2D2!

Attached is basically the same simple example, but has the set up for using CANOpen ROM functions. All R2D2's comments apply to this brief example as well. The examples are for the LPC15xx LPCXpresso Board.

The next LPC15xx LPCOpen release will support the interrupt names and include the simple CAN/CANOpen examples.

Best regards,
-NXP_Support

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:24 GMT

Content originally posted in LPCWare by R2D2 on Sun Jun 08 05:41:02 MST 2014
A few notes:
[h3]Note #1:[/h3]I'm not sure why this sample is using 12MHz main clock...

/* Use main oscilator for rates above 100Kh */
Chip_Clock_SetMainClockSource(SYSCTL_MAINCLKSRCA_SYSOSC);

I would prefer to use default 72MHz and use

clkdiv = 5;

to get 12Mhz base clock again...

Or just calculate clkdiv from board settings:

//adjust clkdiv to 12 MHz
 gCANConfig.clkdiv = (SystemCoreClock / 12E6) -1;

[h3]Note #2:[/h3]Not sure if you plan to add baudrate calculation, but anyway, a few btr settings could be helpful for beginners...

// gCANConfig.btr = 0x1800;/* 1MHz   bit rate  (%83.3 w 12Mhz base clock ) */
 gCANConfig.btr = 0x0502;/* 500KHz bit rate  (%87.5 w 12Mhz base clock ) */
// gCANConfig.btr = 0x0505;/* 250KHz bit rate  (%87.5 w 12Mhz base clock ) */
// gCANConfig.btr = 0x050B;/* 125KHz bit rate  (%87.5 w 12Mhz base clock ) */
// gCANConfig.btr = 0x050E;/* 100KHz bit rate  (%87.5 w 12Mhz base clock ) */

[h3]Note #3:[/h3]Could be useful to define a node ID...

#define NODE_ID 0x20//own node id
...
/* CANopen configuration structure */
static const CAN_CANOPENCFG myCANopen =
{
 NODE_ID,// node_id
...

/* Send a CAN message fom this node */
 msg_obj.msgobj  = 0;
 msg_obj.mode_id = 0x700 + NODE_ID;
....

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:25 GMT

Content originally posted in LPCWare by R2D2 on Sun Jun 08 06:10:27 MST 2014
[h3]Note #4:[/h3]Without overwrite protection mechanism, transmitting message objects can result in unexpected behavior.

Transmitting 2 messages isn't working as expected. Sample:

#define NODE_ID 0x20//own node id

//message #1
msg_obj.msgobj  = 0;
[color=#f00]msg_obj.mode_id = 0x700+ NODE_ID[/color];
msg_obj.mask    = 0x0;
[color=#f00]msg_obj.dlc     = 0x4;[/color]
msg_obj.data[0] = 0x11;
msg_obj.data[1] = 0x11;
msg_obj.data[2] = 0x11;
[color=#f00]msg_obj.data[3] = 0x11;[/color]
LPC_CAND_API->hwCAN_MsgTransmit(pCanHandle, &msg_obj);

//message #2
msg_obj.msgobj  = 0;
msg_obj.mode_id = 0x700 + NODE_ID+1;
msg_obj.mask    = 0x0;
msg_obj.dlc     = 3;
[color=#30f]msg_obj.data[0] = 0x22;
msg_obj.data[1] = 0x22;
msg_obj.data[2] = 0x22;[/color]
LPC_CAND_API->hwCAN_MsgTransmit(pCanHandle, &msg_obj);

C_CAN is transmitting a single message:

Quote:
[color=#f00]720 04 [/color][color=#30f]22 22 22 [/color][color=#f00]11[/color]

a mixture of message #1 and #2

Of course that's the result of overwriting Message Object #0 while it is transmitted.

To avoid this it's useful to add a simple state control and wait until last message is transmitted.

Something like:

//wait 5ms before CAN_Fail
#define CAN_TX_TIME 5 

//CAN State
enum CAN_STATE
{
 CAN_Success,
 CAN_TX,
 CAN_Fail
};

//CAN
typedef struct _CAN_STATE
{
 volatile uint16_t timeout; //tx timeout
 volatile uint8_t  state;//CAN state
}CAN_STATE_t;
CAN_STATE_t can_state;

...
static void CAN_tx(uint8_t msg_obj)
{
 Board_LED_Toggle(1);//show TX
 can_state.state = CAN_Success;//success, ready to transmit next message
}
...
//CAN timer, call every ms in SysTick...
__attribute__((always_inline)) __INLINE void CAN_1ms_timer(void)
{
 //timer to control tx
 if(can_state.state == CAN_TX)
 {
  //timeout to fail
  if(can_state.timeout)
  {
   can_state.timeout--;
   if(can_state.timeout==0) can_state.state = CAN_Fail;
  }
 }
}

//transmit message #1
   while(!((can_state.state == CAN_Success) || (can_state.state == CAN_Fail))){}; //wait
    can_state.timeout = CAN_TX_TIME;//can timeout
    can_state.state = CAN_TX; //set tx busy flag
    msg_obj.msgobj  = 0;
    msg_obj.mode_id = 0x700+ NODE_ID;
    msg_obj.mask    = 0x0;
    msg_obj.dlc     = 0x4;
    msg_obj.data[0] = 0x11;
    msg_obj.data[1] = 0x11;
    msg_obj.data[2] = 0x11;
    msg_obj.data[3] = 0x11;
    LPC_CAND_API->hwCAN_MsgTransmit(pCanHandle, &msg_obj);

//transmit message #2
   while(!((can_state.state == CAN_Success) || (can_state.state == CAN_Fail))){}; //wait
    can_state.timeout = CAN_TX_TIME; //can timeout
    can_state.state = CAN_TX; //set tx busy flag
    msg_obj.msgobj  = 0;
    msg_obj.mode_id = 0x700 + NODE_ID+1;
    msg_obj.mask    = 0x0;
    msg_obj.dlc     = 3;
    msg_obj.data[0] = 0x22;
    msg_obj.data[1] = 0x22;
    msg_obj.data[2] = 0x22;
    LPC_CAND_API->hwCAN_MsgTransmit(pCanHandle, &msg_obj);

Of course another possible solution would be to use 2 Message Objects...

Re: LPC1549 and CAN

lpcware — Wed, 15 Jun 2016 17:07:26 GMT

Content originally posted in LPCWare by R2D2 on Sun Jun 08 08:00:15 MST 2014
[h3]Note #5:[/h3]Another option to control transmissions would be reading CAN transmission request registers (TXREQ1-2)

Sample:

//transmit message #1
[color=#f00]    while(LPC_CAN->TXREQ1 & (1<<0)){}//read pending transmission request of object 0[/color]
    msg_obj.msgobj  = 0;
    msg_obj.mode_id = 0x700+ NODE_ID;
    msg_obj.mask    = 0x0;
    msg_obj.dlc     = 0x4;
    msg_obj.data[0] = 0x11;
    msg_obj.data[1] = 0x11;
    msg_obj.data[2] = 0x11;
    msg_obj.data[3] = 0x11;
    LPC_CAND_API->hwCAN_MsgTransmit(pCanHandle, &msg_obj);

//transmit message #2
[color=#f00]    while(LPC_CAN->TXREQ1 & (1<<0)){}//read pending transmission request of object 0[/color]
    msg_obj.msgobj  = 0;
    msg_obj.mode_id = 0x700 + NODE_ID+1;
    msg_obj.mask    = 0x0;
    msg_obj.dlc     = 3;
    msg_obj.data[0] = 0x22;
    msg_obj.data[1] = 0x22;
    msg_obj.data[2] = 0x22;
    LPC_CAND_API->hwCAN_MsgTransmit(pCanHandle, &msg_obj);

Unfortunately there's no CAN struct defined in LPCOpen (LPC15xx) :~ Probably because it's also forgotten in LPCOpen (LPC11C24), as mentioned already here:

http://www.lpcware.com/content/forum/forgotten-can-register-struct-lpcxpresso-lpc11c24-lpcopen-v200a