topic Re: Post LPCOpen feedback here in LPC Microcontrollers

Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:11 GMT

Content originally posted in LPCWare by wellsk on Mon Feb 10 13:45:01 MST 2014
<h2>
This post is now read-only. Post any comments, suggestions, problems, improvements, etc. as a new post or comment in this forum.</h2>

This sticky topic is for temporary LPCOpen feedback - good things, bad things, issues, desired features, improvements, etc.

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:12 GMT

Content originally posted in LPCWare by LabRat on Mon Feb 10 16:25:23 MST 2014
[u]periph_can - Sample[/u]

Just a simple task: Get a LPC1768 Board with CAN1 running...

In board.c of lpc_board_nxp_lpcxpresso_1769 are a lot of inits, but no CAN_init()??

OK, default setting in can.c is CAN2...

#define LPC_CAN   (LPC_CAN2)

...but where is the pin setup???

Is it

Chip_CAN_Init(LPC_CAN, LPC_CANAF, LPC_CANAF_RAM);

in main? No PINSEL register?

In fact there's no pin setup. Astonishing enough, P0_4/5 are RD2/TD2 in main already.

That's magic. And confusing. I'm used to see default settings while entering main. So this new

'default pin muxing configuration' in board_sysinit.c is a confusing surprise.

Without CAN_init I've to setup CAN1 pins myself?

//set pins
if(LPC_CAN == LPC_CAN1)
{
 Chip_IOCON_PinMux(LPC_IOCON, 0, 0,IOCON_MODE_INACT, IOCON_FUNC1);
 Chip_IOCON_PinMux(LPC_IOCON, 0, 1,IOCON_MODE_INACT, IOCON_FUNC1);
}

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:12 GMT

Content originally posted in LPCWare by larryvc on Mon Feb 10 18:48:10 MST 2014
Duplicate post. Why can't I delete my own post?

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:13 GMT

Content originally posted in LPCWare by larryvc on Mon Feb 10 18:48:45 MST 2014

Quote: wellsk
This sticky topic is for temporary LPCOpen feedback - good things, bad things, issues, desired features, improvements, etc.

Temporary? Does that mean that there might be a forum dedicated to LPCOpen soon? That would be a good thing.

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:13 GMT

Content originally posted in LPCWare by LabRat on Tue Feb 11 00:02:27 MST 2014
[u]periph_can - Sample[/u]

I'm still surprised that Chip_CAN_SetBitRate() is setting an early sample point.

A later or flexible sample point setting could be useful.

Something like:

/* Set CAN Bit Rate */
Status Chip_CAN_SetBitRate(LPC_CAN_T *pCAN, uint32_t BitRate,uint32_t sample_point)
{
IP_CAN_BUS_TIMING_T BusTiming;
uint32_t result = 0;
uint8_t NT, TSEG1 = 0, TSEG2 = 0;
uint32_t CANPclk = 0;
uint32_t BRP = 0;
uint32_t sample =0;
uint32_t ret =0;
#if defined(CHIP_LPC175X_6X)
CANPclk = Chip_Clock_GetPeripheralClockRate(Chip_CAN_GetClkIndex(pCAN));
#else
CANPclk = Chip_Clock_GetPeripheralClockRate();
#endif
result = CANPclk / BitRate;

/* Calculate suitable nominal time value
 * NT (nominal time) = (TSEG1 + TSEG2 + 3)
 * NT <= 24
 * TSEG1 >= 2*TSEG2
 */
for (NT = 24; NT > 0; NT = NT - 2) {
if ((result % NT) == 0) {
BRP = result / NT - 1;
TSEG2 = (NT-3) / 2;
TSEG1 = (NT-3) - TSEG2;
while(TSEG2 > 0)//while TSEG2
{
//calc sample point
 sample = (TSEG1+2) *100/(NT);
 if(sample >= sample_point)//sample point reached
 {
   ret = 1;  //success
    break;
  }//no sample point reached
  else
  {
   TSEG2--;//dec seg2
   TSEG1++;//inc seg1
  }//end sample point reached
 }//end while TSEG2
 NT--;

//TSEG2 = (NT / 3) - 1;
//
//TSEG1 = NT - (NT / 3) - 1;

break;
}
}
if (NT == 0) {
return ERROR;
}
//return ERRROR for missed sample point
    if(ret == 0 ) return ERROR;

BusTiming.TESG1 = TSEG1;
BusTiming.TESG2 = TSEG2;
BusTiming.BRP = BRP;
BusTiming.SJW = TSEG1 > 3 ? 3 : TSEG1;
BusTiming.SAM = 0;
setBusTiming(pCAN, &BusTiming);

return SUCCESS;
}

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:14 GMT

