Adeneo Embedded enhances the already feature rich Windows Embedded Compact 7 (WEC7) BSP for the i.MX6 platforms by adding support for PCIe. PCIe support now enables customers to connect various PCI based peripherals to the high performance i.MX6 platform. In the example shown in the video, a PCIe based network card can be seen working with the i.MX6 SABRE lite board. The PCI bus and controller driver implementations from Adeneo are of production quality.

NOVPEK TM i.MX6Q/D System Download the NOVPEK i.MXQ/D Brochure Includes NOVPEK TM i.MX6Q/D Module 201 easily accessible IOMUX pins Arranged in 32x2 100mil pin headers Advanced Power Management (PM) development support via Add-on Card, various PM options available Multiple voltage settings for each peripheral voltage rail Accurate power consumption analysis framework for all 35 voltage rails on the i.MX6Q/D On-board debug ports: JTAG and 16bit ETM Bootable with terminal support RS232 and TTL interfaces, only uses two i.MX6Q/D pins All i.MX6Q/D boot options Simplified firmware/software development through 10/100 Ethernet port SPI based, doesn’t consume the built-in FEC USB HOST port and USBOTG port that can be forced to HOST mode HDMI video out port SATA interface LVDS interface PCI Express Mini PCIe with SIM slot MIPI/SDI interface Highly integrated NovTech PM solution Multiple power-on events Reprogrammable for configurability   For more information click here  

Hi all, Below is our press release for our i.MX6 solutions, i.e., kits and boards. emtrion GmbH, a company specialised in Embedded Systems design, hardware and software, Freescale Proven Partner, announces the availability of a new industrial processor module based on the multicore Cortex-A9 i.MX6 SoC family from Texas Instruments. This new module, called DIMM-MX6, extends the emtrion DIMM family and offers a full electrical and mechanical compatibility with the other modules of the emtrion DIMM series. emtrion guarantees the availability of its new module for at least 10 years. The DIMM-MX6 module from emtrion brings high computing capabilities with up to 10.000 DMIPS, multiple NEON SIMD and VPFU co-processors at a low power level, without requiring any active cooling system. The DIMM-MX6 module is available in several versions, with either i.MX6 Solo (1 core), Dual (2 cors) or Quad (4 cores) and on-board memories ranging from 512MB up to 8GB for the Flash (SLC NAND) and from 512MB up to 2GB RAM (DDR3). The new module is also qualified for an extended temperature range of -40°C to +85°C. In addition to boards and kits, emtrion offers support for a broad range of operating systems, board support packages (BSP) as well as engineering services. The DIMM-MX6 is available now with a BSP for Linux, that will be followed by additional BSP for Windows Embedded Compact 7 (WEC7), for QNX 6.5 and for Android 4.0. The BSP are available together with a developer kit. Each developer kit includes a DIMM-MX6 industrial module, a base board, a display and a development environment. All parts are mounted together and programmed by emtrion. The kits are shipped ready to use.

