The Embedded Artists LPC3250 based board ships with the kickstart loader and Stage 1 Loader (S1L) pre-installed to execute from large block NAND FLASH. The kickstart loader resides in NAND block 0 and is loaded into IRAM with the LPC32x0 boot ROM on chip reset. Control is then transferred to IRAM after the kickstart loader is loaded. The kickstart loader then loads S1L from block 1 and on of NAND FLASH into IRAM. Once S1L is loaded, control is transferred to S1L.

This section explains how to use the MLC extractor tool to get an image with interleaved MLC data from NAND FLASH. The MET runs on the target hardware, so the image to be extracted must be placed on the hardware first. There are detailed swrites in the CDL on how to do this, so this won't be covered here. The program assumes UART 5 (the LPC32x0 boot UART) is used as the UART interface. The most common code extracted with this is the kickstart loader in block 0. This loaded is used to boot the LPC32x0 from NAND, setup the system, and then bootstrap the secondary loader in NAND blocks 1 and on. This example is shown on the Phytex LPC3250 board, although ti will work similar on other boards. Setup the serial loader tool to load the "mlcextractor.bin" file to the board via the serial port. M<ake sure the ServiceN pin on the LPC3250 is pulled low to enable UART boot mode. Press the "Load bin's/Start primary" button on the serial loader dialog window. Reset the board and the serial loader tool will transfer the MLC extractor to the target board. After the image is loaded, you will see a messaeg displaying the number of blocks and pages per block in NAND. If a message appears that says the NAND device coudn't be found, then the image needs to be rebuilt with the NAND IDs that match the NAND device on the target board. Close the serial load tool and open a terminal program that supports XMODEM transfer (ie, Teraterm). Press the space bar to get the MET menu. Pressing the keys defined by the menu allows you to change the starting block and number of blocks to extract the data for. Once they are selected, press 'd' and then 'y' to start the xmodem transfer. Next, setup the terminal program for an XMODE_cChecksum receive session. Once started, the interleaved data and ECC codes will be read from the NAND device and transferred to the file via XMODEM. This resulting file can be used for NAND programming.

To build a project for IAR, select the Workspace file (eww) file for the example you want to build and deploy. The project will open up in the IAR EWARM IDE. For the project, select the build variant you want to build. Press F7 to build the selected project. Each project will generate a hex file in addition to the executable. Locate the hex file and use Flash Magic to program it into the board's FLASH. Before programming, make sure the board/devie is in ISP mode by holding down the SW6 button while pressing and releasing the reset button.

The LPC LWIP port uses zero-copy buffers. Zero-copy buffers can improve system performance over copied buffers when transferring large amounts of ethernet data. Zero-copy buffers also use less memory for data storage, as bounce buffers are not needed between the LWIP pbufs and the ethernet DMA buffers. This section gives a brief overview of how buffers are managed in the driver and the LWIP applications. Zero-copy RX buffers For zero-copy buffers, the initial pbufs needed to receive packets are pre-allocated and assigned to the ethernet controller at the maximum expected packet size. It should be noted that the payload for the packet in a pbuf must always be non-chained (contiguous) for receive. The driver will allocate packets with maximum packet size without any chaining. When a packet is received, the hardware places the received data directly into the pbuf's data (payload) area. The pbuf is then passed to the network layer without an extra copy where it is used by the application or LWIP and then de-allocated once it finishes with the packet. Once the pbuf leaves the driver's functions, it no longer tracks it or it's buffer, but the original descriptor that was associated with the pbuf is now available for a new pbuf. The driver will attetmpt to allocate and requeue a new pbuf for the descriptor before returning the received packet. If memory is not available for the new pbuf, the descriptor remains free and an attenpt will be made to allocate a new pbuf on the next received packet. (Calling lpc_rx_queue() anytime will also attempt to reload any idle RX descriptors). Note: For the LPC17xx, the descriptors and buffers must be located only in peripheral RAM or external memory. For the LPC18xx/43xx, descriptors and buffers can be located anywhere. Zero-copy TX buffers For zero-copy buffers, the initial pbuf's payload addresses are used directly with the EMAC TX descriptors. The driver will chain buffers in the descriptor if needed (if a chained pbuf is used) and keep a reference of the pbufs that are used for the transfer. The buffers/pbufs must remain in memory until the EMAC has transferred the data related to the pbuf(s). Once the EMAC transfers the buffers, the pbuf(s) will be de-allocated by the driver. Note: For the LPC17xx, the descriptors and buffers must be located only in peripheral RAM or external memory. For the LPC18xx/43xx, descriptors and buffers can be located anywhere. Zero-copy TX buffers and bounce buffers In some cases, buffers may be passed to the driver that are located in FLASH memory, IRAM, or slow memory. The EMAC driver and peripheral can't send this data directly via DMA (due to architecture or speed restrictions), so the data needs to be relocated to an area of memory that it can be sent from. If the driver detects that a buffer address used for a zero-copy transfer is not usable by the EMAC, it will copy the buffer to a temporary bounce buffer and send it from that buffer instead. This occurs automatically inside the driver if the bounce buffer support is enabled. If the bounce buffer support is not enabled and a non-usable buffer is detected, the driver will raise an exception. For the LPC17xx, this support is enabled by setting LPC_TX_PBUF_BOUNCE_EN to 1. For the LCP18xx/43xx, this support is enabled by setting LPC_CHECK_SLOWMEM to 1. If LPC_CHECK_SLOWMEM is set to 1, the memory ranges for the check must be setup with the LPC_SLOWMEM_ARRAY define.

