Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
初めてのMQXLiteアプリケーションの作成 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 投稿者:ルイス・ガラビト アプリケーションエンジニア TICS, メキシコ 新しい環境で初めてアプリケーションを開発するために費やす時間は、かなりのものになる可能性があります。環境がどのように機能するかを理解し、この環境のアプリケーションを生成できるようにする必要があります。 このアプリケーション・ノートの目的は、開発者がフリースケールMQXLite RTOSで初めてのアプリケーションの開発を迅速かつ容易に開始できるようにするための知識を提供することです。 このドキュメントでは、開発者が基本的なフリースケールMQXLiteアプリケーションを作成するために理解しておく必要のある基礎を提供します。 このアプリケーション・ノートは、 Kinetis KL2 USBマイクロコントローラ ・ファミリ、特にKL25Z128VLK4マイクロコントローラに基づいています。この例では、Freescale Freedom開発プラットフォーム・ボード(FRDM-KL25Z) も使用されます。 アプリケーションノートの全文は添付されています。
記事全体を表示
P2020-MSC8156AMCRD: P2020-MSC8156 AdvancedMC™ Reference Design Block Diagram Features Block Diagram Board Design Resources Block Diagram The NXP® P2020-MSC8156 AdvancedMC™ (AMC) reference design is a multi-standard baseband development platform for the next generation of wireless standards such as LTE, WiMAX, WCDMA and TD-SCDMA. This AMC platform integrates the QorIQ® P2020 processor with its MSC8156 DSP A P2020 and MSC8156 mezzanine card provide the system building blocks to enable rapid prototyping systems Ideal for developing solutions for the next generation of wireless standards Features Key P2020-MSC8156 AMC Reference Design Features: Single width, full height AMC form factor QorIQ ®  P2020 processor Dual e500v2 cores at 1.2 GHz 1 GB of DDR2 (SOCDIMM) TCP/IP acceleration eSDHC USB MSC8156 DSP Six SC3850 cores, built on StarCore ®  technology, at 1 GHz each Multi Accelerator Platform Engine for Baseband (MAPLE-B) Programmable Turbo and Viterbi decoder Two banks of 512 MB 64-bit DDR3-800 Block Diagram Board Design Resources Legacy Designs
記事全体を表示
INS-N1981 Wireless MCU Overview As the Smart Home starts to gather momentum, a number of competing Wireless Communication standards are fighting for dominance. With ZigBee® now becoming dominant in the low-power networking market, there is no surprise that two new low power technology Thread and Bluetooth® Low Energy with the new Mesh capability are both trying to enter this market to get a piece of the cake. Moreover competing IoT platforms from the Thread Group (Google/Nest), Allseen Alliance (Qualcomm), Apple's Homekit, the Open Interconnect Consortium (Intel) and many others are creating even more confusion. So in this confusing array of Wireless Communication standards and Iot platforms, what are the main features of each and what does it means for NXP? This session will provide an overview of these Wireless connectivity standards and IoT platforms, their capabilities, and their implication for NXP IoT. Watch Video Presentation As the Smart Home starts to gather momentum, a number of competing Wireless Communication standards are fighting for dominance. With ZigBee® now becoming dominant in the low-power networking market, there is no surprise that two new low power technology Thread and Bluetooth® Low Energy with the new Mesh capability are both trying to enter this market to get a piece of the cake. Moreover competing IoT platforms from the Thread Group (Google/Nest), Allseen Alliance (Qualcomm), Apple's Homekit, the Open Interconnect Consortium (Intel) and many others are creating even more confusion. So in this confusing array of Wireless Communication standards and Iot platforms, what are the main features of each and what does it means for NXP? This session will provide an overview of these Wireless connectivity standards and IoT platforms, their capabilities, and their implication for NXP IoT. Watch Video Presentation Insight & Innovation
記事全体を表示
LPCXpresso IDE - Latest Release : v8.2.2 To download installers for all platforms, please visit: http://www.nxp.com/lpcxpresso   For installation and migration hints and tips, please visit: Migrating to a new version of LPCXpresso IDE   Current release: LPCXpresso 8.2.2 (build 650) September 2016   Changes in this release include: Upgraded GNU tools to ARM launchpad GCC 5 update 2 Fixed issues with debugging FreeRTOS applications Fixed issue with startup code generated by the New Project Wizard for LPC177x_8x family Latest LP18xx/43xx LPCOpen packages included in Examples : https://community.nxp.com/community/lpc/blog/2016/09/02/lpc43xx-lpcopen-updates-are-here  New LPC8xx series "code bundles" added to Examples : LPC8xx family code example bundles  Previous releases: LPCXpresso 8.2.0 (build 647) July 2016   Changes in this release include: Upgraded GNU tools to ARM launchpad GCC 5 update 1 Updated supported C/C++ dialects in IDE preferences and wizards Fixed issue with optimization level of CM4/HardABI Redlib C library build Fixed issue with Redlib strncasecmp() function incorrectly matching for some input strings Corrected size of third RAM bank from 32KB to 16KB on LPC1820, LPC1810 and LPC18S10 Fixed issue causing some peripheral registers not to be displayed debugging LPC5411x MCUs Target CPU automatically selected if possible when debugging multicore MCUs, based on project's CPU settings New "Resume all" and "Pause all" buttons for multicore debug sessions Enabled disassembly view to show opcodes by making GDB alway return opcodes when CDT requests disassembly information. Fixed backtrace issue when debugging inside interrupt handlers Fixed issue with IDE failing to use selected GDB when debug launch configuration modified to use different executable Resolved Mac OS X specific issue with USB reenumeration which could cause a Linkserver crash Fixed issue where flash driver could start with incorrect XPSR and improved error reporting Added support for additional devices in SPIFI flash drivers Added SPIFI flash driver for use with LPC40xx family (see FAQ: LPC40xx SPIFI Flash Driver ) Updated LPC-Link2 CMSIS-DAP firmware to allow SWO Trace and power measurement to run at the same time. Also to provide an alternative firmware variant that provides higher priority for serial-VCOM data Fixed issue with SWO Trace which could trigger IDE crash if trace collected for long period of time Improved SWO Performance Counters view Fixed a Power measurement buffering issue which could result in upto 20 samples per 3k being overwritten with newer data.   LPCXpresso 8.1.4 (build 606) Mid March 2016   Changes in this release include: Fixed issue with some debugger writes to memory silently failing LPCXpresso 8.1.2 (build 603) March 2016   Changes in this release include: Fixed issue with IDE failing to boot debug Linkserver on certain non-English Windows variants Fixed issue triggering GDB to occasionally crash when debugging interrupt handlers Upgraded Eclipse to Mars SR2 (4.5.2) and CDT 8.8.1   LPCXpresso 8.1.0 (build 597) February 2016   Changes in this release include: Upgraded GNU tools to ARM launchpad GCC 5 Added support for LPC5411x devices Updated LPC-Link2 CMSIS-DAP firmware, providing probe serial number support and additional power measurement functionality Support for debugging via multiple LPC-Link2 probes concurrently using the latest CMSIS-DAP probe firmware All Cortex-M debug connections are now made via Redlink LinkServer Project wizard mechanism updated to add -fno-common compiler option and -print-memory-usage linker option to new projects IDE no longer compares Freemarker linker script with a linker script created by the pre-LPCXpresso IDE v7.90 linker script generator Makefile projects now correctly save MCU settings, including memory configuration and flash drivers (required for debugging) "Average Power" view added to compliment existing "Power Measurement Tool" view (for use with latest CMSIS-DAP firmware on LPCXpressoV3 boards) Fixed issue with GUI / command-line flash programmer when programming images with certain complex layouts Fixed issue when connecting in attach mode to LPC18xx/LPC43xx projects that use the Generic SPIFI flash driver Old SPIFI flash drivers for LPC18xx/LPC43xx removed and replaced by copies of the Generic SPIFI driver Documentation restructured, splitting the old User Guide up into several manuals Resolved issues with LPC-Link1 booting on Mac OS X 10.11 El Capitan.The use of Mac OS X 10.11.3 or later is recommended LPC-Link2 Redlink firmware is no longer provided or supported. Use the default CMSIS-DAP firmware instead "Red Trace" (SWO Trace via Red Probe+) is no longer supported. Use SWO Trace via LPC-Link2 instead   LPCXpresso 8.0.0 (build 526) November 2015   Changes in this release include: Upgraded Eclipse to Mars SR1 / CDT 8.8 (plus Java 1.8) Upgraded GNU tools to ARM launchpad GCC 4.9 update 3 Support for multiple flash drivers within a single project Generic SPIFI flash driver source project debug build fixed so that it will execute on parts with internal flash (and less RAM) SWO ITM Trace Console View added to provide printf support via ITM Stimulus Port 0 Fixed an issue triggering error dialogs when the "Terminate All" option was used for non-multicore debug sessions Updated Redlink server/CMSIS-DAP LPC-Link2 firmware to support ISP reset of target MCU (requires target hardware support) Restart button now enabled on Mac OS X by default Note: Restart workaround on Mac OS X (due to an issue with GDB) may leave an unknown "thread" in the debug view - hit terminate again to remove this. Last release to support LPC-Link2 Redlink firmware. Use the default CMSIS-DAP firmware instead Last release to support "Red Trace" (SWO Trace via Red Probe+). Use SWO Trace via LPC-Link2 instead   LPCXpresso 7.9.2 (build 493) September 2015   Changes in this release include: Various fixes and improvements for  Freemarker linker script templates: Fixed link templates for LPC29xx and LPC3xxx Added '__base...' symbols for each memory region Fixed reporting of template errors in headless builds Corrected base address of SRAM2 block for LPC1517/47 Fixed issue with multicore symbols being defined by the IDE for non-multicore parts in some circumstances Improved handling of debug termination to allow target to clean up Instruction trace and SWO trace updated to avoid conflicts when both are trying to use DWT comparators SCT code generation updated to support latest LPCOpen register names Fixed rare issue with creating activation serial number on Linux hosts The use of LPC-Link2 Redlink firmware is now deprecated, and support will be removed in a future LPCXpresso IDE release. Use the (now default) CMSIS-DAP firmware instead The use of "Red Trace" (SWO Trace via Red Probe+) is now deprecated, and support will be removed in a future LPCXpresso IDE release. Use SWO Trace via LPC-Link2 instead   LPCXpresso 7.9.0 (build 455) July 2015   Changes in this release include: Initial support for Windows 10 Upgraded GNU tools to ARM launchpad GCC 4.9 update 2 New Generic SPIFI flash driver mechanism, which will autoconfigure based on SPIFI device detected in target system Enhanced managed linker script template mechanism Known as Freemarker linker script templates Simplifies projects which relocate code from Flash to RAM Support for generating LPC MCU vector table checksums directly in the image, using the startup file and linker script "Active Config" is now the default for the indexer Fixes to Multicore projects Fixed data sections placement Slave image now has bss and noinit sections removed, as they are not required Fixed an issue that was preventing MTB trace with LPC82x parts Extended CMSIS-DAP JTAG support (for Cortex-M parts) to include Keil ULINK2/ULINK-ME probes   LPCXpresso 7.8.0 (build 426) June 2015   Changes in this release include: New SWO Interrupt Trace Graph and Table views (Pro Edition only) LPC-Link2 will now soft-boot with CMSIS-DAP rather than Redlink firmware by default Improved selection of JTAG vs SWD connections - requires launch configurations to be recreated Fixed an issue with flash programming occasionally failing to initialize or complete Fixed an issue with debugging of LPC11A parts through LPC-Link2 Fixed a problem with semihosting output for C++ projects Fixed an issue with reading and displaying unaligned data from the target Fixed an issue with making an attach-only debug connection Fixed an IDE hang if resuming a debug session mid-way through editing a peripheral register Performance improvements when displaying registers Optimized display of Peripherals when editing fields or registers It is now possible to add miscellaneous command-line options to the GUI flash programming dialog Fixed an issue with the reset target option not working when flash programming an AXF file Added path when disambiguating Launch Configurations Wizards now generate liblinks.xml 'smart update' file in library projects, which will still work after a project is renamed Code generated by LPCOpen project wizards now calls SystemCoreClockUpdate() in all cases, not just when linking to a board library For multicore-capable systems an LPCOpen project wizard-generated main.c now only calls Board_Init() for a master core and not for slaves. LPC43xx wizards now generate code using new-style multicore defines Fixed an issue with SymbolViewer not being able to display source for C++ symbols De-cluttered the toolbar by removing the duplicate quickstart toolbar (this can be re-enabled using the User Interface Enablement preferences)   LPCXpresso 7.7.2 (build 379) March 2015   Changes in this release include: Added support for LPC18Sxx and LPC43Sxx parts Upgraded Eclipse to Luna SR2 (4.4.2) and CDT 8.6 Added Technology Preview of SWO Trace support with LPC-Link2 (Redlink) Further major improvements to Flash Download performance Added "Terminate, Build and Debug" Quickstart button SPIFI flash drivers now check for recognised parts CMSIS-DAP support extended to allow multi-core and JTAG debug connections (where supported by probe implementation) Fixed issue with managed linker script for multi-core projects which caused misalignment of slave data section Added support for M4 multi-core projects to use HardABI floating point variant Redlib realloc() fixed to handle heap memory becoming exhausted The LPCXpresso54102 board Power measurement tool is now included   LPCXpresso 7.6.2 (build 326) February 2015   Changes in this release include: Fixed managed linker scripts for GCC 4.9 NewlibNano library names Stopped tracking project selection in Symbol Viewer Added toolbar button for hide/show Red Trace views. Note that a restart of LPCXpresso is required after showing these views before Red Trace can be used. Fixed problem with MCU settings not being saved if changed by using the Quickstart Panel's Edit project settings button Display target chip and core type alongside executable name in Debug View   LPCXpresso 7.6.0 (build 321) January 2015   Changes in this release include: Upgraded GNU tools to ARM launchpad GCC 4.9 Significantly improved flash programming performance across all Cortex-M targets and debug probes Support for additional SPIFI flash parts based on latest LPCSPIFI Library v1.03 Added new Symbol Viewer feature to display the symbols in an object/library/executable Redlink firmware enhanced to improve performance and provide bridging capabilities similar to latest CMSIS-DAP Managed linker scripts now contain start and end symbols for all data and bss sections Improved highlighting of changed registers when single stepping Change colors of stub console messages - dark yellow for warnings and green for information Added support for m0 small-multiplier Redlib now implements single precision fmodf() in math.h Redlib free() will now coalesce with any consecutive free blocks Fixed problem with assembler -D option when selecting No library headers Fixed issue with Memory Configuration Editor when merging memory blocks during import Fixed issue with semihosting SEEK operation (affecting Redlib and Newlib fseek()) always resetting to the start of the file Fixed linker script generation for Internal builder Fixed display of second core index for LPC5410x part (from 16->1) Fixed Build All Projects if no project selected Fixed target connection sequence to avoid timeout when downloading very large applications   LPCXpresso 7.5.0 (build 254) November 2014   Changes in this release include: Upgraded Eclipse to 4.4.1 ('Luna SR1') and CDT to v8.5.0. Upgraded GNU tools to ARM launchpad GCC 4.8 update 3. Added support for LPC5410x devices. Default optimisation level reverted to -O0 (rather than -Og) for Debug builds. LPC18/43 project wizards now provide access to Memory Configuration Editor. Add ability to Merge memory configurations and join contiguous memory blocks in Memory Configuration Editor. Enhanced link-time-optimisation (LTO) options. Disable "Set library type" on projects where it is not applicable. Added a default workspace location for Linux. Redlib string.h functions extended to include implementations of (non-ANSI-standard) strcasecmp() and strncasecmp(). Fixed very rare cause of hard fault in Redlib malloc(). Prevented changing Peripheral registers while target is running. Fixed a problem preventing debug display of arrays within a structure within a union. Fixed issue with viewing of byte-sized peripheral registers, such as CM3/CM4 NVIC priority registers. Fixed issue with writing to byte-sized variables/registers. LPCXpresso 7.4.0 (build 229) September 2014   Changes in this release include: Support for LPC82x family. Upgraded to latest Eclipse release (4.4 'Luna') and CDT 8.4. This fixes a number of display problems with complex datastructure variables. Several improvements have been made to the Opcode display in the disassembly view. Opcodes can be displayed by right-clicking in the disassembly view margin and selecting 'Show Opcodes'. Eclipse Luna requires Java 7, which is installed on all platforms in the 'jre' subdirectory. This is independent of the 'System' Java installation, which is not affected. Disabled inline editing of the Pre/Post build steps and forced editing via a dialog. Peripherals displayed in Memory View now display hexadecimal, decimal, and binary in hover for 'numeric' values. Tidied up the toolbar to remove little-used buttons (which are still available in the Quickstart panel). Added new preprocessor defines for multicore projects. LPCOpen Project wizards will now prepopulate the chip library name where possible. Cleaned up inconsistencies in various Redlib header files. Redlib memcpy and related functions now avoid use of unaligned LDR/STR instructions on Cortex-M3/M4. Fixed various single-precision Redlib math.h functions. Fixed a peripheral problem with LPC11U6x/11E6x GPIO word registers. LPCOpen code bundles are now shipped inside the Examples subdirectory, though users are recommended to check LPCware.com for the latest versions. Absolute rather than relative paths are now used in the debugger for breakpoints by default for new workspaces. The default make command is now 'make -r', which should reduce build times, particularly on Windows. Added new Quick Settings menu for changing a project's FP type. Fixed a flash programming issue for LPC15x7 parts. Fixed a flash programming issue for certain LPC21xx/22xx parts. Updated SPIFI flash drivers based on LPCOpen 'LPCSPIFI' library to use v0.07, adding drivers for more SPIFI devices Improved support for the 'Dark' Theme. Now possible to modify the start address of the heap without modifying linker scripts/templates Mac OS X 10.7 (Lion) is no longer an officially supported platform. LPCXpresso may continue to work on Mac OS X 10.7, but this can no longer be guaranteed. LPCXpresso is no longer tested on Mac OS X 10.7.   LPCXpresso 7.3.0 (build 186) July 2014   Changes in this release include: Upgraded GNU tools to ARM launchpad GCC 4.8 update 2 Run->Debug As... now works correctly for MCU targets Fix problem that caused CMSIS-DAP to not be available for some targets Correctly terminate Redlink Server after using the Flash Utility Updated LPC15xx startup code generated by new project wizards to match interrupt handler names used by LPCOpen. LPC43xx M0 startup code no longer references systick (which is only implemented on M4 cpu in LPC43xx MCUs, not M0 cpus). Fixed issue with LPC43xx (Cortex-M0 basic) wizards failing to create startup file. Quickstart Debug button now respects the build setting in the launch configuration Additional LPC18/43 SPIFI flash drivers supplied, based on LPCOpen lpcspifilib. C Library memory allocator no longer checks new heap end against current stack pointer. New "boot_link1" and "boot_link2" scripts available on all platforms for downloading probe firmware from command line. Peripheral rendering "Refresh" option now forces re-read from target. Peripheral register fix for LPC15xx GPIO port word pin registers.   LPCXpresso 7.2.0 (build 153) May 2014   Changes in this release include: Improvements to reliability of Redlink server connections Add __MULTICORE_type pre-processor symbol to compiler for multicore projects Project wizards now place default main() into projname.c rather than main.c On Mac OS X, prevent occasional hang during Debug Probe discovery On Windows, the debug drivers are now built with Visual Studio 2013 to increase compatibility with latest version of Windows. Remove crt_directory.xml to build parts database dynamically at runtime     LPCXpresso 7.1.1 (build 125) April 2014   This is a bug fix release that solves a problem found in the initial release of v7.1.0. Fixed in this release are: Fix problem affecting LPC-Link2 debug connections to Cortex-M0+ cores Fix regression preventing debugging with CMSIS-DAP Fix for a Red State UI regression which prevented users from graphically adding an output pin to a signal     LPCXpresso 7.1.0 (build 122) April 2014   Changes in this release include: Upgraded IDE to Kepler SR2 and CDT 8.3 Upgraded GNU tools to ARM launchpad GCC 4.8 update 1 Fixed problem with C/C++ indexer being disabled on startup Further reliability improvements with LPC-Link2 connections Default optimisation level is now -Og for Debug builds Improvements to Create Binary option to allow multiple commands (for example checksum the created binary) Improved NVIC/SCB peripheral displays Added preference to display peripheral registers with leading zeroes Added preference for the array "chunk" size in variable and expression views Fixed issue with instruction trace when restart carried out Redlib limits.h updated for when compiler configured to treat unspecified chars as signed (instead of default of unsigned) Redlib now implements integer only version of vprintf() as well as floating point compatible version The wrench overlay icon is now correctly displayed on a file/folder with local build settings Prevent a Redlink Server debug session on a target that is already being debugged Updated RAMFUNC definitions provided by cr_section_macros.h Note: Due to the imminent discontinuation of support by Microsoft, Windows XP is no longer an officially supported platform. LPCXpresso may continue to work on Windows XP but this can no longer be guaranteed. LPCXpresso is no longer tested on Windows XP.   LPCXpresso 7.0.2 (build 102) March 2014   Note - there is a know issue with the indexer in v7.0.2. This can be fixed by a simple change to a configuration file. For details see here.   Changes in this release include: Fixed problem with setting breakpoints on Windows with source paths containing spaces Fixed problem with Memory Configuration editor losing changes Debugging of LPC12xx and LPC11A02/LPC11A04 are now supported with LPC-Link2 mproved reliability of LPC-Link2 when downloading large images SCT code generator version updated to 2.6: switched from using register names that are undocumented on some parts, e.g. CAP_L[0] to CAP[0].L. Users should regenerate their SCT code Managed linker script support for placing specific functions into RAM Fixed display of memory if first displayed when target is executing   LPCXpresso 7.0.0 (build 92) February 2014   Major new release with features including: Support for latest NXP MCUs (including LPC1500) New release of the GNU compilers – v4.8.3. Includes new ‘general’ optimization level, -Og. This new optimization level, aims at providing fast compilation, a superior debugging experience and reasonable runtime performance. Adds Link Time Optimization (LTO). This allows all the different compilation units that make up a single executable to be optimized as a single module (not suitable for debugging). Inclusion of a new small-footprint variant of the Newlib C and C++ library, known as NewlibNano. Use of this library can result in significantly smaller code size, especially of C++ applications. Note that further details on the use of these new options can be found in the compiler documentation that is provided in the IDE help system.] New release of the base Eclipse IDE – Kepler (v4.3). The Managed Linker script mechanism has been extended to support the features of new GNU compiler. 'New project' wizards can now invoke import wizards directly to allow importing of library projects required in creating of new project. gdbserver debug connections enabled -> Enables use of Segger J-Link.   LPCXpresso 6.1.4 (build 194) January 2014 Changes in this release include: Added support for LPC11U6x. Fixed profile and interrupt trace on LPC13xx (12-bit ADC) parts Fixed regression introduced in 6.1.2 where a wizard-generated dual-core slave startup file failed to compile Removed display of CRP option in the wizard for creating dual-core slave apps Fixed various file resource leaks in the IDE; ensure temporary files are cleaned up on exit Fixed linker script generation for LPC1102/1104 Startup files fixed for various parts to prevent name mangling issues in C++ projects Corrected flash driver references for certain LPC11A, LPC11E, LPC11xxLV parts Redlink connections now display correct debug protocol in debug log In project wizards, LPCOpen wizards are listed first if available LPCOpen project wizards for LPC13xx, LPC175x_6x, LPC177x_8x, LPC407x_8x now provided LPCOpen packages can now be browsed from the Import Project page CGU related updates to LPC18/43 CMSIS driver libraries (Windows) Rebuilt version of make provided (Linux) Added new udev rules for CMSIS-DAP probes   LPCXpresso 6.1.2 (build 177) December 2013 Changes in this release include: Added support for LPC11x37H parts including support for IOHandler. Added LPCOpen V2 project wizards for LPC18 and LPC43 families Fixed issue where not all slaves were displayed in the linker properties of a MultiCore project Added missing breakpoint/watchpoint menu items while debugging in the Develop perspective Fixed issue where Watchpoints not trapping with Redlink Fixed issue where Hard fault not trapped / VectPC updated with Redlink Fixed issue with Cycle count registers broken on LPC43xx using an LPC-Link2 Fixed failure of LPC12 project wizards to set "__DISABLE_WATCHDOG" symbol On Windows 8, use the LPC-Link1 WinUSB driver instead of HID   LPCXpresso 6.1.0 (build 164) Late October 2013 Changes in this release include: Introduced Red Trace SWV support for Red Probe+ Fixed issue connecting to a third core when debugging LPC4370 Extended range of prebuilt LPC18/43 SPIFI flash drivers Fixed problem with Watchpoints not being cleared Corrected debug startup with Red Probe+ when more than one FTDI-based device is present Fixed possible null pointer exception after editing memory configuration Fixed lost highlight when using keyboard to scroll through MCU selection Windows) Updated dfu-util/libusb to support additional USB3 hubs   LPCXpresso 6.0.4 (build 159) Early October 2013 Changes in this release include: Added support for ULink-2 CMSIS-DAP interface Fixed display of C++ global variables in Expression view Prevents use of JTAG for CMSIS-DAP connections (it is not currently supported) Added missing launch shortcut preventing display of correct launch config in Run/Debug Settings dialog Stopped display of debug probes when deleting JTAG configuration Fixed display of multiple debug probes reported by Redlink Server "Quickstart->Build all" now works when no projects are selected Fixed problem with memory configurations not being stored correctly Fixed Redlib problem with free() of null pointer Added c++0x and gnu++0x C++ compiler dialect options   LPCXpresso 6.0.2 (build 151) September 2013 LPCXpresso Forum
記事全体を表示
无线充电让您摆脱电线的束缚! <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 如果您的智能手机、平板电脑或数字智能手表的电池可能会没电,或者您的床头柜或办公桌上的充电线可能缠绕不住您,那么无线充电器的简便性将使您的梦想成真!但无线充电器需要很多技术,而且并不是都一样。NXP 的发射器和接收器组件系列为 Qi 和 Rezence 标准提供解决方案。我们对这两者进行了研究,并提供了一些实用的硬件解决方案来切断这种联系。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 如果您的智能手机、平板电脑或数字智能手表的电池可能会没电,或者您的床头柜或办公桌上的充电线可能缠绕不住您,那么无线充电器的简便性将使您的梦想成真!但无线充电器需要很多技术,而且并不是都一样。NXP 的发射器和接收器组件系列为 Qi 和 Rezence 标准提供解决方案。我们对这两者进行了研究,并提供了一些实用的硬件解决方案来切断这种联系。
記事全体を表示
LPC177x_8x u-boot端口 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 该项目解释了如何使用 LPC177x_8x 设备为平台构建和部署 u-boot。要构建 u-boot,您需要运行 Linux 操作系统的系统、适用于 Linux 操作系统的最新 CodeSourcery GNU 工具、u-boot 源代码以及适用于 LPC1788 的 u-boot 补丁。 已实现的功能 -------------------------------------------------------------------------------- 支持带有 32 位 DRAM(32MB)的 EA1788 主板 支持EA1788板的NAND FLASH 支持LPC177x_8x内部FLASH 以太网支持 有限的 MPU 支持 u-boot 已知问题 -------------------------------------------------------------------------------- 问题:“重置”命令导致电路板崩溃 解决方法:改用“cmreset”命令 问题:“boot”命令导致主板崩溃 解决方法:使用环境变量和 go 命令编写脚本 问题:bootvx 命令导致主板崩溃 解决方法:无,但没有理由使用此命令 未实现的功能 -------------------------------------------------------------------------------- FLASH“保护”命令和功能未实现(易于实现) 未实现中断/NVIC 支持(易于实现) 可能的改进 -------------------------------------------------------------------------------- Systick 可以代替 LPC1788 匹配定时器 重定位代码已被“绕过”,并且未正确实施 针对设备特定 IRQ 的宏文件,即需要包含弱链接 在启动文件中(特定于架构的设备覆盖) 有一个基本的 MPU 驱动程序,似乎可以工作,但可以改进 以太网驱动程序和 PHY 设置是“特定于板的”,但可以移动 到驱动程序区域,可以使用通用 PHY 支持 u-boot 启动操作概述 -------------------------------------------------------------------------------- 以下是 u-boot 如何在 LPC1788 上启动的概述。 - LPC1788 启动 ROM 将控制权转移到内部 FLASH 中的 u-boot 代码 每个 CM3 启动过程的地址 0x0 - u-boot 代码首先设置 MPU - 引脚复用、时钟和 DRAM 均已初始化 - 代码和数据从 FLASH 迁移到 DRAM - DRAM 中的 BSS 段被清除 - 控制权转移到 DRAM 中的 u-boot 代码 - 调用 u-boot board_init_f() 进行初始 u-boot 设置 - board_init_r() 用于稍后的 u-boot 设置 - u-boot 在 DRAM 之外正常运行 移植文件的位置 -------------------------------------------------------------------------------- arch/arm/cpu/cortex-m3 - Cortex M3 特定文件(mpu、启动等) arch/arm/cpu/cortex-m3/lpc1788 - LPC1788 特定文件(计时器、串行等) arch/arm/include/asm/arch-cortex-m3 - Cortex M3 头文件 arch/arm/include/asm/arch-lpc17xx - LPC177x_8x 特定的头文件 board/nxp - 使用 NXP 设备的电路板专用区域 board/nxp/ea1788 - EA1788 板特定文件(设置、nand 等) include/configs/ea1788.h - EA1788 板特定配置文件
記事全体を表示
An Overview on QorIQ Trust Features for Securing Embedded Systems EUF-NET-T1742 - This session provides an overview on the security technologies NXP offers to secure a system through two complementary technologies: 1) the Trust Architecture already present in QorIQ P- and T-series including Secure Boot and 2) the TrustZone® technology introduced in the ARM®-based QorIQ LS series processors. We will outline the motivations for offering these technologies in embedded processors and show how they can be complementary for making a final system “Trustable” in the sense it does what its users and suppliers expect it to do. EUF-NET-T1742 - This session provides an overview on the security technologies NXP offers to secure a system through two complementary technologies: 1) the Trust Architecture already present in QorIQ P- and T-series including Secure Boot and 2) the TrustZone® technology introduced in the ARM®-based QorIQ LS series processors. We will outline the motivations for offering these technologies in embedded processors and show how they can be complementary for making a final system “Trustable” in the sense it does what its users and suppliers expect it to do.
記事全体を表示
FreeRTOS 与 MQX RTOS 的快速概述 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> FreeRTOS 与 MQX RTOS 的快速概述 MQX实时操作系统是专为单处理器、多处理器和分布式处理器嵌入式实时系统设计的。飞思卡尔半导体公司在其微处理器中采用了该软件平台。这包括 Kinetis、Coldfire、PowerPC、ARC、ARM、StrongARM、xscale CPU。MQX RTOS 的主要特点是可扩展的大小、面向组件的架构和易于使用。 FreeRTOS 是一种流行的嵌入式设备实时操作系统内核,已移植到 35 种架构。它在 GPL 下分发,但有一个可选例外。FreeRTOS 占用空间非常小,开销很低,执行速度非常快。内核本身仅由三或四个 C 文件组成。最少 4-8k 字节闪存。 类似功能:[待完成] 任务、事件、信号量、互斥量、消息队列、空闲省电                                                                  Freertos 的独特功能: 1 任务通知:每个 RTOS 任务都有一个 32 位通知值,该值在创建 RTOS 任务时初始化为零。RTOS 任务通知是直接发送给任务的事件,可以解除对接收任务的阻塞,并可选择更新接收任务的通知值。 2 递归互斥锁:递归使用的互斥锁可以被所有者反复“获取”。直到所有者为每次成功的 xSemaphoreTakeRecursive() 请求调用 xSemaphoreGiveRecursive() 之后,互斥锁才会再次可用。例如,如果某个任务成功“获取”同一个互斥锁 5 次,则该互斥锁将无法供任何其他任务使用,直到该任务也将互斥锁“归还”5 次为止。 3 堆栈溢出钩子/通知:每个任务维护自己的堆栈。任务堆栈使用的内存在任务创建时自动分配,并由传递给 xTaskCreate() API 函数的参数确定大小。堆栈溢出是导致应用程序不稳定的一个常见原因。因此,FreeRTOS 提供了两种可选机制,可用于协助检测和纠正此类事件 4 延迟中断处理:从应用程序中断服务程序中使用,将功能的执行延迟到 RTOS 守护进程任务。提供了一种机制,允许中断直接返回到随后将执行挂起功能的任务。这使得回调函数能够与中断连续执行 - 就像回调在中断本身中执行一样 5 多个对象上的阻塞:队列集是 FreeRTOS 的一项功能,它使 RTOS 任务能够在同时从多个队列和/或信号量接收时阻塞(挂起)。队列和信号量被分组为集合,然后,任务不再阻塞在单个队列或信号量上,而是阻塞在集合上。 MQX 的独特功能: 1 基于所有权的资源破坏:[待完成] 2 名称服务:任务可以将一个 32 位数字与一个字符串或符号名称关联起来。MQX RTOS 将这种关联存储在名称数据库中,该数据库中的所有任务 处理器可以使用。数据库避免使用全局变量。 3 处理器间通信:应用程序可以在多个处理器上同时运行,每个处理器上都有一个 MQX RTOS 的可执行映像。图像使用由内存或通过处理器间通信的通信链路传输的消息进行通信和协作。每个图像中的应用任务不必相同,而且实际上通常是不同的。 4 看门狗:看门狗是可选组件,可让用户检测任务级别的任务饥饿和死锁情况。 5 任务队列调度:您可以使用任务队列来显式调度任务,或创建更复杂的同步机制。由于任务队列提供的功能很少,因此速度很快。应用程序可以在创建任务队列时指定先进先出 (FIFO) 或循环 (Round Robin) 调度策略。
記事全体を表示
DAC PDB DMA Vybrid The attached project shows a configuration for the DAC and its functionality is explained in the below points: The PDB triggers the next DAC conversion. The DAC features an internal buffer (DAC_DATx) that contains that data to be converted. The DAC data to be converted is determined by  an internal pointer. This internal pointer increases or moves to the next element in the buffer on every PDB trigger The DAC uses the Data Buffer as normal mode. This means that the buffer works as a circular buffer. When the internal pointer reaches some point in the internal buffer, the DMA is triggered and it transfers the new data from an iRAM buffer to the DAC internal buffer. In this specific example the DMA treats the source as a circular buffer, because the source buffer size is 512 bytes but the destination (DAC_DATx) buffer is 8 bytes. The below figure represents the configuration of the example: The frequency of each output sample is determined by the source frequency of the PDB and the DACINT value. Sample_Output_Frequency =  Source_Frequency/ [(PDB_MULT * PDB_PRESCALER) * (DACINT + 1)] In the attached example the Bus Clock = 66MHz., PDB_MULT = 1 ,  PDB_PRESCALER = 128, DACINT = 63 For the 256 elements to convert the frequency of the output signal is 31.47Hz. (Sine Wave) VF6xx
記事全体を表示
Introducing eRPC This tutorial is introducing the eRPC (embedded remote procedure call) open-source project. The eRPC (Embedded Remote Procedure Call) is a Remote Procedure Call (RPC) system created by NXP. An RPC is a mechanism used to invoke a software routine on a remote system using a simple local function call. The remote system may be any CPU connected by an arbitrary communications channel: a server across a network, another CPU core in a multicore system, and so on. To the client, it is just like calling a function in a library built into the application. The only difference is any latency or unreliability introduced by the communications channel. Important links:  Everything related to the eRPC development is placed GitHub - eRPC base. The eRPC development is placed GitHub - eRPC development.  The eRPC releases are placed GitHub - eRPC Releases. The eRPC documentation is placed Github - eRPC wiki  The eRPC as Python Package on pypi  The eRPC is supporting multicore and multiprocessor types of applications.  Where to find eRPC examples Plenty of eRPC multicore and multiprocessor examples can be found in NXP MCUXpressoSDK packages. Visit https://mcuxpresso.nxp.com to configure, build and download these packages. To get the board list with multicore support (eRPC included) use filtering based on Middleware and search for 'multicore' string. Once the selected package with the multicore middleware is downloaded, see /boards/ /multicore_examples for eRPC multicore examples (RPMsg_Lite or Messaging Unit transports used) or /boards/ /multiprocessor_examples for eRPC multiprocessor examples (UART or SPI transports used). eRPC examples use the 'erpc_' name prefix. Another way of getting NXP MCUXpressoSDK eRPC multicore and multiprocessor examples is using the mcux-sdk Github repo. Follow the description how to use the West tool to clone and update the mcuxsdk repo in readme Overview section. Once done the armgcc eRPC examples can be found in mcuxsdk/examples/ /multicore_examples or in mcuxsdk/examples/ /multiprocessor_examples folders. You can use the evkmimxrt1170 as the board_name for instance. Similar to MCUXpressoSDK packages the eRPC examples use the 'erpc_' name prefix. Re: Introducing eRPC Hello Kunal, it seems your question is addressed here: Need Help-Step by Step procedure to implement eRPC in iMx6sx ? · Issue #5 · EmbeddedRPC/erpc-imx-demos · GitHub  Re: Introducing eRPC HI [email protected]‌, I don't know about official usage of eRPC on MPC5748G. Just the remind: eRPC depends on program language, OS, transport layer. There are not board specific files. So if there is used Freertos and C language you almost win, you need just port transport you want to use (if it is not already). Re: Introducing eRPC Hi Dusan,                    Has eRPC been ported to NXP MPC5748G ? Is there any example code I can reference? Best Regards, Alex Re: Introducing eRPC Hi [email protected], i didn't have big experience in this area. Recently we had to add some mutexes when multiple erpc calls were called from multiple taks. But i like your idea.  I quickly looked into source code. You need to specify your usecase. But i think it is imx Linux vs Mcore using RPSMG. In this case i think you can add mutexes as we did (which will serialize eRPC calls. you would need add them somewhere in performRequest function). The creating endpoints for each thread sounds good to me, but i see more issues which has to be solved. The smaller solution could looks like: transport init function will initialize more endpoints (based on number of tasks), eRPC rpmsg send/receive function on client side change to use unused undepoint to send and same endpoint for receive messages, eRPC rpmsg receive function on server need wait for message on all endpoints. I don't know if it is simple task or more complicated for you. But i am affraid that without modification to code you will be not able to have multithread calls. Re: Introducing eRPC Hi Dusan, I am working with Chandini here at Cubic. I just wanted to get extra info about eRPC when called from multiple threads. At the moment we are using a single end point and using this for one off calls that complete before making the next call. Now we'd potentially like to make multiple calls from multiple threads so we're wondering the best way to do this. In fact with my lack of knowledge here we've tried making other calls concurrently, well we didn't realise we were doing this until there was an issue. Now we see comms failure error codes coming back from the eRPC. Can a single end point be used for this i.e. should this be thread safe on the client side? If not should we use a separate end point for each thread, or should we be doing something else? Regards Lee Re: Introducing eRPC Hi [email protected]‌, Thank you to let us know. It is funny, i read about this today because of another project :smileygrin: Re: Introducing eRPC Hi Dusan, Thanks for the quick response. I could able to achieve better performance(response in microsec) in TCP by disabling the Nagel's algorithm using the below API call on both client and server socket connection. int result = setsockopt(sock,            /* socket affected */                         IPPROTO_TCP,     /* set option at TCP level */                         TCP_NODELAY,     /* name of option */                         (char *) &flag,  /* the cast is historical cruft */                         sizeof(int));    /* length of option value */ Reference : TCP_NODELAY: 2018 Best Practices for TCP Optimization | ExtraHop  Thanks, Sasidharan. Re: Introducing eRPC Hi [email protected]‌, Maybe you can ask guys on github (in same topic, or create new one). There are at least two guys who where doing something with TCP: github: GitHub - EmbeddedRPC/erpc: Embedded RPC  thread1:Server with TCP Transport handling multiple connections · Issue #32 · EmbeddedRPC/erpc · GitHub  thread2:TCP Example client / server code · Issue #39 · EmbeddedRPC/erpc · GitHub  Personaly i found this, but i don't know if this is your case and if it will help: linux - Low latency TCP settings on Ubuntu  Re: Introducing eRPC Hi Dusan, I want to port eRPC over TCP socket. I ran your example test code(test_arrays) over virtual serial(inside linux) and the response time taken for serial is less than 1ms. When I ran the same example code over TCP, the response time is taken for TCP is around 90ms. Is there a way to reduce the latency and increase the performance over TCP as like as serial? Thanks, Sasidharan. Re: Introducing eRPC Hi, Dusan. It helped. By the way it was mentioned in example in header file. The function call from A9 works fine and M4 returns data. But now the issue is when M4 calls function. The error is appears in A9 "Waiting MU transmit buffer empty timeout! ugh, imx_mu_rpmsg_send() failed: -5".  After this error data function call doesn't work in another side too: "rpmsg_multiept rpmsg0: virtqueue_add_outbuf failed: -5" What should I check? Thank you for your help. Re: Introducing eRPC Hi Vadim, Generally yes you need two tasks. One for client and one for server. Issue is also that output from erpc_arbitrated_client_init you have to put as a parameter to init server.  Re: Introducing eRPC Hi Dusan, Marek, community. I've made several applications with eRPC, M4(client)-A9(server) or M4(server)-A9(client) works fine, but I want to use client/server appl on each side. But now it doesn't work or function from one side only executes 1 time and appl hangs. I want to check the general structure of the code. What I do wrong? Should I use 2 separate FreeRTOS tasks for client and server on M4? M4 . . erpc_transport_t transport = erpc_transport_rpmsg_lite_rtos_remote_init(.....); erpc_mbf_t message_buffer_factory = erpc_mbf_rpmsg_init(transport); erpc_server_init(transport, message_buffer_factory); erpc_add_service_to_server(create_TEST_service()); erpc_arbitrated_client_init(transport, message_buffer_factory); while (true) { erpc_server_poll(); function1(....); } A9 . . erpc_transport_t transport = erpc_transport_rpmsg_linux_init(......); erpc_mbf_t message_buffer_factory = erpc_mbf_dynamic_init(); erpc_server_init(transport, message_buffer_factory); erpc_add_service_to_server(create_TEST_service()); erpc_arbitrated_client_init(transport, message_buffer_factory); while (true) { erpc_server_poll(); function2(....); } Re: Introducing eRPC Hi vadimfilippenko, if you are stilll interested in using python version you can look into this thread adding MPU patch to my kernel - I cannot see the new module · Issue #2 · EmbeddedRPC/erpc-imx-demos · GitHub . At least last two messages from mhanuel26 should be interesting for you because he was able to use python application. Re: Introducing eRPC Dusan, Marek, finally I successfully started modified eRPC example. But I use C on Linux side and erpc 1.5.0 with 6x parameters rpmsg init function in M4 (Dusan tips at github concerning 6th parameter). Thank you for help. Be ready for new questions) Re: Introducing eRPC You need to run M4 app befor the python app. Re: Introducing eRPC Hi Vadim, Please post here: ls /sys/class/rpmsg it looks like the nameservice was not sent from the M4 (is M4 running with the right firmware?). Because of this, a folder with dynamically announced channel from M4 was not created and therefore python cannot create rpmsg  transport... Please check your M4 core print-outs. Regards, Marek Re: Introducing eRPC Hi Vadim,  as you see in other comments, i am trying to answer as soon as possible. But this week (and maybe next) i am busy.  But from what i see in error you should compare init function in transport.py - class RpmsgTransport And here erpc-imx-demos/sysfs.py at master · EmbeddedRPC/erpc-imx-demos · GitHub   - class RpmsgEndpoint Be sure that GitHub - EmbeddedRPC/erpc-imx-demos: eRPC demos for i.MX devices  is up to date and and subrepos are checkout on commits as they are aligned with erpc-imx-demos. Maybe mareknovak‌ can help better here what is wrong.  Looks like  if self.id == -1: raise Exception() is returning -1 Re: Introducing eRPC Could anybody help me with follow ussue?: I'm using use eRPC demo example from erpc-imx-demos on iMX6COM board. Starting demo application on M4 side: "Hardware initialized eRPC intialized MatrixMultiply service added" adding driver in linux: "root@imx6sxea-com:~# modprobe -v rpmsg_multiept insmod /lib/modules/4.1.15-2.0.3+geb0b90b/kernel/drivers/rpmsg/rpmsg_multiept.ko" (Here are not any feedback from the system that rpmsg channel was created and rpmsg folder under sys/class/rpmsg is empty) Starting appl demo on linux: Traceback (most recent call last): File "example.py", line 111, in transport = erpc.transport.RpmsgTransport() File "build/bdist.linux-armv7l/egg/erpc/transport.py", line 199, in __init__ File "build/bdist.linux-armv7l/egg/rpmsg/sysfs.py", line 116, in __init__ Exception Exception TypeError: 'an integer is required' in > ignored P.S. I've built M4 eRPC demo appl. using cmake and also eclipse. M4 rpmsg demo appl works fine. Re: Introducing eRPC Hi Vakul, sorry i miss your comment. Currently we don't have any cryptographic transport supported. But because of eRPC is modular, i think you can easily add this feature to your eRPC project. Re: Introducing eRPC Hi Can eRPC communication be protected using some cryptographic transport (e.g. TLS)? Regards Vakul Re: Introducing eRPC Hi Evgeny, currently we have no estimation for that. But i think you can write/use your own allocator by writing your own implementation of erpc_malloc/erpc_free functions. Re: Introducing eRPC Hi Dusan, Are there plans to add more static memory allocation to additional parts, such as generated equivalents of erpcMatrixMultiply_shim? Where every input argument gets dynamically allocated before filling it up with data from the codec and then freed after the function invocation? Something like passing pre-allocated memory (statically by user app) to the framework? Thanks, Evgeny Re: Introducing eRPC Hi Evgeny, this looks like MCUExpresso project files/IDE issue. Top layer of folder names should be virtual directories, which will be not presented there in future. In your package on your disk should eRPC have similar directory structure as on github. Github directory structure is preferred.  Re: Introducing eRPC Hi Dusan, I see that the erpc uses a lot of dynamic memory allocation at run-time. Is there a plan to make it more embedded friendly and add a static memory allocation scheme? EDIT: I am sorry for the first question, i do see the erpc_setup_mbf_static.cpp in the repository. The thing is that i am basing  my code on the examples provided in the MCUXpresso SDK - frdmk66f_multiprocessor_examples_erpc_server_matrix_multiply_spi & frdmk66f_multiprocessor_examples_erpc_client_matrix_multiply_spi. Which have a very different directories structure from the code in the repository.  So my question is, again, should the SDK examples directories structure should be used or the repositories? ANd why are they so different? Thanks, Evgeny  Re: Introducing eRPC Hi Evgeny, first of all: Are you using smac.erpc from develop branch (and app built from that branch)? For me is this version working.  Right now version of erpcgen app and rest of eRPC code is connected. That means if you want use newer erpcgen app you built from github, you should and have to copy github erpc_c/* files from github into your example. After than you can regenerate code with newer erpcgen app, update application (erpc init + transport) functions and everything else should work. Otherwise if you will not update erpc_c files you have to use provided erpcgen app. Look at the bottom of this page: Getting Started · EmbeddedRPC/erpc Wiki · GitHub  Should be pretty up to date for newer erpcgen version. I am not sure but on newest commit spi could get changed so you can use older implementation instead. Re: Introducing eRPC Hey Dusan, When i use the erpcgen.exe that i built, i get the same error on the smac.erpc example: error: file smac.erpc:135:5: syntax error, unexpected identifier, expecting '}' The directory structure that i was referring to is the erpc_c from the repository and: From the SDK example. Which directory structure is the "right" one? Would it be safe to use the newly generated files (by me) with the SDK example code? Thanks, Evgeny Re: Introducing eRPC Hi evgenyerlihman‌, Prefered code is always on github on develop branch. Once this code will meet our requirements for new release we will merge it into master branch and we will provide also binaries of application. These updates on develop branch are more often than releases of Kinetis SDK. If some existing eRPC transport will not met version with transport used in Kinetis SDK you can compare old eRPC transport with newer one, or look on file changes in git repository. Re: Introducing eRPC Hey dusancervenka-b51352, Thank you for the quick reply! I cloned the dev branch. I see that the erpc_c directory structure is way different than the example provided with the Kinetis SDK. Which one is preferable? Thanks, Evgeny Re: Introducing eRPC Hi evgenyerlihman‌, Actually we are doing updates more frequently. You need switch to develop branch. GitHub - EmbeddedRPC/erpc at develop. Last code update was yesterday. But you need build erpcgen application there. With that smac IDL should works.  Re: Introducing eRPC Hi dusancervenka-b51352, I am considering using the erpc framework for a new product i am working on, that uses multiple nxp kinetis devices. I see that last updates to erpc github were made 6 months ago. My question is, is it still being maintained/fixed/developed? I tried the example from github: erpcgen.exe smac.erpc And it failed to generate the cpp source code with an error. The erpcgen executable is from the SDK for MCUXpresso. Thanks, Evgeny Re: Introducing eRPC Hi Chandini, It is ok. I was on long holiday too. I hope you enjoyed it well.  I sent you email through community messaging system (private message). We can discuss details through emails. Basically you ned create fork on github, checkout to develop branch, apply your changes, create commit, create pull request. We will review your changes, suggest changes and merge to develop branch. Re: Introducing eRPC Hi Dusan , Very sorry for late response , i was on long holiday . came back now . spoke with my everyone here .  could you please send me your email id so that we will forward stuff for you . according to our company we cant put anything directly to your github . Thank you Chandini  Re: Introducing eRPC Hi Dusan , Sure , i will talk to my seniors and create pull request  . currently i am on holiday .Sorry for the late reply. Thank you Chandini Re: Introducing eRPC Hi Chandini. We are glad you have succeeded. If i can have one special proposal for you, could you send pull request on develop branch on eRPC github with your newly created transport layer (on develop branch). Maybe there will be some work to get it working with newer eRPC. But if you not want updated it i can do that  With pull request on github you will be valuable contributor always seen in contributor's history. I hope eRPC will be good solution for you. And we are always here/ or on github for you Re: Introducing eRPC Hi dusancervenka-b51352 , b50844 , novakma7   Finally got it working , now demo working fine with my c++ code in Linux . Thanks a lot guys for answering all my questions. Special thanks to Dusan  Thank you Chandini Re: Introducing eRPC HI Dusan , As i was busy in some other task , Yesterday i could not try anything . today i will try and let you know . I think i have to change my functions little bit and need to try . because till now i was passing just char* to my send and receive functions. Come back to you soon. Thank you Chandini Re: Introducing eRPC Hi Chandini, yes that is correct. I was outside of company, so i didn't know exact names for functions. Is it working for you? Re: Introducing eRPC Hi Dusan Thank you for your reply : write(fd, message->getBuffer(), message->getUsed()😞 I can see getused function in  erpc/message_buffer.h at 9e18d069aeae19a6e80a5e8783903bc63bd9b567 · EmbeddedRPC/erpc · GitHub  but could not find getbuffer function. I think i have to use below function to get my buffer ? is that right ? /*! * @brief This function returns pointer to buffer to read/write. * * @return Pointer to buffer to read/write. */ uint8_t *get() { return m_buf; } so my functions becomes like this: send :erpc_status_t send(MessageBuffer *message) { write(fd, message->get, message->getUsed())};  Thank you chandini Re: Introducing eRPC Hi chanidi, well you need do it in diferent way 😕 You have to use transport.h. It will not work if you will not use that.  Maybe you can use ioctl commands as i mentioned above: erpc_status_t receive(MessageBuffer *message) {int fd = open("/dev/rpmsg_ept1024.1", O_RDWR);} send :erpc_status_t send(MessageBuffer *message) { write(fd, message->getBuffer(), message->getUsed())}; read: erpc_status_t receive(MessageBuffer *message){size_t size = read(fd, message->getBuffer(), 500); message->setUsed(size)}; novakma7 Can you confirm steps? Re: Introducing eRPC Dusan , Marek Ya i am referring those files as well , but i am using trasport.h to create my transport layer. but facing argument miss-match  problem send and receive functions in transport.h , take Messagebuffer as argument,          virtual erpc_status_t receive(MessageBuffer *message) = 0;          virtual erpc_status_t send(MessageBuffer *message) = 0; As per example.py i have created my RpmsgEndpoint class which need below arguments       RpmsgEndpoint::receive(int maxlen)       RpmsgEndpoint::send(char *buffer,int dst) As per my understanding, we are just need to read and write /dev/rpmsg_ept1024.1 device from Linux .   So i think instead of using transport.h , i think should i need to create my own transport.h version ,? Thank you guys Chandini Re: Introducing eRPC You are welcome. You can get inspirations in /erpc-imx-demos/middleware/erpc/transport/ folder. There is several transports. Re: Introducing eRPC Thanks a lot Dusan for quick reply , i will continue in the same path then and come back to u shortly .  Re: Introducing eRPC Hi Chandini. You are right. That are correct steps. You need create your class which is inheriting class from transport.h Re: Introducing eRPC Hi Marek I have question again . Currently my working status  : i got RpmsgEndpoint class in c++ I am working on how to make my client application working now. Python  example.py in erpc-imx-demos/MPU/example_erpc at master · EmbeddedRPC/erpc-imx-demos · GitHub  call  RpmsgTransport which inherited from Transport class. Question i have is , shall i use transport.h which is inside /erpc-imx-demos/middleware/erpc/erpc_c/infra  to make my application work. So that i can create my RpmsgTransport class and call it my client application . Am i thinking correctly ?  Thank you in advance Chandini Re: Introducing eRPC Yes, you are right. All the Python does are just IO operations on the files (read/write). This is doable in any language, including C/C++. Python was selected to show how it can be done due to its popularity in Linux user-space, but you can certainly port it to C. I think we are on the same wavelenght now, Good luck! Regards, Marek Re: Introducing eRPC Hi Marek Thank you for your reply , it cleared few of my doubts. We are not planning to use freeRTOS on both side. Our plan is   M4- FreeRTOS ----This we have it in your Demo A7-Linux -----Your Demo got python code , to make use of kernel RPMSG implemenation   All we need is instead of python either C or C++. I think  we can port  python code to C or C++ , easily right ? Thank you Chandini Re: Introducing eRPC Hi Chandini Indavara Basavaraju, RPMSg-Lite is implementation of RPMsg protocol and is intended only for the M4 side running FreeRTOS or baremetal. On the Linux/A7 side, you should be fine with the RPMsg implementation in kernel. (like here: GitHub - EmbeddedRPC/erpc-imx-demos: eRPC demos for i.MX devices  ) Or are you planning to run FreeRTOS on both M4 and A7 cores? In that case it would work, but this is not a standard use-case. It would require you to create a porting layer for the A core and to make FreeRTOS run there.  I hope this gives you some direction, Marek Re: Introducing eRPC Hi Marek Some how i have missed your message , sorry for that thanks a lot . i will try your new version soon. Could you please answer my last question regarding RPMSG transport layer ? Thank you  Chandini Re: Introducing eRPC Hi, i understand you.  You need create new one (and with pull request on github you can add it to our repository if you want). On Linux side you can use /dev/ttyRPMSG (if it is present in system).   for example create new transport here erpc_c/transports with: init can looks like:  int fd = open("/dev/ttyRPMSG", O_RDWR); send : write(fd, buffer, buffer_size); read: size_t size = read(fd, buffer, expected size); If there is no device named like this, you can be inspired from python code. RPMSG is not my cup of tea. I don't know how it should be used on Linux. I will forward your question to Marek. Re: Introducing eRPC Hi Dusan , Marek What i am planning : use rpmsg-lite on both M4(freertos) and A7(Linux) What i need: RPMSG C warrper (under erpc_c/setup) which can be use on both M4 and A7 side RPMSG Transport Layer (under erpc_c/transports) which can be use on both M4 and A7 side Questions i have: Could please tell me , Do you have any transport layer for that ?    or Do we need to refer rpmsg-python and write similar like that ?  Any suggestions will be so helpful Thank you guys Chandini Re: Introducing eRPC Hi, i am not sure if we have what you need (c transport for Linux side). But it should be easy to create new one. You can read and write from/to /dev/ttyRPMSG (if it is present in system). for example: init can looks like:  int fd = open("/dev/ttyRPMSG", O_RDWR); send : write(fd, buffer, buffer_size); read: size_t size = read(fd, buffer, expected size); mareknovak can brings more sun into this issue. Re: Introducing eRPC Hi Dusan , thank you for letting me know about update. I thiink now i am ok with erpc what i have shortly , once i got rpmsg Client application working then i can update erpc version as well. I was started looking rpmsg-lite , that got M4 platform files . i wonder do have anything for A7 platform ? or any information will be so helpful. my main aim is to get Client  Application using C with RPMSg as Transport layer Thank you Chandini Re: Introducing eRPC I am happy that you are progressing independently with your issue (for us it means it is not too much complicated for developers). Also mareknovak already updated his imx demo application inside the repository as he mentioned in few comments above. Your next step can be used that version because it is using new rpc features Re: Introducing eRPC Thank you for reply Dusan  that was the information i was looking for, i have created C wrapper for TCP  , after couple of fixes in erpc,  it works fine . My next step is to replace TCP layer with rpmsg . Thank you again Chandini Re: Introducing eRPC Hi Chandini Indavara Basavaraju, I have just updated the GitHub - EmbeddedRPC/erpc-imx-demos: eRPC demos for i.MX devices  repository to use eRPC 1.4.0 and RPMSg-Lite 1.1.0. You can download a pre-built erpcgen application, which is used for code generation here: Release v1.4 · EmbeddedRPC/erpc · GitHub  in the downloads section, just choose your architecture. Then you invoke it like this: ./erpcgen -gpy nameOfInterfaceDefinitionLanguageFile.erpc, this will generate Python serialization and deserialization shim code for you. If you omit -gpy or specify -gc, you will get C shim code. The ser/des shim code was also update in the latest commit in the erpc-imx-demos repository, so feel free to use it. Feel free to submit your changes in form of a pull-request, Regards and thank you for using eRPC & RPMsg-Lite! Marek Re: Introducing eRPC Hi, we don't have currently example on github repository. But we have C(c++) test there. If you are familiar with Linux or Mac you can use that as a example. Other options are as described above: 1. Download sdk for supported board -> multicore/multiprocessor c/python examples. 2. Read this article: Getting Started · EmbeddedRPC/erpc Wiki · GitHub  Re: Introducing eRPC Hi Dusan Could you please tell me , do u have any client application c example instead of python .? or Do you guys are planning to write one ?it will be so useful and helpful, if you have one already. Thank you in advance Chandini Re: Introducing eRPC Finally i got it working , thank a lot for you help   Dusan sorry i could not find attach option to attach my patch . so pasted below. From 7a5b152524a3c82b5bced4a72ed396f21860b666 Mon Sep 17 00:00:00 2001 Date: Mon, 8 May 2017 11:33:05 +0100 Subject: [PATCH] fix to run eRPC_demo --- erpc_c/infra/transport.h | 4 +- erpc_c/setup/erpc_server_setup.cpp | 36 ++++- erpc_c/setup/erpc_server_setup.h | 2 +- erpc_c/setup/erpc_setup_rpmsg_lite_rtos_remote.cpp | 54 +++++++ erpc_c/setup/erpc_transport_setup.h | 18 ++- erpc_c/transports/rpmsg_lite_rtos_transport.cpp | 158 ++++++++++++++++++ erpc_c/transports/rpmsg_lite_rtos_transport.h | 177 +++++++++++++++++++++ erpc_c/transports/rpmsg_rtos_transport.h | 147 +++++++++++++++++ erpc_python/erpc/transport.py | 21 +++ 9 files changed, 602 insertions(+), 15 deletions(-) create mode 100644 erpc_c/setup/erpc_setup_rpmsg_lite_rtos_remote.cpp create mode 100644 erpc_c/transports/rpmsg_lite_rtos_transport.cpp create mode 100644 erpc_c/transports/rpmsg_lite_rtos_transport.h create mode 100644 erpc_c/transports/rpmsg_rtos_transport.h diff --git a/erpc_c/infra/transport.h b/erpc_c/infra/transport.h index eb7ec71..fd4862a 100644 --- a/erpc_c/infra/transport.h +++ b/erpc_c/infra/transport.h @@ -48,7 +48,7 @@ //////////////////////////////////////////////////////////////////////////////// namespace erpc { - +class MessageBuffer; /*! * @brief Abstract interface for transport layer. * @@ -89,7 +89,7 @@ public: * * @return based on send implementation. */ - virtual erpc_status_t send(MessageBuffer *message) = 0; + virtual erpc_status_t send(const MessageBuffer *message) = 0; /*! * @brief Poll for an incoming message. diff --git a/erpc_c/setup/erpc_server_setup.cpp b/erpc_c/setup/erpc_server_setup.cpp index 51fa799..5cd4346 100644 --- a/erpc_c/setup/erpc_server_setup.cpp +++ b/erpc_c/setup/erpc_server_setup.cpp @@ -33,8 +33,10 @@ #include "basic_codec.h" #include "manually_constructed.h" #include "simple_server.h" -#include +#include "message_buffer.h" +#include "erpc_config_internal.h" #include +#include #if !(__embedded_cplusplus) using namespace std; @@ -43,6 +45,29 @@ using namespace std; using namespace erpc; //////////////////////////////////////////////////////////////////////////////// +// Classes +//////////////////////////////////////////////////////////////////////////////// + +class BasicMessageBufferFactory : public MessageBufferFactory +{ +public: + virtual MessageBuffer create() + { + uint8_t *buf = new (nothrow) uint8_t[ERPC_DEFAULT_BUFFER_SIZE]; + return MessageBuffer(buf, ERPC_DEFAULT_BUFFER_SIZE); + } + + virtual void dispose(MessageBuffer *buf) + { + assert(buf); + if (*buf) + { + delete[] buf->get(); + } + } +}; + +//////////////////////////////////////////////////////////////////////////////// // Variables //////////////////////////////////////////////////////////////////////////////// @@ -50,29 +75,32 @@ using namespace erpc; static ManuallyConstructed s_server; SimpleServer *g_server; +static ManuallyConstructed s_msgFactory; static ManuallyConstructed s_codecFactory; //////////////////////////////////////////////////////////////////////////////// // Code //////////////////////////////////////////////////////////////////////////////// -void erpc_server_init(erpc_transport_t transport, erpc_mbf_t message_buffer_factory) +void erpc_server_init(erpc_transport_t transport) { // Init factories. + s_msgFactory.construct(); s_codecFactory.construct(); // Init server with the provided transport. s_server.construct(); s_server->setTransport(reinterpret_cast (transport)); + s_server->setMessageBufferFactory(s_msgFactory); s_server->setCodecFactory(s_codecFactory); - s_server->setMessageBufferFactory(reinterpret_cast (message_buffer_factory)); g_server = s_server; } - void erpc_server_deinit() { + s_msgFactory.destroy(); s_codecFactory.destroy(); s_server.destroy(); + } void erpc_add_service_to_server(void *service) diff --git a/erpc_c/setup/erpc_server_setup.h b/erpc_c/setup/erpc_server_setup.h index 8e6a6ef..e4e9eaa 100644 --- a/erpc_c/setup/erpc_server_setup.h +++ b/erpc_c/setup/erpc_server_setup.h @@ -60,7 +60,7 @@ extern "C" { * * This function initializes server with all components necessary for running server. */ -void erpc_server_init(erpc_transport_t transport, erpc_mbf_t message_buffer_factory); +void erpc_server_init(erpc_transport_t transport); /*! * @brief This function de-initializes server. diff --git a/erpc_c/setup/erpc_setup_rpmsg_lite_rtos_remote.cpp b/erpc_c/setup/erpc_setup_rpmsg_lite_rtos_remote.cpp new file mode 100644 index 0000000..b480d42 --- /dev/null +++ b/erpc_c/setup/erpc_setup_rpmsg_lite_rtos_remote.cpp @@ -0,0 +1,54 @@ + /* + * Copyright (c) 2014-2016, Freescale Semiconductor, Inc. + * + * Redistribution and use in source and binary forms, with or without modification, + * are permitted provided that the following conditions are met: + * + * o Redistributions of source code must retain the above copyright notice, this list + * of conditions and the following disclaimer. + * + * o Redistributions in binary form must reproduce the above copyright notice, this + * list of conditions and the following disclaimer in the documentation and/or + * other materials provided with the distribution. + * + * o Neither the name of Freescale Semiconductor, Inc. nor the names of its + * contributors may be used to endorse or promote products derived from this + * software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR + * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include "manually_constructed.h" +#include "rpmsg_lite_rtos_transport.h" +#include "erpc_transport_setup.h" + +using namespace erpc; + +//////////////////////////////////////////////////////////////////////////////// +// Variables +//////////////////////////////////////////////////////////////////////////////// + +static ManuallyConstructed s_transport; + +//////////////////////////////////////////////////////////////////////////////// +// Code +//////////////////////////////////////////////////////////////////////////////// + +erpc_transport_t erpc_transport_rpmsg_lite_rtos_remote_init( + unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, void (*ready_cb)(void), bool send_nameservice) +{ + s_transport.construct(); + s_transport->init(src_addr, dst_addr, start_address, rpmsg_link_id, ready_cb, send_nameservice); + return reinterpret_cast (s_transport.get()); +} + + diff --git a/erpc_c/setup/erpc_transport_setup.h b/erpc_c/setup/erpc_transport_setup.h index 798d92f..6c3959e 100644 --- a/erpc_c/setup/erpc_transport_setup.h +++ b/erpc_c/setup/erpc_transport_setup.h @@ -34,6 +34,7 @@ #include "erpc_version.h" #include +#include /*! * @addtogroup transport_setup @@ -48,7 +49,7 @@ //! @brief Opaque transport object type. typedef struct ErpcTransport *erpc_transport_t; //! @brief Ready callback object type for RPMsg-Lite transport. -typedef void (*rpmsg_ready_cb)(void); +//typedef void (*rpmsg_ready_cb)(void); //////////////////////////////////////////////////////////////////////////////// // API @@ -106,21 +107,21 @@ erpc_transport_t erpc_transport_rpmsg_lite_master_init(unsigned long src_addr, /*! * @brief Create an RPMsg-Lite zero copy transport. */ -erpc_transport_t erpc_transport_rpmsg_lite_zc_master_init(unsigned long src_addr, - unsigned long dst_addr, - int rpmsg_link_id); +//erpc_transport_t erpc_transport_rpmsg_lite_zc_master_init(unsigned long src_addr, +// unsigned long dst_addr, +// int rpmsg_link_id); /*! * @brief Create an RPMsg-Lite transport. */ erpc_transport_t erpc_transport_rpmsg_lite_remote_init( - unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, rpmsg_ready_cb ready); + unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, void (*ready_cb)(void), bool send_nameservice); /*! * @brief Create an RPMsg-Lite zero copy transport. */ -erpc_transport_t erpc_transport_rpmsg_lite_zc_remote_init( - unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, rpmsg_ready_cb ready); +//erpc_transport_t erpc_transport_rpmsg_lite_zc_remote_init( +// unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, rpmsg_ready_cb ready); /*! * @brief Create an RPMsg-Lite RTOS transport. @@ -133,7 +134,8 @@ erpc_transport_t erpc_transport_rpmsg_lite_rtos_master_init(unsigned long src_ad * @brief Create an RPMsg-Lite RTOS transport. */ erpc_transport_t erpc_transport_rpmsg_lite_rtos_remote_init( - unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, rpmsg_ready_cb ready); + unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, void (*ready_cb)(void), bool send_nameservice); + //@} diff --git a/erpc_c/transports/rpmsg_lite_rtos_transport.cpp b/erpc_c/transports/rpmsg_lite_rtos_transport.cpp new file mode 100644 index 0000000..e04ae91 --- /dev/null +++ b/erpc_c/transports/rpmsg_lite_rtos_transport.cpp @@ -0,0 +1,158 @@ +/* + * Copyright (c) 2015, Freescale Semiconductor, Inc. + * + * Redistribution and use in source and binary forms, with or without modification, + * are permitted provided that the following conditions are met: + * + * o Redistributions of source code must retain the above copyright notice, this list + * of conditions and the following disclaimer. + * + * o Redistributions in binary form must reproduce the above copyright notice, this + * list of conditions and the following disclaimer in the documentation and/or + * other materials provided with the distribution. + * + * o Neither the name of Freescale Semiconductor, Inc. nor the names of its + * contributors may be used to endorse or promote products derived from this + * software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR + * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include "rpmsg_lite_rtos_transport.h" +#include + +#if !(__embedded_cplusplus) +using namespace std; +#endif + +using namespace erpc; + +//////////////////////////////////////////////////////////////////////////////// +// Variables +//////////////////////////////////////////////////////////////////////////////// +uint8_t RPMsgRTOSTransport::s_initialized = 0; +struct rpmsg_lite_instance *RPMsgRTOSTransport::s_rpmsg; + +//////////////////////////////////////////////////////////////////////////////// +// Code +//////////////////////////////////////////////////////////////////////////////// + +RPMsgRTOSTransport::RPMsgRTOSTransport() +: Transport() +, m_dst_addr(0) +{ +} + +RPMsgRTOSTransport::~RPMsgRTOSTransport() +{ + rpmsg_lite_deinit(s_rpmsg); + s_initialized = 0; +} + +erpc_status_t RPMsgRTOSTransport::init( + unsigned long src_addr, unsigned long dst_addr, void *base_address, unsigned long length, int rpmsg_link_id) +{ + if (!s_initialized) + { + s_rpmsg = rpmsg_lite_master_init(base_address, length, rpmsg_link_id, RL_NO_FLAGS); + s_initialized = 1; + } + + m_rpmsg_queue = rpmsg_queue_create(s_rpmsg); + m_rpmsg_ept = rpmsg_lite_create_ept(s_rpmsg, src_addr, rpmsg_queue_rx_cb, m_rpmsg_queue); + + m_dst_addr = dst_addr; + return m_rpmsg_ept == RL_NULL ? kErpcStatus_InitFailed : kErpcStatus_Success; +} + +erpc_status_t RPMsgRTOSTransport::init( + unsigned long src_addr, unsigned long dst_addr, void *base_address, int rpmsg_link_id, void (*ready_cb)(void), bool send_nameservice) +{ + if (!s_initialized) + { + s_rpmsg = rpmsg_lite_remote_init(base_address, rpmsg_link_id, RL_NO_FLAGS); + + /* Signal the other core we are ready */ + if (ready_cb != NULL) + { + ready_cb(); + } + + while (!rpmsg_lite_is_link_up(s_rpmsg)) + { + } + + s_initialized = 1; + } + + m_rpmsg_queue = rpmsg_queue_create(s_rpmsg); + m_rpmsg_ept = rpmsg_lite_create_ept(s_rpmsg, src_addr, rpmsg_queue_rx_cb, m_rpmsg_queue); + + if(send_nameservice) + { + rpmsg_ns_announce(s_rpmsg, m_rpmsg_ept, + "rpmsg-openamp-demo-channel", + 0); + } + + m_dst_addr = dst_addr; + return m_rpmsg_ept == RL_NULL ? kErpcStatus_InitFailed : kErpcStatus_Success; +} + +erpc_status_t RPMsgRTOSTransport::receive(MessageBuffer *message) +{ + int ret_val = rpmsg_queue_recv(s_rpmsg, m_rpmsg_queue, &m_dst_addr, (char *)message->get(), kRpmsgMessageBufferSize, + NULL, RL_BLOCK); + return ret_val != RL_SUCCESS ? kErpcStatus_ReceiveFailed : kErpcStatus_Success; +} + +erpc_status_t RPMsgRTOSTransport::send(const MessageBuffer *message) +{ + int ret_val = + rpmsg_lite_send(s_rpmsg, m_rpmsg_ept, m_dst_addr, (char *)message->get(), message->getUsed(), RL_BLOCK); + return ret_val != RL_SUCCESS ? kErpcStatus_SendFailed : kErpcStatus_Success; +} + +MessageBuffer RPMsgMessageBufferFactory::create() +{ + uint8_t idx = 0; + while (((m_freeBufferBitmap & idx) == 0) && (idx < kInitCountMessageBuffers)) + { + idx++; + } + + assert(idx < kInitCountMessageBuffers); + + m_freeBufferBitmap &= ~(1 << idx); + + uint8_t *buf; + buf = m_buffers[idx]; + + assert(NULL != buf); + return MessageBuffer(buf, kRpmsgMessageBufferSize); +} + +void RPMsgMessageBufferFactory::dispose(MessageBuffer *buf) +{ + assert(buf); + uint8_t *tmp = buf->get(); + + if (tmp) + { + uint8_t idx = 0; + while ((tmp != m_buffers[idx]) && (idx < kInitCountMessageBuffers)) + { + ++idx; + } + m_freeBufferBitmap |= 1 << idx; + } +} diff --git a/erpc_c/transports/rpmsg_lite_rtos_transport.h b/erpc_c/transports/rpmsg_lite_rtos_transport.h new file mode 100644 index 0000000..f1aec8a --- /dev/null +++ b/erpc_c/transports/rpmsg_lite_rtos_transport.h @@ -0,0 +1,177 @@ +/* + * Copyright (c) 2015-2016, Freescale Semiconductor, Inc. + * + * Redistribution and use in source and binary forms, with or without modification, + * are permitted provided that the following conditions are met: + * + * o Redistributions of source code must retain the above copyright notice, this list + * of conditions and the following disclaimer. + * + * o Redistributions in binary form must reproduce the above copyright notice, this + * list of conditions and the following disclaimer in the documentation and/or + * other materials provided with the distribution. + * + * o Neither the name of Freescale Semiconductor, Inc. nor the names of its + * contributors may be used to endorse or promote products derived from this + * software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR + * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#ifndef _EMBEDDED_RPC__RPMSG_LITE_RTOS_TRANSPORT_H_ +#define _EMBEDDED_RPC__RPMSG_LITE_RTOS_TRANSPORT_H_ + +#include "transport.h" +#include "message_buffer.h" +#include "rpmsg_lite.h" +#include "rpmsg_queue.h" +#include "rpmsg_ns.h" + +/*! + * @addtogroup rpmsg_lite_rtos_transport + * @{ + * @file + */ + +//////////////////////////////////////////////////////////////////////////////// +// Definitions +//////////////////////////////////////////////////////////////////////////////// + +enum +{ + kRpmsgMessageBufferSize = RPMSG_BUFFER_SIZE, + kInitCountMessageBuffers = 2, +}; + +//////////////////////////////////////////////////////////////////////////////// +// Classes +//////////////////////////////////////////////////////////////////////////////// + +namespace erpc +{ +/*! + * @brief Transport that uses RPMsg RTOS API for interprocessor messaging. + * + * @ingroup rpmsg_lite_rtos_transport + */ +class RPMsgRTOSTransport : public Transport +{ +public: + /*! + * @brief Constructor. + * + * This function initializes object attributes. + */ + RPMsgRTOSTransport(); + + /*! + * @brief RPMsgRTOSTransport destructor + */ + virtual ~RPMsgRTOSTransport(); + + /*! + * @brief This function call RPMsg rtos init function - as RPMsg master + * + * @Param[in] src_addr Source address. + * @Param[in] dst_addr Destination address. + * @Param[in] base_address RPMsg base address in the shared memory. + * @Param[in] length RPMsg shared memory region length. + * @Param[in] rpmsg_link_id Selection between what cores the communication will occur. + * + * @retval kErpcStatus_Success When rpmsg init function was executed successfully. + * @retval kErpcStatus_InitFailed When rpmsg init function wasn't executed successfully. + */ + virtual erpc_status_t init( + unsigned long src_addr, unsigned long dst_addr, void *base_address, unsigned long length, int rpmsg_link_id); + + /*! + * @brief This function call RPMsg rtos init function - as RPMsg remote + * + * @Param[in] src_addr Source address. + * @Param[in] dst_addr Destination address. + * @Param[in] base_address RPMsg base address in the shared memory. + * @Param[in] rpmsg_link_id Selection between what cores the communication will occur. + * @Param[in] ready_cb Callback called after RPMsg init is done and the core is ready. + * @Param[in] send_nameservice If true, RPMsg master notified by nameservice. + * + * @retval kErpcStatus_Success When rpmsg init function was executed successfully. + * @retval kErpcStatus_InitFailed When rpmsg init function wasn't executed successfully. + */ + virtual erpc_status_t init( + unsigned long src_addr, unsigned long dst_addr, void *base_address, int rpmsg_link_id, void (*ready_cb)(void), bool send_nameservice); + + /*! + * @brief Store incoming message to message buffer. + * + * In loop while no message come. + * + * @Param[in] message Message buffer, to which will be stored incoming message. + * + * @retval kErpcStatus_ReceiveFailed Failed to receive message buffer. + * @retval kErpcStatus_Success Successfully received all data. + */ + virtual erpc_status_t receive(MessageBuffer *message); + + /*! + * @brief Function to send prepared message. + * + * @Param[in] message Pass message buffer to send. + * + * @retval kErpcStatus_SendFailed Failed to send message buffer. + * @retval kErpcStatus_Success Successfully sent all data. + */ + virtual erpc_status_t send(const MessageBuffer *message); + +protected: + /* Remote device */ + struct remote_device *m_rdev; /*!< Device which represent the second core. */ + struct rpmsg_channel *m_app_rp_chnl; /*!< Represent connection between two device (two cores). */ + unsigned long m_dst_addr; /*!< Destination address used by rpmsg. */ + rpmsg_queue_handle m_rpmsg_queue; /*!< Handle of RPMsg queue. */ + struct rpmsg_lite_endpoint *m_rpmsg_ept; /*!< Pointer to RPMsg Lite Endpoint structure. */ + + static struct rpmsg_lite_instance *s_rpmsg; /*!< Pointer to instance of RPMSG lite. */ + static uint8_t s_initialized; /*!< Represent information if the rpmsg-lite was initialized. */ +}; + +class RPMsgMessageBufferFactory : public MessageBufferFactory +{ + uint8_t m_freeBufferBitmap; + uint8_t m_buffers[kInitCountMessageBuffers][kRpmsgMessageBufferSize]; + +public: + /*! + * @brief Constructor. + */ + RPMsgMessageBufferFactory() + : m_freeBufferBitmap(0xFF) + { + } + /*! + * @brief RPMsgMessageBufferFactory destructor + */ + virtual ~RPMsgMessageBufferFactory() {} + /*! + * @brief This function create message buffer used for communication between devices. + */ + virtual MessageBuffer create(); + /*! + * @brief This function dispose message buffer used for communication between devices. + */ + virtual void dispose(MessageBuffer *buf); +}; + +} // namespace erpc + +/*! @} */ + +#endif // _EMBEDDED_RPC__RPMSG_LITE_RTOS_TRANSPORT_H_ diff --git a/erpc_c/transports/rpmsg_rtos_transport.h b/erpc_c/transports/rpmsg_rtos_transport.h new file mode 100644 index 0000000..ad1d229 --- /dev/null +++ b/erpc_c/transports/rpmsg_rtos_transport.h @@ -0,0 +1,147 @@ +/* + * Copyright (c) 2015, Freescale Semiconductor, Inc. + * + * Redistribution and use in source and binary forms, with or without modification, + * are permitted provided that the following conditions are met: + * + * o Redistributions of source code must retain the above copyright notice, this list + * of conditions and the following disclaimer. + * + * o Redistributions in binary form must reproduce the above copyright notice, this + * list of conditions and the following disclaimer in the documentation and/or + * other materials provided with the distribution. + * + * o Neither the name of Freescale Semiconductor, Inc. nor the names of its + * contributors may be used to endorse or promote products derived from this + * software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR + * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#ifndef _EMBEDDED_RPC__RPMSG_RTOS_TRANSPORT_H_ +#define _EMBEDDED_RPC__RPMSG_RTOS_TRANSPORT_H_ + +#include "transport.h" +#include "message_buffer.h" + +extern "C" { +#include "rpmsg.h" +#include "rpmsg_rtos.h" +#include "rpmsg.h" +} + +/*! + * @addtogroup rpmsg_rtos_transport + * @{ + * @file + */ + +//////////////////////////////////////////////////////////////////////////////// +// Definitions +//////////////////////////////////////////////////////////////////////////////// + +enum +{ + kRpmsgMessageBufferSize = RPMSG_BUFFER_SIZE, +}; + +//////////////////////////////////////////////////////////////////////////////// +// Classes +//////////////////////////////////////////////////////////////////////////////// + +namespace erpc +{ +/*! + * @brief Transport that uses RPMsg RTOS API for interprocessor messaging. + * + * @ingroup rpmsg_rtos_transport + */ +class RPMsgRTOSTransport : public Transport +{ +public: + /*! + * @brief Constructor. + * + * This function initializes object attributes. + */ + RPMsgRTOSTransport(); + + /*! + * @brief RPMsgRTOSTransport destructor + */ + virtual ~RPMsgRTOSTransport(); + + /*! + * @brief This function call rpmsg rtos init function. + * + * @Param[in] dev_id Device id number. + * @Param[in] role Device role number. + * + * @retval kErpcStatus_Success When rpmsg init function was executed successfully. + * @retval kErpcStatus_InitFailed When rpmsg init function wasn't executed successfully. + */ + virtual erpc_status_t init(int dev_id, int role); + + /*! + * @brief Store incoming message to message buffer. + * + * In loop while no message come. + * + * @Param[in] message Message buffer, to which will be stored incoming message. + * + * @retval kErpcStatus_ReceiveFailed Failed to receive message buffer. + * @retval kErpcStatus_Success Successfully received all data. + */ + virtual erpc_status_t receive(MessageBuffer *message); + + /*! + * @brief Function to send prepared message. + * + * @Param[in] message Pass message buffer to send. + * + * @retval kErpcStatus_SendFailed Failed to send message buffer. + * @retval kErpcStatus_Success Successfully sent all data. + */ + virtual erpc_status_t send(const MessageBuffer *message); + +protected: + /* Remote device */ + static struct remote_device *m_rdev; /*!< Device which represent the second core. */ + static struct rpmsg_channel *m_app_rp_chnl; /*!< Represent connection between two device (two cores). */ +}; + +class RPMsgMessageBufferFactory : public MessageBufferFactory +{ +public: + /*! + * @brief Constructor. + */ + RPMsgMessageBufferFactory() {} + /*! + * @brief RPMsgMessageBufferFactory destructor + */ + virtual ~RPMsgMessageBufferFactory() {} + /*! + * @brief This function create message buffer used for communication between devices. + */ + virtual MessageBuffer create(); + /*! + * @brief This function dispose message buffer used for communication between devices. + */ + virtual void dispose(MessageBuffer *buf); +}; + +} // namespace erpc + +/*! @} */ + +#endif // _EMBEDDED_RPC__RPMSG_RTOS_TRANSPORT_H_ diff --git a/erpc_python/erpc/transport.py b/erpc_python/erpc/transport.py index 0765e9f..c335943 100644 --- a/erpc_python/erpc/transport.py +++ b/erpc_python/erpc/transport.py @@ -31,6 +31,8 @@ import struct import serial +from rpmsg.sysfs import RpmsgEndpoint +import time import socket import threading from .crc16 import crc16 @@ -107,6 +109,25 @@ class SerialTransport(FramedTransport): class ConnectionClosed(Exception): pass +class RpmsgTransport(Transport): + def __init__(self): + self.ept = RpmsgEndpoint( + RpmsgEndpoint.rpmsg_openamp_channel, + RpmsgEndpoint.LOCAL_DEFAULT_ADDRESS, + RpmsgEndpoint.Types.DATAGRAM) + + def send(self, message): + self.ept.send(message, RpmsgEndpoint.REMOTE_DEFAULT_ADDRESS) + + def receive(self): + while True: + ret = self.ept.recv(2048) + if len(ret[1]) != 0: + return ret[1] + else: + time.sleep(0.001) + return ret[1] + class TCPTransport(FramedTransport): def __init__(self, host, port, isServer): super(TCPTransport, self).__init__() -- 2.7.4 Re: Introducing eRPC Thank you Dusan . once i got my demo working , i will create pull request .. Thanks again for your reply , i got python files . i will run demo and come back to u shortly . Re: Introducing eRPC Hi, great work  If you want you can create pull request for imx demo repository to fix it. mareknovak can review it and merge it to the repository. To generate python code: As other application you can do in command line "erpcgen --help (-h should work too)". python -gpy idl_file -> gpy means generate python. Re: Introducing eRPC That's cool, i can continue to work in the same stable version until update .  with couples of fixes my MCU demo build and run properly now ..Thanks for your information Re: Introducing eRPC Hi Dusan I did fix and now i got MCU demo working properly ... Thanks for pointing out me a stable version .. Could you please tell me How to generate python code using erpcgen tool ..  ? Thank you Chandini Re: Introducing eRPC Hi, not sooner than tomorrow. But i can't promise that it will be tomorrow. My colleague mareknovak is not in work today. But it should be soon. Re: Introducing eRPC Could you please tell me , when are you going to update ?  Re: Introducing eRPC Hi thanks for you interest. Then it looks like the erpc generated files were generated with different erpcgen then on commit Marek provided (our mistake). Best solution looks like we need updated that demo with latests stable erpc and erpcgen version. You can try this from master branch GitHub - EmbeddedRPC/erpc: Embedded RPC (and there is erpcgen prebuilt 1.4.0). But i don't know how much changes you need to do. Or you can wait for our update. mareknovak Re: Introducing eRPC Hi Dusan I was using  same eRPC library one which u refereed  Steps i followed are below: Clone  erpc-imx-demos including sub module(which clone eRPC GitHub - MarekNovakNXP/erpc at 232afb209f0a0cfceb25a1be11879f7d1934e065  ) 1. git clone --recursive https://github.com/EmbeddedRPC/erpc-imx-demos.git 2. go to erpc-imx-demos/middleware/erpc folder and build erpcgen like this: installed required packages flex/bison and boost make eprc make eprcgen sudo make install successfully got erpcgen  3. Tried create my own output files using same erpc_matrix_multiply.erpc like this : erpcgen -I erpc-imx-demos/MCU/example_erpc/service -o test/erpc-imx-demos/MCU/example_erpc/service erpc_matrix_multiply.erpc successfully got below files: erpc_matrix_multiply.h erpc_matrix_multiply_server.cpp erpc_matrix_multiply_server.h erpc_matrix_multiply_client.cpp 4. Tried to build  MCU/example_erpc/build/armgcc/imx7d_sdb_m4/build_all.sh failed with error : /home/basavarajuc/test/erpc-imx-demos/MCU/example_erpc/service/erpc_matrix_multiply_server.cpp: In function 'void* create_MatrixMultiplyService_service()': /home/basavarajuc/test/erpc-imx-demos/MCU/example_erpc/service/erpc_matrix_multiply_server.cpp:168:56: error: invalid new-expression of abstract class type 'MatrixMultiplyService_service' return new (nothrow) MatrixMultiplyService_service(); Sorry for asking again , just to clarify my understanding . 1.if i am using eRPC library from GitHub - MarekNovakNXP/erpc at 232afb209f0a0cfceb25a1be11879f7d1934e065 then Do i need to update demo ? to run demo successfully  2. Could you please tell me  output files from erpc-imx-demos/MCU/example_erpc/service at master · EmbeddedRPC/erpc-imx-demos · GitHub  are generated by which erpcgen version ? So that i can use old erpcgen shortly to create my own files  Thanks a lot . and sorry for disturbance  Chandini   Re: Introducing eRPC Hi and thanks for your comment.  Example you mentioned is an older version than your erpcgen build. mareknovak also created his fork of official eRPC repository due to some minor changes which were not present in an official release at that time. If you click on eRPC reference from erpc-imx-demos repository from middleware folder, you will be redirect to his eRPC repository. You need build erpcgen from that version. We want update demo in the future.  Hope i helped you. If you have any concerns don't hesitate and ask us.  Re: Introducing eRPC Hi Sorry if i am asking basic question. I am trying to understand how to use erpcgen tool from NXP. I successfully ran example demo , with reference : https://github.com/EmbeddedRPC/erpc-imx-demos My next approach  was build erpcgen  and create my own output files using same erpc_matrix_multiply.erpc and run same demo again so i get familiar to use erpcgen tool. i got output files but even though i am using same erpc_matrix_multiply.erpc my files different than example files the changes are : Output files in example demo says (erpc_matrix_multiply_server.h): erpc_status_t erpcMatrixMultiply_shim(erpc::Codec * in, erpc::Codec * out, uint32_t sequence); my files(erpc_matrix_multiply_server.h): erpc_status_t erpcMatrixMultiply_shim(erpc::Codec * codec, uint32_t sequence); why files are different , Am i missing any config ? Do i need to manually edit erpc_matrix_multiply_server.h & erpc_matrix_multiply_server.cpp Thank you in advance Chandini
記事全体を表示
MCUXpresso IDE v11.8.1 现已推出 我们很高兴地宣布 MCUXpresso IDE v11.8.1(build 1197)现已推出。 这是一个基于之前的 MCUXpresso IDE v11.8.0 版本的维护版本,我们建议所有现有用户下载并安装这个新版本。   安装程序下载 要下载所有平台的安装程序,请登录我们的下载网站: https://www.nxp.com/mcuxpresso/ide/download   文档 更多信息可在更新后的用户指南及其他文档中查阅,这些文档可通过 IDE 的“帮助”菜单访问内置帮助系统,或以 PDF 格式从安装目录中获取。   未来版本的发布通知 如需接收有关未来版本发布的通知,请关注:MCUXpresso IDE - 发布历史   变更摘要 - 版本 11.8.1 - 2023 年 10 月 升级:更新的 SEGGER J-Link 软件 (v7.92l)。 已升级:更新的 PEmicro 插件(v5.7.3)。 新增:支持 i.MX RT1180 设备和 MIMXRT1180-EVK 板。 新增:支持 KE1xZ512 器件和 X-FRDM-KE17Z512 开发板。 新增:支持 MCXA153 设备和 FRDM-MCXA153 开发板。 改进:[工具链集成] 在支持的编译器方言列表中添加了 C++20 和 C++23 条目。 修复:[Debugger][RW61x] 当安全项目位于闪存中时,连接脚本在 SYSRESET 后不会暂停。 修复:[Flash Programmer] 与 Flash blank 命令相关的一些问题。 已修复:[SDK 集成] 更改设备包时,未考虑设备特定的预处理器定义。   已知问题 请参阅安装布局中的 KnownIssues.txt 文件以获取详细列表。  
記事全体を表示
调试 Flash 脚本覆盖“保护内部闪存区域”设置 您好, 我们目前正在测试FRDM-S32K344上从App1到App2的应用程序跳转。 我们的应用程序布局如下: 应用程序1起始地址: 0x00400000 应用程序2起始地址: 0x00500000 为了进行调试,我们使用了启用闪存保护的独立调试配置。 调试App1时,内存保护范围配置如下: 0x00500000 到 0x005FFFFF(用于保护 App2) 调试App2时,内存保护范围配置如下: 0x00400000 到 0x004FFFFF(用于保护 App1) 然而,在通过调试配置进行编程时,我们发现即使已经配置了内存保护范围,受保护的闪存区域仍然会被擦除。 请问有人能解释一下以下问题吗? Flash Programmer 在擦除/编程操作期间是否应遵守配置的内存保护范围? 是否需要进行任何额外的配置来防止受保护的闪存区域被擦除? 有没有人成功地使用内存保护功能,在 FRDM-S32K344 上只编写一个应用程序的同时,保留另一个应用程序? 日志文件和 LD 文件已附上,供您参考。 我们正在使用板上 PE 调试器 任何指导或建议都将不胜感激。 谢谢! Re: Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings 你好@Avinpat123 我在相同版本的 S32 Design Studio 中进行了快速测试,以确保它能够正常工作。我使用了相同的设置——一个应用程序被强制使用 0x40_0000 地址,而 0x50_0000 地址区域配置为保留;第二个应用程序被强制使用 0x50_0000 地址,而 0x40_0000 地址区域配置为保留: 以下日志显示此配置已被应用: 而且我可以看到内存中的内容确实被保留了下来,所以它运行正常。 我从你的截图中看到你配置了地址范围,但是“保留此范围”复选框没有启用。问题不就出在这里吗? 此致, Lukas Re: Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings 你好 @lukaszadrapa 谢谢回复,是的,正如您所说,复选框确实是问题所在,现在一切正常了。
記事全体を表示
chromium-ozone-waylandのコンパイル中にビルドが失敗しました こんにちは、 YoctoでIMX8MPボード用にchromium-ozone-waylandをコンパイルしようとしていますが、以下のエラーでコンパイルが失敗します: | デバッグ: Python 関数 extend_recipe_sysroot が完了しました | デバッグ: シェル関数 do_configure を実行中 | エラー //.gn:150:5: 代入が無効でした。 | build_dotfile_settings.exec_script_allowlist + | ^--------------------------------------------- ここで変数「exec_script_allowlist」を設定しましたが、以前は使用されていませんでした。 対象外です。 警告: シェルコマンドからの終了コードが 1 です。 エラー:タスク(/home/admin/Dharmik/IMX8M-Plus/sources/meta-browser/meta-chromium/recipes-browser/chromium/chromium-ozone-wayland_138.0.7204.157.bb:do_configure)終了コード「1」で失敗しました 注:タスクの概要:2814個のタスクが試行され、そのうち2800個は再実行の必要がなく、1個が失敗しました。 conf/local.conf に CORE_IMAGE_EXTRA_INSTALL += "chromium-ozone-wayland" を追加しました。 以下は私のヨクト設定です。 ビルド構成: BB_VERSION = "2.16.0" BUILD_SYS = 「x86_64-linux」 NATIVELSBSTRING = 「ユニバーサル」 TARGET_SYS = "aarch64-poky-linux" MACHINE = "imx8mp-lpddr4-evk" ディストリビューション = "fsl-imx-wayland" DISTRO_VERSION = 「6.18-whinlatter」 TUNE_FEATURES = "aarch64 armv8a crc crypto" ありがとうございます ダルミック Re: Build failed while compiling chromium-ozone-wayland 過去のChromiumバージョンでもこのエラーを見たことがあり、そのビルド状況で私の場合うまくいったのはこのファイルの変更でした。 \tmp\work\armv8a-mx8-poky-linux\chromium-ozone-wayland\117.0.5938.132\chromium-117.0.5938.132\media\gpu\sandbox\BUILD.gn if (current_cpu != "s390x" && current_cpu != "ppc64" && is_linux && ozone_platform_x11 && !is_castos) { # For DRI_DRIVER_DIR. configs += [ "//build/config/linux/dri" ] } このファイルの下部のプラットフォームリストに「&& ozone_platform_x11 」を追加したことで問題は解決しました。 Chromium v138がすでに追加されているか確認してもらえますかozone_platform_x11? よろしくお願いいたします。 ダイアナ Re: Build failed while compiling chromium-ozone-wayland PREFERRED_VERSION_gn-native = "0+git" の変更を追加した後、以下のエラーが発生します。 |DEBUG: Python関数extend_recipe_sysroot完了しました |DEBUG:シェル関数の実行do_configure |//build/config/linux/dri/BUILD.gn:11:20でのエラー:スクリプトがゼロでない終了コードを返しました。 |dri_driver_dir = exec_script(pkg_config_script, |^---------- |現在の編集名: /home/admin/Dharmik/IMX8M-Plus/build-imx8mp/tmp/work/armv8a-mx8mp-poky-linux/chromium-ozone-wayland/138.0.7204.157/sources/chromium-138.0.7204.157/out/Release/ |コマンド: python3 /home/admin/Dharmik/IMX8M-Plus/build-imx8mp/tmp/work/armv8a-mx8mp-poky-linux/chromium-ozone-wayland/138.0.7204.157/sources/chromium-138.0.7204.157/build/config/linux/pkg-config.py --dridriverdir dri |1枚返品して印刷しました: | |pkg-configからのエラーです。 | |スタール: | |pkg-configの検索パスにはdriパッケージが見つかりませんでした。 |おそらく「dri.pc」を含むディレクトリを追加したほうがいいかもしれません |PKG_CONFIG_PATH環境変数に |パッケージの「ドリ」は見つかりませんでした | |//media/gpu/sandbox/BUILD.gn:31:18:を参照し、これがファイルが含まれた原因となりました。 |configs += [ "//build/config/linux/dri" ] |^------------------------- |警告:シェルコマンドからコード1を終了してください。 ありがとうございます ダルミック Re: Build failed while compiling chromium-ozone-wayland こんにちは、ダルミックさん。 local.confにchromiumパッケージ以外にもう一つ追加してみてはどうでしょうか? PREFERRED_VERSION_gn-native = "0+git" 問題が解決しない場合はお知らせください。 よろしくお願いいたします。 ダイアナ
記事全体を表示
S32DS | S32k144 RTD DIO 引脚项目错误 你好 我正在尝试在装有 S32DS 3.6.7 的 S32K144 LQFP100 上使用 RTD AUTOSAR (MCAL) 设置一个基本的 LED 闪烁示例。我在 Pins 工具(.mex 文件)中将 PTC11 配置为 GPIO 输出,并在外围设备/MCAL 视图中添加了 Dio 和端口组件。 但是,当我点击 "更新代码 "时,代码生成失败,并出现以下错误: - [CODEGEN] 生成文件 'Port_Ci_Port_Ip_PBcfg.c' 失败 - TypeError:PinMode.match 不是函数 at GetPDO_IP (:187) - [CODEGEN] 生成文件 'Port_PBcfg.c' 失败 在 GetPDO(port_utils.js:235) 我的设置: -主板:S32K144 LQFP100 -S32DS 版本:3.6.7 -RTD/PlatformSDK_S32K1_S32M24 -引脚:PTC11 配置为 portC: port_11、输出、GPIO-添加了 MCAL 元器件:Dio + 端口(均在 AUTOSAR 模式下) 在端口 MCAL 配置中,PortPin_0 的 "PortPin Direction(端口引脚方向)"和 "PortPin Mode(端口引脚模式)"字段显示为灰色,并显示数值 (0) 而不是字符串。我怀疑代码生成器期望引脚模式的字符串值是 "ALT1",但收到的却是一个数字。 有人遇到过这个问题吗?PortPin 配置是否应该完全由 .mex 自动生成?还是需要手动配置?如能得到任何指导,将不胜感激。 此外,由于我是 RTD AUTOSAR 的新手,我想知道是否有从头开始学习堆栈的推荐资源 - 教程、示例项目、视频或学习 MCAL 模块(端口、Dio、Adc、Pwm、Can...)的任何建议顺序。我有裸机嵌入式 C 语言的经验,但对 AUTOSAR 却一无所知。 如能得到任何指导,将不胜感激。 谢谢! Re: S32DS | S32k144 RTD DIO PIN PROJECT ERROR 我还在努力。我从驱动程序中删除了端口库,但仍然无法正常工作。 PortPinMode 设置为 0,而在你发给我的示例和代码中,它被设置为 GPIO。我不知道如何改变这种状况。 我对工作流程也有些困惑。据我所知 首先,在针脚选择器工具中选择针脚。 然后,在端口模块中配置引脚(底层配置)。 最后,按照 AUTOSAR 原则,使用 DIO 作为封装器/接口,这样应用程序就不会直接依赖于微控制器。 Re: S32DS | S32k144 RTD DIO PIN PROJECT ERROR 你好@antonio_esal 在打开你创建的示例程序时,我确实发现了一些错误。随函附上我创建的示例程序供你参考。 在您的项目中,无需同时在 MCAL 和 Drivers 中添加"Port" 模块。 Re: S32DS | S32k144 RTD DIO PIN PROJECT ERROR 是的,我正在这样做,演示示例运行得很好,但当我尝试从一个新项目中做同样的事情时,我做不到。 Re: S32DS | S32k144 RTD DIO PIN PROJECT ERROR 你好@antonio_esal 您可以参考 RTD 驱动程序包中包含的示例代码开始学习。
記事全体を表示
[S32DS 3.6.7]S32K1xx RTD 3.0.0创建新项目时未检测到 大家好 我在使用 S32 Design Studio 3.6.7 和 S32K1xx RTD Drivers 3.0.0 版本时遇到了问题。 当前设置: S32 Design Studio 版本:3.6.7 设备:S32K1xx 系列 RTD 驱动程序版本: 3.0.0 操作系统:Windows 11 创建新项目时,SDK 选项中未显示 RTD。 是否有人遇到过同样的问题或找到了解决方案? 非常感谢你们的支持。 安东尼奥 Re: [S32DS 3.6.7] S32K1xx RTD 3.0.0 not detected when creating new project 你好,胡利安、 你是对的,问题在于 S32DS 附带了 GCC 11。我安装了 GCC 10.2,现在一切正常。 感谢您的帮助。 Re: [S32DS 3.6.7] S32K1xx RTD 3.0.0 not detected when creating new project 你好,@antonio_esal、 安装 RTD 软件包时,您是否确定安装了正确的恩智浦 GCC 版本?开箱即用,S32DS 3.6.0及以上版本配备 NXP GCC 11.4,但 S32K1 RTD 3.0.0已使用恩智浦GCC 10.2构建和测试(如版本说明中所述): 创建新的 S32DS 应用程序时,请确保选择了正确的工具链: 如果这不是问题的根本原因,请共享您的安装详细信息(Help> Installation Details),以便我确认是否已安装 S32K1 RTD 的所有必要依赖项。 致以最诚挚的问候, Julián
記事全体を表示
s32k344 罐 你好,我正在使用 s32k344 电机驱动器代码,并有几个原型。我发现其中一台 CAN 机器在运行一段时间后会脱机,发送和接收都会出现异常。我打开了离线回复,发现信息会丢失 200 毫秒的帧。我更换了 CAN 收发器,但同样的现象依然存在。我已经阅读了勘误手册,是否是芯片本身存在这个错误? Re: s32k344 can Hi@qicbeng 示例代码"MCSPTE1AK344_PMSM_FOC_2Sh_ll" 不提供 FLEXCAN 功能;您必须自行添加 CAN 相关功能。 请提供您的 CAN 测试项目,以便我检查您的配置是否正确。
記事全体を表示
FRDM-MCXN947:Ee(42) 刷新 tflm_modelrunner 后无法连接到内核 刷新 tflm_modelrunner SDK 示例(FreeRTOS + lwIP,定义 USE_RTOS)后,我的 FRDM-MCXN947 不再响应 SWD。LinkServer v25.6 和 MCU-Link V3.128 报告 Ee(42)。所有操作(包括大量擦除)都无法连接到核心。在 “设备管理器” 中可以正确检测到 MCU-Link 探测器。按下 SW3+RESET 时,Windows 会检测到 USB 枚举,但未安装驱动程序,blhost 报告未找到任何设备。 我怎样才能找回板? 更新:我能够在 Linux 上下载 led_blinky 示例,但在 Windows 10 上问题依然存在。 此外,在这两个操作系统上,我通常会收到以下警告: " 项目是为设备 MCXN947 配置的,但选定的探测器报告已连接到设备 MCXN947VDFT。你确定要继续吗?" 第一次尝试下载程序时(不知道是否与此有关)。 Re: FRDM-MCXN947: Ee(42) Could not connect to core after flashing tflm_modelrunner 最新情况--决议 通过从 Windows 设备管理器中卸载 MCU-Link 设备条目并允许 Windows 在重新连接时重新枚举这些条目,该问题得到了解决。 具体而言,删除了两个条目:通用串行总线设备下的 " MCU-LINK FRDM-MCXN947 CMSIS-DAP ",以及端口 (COM & LPT) 下相应的 MCU-Link vCom 端口。重新连接 USB 电缆后,Windows 自动重新安装了这两个驱动程序,LinkServer 可以正确打开探针。 根本原因似乎是Windows中USB设备状态损坏,很可能是在之前使用tflm_modelrunner固件(FreeRTOS + LwIP)的会话中触发的。该探针在系统中可见并被正确枚举,但其句柄无法被 redlinkserv.exe 打开,导致在所有操作(包括大量擦除、闪存和 gdbserver)中出现 Ee(42)。重新安装集成开发环境,替换 redlinkserv.exe、清除 USB 注册表项也无法解决这个问题。只有从设备管理器重新枚举设备才能解决问题。
記事全体を表示
Fuse Read and Write tool in Linux Userspace for i.MX 9 series Introduction. OEMs need to access fuse values during functional tests and product manufacturing as well, they will fix Ethernet MAC addresses, fix boot mode, enable secure boot and more, There is a tool that is enabled across all i.MX processors, it runs in U-boot and is the command '=> fuse ', some customers are required to write and read fuses in Linux Userspace and this is where different processors have different OTP structures. In this article, you will download a C-written file, using NXP BSP enabled functions to access processor's fuses. i.MX 9 Series manages fuses through EdgeLock Secure Enclave (ELE), which would make this tool easy to adapt for other processors, this release is focused on i.MX91 and i.MX93. 1. Hardware Setup. FRDM-i.MX91. Power supply connected to P1, USB type-C debug cable to P16 Ethernet cable connected to network router and P4, for source code copying. SD/eMMC flashed with Yocto Linux Factory LF_6.12.49, if needed, you can flash it with USB type-C host cable to J31.   2. Documentation Setup. Download reference manual from i.MX 91 Documentation. It contains the attachment i.MX91_Fusemap.xlsx   3. Software Setup. Download and build process. user@host:~$ scp fuse_test.c root@ :~ root@imx91evk:~# gcc -Wall fuse_test.c -o fuse_test Tool features. Uses NXP BSP pread and pwrite functions. Based on Bank * 8 + Word formula, if you are using fusemap attachment, Word would be defined as Word % 8. Defines minimum and maximum bank and word indexes according to i.MX93/i.MX91 fusemap. Requires customer to specifically input 4 arguments: fuse_test read|write . 4. Demonstration. Read Device Unique ID [31:0] from fuses. a. Stop at U-boot for UID fuse reference value. u-boot=> fuse read 1 7 Reading bank 1: Word 0x00000007: 03fc7ef1 u-boot=> boot b. Run tool for read operation. root@imx91evk:~# ./fuse_test read 1 7 ret: 0 fd : 3 READ Bank: 1, Word: 7, Offset: 15 SUCCESS: pread operation resp_len = 4 resp_buf[0] = |f1| resp_buf[1] = |7e| resp_buf[2] = |fc| resp_buf[3] = |3| c. Run tool for write operation. This article explores a simple writing to OEM General Purpose Fuse 2 GPR2_CFG0, located in bank 47; word 376. root@imx91evk:~# ./fuse_test read 47 0 ret: 0 fd : 3 READ Bank: 47, Word: 0, Offset: 376 SUCCESS: pread operation resp_len = 4 resp_buf[0] = |0| resp_buf[1] = |0| resp_buf[2] = |0| resp_buf[3] = |0| This fuse is protected by General Purpose 2 Fuse Lock GPR2_LOCK [2:0] in Packed_FuseIndex 291. Calculate word bits from AN14954 section 3.2 Devices with ELE-AP. root@imx91evk:~# ./fuse_test read 1 1 ret: 0 fd : 3 READ Bank: 1, Word: 1, Offset: 9 SUCCESS: pread operation resp_len = 4 resp_buf[0] = |93| resp_buf[1] = |34| resp_buf[2] = |0| resp_buf[3] = |0| This way, GPR2_LOCK [2:0] = 010, it means that it's in Over-ride Protect and you can burn the fuse. root@imx91evk:~# ./fuse_test write 47 0 ret: 0 fd : 3 READ Bank: 47, Word: 0, Offset: 376 SUCCESS: pread operation resp_len = 4 resp_buf[0] = |5| resp_buf[1] = |0| resp_buf[2] = |0| resp_buf[3] = |0| INFO: Fuse previous valueWRITE Bank: 47, Word: 0, Offset: 376 Enter fuse value (e.g. 0xAA1234BB): 0x4A4F5345 You entered: 0x4A4F5345 (1246712645 decimal) SUCCESS: pwrite operation INFO: Please reset the device for fuse read confirmation 0x4A 0x4F 0x53 0x45 are the uppercase 4 first letters of Joseph. u-boot=> fuse read 47 0 Reading bank 47: Word 0x00000000: 4a4f5345 Conclusion. This tool is capable of reading and burning fuses from i.MX 93 and i.MX 91, it's scalable to i.MX 9 series. iMX95 Latest ELE firmware release, does not support programming SRK values from user space. Required runtime firmware enabling this functionality is planned for next release. This tool is provided by SW and support teams, as is, they were developed under LF6.12.49. Under the BSD-3 license. Please confirm bank and word, if needed create a support ticket, this post is not responsible incorrect usage. Tested in FRDM-i.MX91 Written in C LF-6.12.49
記事全体を表示
For S32G274A multi-core scenario, can the first 0x9100 bytes of fip.bin be neglected? When making ATF image for BSP42, we get information like this: Boot Core: A53_0 IVT Location: QSPI Load address: 0x342f8f00 Entry point: 0x34302000   Entry point - Load address = 0x9100 it's BL2 that sits at offset 0x9100 of fip.bin. So is "Entry point" refering to BL2?   For multi-core scenario, MCU runs bootloader to load BL2 for A53. If BL2 is the entry point, should bootloader just copy from offset 0x9100 of fip.bin(BL2) to 0x34302000 of RAM space(neglect the first 0x9100 bytes)? GoldVIP Re: For S32G274A multi-core scenario, can the first 0x9100 bytes of fip.bin be neglected? Hello, @wansp  Thanks for your post The bootloader will move the data from QSPI to the Load address(SRAM), they would not be neglected. BR Chenyin
記事全体を表示
i.MX8MP 板。show error DRM_CAP_DUMB_BUFFER"/dev/dri/card0 我将代码从 gui-guider 导出到 yocto。设置环境并 版本 bitbake imx-image-multimedia。运行 gui 应用程序(gui-guider)时部署到 板 上显示错误 DRM_CAP_DUMB_BUFFER " /dev/dri/card0 " 没有 dunb 缓冲区。 Re: i.MX8MP board. show error DRM_CAP_DUMB_BUFFER "/dev/dri/card0 你好 /dev/dri/card0 是默认值,你需要在 GUI Guider 的项目设置中根据你的主板更改这个值。 只需在板上使用以下命令进行检查即可: $ ls-l /dev/dri/card * 顺祝商祺! 宗春 Re: i.MX8MP board. show error DRM_CAP_DUMB_BUFFER "/dev/dri/card0 i use 8MPLUSLPD4-PEVK board. Re: i.MX8MP board. show error DRM_CAP_DUMB_BUFFER "/dev/dri/card0 我改为使用 /dev/dri/card1。但请遵循以下提示 错误:drmModeAtomicCommit 失败:Permission denied error:刷新失败 Re: i.MX8MP board. show error DRM_CAP_DUMB_BUFFER "/dev/dri/card0 你好 请尝试使用 /dev/dri/card1。 最佳回复 宗春 Re: i.MX8MP board. show error DRM_CAP_DUMB_BUFFER "/dev/dri/card0 在板中,我找到了 /dri/card0 和 /dri/card1。
記事全体を表示