This document will explain Cairo setup to draw something on screen with hardware accelerates using OpenGL ES 2.0 or OpenVG.   Introduction:   As you know you can use those libraries that I mentioned (OpenGL ES and OpenVG) to draw on frame buffer with hardware accelerate on imx6q but using those libraries are a little bit hard to deal what I mean is that using OpenGL or OpenVG  is a kind of tough job but why? Let me bring an example here to clarify it, Imagine you want to draw an attitude aircraft symbol, this symbol needs some of elements to be drawn to look like a complete attitude symbol it includes: 1-Circle 2-line 3-Text 4-Triangle 5-some custom shapes for instance two L like lines that draw horizontally   If you have an experience with OpenGL specially OpenGL ES you’ll realize that drawing circle, line, triangle and so forth doesn’t a really tough job, of course drawing these primitive in OpenGL needs more lines of code in contrast with Cairo API that you can draw them with just three lines of code but the most hard job is drawing TEXT in OpenGL when you want to draw a simple text you have to deal with extra libraries like freetype,… to fetch the glyph features and then you can using atlas approach to draw text in a bitmap texture then when you need a character in your app  you can access to the character’s position in previous stored glyph in the texture, fetch and use, also you need to work with two specific OpenGL ES shaders in this case.   So I think it’s ok to use OpenGL or OpenVG to draw shapes if you are really skilled with those or if you looking for trouble! 😄 personally I prefer to use a high level API and then focus on other aspect of my application.   Compiling Cairo:   This document doesn’t intend to configure or compile Cairo, I’m sure that you can easily configure and compile it with OpenGL ES backend with YOCTO, Buildroot or any other embedded Linux distribution builders (YOCTO and Buildroot aren’t an embedded Linux distributions they can make custom one for you) even you can compile it manually.   To configure: ./configure --prefix=/home/super/Desktop/ROOTFS/MY_ROOTFS/usr --host=${CROSS_COMPILE} CFLAGS="-I/home/super/Desktop/ROOTFS/MY_ROOTFS/usr/include/ -DLINUX -DEGL_API_FB" LIBS="-L/home/super/Desktop/ROOTFS/MY_ROOTFS/usr/lib/ -lz" --enable-xlib=no --enable-egl --enable-glesv2   To compile: make     By the way you can find your suitable configuration for your own board; Cairo has a lot of options.     How to make surface for Cairo:   If you have an experience drawing shapes with Cairo you know that you need a surface from cairo_t* type to drawing function API can work on and shapes appear on the screen. To create a Cairo surface that uses OpenGL ES you have to configure EGL (EGL is an interface between Khronos rendering APIs (such as OpenGL, OpenGL ES or OpenVG) and the underlying native platform windowing system)[1] correctly and then make a Cairo surface from it.                    EGLint config_attributes[] =                 {                                                EGL_RENDERABLE_TYPE,                                                EGL_OPENGL_ES2_BIT,                                                EGL_RED_SIZE, 8,                                                EGL_GREEN_SIZE, 8,                                                EGL_BLUE_SIZE, 8,                                                EGL_ALPHA_SIZE,EGL_DONT_CARE,                                                EGL_SURFACE_TYPE,EGL_WINDOW_BIT,                                                EGL_DEPTH_SIZE, 16,                                                EGL_SAMPLES,      4,                                                EGL_NONE                 };   When you want to change OpenGL ES v 2.0 with OpenVG it’s enough that change the parameter of EGL_RENDERABLE_TYPE (that is EGL_OPENGL_ES2_BIT) to EGL_OPENVG_BIT.   The below code will appear Figure 1 on screen:     Figure 1:Simple drawing by Cairo on IMX6Q     //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   //======================================================================== // Name        : testCairo.cpp // Author      : Ali Sarlak // Version     : 1.0 // Copyright   : GPL // Description : EGL+Cairo GLIB //========================================================================   #include <iostream> #include <stdio.h> #include <EGL/egl.h> #include <EGL/eglext.h> #include <EGL/eglplatform.h> #include <cairo/cairo-gl.h> #include <EGL/eglvivante.h> #include <stdlib.h>     #define DISPLAY_WIDTH 640 #define DISPLAY_HEIGHT 480 using namespace std;   int main() {     printf("START\n");     printf("~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n");     EGLContext eglContext;     EGLSurface eglSurface;     EGLBoolean resultB;       /* Get a display handle and initalize EGL */     EGLint major, minor;     EGLDisplay eglDisplay = eglGetDisplay(EGL_DEFAULT_DISPLAY);       resultB = eglInitialize(eglDisplay, &major, &minor);       EGLint config_attributes[] =     {             EGL_RENDERABLE_TYPE,             EGL_OPENGL_ES2_BIT,             EGL_RED_SIZE, 8,             EGL_GREEN_SIZE, 8,             EGL_BLUE_SIZE, 8,             EGL_ALPHA_SIZE,EGL_DONT_CARE,             EGL_SURFACE_TYPE,EGL_WINDOW_BIT,             EGL_DEPTH_SIZE, 16,             EGL_SAMPLES,      4,             EGL_NONE     };       EGLint numberConfigs = 0;     EGLConfig* matchingConfigs=NULL;       if (EGL_FALSE             == eglChooseConfig(eglDisplay, config_attributes, NULL, 0, &numberConfigs))     {         printf("eglChooseConfig EROR\n");     }     if (numberConfigs == 0)     {         printf("eglChooseConfig EROR\n");     }       printf("number of configs = %d\n", numberConfigs);     /* Allocate some space to store list of matching configs... */     matchingConfigs = (EGLConfig*) malloc(numberConfigs * sizeof(EGLConfig));       if (EGL_FALSE  == eglChooseConfig(eglDisplay, config_attributes, matchingConfigs, numberConfigs, &numberConfigs))     {         printf("eglChooseConfig EROR\n");         if(matchingConfigs!=NULL)         {             free(matchingConfigs);             matchingConfigs=NULL;         }         return -1;     }       printf("~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n");       EGLint display_attributes[] =     {             EGL_WIDTH, DISPLAY_WIDTH,             EGL_HEIGHT, DISPLAY_HEIGHT,             EGL_NONE };       /*Window attributes*/     EGLint window_attribList[] =     {             EGL_NONE     };       EGLNativeDisplayType eglNativeDisplayType = fbGetDisplay(0);       EGLNativeWindowType eglNativeWindow = fbCreateWindow(eglNativeDisplayType,             0,             0,             DISPLAY_WIDTH,             DISPLAY_HEIGHT);       eglSurface = eglCreateWindowSurface(eglDisplay,matchingConfigs[0],eglNativeWindow,window_attribList);       if (eglSurface == EGL_NO_SURFACE)     {         printf("eglSurface = %x\n", eglGetError());     }       const EGLint attribListCtx[] =     {             // EGL_KHR_create_context is required             EGL_CONTEXT_CLIENT_VERSION, 2,             EGL_NONE     };       eglContext = eglCreateContext(eglDisplay, matchingConfigs[0], EGL_NO_CONTEXT,  attribListCtx);      //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~     if (eglContext == EGL_NO_CONTEXT)     {         printf("eglContext = %x\n", eglGetError());         return -1;     }       cairo_device_t* cdt = cairo_egl_device_create(eglDisplay, eglContext);       eglMakeCurrent(eglDisplay, eglSurface, eglSurface, eglContext);       cairo_surface_t *surface = cairo_gl_surface_create_for_egl(cdt, eglSurface,             DISPLAY_WIDTH,DISPLAY_HEIGHT);         cairo_t *cr = nullptr;     cr = cairo_create(surface);     if(!cr)     {         printf("Wrong cairo_t!\n");         return -1;     }     //*********************************************************************************************     for (int index = 0; index < 1; ++index) {         cairo_set_source_rgb (cr, 0, 0, 0);           cairo_move_to (cr, 0, 0);         cairo_line_to (cr, 200, 200);         cairo_move_to (cr, 200, 0);         cairo_line_to (cr, 0, 200);         cairo_set_line_width (cr, 1);         cairo_stroke (cr);           cairo_rectangle (cr, 0, 0, 100,100);         cairo_set_source_rgba (cr, 1, 0, 0, 0.8);         cairo_fill (cr);          cairo_rectangle (cr, 0, 100, 100, 100);         cairo_set_source_rgba (cr, 0, 1, 0, 0.60);         cairo_fill (cr);          cairo_rectangle (cr, 100, 0, 100, 100);         cairo_set_source_rgba (cr, 0, 0, 1, 0.40);         cairo_fill (cr);          cairo_rectangle (cr, 100, 100, 100, 100);         cairo_set_source_rgba (cr, 1, 1, 0, 0.20);         cairo_fill (cr);          cairo_surface_flush(surface);         eglSwapBuffers(eglDisplay,eglSurface);     }       //to check that cairo can make the photo from the surface, png file created     cairo_status_t s = cairo_surface_write_to_png(surface, "surface.png");     //it is a photo that made by cairo [OK]     cairo_destroy(cr);      if (CAIRO_STATUS_SUCCESS == s)     {         printf("Status = OK \n");     }     else     {         printf("Status = ERROR <ERROR_CODE->%d>\n", s);     }      if(matchingConfigs!=NULL)     {         free(matchingConfigs);         matchingConfigs=NULL;     }       cairo_surface_destroy(surface);     printf("END!\n");     return 0; }     How To Be Sure That My Application Using GPU:   If you have a look at https://community.nxp.com/thread/324670 you can profile a graphical application and investigate if it uses GPU or not, also you can measure the performance and analyze the application by vAnalyzer.       According to the link I’ve mentioned that’s enough to set galcore.gpuProfiler=1 in uboot and then check the /sys/module/galcore/parameters/gpuProfiler   file (read the file by cat, vi, nano, etc.) if the output is 1 all things is done in a right way the final step is that exporting some environment variables :   export VIV_PROFILE=1 export VP_OUTPUT=sample.vpd export VP_FRAME_NUM=1000 export VP_SYNC_MODE=1   VIV_PROFILE[0,1,2,3], VP_OUTPUT[any string], VP_FRAME_NUM[1,N], VP_SYNC_MODE[0,1]   Note: VIV_PROFILE[0] Disable vProfiler (default), VIV_PROFILE [1] Enable vProfiler, VIV_PROFILE [2] Control via application call, VIV_PROFILE [3]Allows control over which frames to profile with vProfiler by VP_FRAME_START and VP_FRAME_END.     If application uses GPU smaple.vpd file will create if not there isn't any vpd file. [1] - https://www.khronos.org/egl