Description This example implements a mass storage class device that operates on a FAT12 volume stored in internal RAM. The size of this volume is set by the constant DATA_RAM_PHYSICAL_SIZE defined in DataRam.h Compiler build configurations The software that makes up this example is designed to run on many different development boards. Therefore the compiler must be configured to build an image that is targeted to the development board you are using. This section explains how to set these build configurations for each of the supported compilers.   LPCXpresso IDE Configure projects   right click on the BSP project in the project explorer window   click Build Configurations->Set Active->(see configuration in table below)   repeat these steps with the CDL, nxpUSBlib, and Example_MassStorageDevice Configure MCU   right click on the Example_MassStorageDevice project in the project explorer window   click Properties->C/C++ Build->MCU settings->(see configuration in table below) Configure the indexer    click Window->Preferences->C/C++->Indexer->Use active build configuration BSP CDL nxpUSBlib Example_MassStorageDevice MCU LPC1850  / Hitex LPC18xx_HITEX LPC18xx LPC18xx_Device LPC18xx LPC1850 LPC4330  / Xplorer LPC4330_Xplorer LPC18xx LPC18xx_Device LPC18xx LPC4330 LPC4350  / Element14 LPC1435_ELEMENT14 LPC18xx LPC18xx_Device LPC18xx LPC4350 LPC11U14 / LPCXpresso LPC11Uxx_LPCXpressoRevB LPC11Uxx LPC11Uxx_Device LPC11Uxx LPC11U14 LPC11U14 / MCB1000 LPC11u14_MCB1000 LPC11Uxx LPC11Uxx_Device LPC11Uxx LPC11U14 LPC1768  / MCB1700 LPC1768_MCB1700 LPC17xx LPC17xx_Device LPC17xx LPC1768 LPC1768  / LPCXpresso LPC17xx_LPCXpressoRevB LPC17xx LPC17xx_Device LPC17xx LPC1768 NOTE: The LPC18xx CDL is used with boards that hold LPC43xx parts. This is done because the LPC43xx CDL is currently experimental. The LPC18xx USB library is used because both parts share the same controller.   Keil uVision 4 IDE Configure a Batch Build     click on Project->Batch Build...   expand the BSP project to display a list of project targets   select the project target by checking the appropriate checkbox (see target list in table below)   repeat these steps with the CDL, nxpUSBlib_Device, and Example_MassStorageDevice BSP CDL nxpUSBlib_Device Example_MassStorageDevice LPC1850  / Hitex HITEX1800 LPC18xx LPC18xx_Device HITEX1800 LPC1768  / MCB1700 MCB1700 LPC17xx LPC17xx_Device MCB1700 LPC11U14 / MCB1000 MCB1000 LPC11Uxx LPC11Uxx_Device MCB1000   Board connections and configurations   LPC18xx_HITEX (LPC1850 Hitex Evaluation Board)  older A2 design schematic ./BSP/schematics/HITEX_SCM_LPC1850EVA-A2-2.pdf   Connect the JTAG to the 20 pin receptacle marked X4 JTAG Connect the type-B end of a USB cable to the receptacle marked X2. Plug the type-A end of this cable into a PC LPC18xx_HITEX (LPC1850 Hitex Evaluation Board)  newer A4 design schematic ./BSP/schematics/HITEX_Final_LPC1850EVA-A3.pdf   LPC4330_Xplorer (NGX Xplorer Evaluation Board with LPC4330) Connect the JTAG to the 10 pin receptacle marked J2 Connect the micro-b end of a USB cable to the receptacle marked USB0. Plug the type-A end of this cable into a PC   LPC1435_ELEMENT14 (Element 14 gaming board with LPC4350) Connect the JTAG to the 10 pin receptacle marked J6 Connect one end of a type-A to type-A USB cable to the receptacle marked USB0. Plug the other end of this cable into a PC   LPC11u14_MCB1000 (Keil MCB1000 development board) schematic: ./BSP/schematics/mcb1000-schematics.pdf   Jumpers:   J4 = 2-3      (UCON - PIO0_6 pulls D+ high)   J2 = 1-2          (VDD  - core power)   J5 not installed  (ISP  - ISP via COMM)   J6 not installed  (RST  - ISP via COMM) Connect the JTAG debugger to the 10 pin Cortex Debug connector labeled J3 Connect the type-B end of a USB cable to the type-B recepticle and the type-A end of the cable to the USB receptacle on a PC Once the USB cable is connected to the board the following LEDs should be illuminated:     Power     All 8 LEDs in PIO2   LPC1768_MCB1700 (Keil MCB1700 development board) schematic: ./BSP/schematics/mcb1700-schematics.pdf   Jumpers:   E/U    = 1-2  (Ethernet/USB)   UMODE  = 1-2  (USB Device Mode)   D-     = Device   D+     = Device   VBUS   = 1-2   VDDIO  = 1-2   VDDREG = 1-2   Connect the JTAG debugger to the 20 pin JTAG or 10 pin Cortex Debug connector. Connect the type-B end of a USB cable to the type-B recepticle labeled 'Device' and the type-A end of the cable to the USB receptacle on a PC. Once the USB cable is connected to the board the following LEDs should be illuminated:     Power     100MHz     USC (LED indicates a USB soft connect from P2.9)    LPC11Uxx_LPCXpressoRevB (LPCXpresso LPC11Uxx on the LPCXpresso Rev B base board) schematic: ./BSP/schematics/lpcxpresso.lpc11u14.schematic.pdf   Running this example on the LPCXpresso LPC11U14 can be done one of two ways:   1. LPCXpresso LPC11U14 stand-alone       Connect the type-B end of a USB cable to the mini receptacle on the LPCXpresso board labeled J8 and the type-A end to the USB receptacle on a PC   2. LPCXpresso LPC11U14 plugged into the LPCXpresso base board Rev B       Plug the LPCXpresso LPC11U14 board into the connector labeled J4 on a LPCXpresso base board Rev B       Configure the base board according to the user's guide from Embedded Artists       Connect the mini type-B end of a USB cable to the receptacle on the base board labeled X1 and the type-A end to the USB receptacle on a PC       Once the USB cable is connected to the board the following LEDs should be illuminated:           LED25  (vbus)          LED26  (3.3v rail)         For both configurations the JTAG debugger is connected to the mini USB receptacle labeled J3 on the LPCXpresso LPC11U14 board   LPC17xx_LPCXpressoRevB (LPCXpresso LPC17xx on the LPCXpresso Rev B base board) schematic: ./BSP/schematics/LPCXpressoLPC1769revB.pdf   Running this example on the LPCXpresso LPC1769 can be done one of two ways:   1. LPCXpresso LPC1769 stand-alone. Solder a type-B USB receptacle onto the board and wire it up. See included schematics for details. Connect the type-B end of a USB cable to the receptacle on the LPCXpresso board and the type-A end to the USB receptacle on a PC   2. LPCXpresso LPC1769 plugged into the LPCXpresso base board Rev B. Plug the LPCXpresso LPC1769 board into the connector labeled J4 on a LPCXpresso base board Rev B. Configure the base board according to the users guide from Embedded Artists. Connect the mini type-B end of a USB cable to the receptacle on the base board labeled X1 and the type-A end to the USB receptacle on a PC.    Once the USB cable is connected to the board the following LEDs should be illuminated:       LED25  (vbus)       LED26  (3.3v rail)         For both configurations the JTAG debugger is connected to the mini USB receptacle labeled J3 on the LPCXpresso LPC1769 board. PC configuration Use a PC running Windows XP, Vista or 7 Connect the type-A end of the USB cable that is connected to the board into one of the USB receptacles on the PC Open a Windows File Explorer window Build and debug the example LPCXpresso IDE In the project explorer window of the IDE right click on the Example_MassStorageDevice project and select Debug As->C/C++ MCU Application In the main window of the IDE click Run->Resume to start running the application   Keil uVision 4 IDE In the Batch Build window, select the project targets as described in Compiler Build Configurations and then click Build In the main window of the IDE click Debug->Start/Stop Debug Session click Debug->Run   How this example runs and what to look for When the example is run and the board is connected to a PC with a USB cable it will enumerate on the PC as a mass storage device and show up in your Windows file explorer as a drive with the volume label "nxpUSBlib".   The drive will contain a single file called "README.TXT" which contains the text "This is a USB Memory Device demonstration. " Design notes This Mass Storage Device example defines a virtual drive size and a physical drive size. These numbers are defined in the file DataRam.h and look like this:   #define DATA_RAM_START_ADDRESS          0x20080000 #define DATA_RAM_PHYSICAL_SIZE            0xc00

