Bug in lpcopen_2_19_lpcxpresso_nxp_lpcxpresso_824, gpio_8xx.h

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Bug in lpcopen_2_19_lpcxpresso_nxp_lpcxpresso_824, gpio_8xx.h

694 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by zuzu on Thu Feb 18 17:16:14 MST 2016
static inline void Chip_GPIO_SetPortDIROutput(LPC_GPIO_T *pGPIO, uint8_t port, uint8_t pinMask)


should be

static inline void Chip_GPIO_SetPortDIROutput(LPC_GPIO_T *pGPIO, uint8_t port, uint32_t pinMask)


In fact all functions should be modified.

Regards,
Labels (1)
Tags (1)
5 Replies

532 Views
larsen
Contributor III

The problem with the width of the GPIO pinMask datatype in gpio8xx.h (as well as the UART_CFG_TXPOL  mistake) is not corrected in the latest version despite the promise given above to have it in april version.

Is this not the place to report such problems? If not, where is it then?

0 Kudos
Reply

532 Views
Carlos_Mendoza
NXP Employee
NXP Employee

Hi Henning,

Yes, this is the correct place to report such problems. I have talked with the LPCOpen developers about this bug and they mention that it is on the list of to do for LPCOpen but schedule is not finalized yet.

Hope it helps!

Best Regards,

Carlos Mendoza

Technical Support Engineer

0 Kudos
Reply

532 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by zuzu on Thu Feb 25 14:55:23 MST 2016
I'm using LPC824 and despite poor efficiency of M0 instruction set, peripherals are quite well done. The price is absolutely gorgeous
I've end up by taking your nice headers and build my own drivers

In uart_8xx.h instead of

#define UART_CFG_TXPOL          (0x01 << 22)    /*!< Transmit data polarity */


should be

#define UART_CFG_TXPOL          (0x01 << 23)    /*!< Transmit data polarity */


Also your UART DMA example is nice, but too complicated and inefficient for high performance embedded applications.
You could just use SRAMBASE descriptors as well, no need for extra in the first place.

And DMA interrupts are useless, consuming MCU time. You could instruct DMA engine to automatically take data from UART RX and fill a buffer in circular fashion.
Use XFERCFG count as "write pointer" for circular buffer

/**
 * Get XFER pointer to buffer
 */
static inline uint32_t Chip_DMA_GetXFERPtr(LPC_DMA_T *pDMA, DMA_CHID_T ch)
{

return (pDMA->DMACH[ch].XFERCFG >> 16) & 0x3FF;
}


and complete write pointer would be

#define uart0RxWp(UART0_RX_BUFF_SIZE - 1 - Chip_DMA_GetXFERPtr(LPC_DMA, DMAREQ_USART0_RX))


Now you'll have a zero intervention CPU while getting high speed data from UART (no interrupts at all).

PS.
Clear DMA errors (btw should never happen) in a background main() task, there is no need to have interrupt priority for that (DMA crashed anyhow)

Just a example

Regards,

Edouard Gora
Hardware/Software Engineer
Bigstep
http://bigstep.com/

532 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bob_walker on Sun Feb 21 13:41:40 MST 2016
Just found this as well. According to UM10800 reference manual, most of the GPIO pin register bits should be [28:0], with PWORD [31:0], and PBYTE[0:0].
Thanks for reporting this zuzu.
0 Kudos
Reply

532 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by NXP_Support on Fri Feb 19 09:05:00 MST 2016
Hi zuzu,

Thank you for reporting this!  We are scheduled for an LPC8xx LPCOpen update in April and will make sure these fixes are in place.
Best regards,
-NXP Support
0 Kudos
Reply