The MYD-JX8MX development board is a versatile platform based on the NXP i.MX 8M Quad processors which feature 1.3GHz quad ARM Cortex-A53 cores and a real-time ARM Cortex-M4 co-processor and provide industry-leading audio, voice, and video processing for applications that scale from consumer home audio to industrial building automation and mobile computers. It is built around the MYC-JX8MX CPU Module and has brought out rich peripherals through connectors and headers such as 4 x USB 3.0 Host ports and 1 x USB 3.0 Host/Device port, Gigabit Ethernet, TF card slot, USB based Mini PCIe interface for 4G LTE Module, WiFi/BT, Audio In/Out, HDMI, 2 x MIPI-CSI, MIPI-DSI, 2 x LVDS display interfaces, NVMe PCIe M.2 2280 SSD Interface, etc. It is provided with both Linux and Android software package and delivered with necessary cable accessories for customer to easily start development as soon as getting it out-of-box. A MIPI Camera Module MY-CAM003 is provided as an option for the board. More information can be found from MYIR's website: MYD-JX8MX Development Board | i.MX 8M ARM Board-Welcome to MYIR                       

This document outlines how to reserve the first 2MB of memory for the M4 from Linux in order to take advantage of the cache-able RAM region available to the M4

iWave, a reliable embedded solutions provider has now optimized the booting time of its Windows Embedded Compact 7 (WEC7) BSP for Freescale’s SABRE SDP/B platform. Now the WEC7 OS is booting in a short period of time  ~3 seconds for a small footprint OS image with display and touch drivers support, and boot time of ~8 to ~10 seconds for an OS image with basic drivers and OS components support. Why boot time optimization? WinCE7 is a real time OS which will be used in performance-critical applications such as automotive and healthcare units. In most of the cases, booting time will play important role, e.g. if the device is used in rear-view camera system in automotive field, the user needs the device to start working as soon as the reverse-gear is applied. This requirement needs the device to boot and start the camera application within few seconds. This demands a very short OS boot time. Some of the techniques which can be applied for efficient boot time optimization are discussed in this article. Boot phases in WEC7: Boot-loader (eboot) Copying of OS image from booting device (e.g. Micro-SD) to RAM OAL Layer Driver initializations and file system mounting Guidelines for reducing the boot time in different booting phases of WEC7: Boot-loader (eboot): Remove the code that initializes a hardware which is not required in boot-loader. E.g. If booting device is micro-SD, the initialization of NAND is not necessary. So, this redundant code needs to be removed. The eboot menu in eboot is important for debugging of WEC7 OS. But it is not needed in an end product. So, the delay for this eboot menu can be completely removed to reduce 3 seconds of time. In few platforms such as Freescale’s SABRE platform, a default splash screen is used, which updates continuously. This can be removed, and a static splash screen can be displayed, which can save a few milliseconds of time. Remove unnecessary serial debug prints. Copying of OS image from booting device (e.g. Micro-SD) to RAM: This time increases as the size of WEC7 OS image increases. So, select the OS components carefully and remove redundant components from OS image so that the OS image can be copied to RAM quickly. Also remove unnecessary registry keys, dlls and libraries to reduce the OS size. Optimize binary image builder (.bib) file to reduce the run-time image file. Implement Multi-BinFS OS binaries to reduce the OS copying size. As the functionalities/driver supports goes on increasing, WEC7 image size increases. So, the time required to copy the image increases, and RAM size needed to store the OS image increases. The Binary ROM Image File System (BinFS) can fix the two issues. In a BinFS file system, the WEC7 OS binary is divided into multi-binary Image files, and only the one binary (less than 5MBs) is copied into the RAM by the boot-loader. The components in the other binary files are copied into the RAM only when they are required to run. Links that can be referred to implement multi-BinFS in WinCE:      MSDN documentation: http://msdn.microsoft.com/en-us/library/aa516960.aspx; An implementation guide by Freescale: http://cache.freescale.com/files/dsp/doc/app_note/AN4137.pdf You can also include compressing-decompressing mechanisms in boot-loader to achieve even shorter copying time. OAL layer: Remove the code that does unnecessary hardware implementations. Skip the initializations that already done in eboot. Remove any wait/loop/delay if exists. Remove unnecessary serial debug prints. Driver initializations and file system mounting: Analyse and remove all the redundant drivers, check for any loop, wait or delay sequences in driver initialization code. Load any applicable drivers (e.g. USB, sensors) after the OS boot (i.e. after user sees a desktop/application). In WEC7 OS, a driver can be either loaded during booting using device manager/GWES, or can be loaded dynamically whenever necessary. This can be achieved easily by changing the registry key configurations to remove the driver from built-in drivers, a small application to load the driver after OS boot-up, and registry settings to launch this application automatically once the OS is booted. To decide the load order, it is important to check the dependencies of/on a driver. Use appropriate splash screen/progress bar while user waits for OS booting. Remove unnecessary serial debug prints. By effectively following the techniques mentioned, WEC7 based platforms can achieve reduced boot time for quick application access. iWave has optimized the WEC7 booting time on Freescale’s SABRE SDP platform. The booting time is as low as ~3 seconds for a WEC7 OS with standard shell, LCD display, DDraw, I2C and touch driver support, and ~8 to 10 seconds for WEC7 OS with following components: Standard shell Display DDRAW Capacitive touch screen MicroSD USB host – Mass storage and HID Ethernet GPU (OpenVG/GL) Multimedia codecs DirectShow Audio Video Playback Ambient Light Sensor Accelerometer SMP PWM Backlight I2C Debugging using KITL For further information or inquiries please write to mktg@iwavesystems.com or visit www.iwavesystems.com

