LPC Microcontrollers Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

LPC Microcontrollers Knowledge Base

Discussions

Sort by:
Overview          Ping-pong is a special case of a linked transfer which typically used more frequently than more complicated versions of linked transfers. A ping-pong transfer usually uses at least two buffers. At any one time, one buffer is being loaded or unloaded by DMA operations. The other buffers have the opposite operation being handled by software, readying the buffer for use when the buffer currently being used by the DMA controller is full or empty. The Fig 1 illustrates an example of descriptors for ping-pong from a peripheral to two buffers in memory. Fig 1 Implementation detail         To continuous transfer the converted result of the ADC to RAM, I’m going to use four 4 DMA descriptors to work in Ping-Pong mode to achieve this goal as the Fig 2 shows. Fig 2 Data flow via Ping-Pong mode Hardware introduction         LPCXpressor54114 Board ( OM13089 ) Fig 3 LPCXpressor54114 Board        Demo code: LPCOpen Library Example code        The code is based on the periph_adc demo, using the SCTimer output as the hardware trigger of ADC, meanwhile, the ADC converted value is transferred to the appointed area of RAM automatically. #include "board.h" #define SCT_PWM            LPC_SCT #define NUM_BUFFERS 4 #define DMA_TRANSFER_SIZE 8 #define ADC_INPUT_CHANNEL 1 #define SCT_PWM_RATE   10000          /* PWM frequency 10 KHz */ #define SCT_PWM_PIN_OUT    7          /* COUT7 Generate square wave */ #define SCT_PWM_OUT        1          /* Index of OUT PWM */ uint16_t adcOut ; ALIGN ( 512 ) DMA_CHDESC_T ADC_TransferDescriptors [ NUM_BUFFERS ] ; uint16_t CapturedData [ 32 ] ; uint16_t DMA_Sum = 0 ; /** * * ADC IRQ not Used right now... Only for testing */ void ADC_SEQA_IRQHandler ( void ) {             /* If SeqA flags is set i.e. data in global register is valid then read it */         Chip_GPIO_SetPinState ( LPC_GPIO , 0 , 6 , true ) ;         //DEBUGOUT("ADC Output = %d\r\n", adcOut);         Chip_GPIO_SetPinState ( LPC_GPIO , 0 , 6 , false ) ;         Chip_ADC_ClearFlags ( LPC_ADC , 0xFFFFFFFF ) ; } void DMA_IRQHandler ( void ) {         static uint16_t DMA_Sum = 0 ;                 DMA_Sum ++ ;                  if ( DMA_Sum == 8 )          {            DMA_Sum = 4 ;          }             Chip_GPIO_SetPinState ( LPC_GPIO , 0 , 7 , true ) ;      /* Rrror interrupt on channel 0? */      if ( ( Chip_DMA_GetIntStatus ( LPC_DMA ) & DMA_INTSTAT_ACTIVEERRINT ) != 0 )      {           /* This shouldn't happen for this simple DMA example, so set the LED              to indicate an error occurred. This is the correct method to clear              an abort. */           Chip_DMA_DisableChannel ( LPC_DMA , DMA_CH0 ) ;           while ( ( Chip_DMA_GetBusyChannels ( LPC_DMA ) & ( 1 << DMA_CH0 ) ) != 0 ) { }           Chip_DMA_AbortChannel ( LPC_DMA , DMA_CH0 ) ;           Chip_DMA_ClearErrorIntChannel ( LPC_DMA , DMA_CH0 ) ;           Chip_DMA_EnableChannel ( LPC_DMA , DMA_CH0 ) ;           Board_LED_Set ( 0 , true ) ;      }      Chip_GPIO_SetPinState ( LPC_GPIO , 0 , 7 , false ) ;      /* Clear DMA interrupt for the channel */      LPC_DMA -> DMACOMMON [ 0 ] . INTA = 1 ; }      /***       *      ____  __  __    _       *     |  _ \|  \/  |  / \       *     | | | | |\/| | / _ \       *     | |_| | |  | |/ ___ \       *     |____/|_|  |_/_/   \_\       *     / ___|  ___| |_ _   _ _ __       *     \___ \ / _ \ __| | | | '_ \       *      ___) |  __/ |_| |_| | |_) |       *     |____/ \___|\__|\__,_| .__/       *                          |_|       */ void DMA_Steup ( void ) {         DMA_CHDESC_T Initial_DMA_Descriptor ;                 ADC_TransferDescriptors [ 0 ] . source = ( uint32_t ) & LPC_ADC -> SEQ_GDAT [ 0 ] ;      ADC_TransferDescriptors [ 1 ] . source = ( uint32_t ) & LPC_ADC -> SEQ_GDAT [ 0 ] ;      ADC_TransferDescriptors [ 2 ] . source = ( uint32_t ) & LPC_ADC -> SEQ_GDAT [ 0 ] ;      ADC_TransferDescriptors [ 3 ] . source = ( uint32_t ) & LPC_ADC -> SEQ_GDAT [ 0 ] ;      ADC_TransferDescriptors [ 0 ] . dest = ( uint32_t ) & CapturedData [ ( 0 + 1 ) * DMA_TRANSFER_SIZE -1 ] ;      ADC_TransferDescriptors [ 1 ] . dest = ( uint32_t ) & CapturedData [ ( 1 + 1 ) * DMA_TRANSFER_SIZE -1 ] ;      ADC_TransferDescriptors [ 2 ] . dest = ( uint32_t ) & CapturedData [ ( 2 + 1 ) * DMA_TRANSFER_SIZE -1 ] ;      ADC_TransferDescriptors [ 3 ] . dest = ( uint32_t ) & CapturedData [ ( 3 + 1 ) * DMA_TRANSFER_SIZE -1 ] ;      //The initial DMA desciptor is the same as the 1st transfer descriptor.   It      //Will link into the 2nd of the main descriptors.      ADC_TransferDescriptors [ 0 ] . next = ( uint32_t ) & ADC_TransferDescriptors [ 1 ] ;      ADC_TransferDescriptors [ 1 ] . next = ( uint32_t ) & ADC_TransferDescriptors [ 2 ] ;      ADC_TransferDescriptors [ 2 ] . next = ( uint32_t ) & ADC_TransferDescriptors [ 3 ] ;      //Link back to the 1st descriptor      ADC_TransferDescriptors [ 3 ] . next = ( uint32_t ) & ADC_TransferDescriptors [ 0 ] ;      //For a test,  stop the transfers here.   The sine wave will look fine.      //ADC_TransferDescriptors[3].next = 0;      ADC_TransferDescriptors [ 0 ] . xfercfg = ( DMA_XFERCFG_CFGVALID |                                DMA_XFERCFG_RELOAD  |                                DMA_XFERCFG_SETINTA |                                DMA_XFERCFG_WIDTH_16 |                                DMA_XFERCFG_SRCINC_0 |                                DMA_XFERCFG_DSTINC_1 |                                DMA_XFERCFG_XFERCOUNT ( DMA_TRANSFER_SIZE ) ) ;      ADC_TransferDescriptors [ 1 ] . xfercfg = ADC_TransferDescriptors [ 0 ] . xfercfg ;      ADC_TransferDescriptors [ 2 ] . xfercfg = ADC_TransferDescriptors [ 0 ] . xfercfg ;      ADC_TransferDescriptors [ 3 ] . xfercfg = ( DMA_XFERCFG_CFGVALID |                                DMA_XFERCFG_RELOAD  |                                DMA_XFERCFG_SETINTA |                               DMA_XFERCFG_WIDTH_16 |                               DMA_XFERCFG_SRCINC_0 |                               DMA_XFERCFG_DSTINC_1 |                               DMA_XFERCFG_XFERCOUNT ( DMA_TRANSFER_SIZE ) ) ;      Initial_DMA_Descriptor . source = ADC_TransferDescriptors [ 0 ] . source ;      Initial_DMA_Descriptor . dest =    ADC_TransferDescriptors [ 0 ] . dest ;      Initial_DMA_Descriptor . next =   ( uint32_t ) & ADC_TransferDescriptors [ 1 ] ;      Initial_DMA_Descriptor . xfercfg = ADC_TransferDescriptors [ 0 ] . xfercfg ;      /* DMA initialization - enable DMA clocking and reset DMA if needed */      Chip_DMA_Init ( LPC_DMA ) ;      /* Enable DMA controller and use driver provided DMA table for current descriptors */      Chip_DMA_Enable ( LPC_DMA ) ;      Chip_DMA_SetSRAMBase ( LPC_DMA , DMA_ADDR ( Chip_DMA_Table ) ) ;      /* Setup channel 0 for the following configuration:         - High channel priority         - Interrupt A fires on descriptor completion */      Chip_DMA_EnableChannel ( LPC_DMA , DMA_CH0 ) ;      Chip_DMA_EnableIntChannel ( LPC_DMA , DMA_CH0 ) ;      Chip_DMA_SetupChannelConfig ( LPC_DMA , DMA_CH0 ,      //(DMA_CFG_PERIPHREQEN     |                                    ( DMA_CFG_HWTRIGEN        |                                     DMA_CFG_TRIGBURST_BURST |                                                          DMA_CFG_TRIGTYPE_EDGE   |                                        DMA_CFG_TRIGPOL_LOW    |     //DMA_CFG_TRIGPOL_HIGH                                        DMA_CFG_BURSTPOWER_1    |                                     DMA_CFG_CHPRIORITY ( 0 )                                          )                                        ) ;      //make sure ADC Sequence A interrupts is selected for for a DMA trigger      LPC_INMUX -> DMA_ITRIG_INMUX [ 0 ] = 0 ;      /* Enable DMA interrupt */      NVIC_EnableIRQ ( DMA_IRQn ) ;      // The 1st descriptor is set up through the registers.      /* Setup transfer descriptor and validate it */      Chip_DMA_SetupTranChannel ( LPC_DMA , DMA_CH0 , & Initial_DMA_Descriptor ) ;      //Use the transfer configuration for our 4 main descriptors      Chip_DMA_SetupChannelTransfer ( LPC_DMA , DMA_CH0 ,      ADC_TransferDescriptors [ 0 ] . xfercfg ) ;      Chip_DMA_SetValidChannel ( LPC_DMA , DMA_CH0 ) ;       } void SCT_PWM_Generate ( void ) {          /* Initialize the SCT as PWM and set frequency */      Chip_SCTPWM_Init ( SCT_PWM ) ;      Chip_SCTPWM_SetRate ( SCT_PWM , SCT_PWM_RATE ) ;      /* Setup Board specific output pin */      Chip_IOCON_PinMuxSet ( LPC_IOCON , 1 , 14 , IOCON_FUNC3 | IOCON_MODE_INACT | IOCON_DIGITAL_EN | IOCON_INPFILT_OFF ) ;      /* Use SCT0_OUT7 pin */      Chip_SCTPWM_SetOutPin ( SCT_PWM , SCT_PWM_OUT , SCT_PWM_PIN_OUT ) ;              /* Start with 50% duty cycle */      Chip_SCTPWM_SetDutyCycle ( SCT_PWM , SCT_PWM_OUT , Chip_SCTPWM_PercentageToTicks ( SCT_PWM , 10 ) ) ;      Chip_SCTPWM_Start ( SCT_PWM ) ;     }      /***            *         _    ____   ____            *        / \  |  _ \ / ___|            *       / _ \ | | | | |            *      / ___ \| |_| | |___            *     /_/__ \_\____/ \____|            *     / ___|  ___| |_ _   _ _ __            *     \___ \ / _ \ __| | | | '_ \            *      ___) |  __/ |_| |_| | |_) |            *     |____/ \___|\__|\__,_| .__/            *                          |_|            */ void ADC_Steup ( void ) {     /*Set Asynch Clock to the Main clock*/     LPC_SYSCON -> ADCCLKSEL = 0 ;     //Set the divider to 1 and enable.  note,  the HALT bit (30) and RESET (29) are not in the manual     LPC_SYSCON -> ADCCLKDIV = 0 ;      /* Initialization ADC to 12 bit and set clock divide to 1 to operate synchronously at System clock */     Chip_ADC_Init ( LPC_ADC , ADC_CR_RESOL ( 3 ) | ADC_CR_CLKDIV ( 0 ) | ADC_CR_ASYNC_MODE ) ;        //select ADC Channel 1 as input     Chip_IOCON_PinMuxSet ( LPC_IOCON , 0 , 30 , IOCON_FUNC0 | IOCON_ANALOG_EN | IOCON_INPFILT_OFF ) ;        LPC_ADC -> INSEL = 0x01 ;     Chip_ADC_SetupSequencer ( LPC_ADC , ADC_SEQA_IDX ,                                                                           ADC_SEQ_CTRL_SEQ_ENA |                               ADC_SEQ_CTRL_CHANNEL_EN ( ADC_INPUT_CHANNEL ) |                                                 ADC_SEQ_CTRL_TRIGGER ( 2 ) |                               ADC_SEQ_CTRL_HWTRIG_POLPOS |                                                 ADC_SEQ_CTRL_HWTRIG_SYNCBYPASS |                               ADC_SEQ_CTRL_MODE_EOS |                                                 ADC_SEQ_CTRL_SEQ_ENA ) ;     /* Enable Sequence A interrupt */     Chip_ADC_EnableInt ( LPC_ADC , ADC_INTEN_SEQA_ENABLE ) ;         /* Calibrate ADC */     if ( Chip_ADC_Calibration ( LPC_ADC ) == LPC_OK ) {         /* Enable ADC SeqA Interrupt */         NVIC_EnableIRQ ( ADC_SEQA_IRQn ) ;     }     else {         DEBUGSTR ( "ADC Calibration Failed \r\n" ) ;         return ;     } } int main ( void ) {       SystemCoreClockUpdate ( ) ;     Board_Init ( ) ;         DMA_Steup ( ) ;     ADC_Steup ( ) ;     SCT_PWM_Generate ( ) ;         while ( 1 )     { }     } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍  Verification      Building the project, then click the   to debug;        Generate the sine wave: 1 KHz, 幅度:0~2 V,feed the wave the ADC via the J9_1(P0_30-ADC1);         Setting the breakpoint (Fig 4) to observe the ADC converted value CapturedData[32]; Fig 4                        4. To verifying the result, I collect several group of data and use the Excel to make these data graphical for checking. Fig 6 is an example. Fig 5 Fig 6 Fig 7 Fig 8
View full article
LWIP debug output or application messages can be routed out to one of the serial ports by configuring the debug options. Enabling debug output in LWIP To enable debug code in LWIP, the "LWIP_DEBUG" flag needs to be defined when compiling the LWIP code. This can usually be done by using the "-D" option to define the flag as part of the argument list for the compiler. For example in the Keil tools, you can add the define C/C++ tab of the target options dialog. To enable specific debug messages in LWIP, just set the specific define value for the LWIP *_DEBUG value to " LWIP_DBG_ON". A full list of debug defines that can be enabled can be found in the opts.h file. Just copy the defines for the debug messages you want to enable into the lwipopts.h file for your project and enable them there. A few examples are shown below. #define TCP_DEBUG                       LWIP_DBG_ON #define ETHARP_DEBUG                    LWIP_DBG_ON #define PBUF_DEBUG                      LWIP_DBG_ON Selecting debug output The UART channel used for debug outputcan be selected by setting the UART_REDIRECT define to the UART number. On the LPC177x_8x devices, setting this to 0, 1, or 2 will enable output for UART ports 0, 1, or 2, respectively. You can completely disable output (while keep the debug code inside LWIP) by setting UART_REDIRECT to -1. As of release v1.01, simply enabling LWIP_DEBUG as the compilation define will automatically select the right UART for debug output. You can still override the UART for output if needed, but will need to edit the UART in the debug framework file. Caveats of enabling debug output Enabling debug output can add significant size to the generated code based on the debug options selected for the build. It will also slow down performance of the LWIP code due to required run-time checks and output. It's is recommended to enable debug support only if needed. Enabling just the UART for debug output adds about 4KBytes to the code size and about 512 bytes to the data size. The UART driver uses a ring buffer for buffering debug output with the UART IRQ to feed that data to the UART. The ring buffer size can be changed by changing the "UART_RING_BUFSIZE" define value in the serial.c file. Note: The call to initialize the debug framework used for LWIP debug output and printf() is active in the examples by default. Just remove the call to debug_frmwrk_init() in the examples to save some additional code and data memory. You may have also to remove the redirect.c file from the project for this change. Enabling debug output in the LWIP code uses a varying amount of memory based on which LWIP *_DEBUG defines are enabled. Without LWIP debug output enabled and the options selected below, the code size is increased by an additional 23.5KBytes and the data size increased by 1.6KBytes. #define LWIP_DEBUG #define TCP_DEBUG                       LWIP_DBG_ON #define ETHARP_DEBUG                    LWIP_DBG_ON #define PBUF_DEBUG                      LWIP_DBG_ON #define IP_DEBUG                        LWIP_DBG_ON #define TCPIP_DEBUG                     LWIP_DBG_ON #define DHCP_DEBUG                      LWIP_DBG_ON #define UDP_DEBUG                       LWIP_DBG_ON Note memory usage was checked at the 'default' compiler optimization setting. Example debug output Some example debug output use for capturing TCPIP, ethernet ARP, PBUF allocaiton and de-allocation, etc. are shown in the example output below captured from a LWIP run. Ethernet link not yet detected, will continue Starting LWIP ping server... dhcp_start(netif=1000eddc) en0 dhcp_start(): starting new DHCP client dhcp_start(): allocated dhcpudp_bind(ipaddr = 0.0.0.0, port = 68) udp_bind: bound to 0.0.0.0, port 68 udp_connect: connected to 0.0.0.0,port 68 dhcp_start(): starting DHCP configuration dhcp_discover() pbuf_alloc(length=308) pbuf_alloc(length=308) == 200018b4 transaction id xid(abcd0001) dhcp_discover: making request dhcp_discover: realloc()ing dhcp_discover: sendto(DISCOVER, IP_ADDR_BROADCAST, DHCP_SERVER_PORT) pbuf_header: old 200018fc new 200018f4 (8) udp_send: added header in given pbuf 200018b4 udp_send: sending datagram of length 316 udp_send: UDP packet length 316 udp_send: UDP checksum 0xdee0 udp_send: ip_output_if (,,,,IP_PROTO_UDP,) pbuf_header: old 200018f4 new 200018e0 (20) ip_output_if: en0 IP header: +-------------------------------+ | 4 | 5 |  0x00 |       336     | (v, hl, tos, len) +-------------------------------+ |        0      |000|       0   | (id, flags, offset) +-------------------------------+ |  255  |   17  |    0xba9d     | (ttl, proto, chksum) +-------------------------------+ |    0  |    0  |    0  |    0  | (src) +-------------------------------+ |  255  |  255  |  255  |  255  | (dest) +-------------------------------+ netif->output()pbuf_header: old 200018e0 new 200018d2 (14) etharp_send_ip: sending packet 200018b4 dhcp_discover: deleting()ing pbuf_free(200018b4) pbuf_free: deallocating 200018b4 dhcp_discover: SELECTING dhcp_discover(): set request timeout 2000 msecs tcp_bind: bind to port 7 dhcp_discover() pbuf_alloc(length=308) pbuf_alloc(length=308) == 200018b4 transaction id xid(abcd0002) dhcp_discover: making request dhcp_discover: realloc()ing dhcp_discover: sendto(DISCOVER, IP_ADDR_BROADCAST, DHCP_SERVER_PORT) pbuf_header: old 200018fc new 200018f4 (8) udp_send: added header in given pbuf 200018b4 udp_send: sending datagram of length 316 udp_send: UDP packet length 316 udp_send: UDP checksum 0xdde0 udp_send: ip_output_if (,,,,IP_PROTO_UDP,) pbuf_header: old 200018f4 new 200018e0 (20) ip_output_if: en0 IP header: +-------------------------------+ | 4 | 5 |  0x00 |       336     | (v, hl, tos, len) +-------------------------------+ |        1      |000|       0   | (id, flags, offset) +-------------------------------+ |  255  |   17  |    0xba9c     | (ttl, proto, chksum) +-------------------------------+ |    0  |    0  |    0  |    0  | (src) +-------------------------------+ |  255  |  255  |  255  |  255  | (dest) +-------------------------------+ netif->output()pbuf_header: old 200018e0 new 200018d2 (14) etharp_send_ip: sending packet 200018b4 dhcp_discover: deleting()ing pbuf_free(200018b4) pbuf_free: deallocating 200018b4 dhcp_discover: SELECTING dhcp_discover(): set request timeout 2000 msecs etharp_request: sending ARP request. pbuf_alloc(length=42) pbuf_alloc(length=42) == 200018b4 etharp_raw: sending raw ARP packet. pbuf_free(200018b4) pbuf_free: deallocating 200018b4 pbuf_alloc(length=594) pbuf_alloc(length=594) == 20004cc0 ethernet_input: dest:00:60:37:12:34:56, src:00:26:f3:a2:6b:b2, type:800 pbuf_header: old 20000050 new 2000005e (-14) ip_input: iphdr->dest 0x1d0a010a netif->ip_addr 0x0 (0x0, 0x0, 0x1d0a010a) ip_input: UDP packet to DHCP client port 68 ip_input: DHCP packet accepted. ip_input: IP header: +-------------------------------+ | 4 | 5 |  0x00 |       576     | (v, hl, tos, len) +-------------------------------+ |        0      |000|       0   | (id, flags, offset) +-------------------------------+ |   64  |   17  |    0x508e     | (ttl, proto, chksum) +-------------------------------+ |   10  |    1  |   10  |    1  | (src) +-------------------------------+ |   10  |    1  |   10  |   29  | (dest) +-------------------------------+ ip_input: p->len 576 p->tot_len 576 pbuf_header: old 2000005e new 20000072 (-20) udp_input: received datagram of length 556 UDP header: +-------------------------------+ |        67     |        68     | (src port, dest port) +-------------------------------+ |       556     |     0x8880    | (len, chksum) +-------------------------------+ udp (10.1.10.29, 68) <-- (10.1.10.1, 67) udp_input: calculating checksum pbuf_header: old 20000072 new 2000007a (-8) dhcp_recv(pbuf = 20004cc0) from DHCP server 10.1.10.1 port 67 pbuf->len = 548 pbuf->tot_len = 548 searching DHCP_OPTION_MESSAGE_TYPE DHCP_OFFER received in DHCP_SELECTING state dhcp_handle_offer(netif=1000eddc) en0 dhcp_handle_offer(): server 0x010a010a dhcp_handle_offer(): offer for 0x1d0a010a dhcp_select(netif=1000eddc) en0 pbuf_alloc(length=308) pbuf_alloc(length=308) == 200018b4 transaction id xid(abcd0003) pbuf_header: old 200018fc new 200018f4 (8) udp_send: added header in given pbuf 200018b4 udp_send: sending datagram of length 316 udp_send: UDP packet length 316 udp_send: UDP checksum 0x9958 udp_send: ip_output_if (,,,,IP_PROTO_UDP,) pbuf_header: old 200018f4 new 200018e0 (20) ip_output_if: en0 IP header: +-------------------------------+ | 4 | 5 |  0x00 |       336     | (v, hl, tos, len) +-------------------------------+ |        2      |000|       0   | (id, flags, offset) +-------------------------------+ |  255  |   17  |    0xba9b     | (ttl, proto, chksum) +-------------------------------+ |    0  |    0  |    0  |    0  | (src) +-------------------------------+ |  255  |  255  |  255  |  255  | (dest) +-------------------------------+ netif->output()pbuf_header: old 200018e0 new 200018d2 (14) etharp_send_ip: sending packet 200018b4 pbuf_free(200018b4) pbuf_free: deallocating 200018b4 dhcp_select: REQUESTING dhcp_select(): set request timeout 2000 msecs pbuf_free(20004cc0) pbuf_free: 20004cc0 has ref 1, ending here. pbuf_free(20004cc0) pbuf_free: deallocating 20004cc0
View full article
Getting Started with LPCXpresso54608  & MCUXpresso is pretty straight forward, but we want to make the process even easier.  So we created a  simple guide to walk you through the getting started process,         LPCXpresso54608: Out of Box & Getting Started Introduction LPC5460x MCU Family part numbering & feature summary table (highlighted in yellow are the first of many parts to be released). If it wasn't already clear, LPCXpresso54608 is the superset development board for our LPC5460x MCU Family. NXP.com Board Page Board Part Number (OM13092) Board User Manual (UM11035) Board Schematics Key features of the LPCXpresso54608 development board, 272x480 color LCD with capacitive touch screen On-board, high-speed USB, Link2 debug probe with CMSIS-DAP and SEGGER J-Link protocol options UART and SPI port bridging from LPC546xx target to USB via the on-board debug probe Support for external debug probe 3 x user LEDs, plus Reset, ISP (3) and user buttons Multiple Expansion options, including Arduino UNO and PMod Built-in power consumption measurement for target LPC546xx MCU 128Mb Micron MT25QL128 Quad-SPI flash 8MB Micron MT48LC8M16A2B4 SDRAM Knowles SPH0641LM4H digital microphone Full size SD/MMC card slot NXP MMA8652FCR1 accelerometer Stereo audio codec with line in/out High and full speed USB ports with micro A/B connector for host or device functionality 10/100Mbps Ethernet (RJ45 connector)
View full article
This document describes how to create a new LPC project using LPCOpen v2.xx, LPCXpresso v8.2.2 and LPC11U24 LPCXpresso board. In addition describes how to create 2 simple example codes. Blinking LED. Set the LED using a push bottom.  LPCOpen LPCOpen is an extensive collection of free software libraries (drivers and middleware) and example programs that enable developers to create multifunctional products based on LPC microcontrollers. After install LPCXpresso, the LPCOpen packages for supported board(s)/device(s) can be found at the path: <install_path>\lpcxpresso\Examples\LPCOpen > This directory contains a number of LPCOpen software bundles for use with the LPCXpresso IDE and a variety of development boards. Note that LPCOpen bundles are periodically updated, and additional bundles are released. Thus we would always recommend checking the LPCOpen pages to ensure that you are using the latest versions. This example was created using the LPC11U24 LPCXpresso board in this case the drivers selected is lpcopen_v2_00a_lpcxpresso_nxp_lpcxpresso_11u14.zip Importing libraries In order to create a new project, it is necessary to first import the LPCOpen Chip Library for the device used and optionally the LPCOpen Board Library Project. For do that it is necessary to follow these steps: 1. Click on Import project(s). 2. Select the examples archive file to import. In this case, the projects imported are contained within archives .zip.  3. For this example the LPC11U14 LPCXpresso board is selected. Click Open. Then click Next 4. Select only the LPCOpen Chip Library and LPCOpen Board Library Project. Click Finish. The same steps are required for any LPC device and board you are used. Creating a new LPC project.   The steps to create a new LPC project are described below: 1. In Quickstar Panel, click "New project"   2. Choose a wizard for your MCU. In this case LPC1100/LPC1200 -> LPC11Uxx -> LPCOpen-C Project This option will link the C project to LPCOpen. Then click Next.   3. Select the Project name and click Next.   4. Select the device used (LPC11U24 for this case) and click Next.   5. Select the LPCOpen Chip Library and LPCOpen Board Library, these projects must be present in the workspace.   6. You can set the following option as default clicking Next, then click Finish.   7. At this point, a new project was created. This project has a src (source) folder, the src folder contains: cr_startup_lpc11uxx.c: This is the LPC11Uxx Microcontroller Startup code for use with LPCXpresso IDE. crp.c: Source file to create CRP word expected by LPCXpresso IDE linker. sysinit.c: Common SystemInit function for LPC11xx chips. <name of project> my_first_example: This file contains the main code.     8. LPCXpresso creates a simple C project where it is reading the clock settings and update the system core clock variable, initialized the board and set the LED to the state of "On". 9. At this point you should be able to build and debug this project.   Writing my first project using LPCXpresso, LPCOpen and LPC11U24.   This section describes how to create 2 simple example codes. Blinking LED. Set the LED using a push bottom. The LPCOpen Chip Library (in this case lpc_chip_11uxx_lib) contains the drivers for some LPC peripherals. For these examples, we will use the GPIO Driver. The LPCOpen Board Library Project (in this case nxp_lpcxpresso_11u14_board_lib) contains files with software API functions that provide some simple abstracted functions used across multiple LPCOpen board examples. The board_api.h contains common board definitions that are shared across boards and devices. All of these functions do not need to be implemented for a specific board, but if they are implemented, they should use this API standard.   After create a new project using LPCXpresso and LPCOpen, it is created a simple C project where it is initialized the board and set the LED to the state of "On" using the Board_LED_Set function.   int main( void ) {   #if defined (__USE_LPCOPEN)     // Read clock settings and update SystemCoreClock variable     SystemCoreClockUpdate(); #if !defined(NO_BOARD_LIB)     // Set up and initialize all required blocks and     // functions related to the board hardware     Board_Init();     // Set the LED to the state of "On"     Board_LED_Set(0, true); #endif #endif       // TODO : insert code here       // Force the counter to be placed into memory     volatile static int i = 0 ;     // Enter an infinite loop, just incrementing a counter     while (1) {         i++ ;     }     return 0 ; }       a. Blinking LED. In board_api.h file there is an API function that toggle the LED void Board_LED_Toggle( uint8_t LEDNumber);   LEDNumber parameter is the LED number to change the state. The number of the LED for the LPCXpresso LPC11U24 is 0. It is easy to create a delay function using FOR loops. For example: void Delay ( unsigned int ms) {         volatile static int x,y;           while (ms)         {                 for (x=0; x<=140; x++)                 {                         y++;                 }                 ms--;         } } In order to have the LED blinking, it is necessary to call these functions in an infinite loop. while (1) {                 Board_LED_Toggle(0);                 Delay (10000);         } Complete code (Blinking LED). int main( void ) { #if defined (__USE_LPCOPEN)         // Read clock settings and update SystemCoreClock variable         SystemCoreClockUpdate(); #if !defined(NO_BOARD_LIB)         // Set up and initialize all required blocks and         // functions related to the board hardware         Board_Init();         // Set the LED to the state of "On"         Board_LED_Set(0, true); #endif #endif          while (1) {                 Board_LED_Toggle(0);                 Delay (10000);         }         return 0 ; }  void Delay ( unsigned int ms) {          volatile static int x,y;         while (ms)         {                 for (x=0; x<=140; x++)                 {                         y++;                 }                 ms--;         } }      b. Set the LED using a push bottom. For this example it is necessary to configure a pin as input.  The gpio_11xx_1.h file contains all the function definitions for the GPIO Driver. The example uses the pin 16 of port 0 to connect the push bottom. The function Chip_GPIO_SetPinDIRInput ( LPC_GPIO_T *pGPIO, uint8_t port, uint8_t pin) sets the GPIO direction for a single GPIO pin to an input. In order to configure the Port 0, pin 16 as input we can use this function: Chip_GPIO_SetPinDIRInput(LPC_GPIO, 0, 16); Then, it is necessary to check the status of this pin to turn-on/turn-off the LED. The function Chip_GPIO_GetPinState ( LPC_GPIO_T *pGPIO, uint8_t port, uint8_t pin) gets a GPIO pin state via the GPIO byte register. This function returns true if the GPIO is high, false if low. State_Input=  Chip_GPIO_GetPinState (LPC_GPIO, 0, 16);   Complete code (Set the LED using a push bottom). int main( void ) {         bool State_Input;   #if defined (__USE_LPCOPEN)     // Read clock settings and update SystemCoreClock variable     SystemCoreClockUpdate(); #if !defined(NO_BOARD_LIB)     // Set up and initialize all required blocks and     // functions related to the board hardware     Board_Init();     Chip_GPIO_SetPinDIRInput(LPC_GPIO, 0, 16);     // Set the LED to the state of "On"     Board_LED_Set(0, false);  #endif  #endif      while (1) {           State_Input=  Chip_GPIO_GetPinState (LPC_GPIO, 0, 16);              if (State_Input==0){                 Board_LED_Set(0, true);             }              else {                 Board_LED_Set(0, false);              }     }     return 0 ; }   I hope this helps!! Regards Soledad
View full article
This document explains how to create a new project using MCUXpresso IDE for a LPCXpresso1549 board. There is important to mention that there is no SDK for LPC15xx device family so we are using LPCOpen libraries.   MCUXpresso IDE introduction   MCUXpresso IDE is based on the Eclipse IDE and includes the industry standard ARM GNU toolchain. It brings developers an easy-to-use and unlimited code size development environment for NXP MCUs based on Cortex-M cores (LPC and Kinetis). MCUXpresso IDE debug connections support Freedom, Tower®, LPCXpresso and your custom development boards with industry- leading open-source and commercial debug probes including LPC-Link2, P&E and SEGGER. The fully featured debugger supports both SWD and JTAG debugging, and features direct download to on-chip flash. When MCUXpresso IDE is installed, it will contain pre-installed part support for most LPC based MCUs. Example code for these pre-installed parts is provided by sophisticated LPCOpen packages (and Code Bundles). Each of these contains code libraries to support the MCU features, LPCXpresso boards (and some other popular ones), plus a large number of code examples and drivers.   In addition, MCUXpresso IDE’s part support can be extended using freely available MCUXpresso SDK2.x packages. These can be installed via a simple ‘drag and drop’ and automatically extend the IDE with new part knowledge and examples. SDKs for MCUXpresso IDE can be generated and downloaded as required using the SDK Builder on the MCUXpresso Config Tools website at: http://mcuxpresso.nxp.com/   Create a new project   For this document, we are using the LPCXpresso1549 board (for this MCU an LPCOpen project exists), however the process is the same for any LPCXpresso board. It is necessary to download the LPCOpen bundle for your target MCU/board and import it into your Workspace, LPCOpen is available in the next link:  http://www.nxp.com/lpcopen Select “New project” in the QuickStart panel, this will open a new window   Select the desire board. For this case, we are using the LPCXpresso1549, and click “Next” NOTE: When the board is selected, you can see highlighted in the above figure that the matching MCU (part) is selected automatically. If no matching board is available, the required MCU can be selected from the list of Pre-Installed MCUs. The MCUXpresso IDE includes many project templates to allow the rapid creation of correctly configured projects for specific MCUs. This New Project wizard supports 2 types of projects: Those targeting LPCOpen libraries Standalone projects In this case, we will show the steps in creating a LPCOpen- Cproject. This option creates a simple C project, with the main() routine consisting of an infinite while(1) loop that increments a counter. In additions, code will also be included to initialize the board and enable a LED. Select the project name and click “Next” When creating an LPCOpen-based project, the first option page that you will see is the LPCOpen library selection page. It is necessary import the LPCOpen Chip Library for the device used and optionally the LPCOpen Board Library Project, the below window allows to import the libraries if you have not already done so. Follow the below steps: a. Click on “Import…”, a new window will appear, select the archive file to import. In this case, the projects imported are contained within archives .zip. For this example, the LPCXpresso1549 board is selected. Click “Open”. Then click “Next” b. Select only the LPCOpen Chip Library and LPCOpen Board Library Project. Click “Finish” Select LPCOpen Libraries. Click “Next” Select CMSIS Library project. The CMSIS library option within the MCUXpresso IDE allows you to select which (if any) CMSISCORE library you want to link to from the project you are creating. For this case we selected “None” as default. Click “Next” NOTE: The use of LPCOpen instead of CMSIS-CORE library projects is recommended in most cases for new projects. Enable SWO trace clock. Click “Next” Enable linker support for CRP. Click “Next” The “Semihosting C Project” wizard for some parts provides two options for configuring the implementation of printf family functions that will get pulled in from the Redlib C library: Use non-floating-point version of printf If your application does not pass floating point numbers to printf() family functions, you can select a non-floating-point variant of printf. This will help to reduce the code size of your application. For MCUs where the wizard does not provide this option, you can cause the same effect by adding the symbol CR_INTEGER_PRINTF to the project properties. Use character- rather than string-based printf By default printf() and puts() make use of malloc() to provide a temporary buffer on the heap in order to generate the string to be displayed. Enable this option to switch to using “character-by-character” versions of these functions (which do not require additional heap space). This can be useful, for example, if you are retargeting printf() to write out over a UART – since in this case it is pointless creating a temporary buffer to store the whole string, only to print it out over the UART one character at a time. For MCUs where the wizard does not provide this option, you can cause the same effect by adding the symbol CR_PRINTF_CHAR to the project properties. For this example we will maintain as default. Having selected the appropriate options, you can then click on the Finish button, and the wizard will create your project for you, together with appropriate startup code and a simple main.c file. At this point you should be able to build and debug this project Writing my first project The LPCOpen Chip Library (in this case lpc_chip_15xx) contains the drivers for some LPC peripherals. For these examples, we will use the GPIO Driver. The LPCOpen Board Library Project (in this case lpc_board_nxp_lpcxpresso_1549) contains files with software API functions that provide some simple abstracted functions used across multiple LPCOpen board examples. The board_api.h contains common board definitions that are shared across boards and devices. All of these functions do not need to be implemented for a specific board, but if they are implemented, they should use this API standard. After create a new project using MCUXpresso and LPCOpen, it is created a simple C project where it is initialized the board and set the LED to the state of "On" using the Board_LED_Set function. In this example, we will toggle the a LED using a push bottom. In LPCXpresso1549 board le LEDs are connected to PIO1.1, PIO0.3 and PIO0.25 pins. And the SW1 to PIO0.17 pin. The function Chip_GPIO_SetPinDIRInput configures a pin as input.  The function Chip _GPIO_GetPinState gets a GPIO pin state via the GPIO byte register. The function Board_LED_Set set the LED to the state of "On" or “Off”.. Complete code (Set the LED using a push bottom).   /* ===============================================================================  Name        : LPCXpresso_new_example.c  Author      : $(author)  Version     :  Copyright   : $(copyright)  Description : main definition ===============================================================================  */   #if defined (__USE_LPCOPEN) #if defined(NO_BOARD_LIB) #include "chip.h" #else #include "board.h" #endif #endif   #include <cr_section_macros.h>     int main( void ) {         bool State_Input;   #if defined (__USE_LPCOPEN)        // Read clock settings and update SystemCoreClock variable        SystemCoreClockUpdate();   #if !defined(NO_BOARD_LIB)        // Set up and initialize all required blocks and        // functions related to the board hardware        Board_Init();        Chip_GPIO_SetPinDIRInput(LPC_GPIO, 0, 17); //Set GPIO direction for a single GPIO pin to an input   #endif #endif          while (1) {                State_Input=  Chip_GPIO_GetPinState (LPC_GPIO, 0, 17);  //Get a GPIO pin state via the GPIO byte register                if (State_Input==0){                       Board_LED_Set (0, true); // Set the LED to the state of "On"                }                else   {                       Board_LED_Set (0, false); // Set the LED to the state of "Off"                }        }        return 0 ; }  
View full article
The DMX512 master and slave board (OM13043) are no longer available. This page is provided for reference purposes only. Board information and code is available in the zip file attached to this posting. NXP offers dedicated components to realize DMX512 based systems for both communication and power stages. The reference design provides a basic set of commands (including Remote Device Management) that can be used as a starting point to develop next-generation DMX512 platforms. The DMX512 Software Development Kit (SDK) for the LPC11xx/LPC11Uxx installer contains: AN11153 - Describes the use of the NXP LPC111x Cortex M0 microcontroller to create an RDM enabled DMX512 Slave AN11154 – Describes the use of the NXP LPC11U1x Cortex M0 microcontroller to create a RDM enabled DMX512 Master (USB - DMX interface) UM10536 - Explains how to get started with the NXP DMX512 Master (USB - DMX interface) and DMX512 Slave (demo board for DMX fixture) and the NXP Windows .NET DMX512control application Software Package – DMX master and slave implementation for LPCXpresso toolchain and Windows .NET GUI Schematics, Gerber files and BOM List The SDK is attached to this page (see below) for REFERENCE PURPOSES ONLY. DMX512 Master Board DMX512 Slave Board System notes Controller side: LPC1100XL microcontroller (up to 50 MHz - 45 DMIPS) offers performance needed to integrate DMX message coding/decoding and PWM generation in a single chip Industry-leading low active power consumption of 110 uA/MHz for bus-powered devices Storage of scene settings in non-volatile memory using EEPROM emulation in flash, or integrated EEPROM in LPC11E00 series Up to four 16-bit and 32-bit timers, generating up to 11 PWM signals to control and dim the ballast Reduced development complexity - software can be written in C Reduced bill of materials – significant cost savings through Cortex-M0 architecture, plus many built-in peripherals to interface with lighting drivers and network in LPC1100XL Power stage: LED dimming using the PWM input of the NXP UBA3070 DC-to-DC LED driver with up to 98% efficiency SSL4101 provides mains isolation for both the RGB LED power stage and the DMX wires Low component count and high efficiency through integrated PFC and flyback control functionality GreenChip TEA1721 buck converter supplies LPC1100XL with high efficiency; no-load power consumption levels 10 mW Implementation example (DMX512 slave unit): RDM-enabled DMX512 slave or receiver built around the NXP LPC111x Cortex-M0 microcontroller Features four DMX controllable LEDs, a red heartbeat LED, a green traffic LED, DIP switches for selecting the DMX start address, a 5-position joystick, and an optional LCD The UART and the 16-bit timer/counters of the LPC111x MCU are the main hardware blocks needed The I2C hardware block is used to interface with the (optional) LCD functionality References to DMX512 refer to DMX512-A, since both hardware and software are designed using the latest standard Implementation example (DMX512 master unit): DMX512 controller and monitoring device, built around the NXP LPC11U1x microcontroller, enabling Remote Device Management (RDM) Features a USB interface, a red heartbeat LED, and a green traffic LED The USB and UART of the LPC11U1x MCU are the main hardware blocks needed
View full article
DALI Software Development Kit The DALI development kits for LPC are no longer available. The LPC MCUs used are still available. This page is provided for reference purposes only. The DALI Software Development Kit (SDK) for the LPC11xx/LPC13xx contains an updated DALI Library for compliancy with the IEC 62386-102 and IEC 62386-201 standard. Parts of the IEC 62386-207 specification are also included. The DALI slave (AN11174 with OM13026 board) and the USB to DALI master (AN11175 with OM13046 board) can be used in combination with the Windows 7 PC GUI to create a demonstration and evaluation setup as described in UM10553. The SDK contains the example software, DALI library, a hardware description and design files of both boards, documentation and is available for download at the end of this document. DALI Slave OM13026                                                       DALI Master OM13046 System notes Controller side: The LPC1100XL (up to 50 MHz - 45 DMIPS) offers enough performance to integrate DALI message coding/decoding and PWM generation in a single chip Industry-leading low active power consumption of 110 uA/MHz for bus-powered devices Storage of scene settings in non-volatile memory using EEPROM emulation in flash, or integrated EEPROM in LPC11E00 series Up to four 16-bit and 32-bit timers, generating up to 11 PWM signals to control and dim the ballast Reduced development complexity - software can be written in C Reduced bill of materials - significant cost savings through Cortex-M0 architecture, plus many built-in peripherals to interface with lighting drivers and network in LPC1100XL Power stage: LED dimming using the PWM input of the NXP UBA3070 DC-to-DC LED driver with up to 98% efficiency SSL4101 provides mains isolation for both the RGB LED power stage and the DALI wires Low component count and high efficiency through integrated PFC and flyback control functionality GreenChip TEA1721 buck converter supplies LPC1100XL with high efficiency; no-load power consumption levels <10 mW DALI Slave Implementation example (OM13026 board): Contains isolated physical layer for the DALI bus with a Cortex M0 LPC111x microcontroller for the DALI protocol handling, and many I/O functions to steer external lighting drivers for solid state or compact fluorescent lighting applications Schematics, gerbers and BOM also available to speed up development Up to four PWM signals available to independently drive different lighting units Frequency and resolution of the signals is software programmable ON_OFF signal can be used independently from the PWM signals to switch a lighting driver into an OFF or ON state I2C-bus pins can be used to externally connect other devices like EEPROM or a temperature sensor Analog A/D input is available via pin 8 IO signal is left open for the end user UART, I2C and A/D converter functionality not included in the software release
View full article
Unboxing video of the low cost OKDO E1 board.    As a quick demo, I hooked up the E1 to a low cost  240x240 Pixel IPS display from buydisplay.com.
View full article
This documents describes how to use this tool in order to generate the routing and muxing for pins. This tool is available as an online WEB application https://mcuxpresso.nxp.com Pins Tool Overview The Pins Tool is an easy-to-use way to configure the pins of the device. The Pins Tool software enables you to create, inspect, change, and modify any aspect of the pin configuration and muxing of the device. This document introduces you to the Pins Tool. It describes the basic components of the tool and lists the steps to configure and use the tool to configure the pins. This tool is provided as an online WEB application. You need to generate a downloadable MCUXpresso SDK v.2 package. The below link shows the steps for do that. Generating a downloadable MCUXpresso SDK v.2 package  User interface The Pins Tool consists of several views. Using the Pins Tool The Pins Tool is designed to configure routing of signals from peripherals either to pins or to internal signals. To define routing path, first select a peripheral, then select the signal, and finally select the pin. 1. Select a peripheral for example GPIO. The following image illustrates the filtering controls in the Pins view. 2.  Route the selected Signal to the desired pin. It is possible to easily identify routed pins/peripherals in the package using highlighting. By default, the current selection (pin/peripheral) is highlighted in the package view. • Red indicates that the pin has an error. • Green indicates that the pin is muxed or used. • Light grey indicates that the pin is available for mux, but is not muxed or used. • Yellow border around the pin such that the other color is still visible indicates that the pin is selected. For example, by peripheral or by pin. 3. Select one of non-conflicting/available pins. Once you have selected Peripheral, Signal, and Route to, the pin configuration is done. Later, it is also possible to configure the pin electrical features. Use the table drop down menu to configure the pin. To configure pins, start from left to right – select the peripheral first, then select required signal, and finally select the routed pin. The italic value indicates that the value is not configured and it shows the after-reset value and no code is generated, so the configuration relies on the after reset value or the values configured from the different functions. Code generation The tool generates source code that can be incorporated into an application to initialize pins routing. The source code is generated automatically on change or can be generated manually by selecting the main menu Pins > Generate Now. The generated code is shown in the Sources tab on the right window. It shows all generated files and each file has its own tab. It is also possible to copy and paste the generated code into the source files. The view generates code for each function. In addition, it is possible to Export generated source using the Export option. 1. Select Pins > Export 2. Click Next. 3. Select the name of the zip file and click Finish. Your download should automatically begin.  Enjoy!!   Related links: Introducing MCUXpresso SDK v.2 for LPC54xxx Series  Generating a downloadable MCUXpresso SDK v.2 package  MCUXpresso Config Tools is now available!   How to start with SDK v.2.0 for LPC5411x using LPCXpresso IDE 
View full article
Today's Data Acquisition Applications require separate ICs for input, processing, and output. With the new LPC4370, designers have a complete data acquisition solution on a single chip. With the release of NXP’s new LPC4370 Cortex-M4F microcontroller, we wanted to provide engineers with the tools necessary to evaluate its high-performance signal processing capabilities (up to 204 MHz) and its host of advanced features and peripherals including the 12-bit ADC at 80 Msps with up to six channels.   The result is a new product from Embedded Artists, named LabTool.  LabTool is as an add-on board to NXP’s LPC-Link 2 debugger and demoboard platform.  The LabTool includes a hardware daughter board and software running on the PC that enables the Link2 to be used as a logic analyzer, oscilloscope, and signal generator. It is designed around NXP’s new LPC4370 microcontroller, and the hardware can serve as a development platform for this MCU.   LPC4370 and LabTool Key Components Follow the URLs in the table to find more information on the product and its key components. LPC4370 The LPC4370, ARM Cortex-M4F based microcontrollers, are complete data acquisition solutions on a single chip. The LPC4370 provide the fast digital and analog inputs, the high performance processing capabilities, and the hi-speed output needed for data acquisition applications. Running up to 204MHz, the ARM Cortex-M4F of the LPC4370 is the industry’s fastest Cortex-M microcontroller. The Cortex-M4F is a next generation 32-bit core that offers system enhancements such as low power consumption, enhanced debug features, and a high level of support block integration. Download the LPC4370 documentation: LPC4370 BGA256 Product Information Page LPC4370 BGA100 Product Information Page LPC4370 User Manual and Data Sheet LPC4300 Series Leaflet LPC-Link2 LPC-Link 2 is an extensible, stand-alone debug probe that can be configured to support various development tools and IDEs using a variety of different downloadable firmware images. It can also be used as an evaluation board in its own right for the NXP LPC4370 triple core MCU. And through the use of an add-on board from Embedded Artists, it can be used as an oscilloscope or logic analyzer! For more information on the Link 2, view our NXP.com page. LabTool LabTool can be purchased as a kit that includes the Link2 main board plus the add-on board, or the two can be purchased separately.  A connector with 26 probe wires is included, and is the only accessory required for using the tool.  The probes feature a 2.54mm pigtail end, for easily connecting to headers and jumpers on a target platform.  A set of compatible microgrippers may also be useful, but must be purchased separately. Purchase LabTool, download documentation and the GUI at Embedded Artists product page.   LabTool also available for purchase at: Watch the video here.   LabTool Features   The LabTool consists of both a hardware platform and a software GUI, which combine together in providing the following set of features that are commonly used by electronic designers during bench debugging.  A standard 5.0V supply from your high-speed USB2.0 connector provides the power needed to operate the board, as well as the high-speed communication channel for the data stream.   Digital Channels 10 channel logic analyzer supporting 100MHz (2ch), 80Mhz (4ch), 50MHz (8ch), 20MHz (10ch) Selectable edge-sensitive and level-sensitive triggers give you flexibility in how the signal is displayed. 11 channel digital signal generator up to 80Mhz, at 3.3 volts logic level. Included with the digital interface are three protocol analyzers.  You can monitor SPI, I2C and UART with a built-in interpreter that shows the timing of clock and data transfers in the GUI. Demonstration signals are provided already on the board, by means of an LPC812 microcontroller.  This devices generates heartbeat PWM, four digital counters (at 750KHz, 1.5MHz, 3.0Mhz and 6.0MHz), plus SPI, I2C and UART data streams.  These signals can be used for quickly verifying the tools is up and running, and provides reference signals for comparing to your own design when measured by the LabTool.   Analog Channels   2 channel oscilloscope sampling at 80Msps (1ch), 40MHz (2ch), with 6MHz bandwidth rating.  The voltage range that can be sampled is a very wide range at +/- 25 volts.  Input impedance is 1Mohm. 2 channel analog output generation at 40KHz bandwidth, at +/- 5 volts.  Three built-in waveform generators support sine, square and triangle waveforms.   GUI   LabTool comes with a feature rich software interfaced developed by Embedded Artists.  The GUI gives users the capability to manage the digital and analog channels through: Dialogs for selecting digital and analog inputs channels One-shot and continuous sampling Sorting and moving of signals Applying application-specific signal names Saving settings in a project file Exporting collected data to .csv formatted files Appling SPI, I2C or UART protocol analyzers to selected channels Using four cursors to measure and interpret waveforms     Open Source Environment   The GUI is developed using Qt framework, and can be provided as open source. Source code for the firmware operating on the LPC4370 is also planned to be released for use among the community of NXP users.  Developers are encouraged to use this firmware as a starting point for creating exciting new applications based on LPC4370! Getting Started   A comprehensive user guide for the LabTool is available from Embedded Artists at the link given above. Tips for getting started:   Refer to the user guide and notes on Embedded Artists web site for the most recent instructions.  Here are some tips that have helped our testers and expert industry users to get started smoothly.   Install the GUI software first.  USB drivers (needed at step #2 below) are copied to the installation folder during this step. Attach the LabTool add-on board to the Link2 (see image below for proper orientation). Driver installation may take several minutes, and is accomplished in two steps.   When the hardware is first connected to a USB port, the driver for the Link2 must be installed.  This driver is included with the LPC-Link2 Configuration Tool.  The device manager shows the hardware is enumerated as “LPC Device”. Once the Link2 driver is loaded, the next step allows the LabTool GUI to be started.  The first time the GUI runs, it will detect the LabTool hardware, and will load an additional driver.  This driver is located in a sub-folder from the location where the LabTool software package was installed.  The device manager shows the hardware is now enumerated as “NXP LabTool”   Once the GUI is running, check that “LabTool Device” is displayed in the section marked “Selected device” in the diagram above. The probe bundle has each wire function labeled on the silk screen of the PCB.  Check these carefully to find cable D0, and connect it to the demonstration signal  labeled “PWM_LED” on the header at the bottom right corner of the board.  In the GUI, choose “Add Signal” and select D0 as an input channel; press OK.  Set a falling edge trigger and a sample rate of 2MHz.  Choose continuous sampling, and view the results in the waveform view.  It’s that simple!   Correct Orientation   Correct orientation is required.  Be sure the expansion headers on the Link2 are aligned properly to the connectors on the LabTool add-on board.  The USB port is located at the end opposite from the BNC connectors.     Industry Experts and NXP Testers   We asked leading experts in the embedded community to test the LPC4370 and LabTool, create some test code, and let us know what they thought of the whole process.  Below are their evaluations:   Industry Experts   Kevin Townsend has been working with LPC microcontrollers since the ARM7 LPC2000 products were released. He specializes in ARM Cortex-M0/M3/M4 design and development with interest in low power and wireless sensors. He is active in the open source HW world as Lead Engineer at Adafruit Industries. Kevin tested the LPC4370 and wrote a review on his blog site, www.microbuilder.eu. To read his insightful commentary follow this link.   Bob Boys is a Product Manager for Keil MDK and ARM DS-5 tools at ARM with multiple years of experience in the industry. He holds a Masters in Information Sciences and has worked with a variety of hardware and software platforms around the ARM Cortex family of products. Bob decided to test out the oscilliscope feature of the LabTool. See his review below.   Dirceu Rodriguez, Jr. is a computer engineer with a master's degree in electrical engineering. As an independent consultant, he tests new products with particular interest in the areas of wireless sensor networks, ARM processors, DSP, motor control, and medical applications. (Review coming soon)   Massimo Manca has 20+ years of experience in the industry. He has worked on a variety of applications with more than 30 different microcontroller families. Massimo gave the LabTool and Link2 a thorough testing on all parts.  Initial comments are provided below, with an additional review coming soon.   NXP Testers NXP Application Engineers have tested the LPC4370 and LabTool for themselves.  Their feedback and use cases are shown below.     Using the SPI Protocol Analyzer     Using LabTool to evaluate Rotary Encoder and QEI peripheral     Investigating I2C/SMBus issue using LabTool     Comparing the LabTool to a commercially available signal analyzer   Evaluations and Reports Kevin Townsend hosts a blog on his microbuilder.eu site. Read his insightful commentary here.   Bob Boys from ARM, Ltd. wrote:   I tested the scope part as this is what I am most interested in.  LabTool in this respect worked quite well compared to other USB scopes I have used that cost mush more.  I tested it on a two node CAN network and the SWO Serial Wire Output: both on a Keil MCB1700 (LPC1768) board.   I liked these things: 1)    Easy to change from neg/pos slope or no trigger. 2)    Changing the trigger point was very easy although I liked using the no trigger setting better to initially get a waveform going. 3)    Determining the timing was easy and surprisingly accurate.  At first I was getting very bad frequencies but after I calibrated the LabTool per the instruction it was fine. 4)    Setting the cursors was easy – but see point 5 below. 5)    The waveform faithfulness compared to my HP 100 mHZ scope was quite good. 6)    Installing the software was easy although I had some initial trouble with the USB drivers – it could detect it and under device the labtool Device was grayed out.  I had to uninstall the previous LPC-Link 2 USB drivers (which had worked OK for me) – it showed it was not installed correctly or something like that -  it had a small yellow icon in Device manager.  Now it works fine. 7)    Single shot and continuous collection works easier than on my HP.   I thought these could be improved: 1)    The scope selection is called Analog.  I was confused – why not just label it scope ? 2)    I had some difficulty getting a waveform displayed sometimes – I had to fiddle with it. 3)    I was not able to erase a waveform so sometimes I didn’t know if I had  a new one or nothing or ????  Making this part easier to use might be worth it. 4)    I could not make the waveform bigger or shift it up or down (position). 5)    When I clicked on a cursor icon to bring it up into the screen – the waveform shifted and it looked like (to me anyway) to have disappeared.  It was there – It took me a while to figure this out. 6)    CAN is a differential signal but it seemed to work.  A differential input would be nice.  So would a CAN Analyzer. 7)    I had a hard time getting the “DC” to work – “AC” was always better and easier. 😎     The ability to change the waveform colour might be a good idea.   Following are the results of two tests.   CAN on one channel: 1)    500 kHz is correct ! 2)    The waveform (at 80 MHz) is good – the overshoots are not visible on the HP but I didn’t adjust the tiny capacitor screws on the LabTool.  There are more of the resolution errors shown on the rise and fall edge than my HP – but HP still has some.  Not a big deal. Here is the CAN frame using two channels:  Even though I had to reduce the sampling freq to 40 mHz – it still looks good.   The ability to move the waveforms vertically (and maybe a polarity switch) would be nice.     SWO: Very often customers must measure the frequency on the SWO pin if they can’t get the Serial Wire Viewer (SWV) working and they do not know what their CPU clock is. A scope makes this easy and – LabTool did very good – I think sometimes the SWO pin can go up to 1 mHz and more – but this example at 1.25 worked fine. 1.25MHz as shown here is correct ! I compared all these waveforms to my HP and LabTool did quite well. Massimo Manca wrote:   After some hours of test my feeling is that the digital part works quite well, the I2C, SPI and UART interpreters are useful and well designed. Should be very interesting to have also a CAN interpreter and a 1-Wire interpreter.   Another thing should be useful is to define the priority of the triggers on the digital signals. I mean that should be useful for instance to define the trigger on the UART - D0 line with the highest priority so the other signals will be captured only it is already captured on its trigger front.   I should need to go back to my lab to test better the analog inputs. My feeling is that the signal is not perfect due to some interference by my laptop. Should be interesting to connect a USB isolator between the boards and the PC to see what changes.   The next step will be to test the board freely always using the demo signals without following the example list. I will provide update with the results.   Using the SPI Protocol Analyzer   Lately I’ve been working with one of NXP’s solution kits.  This kit includes an LPC812 Xpresso board and a daughterboard with the SEN300 sensor.  The sensor measures temperature, humidity and light.  It interfaces the microcontroller through a 4-wire SPI bus (SCK, MISO, MOSI, CS) running at 300kHz.   Considering that an end user of this solution kit may want to add another node on the SPI bus, it should be necessary to increase the communication rate from 300kHz to a higher speed, and allow for transfers to/from the additional device using the same SPI peripheral.  Types of SPI devices that could be considered are a simple LCD for displaying the sensor readings, or an EEPROM for data logging.   After I selected new dividers for the SPI master clock to increase the clock rate to 3MHz, the communication interface broke down.  I setup the LabTool digital interfaces D0 to D3 and configured the SPI protocol analyzer to use these for the corresponding SPI signals.  Following are some screen shots and the conclusion of the problem.   Normally the communication seemed to be occuring just fine.  I noticed that the chip select signal (Digital 3) was active low outside the boundaries of the waveform view in the LabTool GUI. From time to time, actually more often than not, the SPI analyzer could not interpret the transfer data, and showed “Frame Error” was occurring.   By changing the trigger to the rising edge of the chip select, I could see this occurring more frequently.  At that time, the chip select signal was momentarily toggling high/idle and then low/active in the middle of a data transfer.   I began stepping through the code to find the routines that set and cleared the state of the chip select (a simple digital output port).   I found that the routine that handles the SPI transmit/receive buffers could get out of sync with the function controlling the chip select output, and cause message transfers to overlap.  By adding some simple logic to ensure the chip select was not idled before the SPI buffers were serviced, the problem went away.  Here is a screen shot of a good SPI transfer at the higher SCK rate.   Using LabTool and the SPI protocol analyzer feature, I was able to identify the problem in the communication interface, and then use a debugger to finish checking the root cause.   Using LabTool to evaluate Rotary Encoder and QEI peripheral   Motor control applications often use the feedback from a rotary encoder in a closed loop control system.  The LPC4370 microcontroller includes a QEI peripheral (Quadrature Encoder Interface) that decodes these signals directly.  By monitoring both the number of pulses and the relative phase of the two signals, you can track the position, direction of rotation, and velocity.  In this example, we’ve measured the QEI signal sequence with LabTool.  The type of Rotary Encoder used in this project is SXA-4EG05E1024BM with 1024 pulses per round.   The encoder ouputs A,B and Zero terms. So we connect the encoder with LabTool through DIO0~DIO2. LabTool should also be connected with the Encoder’s gound pin to ensure they share a common gound.  Use one of the available grounding probes on the 26-pos connector (e.g. probe #4), to make this connection.   DIO0 -> A Term   DIO1-> B Term   DIO2-> Zero   Open the LabTool application program on your PC, and connect the LabTool using the USB connection. The GUI will show that LabTool is connected when the text "LabTool Device" changes from red to black text.  Now, you can click the “Add Signal” button and choose D0, D1 & D2 digital signals as below picture shows. We’ll rotate the Encoder by hand, so we set the “Sample Rate” as 100kHz.   Set the D2 Digital capture on rising edge.   Click the “Capture->Continuous” or button to start sampling the digital input channels.  When we rotate the Encoder, the signal capture below is displayed with LabTool. We can move the triggers C1&C2, C3&C4 to measure the signal’s frequency and duty cycle.   If we want to measure a whole cycle from the Encoder, we can set the “Sample Rate” as 50Mhz, then rotate the Encoder and capture the entire waveform shown next. LabTool's logic analyzer feature is very powerful and useful for motor control applications measurng the feedback from a rotary encoder.   Investigating I2C/SMBus issue using LabTool   One of our customers is designing-in the NXP Microcontroller in a SAS (Serially Attached SCSI) Server system. This controller is used to manage the overall backplane activities and interfaces to the host SAS Controller on SMBUS/I2C Bus. The customer was facing major issue of I2C Bus hanging.  As such, it was difficult to diagnose the issue as there were multiple slave devices on the bus. Coincidently, we had this LabTool lying around and I thought of using it in debugging the issue. Initially, I isolated this controller from the I2C bus and hooked it up to another I2C Master. While monitoring the bus activity on the LabTool’s I2C Analyzer, apparently the overall communication was just fine as shown below.   On a closer look, I noticed that the clock (SCL) was getting stretched a bit at times, but nothing unusual. I then connected this controller back in the system and monitored the I2C bus activity on I2C Analyzer again. And no surprise, the bus hanging problem was getting reproduced as seen in the capture below. After the clock stretching interval, the clock (D2=SCL) line was holding it’s status as low and data (D1=SDA) was high. It was clear that the problem appears only when there are multiple slaves connected to a SMBUS/I2C Bus Master. It gave me some direction to think and investigate more on similar lines. Gone through the details of SMBUS/I2C peripheral on SAS Controller and as usual googled for I2C issues with multiple slaves.  Finally got a clue while going through the minute details of SMBus specifications. Though it’s normal to use I2C slaves/devices with SMBus master and vice a versa, there are subtle differences in the specifications. The most vital difference is the Timeout and (as a consequence of timeout) minimum clock speed. There’s no time out in I2C specifications, any device can stretch the Clock as long as it wants. While the SMBus clearly specifies the time out of 35msec, where slave devices resets their interfaces whenever Clock goes low for longer than the timeout. Use of such timeout also dictates a minimum speed for the clock, because it can never go static. Thus, the SMBus has a minimum-clock-speed specification of 10kHz.   To comply with the SMBus specifications Slave devices should have this time out implemented. I then added a small piece of code to generate this timeout using one of the available timers and that resolved the issue. Thanks to the LabTool!   Comparing the LabTool to a commercially available signal analyzer   There are three key features of LabTool that are useful to any developer:   80MHz sample rate using digital inputs D0 to D3 and up to 60MHz for one Analog Input. You can analyze any UART, SPI or I2C communication. You have 4 cursors to measure your signals.   Here is a comparison versus another USB-hosted signal analyzer.  We will call it "AnalyzerB" in this article.   Features and Price: Regarding AnalyzerB, the cheaper option is the product SX at $169.0 USD, it has only 8 digital input/output with a maximum sample rate of 24MHz. The most comparable product will be the AX product with a pricing of $795 USD with also 8 digital input/output with 2 analog oscilloscope inputs but you can capture maximum at 24Msps and only one analog input at any time. The AX product also can analyze CAN, PS/2, SM bus and 1-Wire communication. These options could be added easily to the PC software.   So, the pricing of $129.00 USD for the NXP LabTool is a very good pricing and with the source code available you won't have any limit to customize or improve the LabTool.   Using the Tools: I did a zoom in the PWM signals in order to get a more detail measurement and I will compare these signals measurements with the AnalyzerB tool.     D7 is 2MHz D8 is between 3.33MHz and 5MHz D9 is between 3.33MHz and 2.5MHz D10 is between 1.42MHz and 1.66MHz I had these measurements because the sample rate is at 10MHz and LabTool is using the upper channels. Now I did a measurement using AnalyzerB tool.  It couldn’t read the 12MHz signal (channel 0); the sample rate is at 12MSPS. I had to increase to 24MSPS (MAX) in order to be able to measure the 12MHz signal. The frequency measurement in each signal was exactly 1.5MHz channel 3, 3MHz channel 2, 6MHz channel 1 and 12MHz channel 0 without any variation.   Now, using the LabTool I change the 4 PWM signals to channels 0 to 3 and increase the sample rate up to 100MHz. I had the following:   The frequency in the signals is: D0 is 12.5MHz and 10MHz D1 is 6.25MHz and 5.55MHz D2 is 2.94MHz and 3.12MHz D3 is 1.51MHz and 1.47MHz   The AnalyzerB tool didn’t show any variation in the frequency measurements. It might be because the LabTool has more precision. I went up to 100MHz sample rate and I had the same frequency measurements in each signal. Maybe the AnalyzerB is using some other method to implement an average or it might be over sampling to improve the measurement. I might need to have a third logic analyzer to see what tool is getting a right measurement.   I had some trouble using the LabTool GUI.  For example, I didn't know that LabTool is connected at first since the "LabTool Device" indication was not highlighted.  Also it was difficult to know how to choose the protocol analyzer, so that Combo Box could be improved.  It is clear that the LabTool has more resolution when using the lowest channels. The AnalyzerB tool has only a maximum of 25MSMP for all combinations. So the LabTool has an advantage because it could be 100MHz sample rate in 2 digital channels.   I like the LabTool but it might be a good idea to include test clips for each of the signals because not all the time the target circuit will have pins to plug the actual test points. These test clips will give more functionally to the LabTool.  Also, I would like to have more information about the actual LabTool system if it will be like a reference design for customer, like the source code for the LabTool software and also the firmware for the MCU.   The LabTool could be used for debugging without any issue; I think that the Start Guide should be updated with more detail information to improve the usability.
View full article
Flashing and Installing the new firmware and drivers for LPC11U35 debug probes   We recently released a new set of debug firmware and Windows 7 drivers for our boards that feature the LPC11U3x MCU as a debug probe (so all the "MAX" boards). The new firmware can be found under the Software & Tools tab of the board page or it can download directly from this link:  Firmware and drivers for LPC11U35 debug probes The intention is for this firmware to be used instead of the mbed-based firmware and driver that has been used up until now, if you are not going to use MBED (you can continue to use the MBED version if you so wish however). Some reasons to consider the new firmware & driver: - The CMSIS-DAP implementation is newer, so a little more robust and faster. - The VCOM / serial port driver supports autobaud, with speeds up to 115200. - The VCOM driver has a cleaner installation (mbed serial port driver needs board to be plugged in to install, which is a little unusual). - The firmware auto-detects if a target serial port connection is present and enumerates a driver if they are. - The new firmware gives a unique ID per board, allowing multiple board connections at once. To install the windows drivers follow these steps: 1) Unzip the Firmware and drivers and double click on the LPC11Uxx_Debug_Probe_VCOM_v1.0.0 executable:     2) The installation wizard will show up, click on Next: 3) Choose the install location, the driver is installed by default in C:\Users\[USER]\AppData\Local\NXP Semiconductors\LPC11Uxx_VCOM\ but you can override this: 4) You will be asked to install the drivers, click on Install (These drivers were developed by www.ashling.com and are the intellectual property of NXP): 5) Finally click on Finish: The next step is to update the debug probe (LPC11U3x) firmware: 1) Unplug the usb connector. 2) Hold down the reset button and plug in the usb connector. 3) The board will appear on your system as a disk called CRP DISABLD. 4) Delete the file called firmware.bin on this disk. 5) Drag and drop the new binary image. 6) Connect and re-connect usb, you will have an additional VCOM port shown in Windows Device Manager: Hope it helps! Best Regards, Carlos Mendoza Technical Support Engineer
View full article
First, download the LPCXpresso54608 board User Manual.  After scanning the document, let's get started! Plug in LPCXpresso54608 (as shown below).  You will see the pre-loaded, Out of Box demo, which features Draupner TouchGFX.  A screen shot is shown below, Once you've explored the pre-loaded demo, you will likely want to learn more.   For this you will need to configure and build an  MCUXpresso Software Development Kit (SDK)  for your LPCXpresso54608 development board. Register or use your login credentials to sign in and download software from NXP. You can create a configuration for the LPCXpresso54608 in one of two ways: By typing 'LPCXpresso54608' or selecting boards>LPC>LPCXpresso54608 Once you have selected the board you will be presented with two options: 'Select Configuration' or 'Specify Additional Configuration Settings'. (It is recommended that you name the configuration something that specifies the settings as this will help identify multiple configurations.)   Note: By default the SDK Builder will choose IAR as the default toolchain for Windows.  For this tutorial we will use Windows as our Development Host OS.  If this is not the desired toolchain or OS please 'Select 'Specify Additional Configuration Settings' The following window will be presented, which allows you to download an SDK for IAR, Keil or Both (selecting 'All toolchains'.).  During this stage, you can also specify any necessary middleware for your download.  You can select or deselect these under the 'Select Optional Middleware' Select 'Go to SDK builder' once you have made your choices. Note:You may be prompted to update your info before you are allowed to download the package. If this happens select the link in the red at the top to resolve any issues. Once the information is updated you can click on the 'Overview' at the top and reselect 'SDK Builder' to return to the screen you were on. You have the opportunity to rename your file one last time before you hit download now. Once you select 'Download Now' you will be presented with a license agreement and once agreed to the download will start. Once you have downloaded the packaged .zip use your favorite utility to extract to a known location --> Continue here if IAR is your selected default toolchain. --> Continue here if KEIL is your selected default toolchain. --> Continue here if MCUXpresso is your selected default toolchain (coming March 2017!)
View full article
Dear Community User, We recently migrated content from the LPCWare.com forums into this community site. Migrated content can be found in the following two locations: LPCXpresso IDE for content from the LPCXpresso folder on the LPCWare.com forum, and LPC for all other content. All imported content will appear as posted by "LPCWARE" and will have the following message displayed at the top of each thread with the original username and date posted in LPCWare: If you wish to find the content you created in LPCWare you must: 1.-  Open the search box at the top right side of your community near your avatar. 2.- Type in the username you had set up in LPCWare and the results should automatically appear. All responses to postings in the original LPCWare.com forums are also preserved, so if you are looking for a response you or another particular user posted then you should also be able to locate those responses using the same search mechanism. All FAQs have been migrated to the NXP Community site. Several forum postings include references to FAQs and re-directs are in place to take you to their new location from those postings.
View full article
Introducing MCUXpresso SDK v.2 for LPC54xxx Series What's New in MCUXpresso SDK v.2 for LPC54xxx? The Software Development Kit (SDK) 2.0.0 is a collection of software enablement for microcontrollers that includes peripheral drivers, multicore support, and integrated RTOS support for FreeRTOS OS and μC/OS. In addition to the base enablement, the SDK is augmented with demo applications and driver example projects, and API documentation to help the customers quickly leverage the support of the SDK. Development Tools The MCUXpresso SDK v.2 for LPC54xxx 2.0.0 was compiled and tested with these development tools: - LPCXpresso 8.2.0 - IAR Embedded Workbench for ARM® platform version 7.60.2 - MDK-ARM Microcontroller Development Kit (Keil)® 5.20 Supported Development Systems Development boards MCU devices LPCXpresso54114 LPC54114J256BD64, LPC54114J256UK49, LPC54113J128BD64, LPC54113J256BD64, LPC54113J256UK49 LPCXpresso54608 LPC54605J256ET180, LPC54605J512ET180, LPC54606J256ET180, LPC54606J512BD208, LPC54607J256ET180, LPC54607J512ET180, LPC54607J256BD208, LPC54608J512ET180, LPC54608J512BD208   SDK Board Support Folders SDK board support provides example applications for development and evaluation boards. Board support packages are found inside of the top level boards folder, and each supported board has its own folder (a SDK package can support multiple boards). Within each <board_name> folder there are various sub-folders to classify the type of examples they contain.   demo_apps: Full-featured applications intended to highlight key functionality and use cases of the target MCU. These applications typically use multiple MCU peripherals and may leverage stacks and middleware. driver_examples: Simple applications intended to concisely illustrate how to use the SDK’s peripheral drivers for a single use case. These applications typically only use a single peripheral, but there are cases where multiple are used (for example, ADC conversion using DMA). rtos_examples: Basic FreeRTOS examples showcasing the use of various RTOS objects (semaphores, queues, and so on) and interfacing with the SDK’s RTOS drivers usb_examples: Applications that use the USB host/device/OTG stack. multicore_examples: Applications for both cores showing the usage of multicore software components and the interaction between cores. Example Application Structure This section describes how the various types of example applications interact with the other components in the SDK. To get a comprehensive understanding of all SDK components and folder structure, see the SDK v.2.0 API Reference Manual document (SDK20APIRM). Each <board_name> folder in the boards directory contains a comprehensive set of examples that are relevant to that specific piece of hardware. We’ll discuss the hello_world example (part of the demo_apps folder), but the same general rules apply to any type of example in the <board_name> folder. In the hello_world application folder you see this: All files in the application folder are specific to that example, so it’s very easy to copy-paste an existing example to start developing a custom application based on a project provided in the SDK. Related links: For information on how to import and debug the MCUXpresso SDK example projects using LPCXpresso or generate your MCUXpresso SDK package take a look to this document: How to start with SDK v.2.0 for LPC5411x using LPCXpresso IDE Generating a downloadable MCUXpresso SDK v.2 package https://community.nxp.com/docs/DOC-333369  MCUXpresso Config Tools is now available!  
View full article
Hello community!   Attached is a document that explains how to build and run the LPCOpen Ethernet example projects, it also explains the needed board and PC connections and configurations. The steps described in the document were done using the LPC1769 MCU like the one in the LPCXpresso board for LPC1769 with CMSIS DAP probe, but the same principles are applicable to any LPC MCU. The steps described in this document are valid for the following versions of the software tools: o    LPCXpresso v8.1.4 o    LPCOpen v2.xx Boards o    LPCXpresso board for LPC1769 with CMSIS DAP probe o    EA LPCXpresso BaseBoard o    LPC-Link2 Contents 1. Overview and concepts    1.1    LPCOpen       1.1.1 Core driver library       1.1.2 Middleware       1.1.3 Examples       1.1.4 LPCOpen with an RTOS 2. Running the lwip_tcpecho and webserver demo applications    2.1 Downloading a LPCOpen package    2.3 Setting up the hardware       2.3.1 LPCXpresso board for LPC1769 with CMSIS DAP probe       2.3.2 EA LPCXpresso BaseBoard    2.2 Importing the LPCOpen examples    2.4 Building the demo applications    2.5 Running the demo applications       2.5.1 lwip_tcpecho_sa demo       2.5.2 webserver demo Appendix A - References I hope you can benefit from this post, if you have questions please let me know.   Best Regards! Carlos Mendoza
View full article
This cook book includes lots of interesting examples leveraging LPC MCU's powerful SCT Timer. Have fun using them, creating more and sharing more. #sct‌
View full article
This documet is an introduction about TrustZone on the LPC55S6x devices. LPC55S6x MCU platform and general-purpose blocks The LPC55S69 has one 100-MHz Cortex-M33 core with TrustZone, MPU, FPU, and SIMD and another 100-MHz Cortex-M33 without security features enable. Lets remark that the LPC55Sxx family has another LPC55S66 that only implements a single 100-MHz core. There are two coprocessors on core 0, a DSP accelerator called PowerQuad, and a crypto engine called CASPER. The core platform has a multilayer bus matrix that allows simultaneous execution from both cores and parallel access of the other masters to peripherals and memories. The memory on chip includes up to 640 KB of Flash, up to 320 KB of RAM, and 128 KB of ROM. Timers include 5 - 32-bit timers, a SCTimer/PWM, a multi-rate timer, a windowed watchdog timer, Real Time Clock (RTC), and a micro timer. Each core has its own systick timer. Communication interfaces include a USB high-speed with on-chip HS PHY, a USB full-speed that can run crystal-less, two SDIO interfaces to support WIFI and SD cards at the same time, 1 high-speed SPI with up to 50-MHz clock rate, and 8 Flexcomms with support of up to 8 SPI, I2C, UART, or 4 I2S. The analog system includes a 16-channel 16-bit ADC that samples at 1 MSPS, an analog comparator, 16-channel capacitive touch controller, and a temperature sensor. Other modules include a programmable logic unit, a buck DC-DC converter, operating voltage from 1.71 to 3.6 V over a temperature range from -40 to 105 °C. What is TrustZone? In recent years, the Internet of Things (IoT) has become a hot topic for embedded system developers. IoT system products have become more complex, and better solutions are needed to ensure system security. ARM® TrustZone® technology is a System on Chip (SoC) and CPU system-wide approach to security. The TrustZone® for ARMv8-M security extension is optimized for ultra-low power embedded applications. It enables multiple software security domains that restrict access to secure memory and I/O to trusted software only. TrustZone® for ARMv8-M: Preserves low interrupt latencies for both secure and non-secure domains Does not impose code overhead, cycle overhead or the complexity of a virtualization based solution Introduces efficient instructions for calls to the secure domain with minimal overhead TrustZone® is a technology available in Cortex M23 and Cortex M33. TrustZone® provides the means to implement separation and access control to isolate trusted software and resources to reduce the attack surface of critical components. The created trusted firmware can protect trusted operations and is ideal to store and run the critical security services. The code should also protect trusted hardware to augment and fortify the trusted software. This includes the modules for hardware assists for cryptographic accelerators, random number generators, and secure storage. Best practices demand that that this code be small, well-reviewed code with provisions of security services. The LPC55S66 and LPC55S69 have implemented core 0 as a Cortex-M33 with full TEE and TrustZone® support enabled. The LPC55S69 has a second Cortex-M33 (core 1) that does not implement the secure environment with TZ. Isolation is just the foundation. Security is about layers of protection, adding in further hardware and software to create more layers. Features of TrustZone® technology: Allows user to divide memory map into Secure and Non-Secure regions Allows debug to be blocked for Secure code/data when not authenticated CPU includes Security Attribution Unit (SAU) as well as a duplication of NVIC, MPU, SYSTICK, core control registers etc. such that Secure/Non-Secure codes can have access to their own allocated resources Stack management expands from two stack pointers in original Cortex-M (Main Stack Pointer (MSP) and Process Stack Pointer (PSP)) to four, providing the above pair individually to both Secure and Non-Secure Introduces the concept of Secure Gateway opcode to allow secure code to define a strict set of entry points into it from Non-secure code Secure and non-secure memory TrustZone® technology divides the system into two states, safe (S) and non-secure (NS), and can switch between the two states through corresponding commands. The CPU states can be secure privilege, secure non-privilege, privilege (Handler), or non-privilege (Thread). The Secure memory space is further divided into two types: Secure and Non-secure Callable(NSC). Below are the feature/properties of Trustzone memory regions ( S, NS, NSC 😞 Secure (S) - For Secure code/data − Secure data can only be read by secure code − Secure code can only be executed by CPU in secure mode Non-Secure (NS) – For non-Secure code/data − NS Data can be accessed by both secure state and non-secure state CPU − Cannot be executed by Secure code Non-Secure Callable (NSC) − This is a special region for NS code to branch into and execute a Secure Gateway (SG) opcode. Attribution Units Combination of Security SAU and IDAU assign a specific security attribute  (S, NS, or NSC) to a specific address from the CPU0. Device Attribution Unit (DAU) connects to CPU0 via IDAU interface as show the following Figure. Access from CPU0, dependent on its security status and the resultant security attribute set by the IDAU and SAU, is then compared by the secure AHB Controller to a specific checker which marks various access policies for memory and peripherals. All addresses are either secure or non-secure. The SAU inside of the ARMv8-M works in conjunction with the MPUs. There are 8 SAU regions supported by LPC55S69. Secure and non-secure code runs on a single CPU for efficient embedded implementation. A CPU in a non-secure state can only execute from non-secure program memory. A CPU in a non-secure state can access data from both NS memory only. For the secure, trusted code, there is a new secure stack pointer and stack-limit checking. There are separate Memory Protection Units (MPUs) for S and NS regions and private SysTick timers for each state. The secure side can configure the target domain of interrupts. The NXP IDAU (Implementation specific Device Attribution Unit) implementation of ARM TrustZone for core0 involves using address bit 28 to divide the address space into potential secure and non-secure regions. Address bit 28 is not decoded in memory access hardware, so each physical location appears in two places on whatever bus they are located on. Other hardware determines which kinds of accesses (including non-secure callable) are allowed for any address.  The IDAU is a simple design using address bit 28 to allow aliasing of the memories in two locations. If address bit 28 is = 0 the memory is Non-Secure. If address bit 28 = 1 the memory is Secure. The SAU allows 8 memory regions and allow the user to override the IDAU’s fixed Map, to define the non-secure regions. By default, all memory is set to secure. At least one ASU descriptor should be used to make IDAU effective. If either IDAU or SAU marks a region, then that region is secure. NSC area can be defined in NS region of the IDAU. For example a designer could use bit [28] of the address to define if a memory is Secure or Non-secure, resulting in the following example memory map. Simple IDAU, without creating a critical timing path. (CM33 does allows little for IDAU function) Addresses 0x0000_0000 to 0x1FFF_FFFF are NS, Addresses 0x2000_0000 to 0xFFFF_FFFF If Address Bit_28 = 0  Non-Secure If Address Bit_28 = 1  Secure All peripherals and memories are aliased at two locations. The SAU define region numbers for each of the memory regions. The region numbers are 8-bit, and are used by the Test Target(TT) instruction to allow software to determine access permissions and security attribute of objects in memory. The number of regions that are included in the SAU can be configured to be either 0, 4 or 8. Note: When programming the SAU Non-secure regions, you must ensure that Secure data and code is not exposed to Non-secure applications. Security state changes The system boots in secure state and can change security states using branches as summarized in the following Figure. Transitions from secure to non-secure state can be initiated by software through the use of the BXNS and BLXNS instructions that have the Least Significant Bit (LSB) of the target address unset. Note: The M profile architecture does not support the A32 instruction set. This allows the LSB of an address to denote the security state. Transitions from non-secure to secure state can be initiated by software in two ways: A branch to a secure gateway. A branch to the reserved value FNC_RETURN. A secure gateway is an occurrence of the Secure Gateway instruction (SG) in  the Non-Secure Callable (NSC) region. When branching to a secure gateway from non-secure state, the SG instruction switches to the secure state and clears the LSB of the return address in lr. In any other situation the SG instruction does not change the security state or modify the return address. A branch to the reserved value FNC_RETURN causes the hardware to switch to secure state, read an address from the top of the secure stack, and branch to that address. The reserved value FNC_RETURN is written to lr when executing the BLXNS instruction. Security state transitions can be caused by hardware through the handling of interrupts. Those transitions are transparent to software and are ignored in the remainder of this document. The TT instruction The ARMv8-M architecture introduces the Test Target instruction (TT). The TT instruction takes a memory address and returns the configuration of the Memory Protection Unit (MPU) at that address. An optional T flag controls whether the permissions for the privileged or the unprivileged execution mode are returned. When executed in the secure state the result of this instruction is extended to return the Security Attribution Unit (SAU) and Implementation Defined Attribution Unit (IDAU) configurations at the specific address. The MPU is banked between the two security states. The optional A flag makes the TT instruction read the MPU of the non-secure state when the TT instruction is executed from the secure state. The TT instruction is used to check the access permissions that different security states and privilege levels have on memory at a specified address. You can find more useful information about ARM® TrustZone® , in the following links: https://developer.arm.com/ip-products/security-ip/trustzone https://www.nxp.com/docs/en/application-note/AN12278.pdf http://www.keil.com/appnotes/files/apnt_291.pdf  http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/ECM0359818_armv8m_security_extensions_reqs_on_dev_tools_1_0.pdf
View full article
This is a quick introduction that shows how to interface the LPC845 Breakout Board with an OLED display based on the popular SSD1306 controller, using SDK drivers for SPI. With this application, you can print a text string or draw a bitmap image.   SPI Protocol The Serial Peripheral Interface (SPI) protocol is asynchronous serial data standard, primarily used to allow a microprocessor to communicate with other microprocessors or ICs such as memories, liquid crystal diodes (LCD), analog-to-digital converter subsystems, etc.   The SPI is a very simple synchronous serial data, master/slave protocol based on four lines:       • Clock line (SCLK)       • Serial output (MOSI)       • Serial input (MISO)       • Slave select (SS)   Adafruit Monochrome OLED Graphical Display This display is made of 128x64 individual white OLED pixels, each one is turned on or off by the controller chip. Because the display makes its own light, no backlight is required. This reduces the power required to run the OLED and is why the display has such high contrast; we really like this miniature display for its crispness !     OLED Display Example NXP provides an example package for the LPC845 Breakout that  includes projects to use the principal's peripherals that the board include: ADC, I2C, PWM, USART, Captouch, and SPI   What we need: LPC845 Breakout Board MCUXpresso IDE V10.3.0 SDK_2.5.0_LPC845 NXP example package OLED Display from Adafruit (also available via NXP distributors) LCD assistant software to convert bitmaps Micro USB cable   Once downloaded, we import the library project into the workspace using the ''Import project(s) from file system... from the Quickstart panel in MCUXpresso IDE: Figure 1. Import Projects.   Then browse the examples packages archive file: Figure 2. Select Example Package.   Press next, and see that are a selection of projects to import, in this case, only keep select the LPC845_BoB_OLED how it looks in the picture below: Figure 3. Select the OLED Project.   Press finish and the project example shows up in the workspace: Figure 4. OLED Project in workspace. Create Bitmaps Bitmap (BMP) is an image file format that can be used to create and store computer graphics. A bitmap file displays a small dots in a pattern that, when viewed from afar, creates an overall image. A bitmap image is a grid made of rows and columns where a specific cell is given a value that fills it in or leaves it blank, thus creating an image out of the data. First, you have to create the image using any kind of graphics software such a paint, Photoshop, etc and save the picture as Monochrome Bitmap (bmp), make sure that the image size match whit the OLED size.       Figure 5. Save picture as Bitmap.   Now inside the LCD software assistant, this program will help us to convert an image from Bitmap to data array, we have to load the image by click on file >> load image, and select the appropriate size.   Figure 6. LCD Assistant    To import the array go to file >> save the output, choose the place where are going to save. Then inside the example, go to fsl_Font5x7.h and paste the array.   Figure 7. Data Array.      *Note: Inside the example, the array for the NXP logo is already there, if you want another image, delete this array and pas the new.   Connections Now, with the project already in the workspace, it is time to set up the connection between the LPC845 Breakout board and the OLED Display. The table below shows which LPC845 Breakout pin are routed each line of the SPI interface and the pins for reset and Data/Command select.   Table 1. Connections.   You can check the Datasheet of the board, of bases on the picture below to see where the pin are, note that GND and 3.3V also needed for the OLED display: Figure 8. LPC845 Breakout to OLED Connection.   Debug. Now, with the demo in the workspace and the connections done, connect a micro USB cable from connector CN2 to a host computer and debug the application.   Figure 9. Run example
View full article
The following document contains a list of documents, questions and discussions that are relevant in the community based on the amount of views they are receiving each month. If you are having a problem, doubt or getting started in LPC or MCUXpresso you should check the following links to see if your doubt have been already solved in the following documents and discussions. MCUXpresso MCUXpresso Supported Devices Table  FAQ: MCUXpresso Software and Tools  How to create a new LPC project using LPCOpen and MCUXpresso IDE  Introducing MCUXpresso SDK v.2 for LPC54xxx Series  Generating a downloadable MCUXpresso SDK v.2 package  Using the MCUXpresso Pins Tool   MCUXpresso Config Tools is now available!   LPC55xx Multicore Applications with MCUXpresso IDE  LPC information LPC5460x MCU Family Overview  USB with NXP Microcontrollers LWIP memory requirements  LPC800 Four-Part Webinar Series!  The LPC804 Programmable Logic Unit (PLU)   LPC84x Technical Training - Now Available Guides and Examples Flashing and Installing the new firmware and drivers for LPC11U35 debug probes  Enabling debug output  USB FLASH download, programming, and security tool (DFUSec)  DMA Ping-Pong application  Getting start with LPCXpresso54608 &amp; emWin Graphics;  Capacitive Touch example using the LPC845 Breakout Board  OLED Display Application Example using LPC845 Breakout Board and SPI  Mixed-Signal Logic Analyzer &amp; Oscilloscope (Lab Tool) Solution  LPC FAQ How to calculate the value of crystal load capacitors? Can I send a message with X/Y/Z bits in the ID?  What is the difference between error active and error passive? What is the sample point for?  How can I verify the configured CAN bitrate, using an oscilloscope? 
View full article
This blog posting is an introduction to Capacitive Touch provided for the LPC845 MCU device. We are going to take advantages of the features that the LPC845 Breakout Board to show how to interface with the onboard Cap touch button using SDK drivers.    The Capacitive Touch module measures the change in capacitance of an electrode plate when an earth-ground connected object (for example, the finger or stylus) is brought within close proximity. Simply stated, the module delivers a small charge to an X capacitor (a mutual capacitance touch sensor), then transfers that charge to a larger Y capacitor (the measurement capacitor), and counts the number of iterations necessary for the voltage across the Y capacitor to cross a predetermined threshold.   Figure 1. Mutual Capacitive Touch   A pulse is applied between the transmitting and receiving electrode to generate an electromagnetic field. When a finger comes into close proximity, part of the electromagnetic field moves to the finger where the decrease in electromagnetic field strength is detected by the electrodes. The capacitance is detected and captured and recognized as a finger presence.   LPC845 MCU Capactive Touch Features Up to nine mutual-capacitance touch sensors. Both GPIO port pin and analog comparator measurement methods are available. DMA for continuous sequential polling of all sensors with no CPU intervention. Wake up from sleep, deep-sleep, and power-down modes.   Advantages Cap-touch interfaces can be incorporated into products with curved surfaces allowing for greater design flexibility. No moving parts allow for increased durability and reduce the number of components, thus lowering overall costs. Provides a smooth, sleek appearance without raised surfaces or button openings allowing for ease of cleaning and sealed designs. Can be a complete plug-and-play interface or simply a graphic bonded to a cap-touch circuit that interfaces with the microcontroller.   Pin usage The Capacitive Touch module uses one standard GPIO pin for YL and up to nine standard GPIOs for X0 through XMAX.    YH, YL, and X functions are typically enabled on their pins using the switch matrix or IOCON, depending on the product family. Additionally, the set of X pins that the application will use must be enabled or identified to the module by writing ‘1’s to their bit positions in the XPINSEL field of the control register.   Registers Programming of all these registers is performed only during initialization.   Table 1. Capacitive Touch Registers. Capacitive Touch with the LPC845 Breakout Board.   The LPC845 Breakout Board include an on-board Cap Touch button that enables easy evaluation of the capacitive touch features of the LPC84x family of devices.   The connections for the capacitive touch button are shown in Table 2 below. If the Cap Touch button is not being used, the ports connected to it can be used for other purposes (such as GPIO), but note that PIO0_30 and PIO0_31 are effectively shorted together through resistor R19. If this zero ohm resistor may be removed if the Cap Touch button is not required.   Table 2. Capacitive touch button signals   Capacitive Touch Example    What we need: LPC845 Breakout Board MCUXpresso IDE V10.3.0 SDK_2.5.0_LPC845 NXP example packages Micro USB cable   The NXP example package includes projects to use the principal's peripherals that the board includes: ADC, I2C, PWM, USART, Captouch, and SPI.  We are going to use the Captouch example include here, this after an initial calibration, once the cap touch button is touched, the RGB's Red led will turn on.   Once downloaded, we import the library project into the workspace using the ''Import project(s) from file system... from the Quickstart panel in MCUXpresso IDE:   Figure 2. Import Projects.   Then browse the examples packages archive file:   Figure 3. Select Example Package.   Press next, and see that are a selection of projects to import, in this case, only keep select the LPC845_BoB_CAPTouch how it looks in the picture below:   Figure 4. Select CapTouch Project   Now with the project in the workspace, we are going to build and run the example, you are going to see instructions in the IDE console for the calibration. Put your finger in the captouch button and press enter to start the calibration, once finished, you are going to see a message, and with that the demo is ready, you are going to see the RGB red led on when the when the cap touch button is touched and off then it´s not.
View full article