Introduction This page gives more detailed information on how to use the IOH libraries in custom projects when using the LPCXpresso IDE. For more general information regarding using IOH libraries in custom project or for detailed instructions for Keil MDK and IAR EWARM, visit IOH: Getting started with IOH in custom projects. Ready-to-use examples can be found at the main I/O Handler page. Note: This guide assumes the IOH I2S library is to be added to a project, hence the 'I2S' references. For other IOH libraries, 'I2S' should be replaced with the library name. 1. Add the IOH library (libioh_*lpcxpresso.a) to the project The first step is to configure the LPCXpresso project to link against the IOH library. Open the project properties. Browse to 'Settings', then 'Libraries'. Add the library name (minus the 'lib' prefix) to the first box ('Libraries (-l)'), the library location to the second box ('Library search path (-L)'). 2. Add the path where the library's header file resides to the project’s include path The next step is to add the file location of the library's header file to the include path of the project. Still in the project properties, browse to 'Settings', then 'Includes'. Add the location to the 'Include paths (-I)' box. 3. #include the IOH header file in the source code of the application The IOH header file must be included in the source code of the project (e.g. main.c) by using the following preprocessor directive: #include "IOH_I2S.h" 4. Configure the linker to place the IOH related sections in the IOH SRAM All IOH parts have an SRAM region reserved for I/O Handler. When starting IOH, usually by calling the library's init() function, I/O Handler expects this memory region to be loaded with the IOH data provided by the IOH library. This means this data must be stored in Flash and copied to the IOH SRAM upon startup. A convenient way to do this, is by using scatter loading. With scatter loading, the linker and c-library are instructed to program certain data sections (IOH data) into Flash, and copy it to the specifed region (IOH SRAM) upon start up. This requires a linker script. When using LPCXpresso, this is taken care of automatically when selecting an IOH-enabled part and using the 'Manage Linker Script' option active 5. Enable the IOH SRAM (SRAM1) before C-library initialization The copying of data from the 'load region' to the 'execution region' when using scatter loading (explained above) is executed by the c-library just before main() gets called. It's important that both regions are enabled when the copying is initiated. After power-on, the IOH SRAM on the LPC11E/U37H is disabled (clock disabled in the SYSAHBCLKCTRL register), so it must be enabled before the scatter loading is initiated. The startup file included in LPCXpresso for IOH-enabled parts automatically enable the SRAM in time. 6. Interact with IOH via the library's API The final step is to interact from the application with IOH. This can be done through the library's API. Each library comes with an application note explaining how to use the library and what data structures and functions are available, and with one or more application examples showing how to use the library. This application note and application example provide an easy way to get started. They can be downloaded from the main I/O Handler page.