The documentation is the V2 version has added some FAQs for development based on NXP's i.MX 6UL/6ULL ARM Cortex-A7 processors. MYIR provides a series of i.MX 6UL/6ULL based products including SoM, SBC, development board and HMI display panel.   MYS-6ULX | NXP i.MX 6UL / 6ULL SBC Board for IoT and Industry Applications  MYC-Y6ULX CPU Module | NXP i.MX 6UL, i.MX 6ULL SOM | ARM Cortex-A7 Processor    MYD-Y6ULX | NXP i.MX 6UL, i.MX 6ULL Development Board / SOM, ARM Cortex-A7 Processor MYD-Y6ULX-HMI Development Board | NXP i.MX 6UL/6ULL Board for HMI Applications    MYD-Y6ULX-CHMI Display Panel | NXP i.MX 6UL/6ULL based 7-inch HMI Solution MYIR is pleased to share the experience with more developers. 

Dynamic voltage and frequency scaling (DVFS) is a power management technique that allows dynamically reducing power consumption of a CPU by dynamically scaling down supply voltage and CPU frequency. Because the internal DCDC of the i.MX RT1170 cannot cover the needed maximum current requirement at the junction temperature of 125 °C, the DVFS technique can be used to reduce current drain for compatibility with the internal DCDC. Lowering the processor frequency dynamically can help reduce the chip input current demand and ensure that the chip can continue to work at the junction temperature of 125 °C. The demo is attached. Only IAR and armgcc versions are enabled. The corresponding Application Note can be downloaded in the below link. https://www.nxp.com/docs/en/application-note/AN13267.pdf

