Now that you've downloaded & unzipped your LPCXpresso54608 SDK, let's open IAR Embedded Workbench IDE. Note: You must have at least IAR Embedded Workbench version 7.80.3.12146 to use this board Once open, select File>Open>Workspace Navigate to the location where you unzipped your SDK files. Within this folder there are plenty of SDK based demos for you to explore our microcontroller.  We will use one of them to guide you through this tutorial, but definitely take time to try all of them! Select boards>lpcxpresso54608>demo_apps>touch_cursor>iar>touch_cursor Once the workspace is loaded, you will see the project files on the left.  Along the toolbar the first highlighted item is 'Build' select it. Once your console shows no errors you can select the 'Download and Debug' a few icons to the right of 'Build' Your debug session will start and will look like the following window.  Once it opens 'touch_cursor.c' and has a green arrow next to the main function you can select 'Go' After you have successfully flashed the board with this demo you will see the following on your board. This demo utilizes the touch interface on the screen to read where you are touching and updates the cursor position to the last known location.   Remember that other demos and sample code are provided in the root folder of the SDK download.   Be sure to explore these demos and reach out on the community if you need help!

[中文翻译版] 见附件 原文链接： https://community.nxp.com/docs/DOC-342406

The LPC55S6x family was initial silicon die version was 0A, and this silicon was using on Revision A1 LPCXpresso55S69 boards. Revision 1B silicon has been used on Revision A2 boards. Both versions of silicon support the new, more robust debug session request method, but 1B silicon requires its use. If the correct version of IDE and/or debug probe drivers are not used then debug operation will be affected or non-functional.  When using Revision A2 boards, the current software release versions are required: MCUXpresso IDE Version  11.0.1 or later (11.1 or later recommended) [Note: IDE 11.0.1 may also be used but when using Revision A1 boards a hot fix is required for this release. See  MCUXpresso IDE v11.0.1 LPC55xx Debug Hotfix ] Note that you may need to start from a new workspace if transitioning from one developed using a Revision A1 board to a Revision A2 board (or any target system using Revision 1B silicon). IAR Embedded Workbench version 8.40.2 or later Keil uVISION LPC55S6x Device Family Pack (DFP) 12.0.1 or later SEGGER J-Link J-link version 6.54c or later should be used (from the SEGGER download site), and V6.64 or later is recommended. When using J-link with non-SEGGER IDEs (MCUXpresso, IAR, Keil), ensure that you IDE configuration is pointing to the latest J-Link drivers. If using MCUXpresso IDE 11.0.1 the included J-link drivers need to be updated to the latest version to support Revision A1 boards. See Updating a SEGGER J-Link installation on Windows for more information. For more information about silicon revision and tools, please refer to Understanding LPC55S6x Revisions and Tools  Please also note that there are Chinese versions of description regarding board revision, silicon revision and the corresponding tools as shown below: 中文版：LPC55S6x 版本更新及开发工具注意事项 中文版：LPC55S6x 0A和1B版本区别进阶

The MCUXpresso IDE SWO trace function is a special feature which enables user to observe variable update, interrupt entry/exit timing, interrupt event statistic, to print information in SWO ITM Console while the MCU is running. The MCUXpresso IDE SWO trace function is a supplement to the debugger of the MCUXpresso IDE. The main advantage is to display variable, print information, list interrupt entrying/exitting/returing while the MCU is running.  The documentation describes the hardware connection to implement the SWO function, MCUXpresso configuration and source code to implement the function. 

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

