i.MXプロセッサ ナレッジベース

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

i.MX Processors Knowledge Base

ディスカッション

ソート順:
The user interface has limited the use of the tool GUI Guider. Getting an interaction only through a mouse or touchscreen can be enough for some use cases. However, sometimes the use case requires to go beyond its limitations. This video/appnote explores the possibility of integrating voice by creating a bridge between a speech recognition technology, such as VIT, and the interface creator GUI Guider. It uses a universal way to link all the voice recognition commands and a wakeword to any interaction created by GUI Guider. The following video shows the steps necessary to create that connection by creating the voice recognition using VIT voice commands and wakewords, create an interface of GUI Guider using a template, how to connect between them using the board i.MX 93 evk and testing it. For more information consult the following links AppNote HTML: https://docs.nxp.com/bundle/AN14270/page/topics/abstract.html?_gl=1*1glzg9k*_ga*NDczMzk4MDYuMTcxNjkyMDI0OA..*_ga_WM5LE0KMSH*MTcxNjkyMDI0OC4xLjEuMTcxNjkyMDcyMy4wLjAuMA AppNote PDF: https://www.nxp.com/docs/en/application-note/AN14270.pdf Associated File: AN14270SW  
記事全体を表示
[中文翻译版] 见附件   原文链接: https://community.nxp.com/docs/DOC-343116 
記事全体を表示
The i.MX27 multimedia applications processors balance high performance with low power consumption through an intelligent combination of dedicated hardware video accelerators and a fast ARM926EJ-S™ core. Both the i.MX27 and the i.MX27L processors provide an array of connectivity options and robust security. The rich feature set of the i.MX 27 processors make them an excellent choice for video- and voiceover- IP (V2IP) cordless and mobile phones, intelligent remote controls, point-of-sale terminals, control devices, low to mid end PNDs and many other wireless applications. i.MX Family Comparison Product Information on Freescale.com i.MX27 Multimedia Applications Processor i.MX27L Multimedia Applications Processor Evaluation/Development Boards and Systems IMX27PDK:  i.MX27 Development Kit Bootloader Compiling U-Boot for iMX27ADS Installing U-Boot on iMX27ADS Embedded Software and Tools Android OS for i.MX Applications Processors Partners / 3rd-Party Development Tools STK5:  Starter-Kit V for TX Modules with Freescale i.MX Processors (Karo Electronics) Additional Resources i.MX27 ADS Adding USB Host2 i.MX27 D1 Capture Kernel 2.6.22 Compiling U-Boot for i.MX27ADS IMX27-ADS i.MX27 ADS Board Flashing I.MX27 ADS Board Video i.MX27 ADS Board TV Out i.MX 27 ADS Adding USB Host2 i.MX 27 ADS Board Video GST Encode i.MX 27 ADS Board Video GST Play i.MX 27 ADS Compiling Linux Kernel Mainline i.MX 27 mDDR Issue i.MX 27 PDK I.MX27 PDK Board Flashing IMX27-Lite-Kit i.MX 27 Video GST Caps Installing U-Boot on i.MX27ADS
記事全体を表示
[Brief description] (1)Contents The ducoment introduced how to expand Gigabit Ethernet based on i.MX6 PCI Express, and attached schematics in DSN & pdf format. (2)Binary file for EEROM I have the binary file used to debug intel82574 circuit in this schematic, If customer wants to use it to debug board based on i.MX6+Intel82574, she can submit a case for me to get the file by our Salesforece system. Best Regards, TIC Weidong Sun Email: [email protected]
記事全体を表示
Question: How to enable HAB on the MX28, following the recommendations of AN4555 to get the "get_hab_status()" function working, but has run into an issue. Question #1 They believe they have all the HAB components worked out that are inputs to the efltosb tool as they are able to successfully run U-boot to the interactive prompt.  However, at the point where they:     - call the rvt_report_status() function, their board says "### ERROR ### Please RESET the board ###".      - call the rvt_entry(), their board prints some garbage characters on the screen and then hangs. This suggests that there is something wrong with the clock that in turn affects the baudrate on the serial console causing the above behavior. Question #2 Is there a concept of a "Bound Signature" in HABv4 as there is in HABv3? Any chance the addresses for the rvt_ calls are incorrect? Can you provide the u-boot source? Either Bound signature verification or UID is never mentioned in the HABv4 Application Note. So I suppose it is not supported. We have made assumptions about the RVT function pointer offsets.  The HAB 4 API does not explicitly say the offsets but uses a rvt_base::function_name notation.  We have assumed that function pointers are placed in order, at every word offset beyond the RVT header.  We have confirmed the RVT header exists at the latest address in the reference manual based on a memory dump but we cannot be certain the function offsets we have setup are correct. As far as source code, we modeled our changes for our mx28 board off of the hab.c and hab.h files available from the mainline u-boot for the mx6 architecture. This is basically the same code get_hab_status code that is written in the AN4555 document.  We did HAB API function pointer addresses to match the updated RVT base address and assumed offsets. Answer: Here are the first 3 instructions from report_status(), could your customer check the instructions from the address which they called is correct? <report_status>: :   b087b570        addlt   fp, r7, r0, ror r5 :   1c0e1c05        stcne   12, cr1, [lr], {5} :   22182433        andscs  r2, r8, #855638016      ; 0x33000000
記事全体を表示
    The document is about how to use WSL2 to compile yocto(android is the same process)  
