SCTimer implement traffic signal Overview      The State Configurable Timer (SCTimer/PWM) is a peripheral that is unique to NXP Semiconductors. It can operate like most traditional timers, but also adds a state machine to give it a higher degree of configurability and control, in another word, the SCTimer/PWM can be considered as consist of Stand Timer and State/Event Logic (Fig 1). This allows the SCT to be configured as multiple PWMs, a PWM with dead-time control, and a PWM with reset capability, in addition to many other configurations that can’t be duplicated with traditional timers. Once the SCTimer/PWM has been configured, it can run autonomously from the microcontroller core, unless the SCTimer/PWM interrupt has been enabled which requires the core to service the interrupt. Fig 1       The first time you look at the SCTimer/PWM, it may appear to be a very complex peripheral, but you will see that it is actually not that difficult to use. Understanding the Event and State is critical to understanding the SCTimer/PWM.        Event:        The following conditions define possible events: a counter match condition, an input (or output) condition, a combination of a match and/or an input/output condition in a specified state, and the count direction. Events can control outputs, interrupts, DMA requests and the SCTimer/PWM states. They can also cause timer limit, halt, start, or stop conditions to occur.        State:         The state variable is the main feature that distinguishes the SCTimer/PWM from other counter/timer/PWM blocks. Events can be made to occur only in certain states. Events, in turn, can perform the following actions: a)    Set and clear outputs; b)   Limit, stop, and start the counter; c)    Cause interrupts; d)   Modify the state variable;         Regarding the event and state mechanism (Fig 2 show a basic example), The SCT allows the user to group and filter events, thereby selecting some events to be enabled together while others are disabled. A group of enabled and disabled events can be described as a state, and several states with different sets of enabled and disabled events are allowed. Changing from one state to another is event driven as well and can happen without software intervention. Formally, the SCTimer/PWM can be programmed as state machine generator. The ability to perform switching between groups of events provides the SCT the unique capability to be utilized as a highly complex State Machine engine. Events identify the occurrence of conditions that warrant state changes and determine the next state to move to. This provides an extremely powerful control tool - particularly when the SCT inputs and outputs are connected to other on-chip resources (comparators, ADC triggers, other timers etc.) in addition to general-purpose I/O. Fig 2 Traffic signal implementation             Fig 3 illustrates the application of the SCT to simulate the traffic signal. Fig 3 v Demo create         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. In this article, I will illustrate the steps of creating a new demo in the LPCOpen, for instance, create a demo by using the IAR IDE. Since the selected hardware board is the LPCXpresso824, the creating work is based on the corresponding LPCOpen.              Creates a new project Fig 4   2.    Create the example and lib groups, then add the startup and board initialization files under the example group and add the library files: board_nxp_lpcxpresso_824.a and chip_82x_lib.a under the lib group. Next, create a main.c file: traffic_signal_demo.c. Fig 5 3.     Add the corresponding paths $PROJ_DIR$\..\..\..\..\..\..\software\lpc_core\lpc_chip\chip_8xx\config_82x $PROJ_DIR$\..\..\..\..\..\..\software\lpc_core\lpc_chip\chip_common $PROJ_DIR$\..\..\..\..\..\..\software\lpc_core\lpc_chip\chip_8xx $PROJ_DIR$\..\..\..\..\..\..\software\lpc_core\lpc_board\board_common $PROJ_DIR$\..\..\..\..\..\..\software\lpc_core\lpc_board\boards_8xx\nxp_lpcxpresso_824                $PROJ_DIR$\..\..\..\..\..\..\software\CMSIS\CMSIS\Include 4.     Miscellaneous settings For instance, target selecting, adds the linker file, add other c files (Fig 6),etc. Fig 6   v Crucial code                                                          Table 1 main.c /**  * @brief             Application main program  * @return          Nothing (This function will not return)  */ int main(void) {                 /* Generic Initialization */                 SystemCoreClockUpdate();                   /*Set system clock div as 30*/                 Chip_Clock_SetSysClockDiv(30);                                 /*Assign SCT_out to board LED pin*/                 Chip_SWM_MovablePinAssign(SWM_SCT_OUT1_O, 13); // assign SCTOUT_0 to P0_13 YELLOW_LED                 Chip_SWM_MovablePinAssign(SWM_SCT_OUT2_O, 27); // assign SCTOUT_0 to P0_27 GREEN_LED                 Chip_SWM_MovablePinAssign(SWM_SCT_OUT0_O, 17); // assign SCTOUT_0 to P0_17 RED_LED                                 /* Initialize the SCT clock and reset the SCT */                 Chip_Clock_EnablePeriphClock(SYSCTL_CLOCK_SCT);                 Chip_SYSCTL_PeriphReset(RESET_SCT);                   /*Initialize SCT*/                 sct_fsm_init();                   /* Start the SCT counter by clearing Halt_L in the SCT control register */                 Chip_SCT_ClearControl(LPC_SCT, SCT_CTRL_HALT_L);                /* Enter sleep mode */                 while (1) {                                 __WFI();                 } }                                                     Table 2 sct_fsm_init(void) void sct_fsm_init (void) { /*The SCT operates as a unified 32-bit counter*/ LPC_SCT->CONFIG = (LPC_SCT->CONFIG & ~0x00060001) | 0x00000001; /* UNIFIED */   /* MATCH/CAPTURE registers */ LPC_SCT->REGMODE_L = 0x00000000;           LPC_SCT->MATCH[0].U = entry_mat;             /* entry_match */ LPC_SCT->MATCHREL[0].U = entry_mat; LPC_SCT->MATCH[1].U = flash;                       /* flash_mat0 */ LPC_SCT->MATCHREL[1].U = flash; LPC_SCT->MATCH[2].U = flash1;                    /* flash_mat1 */ LPC_SCT->MATCHREL[2].U = flash1; LPC_SCT->MATCH[3].U = delay;                     /* match0 */ LPC_SCT->MATCHREL[3].U = delay; LPC_SCT->MATCH[4].U = yel_delay;              /* yel_delay_mat */ LPC_SCT->MATCHREL[4].U = yel_delay; LPC_SCT->MATCH[5].U = yel_flash;               /* yel_flash_mat */ LPC_SCT->MATCHREL[5].U = yel_flash;   /* OUTPUT registers */ /*Event 1 set the output*/ LPC_SCT->OUT[5].SET = 0x00000002;        /* out_track */ /*Event 3 clear the output*/ LPC_SCT->OUT[5].CLR = 0x00000008; /*Event 0 and 3 set the output*/ LPC_SCT->OUT[2].SET = 0x00000009;        /* turn_green */ /*Event 7 clear the output*/ LPC_SCT->OUT[2].CLR = 0x00000080; /*Event 1 set the output*/ LPC_SCT->OUT[0].SET = 0x00000002;        /* turn_red */ /*Event 0 and 6 clear the output*/ LPC_SCT->OUT[0].CLR = 0x00000041; /*Event 0, 2, 4, 5, 6 and 7 set the output*/ LPC_SCT->OUT[1].SET = 0x000000F5;        /* turn_yellow */ /*Event 1, 3, 4, 5 set the output*/ LPC_SCT->OUT[1].CLR = 0x0000003A;   /* Unused outputs must not be affected by any event */ LPC_SCT->OUT[3].SET = 0; LPC_SCT->OUT[3].CLR = 0; LPC_SCT->OUT[4].SET = 0; LPC_SCT->OUT[4].CLR = 0;   /* Conflict resolution register */ LPC_SCT->RES = (LPC_SCT->RES & ~0x0000000C) | 0x0000000C;   /*  Set COMBMODE = 0x1. Event 0 uses match condition only.  Set MATCHSEL = 0x0. Select match value of match register 0. The match value of MAT0 is associated with event 0 Set STATEV bits to 1 and the STATED bit to 1. Event 0 changes the state to state 1 */ LPC_SCT->EV[0].CTRL = 0x0000D000;     /* U: --> state RED */ LPC_SCT->EV[0].STATE = 0x00000001; /*  Set COMBMODE = 0x1. Event 1 uses match condition only.  Set MATCHSEL = 0x3. Select match value of match register 3. The match value of MAT3 is associated with event 1 Set STATEV bits to 2 and the STATED bit to 1. Event 1 changes the state to state 2 */ LPC_SCT->EV[1].CTRL = 0x00015003;     /* U: --> state YELLOW */ LPC_SCT->EV[1].STATE = 0x00000002; /*  Set COMBMODE = 0x1. Event 1 uses match condition only.  Set MATCHSEL = 0x4. Select match value of match register 4. The match value of MAT4 is associated with event 2 Set STATEV bits to 4 and the STATED bit to 1. Event 1 changes the state to state 4 */ LPC_SCT->EV[2].CTRL = 0x00025004;     /* U: --> state YELLOW_FLASH */ LPC_SCT->EV[2].STATE = 0x00000004; /*  Set COMBMODE = 0x1. Event 1 uses match condition only.  Set MATCHSEL = 0x3. Select match value of match register 3. The match value of MAT3 is associated with event3 Set STATEV bits to 2 and the STATED bit to 1. Event 1 changes the state to state 2 */   LPC_SCT->EV[3].CTRL = 0x00015003;     /* U: --> state YELLOW */ LPC_SCT->EV[3].STATE = 0x00000008; /*  Set COMBMODE = 0x3. Event 6 uses when match and I/O condition occur.  Set MATCHSEL = 0x5. Select match value of match register 5. Set OUTSEL = 1. Select output. Set IOSEL = 5. Select output 5. Set IOCOND = 0x0. Output 0 is Low The match value of MAT5 is associated with event 6 Set STATEV bits to 1 and the STATED bit to 1. Event 1 changes the state to state 1 */ LPC_SCT->EV[6].CTRL = 0x0000F165;     /* U: --> state RED */ LPC_SCT->EV[6].STATE = 0x00000010; /*  Set COMBMODE = 0x3. Event 6 uses when match and I/O condition occur.  Set MATCHSEL = 0x5. Select match value of match register 5. Set OUTSEL = 1. Select output. Set IOSEL = 5. Select output 5. Set IOCOND = 0x3. Output 0 is High The match value of MAT5 is associated with event 7 Set STATEV bits to 3 and the STATED bit to 1. Event 7 changes the state to state 3 */ LPC_SCT->EV[7].CTRL = 0x0001FD65;     /* U: --> state GREEN */ LPC_SCT->EV[7].STATE = 0x00000010; /*  Set COMBMODE = 0x1. Event 1 uses match condition only.  Set MATCHSEL = 0x1. Select match value of match register 1. The match value of MAT1 is associated with event4 Set STATEV bits to 4 and the STATED bit to 1. Event 1 changes the state to state 4 */ LPC_SCT->EV[4].CTRL = 0x00025001;     /* U: --> state YELLOW_FLASH */ LPC_SCT->EV[4].STATE = 0x00000010; /*  Set COMBMODE = 0x1. Event 1 uses match condition only.  Set MATCHSEL = 0x2. Select match value of match register 2. The match value of MAT2 is associated with event5 Set STATEV bits to 4 and the STATED bit to 1. Event 1 changes the state to state 4 */ LPC_SCT->EV[5].CTRL = 0x00025002;     /* U: --> state YELLOW_FLASH */ LPC_SCT->EV[5].STATE = 0x00000010;   /* STATE registers */ LPC_SCT->STATE_L = 0;   /* state names assignment: */   /* State U 0: U_ENTRY */   /* State U 1: RED */   /* State U 2: YELLOW */   /* State U 3: GREEN */   /* State U 4: YELLOW_FLASH */   /* CORE registers */ LPC_SCT->START_L = 0x00000000; LPC_SCT->STOP_L =  0x00000000; LPC_SCT->HALT_L =  0x00000000; /* Event0, 1, 2, 3, 6 and 7 reset the counter register */ LPC_SCT->LIMIT_L = 0x000000CF; LPC_SCT->EVEN =    0x00000000; LPC_SCT->DMAREQ0 = 0x00000000; LPC_SCT->DMAREQ1 = 0x00000000;   } v Result demonstrate          The demo runs on the LPCXpresso824-MAX board, and using the Blue led replaces the Yellow led, and the video shows the demo working. Fig 7 LPCXpresso824-MAX board Video's link: SCTimer implement traffic signal - YouTube 

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

Hello community!   Attached is a document that explains the steps to use LPCXpresso with the LPCOpen projects for your preferred device and platform. The steps described in the document were done using the LPC54102 MCU like the one in the LPCXpresso Board for the LPC54100 family of MCUs, 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 v3.xx 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 Using LPCOpen with an RTOS 2. Running the demo applications    2.1 Downloading a LPCOpen package    2.2 Importing the LPCOpen examples    2.3 Building and debugging blinky project Appendix A - References I hope you can benefit from this post, if you have questions please let me know.   Best Regards! Carlos Mendoza

1 Abstract       MCB1700 is the evaluation board from KEIL, the onboard chip is LPC1758, LPC1768 or LPC1769 which is based on ARM cortex-M3.       EmWin is the embedded graphics library developed by SEGGER, it is now offered by NXP in library form for free commercial use with NXP microcontrollers. The software bundle offered by NXP includes the emWin Color basic package, the Window Manager/Widgets module including the GUIBuilder, the Memory Devices module for flicker-free animation, the Antialiasing module for smooth display of curves, lines and fonts, the Font Converter and the VNC Server.        NXP have provided the MCB1700 emWin board support packages: emWin 5.14 BSP version 1.0 for MCB1700  This package includes three IDE project: IAR, MDK and LPCXpresso, but now, when customer use it, normally will find these questions: LPCXpresso project have the build error MDK project have the build error Some MCB1700 boards can’t work after downloading this code, LCD always display white, no other pictures.     This document is mainly talking about these three problems and give the according solutions to make the MCB1700 emWin_mcb1700_bsp work. 2 Code issue analysis and solutions      Customer need to download the emWin_mcb1700_bsp at first from the above link, and install it, after the package is installed in default, the source code can be found in this path: C:\nxp\emWin\NXP_emWin514_MCB1700_BSP 2.1 keil project build error       This chapter mainly describe the emWin_mcb1700_bsp keil project build error and it’s solutions. 2.1.1 Problem reproduction       Open the emWin_mcb1700_bsp keil project with keil IDE, you may find there has 6 errors like the following picture: All these errors are related to the GUI function which is included in the emwin lib, after click the GUI folder, you will find the lib is emWin_514 which is the old emWin lib. So people can try to use the newest lib from the nxp website. 2.1.2 Problem solution     Download the newest emWin lib from this link:    emwin 5.30 Pre-Compiled Libraries for NXP ARM MCUs    After install it, copy emWin_M3.lib from folder: NXP_emWin530\emWin_library\Keil\ to NXP_emWin514_MCB1700_BSP\GUI folder. Then add this new lib to the KEIL project’s GUI folder like this:    After the emWin_M3.lib is added, remove the build of old lib emWin_514_Keil4_M3_LE.lib, just deselect item include in Target build in the right click options like this: Save and rebuild it again, you will find the error is disappeared. 2.2 LPCXpresso project build error     This chapter mainly describe the emWin_mcb1700_bsp LPCXpresso project build error and it’s solutions. 2.2.1 LPCXpresso project problem reproduction Open LPCXpresso project, and build it, you may find these problems:     All the errors are C/C++ Problem. 2.2.2 LPCXpresso project problem solution     Choose project->properties, change the language standard to GNU C90 stand like this:   Click button “ Apply”,  then rebuild it again, you will find the error is disappeared: Of course, you also can change the lib to the newest one, just like the method in the KEIL project, use the newest LPCXpresso emWin lib from this folder:  NXP_emWin530\emWin_library\LPCXpresso\libemWin_M3.a   2.3 Code function problem in some MCB1700 board      This part is mainly taking about the function problem in some MCB1700 boards, give the analysis and the according solutions. 2.3.1 Code function problem reproduction       After the build problem is solved, customer can download the code to the MCB1700 board by debugger or programmer, no matter with LPC1758, LPC1768 or LPC1769. After testing some MCB1700 boards, we found some board always display white, the emwin function doesn’t work, but some board can display the correct picture. All these boards seems the same.       I have compared these boards carefully, I found the series number in the LCD have difference, now I list it as follows:   MCB LCD Series number RESULT MCB1758 A774A-43-P101210-4072 OK MCB1758 A774A-61-P120814-4074 Abnormal, LCD display white MCB1769 A774A-22-P120814-4074 Abnormal, LCD display white MCB1769 A774A-57-P120814-4074 Abnormal, LCD display white      From the above form, we can find all the MCB boards which can’t work have one feature: the LCD series number contains P120814, so it should be related to the LCD controller, but what the controller on these MCB1700 boards? After download the LCD_Blinky code from the KEIL IDE install path: C:\Keil_v5\ARM\Boards\Keil\MCB1700\LCD_Blinky I found this project can display the picture correctly, so I do the debugging and the source code checking, after that I get the LCD with P120814 is using the HX8347-D LCD controller which from Himax company. But the LCD diver code in emWin MCB1700 BSP is for SPFD5408 LCD controller.   2.3.2 Code function problem solutions     Here take MDK project as an example, describe how to modify the emWin_MCB1700_BSP code and make it work in those not working MCB1700 boards. After the analysis in the above chapter, you will get that the main problem is caused by the LCD driver, so the code modification is mainly about the LCDConf.c file, this code in this file is for the LCD driver configuration. 2.3.2.1 Modify the display orientation     Comment the old DISPLAY_ORIENTATION definition, and define it like this: //#define DISPLAY_ORIENTATION (GUI_SWAP_XY) #define DISPLAY_ORIENTATION (GUI_MIRROR_X | GUI_SWAP_XY)   2.3.2.2 Modify the LCD controller initialization code From chapter 2.3.1, we can get the LCD on the not working MCB1700 board is HX8347-D, the HX8347 LCD controller initialization code should be modified like this: static void _InitController(void) { #ifndef WIN32     GUI_X_Delay(10);   LCD_X_SPI_Init();   GUI_X_Delay(10);     /* Driving ability settings ------------------------------------*/     wr_reg(0xEA, 0x00);       /* Power control internal used (1)    */     wr_reg(0xEB, 0x20);       /* Power control internal used (2)    */     wr_reg(0xEC, 0x0C);       /* Source control internal used (1)   */     wr_reg(0xED, 0xC7);       /* Source control internal used (2)   */     wr_reg(0xE8, 0x38);       /* Source output period Normal mode   */     wr_reg(0xE9, 0x10);       /* Source output period Idle mode     */     wr_reg(0xF1, 0x01);       /* RGB 18-bit interface ;0x0110       */     wr_reg(0xF2, 0x10);             /* Adjust the Gamma Curve --------------------------------------*/     wr_reg(0x40, 0x01);     wr_reg(0x41, 0x00);     wr_reg(0x42, 0x00);     wr_reg(0x43, 0x10);     wr_reg(0x44, 0x0E);     wr_reg(0x45, 0x24);     wr_reg(0x46, 0x04);     wr_reg(0x47, 0x50);     wr_reg(0x48, 0x02);     wr_reg(0x49, 0x13);     wr_reg(0x4A, 0x19);     wr_reg(0x4B, 0x19);     wr_reg(0x4C, 0x16);       wr_reg(0x50, 0x1B);     wr_reg(0x51, 0x31);     wr_reg(0x52, 0x2F);     wr_reg(0x53, 0x3F);     wr_reg(0x54, 0x3F);     wr_reg(0x55, 0x3E);     wr_reg(0x56, 0x2F);     wr_reg(0x57, 0x7B);     wr_reg(0x58, 0x09);     wr_reg(0x59, 0x06);     wr_reg(0x5A, 0x06);     wr_reg(0x5B, 0x0C);     wr_reg(0x5C, 0x1D);     wr_reg(0x5D, 0xCC);       /* Power voltage setting ---------------------------------------*/     wr_reg(0x1B, 0x1B);     wr_reg(0x1A, 0x01);     wr_reg(0x24, 0x2F);     wr_reg(0x25, 0x57);     wr_reg(0x23, 0x88);       /* Power on setting --------------------------------------------*/     wr_reg(0x18, 0x36);       /* Internal oscillator frequency adj  */     wr_reg(0x19, 0x01);       /* Enable internal oscillator         */     wr_reg(0x01, 0x00);       /* Normal mode, no scrool             */     wr_reg(0x1F, 0x88);       /* Power control 6 - DDVDH Off        */     GUI_X_Delay(200);     wr_reg(0x1F, 0x82);       /* Power control 6 - Step-up: 3 x VCI */     GUI_X_Delay(50);                     wr_reg(0x1F, 0x92);       /* Power control 6 - Step-up: On      */     GUI_X_Delay(50);     wr_reg(0x1F, 0xD2);       /* Power control 6 - VCOML active     */     GUI_X_Delay(50);       /* Color selection ---------------------------------------------*/     wr_reg(0x17, 0x55);       /* RGB, System interface: 16 Bit/Pixel*/     wr_reg(0x00, 0x00);       /* Scrolling off, no standby          */       /* Interface config --------------------------------------------*/     wr_reg(0x2F, 0x11);       /* LCD Drive: 1-line inversion        */     wr_reg(0x31, 0x00);     wr_reg(0x32, 0x00);       /* DPL=0, HSPL=0, VSPL=0, EPL=0       */       /* Display on setting ------------------------------------------*/     wr_reg(0x28, 0x38);       /* PT(0,0) active, VGL/VGL            */     GUI_X_Delay(200);     wr_reg(0x28, 0x3C);       /* Display active, VGL/VGL            */   //  wr_reg(0x16, 0x00);       /* Mem Access Control (MX/Y/V/L,BGR)  */       /* Display scrolling settings ----------------------------------*/     wr_reg(0x0E, 0x00);       /* TFA MSB                            */     wr_reg(0x0F, 0x00);       /* TFA LSB                            */     wr_reg(0x10, 320 >> 8);   /* VSA MSB                            */     wr_reg(0x11, 320 & 0xFF); /* VSA LSB                            */     wr_reg(0x12, 0x00);       /* BFA MSB                            */     wr_reg(0x13, 0x00);       /* BFA LSB                            */ #endif }   2.3.2.3 Modify the LCD_X_Config configuration    From the emWin display drivers website in the Segger: https://www.segger.com/emwin-display-drivers.html You can find the HX8347 display driver is GUIDRV_FlexColor, the parameter pfFunc in function GUIDRV_FlexColor_SetFunc is GUIDRV_FLEXCOLOR_F66712.   So, modify GUIDRV_FlexColor_SetFunc in the LCD_X_Config function like this: GUIDRV_FlexColor_SetFunc(pDevice, &PortAPI, GUIDRV_FLEXCOLOR_F66712, GUIDRV_FLEXCOLOR_M16C0B16);     After the modification, then save and rebuild it. At last, download the code to the MCB1700 board which was not working before, download the code to the board, press the RESET button on the board, you will find the LCD displays the GRAPH_DATA_XY demo picture like this:   2.3.3 Other applications testing    After the above code modification for the not working MCB1700 board, if you have interest, you also can try the other application to display other pictures. In folder  NXP_emWin514_MCB1700_BSP\Application, there still has a lot of other applications, you just need to add it to the application folder in the project, then the LCD can display the according picture,  now list some application’s testing result. 2.3.3.1 GUI_WIDGET_GraphYtDemo.c   2.3.3.2 GUI_HelloWorld.c     2.3.3.3 GUI_ALPHA_TransparentDialogDemo.c   2.3.3.4 WM_RadialMenu.c   3 Conclusion    From the above detail descriptions, you will know emWin_MCB1700_bsp KEIL project build error can be fixed by changing the lib to the newest emwin lib, LPCXpresso project build error can be fixed by changing the language standard to GNU C90, the function problem in some MCB1700 is mainly caused by the mismatch LCD driver, just modify the code to the according LCD driver can fix the LCD display white problem.    Wish this document can help those customers who are using the emWin_MCB1700_bsp on the MCB1700 board, the modified project also in the attachment for your reference.

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.

This content was originally contributed to lpcware.com by Dirceu Rodrigues Introduction My work evaluating the SCT peripheral with the Hitex LPC4350 board (ARM Cortex-M4/M0) included the generation of non standard PWM signals for use in Power Electronics. At the end, some results would be compared with solutions based on LPC1114 (Cortex-M0), for example.  The first idea was to apply a concept that I had used when developing universal controllers for laser printer fuser, at 2001. This is a gate drive for MOSFET / IGBT isolated by pulse transformers. Two pulses Gate Drive – LPC1114 solution The circuit is implemented with pulse transformers (20 kHz PWM frequency) using the gate-source capacitance as memory. A Schottky diode avoids the stored charge to leak through windings. Thus, it's possible to achieve duty-cycles near to 0 and 100 %, simply applying 1 µs pulses shifted in time - one for charge, other for discharge. A very simplified schematic is shown in Figure 1.       Figure 1. Simplified circuit. My solution for the LPC1114 - Cortex-M0, uses two timers in a different scheme: Phase-out or lead/lag the counter values. With CT32B0 and CT32B1 32 bit timers, the behavior, including the pulsed outputs, is better understood looking on Figures 2 and 3 for duty-cycles of 75% and 25%. As opposed to common solutions, for each timer, the MR0 and MR1 matching registers values are constant. The difference between them is equivalent to pulse width (1 µs). The MR0 value also defines the period. The duty-cycle it’s determined through the expression:   DC = TC1 / MR0                                   (1) Where, TC1 is the CT32B1 timer value when this one, for the CT32B0, is zero.      In order to change the duty-cycle, the code in foreground task establishes a new TC1 and enables the CT32B0 overflow interrupt, where  this value is effectively loaded on CT32B1 timer in a safe point (to avoid jitter and other dangerous edges on outputs). Also, the CT32B0 ISR disables itself at the end, ensuring low interrupt overhead. For safety, the first applied pulse is a “discharge pulse”. This solution was proven driving a 930 W (120V/8.7 A) single-phase induction motor and it can be seen in reference [1], using a synchronous AC version of circuit shown in Figure 1 (no diode, four mosfets).      Figure 2. LPC1114 Two Pulses Gate Drive solution - DC 75%.  Figure 3. LPC1114 Two Pulses Gate Drive solution - DC 25%.      Two pulses Gate Drive – LPC4350 SCT solution The equivalent SCT implementation for the Two Pulses Gate Driver has the advantage of saving one timer. The pulse generation can be accomplished through a Mealy finite state machine plus the companion SCT counter. The LPC4350 generates 1 µs pulses with repetition rate of 20 kHz on CTOUT_4 and CTOUT_5 outputs. Two pushbuttons allow that a falling edge on CTIN_2 input, start the timer and a low value on CTIN_6, stop it. The counter operates as a unified 32 bit timer (UNIFY = 1) counting up and down (BIDIR = 1). ADC0 input is used to read the voltage on R26 potentiometer. So, the firmware can convert it in PWM change. As for LPC1114, the LPC4350 core and SCT runs in 48 MHz. Register MATCH 0 defines half-period. The difference between MATCH 2 and MATCH 1 registers is equivalent to pulse width (1 µs). In other words: PULSE_WIDTH = MATCH 2 - MATCH 1                       (2) Despite this difference be constant, now the MATCH 2 and MATCH 1 contents must change at the same time. Figures 4 and 5 show the waveforms for duty-cycles 15 % and 85 %. For example, the duty-cycle can be determined through the expression: DC = 1 – (MATCH 1 + 0.5*PULSE_WIDTH )/ MATCH 0        (3) Figure 4. SCT Two Pulses Gate Drive solution - DC 15%. Note: In companion source code, the PULSE_WIDTH is referred as PULSE_LENGTH. Figure 5. SCT Two Pulses Gate Drive solution – DC 85%. In order to achieve this behavior, one simple Finite State Machine with two states has been defined (Table 1): STATE Meaning 0 CTOUT_4 pulse generation 1 CTOUT_5 pulse generation Table 1. Definition of states. Figure 6 illustrates the relationship between the counter, states and interrupts. The PWM updating scheme takes advantage of following SCT property (as stated on User Manual): “A MATCH register is loaded from the corresponding MATCHREL register when BIDIR is 1 and the counter reaches 0”. In this application, the ADC0 interrupts MCU in a 24 Hz rate, triggered by TIMER0 MR0 (EM0 rising edge). The code on this ISR determines the new MATCH 1, saves it on global variable match1 and enables the SCT interrupt associated with event “counter reach limit” - in fact, event for MATCH 0. Here note, as stated in expression (3), that DC depends only on MATCH1, since MATCH 0 is constant. The ISR code for MATCH 0 event, updates MATCHREL 1 and MATCHREL 2 registers based on variable match1. Also disables the associated interrupt for low overhead. When counter reaches 0, the MATCH 1, 2 registers will be reloaded from the MATCHREL 1, 2 values automatically. This procedure should avoid jitter and other dangerous edges on outputs. Note that MATCH registers are never handled by software when counter is running. The new desired values are indirectly loaded on MATCHREL registers. The first values for MATCH registers are intentionally unreachable (> MATCH 0). This ensures that only ADC readings brought useful values to them. The on board potentiometer generates a voltage from 0 V to 3.3 V, which translates to 0 – 1023 range by the 10 bit AD converter. The MIN_MATCH1 and MAX_MATCH1 predefined values equates to 36 and 1116 (equivalent to duty-cycle 5 % and 95 % DC). Therefore, the software relates ADC0 voltage to with match1 variable approximately through the expression: match1 = [(MAX_MATCH1 - MIN_MATCH1)*ADC0] / 1024 +            (4)                                                  MIN_MATCH1 Note: In the companion source code, the division by 1024 is performed with a 10 bit right shift.           Figure 6. PWM updating scheme - DC 50%. Table 2 lists the eight states comprising the state machine for the current application. The companion state transition diagram is showed on Figure 7. Here, note other SCT important property, as stated on User’s Manual: “If more than one event associated with the same counter occurs in a given clock cycle, only the state change specified for the highest-numbered event among them takes place”. This applies to events 6 and 7. In normal operation, the event 6 happens periodically in State 1; but when a pushbutton press causes a low level on CTIN_6, the event 7 is fired on State 1 and counter is stopped. The state is driven to 0, with the outputs cleared (until one falling edge on CTIN_2 initiates the counting). EVENT ID Happens in state Conditions Actions 0 0 Falling edge on CTIN_2 Start counter 1 0 Counter reach MATCH 1 when counting up Set CTOUT_4 (pulse rise) 2 0 Counter reach MATCH 2 when counting up Clear CTOUT_4 (pulse fall) 3 0 Counter reach MATCH 0 Limit counter (defines the half period) Int. to update MATCHREL 1/ 2 Change to STATE 1 4 1 Counter reach MATCH 2 when counting down Set CTOUT_5 (pulse rise) 5 1 Counter reach MATCH 1 when counting down Clear CTOUT_5 (pulse fall) 6 1 Counter reach MATCH 3 (0) MATCH 1/ 2 automatic reloading Change to STATE 0 7 1 Counter reach MATCH 3 (0) AND Low value on CTIN_6 Stop counter MATCH 1/ 2 automatic reloading Change to STATE 0 Table 2. Definition of states. Figure 7. State transition diagram. Conclusion The PWM generation carried out by two short pulses shifted in time is a good alternative when isolation and duty-cycles far from 50% are required - specially driving gate charge devices like Mosfet/IGBT. The main advantage over opto-isolated implementations is not necessary create an auxiliary power supply.  Regarding to the architecture, the designer can use microcontrollers equipped with UP/DOWN timers (bidirectional), but is required some external glue logic in order to generate those short pulses. In comparison with the LPC1114 presented solution, the SCT version consumes just one timer/counter. As shown, the SCT peripheral is very independent, resulting in low (or no) MCU intervention after an initial configuration. This simple application used only two inputs, two outputs, two states and eight events. For more complex designs, the SCT provides up to 8 inputs, 16 outputs, 16 events and 32 states. I’ve future plans to make other power electronics applications based on SCT, including a small dot matrix printer controller. Code Red company   provides a tool to draw state diagrams and automatically generate code for the SCT engine, called Red State [2] (not used in this application). Finally, I would like to thank David Donley from NXP, who assisted me by answering my technical enquiries about the State Configurable Timer and suggesting improvements on code. References     [1]    http://www.youtube.com/DirceuRodriguesJr     [2]    http://www.code-red-tech.com/lpcxpresso

This content was originally contributed to lpcware.com by George Romaniuk     This project included testing the performance of the SPIFI interface on LPC4350. Example files were modified to run the M4 core at 200MHz and read and write to SPIFI attached FLASH. Timer was added to measure the execution and data transfer time. Reads were at an amazing 44.9MByte/s; writes were much slower due to FLASH. In addition to SPIFI, some DSP routines were timed and performance was documented.

This content was originally contributed to lpcware.com by Cam Thompson This project is a simple data logging example that takes readings from various sensors, and log the information to a web page. The Cortex-M4 is used to collect and process sample data, and the Cortex-M0 is used to run a web server for supplying data to web clients. This allows data to be viewed on any web browser, including portable devices such as smart phones and tablets. The web data logging example was implemented using the Hitex LPC4300 evaluation board, which has all the necessary components. The LPC43xx has a built-in ethernet controller accessible by either core, and the Hitex evaluation board provides the physical layer. An on-board 128x32 pixel Chip-on-Glass (COG) LCD display, four touch sensors, and several LEDs are used for implementing a simple user interface. The LPC43xx contains a Real-Time Clock (RTC) which is used to record the date and time of data samples.

This content was originally contributed to lpcware.com by Steve Sabram This example project implements acoustic range, finite infinite response (FIR) filters using the LPC4350 demo board and the ARM CMSIS DSP library. A sound resource of a science fiction “zap gun” plays out the headphone jack of the demo board. This sound sample is great for demonstration since it has many low-, mid-, and high-frequency components along the acoustical band. You play the sound resource by touching the capacitive touch buttons on the demo board as explained by the menu shown on the demo board’s LCD. It is best to listen to the sound with a headphone or ear buds. Each of the four buttons plays the same sound resource differently: 1)  Raw – The unprocessed sound plays according to its format (sample rate of 44.1 kHz, 16-bit sample and mono sound). 2)  Low Pass – filtered through a low pass, Butterworth filter with a cutoff of 5 kHz, similar to the bandwidth of a common analog telephone. When played, notice that high pitch components are removed similar       to the sound heard over a telephone. 3)  High Pass – filtered through a high pass, Butterworth filter with a low frequency cutoff of 8 kHz. Notice that the sound is lower in volume since only the upper harmonic components are played. 4)  Backward Mask – The sound resource sample plays in reverse order. The “Zap!” is now a “Zoup!” The digital filters were designed with a favorite public domain tool, WinFilter (http://www.winfilter.20m.com/)       accompanying this example. With exposure of this free DSP design tool via NXP, I hope its author expands its features.

This content was originally contributed to lpcware.com by Brewster LaMacchia   This project shows how to take the filter coefficients created by MDS' QEDesign filter design package and use them for real time audio filtering using the floating point DSP capability of the LPC4350. It's designed to run on the Hitex board and uses the UDA1380 for analog stereo I/O. It also uses the touch buttons, COG LCD, and LEDs for controlling operation.   Keil's Logic Analyzer tool was used for performance measurement. For full details see \doc\gen\html\index.html after unzipping the download.   Updated 16-Mar-12 to correct output rolloff in the UDA1380 due to the deemphasis filter being on by mistake.   Original Attachment has been moved to: MyProj.zip

This content was originally contributed to lpcware.com by Richard Man This project demonstrates how easy it is to port a commonly used open source FatFS code to the LPC4350 using SDIO and built-in SDMMC support. In the competitive embedded microcontroller market, one way a silicon vendor can differentiate its offerings from the rest is by integrating higher-function peripherals onchip. As such, it is no longer unusual to find chips with built-in LCD, USB, CAN, Ethernet, and in some instances, even hardware support for the SD/MMC memory devices. Such is the case with the NXP LPC4350. With two ARM Cortex cores and many other features, it also sports SD/MMC hardware. Without dedicated SD/MMC support, the firmware typically must use bit banging code which is timing sensitive and adds to the complexity of the code.

This content was originally contributed to lpcware.com by Jack Ganssle In this project I looked at the relative performance of the LPC4350's M4 vs. M0 cores, emulating ARM's big.LITTLE approach. In the last few years the industry has increasingly embraced the notion of using multiple processors, often in the form of multicore. Though symmetric multiprocessing – the use of two or more identical cores – has received a lot of media attention, many embedded systems are making use of heterogeneous cores. A recent example is ARM’s big.LITTLE approach, which is specifically targeted to smart phones. A big Cortex-A15 processor does the heavy lifting, but when computational demands are slight it goes to sleep and a more power-frugal A7 runs identical code. NXP’s LPC43xx also has two ARM cores: a capable Cortex-M4 and a smaller M0. Since power constraints are hardly novel to phones, my question was: “if we mirror the big.LITTLE philosophy, what is the difference in performance between the M4 and the M0?”

This content was originally contributed to lpcware.com by Jerry Durand When I found the M4 core in the LPC43xx series could be used as a hardware Floating Point Unit (FPU) while the actual code ran in the M0 core, I immediately thought of an application; a stand-alone 4-axis CNC control box for use with table-top milling machines.  Currently these machines are almost exclusively controlled by software running on very old PC hardware that has a parallel port and either MS-DOS or Windows XP for an operating system. Control of these milling machines entails tasks such as receiving g-code commands in ASCII text and a large amount of high-precision floating point operations which calls for an FPU.  This all has to occur rapidly and continously as each of the 4 motors has to be updated thousands of times per second. It seemed the M0 core would excel at the basic input/output (I/O) and timing functions while using the M4 as an FPU would speed the floating point operations. I originally hoped to port the entire RS274NGC open source Enhanced Machine Controller (EMC) software to the LPC4350 and run it with and without the FPU enabled, comparing the time to process a sample g-code file.  Problems getting the development software and examples set up caused me to run short of time even though NXP was fairly fast to fix problems as they were found.  Instead I modified one of the example programs (GPIO_LedBlinky) to enable testing the performance and this turned out to have some interesting results I might have otherwise missed. I ran the test code in eight different configurations:      1. FPU disabled, 32-bit float multiplication      2. FPU enabled, 32-bit float multiplication      3. FPUdisabled, 64-bit double multiplication      4. FPU enabled, 64-bit double multiplication      5. FPU disabled, 32-bit float division      6. FPU enabled, 32-bit float division      7. FPUdisabled, 64-bit double division      8. FPU enabled, 64-bit double division All tests were run from internal SRAM so external memory access time would not distort the results.  The optimization level was left at the default of zero (0) as I had problems with the compiler eliding parts of my code if I tried higher levels. Test results (loops per second averaged over 10 seconds):      1. 990,550        float, *      2. 2,768,000        FPU, float, *      3. 284,455        double, *      4. 276,796        FPU, double, *      5. 282,316        float, /      6. 1,894,000        FPU, float, /      7. 85,762        double, /      8. 85,053        FPU, double, / As expected 32-bit floating point operations run a lot faster with the FPU, 2.79 times faster for multiply and 6.7 times faster for division.  I would have expected somewhat better performance but this is still a significant improvement in speed. The 64-bit floating point operations were a different story, for both multiplication and division the operations ran SLOWER with the FPU than they do without it.  This points to an error in the library functions since it should be no worse than equal.  I was very surprised by this result and hope when the problem is fixed the 64-bit operations improve significantly. In conclusion the low cost of these parts and the simplicity of using the FPU allows performance improvement to an existing product that uses 32-bit floating point operations.  There is no long development cycle or fear of breaking something in your code as the changes to use the FPU consist of adding a small initilization routine for the FPU and enabling it in your compiler options.  This also leaves open the option of an even greater improvement with no hardware changes once you've had time to port your critical code to run directly on the M4 core instead of just using it as an FPU. In the case of 64-bit floating point operations, it seems this may not be the best choice if you only use the M4 as an FPU.  Running your critical code directly on the M4 may give a significant improvement but that requires porting the code to run on both cores and isn't something I tested.

This content was originally contributed to lpcware.com by Massimo Manca Example application for the "LPC4300 Getting started Kit" to learn and to use the multi processor communication and the newest peripherals of LPC43xx MCU family. System resources used and assignment to the cores: The Cortex-M4 core handles the application logic, manages the 4 touch keys and 4 leds (via the PCA9502 I2C 8 bit I7O expander), the lcd display and the real time clock. The Cortex-M0 core is dedicated to the printer management using the RS232 on board interface (in near future SCT and SGPIO will be used to interface a thermal printing head). The cores communicates using inter processor communication mechanisms minimizing the data passed from M4 to M0 and providing a simple security mechanism.

Description The brushless DC (BLDC) motor control design example describes how to connect and control up to four brushless DC motors using a single NXP microcontroller from the ARM968-based LPC2900 series, making this a low cost solution. Four dedicated motor control PWM blocks keep the CPU load low while running four motors. This allows the microcontroller to still perform other tasks in Hardware used Hitex LPC2939 or LPC2929 evaluation board Hitex BLDC motor control extension board (4x) Interface board Maxon EC32 80W brushless servo motor with Quadrature Encoder Interface (QEI) Three of the Hitex BLDC motor boards are driven as-is (spinning their on-board motors). The fourth board is driving the Maxon EC32 motor using the quadrature encoder interface. The interface board is used to create the correct pin-out that makes it possible to connect the four motor control extension boards to the LPC29xx evaluation board. Block Diagram Documentation BLDC Motor Control Products Below are recommended microcontrollers for use in BLDC motor control applications. Comparison Table Product Pins On-Chip Flash On-Chip RAM Comments LPC2939 208 768KB 56KB Base microcontroller used in the design example. LPC2930 208 0KB 56KB A lower-cost microcontroller with the same amount of pins but without on-chip flash memory. LPC2929 144 768KB 56KB Same on-chip memory as on the LPC2939 but in a smaller package and without USB Host functionality. LPC2927 144 512KB 56KB Same as LPC2929 but with less on-chip flash memory. More Information Image BLDC Motor Control Demo at ESC SV 2009 Schematics LPC2939 Evaluation Board BLDC Motor Control Extension Board Interface Board Example Code BLDC Motor Control Bill of Materials BLDC Motor Controlhttp://www.lpcware.com/sites/default/files/bom.xls Disclaimer This design example shows possible hardware and software techniques used to implement the design. It is imperative that the viewer use sound engineering judgment in determining the fitness of this design example for any particular application. This design example may include information from 3rd parties and/or information which may require further licensing or otherwise. Additional hardware or software design may be required. NXP Semiconductors does not support or warrant this information for any purpose other than an informational design example. lpc2939.eval_.board_.schematics.pdf 143.6 KB documentation.pdf 243.48 KB bldc.board_.schematics.pdf 188.85 KB interface.board_.zip 2 MB example.code_.zip 72.55 KB bom.xls 3.87 KB

Description The Audio Player Design Example, based on an NXP LPC2138 ARM7-based microcontroller, delivers high-quality, uncompressed, 16-bit digital audio playback. This design allows engineers to add MP3 music or sound effects to a variety of consumer applications at a very low cost. Entertaining sounds could be added to children's items or music clips could be easily added to products targeted at teens. There is no limit to the number of existing applications that could be enhanced by inexpensively adding high-quality sound or music. Block Diagram Documentation Audio Player Products Below are recommended microcontrollers for use in implementing this design to a system. Comparison Table Product Pins On-Chip Flash On-Chip RAM Comments LPC2138 64 512KB 32KB Base microcontroller used in the design example. LPC2136 64 256KB 32KB A lower-cost microcontroller with the same amount of on-chip RAM but with only half the on-chip flash memory. LPC2146 64 256KB 32KB + 8KB An upgraded microntroller with more on-chip RAM allowing for a real-time MP3 software decoder. The added USB interface allows file transfer with a personal computer. LPC2148 64 512KB 32KB + 8KB An upgrade to the LPC2138 microntroller, the LPC2148 substitutes Full-speed USB 2.0 device functionality for a slightly higher cost. More Information Images Working Prototype DAC Circuit                                                       SD Card InterfaceSchematics Audio Player Example Code Audio Player Disclaimer This design example shows possible hardware and software techniques used to implement the design. It is imperative that the viewer use sound engineering judgment in determining the fitness of this design example for any particular application. This design example may include information from 3rd parties and/or information which may require further licensing or otherwise. Additional hardware or software design may be required. NXP Semiconductors does not support or warrant this information for any purpose other than an informational design example. documentation.pdf 418.54 KB schematics.zip 123.65 KB example.code_.zip 719.42 KB

Description The Telephone Answering Machine Design Example is a sophisticated telephone answering machine that provides everything commercial devices offer and more. Noteworthy features include improved voice quality and increased storage capacity over commercial machines. Additionally, Internet connectivity enables convenient messaging in the form of SMS messages or e-mails from anywhere in the world. Virtual answering machines can be set up for four different users. A user-friendly interface makes learning how to use this device and taking advantage of its many special features easy for anyone, regardless of their electronics savvy. The highly efficient system is designed around an LPC2138 microcontroller, which features an ARM7 RISC processor. Built with a small handful of components, the Telephone Answering Machine Design Example is cost-effective. The thoughtful inclusion of an external flash memory card and well-chosen algorithms for nearly unlimited storage capacity of crystal-clear messages contribute to the success of the design. Block Diagram Documentation Telephone Answering Machine Products Below are recommended microcontrollers for use in implementing a telephone answering machine. Comparison Table Product Pins On-Chip Flash On-Chip RAM Comments LPC2138 64 512KB 32KB Base microcontroller used in the design example. LPC2136 64 256KB 32KB A lower-cost microcontroller with the same amount of on-chip RAM but with only half the on-chip flash memory. LPC2146 64 256KB 32KB + 8KB An upgraded microcontroller with a USB interface. USB could be used instead of Ethernet to connect to a PC if Internet functionality is not desired. More Information Images Working Prototype Circuit Blocks Answer Flow Telephone Answering Machine Schematics Example Code Bill of Materials Disclaimer This design example shows possible hardware and software techniques used to implement the design. It is imperative that the viewer use sound engineering judgment in determining the fitness of this design example for any particular application. This design example may include information from 3rd parties and/or information which may require further licensing or otherwise. Additional hardware or software design may be required. NXP Semiconductors does not support or warrant this information for any purpose other than an informational design example. documentation.pdf 927.44 KB schematics.pdf 92.13 KB example.code_.zip 646.98 KB bom.txt 1.39 KB

Description This is a demonstration-only design of a Point Of Sale (POS) system using the NXP LPC2214FBD144. Fiscal Cash Register (FCR) is a kind of POS machine which is popularized by governments, in particular, in China. A tax control function is added to the POS machine for revenue supervision. Considering the national standard and function expansion and complexity, an ARM MCU is used in the application market. The LPC2214 is the central control unit of the system. The system consists of an LCD, NAND flash, keypad, printer, RTC, IC card, etc. The FCR demonstration system is divided into two boards. The first is the NXP LPC22xx development board. On this board, general peripheral resources are integrated such as external flash and SRAM, keypad, ethernet, LCD, USB, CF card, and IDE. This can be considered as the motherboard used for the overall application. The FCR-specific resources such as NAND flash, UART, printer, and IC card are on the extended board. If more resources are needed, just replace the extended board. In the system, the LCD module is needed to display the operation and the keypad is used to send commands to the system. NAND flash is used to store the business data and the DOT Matrix printer is used to print the invoice. The IC card is used for security. The POS demo system demonstrates the functions which are important in a complete FCR system. The demo system can be used for software development and can help in reducing the development cycles and time to market. Block Diagram Products Below are recommended microcontrollers for use in implementing this design to a system. More Information Images Working Prototype Point of sale Schematics Example Codehttp://www.lpcware.com/sites/default/files/example.code__3.zip Disclaimer This design example shows possible hardware and software techniques used to implement the design. It is imperative that the viewer use sound engineering judgment in determining the fitness of this design example for any particular application. This design example may include information from 3rd parties and/or information which may require further licensing or otherwise. Additional hardware or software design may be required. NXP Semiconductors does not support or warrant this information for any purpose other than an informational design example. schematics.zip 151.79 KB example.code_.zip 602.53 KB

Description This application provides a human interface via terminal (UART1) menus and numbered selections to select and play audible medical alerts that are generated algorithmically on the NXP LPC23xx. The medical alarms are designed to comply with the IEC 60601-1-8 standard for audible medical alarms. The IEC standard seeks to improve patient safety by standardizing medical audible and visual alarms. The audible portion of the standard specifies high, medium, and low priority alarms, and these are provided via a menu system. In addition, a test menu is added to facilitate analysis of the quality of the alarms generated and their compliance with the standard. Many previous applications used playback techniques to use pre-recorded alarm sounds for the alerts. An algorithmic approach provides a much more efficient, high-quality implementation compared to the pre-recorded sounds. Plus, the sounds can be customized to differentiate equipment while still staying within the parameter limits of the standard. Block Diagram Documentation     IEC Alarm Detailed Documentation Products Below are recommended microcontrollers for use in implementing this design to a system. Comparison Table Product Pins On-Chip Flash On-Chip RAM Comments LPC2364 100 128KB 34KB 128KB flash/34KB RAM version of LPC2368, no SD/MMC LPC2366 100 256KB 58KB 256KB flash version of LPC2368, no SD/MMC LPC2368 100 512KB 58KB + 8KB 100-pin version of LPC2378, no external bus LPC2378 144 512KB 58KB + 8KB 144 pin, similar to LPC2368 but more pins and a MiniBus (8-bit) LPC2387 100 512KB 98KB LPC2368 with 98KB SRAM LPC2388 144 512KB 98KB LPC2378 with 98KB SRAM and USB Host/OTG LPC2458 180 512KB 98KB + 8KB LPC2468 with 16-bit External Memory Interface LPC2460 208 0KB 98KB + 8KB Flashless LPC2468 LPC2468 208 512KB 98KB Host/OTG/device, 32-bit ext. bus, 512KB flash/98KB RAM, 208 pin package LPC2470 208 0KB 98KB + 8KB LPC2460 with XGA LCD controller LPC2478 208 512KB 98KB + 8KB LPC2468 with XGA LCD controller More Information Example Code IEC Alarm Example Code Disclaimer This design example shows possible hardware and software techniques used to implement the design. It is imperative that the viewer use sound engineering judgment in determining the fitness of this design example for any particular application. This design example may include information from 3rd parties and/or information which may require further licensing or otherwise. Additional hardware or software design may be required. NXP Semiconductors does not support or warrant this information for any purpose other than an informational design example. documentation.pdf 395.85 KB example.code_.zip 255.55 KB