NXP i.MX8M Mini SoC, quad-core ARM Cortex-A53, 1.8GHz Integrated 2D/3D GPU and 1080p VPU Up to 4GB LPDDR4 and 64GB eMMC Certified dual-band WiFi 802.11ac, BT 4.2 GbE, PCIe, 2x USB, 4x UART, 60x GPIO Tiny size and weight - 28 x 38 x 5 mm, 7 gram Yocto Linux and Android - BSPs and ready-to-run images Industrial temperature range: -40° to 85° C 10-year availability CompuLab's UCM-iMX8M-Mini is a miniature System-on-Module board designed for integration into industrial embedded applications. Measuring just 28 x 38 mm, UCM-iMX8M-Mini is an ideal solution for space constrained and portable systems. UCM-iMX8M-Mini Detailed Spec UCM-iMX8M-Mini Development Kit UCM-iMX8M-Mini Online Pricing

iMX6Q SABRE Lite WEC2013 Solution from Adeneo Embedded

This full featured BSP comes with all the core improvements that were made on the SABRE Lite BSP along with support for most of the features available for the SABRE board platform. Please contact Adeneo Embedded for access to the BSP as binary OS images or evaluation source code version at sales@adeneo-embedded.com

Boundary Devices has a variety of i.MX6 solutions. The SABRE Lite and Nitrogen6X boards are great tools for hardware and software evaluation. The Nitrogen6X_SOM is a low cost, highly integrated System-on-Module that is ideal for customers looking for rapid product development while maintaining the flexibility of a custom design. The Nitrogen6X_SOM is shown here running the QNX operating system with QT and Storyboard Suite from Crank Software on a 7" 800x480 display.