記事全体を表示
   Memory Compatibility Guides   Processor/Family Link to Guide i.MX 8/8X/8XLite DDR3L & LPDDR4 i.MX 8M Quad/8M Mini/8M Nano/8M Plus DDR3L, DDR4, LPDDR4 i.MX 8ULP  LPDDR3, LPDDR4 & LPDDR4x i.MX 91 LPDDR4 - New i.MX 93 LPDDR4/LPDDR4x i.MX 95 LPDDR5/LPDDR4x - New Ara240 - DNPU LPDDR4 - New Other Processor Families Please contact NXP Support or Sales   Additional Resources i.MX Memory Fact Sheet DDR memory selection & enablement for i.MX platforms Smarter World Blog Building Resilient Embedded Systems: NXP’s Approach to DDR Memory Selection and Support DDR Configuration Tools DDR Configuration tool for i.MX  Developer Resources i.MX Developer Resources SW & Tools
記事全体を表示
This document mainly introduces how to use gpio usb id. This can provide more options to avoid pin conflicts.   iMX93 11x11 evk uses a peripheral circuit built with a typeC chip to perform USB role switch. However, in many cases, the hardware design does not have the same typeC circuit as the evk, and the USB ID is needed to do switch. The two USB IDs of the current iMX93 are muxed with the eQOS pins. The probability of this conflict is very high. So we need to use an alternative solution “gpio usb id”  to avoid this pin allocation conflict. MX93_PAD_ENET1_MDC__HSIOMIX_OTG_ID1 MX93_PAD_ENET1_MDC__ENET_QOS_MDC MX93_PAD_ENET1_TD3__HSIOMIX_OTG_ID2 MX93_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3   Based on lf-6.6.52-2.2.0  
記事全体を表示
Introduction LVGL is a graphics library to run on devices using a limited amount of resources. Previously, we have ran an LVGL demo from the LVGL repository, this contains a couple more demos which all of them are pieces of code included and lends us the opportunity to evaluate the library in a quick and easy way. GUI projects are developed by customers through a lot more options than bare code, there are GUI tools that translate a graphic asset into LVGL code, in this demonstration we will use a tool that's widely used in MCU GUI development and translate the GUI created into LVGL code; SquareLine. NOTE: refer to the appendix for precedent LVGL documents on i.MX series processors. HW set-up i.MX 93 EVK boot over eMMC/uSD to Linux Factory or Ubuntu. Connect power and debug receptables. Connect MX8_DSI_OLED1 to J701 (MIPI DSI) through MiniSAS cable. SquareLine set-up Download the latest version of SquareLine under the following link according to your host system. NOTE: This document is intended for demonstration of templates included within the tool, so it's recommended to download a free trial, for formal development please refer to the appendix of this document. Unzip and execute the installer, this is the windows prompt.   Demo download After setting SquareLine up go to the example section, we will demonstrate the thermostat capabilities with the Thermostat Demo. We can directly export these UI files and they would be graphically ready to be build, click on Export -> Export UI Files and select your preferred destination to save these.   LVGL setup. Option 1 Fresh Environment Clone LVGL and LV_DRIVERS repositories, this is a .gitmodules file that points to the specific branches needed. [submodule "lvgl"] path = lvgl url = https://github.com/lvgl/lvgl.git branch = release/v8.3 [submodule "lv_drivers"] path = lv_drivers url = https://github.com/lvgl/lv_drivers.git branch = release/v8.3 NOTE: If you are using other methods, you should point to these commits, lv_drivers @ 8cdabe8 and lvgl @ f2c1032. Gather the necessary files described below from the LVGL Linux Port example found here. Makefile lv_conf.h lv_drv_conf.h main.c mouse_cursor_icon.c Patch the Makefile. + include $(LVGL_DIR)/thermostat/thermostat.mk Patch the lv_drv_conf.h # define EVDEV_NAME "/dev/input/event10" /*You can use the "evtest" Linux tool to get the list of devices and test them*/ +# define EVDEV_NAME "/dev/input/event<Number>" NOTE: This changes according to the output of # evtest. Patch lv_conf.h -#define LV_FONT_MONTSERRAT_20 0 +#define LV_FONT_MONTSERRAT_20 1 Patch the main.c - disp_drv.hor_res = 800; - disp_drv.ver_res = 480; + disp_drv.hor_res = 1080; + disp_drv.ver_res = 1920; … - /*Create a Demo*/ - lv_demo_widgets(); + /*Create a Squareline Demo*/ + ui_init(); LVGL Setup. Option 2 with LVGL demos already running Gather the necessary files described below from the LVGL Linux Port example found here. Makefile lv_conf.h lv_drv_conf.h main.c mouse_cursor_icon.c Patch the lv_drv_conf.h # define EVDEV_NAME "/dev/input/event10" /*You can use the "evtest" Linux tool to get the list of devices and test them*/ +# define EVDEV_NAME "/dev/input/event<Number>" NOTE: This changes according to the output of # evtest. Patch the main.c - disp_drv.hor_res = 800; - disp_drv.ver_res = 480; + disp_drv.hor_res = 1080; + disp_drv.ver_res = 1920; … - /*Create a Demo*/ - lv_demo_widgets(); + /*Create a Squareline Demo*/ + ui_init(); Run the demo Build the demo with the following command and copy the ./demo output to the i.MX 93 EVK RootFS. # source /opt/path/to/your/toolchain # make clean # make The demo can be ran with the following commands. # systemctl stop weston # For LF $ sudo service gdm3 stop # For Ubuntu # ./demo   Conclusion SquareLine demos can run in prebuilt and basic builds of i.MX processors through FB, which can enable a quick set-up for GUI testing before moving to use a windowing stack without sacrificing any features. Appendix Document: How to run LGVL on iMX using framebuffer Official page for pricing information
記事全体を表示
Overview The purpose of this document is to provide a guide on how to enable UART 4 on i.MX8M Mini on Cortex A53. By default on i.MX-ATF is set on Cortex M4 Domain, i.MX-ATF helps ensure that i.MX processors boot securely. Reference: imx-atf. Requirements: Arm Toolchain: sudo apt-get install gcc-aarch64-linux-gnu 1. Build imx-boot image For a better reference how to build imx-boot image, go to Section 4.5.13 How to build imx-boot image by using imx-mkimage available on i.MX Linux User's Guide.   $ cd ~ $ git clone https://github.com/nxp-imx/uboot-imx -b lf_v2023.04 $ cd uboot-imx/ $ git checkout lf-6.6.23-2.0.0 $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- imx8mm_evk_defconfig $ export ARCH=arm64 $ cd ~ $ git clone https://github.com/nxp-imx/imx-mkimage.git $ cd imx-mkimage/ $ git checkout lf-6.6.23-2.0.0 $ cd ~ $ git clone https://github.com/nxp-imx/imx-atf.git $ cd imx-atf/ $ git checkout lf-6.6.23-2.0.0   The master domain for the UART4 is assigned to the Cortex M4, so, make the following changes to assign it to the A53 processor instead: diff --git a/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c b/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c index 179b6226f..b0427afff 100644 --- a/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c +++ b/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c @@ -114,10 +114,11 @@ static const struct imx_csu_cfg csu_cfg[] = { #else static const struct imx_rdc_cfg rdc[] = { /* Master domain assignment */ - RDC_MDAn(RDC_MDA_M4, DID1), + RDC_MDAn(RDC_MDA_A53, DID0), /* peripherals domain permission */ - RDC_PDAPn(RDC_PDAP_UART4, D1R | D1W), + RDC_PDAPn(RDC_PDAP_UART4, D0R | D0W), RDC_PDAPn(RDC_PDAP_UART2, D0R | D0W), RDC_PDAPn(RDC_PDAP_UART1, D0R | D0W),   After applying the changes, set your toolchain and then, compile with the following command: $ make PLAT=imx8mm bl31   In case you have the following error: Use this command to unset the flags and compile again: $ unset LDFLAGS   Then, copy the corresponding files to imx-mkimage/iMX8M. For more information, please check section 4.5.13 on i.MX Linux User's Guide. *NOTE: Some of this files are located on a link which you can access with the following command, for more information check the Release Notes, in this case for version 6.6.23-2.0.0 on Embedded Linux for i.MX Applications Processors. $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.24-fbe0a4c.bin $ chmod +x firmware-imx-8.24-fbe0a4c.bin $ ./firmware-imx-8.24-fbe0a4c.bin   Finally, copy flash.bin located on: imx-mkimage/iMX8M to a folder to flash your board as follows: You can download the uuu.exe from mfgtools and the .wic file from the prebuild images from: Embeded Linux for i.MX Applications Processors uuu.exe -b emmc_all flash.bin imx-image-full-imx8mmevk.wic   2. Change DTB to enable UART4 First, copy and rename the imx8mm-evk.dts to identify there is a change for enabling UART4: $ cd linux-imx $ cp arch/arm64/boot/dts/freescale/imx8mm-evk.dts arch/arm64/boot/dts/freescale/imx8mm-evk-uart4.dts $ vi arch/arm64/boot/dts/freescale/imx8mm-evk-uart4.dts And make the following changes: &ecspi2 { status = "disabled"; }; &uart4 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart4>; assigned-clocks = <&clk IMX8MM_CLK_UART4>; assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>; fsl,uart-has-rtscts; status = "okay"; }; &iomuxc { pinctrl_uart4: uart4grp { fsl,pins = < MX8MM_IOMUXC_ECSPI2_SCLK_UART4_DCE_RX 0x140 MX8MM_IOMUXC_ECSPI2_MOSI_UART4_DCE_TX 0x140 MX8MM_IOMUXC_ECSPI2_SS0_UART4_DCE_RTS_B 0x140 MX8MM_IOMUXC_ECSPI2_MISO_UART4_DCE_CTS_B 0x140 >; }; }   After applying the changes, set your toolchain and then, compile with the following commands: $ make imx_v8_defconfig $ make freescale/imx8mm-evk-uart4.dtb Finally, copy the DTB to your board, reboot it and change the DTB in the u-boot environment, boot your board and take a look to see if the UART4 is correctly enabled.    
記事全体を表示
This document is about to build an image by Yocto , and it will disable a function that normal user can’t use command line of “ su ”.
記事全体を表示
We are pleased to announce that Config Tools for i.MX v14.0 are now available. Downloads & links To download the installer for all platforms, please login to our download site via:  https://www.nxp.com/design/designs/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX Please refer to  Documentation  for installation and quick start guides. For further information about DDR config and validation, please go to this  blog post. Release Notes Full details on the release (features, known issues...) The product is based on Eclipse 2022-12 Open JDK 17 is updated. Batch processing on command line is supported. Support for SDK 2.14 in Project cloner and Detect toolchain project is added. Quick fix for errors allows setting the "Called by the default initialization function" flag when it would fix an error. Search functionality to Code Preview is added. TEE Export TEE registers via wizard or command line is available. Boot ROM hiding feature is supported. Tier mode for TRDC is supported. Domain ambivalence for RDC masters is added. Master-specific memory alias Validation for A28 bit of MPU region address is added. Memory map filters are aligned with Arm terminology. Status bar is united with other tools. Pins Labels defined for Expansion header pins can be set as identifiers of the routed pin. Expansion headers can be locked for editing. Expansion headers and boards are added to the HTML and CSV reports. Pins filtering is added into the expansion header pin routing dialogs. Columns from Routing Details can be added to the External User Signals view. New External User Signals can be created for all routed pins that are missing in the signals table. Clocks Support for the same frequencies settings from different source for internal clocks is added.
記事全体を表示
i.MX28 LCD driver 8080 bus interface mechanism please read readme.txt and it will teach you how to use it
記事全体を表示
Overview Measuring the power consumed an i.MX application processor can be a challenging undertaking. This document describes several boards designed to instrument i.MX application boards for current measurements. While this system does not offer many digits of accuracy, it can be used to quantify power consumed by application use cases as well as while in low power modes. The system can be used to instrument up to four power supply rails and measure current in two ranges. Range switching on the sensor boards is controlled via software running on the Kinetis K20 at the heard of the profiler board. Measured data is sent to a host computer over a virtual serial link over USB. Power for the profiler system is obtained from the USB connection although a external 5V supply may be used. Dual-Range Current Sensors INA250 + INA21x Sensor Circuit Description: The INA250 + INA21x Sensor board can measure two ranges using the INA250 and INA21x current sense amplifiers. The high range is measured with an INA250, which has an integrated 0.002 Ohm shunt, and is available in four output gains. The low range is measured with shunt R1 and the INA21x sense amp. The low range shunt is taken out of the circuit (by shorting it) with two paralleled, very low-Rds(on) FETs, Q1 and Q1. VCC_SENSE powers the two sense amplifiers. VCC_FET supplies the gate voltage on Q1 and Q2. The DMN1019 device has a Vgs max of 8V. The sources of both FETs are tied to the i.MX side of the current sense loop, so the gate voltage Q1 and Q2 see is VCC_FET-(rail voltage). The signal /LOW_EN controls the state of both Q1 and Q2. The sense amplifier outputs (HIGH_OUT1 and LOW_OUT1) and rail voltage (V_RAIL_MEASURE) are sent down the ribbon cable (X2) to the profiler board for measurement. When not used for a wire loop for a Hall-effect current probe, resistor R3 should be shorted with a solder bridge, a piece of wire, or a 0.001 Ohm resistor. Schematic: Board Layout: The two large vias by the current sense connection points are provided for use with a 0.1" header and jumper to short the low range shunt, allowing normal operation of the target board when the profiler is not powered. It should be noted a jumper will not be as effective for relatively large currents. BOM: Part   Device C1,C2  0.1uF 0805 Q1,Q2  DMN1019USN-13 SOT23 R1     2 1% 0805 (resize to change low range) R2     10k 0805 R3     Solder bridge/wire loop (see schematic) U1     INA250 TSSOP16 (choose gain, A3 [0.8V/A] or A4 [2.0V/A]) U2     INA21X SC70 (choose desired gain) X2     WM6769CT/0527460871 (bottom contacts) Dual INA21x Sensor Circuit Description: The Dual INA21x Sensor board can measure two ranges using two INA21x current sense amplifiers and two different shunts. The high range shunt (R1) is always in place. The low range shunt is taken out of the circuit (by shorting it) with two paralleled, very low-Rds(on) FETs, Q1 and Q1. VCC_SENSE powers the two sense amplifiers. VCC_FET supplies the gate voltage on Q1 and Q2. The DMN1019 device has a Vgs max of 8V. The sources of both FETs are tied to the i.MX side of the current sense loop, so the gate voltage Q1 and Q2 see is VCC_FET-(rail voltage). The signal /LOW_EN controls the state of both Q1 and Q2. The sense amplifier outputs (HIGH_OUT1 and LOW_OUT1) and rail voltage (V_RAIL_MEASURE) are sent down the ribbon cable (X2) to the profiler board for measurement. Schematic: Board Layout: The two large vias by the current sense connection points are provided for use with a 0.1" header and jumper to short the low range shunt, allowing normal operation of the target board when the profiler is not powered. It should be noted a jumper will not be as effective for relatively large currents. BOM: Part   Device C1,C2  0.1uF 0805 Q1,Q2  DMN1019USN-13 SOT23 R1     0.002 1% 0805 (resize to change high range) R2     0.05 1% 0805 (resize to change low range) R3     10k 0805 U1,U2  INA21X SC70 (choose desired gain) X2     WM6769CT/0527460871  (bottom contacts) Four-Channel Power Profiler Circuit Description: The Four-Channel Power Profiler board has at its heart a Kinetis K20 on a Teensy3.2 board. The ADCs of the K20 measure all the current sense amplifier's outputs, the voltage of each instrumented rail. There is provision for measuring temperature using up to three thermistors. GPIO provide control each sensor board's current range, and optionally, a hardware wake-up signal for the instrumented target board. Up to four dual-range sensor boards can be connected (either sensor board mentioned above). A micro-SD card socket is included for storing measured data (the SD card functionality has been tested but not implemented for use with measurements). Measured data is sent to the host computer over a virtual serial port using the Teensy's USB. Charge pump U1 boosts the 5V supply to 12V. The output is regulated down to 8V on VCC_FET via regulator U2. R2 and C5 provide filtering for the 3.3V supply from the Teensy that feeds the sensor boards through VCC_SENSE. FETs Q1 through Q4 provide voltage level translation which protect the Teensy's GPIO pins from the 8V that's placed on the gates of the shorting FETs on the sensor boards. Regulator IC2 provides power for the micro-SD socket, since the 3.3V regulator on the Teensy does not provide enough capacity. Since there are not "smarts" on the sensor boards, the Teensy has no way of knowing what kind of sensor board is connected or what shunt values and sense amplifier gains are in use. As currently implemented, current and voltage calculations are hard coded in the Teensy application code. Schematic: Board Layout: BOM: Part    Device C1,C2   0.22uF 0805 C3-C7   1uF 0805 C10,C12 1uF 0805 C11     0.1uF 0805 IC2     MCP1825ST-3302 SOT223 Q1-Q4   DMN1019USN SOT23 R2-R4   20k 1% 0805 R5-R8   10k 0805 R9      Ferrite bead 0805 S1-S4   WM6769CT/0527460871 (bottom contacts) U$1     101-00660-68-6-1-ND MICROSD U1      MAX662CPASO8 SO08 U2      78L08SMD SO08 Use mating Molex cables: 8in: 0150200087 or 10in: 0151660091 Using the Power Profiler Obtaining Sensor and Profiler Boards: Bare boards may be ordered directly from OSH Park using these links: INA250 + INA21x Sensor board (order with 2oz copper option selected) Dual INA21x Sensor board (order with 2oz copper option selected) Power Profiler board The sensor boards should be ordered with the 2oz copper option selected to reduce the trace resistance of the target board's current path. No special option is needed for the profiler board. Teensy3.2 boards may be ordered from OSH Park as well, and at a slightly lower price than the manufacturer (PJRC) sells them. Choosing Current Ranges: To choose the value of a shunt resistor, use the following equation: Rsh = Vfs / (Ifs * gain) where: Rsh is the shunt resistance Vfs is the full scale sense amplifier output voltage (3.3V here) Ifs is the full scale current to be measured gain is the gain of the sense amp to be used For example, to measure a 66mA full scale current with a sense amp of gain 1000, Rsh = 3.3V / (0.066A * 1000) = 0.050 Ohms. For sleep/leakage current, say 1mA full scale: Rsh = 3.3V / (0.001 * 1000) = 3.3 Ohms. The pads on both sensor boards for the shunt resistors have been laid out for 0805 SMT resistors. Precision resistors should be used, 1% or better. The highest power dissipation resistor available should be used to minimize resistance change from the shunt resistor heating up; 0805 resistors are typically available with 1/8, 1/4, 1/2 and 1 Watt dissipation. Building and Testing: These boards were designed to be assembled by hand in small quantities. The most difficult components to solder are the ribbon connectors and the SC70 packaged sense amplifiers. A fine tip soldering iron and a microscope are required. Solder wick is helpful for removing solder bridges from between pins (typically the ribbon connector and the sense amplifiers).  Early versions of the profiler board were assembled with header pins soldered to the Teensy and mating female recepticles soldered to the profiler board. Later versions (like in the example below) were assembled with male header pins between the Teensy and the profiler board.  To test the boards after assembly, check for the presence of 8V on the pull-up resistors R5-R8 when a USB cable is plugged into the Teensy. Program the Teensy with suitable application code. Connect the sensor boards to the profiler. Connect all the sensor boards together in series, positive of one to negative of the next and connect to a calibrated current source. (The image below shows an early prototype of the profiler with the sensor boards connected in series. Current is forced through them via the Kelvin contact clips.) Open a terminal window on the host computer. Force known currents and toggle the ranges of each sensor to verify that each sensor operates correctly in both ranges. To check that the profiler measures rail voltage correctly, disconnect the current source and apply the positive side of a voltage source to either side of the sensors still connected in series and connect the ground of the voltage source to a ground point on the profiler. The rail voltage measured by each sensor should match the supplied voltage (0 to 3.3V max). Accuracy/Calibration: After building in excess of 20 sensor boards and 6 profiler boards and checking their measurements against a Keysight B2902 SMU forcing known currents, the profiler system is fairly accurate. Measurements are good down to about 2% of any range's full scale; lower than that gets into the input offset range of the sense amplifier. Individual readings within 1% of that range's full scale when compared against forced current values. No calibration or tuning has been necessary. Measured values should only be considered good to at most 3 significant figures. Limitations: The maximum current through any sensor should be limited to a maximum of 4A. The current limit when using the low range needs to avoid exceeding the power dissipation of the low range shunt resistor. Particularly, the dissipation in the low range shunt resistor can cause resistance changes that would affect measurement accuracy. The voltage of any instrumented rail cannot be greater than 3.3V, the maximum input voltage of the K20's ADC inputs. Minimum resistance the sensor introduces is in high range is about 0.012 to 0.015 Ohms with a 0.002 Ohm shunt. At least 0.005 Ohms comes from the two shorting FETs on the sensor board. The rest comes from the traces on the board as well as the interconnect wires. The bottom line is: the sensor board has to be mounted as closely as possible to the current sense point on the target board. The maximum resistance the sensor introduces depends on the low range shunt. With a 0.020 Ohm low range shunt, the resistance is about 0.025 to 0.030 Ohms. With a 0.050 Ohm low range shunt, the resistance is about 0.065 to 0.075 Ohms. The sensor board needs to be rigidly mounted to prevent ripping up the current sense points on the target board. This can be a challenge when many rails are instrumented. Instrumenting Target Board: When instrumenting a target board, the on-board current sense resistor should be removed. The sensor board should be attached to the target board placed as close as possible to the sense resistor pads. Connection wires to the sensor board should be as short as possible to minimize series resistance. Great care should be taken to prevent movement of the sensor boards that could in turn lift the sense resistor pads off the target board. Foam double sticky tape should be used over clear areas of the target board to avoid dislodging components when the tape is removed. In the photos below, seven power supplies are instrumented on an interposer card. In this example, the sensor boards were affixed to perf board held in place by the headers. Because of the physical constraints of the target board and its power supply card, mounting the sensor boards directly to the interposer was not possible. Four sensors were mounted on one side and three on the other. Notches were cut in the perf board for the sensor's connection wires on the opposite side. Two profiler boards are required for simultaneous use. (Two were also required because the 0.1" headers and jumpers were not installed on the sensor boards to passively short the low-range shunts; all the sensor boards need to be powered to actively short the low-range shunts.)  The positive input of the sensor board (the center of the three connection points) goes to the regulator side of the current sense resistor. The negative input (either of the two outside connections) goes to the i.MX side of the sense resistor. [NOTE: In this example, the power profiler boards have not been fully populated: the thermistor-related components and the micro-SD card socket. The sensor boards were fully populated with the exception of the passive shorting jumper.] Here is another example of a board with six instrumented rails. The sensors in this case are mounted directly on the target board. In this example, the 12V rail is instrumented, which required modding to add a voltage divider to V_RAIL_LOWSIDE on that sensor board.  And here's yet another example of an instrumented i.MX6Q SDB (which still has wires on it from measuring it the old way...). Although it's difficult to see in this photo, all of the sensor boards have a jumper across the low range shunt which permits normal operation of the board without the profiler board attached to provide power to the shorting FETs. Profiler Application Code for Kinetis/Teensy: Below is sample application code for the Teensy for use with four INA250 + INA21x sensor boards populated with the INA250A3 (0.8V/A gain) for the high range and 0.05 Ohm shunts and INA212 (gain 1000). The current range of each channel can be independently changed. This code is also attached below as a file. Data is sent to the host computer over a USB virtual serial port. To reflash/update Teensy code, follow the instructions from PJRC. Download Windows virtual com port driver. /* MIT License (https://spdx.org/licenses/MIT.html) Copyright 2017 NXP Teensy Power Profiler v.2 (revised main board with individual Hi/Lo GPIO, fixed voltage levels, and on-board uSD card socket. Very basic code for the Teensy Power Profiler that sets up the ADCs and controls the GPIO with very basic, single-character serial commands... This version for all INA250A3 on high range, and 0.05Ohms+INA212 (1000 gain) on low range. */ // These constants won't change.  They're used to give names to the pins used: const int LoHiEn1 = 0; const int LoHiEn2 = 1; const int LoHiEn3 = 2; const int LoHiEn4 = 3; const int WakeUp = 5; const int Lo_1 = A0; const int Vrail_1 = A1; const int Hi_1 = A2; const int Lo_2 = A3; const int Vrail_2 = A4;  const int Hi_2 = A5; const int Lo_3 = A6; const int Vrail_3 = A7; const int Hi_3 = A8; const int Lo_4 = A9; const int Vrail_4 = A11; const int Hi_4 = A10; const int Therm1 = A14; #include <math.h> // thermistor temperature calculation stuff... int sensorValue = 0;        // value read from the pot float sensorValuef = 0.0; int B = 4334; // B25/100 value for thermistor NXRT15WF104FA1B040 // other stuff... int delayintvl = 20; int incomingByte; float vrefL = 3.3; float vrefH = 3.3; float vrefV = 3.3; bool one=true;   bool dispone=true; bool two=true;   bool disptwo=true; bool three=true; bool dispthree=true; bool four=true;  bool dispfour=true; int i,j; int num=100; float v1, v2, v3, v4, i1, i2, i3, i4; float il1, il2, il3, il4; void setup() {   // initialize serial communications at 115200 bps:   Serial.begin(115200);   // set analog resolution to 12 bits... (we want more than the 8 default bits...)   analogReadResolution(12);   // set up low/high range wakeup GPIO signals...   pinMode(LoHiEn1, OUTPUT); digitalWrite(LoHiEn1, HIGH);   pinMode(LoHiEn2, OUTPUT); digitalWrite(LoHiEn2, HIGH);   pinMode(LoHiEn3, OUTPUT); digitalWrite(LoHiEn3, HIGH);   pinMode(LoHiEn4, OUTPUT); digitalWrite(LoHiEn4, HIGH);   pinMode(WakeUp, OUTPUT); digitalWrite(WakeUp, HIGH); } void loop() {   // average voltages and currents...   v1=0; v2=0; v3=0; v4=0;   i1=0; i2=0; i3=0; i4=0;   il1=0; il2=0; il3=0; il4=0;   for (i=0; i<num; i++){     v1 = v1+ analogRead(Vrail_1)/4095.*vrefV;     i1 = i1+ analogRead(Hi_1)/4095.*vrefH/0.8*1000;     il1 = il1+ analogRead(Lo_1)/4095.*vrefH/0.05;     v2 = v2+ analogRead(Vrail_2)/4095.*vrefV;     i2 = i2+ analogRead(Hi_2)/4095.*vrefH/0.8*1000;     il2 = il2+ analogRead(Lo_2)/4095.*vrefH/0.05;     v3 = v3+ analogRead(Vrail_3)/4095.*vrefV;     i3 = i3+ analogRead(Hi_3)/4095.*vrefH/0.8*1000;     il3 = il3+ analogRead(Lo_3)/4095.*vrefH/0.05;     v4 = v4+ analogRead(Vrail_4)/4095.*vrefV;     i4 = i4+ analogRead(Hi_4)/4095.*vrefH/0.8*1000;     il4 = il4+ analogRead(Lo_4)/4095.*vrefH/0.05;   }   v1 = v1/num; v2 = v2/num; v3 = v3/num; v4 = v4/num;   i1 = i1/num; i2 = i2/num; i3 = i3/num; i4 = i4/num;   il1 = il1/num; il2 = il2/num; il3 = il3/num; il4 = il4/num;   // print the results to the serial monitor:   if (dispone) {   Serial.print(" RAIL1 (V)= ");  Serial.print(v1);  //Serial.print("\r\n");   if (!one) {Serial.print("    L1 (mA)= ");  Serial.print(il1, 1);}  //Serial.print("\r\n");   if (1==1) {Serial.print("    H1 (mA)= ");  Serial.print(i1, 1); }   Serial.print("\r\n");   }   if (disptwo) {   Serial.print(" RAIL2 (V)= ");  Serial.print(v2);  //Serial.print("\r\n");   if (!two) {Serial.print("    L2 (mA)= ");  Serial.print(il2, 1);}  //Serial.print("\r\n");   if (1==1) {Serial.print("    H2 (mA)= ");  Serial.print(i2, 1);}    Serial.print("\r\n");   }   if (dispthree) {   Serial.print(" RAIL3 (V)= ");  Serial.print(v3);  //Serial.print("\r\n");   if (!three) {Serial.print("    L3 (mA)= ");  Serial.print(il3, 1);}  //Serial.print("\r\n");   if (1==1) {Serial.print("    H3 (mA)= ");  Serial.print(i3, 1);}    Serial.print("\r\n");   }   if (dispfour) {   Serial.print(" RAIL4 (V)= ");  Serial.print(v4);  //Serial.print("\r\n");   if (!four) {Serial.print("    L4 (mA)= ");  Serial.print(il4, 1);}  //Serial.print("\r\n");   if (1==1) {Serial.print("    H4 (mA)= ");  Serial.print(i4, 1);}    Serial.print("\r\n");   }   Serial.print("\r\n");   Serial.print("\r\n");   while (Serial.available()) {  // while there are characters in the buffer, grab them all...     incomingByte = Serial.read();  // will not be -1     Serial.print("Incoming byte: "); Serial.print(incomingByte);     // Serial.print("    Delay interval:"); Serial.print(delayintvl);  Serial.print("\r\n");     if (incomingByte == 'h' || incomingByte == 'H'){       Serial.print("\r\n\r\nHelp:\r\n\r\n");       Serial.print("  +/= delay interval +/- 10mS\r\n");       Serial.print("  /- delay interval 20msec/1sec\r\n");       Serial.print("  l/L all rails low/high range in unison\r\n");       Serial.print("  q/w/e/r toggle display of rail 1/2/3/4\r\n");       Serial.print("  1/2/3/4 high range of rail 1/2/3/4\r\n");       Serial.print("  !/@/#/$ low range of rail 1/2/3/4\r\n");       Serial.print("  h print this help...\r\n");       Serial.print("\r\n");       delay(2000);       }     // change delay interval...     if (incomingByte == '+') delayintvl = delayintvl + 10;     if (incomingByte == '=') delayintvl = delayintvl - 10;     if (incomingByte == '_') delayintvl = 20;     if (incomingByte == '-') delayintvl = 1000;     if (delayintvl<1) delayintvl = 20;     // toggle low/high range of all rails in unison...     if (incomingByte == 'L') {       digitalWrite(LoHiEn1, LOW);       digitalWrite(LoHiEn2, LOW);       digitalWrite(LoHiEn3, LOW);       digitalWrite(LoHiEn4, LOW);       one = true; two = true; three = true; four = true;     }     if (incomingByte == 'l') {       digitalWrite(LoHiEn1, HIGH);       digitalWrite(LoHiEn2, HIGH);       digitalWrite(LoHiEn3, HIGH);       digitalWrite(LoHiEn4, HIGH);       one = false; two = false; three = false; four = false;     }     // still unimplemented, but for wakeup of target board...     if (incomingByte == 'w') digitalWrite(WakeUp, LOW);     if (incomingByte == 'W') digitalWrite(WakeUp, HIGH);     // toggle display of rail...     if (incomingByte == 'q') dispone = !dispone;     if (incomingByte == 'w') disptwo = !disptwo;     if (incomingByte == 'e') dispthree = !dispthree;     if (incomingByte == 'r') dispfour = !dispfour;     // change between high/low range..     if (incomingByte == '1') { digitalWrite(LoHiEn1, LOW);  one = true; }     if (incomingByte == '!') { digitalWrite(LoHiEn1, HIGH); one = false;}     if (incomingByte == '2') { digitalWrite(LoHiEn2, LOW);  two = true;}     if (incomingByte == '@') { digitalWrite(LoHiEn2, HIGH); two = false;}     if (incomingByte == '3') { digitalWrite(LoHiEn3, LOW);  three = true;}     if (incomingByte == '#') { digitalWrite(LoHiEn3, HIGH); three = false;}     if (incomingByte == '4') { digitalWrite(LoHiEn4, LOW);  four = true;}     if (incomingByte == '$') { digitalWrite(LoHiEn4, HIGH); four = false;}     }   // wait delayintvl mS after the last reading:   delay(delayintvl); }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Future Work and Improvements Work on a "smart" sensor with a local Kinetis device (KL02Z or KL05Z) on the sensor board itself that has three separate sense amplifiers (one run/high current and two low) has begun. There are several advantages to having a microcontroller on each sensor board: All instrumented rails can be measured simultaneously The sampling rate can be increase over current generation's round robin Measured data is sent over I2C or UART, allowing arbitrary number of rails to be instrumented Each sensor board can provide all its shunt and gain info Sensor board can be used in isolation, i.e., without a master profiler board A GUI interface for the serial data output by the profiler would be really nice... Addditional Information For more information on current measurements in general, see this tutorial series: A Current Sensing Tutorial--Part 1: Fundamentals | EE Times  A Current Sensing Tutorial-Part II: Devices | EE Times  A Current Sensing Tutorial--Part III: Accuracy | EE Times  A Current Sensing Tutorial-Part IV: Layout and Troubleshooting Guidelines | EE Times 
記事全体を表示
Qtopia Qt Extended, formerly known as Qtopia until September 30, 2008, is an application platform for Embedded Linux-based mobile computing devices such as personal digital assistants, mobile phones, and web pads. It is being developed by Qt Software, a subsidiary of Nokia. [Source: http://en.wikipedia.org] Qt Software discontinues Qt Extended March 3, 2009 — Oslo, Norway — Qt Software today announced that the product, Qt Extended, will be discontinued as a stand-alone product. Instead, selected features will be migrated into the Qt framework which will result in Qt becoming an even richer, cross-platform application framework. The final release of Qt Extended will be version 4.4.3, which will is planned for release on March 5, 2009. Qt Extended will be maintained for one year from that date. Qt Software will honor all existing support agreements, and for customers who need continued access to support beyond the term of their current agreement, Qt Software is offering the possibility of purchasing supplemental support. [Source: http://www.qtsoftware.com/about/news/qt-software-discontinues-qt-extended] Compiling Qtopia Crosscompiling Qtopia for i.MX processors requires some packages to be installed on host (PC). For more details click on your host PC Linux distribution below: All Boards Qtopia All Boards Qtopia on Ubuntu It's possible to compile Qtopia (version 2 or 4) by selecting Qtopia on package list or simply selecting Qtopia profile on Ltib configuration. Starting Qtopia Touchscreen setup When the system starts up, TSLIB_TSDEVICE environment variable must be set and ts_calibration application must be called to calibrate the touchscreen. $export TSLIB_TSDEVICE=/dev/input/event1 /dev/input/event1 is the usual touchscreen device. Some systems can address the touchscreen device to other names. It's possible to check what's the touchscreen device by typing: $cat /dev/input/<supposed device> After the command above, when touchscreen is pressed, some characters will be showed indicating that the <supposed device> device is the touchscreen device and it's working properly. $ts_calibrate Calibrate screen will appear. After touchscreen calibration, Qtopia can be executed by calling the following script: $/etc/rc.d/init.d/qtopia start Qtopia will be started.
記事全体を表示
Attached you can find a document that explains how to add Wi-Fi support in the iMX28evk using Yocto.
記事全体を表示
This is a HW design checklist for customer's reference. Please read and fill it in carefully before requesting a schematic/design review.
記事全体を表示
This tutorial teaches how to program bootloader on a SD Card using ATK. To program kernel and root file system to the SD card, please follow this i.MX35 PDK Linux Booting SD    ATK (Advanced Toolkit)       ATK (Advanced Toolkit) is a Windows software for programming the flash memory of i.MX boards. It can be downloaded here.     Using ATK       This section will describe the procedure to erase and program the bootloader in the SD Card.       1. Connect a serial cable between PC and i.MX board.       2. Set the switches:       Debug Board: SW9 -> 0         SW10 -> 0         Personality Board: SW1 and SW2 (All bits) -> 0     3. Run ATK going to Start -> Programs -> AdvancedToolKit -> AdvancedToolKit           Set the options:       i.MX CPU -> i.MX35_TO2       Device memory -> DDR2;       Communication Channel -> Serial Port (Usually COM1)     4. Click Flash Tools to erase, program, or dump the the memory and click GO     Erasing     1. To erase SD Card, select the parameters as below: Select MMC/SD as "Flash Model".     Select Erase on "Operation Type". 2. Turn on the board and press Erase.     3. ATK shows a message: "Flash erase successful!" when card is erased   Programming     Next, program the bootloader image into the memory card following the steps below:     1. Select the parameters: The bootloader binary image file can be found into your Board Support Package (click here to download) Select Program on "Operation Type".     Address: 0x00000000     File: "mx35_3stack_redboot_mmc.bin" (or similar name that indicates a MMC/SD image)     2. Press Program.     3. Close ATK, turn off the board and set switches to:     Debug Board: SW9 -> 0       SW10 -> 0 Personality Board: SW2 (Bits 1 and 2) -> 1       SW2 (All other bits) -> 0       SW1 (All bits) -> 0     4. Open Hyper Terminal, set it 115200,N,8 and see RedBoot Prompt.      
記事全体を表示