Content originally posted in LPCWare by LabRat on Tue Feb 11 08:11:12 MST 2014
I'm missing USB in lpcopen_2_07_lpcxpresso_nxp_lpcxpresso_1769.

nxpUSBlib (http://www.lpcware.com/content/project/nxpusblib) is announcing it...

Quote:
[color=#f00]The nxpUSBlib software package is now obsoleted by the new LPCOpen Platform[/color]...

Am I missing something here?

BTW: http://www.lpcware.com/content/nxpfile/lpcopen-platform still shows:

Quote:
LPCOpen v2.xx for LPC17xx family devices (not yet available, use v1.xx releases)
LPCOpen v2.xx for LPC40xx family devices (not yet available, use v1.xx releases)

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:15 GMT

Content originally posted in LPCWare by wellsk on Tue Feb 11 11:12:16 MST 2014
The USBDLIB and USBDROM examples didn't make it into this release. They are planned for an upcoming release along with some additional examples, improvements, and fixes for known issues. (See http://www.lpcware.com/content/project/lpcopen-software-development-platform-nxp-lpc-microcontrollers/lpcopen-lpc17xx)

So when is the date for the upcoming release? It could be as little as 2 weeks and as long as 6. :(
However - if we can - we'll try to provide some early code for usbd_lib/usbd_rom prior to that release.

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:15 GMT

Content originally posted in LPCWare by wellsk on Tue Feb 11 11:15:24 MST 2014

Quote:
Does that mean that there might be a forum dedicated to LPCOpen soon? That would be a good thing

Yes, it means there might be :). It would be a good thing.

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:16 GMT

Content originally posted in LPCWare by wellsk on Tue Feb 11 19:30:58 MST 2014
Yes - pin muxing is somewhat of a mixed approach right now. Some examples assume the pins are correctly setup as part of the board SystemInit() code. And other examples don't make that assumption and setup pin muxing locally in the example code itself. Some older examples call board setup functions (Board_Uart_Init(), Board_ADC_Init()), etc.

The plan is to get this cleaned up and rely on the board layer code to setup pin muxing as part of board SystemInit() and get comments in the example code that pin muxing is setup in the board layer - maybe with a single example for setting up a possible pin configuration for the example. For examples where we need to specifically override a muxed pin, it will be done in the example.

Well, that's the plan at least. Putting all the required pin muxing in an example for all boards will get messy quick (the same example can be used on a number of supported boards).

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:16 GMT

Content originally posted in LPCWare by LabRat on Wed Feb 12 03:55:12 MST 2014

Quote: wellsk
The plan is to get this cleaned up and rely on the board layer code to setup pin muxing as part of board...

That's what I fear. I know it's an usual approach today to use a board layer, but that's causing problems. Especially if pin muxing is done there. This approach is more usable for single device board layers. Since we use a lot of different boards with different peripheral locations this would result in a confusing bunch of board files. So I use board layers in a more general way for several boards ('board layer family') and let the project do the setup. Using CAN is a good example. I've created a new board layer for our LPC176x CAN boards and deleted CAN pin muxing there. Adding a flexible Board_CAN_Init now allows me to use this board layer for several boards and projects. 'Board_CAN_Init(LPC_CAN1,0)' in main is showing me clearly which CAN and CAN location is used. That's avoiding a lot problems. Also migrating to another board of this board layer family is easy and fast. Therefore I prefer the old fashioned approach to do pin setups in Init functions and leave the general pin setup as default as possible...

Re: Post LPCOpen feedback here

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

Content originally posted in LPCWare by j.loh on Wed Feb 12 05:22:27 MST 2014
In the 2.07 release for LPC17xx this bug still exists:

http://www.lpcware.com/content/bugtrackerissue/lpcgpio3base-address

\lpcopen\software\lpc_core\lpc_chip\chip_17xx_40xx\chip_lpc175x_6x.h, line 60:

#define LPC_GPIO3_BASE 0x20098060

Shoud be:

#define LPC_GPIO3_BASE 0x2009C060

Regards,
Jürgen

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:18 GMT

Content originally posted in LPCWare by wellsk on Wed Feb 12 10:10:19 MST 2014
Thanks - we have updated this for the next release.

For the v2 LPCopen release, the GPIO APIs have changed and you should only need to use the LPC_GPIO definition without neededing to know the individual GPIO group bases.

LPC_GPIO[1].DIR |= 1UL << 2; /* Set p1.2 as an output */
LPC_GPIO[1].SET = (1 << 2); /* Set p1.2 pin output high */

/* Get p0.8 pin state */
bool pinState = (bool) ((LPC_GPIO[0].PIN >> 8) & 1);

/* Get all pin states on port 0 */
uint32_t portState = LPC_GPIO[0].PIN;

It would be better to use the GPIO API provided for these instead. These are inlined and normally use no extra memory over the statements above.
This API is the same - or very similar - for all device families (regardless of type of GPIO block used).

Using the API for the same code above is like this:

Chip_GPIO_SetPinDIROutput(LPC_GPIO, 1, 2);
Chip_GPIO_SetPinOutHigh(LPC_GPIO, 1, 2);
bool PinState = Chip_GPIO_GetPinState(LPC_GPIO, 0, 8);

/* Get all pin states on port 0 */
uint32_t portState = Chip_GPIO_GetPortValue(LPC_GPIO, 0);

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:19 GMT

Content originally posted in LPCWare by wellsk on Wed Feb 12 10:13:41 MST 2014
Thanks for your feedback on this. I'd like to see more opinions from other developers using LPCOpen on whether the current approach is usable.

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:20 GMT

Content originally posted in LPCWare by rocketdawg on Wed Feb 12 11:21:56 MST 2014

Quote: wellsk

Chip_GPIO_SetPinDIROutput(LPC_GPIO, 1, 2);
Chip_GPIO_SetPinOutHigh(LPC_GPIO, 1, 2);
bool PinState = Chip_GPIO_GetPinState(LPC_GPIO, 0, 8);

/* Get all pin states on port 0 */
uint32_t portState = Chip_GPIO_GetPortValue(LPC_GPIO, 0);

What I do not like is the magic numbers
what is 1, what is 2

typedef enum {
PORT_1, ...
} PortNumbers_t;

prototype
Chip_GPIO_SetPinDIROutput(..., PortNumbers_t port, ....

Chip_GPIO_SetPinDIROutput(LPC_GPIO, PORT_1, PIN_2);
if these were typedef enums, then one could never call
int pin = 200;
Chip_GPIO_SetPinDIROutput(LPC_GPIO, 100, pin);
because the compiler would complain about argument types

sorry, I have been reading "clean code"

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:20 GMT

Content originally posted in LPCWare by j.loh on Thu Feb 13 06:51:43 MST 2014
Hello Kevin,

you're right, I already changed most of my code not to use LPC_GPIO3 directly, but to use the API. I was puzzled because the bug was reported in the bug tracker some time ago but did not considered in the current release.

In general, LPCopen is a good approach, because it hides most of the chip internals, better than CMSIS does. E.g. I'm just developing for a LPC1768 but later the project has to be ported to a LPC43xx. Hopefully LPCopen will speed up this task.

Another suggestion for the GPIO API: It should be possible to set mode and function of a GPIO pin independently with the API. Currently they're bound together:

void Chip_IOCON_PinMux(LPC_IOCON_T *pIOCON, uint8_t port, uint8_t pin, uint32_t mode, uint8_t func);

In most cases I want to change the pin's function and not it's mode. Since it's even not possible to read mode and/or function, this can't be done with the API.

Regards,
Jürgen

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:21 GMT

Content originally posted in LPCWare by djlegge on Thu Feb 13 10:40:17 MST 2014
Some more feedback. I built the lwip_tcpecho_freertos demo with just one small problem - The file lwip_tcpecho_freertos.c has some #includes with windows slashes in the path name (eg. arch\lpc_arch.h instead of arch/lpc_arch.h) and doesn't build on Linux. It took me an embarrassingly long time to workout that was why the compiler could not see the header files when the paths looked correct.

One other thing. Our board is basically similar to the LPCXpresso LPC1769 board but has an LPC1768 instead. With this example it appears to be running at 120MHz which it shouldn't. I would imagine the best place to set the CPU clock would be in board.c, at the board level but this seems to be done at the chip level in lpc_chip_175x_6x, as far as I can tell. What would be the recommended way to do this ?
I tried changing const uint32_t OscRateIn = 10000000 in board.c but that only changed the speed it thought it was running at so the uart board rates were wrong...

Thanks.

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:22 GMT

Content originally posted in LPCWare by wellsk on Thu Feb 13 11:32:52 MST 2014

Quote:
Some more feedback. I built the lwip_tcpecho_freertos demo with just one small problem - The file lwip_tcpecho_freertos.c has some #includes with windows slashes in the path name (eg. arch\lpc_arch.h instead of arch/lpc_arch.h) and doesn't build on Linux. It took me an embarrassingly long time to workout that was why the compiler could not see the header files when the paths looked correct.

These incorrect slashes appear to be our nemesis. We will fix for the next release.

Quote:
One other thing. Our board is basically similar to the LPCXpresso LPC1769 board but has an LPC1768 instead. With this example it appears to be running at 120MHz which it shouldn't. I would imagine the best place to set the CPU clock would be in board.c, at the board level but this seems to be done at the chip level in lpc_chip_175x_6x, as far as I can tell. What would be the recommended way to do this ?

The clock setup is part of the chip layer now and make an assumption about oscillator rate. See the API below.
Override this by copying the necessary code (Chip_SetupXtalClocking()) from sysinit_17xx_40xx.c into board.c and then altering the Board_SystemInit() to use your board.c version instead. Edit the board.c version of Chip_SetupXtalClocking() to match your hardware. It sounds like the 120MHz might be an oversight on our part and the other parts need to be setup at 100MHz. Thanks for letting us know about this, we will look for a fix for this.

/**
 * @briefClock and PLL initialization based on the external oscillator
 * @returnNone
 * @noteThis function assumes an external crystal oscillator
 * frequency of 12MHz.
 */
void Chip_SetupXtalClocking(void);

Quote:
I tried changing const uint32_t OscRateIn = 10000000 in board.c but that only changed the speed it thought it was running at so the uart board rates were wrong...

This should be your board's oscillator rate. Are you using a 10MHz oscillator?
Be sure to adjust your PLL settings to generate the rate you need. The clock driver uses the PLL settings and the oscillator rate to get the main clock rate used for system. Peripherals (depending on chip and adjusted by dividers) usually use this as base clock for peripheral clock functions too.

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:22 GMT

Content originally posted in LPCWare by djlegge on Fri Feb 14 02:23:39 MST 2014
Thanks for your help Kevin. As for OscRateIn, no I am using 12MHZ I just thought I saw an extra zero in there and got confused about what it meant.
Darren.

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:23 GMT

Content originally posted in LPCWare by gloverde on Fri Feb 14 14:39:18 MST 2014
I'm assuming the V2.06 releases listed on the "LPCOpen Software Development Platform (LPC11xx packages)" page are specific to 11u68,
but this is sort of non obvious considering the title of the page mentions LPC11xx

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

I'm still bathing in all the information on these chips and ARM in general so i'm finding this rather confusing.
The table for "Older versions of LPCOpen 1.xx software package downloads" lists supported microcontrollers, very straightforward.
The talbe for "Latest available LPCOpen 2.xx software package downloads" lists supported boards.

I don't have a development board though.

The single greatest resource I wish i had found 2 days ago was this:
http://www.lpcware.com/content/faq/what-include-paths-library-paths-and-sources-files-do-i-need-lpcopen-project

Re: Post LPCOpen feedback here

lpcware — Wed, 15 Jun 2016 20:22:24 GMT

Content originally posted in LPCWare by schisanoa on Sat Feb 15 14:47:10 MST 2014
I'm using LPCOpen 2.07 for LPC4088 part, while testing code, I found a problem on the Board.c file in this function: Board_LED_Set(uint8_t LEDNumber, bool On)

void Board_LED_Set(uint8_t LEDNumber, bool On)
{
if (LEDNumber == 0) {
Chip_GPIO_WritePortBit(LPC_GPIO, 2, ledBits[LEDNumber], (bool) !On);
}
}

with this if statement we can only drive LED 3 on the OEM board, but there might be useful drive also the other LED. For me it is no more a problem I will drive the led in other way