Measuring only 70mm by 55mm, the MYS-6ULX designed by MYIR is a high-performance low-cost Single Board Computer (SBC) specially designed for industry and Internet of Things (IoT) applications. It is based on NXP i.MX 6UL/6ULL processor family which features the most efficient ARM Cortex-A7 core and can operate at speeds up to 528 MHz. The MYS-6ULX Single Board Computer supports Yocto and Debian OS. Here we take Debian OS as an example.   The programming procedure:      Prepare an SD card. Open the image file of OS “mys6ull-debian8.rootfs.sdcard” with Win32Disk Imager, then program it into the SD card.      Power on the MYS-6ULX board. Insert the SD card to the slot, set the dip switch to 0101. Connect the serial port cable and USB power cable to the board, then power on the board.      Login in the system. The user name is root and the pass word is 123456. View the system information with command cat/etc/issue, the system version is Debian8 as shown below, which means the OS has been programmed into the SD card successfully. The develop environment I work on PC is Ubuntu VMS, ARMGCC compiler is needed to be installed in the Ubuntu VMS. We can check if the compiler is available with instruction arm-linux-gnueabihf-gcc–v. Ubuntu16 comes with a 5.4 version compiler as below: We need to install a compiler if the system doesn’t come with one. The toolkit MYIR provided contains that compiler. Open the folder 03-Tools\Toolchain, there is a package named “gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf.tar.xz”. Copy this package into a folder of VMS and use commands below to extract it. xz -dgcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf.tar.xz tar -xfgcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf.tar We would have a file named gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf after unpacking, then use instruction below to set the compiler: export PATH= $PATH:$DEV_ROOT/\gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf/bin exportCROSS_COMPILE=arm-linux-gnueabihfexport ARCH=arm View the compiler version again, the information printed on the screen should be: We can see the compiler version is 4.9.3. Then all the settings of develop environment has been completed.