These examples show several possible uses for the DFUSec programming feature of the tool. LPC1857 single bootable image programmed in internal FLASH This example shows how to burn a snigle bootanle image into internal FLASH. When booting from internal FLASH, the boot address is 0x1A000000. The image has been linked for this address with data in IRAM. This operation requires a simple 1-step programming sequence. The operation will do the following: Erase just the area of internal FLASH dedicated to the bootable image (we'll use 64K starting at address 0x1A000000) Program the image (up to 64K) into address 0x1A000000 DFUSec configuration The image below shows the DFUSec configuration and a successful program cycle. This uses the LPC18xx/43xx internal FLASH programming algorithm. The 2nd file box contains the path/filename to the image file to program. The image file already includes the checksum and CRP. The address (0x1A000000) and size (0x10000) designate the erase region, program address, and maximum program size. Since the 'Erase region before programming' option is selected, the FLASH at address 0x1A000000-0x1A00FFFF will be erased prior to programming. After rease completes, the image will be sent to the board (in small chunks) and programmed into FLASH. If the image exceeds 64K (specified by the same size parameter used for region erase), an error will be generated, even if FLASH extended beyond the 64K limit specified. LPC1857 multiple images in internal FLASH This example shows how to burn multiple images into different location in internal FLASH. Although this example is shown using the Keil MCB1857 board, the example can easily be used to separately program (or update) M0 and M4 images into different location in internal FLASH for the LPC4350 dual core device! Either image can be updated later without erasing the entire device or the other image. This operation requires a 2-step programming sequence. Step 1 will erase the entire device and program image_1 into bank A. Step 2 will program image_2 into bank B. Optionally, with step 2, we can program image_2 into another area of bank A if needed. Step 1 DFUSec configuration The internal FLASH programming algorithm is used with the image_1.bin program file. Step 1 will erase the entire device (both bank A and B) before programming. Then image_1 will be placed at the bootup address (0x1A000000). We'll limit the image size to a maximum of 128K for programming. The configuration is show below: Step 2 DFUSec configuration The internal FLASH programming algorithm is used with the image_2.bin program file. Step 2 will place image_2 at the 2nd bank address (0x1B000000). We'll limit the image size to a maximum of 16K for programming. The configuration is show below: Screenshot of the completed DFUSec 2-step program operation

Introduction NXP Semiconductors provides a free Common Driver Library (CDL) software package for use with LPC32xx microcontrollers. This software package provides a generic set of drivers which highlight how specific peripherals and functions work. This software package also comes bundled with Board Support Packages (BSPs) for the Embedded Artists, Future Designs, and Phytec development boards which feature the NXP LPC3250 microcontroller. The BSPs includes startup code and examples which can be easily built and executed using any of the supported tool chains. Combined, the LPC32xx CDL and BSPs allow you to jump-start your LPC32xx microcontroller development. This software package is maintained by NXP Semiconductors and is periodically updated with issue fixes or new features. Features The free LPC32xx CDL and BSPs from NXP Semiconductors support the following features: Various drivers and header files for the LPC32xx microcontroller Common software for LPC32xx microcontrollers System startup code and various examples for the Embedded Artists, Future Designs, and Phytec LPC3250 development boards Tool-less software deployment options when used with the Stage 1 Loader (S1L) Support for IAR Embedded Workbench, Keil uVision4, ARM Realview 3.x, and GNU CodeSourcery tool chains Free for use with NXP LPC32xx microcontrollers Documentation LPC32x0 CDL and BSP Startup Code Documentation   Software The LPC32xx CDL and BSPs are free to NXP customers for unlimited use with the NXP LPC32xx microcontrollers. By downloading or using the LPC32xx CDL or BSPs, you agree to use it solely with these NXP microcontrollers. LPC32xx CDL and BSPs V2.01 Pre-Built Bootloaders for the Embedded Artists Board V2.01 Pre-Built Bootloaders for the Future Designs Board V2.01 Pre-Built Bootloaders for the Phytec Board V2.01   More Information Disclaimer This software is provided AS-IS by NXP Semiconductors. NXP Semiconductors does not support or warrant the software contained herein for any purpose other than for informational use. References Embedded Artists Future Designs PHYTEC America ARM CodeSourcery IAR Keil

NXP Smartphone Quick-Jack Solution Transform the audio jack of a smartphone into a multi-purpose, self-powered data port. This hardware/software platform, designed for use with iPhone® and Android® smartphones, is the simplest way to design compact sensor peripherals that use the phone’s audio jack for data and power. Whether you are a Smartphone App Developer looking for an easy way to add cool context-aware features to your next app or an End product designer looking for simple way to Monitor or control sensors, the new NXP Smarphone Quick-Jack solution will make it easy to connect external devices to smartphones for self-powered data communications. It gives smartphones app developers an easy way to add context-aware app features, input user or environment data, or connect peripherals and provides end-product designers instant access to smartphones’ convenience, appealing UI, and cloud connectivity, with unmatched simplicity for endless applications. Compatibility The current version of the OM13069 Quick-Jack solution has been tested with the following devices: • iOS: iPhone 4, iPhone 4S, iPhone 5, iPhone 5S • Android: Samsung Galaxy S3. It is not guaranteed to work with other devices. Quick-Jack Solution quick start guide and Application Note: The NXP Smartphone Quick-Jack Solution quick start guide can be found at:  http://www.nxp.com/documents/user_manual/UM10815.pdf The Chinese version of the NXP Smartphone Quick-Jack Solution quick start guide can be found at:  http://www.nxp.com/documents/user_manual/UM10815_ZH.pdf The NXP Smartphone Quick-Jack Solution Application Note can be found at:  http://www.nxp.com/documents/application_note/AN11552.pdf The Chinese version of the NXP Smartphone Quick-Jack Solution Application Note can be found at: http://www.nxp.com/documents/application_note/AN11552_ZH.pdf Useful Links For more information on the solution kit and how to order it please visit: http://www.nxp.com/demoboard/OM13069.html For more information on the LPC812 Series please visit: http://www.nxp.com/products/microcontrollers/cortex_m0_m0/lpc800/ For the LPC800 Promotional web page please visit: http://www.nxp.com/campaigns/lpc800-go/ To Download your iPhone App into your Phone, use this link: https://itunes.apple.com/us/app/nxp-quick-jack/id854875264?mt=8 To Download your Android App into your Phone, use this link: https://play.google.com/store/apps/details?id=com.nxp.HijackU To Download the leaflet use this link; http://www.nxp.com/documents/leaflet/75017571.pdf  To see the Hi-Jack project web page from the University of Michigan, use this link; http://web.eecs.umich.edu/~prabal/projects/hijack/ To Download the Press Release use this link; http://www.nxp.com/news/press-releases/2014/05/nxp-unveils-smartphone-quick-jack-solution-transforming-audio-jack-into-multi-purpose-self-powered-data-port.html Note Concerning iOS Source Code By rule, iOS source code is not allowed to be distributed on public web sites.  Please contact NXP at our technical support centerto inquire about iOS source.

The Future Designs LPC3250 based board ships with u-boot pre-installed. However, the kickstart loader and S1L can be installed on Future Designs LPC3250 boards. This will allow easier upgrade of the boot loader and the additional features and capabilities offered by S1L. Once installed, the kickstart loader resides in NAND block 0 and is loaded into IRAM with the LPC32x0 boot ROM on chip reset. Control is then transferred to IRAM after the kickstart loader is loaded. The kickstart loader then loads S1L from block 1 and on of NAND FLASH into IRAM. Once S1L is loaded, control is transferred to S1L. The kickstart loader concept and S1L are explained in more detail in the CDL boot loaderspage. S1L can be setup to load another application in IRAM or SDRAM. For Linux, u-boot can be setup to load and run in SDRAM at address 0x81fc0000. However, S1L isn't required and the kickstart loader can be built to load u-boot directly from NAND FLASH into SDRAM.

Introduction The MicroCore48/64/100 has been developed to evaluate, test and demonstrate general purpose Microcontrollers from NXP Semiconductors.  The Microcore48/64/100 demo, evaluation and test board supports NXP’s 100 pin (or less) Cortex M0/M0+/M3 based microcontrollers (LPC800, LPC1100, LPC1200, LPC1300, LPC1500 and LPC2100 family).  Special adapter boards are available to support a wide range of ARM Cortex based microcontrollers in different packages, like: LPC81x LPC111x, LPC11A1x, LPC11Cxx, LPC11E1x and LPC11Uxx LPC131x and LPC134x LPC151x and LPC154x   Main features of the MicroCore48/64/100 - Wide supply range of 0V to 3.6V    o Via primary USB (Vbus) 3.3V    o Via secondary USB (Virtual COMM Port) 3.3V    o Via pins (f.i lab supply) 0 - 3.6V - Additional supply of 1.8V available - Exchangeable external crystal - Every pin of the Microcontroller contains a measure point and jumpers to (dis)connect it from the on-board peripherals - Serial In-System Programming (ISP) is possible - One RS232 buffered serial communication interface is provided to connect the MicroCore48 to a PC (or terminal) - USB communication port interface is implemented    o Soft or hardware USB connect possibility - USB to serial (Virtual COMM port) interface is implemented - I2C bus I/O expander and 256 bytes EEPROM is implemented - SPI bus Real Time Clock with temperature sensor, watchdog, time stamp and internal crystal is implemented - SPI bus RF module for wireless communication is implemented - CAN bus interface is implemented - Digital IO is implemented    o 3 push buttons, one with RC network and one for external RESET    o 8 LED’s (connected to I2C I/O expander) - Analogue inputs to micro’s AD converter    o 10k potentiometer is implemented to divide the 3.3V Vdd    o Photo transistor for ambient light sensing   Functional Blocks NXP’s Microcontroller Central part of the MicroCore64 board is the microcontroller. It can be mounted directly (at the LQFP64 footprint), with a test socket from Yamaichi type: IC149-064-69-B5 or with the use of an adapter board placed over headers X1, X3, X5 and X7. Every pin of the micro contains a  measure point and a jumper (at X2, X4, X6 and X8). This allows the user to connect or disconnect every single pin from the on-board peripherals and power signals. RS232 The MicroCore64 contains a MAX3232CSE device and a 9-pin sub D connector for the RS232 interface between a PC (terminal emulator) and the on-chip UART of the microcontroller. The RS232 port can be directly connected to a PC COMx port with a standard serial cable, with a female 9 pin sub D connector. Note that jumpers J2 and J3 have to be set correctly. I2C The MicroCore64 kit also contains an NXP - PCA9500 I/O expander and 256 bytes EEPROM with I2C bus interface. The PCA9500's I2C address is determined by both a fixed on-chip mask address and by external hardware wired links on the MicroCore64. These hardware wired links are all grounded, resulting in an I2C device address for the IO expander of 0x40 and an I2C device address for the EEPROM of 0xA0 All (eight) I/O port pins are used to drive LEDs. These are also connected to pin header X11, to optionally connect the LEDs directly to port pins of the Microcontroller. SPI0 The MicroCore64 kit contains an NXP - PCF2129A device (RTC) with SPI interface, connected to the on-chip SSP0 interface of the microcontroller. SCK is connected to pin 41, SDI to pin 37 and SDO to pin 36. Chip Enable (Slave Select) is software controlled and connected to pin 34. The PCF2129A Interrupt output, Clock output and the Time Stamp input are available at 3 pin header P4. SPI1 The board contains a connector (X15) for an RFM12 module from Hope. This module is a low cost ISM band FSK transceiver module implemented with unique PLL. It works within signal ranges from 315/433/868/915MHZ bands and complies with FCC and ETSI regulations. The SPI interface, used to interface with a microcontroller for parameter settings, is connected to the on-chip SSP1 interface (if available). SCK is connected to pin 57, MOSI is connected to pin 51 and MISO is connected to pin 35. SS_RFM is connected to pin 49. The interrupt request output is connected to pin 50. For more info about the RFM12 module visit: http://www.hoperf.com/rf_fsk/cob/RFM12.htm. USB (device) Some micro’s like the LPC1347 and LPC11U24 do have an on-chip USB device controller. For that reason the board contains a USB interface to connect it to a host. Next to a USB type B connector a switch for the soft connect feature of the micro is provided (Q1 – PDTA114 plus yellow LED D10). VBUS of this interface can be used to supply power to the MicroCore64 (check J1). Power The Microcore64 board can be powered in three ways. Either using VBUS (5V) of one of the two USB connectors (jumper J1 to determine, see figure above), or directly (using a lab supply) at the center pin of J1 or at the 3V3 and GND header pins (P2 and P3). If powered over VBUS then green LED D1 indicates power present. To support LPC2100 parts an additional 1V8 supply is available at the board (P7).   XTAL The external crystal is mounted on a 3 pin female header (Y1). Middle pin is connected to GND for easy interchanging crystals or resonators. The load capacitors C4 and C5 can be replaced by other ones by unsoldering/soldering. USB (VCP) The board contains an FT232RL device from FTDI to provide a USB virtual com port interface between a host PC and the on-chip UART of the micro. Note that jumpers J2 and J3 have to be set correctly. VBUS2 can be used to power the MicoCore64. VBUS2 is also used to generate a 1V8 supply, available at P7. This supply is needed to support LPC2100 devices (like LPC2129). CAN bus Parts like the LPC2119 have an on-chip CAN interface. To support CAN the board contains a TJA1040 CAN transceiver and a 9 pin male sub D connector. To connect the CAN pins of the micro pin header P5 can be used. To bypass the transceiver (for example with an LPC11C24) pin header P6 can be used. Analog Inputs The MicroCore48 board contains a 10k potentiometer (R20) to provide an analog input to the micro. This input is available at pin 44 of the micro (AD1 input). A second analog input signal is generated by a photo transistor (Q2 - BPW85C) and is available at pin 45 of the micro (AD2 input). This input can be used as a light sensor. RESET, BOOT and WAKE UP The MicroCore64 contains three pushbuttons. S1 (plus RC network) used as RESET, S2 used as BOOT (to force the micro into ISP mode) and S3 connected to pin 53 of the micro (could for example be used to wake up the micro from a power reduction mode). LED Indicators Besides the eight red LEDs connected to the I2C IO expander the MicroCore64 contains two additional red LEDs (D11 and D12) connected to pin 14 and pin 15 of the microcontroller. SWD (Serial Wired Debug) The MicroCore64 is equipped with the commonly used 10 pin SWD connector. The debug interfaces from Keil uLink and IAR / Segger JLink can be used with this board. For evaluation of LPC2100 devices a separate JTAG connector is provided at the socket adapter board.

The LPC247x microcontrollers have integrated LCD controllers. These microcontrollers support Super-Twisted Nematic (STN) and Thin-Film Transistor (TFT) graphic display panels up to 1024 x 768 pixels, from monochrome up to 24-bit true-color, and with hardware cursor support. This capability is ideal for point-of-sale, industrial, and medical/diagnostic applications. Further, the LCD controller supports Windows CE data formats. Below are LPC247x-based design examples for a selection of common LCD daughter cards. The designs use an LPC247x Validation Board to carry LPC247x-related signals to the LCD daughter card. Each daughter card provides connectors to the universal LCD connector on the LPC247x Validation Board. Also included are LPC247x configuration codes (IAR EWARM), schematics, gerber files, and BOM's for each LCD module. LCD Technology Color Depth Resolution Manufacturer Model STN 4-bit B/W QVGA (320x240) Optrex DMF50840 TFT 18-bit WVGA (800x480) Hantronix HDA700L TFT 24-bit QVGA (320x240) Innolux PT035TN01V6 ADTFT 24-bit TFT QVGA (240x320) Sharp LQ035Q7DB03 Block Diagram Products Below are recommended microcontrollers for use in implementing this design to a system. Comparison Table Product Flash SRAM External Bus 10/100 Ethernet USB 2.0 CAN LCD Controller SD/MMC Package(s) LPC2470 0KB 98KB Full 32-Bit 1 1 2 Y 1 LQFP-208 TFBGA-208 LPC2478 512KB 98KB Full 32-Bit 1 1 2 Y 1 LQFP-208 TFBGA-208 LCD Daughter Cards Optrex LCD Board Datasheet Optrex LCD Board Schematics Optrex LCD Board Example Code Optrex LCD Board Gerber Files Optrex LCD Board Bill of Materials Click here to download Hantronix files (attached) Hantronix LCD Board Datasheet Hantronix LCD Board Schematics Hantronix LCD Board Example Code Hantronix LCD Board Gerber Files Hantronix LCD Board Bill of Materials Click here to download Innolux files (attached) Innolux LCD Board Datasheet Innolux LCD Board Schematics Innolux LCD Board Example Code Innolux LCD Board Gerber Files Innolux LCD Board Bill of Materials Click here to download Sharp files (attached) Sharp LCD Board Datasheet Sharp LCD Board Schematics Sharp LCD Board Example Code Sharp LCD Board Gerber Files Sharp LCD Board Bill of Materials More Information Click here to download LPC247x Validation Board (attached) LPC247x Validation Board Schematics LPC247x Validation Board Gerber Files LPC247x Validation Board Bill of Materials

This is the uCOSIII port for LPC43XX based hitex board with revision A4. The BSP and the applicaton code for the port is attached below. The tools supported to build the package are: a) Keil uVision. It has been tested with V4.53.0.0 There are three attachments on the page containing i)The BSP,application and the CPU port files. ii)OS port for the core. iii) A png file showing the directory structure of the project. Here is a set of instructions to build and test the port: 1) Unzip the uCOSIII_Port.zip attachment and you should have "EvalBoards" and "uC-CPU" folders.Place them in your convinient folder. 2) Download uCOSIII source from http://micrium.com/page/downloads/download_os-III_source_code 3)You should now have a "Source" folder containing uCOSIII sources. Place this folder in The directory structure should look like the one shown in the attached png file. 4)Now, find the project file at 5)Double click "hitex4350_tcpecho_uCOSIII.uvproj" which opens the project. Go ahead and build the project for the required target. 6) Connect the Target "Hitex board" with J-Link. And Power it ON. You can either power it with USB or external supply. The default project is setup to use JLink. 7) You can download the image to the IRAM or flash depending on the target you have built. 😎 Run the image, you should be able to ping and telnet it.( This project uses static IP, so change your IP according to your need in the main.c file before building the image)

