i.MX Solutions Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX Solutions Knowledge Base

Labels
  • General 294

Discussions

Sort by:
This post is based on http://boundarydevices.com/using-the-cortex-m4-mcu-on-the-nit6_solox/ The i.MX6 SoloX processor is the first of a kind, coupling a Cortex-A9 with a Cortex-M4 core inside one chip to offer the best of both MPU and MCU worlds. The MCU is perfect for all the real-time tasks whereas the MPU can provide a great UI experience with non real-time OS such as GNU/Linux. This blog post will detail how to build and run source code on the MCU using our Nit6_SoloX. Terminology Before getting any further, here is a list of terms that will be used in this post: MCC: Multi-Core Communication: protocol offered by Freescale for the MCU and MPU to exchange data MCU: Microcontroller Unit such as the ARM Cortex-M series, here referring to the Cortex-M4 MPU: Microprocessor Unit such as the ARM Cortex-A series, here referring to the Cortex-A9 MQX: RTOS provided by Freescale to run their MCUs RTOS: Real-Time Operating System such as MQX or FreeRTOS For the impatient You can download a demo image from here: 20150814-buildroot-nitrogen6x-mcu-demo.img.gz for Nit6_SoloX. As usual, you’ll need to register on our site and agree to the EULA because it contains Freescale content. The image is a 1GB SD card image that can be restored using zcat and dd under Linux. ~$ zcat 20150814-buildroot*.img.gz | sudo dd of=/dev/sdX bs=1M For Windows users, please use Alex Page’s USB Image Tool. This image contains the following components: Linux kernel 3.14.38 from our repo https://github.com/boundarydevices/linux-imx6/tree/boundary-imx_3.14.38_6qp_beta U-Boot v2015.04 from our repo https://github.com/boundarydevices/u-boot-imx6/tree/boundary-imx6sx Development environment setup This section will detail how to set up a Linux machine to be able to build MCU source code. First you need to download the "MQX RTOS for i.MX 6SoloX v4.1.0 releases and patches" file from Freescale website: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MQX Then you need to untar this archive and apply our patch to add support for the Nit6_SoloX board. ~$ cd && mkdir mqx && cd mqx ~/mqx$ tar xf ~/Downloads/Freescale\ MQX\ RTOS\ 4.1.0\ for\ i.MX\ 6SoloX\ Linux\ Base.tar.gz ~/mqx$ wget http://boundarydevices.com.commondatastorage.googleapis.com/0001-Add-Nit6_SoloX-board-support.patch ~/mqx$ patch -p1 < 0001-Add-Nit6_SoloX-board-support.patch ~/mqx$ find . -name "*.sh" -exec chmod +x {} \; Note that this package comes with a good set of documentation which we invite you to read: doc/Freescale_MQX_RTOS_4.1.0_i.MX_6SoloX_Release_Notes.pdf doc/Getting_Started_with_Freescale_MQX_RTOS_on_i.MX_6SoloX.pdf As specified in the documentation, you need to install a specific toolchain (CodeSourcery v2014q1) in order to build the BSP. ~$ cd && mkdir toolchains && cd toolchains ~/toolchains$ wget https://launchpad.net/gcc-arm-embedded/4.8/4.8-2014-q1-update/+download/gcc-arm-none-eabi-4_8-2014q1-20140314-linux.tar.bz2 ~/toolchains$ tar xjf gcc-arm-none-eabi-4_8-2014q1-20140314-linux.tar.bz2 ~/toolchains$ rm gcc-arm-none-eabi-4_8-2014q1-20140314-linux.tar.bz2 Your machine is now ready to build applications for the MCU! Build instructions This section explains how to build the BSP as well as the applications for the MCU only. In order to build the BSP for the MPU, please refer to other blog posts on either Yocto or Buildroot. ~$ cd ~/mqx/ ~/mqx$ export TOP=$PWD ~/mqx$ export TOOLCHAIN_ROOTDIR=$HOME/toolchains/gcc-arm-none-eabi-4_8-2014q1/ ~/mqx$ cd $TOP/build/imx6sx_nit6sx_m4/make ~/mqx$ ./build_gcc_arm.sh As the BSP for our board is now built, we can build any example application provided in the MQX package. In order to have an interaction between the MPU and the MCU, you need to build a MCC application. Below are the instructions to build the pingpong application which sends data back and forth between the cores. ~/mqx$ cd $TOP/mcc/examples/pingpong/build/make/pingpong_example_imx6sx_nit6sx_m4/ ~/mqx$ ./build_gcc_arm.sh ~/mqx$ $TOOLCHAIN_ROOTDIR/bin/arm-none-eabi-objcopy \        ./gcc_arm/ram_release/pingpong_example_imx6sx_nit6sx_m4.elf \        -O binary m4_fw.bin That's it, the binary is ready to be used! Some might be interested in using an IDE to browse/modify/build the source code, note that Freescale provides instructions to use IAR Workbench (Windows only). It seems that there isn't any plan to support the SoloX MQX release inside the KSDK (Kinetis SDK) as explained in a community forum post. Run the demo First you need to copy the image (20150814-buildroot-nitrogen6x-mcu-demo.img.gz) provided at the beginning of this post to an SD Card. Then copy the m4_fw.bin binary to the root directory of the SD Card. The SD Card contains the U-Boot version that enables the use of the Cortex-M4, the bootloader inside your NOR must therefore be upgraded. U-Boot > setenv bootfile u-boot.imx U-Boot > run upgradeu Once the upgrade is complete and the board restarted, make sure to have a clean environment: U-Boot > env default -a ## Resetting to default environment U-Boot > saveenv By default, the M4 must be flashed in NOR memory, a U-Boot command has been added to look for the m4_fw.bin as the root of any external storage (SD, USB, SATA): U-Boot > run m4update This command will download the firmware from external storage to RAM and flash it at the offset 0x1E0000 of the NOR. While debugging on the MCU, you might wish not to write every firmware into NOR so we've added a command that loads the M4 firmware directly from external storage. U-Boot > setenv m4boot 'run m4boot_ext' Before going any further, make sure to hook up the second serial port to your machine as the one marked as "console" will be used for U-Boot and the other one will display data coming from the MCU. In order to start the MCU at boot up, we need to set a variable that will tell the 6x_bootscript to load the firmware into OCRAM. If you wish to start the MCU at every boot, make sure to save this variable. U-Boot > setenv m4enabled 1 U-Boot > boot While the kernel is booting, you should see the following prompt on the MCU serial output: ***** MCC PINGPONG EXAMPLE ***** Please wait :   1) A9 peer is ready   Then press "S" to start the demo ******************************** Press "S" to start the demo : Press the S key as requested above on the MCU serial console and then log into Buildroot on the MPU serial output (login is root, no password). You now need to enable the MPU side of the communication before starting the demo: # echo 1 > /sys/bus/platform/drivers/imx6sx-mcc-test/mcctest.15/pingpong_en & A9 mcc prepares run, MCC version is 002.000 test/mcctest.15/pingpong_en & # Main task received a msg from [1, 0, 2] endpoint Message: Size=0x00000004, data = 0x00000002 Main task received a msg from [1, 0, 2] endpoint Message: Size=0x00000004, data = 0x00000004 ... That's it, you've built a MCU application from scratch and can now start exploring all the examples provided inside the MQX SoloX release.
View full article
This blog post will present the architecture of the i.MX6SoloX and i.MX7D processors and explain how to build and run the FreeRTOS BSP v1.0.1 on the MCU. Both processors are coupling a Cortex-A with a Cortex-M4 core inside one chip to offer the best of MPU and MCU worlds (see i.MX7D diagram). Content below will apply for our Nit6_SoloX and Nitrogen7 platforms. For the impatient You can download a demo image from here: 20160804-buildroot-nitrogen6sx-freertos-demo.img.gz for Nit6_SoloX 20160804-buildroot-nitrogen7-freertos-demo.img.gz for Nitrogen7 As usual, you’ll need to register on our site and agree to the EULA because it contains NXP content. The image is a 1GB SD card image that can be restored using zcat and dd under Linux. ~$ zcat 20160804-buildroot*.img.gz | sudo dd of=/dev/sdX bs=1M For Windows users, please use Alex Page’s USB Image Tool. This image contains the following components: Linux kernel 4.1.15 U-Boot v2016.03 FreeRTOS 1.0.1 demo apps Please make sure to update U-Boot from its prompt before getting started: => run clearenv => run upgradeu After the upgrade, the board should reset, you can start your first Hello World application on the Cortex-M4: => run m4update => run m4boot Architecture As an introduction, here is the definition of terms that will be used throughout the post: MCU: Microcontroller Unit such as the ARM Cortex-M series, here referring to the Cortex-M4 MPU: Microprocessor Unit such as the ARM Cortex-A series, here referring to the Cortex-A9/A7 RTOS: Real-Time Operating System such as FreeRTOS or MQX The i.MX6SX and i.MX7 processors offer an MCU and a MPU in the same chip, this is called a Heterogeneous Multicore Processing Architecture. How does it work? The first thing to know is that one of the cores is the "master", meaning that it is in charge to boot the other core which otherwise will stay in reset. The BootROM will always boot the Cortex-A core first. In this article, it is assumed that U-Boot is the bootloader used by your system. The reason is that U-Boot provides a bootaux command which allows to start the Cortex-M4. Once started, both CPU are on their own, executing different instructions at different speeds. Where is the code running from? It actually depends on the application linker script used. When GCC is linking your application into an ELF executable file, it needs to know the code location in memory. There are several options in both processors, code can be located in one of the following: TCM (Tightly Coupled Memory): 32kB available OCRAM: 32kB available If not using the EPDC, 128kB can be used but requires to modify the ocram linker script DDR: up to 1MB available QSPI flash (not available for ou Nit6_SoloX): 128kB allocated on Nitrogen7 Note that the TCM is the preferred option when possible since it offers the best performances since it is an internal memory dedicated to the Cortex-M4. External memories, such as the DDR or QSPI, offer more space but are also much slower to access. In this article, it is assumed that every application runs from the TCM. When is the MCU useful? The MCU is perfect for all the real-time tasks whereas the MPU can provide a great UI experience with non real-time OS such as GNU/Linux. We insist here on the fact that the Linux kernel is not real-time, not deterministic whereas FreeRTOS on Cortex-M4 is. Also, since its firmware is pretty small and fast to load, the MCU can be fully operating within a few hundred milliseconds whereas it usually takes Linux OS much longer to be operational. Examples of applications where the MCU has proven to be useful: Motor control: DC motors only perform well in a real-time environment since feedback response time is crucial Automotive: CAN messages can be handled by the MCU and operational at a very early stage Resource Domain Controller (RDC) Since both cores can access the same peripherals, a mechanism has been created to avoid concurrent access, allowing to ensure a program's behavior on one core does not depend on what is executed/accessed on the other core. This mechanism is the RDC, it can be used to grant peripheral and memory access permissions to each core. The examples and demo applications in the FreeRTOS BSP use RDC to allocate peripheral access permission. When running the ARM Cortex-A application with the FreeRTOS BSP example/demo, it is important to respect the reserved peripheral. The FreeRTOS BSP application has reserved peripherals that are used only by ARM Cortex-M4, and any access from ARM Cortex-A core on those peripherals may cause the program to hang. The default RDC settings are: The ARM Cortex-M4 core is assigned to RDC domain 1, and ARM Cortex-A core and other bus masters use the default assignment (RDC domain 0). Every example/demo has its specific RDC setting in its hardware_init.c. Most of them are set to exclusive access. The user of this package can remove or change the RDC settings in the example/demo or in his application. It is recommended to limit the access of a peripheral to the only core using it when possible. Also, in order for a peripheral not to show up as available in Linux, it is mandatory to disable it in the device, which is why a specific device tree is used when using the MCU: imx7d-nitrogen7-m4.dts The memory declaration is also modified in the device tree above in order to reserve some areas for FreeRTOS and/or shared memory. Remote Processor Messaging (RPMsg) The Remote Processor Messaging (RPMsg) is a virtio-based messaging bus that allows Inter Processor Communications (IPC) between independent software contexts running on homogeneous or heterogeneous cores present in an Asymmetric Multi Processing (AMP) system. The RPMsg API is compliant with the RPMsg bus infrastructure present in upstream Linux 3.4.x kernel onward. This API offers the following advantages: No data processing in the interrupt context Blocking receive API Zero-copy send and receive API Receive with timeout provided by RTOS Note that the DDR is used by default in RPMsg to exchange messages between cores. Here are some links with more details on the implementation: RPMsg_RTOS_Layer_User's_Guide.pdf https://www.kernel.org/doc/Documentation/rpmsg.txt Where can I find more documentation? The BSP actually comes with some documentation which we recommend reading in order to know more on the subject: FreeRTOS_BSP_1.0.1_i.MX_7Dual_Release_Notes.pdf FreeRTOS_BSP_for_i.MX_7Dual_Demo_User's_Guide.pdf FreeRTOS_BSP_i.MX_7Dual_API_Reference_Manual.pdf Getting_Started_with_FreeRTOS_BSP_for_i.MX_7Dual.pdf Build instructions Development environment setup In order to build the FreeRTOS BSP, you first need to download and install a toolchain for ARM Cortex-M processors. ~$ cd && mkdir toolchains && cd toolchains ~/toolchains$ wget https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q3-update/+download/gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 ~/toolchains$ tar xjf gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 ~/toolchains$ rm gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 FreeRTOS relies on cmake to build, so you also need to make sure the following packages are installed on your machine: ~$ sudo apt-get install make cmake Download the BSP The FreeRTOS BSP v1.0.1 is available from our GitHub freertos-boundary repository. ~$ git clone https://github.com/boundarydevices/freertos-boundary.git freertos ~$ cd freertos Depending on the processor/board you plan on using, the branch is different. For Nit6_SoloX (i.MX6SX), use the imx6sx_1.0.1 branch. ~/freertos$ git checkout origin/imx6sx_1.0.1 -b imx6sx_1.0.1 For Nitrogen7 (i.MX7D), use the imx7d_1.0.1 branch. ~/freertos$ git checkout origin/imx7d_1.0.1 -b imx7d_1.0.1 Finally, you need to export the ARMGCC_DIR variable so FreeRTOS knows your toolchain location. ~/freertos$ export ARMGCC_DIR=$HOME/toolchains/gcc-arm-none-eabi-4_9-2015q3/ Build the FreeRTOS apps First, here is a quick overview of what the FreeRTOS BSP looks like: All the applications are located under the examples folder: examples/imx6sx_nit6sx_m4/ for Nit6_SoloX examples/imx7d_nitrogen7_m4/ for Nitrogen7 As an example, we will build the helloworld application for Nitrogen7: ~/freertos$ cd examples/imx7d_nitrogen7_m4/demo_apps/hello_world/armgcc/ ~/freertos/examples/imx7d_nitrogen7_m4/demo_apps/hello_world/armgcc$ ./build_all.sh ~/freertos/examples/imx7d_nitrogen7_m4/demo_apps/hello_world/armgcc$ ls release/ hello_world.bin hello_world.elf hello_world.hex hello_world.map The build_all.sh script builds both debug and release binaries. If you don't have a JTAG to debug with, the debug target can be discarded. You can then copy that hello_world.bin firmware to the root of an SD card to flash it. Run the demo apps Basic setup First you need to flash the image provided at the beginning of this post to an SD Card. The SD Card contains the U-Boot version that enables the use of the Cortex-M4 make sure to update it as explained in the impatient section. By default, the firmware is loaded from NOR to TCM. You can execute m4update to upgrade the firmware in NOR. It will look for file named m4_fw.bin as the root of any external storage (SD, USB, SATA) and flash it at the offset 0x1E0000 of the NOR: => run m4update If you wish to flash a file named differently, you can modify the m4image variable as follows: => setenv m4image While debugging on the MCU, you might wish not to write every firmware into NOR so we've added a command that loads the M4 firmware directly from external storage. => setenv m4boot 'run m4boot_ext' Before going any further, make sure to hook up the second serial port to your machine as the one marked as "console" will be used for U-Boot and the other one will display data coming from the MCU. In order to start the MCU automatically at boot up, we need to set a variable that will tell the 6x_bootscript to load the firmware. To do so, make sure to save this variable. => setenv m4enabled 1 => saveenv This blog post only considers the TCM as the firmware location for execution. If you wish to use another memory, such as the OCRAM or QSPI or DDR, you can specify it with U-Boot variables. => setenv m4loadaddr => setenv m4size Note that the linker script must be different for a program to be executed from another location. Also, the size reserved in NOR right now is 128kB. Hello World app The Hello World project is a simple demonstration program that uses the BSP software. It prints the "Hello World" message to the ARM Cortex-M4 terminal using the BSP UART drivers. The purpose of this demo is to show how to use the UART and to provide a simple project for debugging and further development. In U-Boot, type the following: => setenv m4image hello_world.bin => run m4update => run m4boot On the second serial port, you should see the following output: Hello World! You can then type anything in that terminal, it will be echoed back to the serial port as you can see in the source code. RPMsg TTY demo This demo application demonstrates the RPMsg remote peer stack. It works with Linux RPMsg master peer to transfer string content back and forth. The Linux driver creates a tty node to which you can write to. The MCU displays what is received, and echoes back the same message as an acknowledgement. The tty reader on ARM Cortex-A core can get the message, and start another transaction. The demo demonstrates RPMsg’s ability to send arbitrary content back and forth. In U-Boot, type the following: => setenv m4image rpmsg_str_echo_freertos_example.bin => run m4update => boot On the second serial port, you should see the following output: RPMSG String Echo FreeRTOS RTOS API Demo... RPMSG Init as Remote Once Linux has booted up, you need to load the RPMsg module so the communication between the two cores can start. # modprobe imx_rpmsg_tty imx_rpmsg_tty rpmsg0: new channel: 0x400 -> 0x0! Install rpmsg tty driver! # echo test > /dev/ttyRPMSG The last command above writes into the tty node, which means that the Cortex-M4 should have received data as it can be seen on the second serial port. Name service handshake is done, M4 has setup a rpmsg channel [0 ---> 1024] Get Message From Master Side : "test" [len : 4] Get New Line From Master Side RPMsg Ping Pong demo Same as previous demo, this one demonstrates the RPMsg communication. After the communication channels are created, Linux OS transfers the first integer to FreeRTOS OS. The receiving peer adds 1 to the integer and transfers it back. The loop continues infinitely. In U-Boot, type the following: => setenv m4image rpmsg_pingpong_freertos_example.bin => run m4update => boot On the second serial port, you should see the following output: RPMSG PingPong FreeRTOS RTOS API Demo... RPMSG Init as Remote Once Linux has booted up, you need to load the RPMsg module so the communication between the two cores can start. # modprobe imx_rpmsg_pingpong imx_rpmsg_pingpong rpmsg0: new channel: 0x400 -> 0x0! # get 1 (src: 0x0) get 3 (src: 0x0) get 5 (src: 0x0) ... While you can send the received data from the MCU on the main serial port, you can also see the data received from the MPU on the secondary serial port. Name service handshake is done, M4 has setup a rpmsg channel [0 ---> 1024] Get Data From Master Side : 0 Get Data From Master Side : 2 Get Data From Master Side : 4 ... That's it, you should now be able to build, modify, run and debug
View full article
iWave Systems, AI/ML demo shows a low power smart door running eIQ heterogeneously on NXP i.MX 8M Mini Development kit. The demo application is built around the Django framework running on the board. In addition to face recognition, the MPUs are able to run a Django server to manage the user’s database, a QT5 application for the graphical interface, and perform training on the edge.
View full article
NXP i.MX8M-Mini CPU, quad-core Cortex-A53 Up-to 4GB RAM and 128GB eMMC LTE modem, WiFi 802.11ac, Bluetooth 5.0 2x Ethernet, 3x USB2, RS485/RS232, CAN-FD Custom I/O expansion boards Fanless design in aluminum, rugged housing Designed for reliability and 24/7 operation Wide temperature range of -40C to 80C Wide input voltage range of 8V to 36V Debian Linux, Yocto Project and mainline kernel Support for Docker and Microsoft Azure IoT   IOT-GATE-iMX8 is built around the NXP i.MX8M Mini System-on-Chip, featuring an advanced ARM Cortex-A53 CPU. The SoC is supplemented with up-to 4GB LPDDR4 and 128GB of eMMC storage.   Featuring dual Ethernet, CAN-FD, LTE modem, 802.11ac WiFi and Bluetooth 5.0, IOT-GATE-iMX8 is a highly versatile platform for industrial control, networking, communications and IoT applications. Fanless rugged enclosure design, wide range DC input of 8V to 36V and industrial temperature range of -40C to 80C make IOT-GATE-iMX8 an ideal solution for industrial installations and harsh environments.  IOT-GATE-iMX8 is provided with ready-to-run Debian Linux and full Linux Board Support Package. IOT-GATE Linux packages support Docker and Microsoft Azure IoT.   IOT-GATE-iMX8 spec IOT-GATE-iMX8 evaluation kit IOT-GATE-iMX8 pricing
View full article
NXP MCU-level face recognbition solution is implemented by using i.MX RT106F, which makes the developers add face recognition capabilities to their MCU-based IoT products. This ultra-small size, integrated software algorithm and hardware solution can facilitate developers for rapid evalution and proof of concept development. This solution minimizes time to market, reduces risk and reduces development work, which can make it easier for many OEMs to add face recogtion functions. It provides advanced user interface and access control functions for smart homes, smart appliances, smart toys and smart industries without the need for Wi-Fi and cloud connectivity, solving the privacy issues of many consumers. i.MX RT106F is a member of the i.MX RT1060 series. It will be officially mass-produced in April 2020. It is mainly aimed at low-cost face recognition applications. It is based on the Arm Coretx-M7 core and a high-performance real-time processor with a frequency up to 600MHz. In addition to the face recognition function, the i.MX RT106F also has a large number of available peripherals, which can be used as the main chip for a variety of applications. i.MX RT106F has been licensed to run NXP OASIS runtime for face recognition, including: ● Camera Driver ● Image capture and preprocessing ● Face Detection ● Face Tracking; ● Face Contrast; ● Face Recognition; ● Anti-fraud; ● Face Configuration; ● Confidence; ● Face recognition authenticat results; ● Built-in secure bootloader, application verification; ● Automatic Verification Script; ● Support MCUXpresso SDK, IDE and configuration tools. Hardware Framework Software Framework Core Process of Software
View full article
Hi All, One of my recent work with IMXRT Series MCU's, A Simple Drum Pad Proto designed with IMXRT Crossover platform MCU's and Capsense touch. For more details about the project and source. checkout here https://www.hackster.io/ashokr/imx-rt-drum-pad-a8c1cd Thanks Ashok R Embedded Club (@embeddedclub) • Instagram photos and videos #nxp 
View full article
MYD-JX8MX development board based on NXP i.MX8M quad processors provides powerful multi-media functions including dual displays, dual cameras, high-quality audio, etc. The target applications scale from consumer home audio to industrial building automation and mobile computers requiring high-performance and low-power processors. Highlights: - MYC-JX8MX CPU Module as Controller Board - NXP i.MX 8M Quad Application Processor - 1GB / 2GB LPDDR4, 8GB eMMC Flash, 256Mbit QSPI Flash - RS232, 4 x USB 3.0 Host, 1 x USB 3.0 Host/Device, PCIe 3.0 (x4) NVMe SSD Interface, TF Card Slot - Supports Gigabit Ethernet, WiFi/BT and 4G LTE - 2 x MIPI-CSI, HDMI, 2 x LVDS, MIPI-DSI, Audio Input/Output
View full article
Watch the demo of Color Segmentation using e-CAM130_iMX8 - 13MP Autofocus Camera Board for i.MX8. e-CAM130_iMX8 is a 13MP 4-lane MIPI CSI-2 autofocus color camera board for i.MX8 family of processors. The e-CAM130_iMX8 camera board is interfaced directly to the CSI-2 MIPI interface on the Variscite's DART-MX8M Evaluation kit (VAR-DVK-DT8M). The iHDR (interlaced High Dynamic Range) support helps to capture good quality images in both high and low illumination. e-CAM130_iMX8 also comes with a high-performance Image Signal Processor (ISP) that performs all the Auto functions (autofocus, auto white balance, auto exposure control).
View full article
e-con Systems with over 15 years of experience in pioneering different cameras for embedded devices have been working towards integrating MIPI CSI-2 cameras to the i.MX 8M EVK from NXP. Our current pursuit to interface the e-CAM130_MI1335_MOD to the MCIMX8M-EVK was successful and we have evaluated the following resolutions and framerates. S. No Resolution Framerate (per second) 1 640×480 120 2 1280×720 80 3 1920×1080 80 4 3840×2160 30 5 4192×3120 13* Table 1 : Resolutions and framerates supported * – under development. Expected to go higher. The MCIMX8M-EVK is the official evaluation kit for the i.MX 8M series application processors from NXP. It has a quad core ARM Cortex A53 running at 1.5 GHz and an ARM Cortex M4 core for low power operations and 3GB of LPDDR4 RAM. The MCIMX8M-EVK supports 2 MIPI CSI2 cameras in 4 lane configuration simultaneously. It also has other IO options such as a DSI display interface, HDMI 2.0, USB 3.0, MicroSD, Ethernet and Audio out. This configuration is ideal for designing low power devices such as OTT STBs, AV receivers, handheld devices, machine visual inspection systems and other general-purpose HMI solutions. The e-CAM130_MI1335_MOD uses the 1/3.2” AR1335 rolling shutter sensor from ON Semiconductor. This sensor supports a maximum resolution of 13MP with an active pixel array of 4208×3120. We have also added additional features such as 3A (Auto Exposure, Auto Focus, Auto White Balance) and HDR imaging using a dedicated onboard ISP. The output format of the camera is UYVY which removes the need for bayer demosaic processing on the host processor. This camera is ideal for developing high resolution imaging with HDR for close range machine visual inspection. You can soon expect our launch for various camera products for the i.MX 8M platform. Please check out our product page for updates.
View full article
Mar 13, 2020: imx_builder_03122020.tgz  --- change the i.MX8MN  configuration.  Dec 11, 2019: imx_builder_12112019.tgz --- add support  L4.19.35_1.1.0 August 28, 2019:  imx_builder_08282019.tgz   --- add i.MX8MM July 03, 2019:  imx_builder_07032019.tgz --- add i.MX8QM: build_i.MX8  Feb 26, 2020: imx_builder_02262020 --- add i.MX8MN, add spl m4 for build_i.MX8, build_i.MX8X with L4.14.98_2.0.0_ga, L4.14.98_2.2.0, L4.19.35_1.1.0 imx_builder_02262020: imx_builder |-- atf -> bsp/imx-atf |-- bsp -> REL/rel_imx_4.19.35_1.1.0 |-- build -> build_i.MX8X/L4.19.35_1.1.0 |-- build_i.MX6 |   |-- L3.0.x |   |-- L3.1x.xx |   |-- L4.14.xx |   |-- L4.19.xx |   `-- L4.1.xx |-- build_i.MX8 |   |-- before_L4.14.98_2.0.0_ga |   |-- L4.14.98_2.0.0_ga |   |-- L4.14.98_2.2.0 |   `-- L4.19.35_1.1.0 |-- build_i.MX8M |   |-- before.L4.19.35 |   `-- L4.19.35 |-- build_i.MX8MM |   |-- before.L4.19.35 |   `-- L4.19.35 |-- build_i.MX8MN |   `-- L4.19.35 |-- build_i.MX8X |   |-- before_L4.14.98_2.0.0_ga |   |-- L4.14.98_2.0.0_ga |   |-- L4.14.98_2.2.0 |   `-- L4.19.35_1.1.0 |-- dts -> linux/arch/arm/boot/dts |-- dts64 -> linux/arch/arm64/boot/dts/freescale |-- dts_uboot -> u-boot/arch/arm/dts |-- imx-mkimage -> bsp/imx-mkimage |-- linux -> bsp/linux-imx |-- m4_img |   |-- m4_1_image.bin -> rpmsg_lite_str_echo_rtos_imxcm4.bin |   |-- m4_image.bin -> power_mode_switch.bin |   `-- readme.txt |-- Makefile -> build/Makefile |-- Others |   |-- clk_module |   |-- cryptodev-linux-1.8 |   |-- helloworld_module |   |-- key_blob_module |   `-- spi |-- out |-- README -> build/README |-- REL |-- scfw -> bsp/scfw |-- SETTINGS.MK -> build/SETTINGS.MK |-- toolchains |   `-- scfw |-- u-boot -> bsp/uboot-imx `-- VERSION.MK imx_builder is a set of Makefile for build u-boot, Linux kernel, atf, scfw, imx-mkimage.  You can call it standalone build. here is the step to try it.  You can use  -n for make to get the detail build steps. ex:  make atf -n         make linux.Image -n L4.14.78_ga as example: 1. Untar  imx_builder_02282019.tgz 2. Read the  Standalone_Build_Preparation.pdf inside to prepare the bsp. 3. Prepare the toolchains(populate_sdk from yocto, get from linaro, get from buildroot, etc.) 4. Prepare scfw toolchains following the SCFW Porting Kit.  5. Follow the Standalone_Build_Preparation.pdf to check if the Build Structure is correct. Build Structure L4.14.78_1.0.0_ga as example. Prepare rel_imx_4.14.78_1.0.0_ga in REL Make symbol link to REL/rel_imx_4.14.78_1.0.0_ga Make symbol link to build_i.MX8X   imx_builder/ |-- atf -> bsp/imx-atf |-- bsp -> REL/rel_imx_4.14.78_1.0.0_ga |-- build -> build_i.MX8X |-- build_i.MX6 |-- build_i.MX8M |-- build_i.MX8X |   |-- Makefile -> Makefile.4.14.78_ga |   |-- Makefile.4.14.78_ga |   |-- README |   |-- SETTINGS_4.14.78_1.0.0_ga.MK |   |-- SETTINGS.MK -> SETTINGS_4.14.78_1.0.0_ga.MK |   `-- VERSION.MK |-- dts -> linux/arch/arm/boot/dts |-- imx-mkimage -> bsp/imx-mkimage |-- linux -> bsp/linux-imx |-- Makefile -> build/Makefile |-- Others |-- out |-- README -> build/README |-- REL |   `-- rel_imx_4.14.78_1.0.0_ga |       |-- firmware-imx-8.0.bin |       |-- imx-atf |       |-- imx-mkimage |       |-- imx-sc-firmware-1.1.bin(optional) |       |-- imx-scfw-porting-kit-1.1.tar.gz |       |-- linux-imx |       `-- uboot-imx |-- scfw -> bsp/scfw |-- SETTINGS.MK -> build/SETTINGS.MK |-- Standalone_Build_Preparation.pdf |-- toolchains |   `-- scfw |       `-- gcc-arm-none-eabi-6-2017-q2-update |-- u-boot -> bsp/uboot-imx `-- VERSION.MK -> build/VERSION.MK
View full article
MYIR launches a 7-inch HMI display panel with capacitive touch screen, the MYD-Y6ULX-CHMI, which runs Linux on NXP’s i.MX6 ULL ARM Cortex-A7 processor, is specially designed for HMI system like POS, intelligent access control and more other applications. It provides many peripheral interfaces and much software resources. Know more at MYD-Y6ULX-CHMI | 7-inch HMI Display Solution based on NXP i.MX 6UL/6ULL-Welcome to MYIR 
View full article
MYIR launches a 7-inch HMI display panel with capacitive touch screen, the MYD-Y6ULX-CHMI, which runs Linux on NXP’s i.MX6 ULL ARM Cortex-A7 processor, is specially designed for HMI system like POS, intelligent access control and more other applications. It provides many peripheral interfaces and much software resources. Know more at MYD-Y6ULX-CHMI | 7-inch HMI Display Solution based on NXP i.MX 6UL/6ULL-Welcome to MYIR 
View full article
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
View full article
澳洲大学挂科怎么办联系QQ1252839746,考试挂科作弊、GPA低被开除退学、收到学术警告。澳洲大学2018 S1的Final成绩已经在陆续发放了,拿到成绩的时候,有些人难免会沮丧,复习了的内容没考,考的内容没复习,所以就有科目理所应当的挂科了…… 澳洲大学向来是宽!进!严!出!随着成绩的公布,小伙伴们都在问挂科了到底该怎么办?一起来了解一下不同情况的挂科该如何处理吧! 同一学期挂科科目挂科小于等于50% 什么叫挂科科目小于等于50%呢?各大学的课程设置都是一学期4门课,如果你在一学期中挂了1-2门,但是还没有出现double fail(一科已经连续fail两次以上),那么学校不会对你有任何行动,下学期一定要争取4门全部Pass来弥补! 同一学期挂科科目挂科大于等于50% 大于等于50%的意思就是如果在一学期中挂了2门以上课程,那一般学校就会采取第一次行动了,会对你发出一封警告信! 学校出勤率低于80% 和挂科无关,但非常重要。如果同学们在一学期中,因各种原因出勤率不满80%的,并且针对这过低的出勤率没有合理的理由,学校也会先对你做出警告需要解释,如果理由没有被学校接受,学校也有资格将你上报移民局,移民局可以会跟据情况取消签证。 努力学习却还是挂科 如果是平时十分努力却还是掌控不了挂科的同学门要及早正视自己的问题,对自己挂科的原因进行总结,可能是由于专业不适合,学习能力不够,学校和你的学习理念存在差异……而这类学生最重要的就是正视自己的情况考虑转学校或者是换专业。 警告信解释 当你不幸收到开除警告信后,书面解释的质量非常重要。 首先,解释列举的原因,一定是不可控的因素,由此导致的学习成绩差;接着表明自己坚信可以完成学业,并列举理由;最后认真的规划应该如何去克服困难,努力提高成绩。 如果以身体健康原因作为理由,必须准备辅助材料,如医生开具的证明等,一同上交。校方受理后会决定十分需要召开听证会,听证会后即会给出解释结果。 转校 这里需要提醒小伙伴们如果被公立大学开除,则无法转到其它公立大学继续学习,只能转到各种私立大学或学院,但可以在收到学校警告信后,马上开始准备转学事宜,在开除程序正式开始之前申请转学。 转学 若未读满6个月的课程就申请转学,首先需要获得想转学学校OFFER,然后向在读学校申请Release letter(放行信),在读学校会根据转学政策和程序审核申请,再决定是否发放Release letter; 如果已经在主课学校就读超过六个月,一般学校都会同意学生的转学申请。 在澳洲挂科除了昂贵的学费外,还有可能会面临强制退学和取消学生签证,并且3年都不得进入澳洲,所以要谨慎对待每次考试,澳洲大学挂科改成绩(Q1252839746)挂科GPA成绩修改,解决被退学开除等问题。
View full article
Imx6 can output lvds direct.But the lvds-wire is too  expensive to buy. So they can cannect ds90ub947 serializer to applied in automotive instrumentation. By the way, it need a ds90ub948 deserializer in the remote which cannect a lvds displayer. The attachment is the driver of ds90ub947/948 for linux.It can  support linux 3.10 and above.It was verified working on linux 3.10.53 and imx6q. The attachment list: ds90ub947.c ds90ub947.h readme.txt You can follow the readme to use it. This driver was barely in embryo.You should modify it according to your application. Sometime, it very looks like the ds90ub913/914 and max9286/96705.
View full article
e-con Systems launches the 13MP Autofocus 4-lane MIPI camera board for NXP i.MX6. This camera is based on 1/3.2" AR1335 CMOS image sensor with advanced 1.1µm pixel BSI technology from ON Semiconductor® and an integrated high-performance image signal processor (ISP) that performs all the Auto functions (Auto White Balance, Auto Exposure control). Target Applications Kiosk Documents Reader/Scanner Unmanned Aerial Vehicles (UAVs) Autonomous Robotic Systems Mobile Medical Imaging Intelligent Video Analytics (IVA) Features Benefits Advanced 1.1µm pixel BSI technology Delivers superior low-light image quality and produces accurate color reproduction 1080p @80 fps - YUV422 High quality HD video playback Interlaced High Dynamic Range (iHDR) Allows to capture clear images in both extreme lighting conditions Pan Tilt Digital Zoom(Upto 8x) Allows to get a closer view of far-away objects Autofocus Allows users to reliably and easily maintain sharp focus on subjects as they move throughout the frame
View full article
e-con Systems announces their new System-On-Module aimed for Applications which require higher GPU performance and faster network connectivity. eSOMiMX6PLUS System-On-Module is based on NXP’s QuadPLUS/DualPLUS ARM Cortex™ A9 Processor running up to 1.2GHz, featuring 3 high speed Camera interfaces with support for 13MP Camera and supporting 802.11 ac Wi-Fi network. The eSOMiMX6PLUS at volumes is available at USD79 onwards and samples can be bought from the Webstore. Customers wanting to evaluate thee SOMiMX6PLUS, can do so by ordering the AnkaaPLUS development kit from e-con’s Webstore. The development kit, among other accessories, also includes a13MP camera board, 5MP camera board and 7” LCD panel. 
View full article