LPC4300 10-bit ADC module Introduction        LPC4300 Series microcontrollers combine the high performance and flexibility of an asymmetric dual-core architecture (ARM Cortex-M4F and Cortex-M0 coprocessor) with multiple high-speed connectivity options, advanced timers, analog, and optional security features to secure code and data communications. DSP capabilities enable all LPC43xx families to support complex algorithms in data-intensive application. Flash and Flashless options support large, flexible internal and external memory configurations.         LPC4370/LPC43S70 products provide 12-bit high-speed ADC module with up to 80MSamples/s. This document does not test 12-bit high-speed ADC performance. LPC43xx/LPC43Sxx series products provide two 10-bit SAR ADC module with below features: *   Measurement range 0 to 3.3 V *   10-bit conversion time = 2.45 us (up to 400K Samples/s) *   Burst conversion mode for single or multiple inputs *   Support hardware/software trigger *   Support Interrupt/DMA mode Test hardware platform introduction         This test hardware platform uses Keil MCB4357 evaluation board (OM13040), which enables customer to create and test working programs based on the LPC4300 family of Dual Core ARM Cortex™-M4/M0 devices. Keil MCB4357 with below features:  204 MHz LPC4357 device with ARM Cortex-M4 processor and Cortex-M0 coprocessor 136 KB On-Chip SRAM 1 MB dual bank On-Chip Flash On-Board Memory: 16 MB NOR Flash, 4 MB Quad-SPI Flash, 16 MB SDRAM & 16 KB EEPROM (I²C) Color QVGA TFT LCD with touchscreen High-speed USB 2.0 Host/Device/OTG interface (USB host + Micro USB Device/OTG connectors) Full-speed USB 2.0 Host/Device interface (USB host + micro USB Device connectors) MicroSD Card Interface Analog Voltage Control for ACD Input Audio CODEC with Line-In/Out and Microphone/headphone connector + Speaker Debug Interface Connectors 20-pin JTAG (0.1 inch) 10-pin Cortex debug (0.05 inch) 20-pin Cortex debug + ETM Trace (0.05 inch connector Test software introduction       This test software uses LPCOpen software ADC demo, the software version is V2.20.       ADC demo default path is:       ..\lpcopen_2_19_keil_iar_keil_mcb_4357\applications\lpc18xx_43xx\iar\keil_mcb_4357\periph_example.eww      LPCOpen software [periph_example.eww] project provides LPC4357 most modules driver application demos. The ADC demo need precompile MCB4357 board support package (lib_lpc_board_keil_mcb_4357) and LPC43xx chip driver (lib_lpc_chip_43xx). MCB4357 board support package provides MCB4357 board related pins configuration, clock configuration, on-board external memory configuration, Ethernet PHY driver configuration and board hardware resource configuration; LPC43xx chip driver provides LPC43xx modules driver API function.       ADC demo provides three modes to get ADC conversion value: polling mode, interrupt mode and DMA mode. The demo config 10-bit ADC module with 400K Samples/s and ARM Cortex-M4 core clock frequency with 204MHz. The test uses Timer0 module as time-base and counter reference clock is same with ARM Cortex-M4 core clock frequency (204MHz).       Timer0 initialization code comments: ADC module initialization code comments: ADC polling mode code comments: ADC interrupt mode code comments: ADC DMA mode code comments: Test result     The test will use TIMER0 counter to calculate each test item time interval.      The test includes below test items:      Single/no burst: ADC convert one time with burst mode disabled      100K/no burst: ADC convert 100K times with burst mode disabled      Single/burst: ADC convert one time with burst mode enabled      100K/burst: ADC convert 100K times with burst mode enabled

Some processors in LPC family have EMC, which enable customer to connect external parallel SRAM, NOR flash, SDRAM, there is application which saves code in serial flash for example SPI flash or IIC flash, copy the code to SDRAM and run code in SDRAM. This is a simple code to demo how to run the code in SDRAM, the Code is developed under the SDRAM example code with SDK package, which initialize SDRAM and write data to SDRAM, read the data from SDRAM, compare whether the writing data and reading data are the same. A simple function void LED_Toggle(void) is used to toggle a LED, the API function is copied to SDRAM with the function void mem2mem(uint16_t *sourceAdd,uint16_t *destinationAdd,uint16_t length), after the function is called, an function pointer is defined and jump to the function pointer. BTW, if user would like to run code in SDRAM, the MPU module for the Cortex-M4 has to be initialized, which enable the code in SDRAM to be fetched and executed. The Demo code is developed under MCUXpresso ver10.3.1 and LPCXpresso546xx board(OM40003). after you Run code, the LED2 can toggle on LPCXpresso546xx board.. I list the main code here. All the project is attached. void mem2mem(uint16_t *sourceAdd,uint16_t *destinationAdd,uint16_t length) {     sourceAdd = (uint16_t *)((uint32_t)sourceAdd & (0xFFFFFFFE));     destinationAdd=(uint16_t *)((uint32_t)destinationAdd & 0xFFFFFFFE);     for(uint16_t i=0; i<length; i++)     {         destinationAdd[i]=sourceAdd[i];     }     __DSB();     __ISB(); } #define SDRAM_BASE_ADDR_CODE 0xa0000001 typedef void (*functionPointer)(void); //The PC value must be an odd value although the code address is an even //value void runCodeInSDRAM(void) {     ((functionPointer)SDRAM_BASE_ADDR_CODE)(); } void LED_Toggle(void) {     while(1)     {         delay_1();         GPIO->NOT[3]|=1<<3;     } } void MPU_Init(void) {     //disable MPU     MPU->CTRL=0x00;     //Region0: default region 0     MPU->RBAR=0x00000010;     MPU->RASR=0x1004003f;     //Region 1:     //set up flash, ROM, SRAM ... as region 1     //# 0x00000000 - 0x3FFFFFFF     MPU->RBAR=0x00000011;     MPU->RASR=0x0306E23b;     //Region 2:     //set up peripheral device     //# 0x40000000 - 0x400FFFFF     MPU->RBAR=0x40000012;     MPU->RASR=0x13050033;     //Region 3:     //set up chip select and device     //# 0x80000000 - 0x9000FFFF     MPU->RBAR=0x80000013;     MPU->RASR=0x1305001f;     //Region 4:     //set up SDRAM     //# # 0xA0000000 - 0xA0FFFFFF     MPU->RBAR=0xa0000014;     MPU->RASR=0x0307002f;     //Region 5:     //set up Cortex-M4 Private Peripheral Bus     //# 0xE0000000 - 0xE00FFFFF     MPU->RBAR=0xe0000015;     MPU->RASR=0x13040027;     //Region 6:     //set up Not used     //# 0xE0000000 - 0xE00FFFFF     MPU->RBAR=0xe0000016;     MPU->RASR=0x00000000;     //Region 7:     //set up stack     //#     MPU->RBAR=0x1000E017;     MPU->RASR=0x10060009;     //enable MPU     MPU->CTRL=0x01; } int main(void) {     uint32_t index;     uint32_t *sdram = (uint32_t *)SDRAM_BASE_ADDR; /* SDRAM start address. */     /* Hardware Initialization */     CLOCK_EnableClock(kCLOCK_InputMux);     /* attach 12 MHz clock to FLEXCOMM0 (debug console) */     CLOCK_AttachClk(BOARD_DEBUG_UART_CLK_ATTACH);     BOARD_InitPins();     BOARD_BootClockFROHF96M();     BOARD_InitDebugConsole();     LEDInit();     //LED_Toggle();     BOARD_InitSDRAM();     MPU_Init();     mem2mem((uint16_t *)LED_Toggle,(uint16_t *)SDRAM_BASE_ADDR_CODE,400);    // LED_Toggle();     runCodeInSDRAM(); }

The Economist Intelligence Unit’s (EIU) 2020 IoT Index recently highlighted that 2020 will be the year when the Internet of Things (IoT) officially moves from “proof of concept” to “mass deployment”, with over half of all companies surveyed now undergoing early or extensive deployment of internal or external IoT networks. Read more >> NXP and Arm Pelion Device Management Secure Deployment of IoT Devices from Chip to Cloud | Pelion IoT Blog 

A demonstration of decoding animated GIF files from internal flash on the LPC55S69.   I ported this library:   GitHub - bitbank2/AnimatedGIF: A lightweight Arduino GIF decoder for playing animated files from memory or files on SD c…    The code for the MiniMonkey can be found here:   https://bitbucket.org/ehughes_/minimonkey-sw/src/master/   

[中文翻译版] 见附件   原文链接： https://community.nxp.com/community/general-purpose-mcus/lpc/blog/2019/05/05/trustzone-with-armv8-m-and-the-nxp-lpc55s69-evk

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

Test Elapsed time based on CTimer module   Sometimes, It is required to test the time which an api function takes when the function is executed, for example, some users want to test the flash erasing time and flash programming time. User can use GPIO to set/clear and use scope to test the GPIO timing to measure the time an api function takes, the method is very simple and straightforward but inaccurate. The document describes to configure CTimer as a 32bits  free-running counter, user can read the counter value before and after an api function and compute the counter value difference to get the time the api function takes. The CTimer of LPC54xxx family counts the APB bus clock, the APB bus clock Is driven by 12 MHz FRO, user can use the following code to measure the elapsed time. For example, we test the elaped time of  delayTimer(10000); function, we get the variable tPoint1, tPoint2. The actual time is (tPoint2- tPoint1)*(1/12000000). In the example, the tPoint2=110127, the tPoint1=53, the elapsed time is (110127-53)*(1/12000000)=9.172us. //the souce code focuses on LPC54xxx family uint32_t tPoint1,tPoint2,tPoint3,tDiff; void test(void) {     tPoint1=CTIMER_GetTimerCountValue(CTIMER2);     //simulate elapsed time     delayTimer(10000);     tPoint2=CTIMER_GetTimerCountValue(CTIMER2);     tDiff=tPoint2-tPoint1;       //simulate elapsed time     delayTimer(20000);     tPoint3=CTIMER_GetTimerCountValue(CTIMER2);     tDiff=tPoint3-tPoint2;      PRINTF("Time instand:tPoint1=%d, tPoint2=%d, tPoint3=%d \r\n",tPoint1,tPoint2,tPoint3); } Snippet of simple source code based on MCUXpresso tools and LPC54618 board developed by XiangJun Rong #include "fsl_ctimer.h" void test(void); void CTimerInit(void); void delayTimer(uint32_t elapsedTimer); uint32_t tPoint1,tPoint2,tPoint3,tDiff; void CTimerInit(void) {     ctimer_config_t config;     ctimer_match_config_t matchConfig;     /*CTimer use APB bus clock as Timer tick, set the APB bus clock as 12MHz internal FRO */      CLOCK_AttachClk(kFRO12M_to_ASYNC_APB);     CTIMER_GetDefaultConfig(&config);       CTIMER_Init(CTIMER2, &config);       matchConfig.enableCounterReset = true;     matchConfig.enableCounterStop = false;     matchConfig.matchValue = 0xFFFFFFFF;     matchConfig.outControl = kCTIMER_Output_NoAction;     matchConfig.outPinInitState = true;     matchConfig.enableInterrupt = false;     CTIMER_SetupMatch(CTIMER2, kCTIMER_Match_3, &matchConfig);     CTIMER_StartTimer(CTIMER2); }   void test(void) {     tPoint1=CTIMER_GetTimerCountValue(CTIMER2);     //simulate elapsed time     delayTimer(10000);     tPoint2=CTIMER_GetTimerCountValue(CTIMER2);     tDiff=tPoint2-tPoint1;       //simulate elapsed time     delayTimer(20000);     tPoint3=CTIMER_GetTimerCountValue(CTIMER2);     tDiff=tPoint3-tPoint2;      PRINTF("Time instand:tPoint1=%d, tPoint2=%d, tPoint3=%d \r\n",tPoint1,tPoint2,tPoint3); }   void delayTimer(uint32_t elapsedTimer) {     uint32_t i;     for(i=0; i<elapsedTimer; i++)     {         __asm("nop");     } }   int main(void) {    …………………………………………………………………………………………………..     PRINTF("Elapse time test start: \r\n");     CTimerInit();     test();     for(;;) {} ………………………………………… }  

The series of LPC540XX chips are flashless, only LPC54018JXM and LPC54S018JXM integrate internal QSPI Flash. The typical part numbers are LPC54018J2(4)M and LPC54S018J2(4)M. Some customers have questions about the concept of SPIFI interface and clock configuration when using this series of chips. This article mainly explains this. Introduction to SPIFI SPIFI (SPI Flash Interface) is an SPI Flash interface that can help microcontrollers replace large-size, high-cost parallel Flash with small-size, low-cost serial Flash. Using SPIFI technology, the external serial FLash can be mapped to microcontroller memory to achieve on-chip memory read effect, that is, cost can be optimized and Flash size can be increased while ensuring the operating speed. The electrical interface of SPIFI is as follows:   In the LPC540XX series of chips, if the part number includes M, QSPI Flash is integrated inside chip; if the part number does not include M, the QSPI Flash is externally connected to chip. The following picture shows the comparison of LPC54S018JXM and LPC54S018 in SPIFI structure:   SPIFI clock frequency description Taking LPC54S018J4M as an example, the SPIFI clock frequency is described below in the UserManual. SPIFI supports 1/2/4bit transmission mode. In 4bit transmission mode, the maximum transmission rate is SPIFI_CLK/2 bytes per second. The data transmission rate is up to 52Mbytes /s, that is, it takes two clock to transmit one byte. If you want to configure the SPIFI transmission rate to 52Mbytes /s, it needs to be in 4bit mode, so SPIFI_CLK is configured to 104M.     The SPIFI clock source is as follows in LPC54S018J4M Datasheet. By default, the SPIFI clock source is FRO96. For example, when the SPIFI clock is configured to 96M, in 4bit transmission mode, the transmission rate is 96/2=48Mbyte/s.   The LPC54S018J4M uses W25Q32JV-DTR as the internal SPIFI Flash. The figure below shows the maximum clock frequency it supports. In 4bit transmission mode, the maximum transmission rate is 133/2=66.5Mbyte/s, which is greater than SPIFI's maximum transmission rate of 52Mbyte/s. It shows that the maximum data transmission rate of W25Q32JV can meet the requirements of LPC54S018J4M QSPI Flash interface for communication rate.   3．Change SPIFI clock frequency The description of the SPIFI clock frequency in UserManual is as follows. In setup_lpc54s018m.c, the SPIFI clock frequency is defined on the address with an offset of 0X1C (the macro is defined as IMG_BAUDRATE), and the initial value is 0. According to the following table, when IMG_BAUDRATE=0, the SPIFI clock frequency is 24M. Since the default SPIFI clock source is the internal clock FRO96M, the SPIFI clock can be configured up to 96MHz in the following table by modifying the value of IMG_BAUDRATE.          There are two ways to modify the SPIFI clock.   3.1 Modify the SPIFI clock through IMG_BAUDRATE Before the main function runs, IMG_BAUDRATE is obtained by BOOT ROM to set the SPIFI clock frequency. If the requirement for the SPIFI clock rate is less than or equal to 96M, it is recommended to directly change the macro definition of IMG_BAUDRATE in setup_lpc54s018m.c to change the SPIFI clock frequency, as follows:   3.2 Modify the SPIFI clock through system config Another method is to modify the SPIFI clock frequency by changing the SPIFI frequency division coefficient in user code, as follows:   The result is as follows. The SPIFI clock frequency is set to 96M.   If you want to configure a higher SPIFI working clock, such as 104M, you must use a higher frequency external clock source to adjust the PLL coefficient and SPIFI frequency division coefficient in order to achieve the required clock frequency.

Live at Computex 2018 this week is: The High Performance Gaming Mouse Controlling Hundreds of Full Color LEDs Powered by LPC51U68 A 100MHz Arm® Cortex®-M0+ delivering real-time response for game player 96K SRAM for LED pattern allows for a smooth transition  Built-in USB drivers in ROM and supports 1K report rate 8 Flexcomm serial channels to drive up to 800 LEDs with full color control at the same time

Introduction FEZ is an open source development platform for beginners. Powered by an ARM processor (LPC2388) and driven by Microsoft's .NET Micro Framework, FEZ is a doorway to the embedded world. From the ground up, we designed FEZ to be extremely easy to learn. From the boards to the brochures, we made sure to explain everything on your journey. Programming is made easy by using Microsoft's Visual Studio and C#. Enabling those unfamiliar with the embedded world to program without having any prior knowledge. To further assist exploration, we've created an eBook providing extensive details and code examples. Not only is this eBook free, the SDK and IDE are also completely free. This overall low-cost starting point opens the opportunity to learn embedded devices to everyone. Key Features Based on Microsoft's .NET Micro Framework Runs on 72MHz NXP ARM processors (LPC2387 and LPC2388) Supports runtime debugging (breakpoints, variable inspection, stepping, etc.) Use Visual Studio 2008 C# Express Edition for development Advanced capabilities like FAT, USB device, and USB host Easily upgrades to hardware such as Embedded Master Open source hardware design files Use existing shields and holder boards Based on the USBizi chipset (ideal for commercial use) FEZ Mini pin-out compatible with BS2 FEZ Domino pin-out compatible with Arduino Developent Environment FEZ development is done using Visual Studio 2008 C# Express Edition. You're now able to use the same powerful IDE used by PC developers. The benefits of managed C# programming include reducing programming errors significantly and automatically managing system resources. From the code IntelliSense and included peripheral libraries to deploying and debugging applications. These tools are not only the most advanced, they are all free. As you type, IntelliSense gives you the appropriate methods and properties. Stepping through the code on-device allows you to debug problems efficiently. Hardware FEZ comes in two models: FEZ Domino and FEZ Mini. Both include libraries that contain the FAT file system, threading, UART, SPI, I 2 C, GPIO, PWM, ADC, DAC, and many more. Two kits are also available: the starter kit and the robot kit. We also offer a multitude of peripherals for these boards such as Bluetooth, LEDs, buttons, light sensors, and thermometers, to name a few. FEZ Domino FEZ Mini Software Microsoft's .NET Micro Framework is a lightweight implementation of the .NET Framework. It focuses on the specific requirements of resource-constrained embedded systems. Supporting development in C# and debugging on an emulator or the device, both using Visual Studio. The .NET Micro Framework is also open source, released under the Apache 2.0 license and completely free. Developers already experienced with .NET and Visual Studio can take advantage of their skills immediately, reducing the learning curve. The actual C# application development process is completely shielded from the low-level design details of the hardware platform. Combining the benefits with off-the-shelf, low-cost, network-enabled embedded systems creates a rapid product development solution. More Information FEZ Partners Links TinyCLR Brochure TinyCLR Ebook Reference TinyCLR Tutorial Microsoft .NET Micro Framework Blog Wikipedia Fez (hat

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-341477

LPC55xx系列的MCUXpresso SDK使用FLASH API来实现FLASH驱动。 一些用户在执行如下FLASH写操作时可能会遇到如下的问题： status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 8);       执行完上述代码后，对应的地址区间数据没有变化，写入失败，返回错误代码101，如下图所示, 错误代码101看上去有点陌生，这在之前的LPC产品中并不常见，我们在用户手册中搜索FLASH driver status code，可以查找到错误代码101为FLASH 对齐操作错误（Alignment Error）。   对齐操作错误是什么？我们先来看程序是如何对FLASH_Program函数进行定义的。 FLASH写函数定义如下： status_t FLASH_Program(flash_config_t *config, uint32_t start, uint32_t *src, uint32_t lengthInBytes); 新用户经常会忽略掉用户手册中对于这个API的介绍“the required start and the lengthInBytes must be page size aligned”，这句话的意思是在执行FLASH_Program函数时，写入的起始地址和数据长度必须512字节对齐，所以如果我们把代码 status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 8); 更正为 status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 512); FLASH_Program函数就可以运行成功。   请注意：在2.6.x版本的SDK中，FLASH_Program函数的注释将参数的起始地址和数据长度错误的表述为字对齐，2.7.0版本的SDK已经对注释进行了修正。即使你想要操作一个字节，lengthInBytes也是512字节对齐。   最后：建议用户在遇到关于FLASH API操作失败的相关问题，一定要查看用户手册中的FLASH驱动状态码，我们可以从UM11126中的第九章节FLASH API部分找到它，如下图所示。  

View Webinar Recording

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.