The LPC1500 microcontroller series are optimized for fast, easy, and high-precision motor control. Incorporating all the features required for high-accuracy sensored and sensorless motor control, the LPC1500 enables simultaneous control of multiple motors in highly flexible configurations. Based on the ARM® Cortex™-M3 processor, the LPC1500 series has two 12-bit, 12-channel, 2 Msps ADCs and an on-chip quadrature encoder interface (QEI) to enable highly accurate control of both sensored and sensorless motor combinations. With four on-chip comparators enable fast-response over-current/voltage monitoring and protection and four flexible SCTimer/PWM timers to provide up to 28 PWM channels in a tightly coupled analog and timing subsystem with minimal load on the CPU, the LPC1500 are ideal for use with a wide range of brushless DC (BLDC) motors, permanent-magnet synchronous motors (PMSM), and AC induction motors (ACIM) commonly found in products such as large home appliances, HVAC, industrial pumps and generators, and more. They are also well suited for industrial applications requiring high-precision data sampling and real-time control, such as digital power and instrumentation. The LPC1500 microcontrollers are fully supported by the LPC software ecosystem and an extensive collection of tools, drivers and middleware. With ultra-efficient motor control firmware, easy-to-use GUI-based tuning tools, and two new motor control solution kits, NXP's LPC1500 microcontrollers simplify evaluation and development of motor control applications, without requiring deep motor control experience.   Features of LPC1500 : 72 MHz ARM Cortex-M3 processor Upto 256 kB on-chip flash programming memory Upto 36 kB SRAM 4kB EEPROM Memory Protection Unit(MPU) USB/SPI/I2C drivers DMA drivers C-CAN drivers Four SCTimers/PWM Two 12-bit ADC and One 12-bit DAC   Brushless DC Motor (BLDC) Solution The LPC1549 Brushless DC motor control solution helps you get started with motor control protoyping immediately.  It utilizes the SCTimer/PWM available on the LPC1549 MCU for the motor operation.The SCTimer/PWM combines the features of a timer and a state machine making possible to develop sophisticated solutions in the digital control field. The project is implemented on the LPC1549 BLDC Motor Control Kit, which includes an LPC1549 LPCXpresso board. The joystick present on the motor control kit is used to control the speed and direction of the motor. It is possible to define a more complex sequence of events, having the SCTimer/PWM evolve autonomously through the state machine over time, in response to the time-based or I/O defined events. This typically implies that less CPU interventions are needed, since the SCTimer/PWM is able to handle most of the control sequence in hardware. Using the SCTimer/PWM also reduces the code size. The firmware package contains the project implemented in Keil IDE. The package also contains an application note which decribes the motor control operation using the SCTimer/PWM in detail.     Permanent-Magnet Synchronous Motor (PMSM) Control Solution The LPC1549 PMSM motor control solution provides a Field-Oriented Control (FOC) example to get you started with motor control prototyping. This example utilizes the QEI feature on the LPC1500 to monitor the position and velocity of the motor for both sensor and sensorless modes. The additional advanced features of the LPC1500 including the SCTimer/PWM and high speed ADC ensures easy and reliable control of time critical peripherals, and a mechanism for sychronization of the ADC's with the PWM for exact timing of the sample moments. FOC is a more advanced approach where each phase is driven sinusoidally and permanently powered so the magnetic field inside the motor is regulated to the most optimal value.  The project is implemented on the LPC1549 PMSM Motor Control Kit, which includes an LPC1549 LPCXpresso board. The firmware package contains the project implemented in IAR IDE. The package also contains an application note which decribes the motor control operation using the QEI and SCTimer/PWM in detail. This solution also comes with a GUI interface, which is developed to tune motor parameters in FOC firmware.                                           FOC Control Block Diagram                                                      GUI Interface   Motor Control Solution Overview Video Useful Links : LPC1500 MCU Product Pages LPC1549 LPCXpresso Board LPC1549 BLDC Motor Control Kit  (OM13068) LPC1549 PMSM Motor Control Kit (OM13067) LPC1500 Datasheet LPC1500 User Manual

