LPC Microcontrollers Knowledge Base

Discussions

Link to board: http://www.lpcware.com/content/devboard/android-open-accessory-aoa-kit Android Demos There are three demos available for download on the Embedded Artists website http://embeddedartists.com/products/app/aoa_kit.php The code bundle contains the following: Demo 1: Android Open Accessory demo which lets you control and monitor the AOA Board (LPC1769 side) from an Android device. Demo 2: Android Open Accessory demo which lets an Android device detect CAN nodes (such as the LPC11C24 side of the AOA board) in a CAN network. The CAN nodes can be controlled and monitored from the Android device. Demo 3: Android Open Accessory demo which lets an Android device detect Xbee nodes in an Xbee network. The Xbee nodes can be controlled and monitored from the Android device. FreeRTOS has been ported to the board and a demo is available that show how to use it. lwIP v1.4.0 has been ported to the board. The httpserver_raw (webserver) application from the lwIP contrib package is available with a small modification to use the on-board SD-card interface instead of the ROM based file system. FatFs file system module has been ported to the board. The lwIP demo (based on httpserver_raw) is using this module to access files on an SD card. nxpUSBlib is available and used in the AOA demos. How to setup the projects in LPC Xpresso Make sure that the latest version of the LPCXpresso IDE is installed. Download the package of sample application projects into the Eclipse workspace. The package can be downloaded (as a zip-file) from Embedded Artists’ support page after registering the product. The zip-file contains all project files and is a simple way to distribute complete Eclipse projects. Start the LPCXpresso IDE and select a new (and empty) workspace directory. Select the Import and Export tab in the Quickstart Panel and then Import archived projects (zip), see Figure 1 below. Browse and select the downloaded zip file containing the archived sample applications. Select all sub-projects to be imported, see Figure 2 below. By default the NXP USB library has been configured for USB device only. This needs to be changed to USB host. Right click on the nxpUSBlib project and select Build Configuration, then Set Active. In the list select LPC17xx_Host. See Figure 3. The projects are now imported. Click (to select) the project to work with. Click Build in the Quickstart Panel (under Start Here). See Figure 4 There is also a video on how to setup Demo 1 and get it running by connecting your android device. (Getting started video provided by Embedded Artists) http://www.youtube.com/watch?v=l3f2ss1IdV0&feature=player_embedded

LPC4088 Closed Payment Loop Demo - Compiling the software & flashing the board After connecting the three boards together, it's time to compile the software and flash it onto the board. To do so, please follow below steps. Download the software. Unzip the software. Open the Keil Multi-Project workspace by opening the file .\LPC4088 POS Demo\Project_BlueboardPOS_Workspace.uvmpw. Note: Keil version V.4.54 or higher is required to open the workspace correctly. If you do not meet this requirement, an error will be shown when opening the workspace. Compile project "CDL" by right-clicking on the CDL project and selecting option "Set as Active Project" (1). Next, click on the "Rebuild" button (2) Repeat Step 4) for the 4 remaining projects (BSP, emWinlib, NxpRdLib_PublicRelease, Project_BlueboardPOS). Connect the Keil ULINK2 debugger to the baseboard (J8). If any other debugger than the Keil ULINK2 is used, the Keil project should be changed to use this other debugger. Power-up the board. Although the Embedded Artists base-board can be powered by a USB connection, it is advisable to use the power-jack because of the high-power consumption of the 7" LCD. Powering the board by USB may result in incorrect behavior. With project "Project_BlueboardPOS" set as active project, click on the "Load" button ( ). This will load the compiled POS demo to the FLASH. Proceed to "Running the demo"

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

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?”

Featured article

New update to errata will be published regarding the vendor_usage field in the PFR. In ROM, the 16-bit monotonic counter is implemented in the upper 16 bits of the 32-bit VENDOR_USAGE field and the inverse of the monotonic counter is in the lower 16 bits. Users must take care when using the ROM API to increment the upper end of this field and write the inverse on the lower 16 bits in order for ROM to validate the value correctly. The initial value that shall be written is 0x0000FFFF. Then the updates will be as follows: 0x0001FFFE 0x0002FFFD . . 0x0005FFFA . . 0x1010EFEF . . 0xFFFF0000 Example Code using ROM API: *This example demonstrates the increment of the version in CFPA page as well as the vendor usage, it does not cover all use cases, so please use this as a reference only* case APP_INCREASE_VENDOR_USAGE_ONLY: PRINTF("Disable Flash Protect...\r\n"); /* Initialize flash driver */ FLASH_Init(&flashInstance); if (FFR_Init(&flashInstance) == kStatus_Success) { PRINTF("Flash init successfull!!. Halting...\r\n"); } else { error_trap(); } status = FFR_GetCustomerInfieldData(&flashInstance, (uint8_t *)g_CFPAData, 0x0, FLASH_FFR_MAX_PAGE_SIZE); PRINTF("\r\n"); PRINTF("Header 0x%08x , Version 0x%08x , SecureFW Version 0x%08x , NonSecureFW Version 0x%08x\r\n", g_CFPAData[0], g_CFPAData[1], g_CFPAData[2], g_CFPAData[3]); PRINTF("ImageKey Revoke 0x%08x , Reserved 0x%08x , RothRevoke 0x%08x , Vendor Usage 0x%08x\r\n", g_CFPAData[4], g_CFPAData[5], g_CFPAData[6], g_CFPAData[7]); PRINTF("NS PIN 0x%08x , NS DFLT 0x%08x , Enable FA Mode 0x%08x , Reserved1 0x%08x\r\n", g_CFPAData[8], g_CFPAData[9], g_CFPAData[10], g_CFPAData[11]); PRINTF("\r\n"); /* Clean-up CFPA area */ g_CFPAData[8] = 0; g_CFPAData[9] = 0; /*Increase Monotonic counter*/ p32 = (uint32_t *)(uint32_t)g_CFPAData; version = p32[1]; if (version == 0xFFFFFFFFu) { return kStatus_Fail; } version++; p32[1] = version; PRINTF("Version to write: 0x%08x \r\n", version); /*Increase Vendor Usage*/ uint32_t vendor_usage = p32[7]; if(vendor_usage == 0x0) { vendorUsage_right = 0xFFFF; vendorUsage_left = 0x0000; } else { vendorUsage_right = vendor_usage & 0xFFFF; vendorUsage_left = vendor_usage >> 16; } vendorUsage_left += 0x1; vendorUsage_right -= 0x1; vendor_usage = (vendorUsage_left << 16) | vendorUsage_right; p32[7] = vendor_usage; PRINTF("Vendor_Usage to write: 0x%08x \r\n", vendor_usage); Status = FFR_InfieldPageWrite(&flashInstance, (uint8_t *)g_CFPAData, FLASH_FFR_MAX_PAGE_SIZE); if (kStatus_FLASH_Success == Status) { status = kStatus_Success; PRINTF("CFPA Write Done!\r\n"); } else { status = kStatus_Fail; }

LPC Microcontrollers Knowledge Base

LPC Microcontrollers Knowledge Base

Discussions

TN006_Test VDD value on LPC82x.docx

TN002_低功耗模式下的串口通信异常.docx

Android Open Accessory (AOA) kit

LPC4088 Closed Payment Loop Demo - Getting Started - Compile

lpcxpresso54114_driver_example_gpio_led_output.zip

IEC alarm design example

LPC MCU Training Session _ LPC82x SCT Slides and Hands-on

LPC4350 Speed of M4 vs M0 processors

TN002_UART Dataloss with low power mode.docx

LPC55S6x/S2x/S1x/S0x Vendor Usage Errata Update