Missing LPCOpen support for LPC845 devices

[carstengroen]

Dear NXP,

it is such a shame that you decide to drop the LPCOpen support for new LPC84x devices :smileysad:  We have a new project where there is a LPC824 device (as a co-processor to a LPC1778) and during development (added features) we have outgrown the flash. A natural step is then to use the LPC845 (which is an impressing device to say the least!), but only to discover that there is no LPCOpen support for that one. This does not make any sense, the LPC845 is a "natural" improvement for the 82x series (pin compatible!), but you destroy the easiness of this by not continuing the support for LPCOpen when it would be natural in this case (the 845 is a drop-in replacement hardware wise, but not software wise because of your decision).

Very disappointing step in my view!

Are there any (at all) chance that you might add support for the 84x family in LPCOpen ??

[hassemuller]

I'm not happy as well! Looking for a way to migrate from 824 to 845 and having to maintain both versions for a while.... common guys, make an update of LPCOpen to support 845 as well.

[carstengroen]

Hasse,

the SAKE application above contains a "ok" version of LPCOpen for the 845, I fixed a few errors etc so it mimics the 824 version better. There a couple of modules that are not done, but 90% of it is complete.

I have packed my version for this in a zipfile, you can grab a copy if you like at Dropbox - lpc_chip.zip 

(I hope this is not violating NXP's policies in any way....)

[hassemuller]

Yes, I noticed the SAKE version but I ran into may compiler errors on GNU-C (for example dma_84x.c on the DMA_Table alignment) and the naming was also inconsistent with LPCOpen (for example SYSCON was SYSCTL in LPCOpen, and several more interface changes). I need to be able to support 824 as well for the time being and therefor interface compatibility is important (or I will drown in #ifdef's). Having a final solution from NXP would have been the best.

I'll check out your work in the dropboxfile, thanks for that.

Is I2C working in that version? Because that seems to be the major problem with the SAKE implementation (a file for master, slave, common and one without named purpose but the total seem to be incomplete/incompatible on a first try)

[carstengroen]

Hasse,

you are absolutely correct, I would also hope that NXP would have supported actively the 845 as it is a 100% logical choice to use that device as a "upgrade" path to existing 824 designs. Had I been aware of the shortcomings on the LPCOpen, we would never have chosen the 845 in the projects later on.

It is very very bad when vendors "changes horses", it leaves massive gaps for us developers :smileysad:

Sorry about the GCC, we use Keil so the path was a little easier. And yes, the I2C is not usable, I need especially the I2C slave at some point, have not had the time yet to port that also. If you at some point manages to do that, I would be grateful for input :smileywink:

[海鹏陈]

you can download at this web,GitHub - Magicoe/LPC845_SAKEE_TEST 

[carstengroen]

海鹏 陈,

that is wonderful news! I just had a quick look at the code, and it seems that at least some of the stuff is there (I2CS is missing which we currently use). Definitely a part of the way :smileyhappy:

[carstengroen]

I can confirm that the SAKEE code works (at least some of it). We use USARTS, SWM, IOCON and GPIO, these works fine. The original "SAKEE" LPCOpen code does not have support for GPIO port 1, I changed that so that also works.

Thanks for the heads-up on this!

[carstengroen]

For anyone else that uses the code, there is a bug in swm_84x.h at line 102 to line 105:

The original code:

     SWM_COMP0_0         = 0xB0,     /*!< PINASSIGN11 - COMP0 output */
     SWM_CLKOUT_O        = 0xB1,     /*!< PINASSIGN11 - CLKOUT Output */
     SWM_GPIO_INT_BMAT_O = 0xB3,     /*!< PINASSIGN11 - GPIO INT BMAT Output */
     SWM_U3_TXD_O        = 0xB4,     /*!< PINASSIGN11 - UART3 TXD Output */
‍‍‍‍

The corrected code:

     SWM_COMP0_0         = 0xB0,     /*!< PINASSIGN11 - COMP0 output */
     SWM_CLKOUT_O        = 0xB1,     /*!< PINASSIGN11 - CLKOUT Output */
     SWM_GPIO_INT_BMAT_O = 0xB2,     /*!< PINASSIGN11 - GPIO INT BMAT Output */
     SWM_U3_TXD_O        = 0xB3,     /*!< PINASSIGN11 - UART3 TXD Output */
‍‍‍‍

I was unable to assign SWM_U3_TXD_O because of the 0xB4, must be 0xB3.

[海鹏陈]

Thanks for the reminder.

I used 7 ADC channels on my project. Do you have an example of ADC DMA?

[carstengroen]

Sorry, I'm not using DMA for ADC

[soledad]

Like you mention, there is no LPCOpen nor SDK for LPC84x, however there is an example code bundles (register level) available for this family.

Sorry for any inconvenience that may cause and thank you for your feedback.

Have a great day,
Soledad

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[carstengroen]

Soledad,

I'm not sure I understand this. When I look at the "code bundle" for the LPC845, the only thing I can find are some (very) thin examples that punches some bits in some registers and no library whatsoever for the peripherals (just back to the way "support" was many years ago for processors. Is that correct or am I looking at the wrong place ??

I hope I'm wrong, I can't believe that NXP has dropped the LPCOpen support for this new nice chip and nothing to take its place ? Makes not much sense to make a device that is pin compatible with f.ex LPC824 (and a natural upgrade)  and then have no support for peripheral libraries for it

Tell me I'm wrong :smileyhappy:

[brendonslade]

Hi Carsten,

we've had some other feedback like yours on a desire for a more abstracted driver set for LPC8xx devices and are currently looking at the best way we can address this in a way that is most consistent with our overall tools offering. It will take a few months I'm afraid, but please stay tuned for updated in 2018.

regards,

Brendon

[carstengroen]

Brendon,

thanks for input on this, really appreciate it!

It seems like it would be a pity not to offer some kind of direct path for users of the 824 that wants to go with the 845.

Could a possible transition not be to update the LPCOpen for the 84x series, maybe at least make a update that would make the existing 82x LPCOpen run on 84x series and leave the new 84x features out from the LPCOpen (just make it so that the existing LPCOpen would be able to run on 84x), change APB adresses, fix #defines etc ?

That would open a temporary path for 82x users that needed to port existing code/applications to the new devices.

That must be possible for NXP using very limited resources (hours), and then work on a more permanent solution ?