Post LPCOpen feedback here

lpcware · ‎06-15-2016

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.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wellsk on Wed Feb 26 11:18:00 MST 2014

Quote:
Could I suggest a separate forum for general LPCOpen questions, away from microprocessor-specific questions?

Yes, one will go up later today. Once live, this thread will go read-only.

Quote:
. If we could sneak in things like the FatFS fix into the 03/03 release that would be superb as we are delivering a big software port from a Stellaris chip to the LPC4357 for the end of March!

Someone will take a look at this for the next release. This might affect 17xx/40xx too if it's an 8.3/LFN problem.

Quote:
Do you know if the Internet Radio demo will be updated to match the LPCOpen 2.04 distribution?

Sorry, I don't know on this one. I'm not up to date on this demo, is the current package working that uses the legacy v1.03 release?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by rgledhill on Wed Feb 26 01:50:29 MST 2014
Hi Kevin,

Many thanks, that's extremely helpful. Could I suggest a separate forum for general LPCOpen questions, away from microprocessor-specific questions?

I'll link across from my other posting (see LPC43xx forum) as there are a few items in here. If we could sneak in things like the FatFS fix into the 03/03 release that would be superb as we are delivering a big software port from a Stellaris chip to the LPC4357 for the end of March!

Do you know if the Internet Radio demo will be updated to match the LPCOpen 2.04 distribution?

Kind regards
Richard

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Tue Feb 25 22:25:00 MST 2014

Quote: LabRat

LPCXpresso isn't including samples for LPC15xx at all...

As detailed in the LPCXpresso 7 User Guide (provided in the built in help and in PDF format in your install directory), LPCOpen is now the recommended route in most cases for example/peripheral driver libraries. Thus LPCOpen is the actually the only samples for the new LPC1500 family.

As the releases of the LPXpresso IDE and LPCOpen will not always be synchronised, we have included various links within the LPCXpresso IDE to the latest LPCOpen bundles so that users will always have access to the latest versions (rather than including a specific version within the LPCXpresso install itself).

We will also continue to improve the LPCOpen related functionality in future releases of LPCXpresso IDE, complementing and extending the existing new project wizards, import wizards, etc.

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by LabRat on Tue Feb 25 17:32:51 MST 2014
I'm missing a CAN sample in LPCOpen 2.08 LPC15xx?

LPCXpresso isn't including samples for LPC15xx at all...

So are there any CAN samples available?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wellsk on Tue Feb 25 11:43:54 MST 2014
Some updates on various LPCOpen hot topics...

LPC18xx/43xx
We are putting together some updated 18xx/43xx packages that should be released the week of 03/03 (fingers crossed). This should have various fixes and updates to board bringup that affects LWIP, DRAM, and some other board specific functions.

LPC17xx/40xx
USBDLIB libraries are working for the LPC175x/6x, LPC177x/8x, and LPC40xx device families. We are looking at releasing an update for this that adds this capability and fixes some other small issues. I don't have a date on this yet. Sorry, no USB host yet.

New FAQ: Board porting guide
Online at http://www.lpcware.com/content/faq/how-do-i-port-lpcopen-new-baord

New FAQ: LPCOpen and system startup
Online at http://www.lpcware.com/content/faq/how-do-lpcopen-applications-handle-system-startup

New FAQ: LPCOpen development guidelines
Online at http://www.lpcware.com/content/faq/what-best-way-top-develop-lpcopen-avoid-change-impact-lpcopen-ver...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wellsk on Mon Feb 24 13:16:05 MST 2014
Hi Richard,

It's for anything LPCOpen related - all tool chains and all boards.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by rgledhill on Mon Feb 24 10:40:06 MST 2014
Hi Kevin,
Is this for general LPCOpen feedback? Or is it restricted to Xpresso systems?
Thanks
Richard

lpcware · ‎06-15-2016

Content originally posted in LPCWare by schisanoa on Sat Feb 15 14:47:46 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

lpcware · ‎06-15-2016

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

lpcware · ‎06-15-2016

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-lpco...

lpcware · ‎06-15-2016

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.

lpcware · ‎06-15-2016

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.

lpcware · ‎06-15-2016

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.

lpcware · ‎06-15-2016

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

lpcware · ‎06-15-2016

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"

lpcware · ‎06-15-2016

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.

lpcware · ‎06-15-2016

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);

lpcware · ‎06-15-2016

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

lpcware · ‎06-15-2016

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...

lpcware · ‎06-15-2016

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).