To build a project for Keil, select the uvproj file for the example you want to build and deploy. The project will open up in the Keil uVision4 IDE. For the project, select the build variant you want to build. Press F7 to start the build. The image can be programmed into the board's internal FLASH (if it's a FLASH image) using the Flash menu and selecting Download. Optionally, you can download and debug the program using the Debug menu and selecting "Start/stop debug session". Note you need a Keil ULINK JTAG/SWD debugger to debug or download code. If you get an error attempting to program FLASH, check that the FLASH algorithm selected for the device is correct by selecting the FLASH menu and then selecting the Settings box. On the Flash Target driver setup display, select the LPC17xx IAP 256K Flash algorithm for programming. If a debugger isn't available, you can use Flash Magic with the created hex file to burn the image into the board. Before attempting to run Flash Magic, make sure the LPC17xx device is in ISP mode by holding down the SW6 while pressing and releasing the reset button.

This section explains the LPC32x0 boot process for the various non-volatile memory types or the UART. Depending on the boot device, there may be limitations to the boot image size. This limitation may prevent a desired image from initially loading and executing – instead requiring a smaller boot loader to be loaded first and then using it to load and run a more capable boot loader or application. LPC32x0 boot options The LPC32x0 supports booting from small and large block NAND FLASH, SPI EEPROMS or FLASH, NOR FLASH, and via the UART. In production systems, the UART boot method isn't used. However, the UART boot method serves a useful purpose in early board debug, The boot order for the LPC32x0 is as follows: UART, SPI, NOR, NAND. UART boot can be disabled to reduce boot time. Each boot device will be tried prior to the next device. A device is bootable if the boot ROM locates a special boot pattern that identifies the device as bootable. It's possible that a system can have SPI FLASH, NOR FLASH, and NAND FLASH and only boot from NAND FLASH although the SPI and NOR methods are attempted first. (For example, the Phytec 3250 board has all 3 of these boot devices, but normally boots from NAND FLASH). When the LPC32x0 chip is reset, the internal boot ROM is executed. It queries each device looking for a special boot pattern used to identify the device as bootable. The first device that returns a correct pattern will be used by the boot ROM as the bootable device. The boot ROM will then either copy data from the bootable device (NAND and SPI FLASH) or transfer control to the bootable device (NOR FLASH). Each boot method is explained in the following sections. See the LPC32x0 User's guide for more information on the LPC32x0 boot process. UART boot The UART boot option allows a binary to be downloaded into the board and then executed prior to any code running in NAND, SPI, or NOR FLASH. This is useful for burning new images into FLASH, testing simple applications, or recovering the board from corrupt boot code. UART boot is used with the burner tools in the CDL package to program the bootloader(s) into the boot device. UART5 is supported with the UART boot option, so new designs should make UART5 available for debugging. For a system that entirely runs from IRAM, this allows a system to download an image via the UART that provides interactive access once the image is executed. The downloaded interactive program can be used for bandwidth or memory tests, register dumps, further image loading, or other functions. Initial versions of S1L can be used with this boot method to test different SDRAM configurations using the included SDRAM initialization code. Using this approach, startup and debug of the SDRAM code (one of the tougher issues of bringing up a new board) can be drastically simplified. NOR FLASH boot On a system that boots from NOR FLASH, the ARM core directly executes code from the NOR FLASH device starting at address 0xE0000004. The first 4 bytes at address 0xE0000000 are used for the special boot pattern value required by the boot ROM to identify the device as bootable and to provide the boot width (8, 16, or 32 bits). SPI FLASH/EEPROM boot On a system that boots from SPI, a small image is copied from the SPI EEPROM or FLASH device at offset 0x8 into IRAM at address 0x00000000. The first 4 bytes are used for the special boot pattern value required by the boot ROM. The next 4 bytes are used to designate the size of the image to load at offset 0x8 in the SPI device. After the image is loaded into IRAM, control is transferred to address 0x00000000. The maximum image boot size that can be loaded with this method is 54K. NAND FLASH boot On a system that boots from NAND FLASH, a small image is copied from block 0 or block 1 of the NAND device into IRAM at address 0x00000000. The maximum bootable image size for NAND FLASH boot is 54K, or 1 block minus 1 page, whichever is smaller. The first page of the boot block is used to store boot information, such as the boot image size and values needed by the boot ROM used for the boot sequence. For small block NAND (32 pages per block and 512 bytes per page) with the first page of the block dedicated to the boot ROM boot information, the maximum boot size is 31 pages of 512 bytes per page, or 15.5K. For large block NAND (64 pages of 2Kbytes per page), the maximum boot size is 54Kbytes. The boot ROM always uses the MLC NAND controller for NAND boot. This requires the boot image booted from NAND by the boot ROM to be programmed into NAND with the MLC NAND controller or with the ECC algorithms required by the MLC NAND controller.

The LPC32x0 boots from SPI FLASH first, NOR FLASH second, and NAND FLASH last. The LPC32x0 will always attempt to boot from the first valid boot source based on a special boto pattern located at the start of the FLASH device. If you need to erase one of these FLASH boot sources, the procedure below can be used. Step 1: Download the pre-built boot software and restoration images for the Phytec LPC3250 board from the Resource page. Step 2: Extract the files on a Windows based PC Step 3: Connect a serial cable between the Phytec boards' lower serial connector and the PC Step 4: Start the Serial loader software (LPC3250_Loader.exe) included in the pre-built boot software package. Step 5: Setup the 'Primary boot (IRAM)' file in the Serial loader to one of the eraser binary image files. To erase NOR FLASH, use the eraser_nor_rvw.bin file. For SPI FLASH, use the eraser_spi_rvw.bin file. For NAND FLASH, use the eraser_sb_nand_rvw.bin file. Verify that the Comport control selection matches the COM part on the PC that is connected to the Phytec board. The example below shows the configuration for erasing NOR FLASH. NOTE: The pre-built binaries may have slightly different names than those listed in step 5, depending on the tool used to build the binaries. If the binaries were build with GNU instead of Realview, the 'rvw' field in each name will contain the 'gnu' identified instead. Change the file names as necessary for you binaries you have.