iWave Systems Technologies Pvt. Ltd., a leading innovative Embedded Product Engineering Services company headquartered in Bangalore, launches “i.MX 6 SBC - Industry's latest Pico ITX Board around Freescale Semiconductor’s i.MX 6 Solo/Dual Lite processor which is iWave’s 4th i.MX 6 based design” on 26-02-2013 in Embedded World 2013 Nuremberg Germany. Measuring just 10cm x 7.2cm, iWave’s i.MX6 SBC is a highly integrated platform for increased performance in “Intelligent Industrial Control Systems, Industrial Human Machine Interface, Ultra Portable Devices, Home Energy Management Systems and Portable Medical Devices”. The i.MX 6 Solo/Dual Lite with ARM Cortex™-A9 single/dual cores running up to 1.0 GHz includes 2D and 3D graphics processors, 1080p video processing, and integrated power management. Each processor provides 32/64-bit DDR3/LVDDR3/LPDDR2-800 memory interface and a number of other interfaces for connecting peripherals, such as WLAN, Bluetooth™, GPS, hard drive, displays, and camera sensors. iWave’s new i.MX6 Solo/ Dual Lite based Pico ITX SBC integrates all standard interfaces into a single board with ultra-compact platform that can be utilized across multiple embedded PCs, systems and industrial designs. The i.MX6 SBC from iWave with its features like DDR3 RAM, Dual Display, Dual camera inputs, Gigabit Ethernet, Micro SD & SD slots, Dual USB 2.0 hosts, USB 2.0 OTG, Audio Out/In & serial interfaces, enables developers/users to quickly develop/implement their application needs around i.MX6 processor and optimize the “development effort and time to market” of their products. The i.MX6 SBC from iWave helps to reduce system cost, supports ultra-small form factor, wide operating temperature range from -20 0 C to +85 0 C and is backed with a minimum five years longevity support. Highlights of iWave’s i.MX6 SBC: ARM Cortex A9@ 1GHz Dual Lite/Solo core 10cm x 7.2cm Pico-ITX form factor Single Board Computer HD 1080p encode and decode,3D video playback in high definition Includes HDMI v1.4, MIPI and LVDS display ports, MIPI camera, Gigabit Ethernet, multiple USB 2.0 and PCI Express Comprehensive security features include cryptographic accelerators, high-assurance boot and tamper protection Technical &quick customization support with 5+ years, Long term support About iWave Systems: iWave has been an innovator in the development of “Highly integrated, high-performance, low-power and low-cost i.MX6/i.MX50/i.MX53/i.MX51/i.MX27 SOMs”. iWave helps its customers reduce their time-to-market and development effort with its products ranging from System-On-Module to complete systems. The i.MX6 Pico ITX SBC is brought out by iWave in a record time of just 5 weeks. Furthermore, iWave’s i.MX6/i.MX50/i.MX53/i.MX51/i.MX27 SOMs have been engineered to meet the industry demanding requirements like various Embedded Computing Applications in Industrial, Medical & Automotive verticals. iWave provides full product design engineering and manufacturing services around the i.MX SOMs to help customers quickly develop innovative products and solutions. For more details, please visit: http://www.iwavesystems.com/product/development-platform/i-mx6-pico-itx-sbc/i-mx6-pico-itx-sbc.html email: mktg@iwavesystems.com

This FAQ is based on MYIR's i.MX6UL&6ULL products but also can be applied on products of other vendors. MYIR provides a series of i.MX 6UL/6ULL based products including SoM, SBC, development board and HMI display panel. MYD-Y6ULX-CHMI | 7-inch HMI Display Solution based on NXP i.MX 6UL/6ULL-Welcome to MYIR  MYS-6ULX | NXP i.MX 6UL / 6ULL SBC Board for IoT and Industry Applications-Welcome to MYIR  MYC-Y6ULX CPU Module | NXP i.MX 6UL, i.MX 6ULL SOM | ARM Cortex-A7 Processor-Welcome to MYIR   MYD-Y6ULX | NXP i.MX 6UL, i.MX 6ULL Development Board / SOM, ARM Cortex-A7 Processor-Welcome to MYIR  MYD-Y6ULX-HMI Development Board | NXP i.MX 6UL/6ULL Board for HMI Applications-Welcome to MYIR  MYIR is pleased to share the experience with more developers. 

Freescale i.MX6 UltraLite processor, 528MHz Up to 1GB DDR3 and 32GB on-board eMMC Dual-band 802.11a/b/g/n WiFi and BT 4.1 BLE Ethernet, 5x USB, 8x UART, 2x CAN, SDIO, 78x GPIO Miniature size - 36 x 68 x 5 mm               CL-SOM-iMX6UL​ is a tiny System-on-Module (SoM) / Computer-on-Module (CoM) board designed to serve as a building block in embedded applications. CL-SOM-iMX6UL is build around the Freescale i.MX6 UltraLite system-on-chip featuring an advanced Cortex-A7 ARM CPU. The SoC is coupled with up-to 1GB DDR3 and 32GB of on-board eMMC storage. The processor is supplemented with up-to 4GB DDR3 and 32GB of on-board SSD. Measuring only 36 x 68 x 5 mm CL-SOM-iMX6UL features a wide range of industry standard interfaces - Ethernet, WiFi 802.11, Bluetooth, USB, CAN bus, serial ports, I/O lines and ADC inputs. Low price makes CL-SOM-iMX6UL an ideal selection for cost-sensitive systems, while its small size and low power consumption facilitate integration into portable and space-constrained designs. CL-SOM-iMX6UL is provided with comprehensive documentation​ and full ready-to-run SW support for Linux operating system. CL-SOM-iMX6UL Detailed Spec​ CL-SOM-iMX6UL Block Diagram​ CL-SOM-iMX6UL Development Kit​ CL-SOM-iMX6UL Online Pricing​