A simple programming API is available that allows custom development of programming algorithms for different memory types such as NOR or NAND FLASH or EEPROM based memory. By mixing programming algorithms and different program images as different steps with the DFUSec tool, a single programming sequence could program all non-volatile memories and memory regions in a single DFUSec programming cycle via USB! This section explains the process of creating a new programming algorithm. Programming algorithm creation process A programming algorithm is an executable program that runs on the target hardware and is download via DFUSec to the board using the LPC18xx/43xx's DFU boot capability. Each programming algorithm has unqiue code for handling the memory it will program. To create a new programming algorithm requires the following steps: Download the DFUSec programming API examples (here). This provides the DFU streaming code that calls the programming API, several reference drivers (emulated IRAM, internal FLASH, SPI FLASH), and several projects to build an executable programming algorithm image. The examples require the LPC18xx CMSIS library attahced below. Although the example builds inside the LPC18xx CMSIS source tree, the generated binaries should executed on the LPC43xx device (as it's using the M3 instruction set) with common peripherals. Write a new driver for the new memory type with the supported API functions Compile the driver with the DFU streaming code to get a programming algorithm executable in binary form Using the DFUSec RAW/HDR mode tab, generate a binary with a header attached to it Programming API functions The dfusec_programming_api.h header file contains the function prototypes and shared data structures that must be developed for the DFU streamer code driver. The driver requires one global function that initializes the non-volatile memory interface and device and prepares the data structure that defines the non-volatile's devices memory regions and callback functions. The structure provides five additional functions (via indirect calls) that handle region erase, full erase, program, verify, and address check.Not all of these functions are required to do something. Programming API - algo_flash_init() function The first function that needs to be provided is the algo_flash_init() function. This function is called by the DFU streamer to initialize the non-volatile memory device, return the pointer and size of the DFU streaming buffer, and return the FLASH configuration structure and callbacks.The function has the following prototype:/* Initializes device programming capability */ DFUPROG_REGION_T *algo_flash_init(void **buffer, int32_t *buffer_size); style="color:rgb(100, 100, 100);font-family:Arial, sans-serif;font-size:12px" The buffer size must be a multiple of 64 bytes (DFU max packet size) typedef struct {     int32_t num_regions; /* Number of program regions on the device */     /* Buffer should be 32-bit aligned */     void *buffer;     /* This must be a minimum of 64 bytes or DFU max packet size and must        be a factor (1x, 2x, 3x, etc.) of max packets size */     uint32_t buffer_size;     const PROGALGOS_T *pprogalgos;     const DFUPROG_REGZONE_T *pregions; /* Address and region size array */ } DFUPROG_REGION_T; /* Function pointer types and function array */ typedef int32_t (* progalgo_flash_erase_region) (uint32_t, uint32_t); typedef int32_t (* progalgo_flash_erase_all) (void); typedef int32_t (* progalgo_flash_write) (uint32_t, uint32_t); typedef int32_t (* progalgo_flash_verify) (uint32_t, uint32_t, uint32_t); typedef int32_t (* progalgo_verify_range) (uint32_t, uint32_t); typedef struct {     progalgo_flash_erase_region erase_region;     progalgo_flash_erase_all    erase_all;     progalgo_flash_write        write;     progalgo_flash_verify       verify;     progalgo_verify_range       vrange; } PROGALGOS_T; Shared DFU streamer programming info structure /* Programming info received from DFUSec for a specific step */ #define DFUPROG_VALIDVAL 0xDB001843 typedef struct {     int32_t stepnum;         /* Step number, 0 - 9 */     uint32_t imagesize;      /* Size of image in bytes */     uint32_t address;        /* Address to start programming of image or start of erase */     int32_t regionsize;      /* Size of region to erase for 'eraseregion' */     int32_t eraseregion;     /* Erase region flag, will erase region if !0 */     int32_t erasefulldevice; /* Erase full device if !0 */     int32_t parameter;       /* Optional parameter value */     uint32_t validatetag;    /* Must be value of DFUPROG_VALIDVAL */ } DFUSEC_PROGINFO_T; extern DFUSEC_PROGINFO_T dfusec_proginfo; Building the programming algorithm The currently available pre-configured projects for building the programming algorithms are only available for the Keil uVision4 toolchain. To build the project with your driver, open one of the pre-configured projects and replace the file under the DFUSec_programming_algorithm group with the new driver. Click build to compile and link the image. The final result of the build cycle will be a binary image with a .bin extension. Adding UART log output support to the programming algorithm LPC18xx/43xx DFUSec programming API tool Build date: Jul 19 2012:15:03:24 Initializing USB interface Initializing DFU Connecting USB stepnum         = 0 imagesize       = 4724 address         = 10080000 regionsize      = 00004000 eraseregion     = 0 erasefulldevice = 0 validatetag     = db001843 Program cycle complete Appending a header to the programming algorithm binary The final step in preparing the programming algorithm for use with the DFUSec tool is to append a boot header to the binary file generated in the previous step. The DFUSec tool cannot boot the binary directly and requires this header. To generate the header, run the DFUSec tool and click on the HDR/RAW modes tab. For the binary box, select the .bin file to create the header for. Then click the "Generate binary file with header" button to generate a new file. A new file will be created in the same directory as the .bin file with the .hdr extension. This .hdr file is you programming algorithm file that should be used with the Algo box in the Program mode tab with DFUSec.

To use SWIM in Linux, SWIM must have direct access to the frame buffer memory in Linux. This can be done by accessing the /dev/fb device and mapping virtual memory to the device that SWMO will be used. The basic code snippet below shows how to do it. #define XSIZE 240 #define YSIZE 320 int fbdev; Uint16 *fb; /* Assumes frame buffer is 16-bit data */ /* Open frame buffer device */ fbdev = open("/dev/fb0", O_RDWR); /* Get mmap'd pointer to frame buffer */ fb = (Uint16 *) mmap(0, XSIZE * YSIZE * sizeof(Uint16), PROT_WRITE, MAP_SHARED, fbdev, 0); After this code is executed, the variable 'fb' will point to a usable frame buffer in memory that can be directly written to and read from in the Linux application. The next step is to initialize the SWIM window for the size of the display. SWIM_WINDOW_T win1; /* Create window with black background and no border */ if (swim_window_open(&win1, XSIZE, YSIZE, fb, 0, 0, XSIZE - 1, YSIZE - 1, 0, WHITE, BLACK, WHITE) == 0) { fprintf(stderr, "Error opening chat window\n"); close (fbdev); return -1; } /* select the font to use */ swim_set_font(&win1, (FONT_T *)&font_winfreesys14x16 ); /* set the pen color to use */ swim_set_pen_color(&win1, WHITE); A title bar can be easily added to the window. swim_set_title(&s1, "SWIM window demo", LIGHTGRAY); All objects in the window are drawn using logical window coordinates. Positions for pixels/lines and text are independent of each other, so you can draw some text, then do a line, and then if you draw text again, it will place the next where the previous text output ended before the line was drawn. /* Draw a simple box */ swim_put_line(&win1, 10, 10, 50, 10); swim_put_line(&win1, 50, 10, 50, 50); swim_put_line(&win1, 50, 50, 10, 50); swim_put_line(&win1, 10, 50, 10, 10); With Linux, finish the application by closing the frame buffer device. close (fbdev); The SWIM library and application note can be found here.

Introduction This page gives a quick overview of the available IOH libraries. A description of the library, its specifications and its requirements are summarized on this page. The the following downloads are attached to the community post below. Full library documentation. The IOH pre-compiled libraries. 1 or more application example source-code/projects per library (LPCXpresso, Keil MDK, IAR EWARM). The following libraries are currently available: Serial-interface emulation DALI I2S master I2C master UART CPU-cycle saving libraries CRC Windowed Comparator DMA The serial-interface emulation allows easy addition of one more serial interface to the LPC11x37H microcontrollers.The CPU-cycle saving libraries offer CPU-offloading for certain tasks, which can be used for lower power consumption (ARM core put in sleep mode), or for high performance (ARM executing other tasks in parallel). DALI The I/O Handler DALI library provides functionality to emulate a DALI master using the I/O Handler hardware block. DALI is a technical standard for network-based systems that control lighting in e.g. building automation. The IOH library allows to handle a large portion of the DALI standard autonomously by the I/O Handler peripheral with zero to very little CPU load.The library integrates a large portion of the DALI interface. The easy-to-use API is non-blocking and only passes the data to be transmitted to the I/O Handler.After a transfer has been initiated, the I/O handler takes care of the Manchester encoding and generation of edges on an I/O pin without any CPU involvement. The IOH ensures the mandatory wait time (settling time) between frames is honored and keeps track of the DALI input pin to watch for any response. Besides the supported polling mode to test if a transmission has finished, an interrupt is also generated at the end of every transmission. Data indicating whether the slave has send back a response and what this response is, can be accessed through another API call. Specifications Master mode only (a future library update may add slave support). Manchester encoding/decoding, pin I/O and settling time all handled by IOH with zero CPU load. Support for both polling mode and interrupt mode. Configurable Rx/Tx polarity. This allows using both inverting and non-inverting DALI bus drivers. Requirements Library is designed for the LPC11E37H and the LPC11U37H. Requires 1.5kB Flash storage. Counter/timer module CT16B1 is used by IOH and is no longer available to the ARM core. Pinning DALI Function Description Pin TxD DALI transmit data output PIO1_6/IOH_16 RxD DALI receive data input PIO1_7/IOH_17 I2S master The I/O Handler I2S library allows emulation of a basic I2S master (transmit only). I2S (Inter-IC Sound) is an electrical serial bus interface standard used for connecting digital audio devices together. It is used to communicate PCM audio data between integrated circuits in an electronic device. The IOH library allows emulation of a basic I2S master while not loading the CPU heavily with this task. The required CPU activity for this task is limited to ensure the data is available in the buffer in time for IOH to read it.After configuring and starting the I2S emulation, the I/O Handler continuously reads a 1kB data buffer and transmitting this buffer over the emulated I2S interface. After reading/transmitting the entire buffer, it wraps-around and begins reading/transmitting from the top of the buffer, thereby creating a continuous stream of data. An interrupt is asserted every time when the first half of the buffer has been read, and when the second half of the buffer has been read. This allows the CPU to fill the half of the buffer which is not being accessed by IOH with new data. Specifications Master mode only. Configurable for either I2S transmit or receive functionality (simultaneous transmit/receive not supported). 2 channels, 16-bit per channel. Loops over a 1kB data array. Requirements Library is designed for the LPC11E37H and the LPC11U37H. Requires 1kB Flash storage. Requires usage of one of any of the available timer modules (CT16B0, CT16B1, CT32B0 or CT32B1). Selected timer module is no longer available to the ARM core. Pinning I2S Function Description Pin SCL I2S bit-clock Any external match output pin of the selected timer (e.g. CT16B1_MAT0, CT32B0_MAT3, etc) WS I2S word-select output Configurable, following pins can be selected: IOH[7:0] TX_SDA I2S data output Configurable, following pins can be selected: IOH[7:0] RX_SDA I2S data input Configurable, following pins can be selected: PIO1_5/IOH_15 or PIO1_6/IOH_19 SCL_In I2S bit-clock input (requires to be connected externally to the SCL signal) Configurable, following pins can be selected: PIO0_8/IOH_6,  PIO1_6/IOH_16 or PIO1_27/IOH_20   I2C master The I/O Handler I2C library provides functionality to emulate an I2C master using the I/O Handler hardware block. The I2C bus was designed by Philips in the early ‘80s to allow easy communication between components which reside on the same circuit board. The IOH library allows I2C communication fully handled by IOH, with zero CPU load after a transfer has been initiated. The easy-to-use API is non-blocking and only passes the data to be transmitted to the I/O Handler.After a transfer has been initiated, the I/O Handler handles the full I2C transfer with zero CPU-load. The IOH interrupt is asserted when a transfer has been completed. The API supports functions like I2C write, I2C read and I2C read/write. Specifications Master mode only. Repeated start supported. Clock stretching supported. Bit rate up to 300Kbps for 48MHz CPU clock. Support for both polling mode and interrupt mode. Multi-master not supported. 10-bit address not supported. Requirements Library is designed for the LPC11E37H and the LPC11U37H. Requires 1.5kB Flash storage. Counter/timer module CT16B1 is used by IOH and is no longer available to the ARM core. Pinning I2C Functions Description Pin SDA I2C data input/output Configurable, following pins can be selected: PIO1_[31:0] SCL I2C clock output Configurable, following pins can be selected: PIO1_[31:0]     UART The I/O Handler UART library provides functionality to emulate a UART using the I/O Handler hardware block. The implemented UART is capable of full-duplex communication at common UART formats (7/8 databits, 1/2 stopbits), and with a configurable baud rate (up to 115200 baud). Flow control through hardware handshaking is supported (RTS/CTS). Receive and transmit FIFOs are configurable, and interrupts are generated based on FIFO thresholds. A low-level API offers receive and transmit primitives, as well as interrupt events. A sample driver demonstrates how to use this to create buffered I/O. Specifications Asynchronous, full-duplex. Baud rates up to 115200 for 48 MHz CPU clock. Data formats 7N1, 7N2, 8N1, 8N2. Hardware handshaking: CTS controlled by I/O Handler, RTS controlled by driver software. Requirements Library is designed for the LPC11E37H and the LPC11U37H. Requires 1.25 KiB Flash storage. Counter/timer module CT16B1 is used by IOH and is no longer available to the ARM core. Pinning UART Function Description Pin TXD UART transmit data output Freely selectable from the 21 possible I/O Handler pins IOH_0…IOH_20 RXD UART receive data input Can be selected from the following three pins: PIO0_8/IOH_6, PIO1_6/IOH_16, PIO1_27/IOH_20 CTS UART clear-to-send input Freely selectable from the 21 possible I/O Handler pins IOH_0…IOH_20. This signal is optional.   CRC The I/O Handler CRC library enables the I/O Hander hardware block as a CRC engine. A cyclic redundancy check (CRC) is an error-detecting code commonly used in digital networks and storage device to detect accidental changes to raw data. The IOH library allows CRC calculation to be performed by the I/O Handler peripheral with zero CPU load. Through the easy-to-use, non-blocking API of the library the emulated CRC engine can be configured, started and stopped.After a CRC calculation has been initiated, the IOH calculates the CRC over the raw data block with zero CPU load. When the calculation has finished, the IOH interrupt is asserted and the result of the calculation can be read through an API call. Specifications Supported polynomials: CRC-16-CCITT (x16 + x12 + x5 + 1) CRC-16-IBM (x16 + x15 + x2 + 1) Big endian and little endian data supported. Configurable seed. Support for both polling mode and interrupt mode. Requirements Library is designed for the LPC11E37H and the LPC11U37H. Requires 1kB Flash storage. Windowed Comparator The IOH windowed comparator allows monitoring up to 4 analog channels with zero CPU load. The ADC continuously converts all enabled channels, while IOH compares the converted values against a per-channel configurable window (consisting of an upper-limit and a lower-limit). When the converted value of any of the enabled channels is outside this window, an interrupt is generated. This task is fully handled by IOH at zero CPU load, meaning that in the meantime the ARM core can be put in sleep mode or execute other tasks. This provides a way to either lower the power consumption (ARM in sleep mode), or enhance performance (ARM executing other tasks). Specifications Converts up to all 8 available analog channels. Channel 0-3 can be selected for windowed comparator function. Interrupt is generated whenever any of the enabled comparator channels exceeds their window. True zero CPU-load. Requirements Library is designed for the LPC11E37H and the LPC11U37H. Requires 1.8kB Flash storage. ADC module is used by IOH and is no longer available to the ARM core. Note: Conversion result of enabled ADC channels available through API.