Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
Qt5 QPainter 与 QML 和场景图。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 使用 Qt5,您会发现新增的技术将使您的开发变得更加容易。 Qtquick2 场景图 质量 Qt5 向后兼容,这意味着您可以运行 Qt 4.8 应用程序,但这并不意味着它们将具有最佳性能,有时最好进行移植以使用最新的功能。 Qt5,有两种选项可以将组件绘制到屏幕上。Qt 5 中的绘画主要通过以下方式完成: 命令式 QPainter API Qt 的声明性 UI 语言QML及其场景图后端。 QPainter 正如本文档提到的Qt5GraphicsOverview | Qt Wiki | Qt Project Qpainter 引擎使用软件进行绘画,并在绘制 Qimages 或 Qwidgets 时使用。它相对于 OpenGL 的优势在于启用抗锯齿功能时的高质量以及完整的功能集。 Qpainter 可以使用 OpenGL 引擎,但正如文档中提到的,它更容易受到状态变化的影响。并且必须小心使用。 QML 和场景图。 所有可视化 QML 项目均使用场景图进行渲染,场景图是一种低级、高性能渲染堆栈,与 OpenGL 紧密相关。 Qt Quick 2 使用基于 OpenGL ES 2.0 或 OpenGL 2.0 的专用场景图进行渲染。使用场景图进行图形处理,而非传统的命令式绘画系统(QPainter等),意味着待渲染的场景可以在帧之间保留,并且在渲染开始之前即可知道要渲染的完整图元集合。这为一系列优化提供了可能,例如批量渲染以最大限度地减少状态变化,以及丢弃被遮挡的图元。 QML 场景 图 是 Qt 5 中 QML 的新后端 ,它基于 OpenGL。 与 Qt 4 中使用的基于 QPainter 的后端相比,它总体上显著 提高了 QML 的性能。它通过多种方式实现了更佳的性能: 场景图直接使用 OpenGL,而不是通过可以使用光栅或 OpenGL 绘画引擎的 QPainter。这意味着所有资源(如几何体、纹理和着色器)都可以以适合 OpenGL 的格式存储,而不是使用 QPainterPath、QPixmap、QBrush 或 QPen 等类,QPainter 需要将这些类转换为 OpenGL 原语并可能进行缓存。 QML是一种声明性语言,它定义了最终结果应该是什么样的,但它并没有定义如何以及以何种顺序绘制每个单独的元素。因此,可以重新排序绘图以减少状态变化的次数,或者合并绘图以减少绘图调用的次数。 场景图使用单独的渲染线程,并在支持此功能的平台上将动画与垂直回扫同步。渲染线程允许在渲染当前帧的同时准备下一帧。这对单核系统也有积极的影响,因为渲染线程可能会阻塞 OpenGL 命令。与垂直回扫的同步提高了动画的感知平滑度。 我们已经在 i.MX6 上测试了这两个选项,使用 QML Qtquick2 元素获得了最佳效果。当我们尝试通过 Widgets 使用 QtPainter 时,我们面临的问题是,如果不使用像 X11 或 Wayland 这样的窗口系统,画家将无法正常工作并且只会显示 QtGLWidget。 使用 QML 场景图,我们可以在同一个环境中拥有一个 OpenGL 元素和一个 Qt 元素,并且可以轻松地相互通信和共享变量。请在此处查看示例结果: I.MX6 场景图 Qt5 - YouTube 最大的优势是,sceneGraph 全部通过 OpenGL 加速。 回复:Qt5 QPainter 与 QML 和场景图。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好 我正在将一个大型应用程序移植到带有 Qt5.1 的 iMX6,该应用程序最初基于 Qt4.7 并在 iMX35 上运行。 我的旧应用程序有很多基于 QPainter API 的 2D 绘图。 我希望用 QGLWidget 替换 QWidget 并获得硬件加速的 QPainter API;但看起来情况并非如此。 我继续使用 QPainter,但只获得像 Qt 4.7 那样的软件渲染 如果我想要硬件加速 2D 渲染,那么我必须使用 gl API 重写所有绘图代码。 我的理解正确吗? Fabio 回复:Qt5 QPainter 与 QML 和场景图。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> FranciscoCarrillo ,您能否将此文档移至公共 i.MX 社区,以便那里的文档不会指向外部成员无法访问的地方的文档?然后在下面的公开讨论中添加一个帖子来报告这个问题? 链接文章称“访问此地点或内容受到限制...” 此问题尚未回答。 (标记为假定已回答)      stephenlangstaff 2013年7月12日 上午2:43 我看到“对此地点或内容的访问受到限制。如果您认为这是一个错误,请联系您的管理员或引导您到这里的人。”当尝试访问https://community.freescale.com/docs/DOC-94234时,指出EGLFS 上的 QT5 Demo 错误。 谢谢。 授予
記事全体を表示
LPC55S69に基づくMCU用の幅広い自動調整電力測定ソリューション 電力測定ボードには、8つのプログラマブル・ゲイン・アンプ(LTC6915)と2つのADCコンバータ(AD7175)をサポートする8つの測定チャンネルが含まれています。測定ボードは、サンプリング抵抗の両端の電圧降下を測定し、電圧降下がアンプによって処理された後、ADCに送信し、SPIを介して利用できるようにします。マイコンLPC55S69は、測定回路からデータを収集し、USB VCOMポートを介してホストコンピュータに送信します。MCUは、異なる電源回路を測定するときに、SPIによってプログラマブルゲインアンプのゲイン値を制御できます。 ホストコンピュータはUSB仮想シリアルポートを介して電力測定ボードに接続し、MCUはSPIによって測定ユニットを初期化および構成し、内部電流の測定と電圧の監視を開始します。MCUはゲインパラメータを調整し、SPIによって電流と電圧のデータをMCUに送信し、MCUはデータをホストコンピュータに送信して、仮想シリアルポートを介して処理および表示します。測定対象の回路の電圧降下は、まずプログラマブルアンプLTC6915で増幅され、同時にMCUがデータが異常でないかの状態を監視します。 R0はサンプリング抵抗、LTC6915は選択可能なプログラマブルアンプで、ゲインは14種類に設定でき、電流が変化するとPGAゲインパラメータが調整されます。ADC7175は24ビットの高精度ADCで、これは小電流測定のアプリケーションにより有利です。MCUが低電力モードを通常モードに切り替えると、LTC6915はSPIによってゲイン値を減少させます。 電力測定ボードは、2線式ケーブルによる簡単な接続方法を提供します。たとえば、MIMXRT1180EVKとMIMXRT1020EVKは電力測定ボードに接続されています。 USB仮想COMはデータ転送に使用され、PMT(電源管理ツール)または他のPCGUIによって表示され、測定電力データには電流、電圧、電力が含まれます。 添付ファイルには、より詳細な説明があります。 全般 LPC55xx ペリフェラル
記事全体を表示
FS26でS32K341に電力を供給する/v11の入手方法 S32K344評価ボードの回路図とボードを見ていますが、v11がどこから来ているのか理解できず、MCUのV11ピンにのみ接続されており、それ以外は何も接続されていないように見えます 私はこれを誤解しており、ボードに2.5Vと1.1Vを供給する必要はなく、これらのピンにコンデンサが必要なだけだと誤解していますか? 私はこれを見落としていました、私は正しく理解していますか、私は1.5Vを供給する必要があるだけでなく、VDD_HV_AとB、およびVREFHのために5Vを供給する必要がありますか? さらに、FS26のVCoreなどの電圧レベルをv15に電力を供給する方法がわかりません。この情報は、セキュアアクセスファイルの完全なデータシートに含まれていますか? Re:FS26でS32K341に電力を供給する/v11の入手方法 こんにちはジェイソンZ、 はい、あなたはそれを非常によく理解しています:V11ピンとV25ピンを外部に供給する必要はなく、デカップリングコンデンサを接続するだけで済みます。 はい、1.5VとVDD_HV_AとB、およびVREFHに5Vを供給する必要があります。 この情報は、S32K3xx MCUファミリのデータシート(図20など)およびS32K3xx MCUファミリ - リファレンスマニュアル(図165など)に記載されています。しかし、供給管理の最良のリファレンスは、S32K3 MCUの汎用 - ハードウェア設計パッケージで、考えられるすべての供給実施形態がリストされています。これらのドキュメントはいずれも[セキュリティ]セクションにはありません。 よろしくお願いいたします。 パベル
記事全体を表示
Autosar RTD開発キットを使用すると、s32k314は割り込みに入ることができませんが、s32dsパッケージインターフェースを使用して正常に送受信できます。 こんにちは、 (1)CAN開発にNXPパッケージインターフェースを使用すると、すべて正常に動作します。 (2) Autosar開発キットを使用すると、クロックが割り込みに入ることができません。下図のロジックが理解できません。メッセージ0x55AはIDからCANFDではないと判断できるのはなぜでしょうか? (3)Can_43_FLEXCAN_Writeインターフェースへの最初の呼び出し後、メッセージは内部のFlexCAN_Ip_Sendインターフェースで送信されず、後続の割り込みに入ることができないため、mb状態がビジー状態のままになり、後続の送信プロセスを実行できなくなります。 以下にEBプロジェクトとS32dsプロジェクトを示します。原因がAutosarによってカプセル化されたRTDパッケージに問題があるかどうかの確認にご協力ください。よろしくお願いいたします。EB 29.0を使用しており、対応するRTDバージョンはSW32K3_S32M27x_RTD_R21-11_5.0.0_D2410.exeです。 回复: 使用Autosar RTD开发包,s32k314无法进入中断,但使用s32ds封装接口可以正常收发 CANのTRCVはTJA1050です。can_STBやENピンの設定は不要です。
記事全体を表示
S32K146:D-Flash代码烧录 你好:         想了解一下,如果我拿到了一块新的S32K146芯片,在我没有运行过任何程序的情况下,将包含D-Flash区域的.hex文件直接烧写到芯片中,D-Flash区域能写入代码么,还是只有P-Flash地址段能够烧写成功? Re: S32K146:D-Flash Code burning Hi@ShaoTianzhi D-Flash的数据掉电也不会丢失,如果丢失一定是被擦除,擦除可能的原因 1.执行了分区操作,每次执行分区都会擦除数据 2.调试器在下载程序的时候,没有设置区域保护,默认会全擦。
記事全体を表示
Linux内核的调试方法 以下是针对内核性能要求或相关问题的一些调试方法。它包括所有常见的方法,例如 oops/panic 问题、内存问题等等。详情请查看附件。 操作系统和系统分析 糟糕/恐慌 地址2线 objdump gdb Pstore Kdump 内存调试 SLAB KASAN Kmem泄漏 性能 Perf Ftrace eBPF/密件抄送 i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano
記事全体を表示
S32 Power 设计工作室 v1.1 - 更新 1 现已发布 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 尊敬的S32DS用户: S32 Design Studio for Power v1.1 Update 1 已发布。 离线更新包可以在这里下载: https://www.nxp.com/webapp/Download?colCode=S32DS_PA_v1.1_UP1&appType=license&location=null&Parent_nodeId=14320533561557…    对于在线安装,请选择预定义的 NXP 存储库“帮助”->“安装新软件...”对话框: ${p2.metadata.repo.name} - http://www.nxp.com/lgfiles/updates/Eclipse/S32DS_POWER_1_1/com.freescale.s32power.updatesite       变更列表: 新的编译器版本 1.1.3– 请参阅编译器发行说明(附件)中的详细信息 适用于 Windows 10 的 SPT 工具包含 MS Visual C++ 2010 Redistributable x86 更新的 SPT 工具: ENGR00381373 - 生成 SPT 后出现错误构建 当目标寄存器与 src1 不同时,修复 ADD、SUB、CMP ENGR00380758 Windows 上的 spt2 不支持 64 位操作数 更新的示例 MPC5775K 的新 SPT1 示例 o SingleElf_MPC5748G 启动文件使用 GDB 命令“set architecture powerpc:vle”更新 图形工具 ENGR00380255 [SPT] 应使用标准包含项创建默认图表 错误修复: ENGR00375995 MPC5746C Embsys 寄存器定义缺少 SPI 寄存器集 ENGR00379744 SPT 汇编程序应在 MPC577xK 或 S32R274 项目创建后初始化“包含路径(-I)”选项 ENGR00380796 链接器文件部分.spt应针对 SPT1/SPT2 进行校正 概述 回复:S32 Design Studio for Power v1.1 - 更新 1 可用 我们能否以 C 代码或 C 库文件的形式获得 SPT 功能 这将有助于我们在 IDE 中使用应用程序分析 ADC 输出。 #S32DS #SPT  @iulianbulancea  回复:S32 Design Studio for Power v1.1 - 更新 1 可用 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 看起来,线上和线下网站都宕机了很长时间。有什么提示吗?
記事全体を表示
Boundary Devices 的 SABRE Lite <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 飞思卡尔和 Boundary Devices 很高兴地宣布推出 i.MX6x Sabre Lite Board,这是一款配备强大的 i.MX 6Quad 应用处理器的低成本开发平台。     $299   i.MX6开发板 该平台的亮点包括: 1GHz 四核 ARM ® Cortex A9 处理器 1GB 64 位宽 DDR3 @ 532MHz 三个显示端口(RGB、LVDS 和 HDMI 1.4a) 两个摄像头端口(1x并行,1x MIPI CSI-2) 支持多流的高清视频引擎提供 H.264 1080p60 解码、1080p30 编码和高清 3-D 视频播放 三重播放图形系统由一个四着色器 3D 单元组成,能够达到 200MT/s,以及一个单独的 2-D 和单独的 OpenVG Vertex 加速引擎,可实现卓越的 3D、2D 和用户界面加速 串行 ATA 2.5 (SATA),3Gbps 双 SD 3.0/SDXC 卡插槽 PCIe端口(1通道) 模拟(耳机/麦克风)和数字(HDMI)音频 紧凑尺寸(3英寸x3英寸) 10/100/Gb IEEE1588以太网 10-pin JTAG interface 3 个高速 USB 端口(2xHost、1xOTG) 1个CAN2端口 I2C GPIOs     查看兼容产品: 7英寸显示屏 SATA 线缆 5MP 摄像头 Android 按钮板 适用于 Freescale 10.1 英寸的 LVDS 电缆 PCIE数据库   目前交货时间为 2-3 周 生产成本为 199 美元(2012 年 10 月)   点击此处获取更多信息。   概述
記事全体を表示
バウンダリーデバイス - FreeRTOS BSP v1.0.1 for Nitrogen7 & Nit6_SoloX <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このブログ記事では、i.MX6SoloX および i.MX7D プロセッサのアーキテクチャを紹介し、MCU で FreeRTOS BSP v1.0.1 をビルドして実行する方法について説明します。 どちらのプロセッサも、 Cortex-A と Cortex-M4 コアを1つのチップ内で結合し、MPUとMCUの最高の機能を提供します(i.MX7Dの図を参照)。以下の内容は、 当社のNit6_SoloX および Nitrogen7 プラットフォームに適用されます。 せっかちな方へ デモ画像はこちらからダウンロードできます。 Nit6_SoloX のための 20160804-buildroot-nitrogen6sx-freertos-demo.img.gz 窒素の 20160804-buildroot-nitrogen7-freertos-demo.img.gz 7 通常どおり、NXPコンテンツが含まれているため、当社のサイトに登録し、EULAに同意する必要があります。イメージは 1GB の SD カード イメージで、Linux で zcat と dd を使用して復元できます。 ~$ zcat 20160804-buildroot*.img.gz |sudo dd of=/dev/sdX bs=1M Windowsユーザーの方は、 Alex PageのUSB Image Toolをご利用ください。 このイメージには、次のコンポーネントが含まれています。 Linux kernel 4.1.15 Uブート v2016.03 FreeRTOS 1.0.1 デモアプリケーション 開始する前に、プロンプトからU-Bootを更新してください。 => clearenv を実行 => upgradeu を実行 アップグレード後、ボードがリセットされ、Cortex-M4で最初のHelloWorldアプリケーションを起動できます。 => m4update を実行 => m4boot を実行 アーキテクチャ はじめに、投稿全体で使用される用語の定義を次に示します。 MCU:ARM Cortex-Mシリーズなどのマイコンユニットで、ここではCortex-M4を指します MPU:ARM Cortex-Aシリーズなどのマイクロプロセッサユニット、ここではCortex-A9 / A7を指します RTOS:FreeRTOSやMQXなどのリアルタイムオペレーティングシステム i.MX6SXプロセッサとi.MX7プロセッサは、同じチップにMCUとMPUを提供し、これは ヘテロジニアスマルチコアプロセッシングアーキテクチャと呼ばれます。 それはどのように機能しますか? 最初に知っておくべきことは、コアの1つが「マスター」であり、他のコアの起動を担当しているということです。これは、リセットされたままになるコアです。 BootROM は常に Cortex-A コア を最初に起動します。この記事では、 U-Boot がシステムで使用されるブートローダーであると仮定しています。その理由は、U-Boot が Cortex-M4 を起動できる bootaux コマンドを提供しているためです。 起動すると、両方のCPUは独立して、異なる命令を異なる速度で実行します。 コードはどこから実行されていますか? 実際には、使用するアプリケーション リンカスクリプト に依存します。GCC がアプリケーションを ELF 実行可能ファイルにリンクする場合、メモリ内のコード位置を知る必要があります。 どちらのプロセッサにもいくつかのオプションがあり、コードは次のいずれかに配置できます。 TCM (密結合メモリ):32kBが利用可能 OCRAM:32kB利用可能 EPDC を使用しない場合は、128kB を使用できますが、ocram リンカ スクリプトを変更する必要があります DDR:最大1MB利用可能 QSPIフラッシュ (ou Nit6_SoloXでは使用不可):128kBをNitrogen7に割り当て TCMはCortex-M4専用の内部メモリであるため、最高のパフォーマンスを提供するため、可能な場合は推奨されるオプションであることに注意してください。 DDRやQSPIなどの外部メモリは、より多くのスペースを提供しますが、アクセス速度も大幅に低下します。 この記事では、すべてのアプリケーションが TCM から実行されることを前提としています。 MCUはどんなときに役に立ちますか? MCUはすべてのリアルタイムタスクに最適ですが、MPUはGNU / Linuxなどの非リアルタイムOSで優れたUIエクスペリエンスを提供できます。 ここでは、Linuxカーネルはリアルタイムではなく、決定論的ではないが、Cortex-M4上のFreeRTOSはリアルタイムではないという事実を主張します。 また、ファームウェアは非常に小さく、読み込みが速いため、MCUは数百ミリ秒以内に完全に動作できますが、通常はLinux OSが動作するのにはるかに時間がかかります。 MCUが有用であることが証明されているアプリケーションの例: モーター制御:DCモーターは、フィードバック応答時間が重要であるため、リアルタイム環境でのみ良好に機能します オートモーティブ:CANメッセージをMCUで処理し、非常に早い段階で運用可能 リソース・ドメイン・コントローラ (RDC) 両方のコアが同じペリフェラルにアクセスできるため、同時アクセスを回避するメカニズムが作成され、一方のコアでのプログラムの動作がもう一方のコアで実行/アクセスされる内容に依存しないようにすることができます。 このメカニズムはRDCであり、各コアに ペリフェラルおよびメモリのアクセス許可を付与する ために使用できます。 FreeRTOS BSP の例とデモアプリケーションは、RDC を使用して周辺機器のアクセス許可を割り当てます。FreeRTOS BSP サンプル/デモを使用して ARM Cortex-A アプリケーションを実行する場合は、 予約済みの周辺機器を尊重することが重要です。 FreeRTOS BSP アプリケーションには、ARM Cortex-M4 でのみ使用される予約済み周辺機器があり、 これらの周辺機器で ARM Cortex-A コアからアクセスすると、プログラムがハングする可能性があります。 デフォルトの RDC 設定は次のとおりです。 ARM Cortex-M4 コアは RDC ドメイン 1 に割り当てられ、ARM Cortex-A コアおよびその他のバス マスターはデフォルトの割り当て (RDC ドメイン 0) を使用します。 すべての例/デモには、hardware_init.cに特定のRDC設定があります。それらのほとんどは排他的アクセスに設定されています。 このパッケージのユーザーは、サンプル/デモまたは自分のアプリケーションで RDC 設定を削除または変更できます。可能な限り、ペリフェラルのアクセスを、それを使用する唯一のコアに制限することをお勧めします。 また、周辺機器がLinuxで利用可能として表示されないようにするには、デバイスで周辺機器を無効にすることが必須であるため、MCUを使用するときに特定のデバイスツリーが使用されます。 imx7d-nitrogen7-m4.dts メモリ宣言は、FreeRTOS や共有メモリ用に一部の領域を予約するために、上記のデバイスツリーでも変更されます。 リモート・プロセッサー・メッセージング (RPMsg) Remote Processor Messaging (RPMsg) は、非対称マルチプロセッシング (AMP) システムに存在する同種または異種コア上で動作する独立したソフトウェアコンテキスト間でのプロセッサー間通信 (IPC) を可能にする virtio ベースのメッセージングバスです。 RPMsg API は、アップストリームの Linux 3.4.x カーネル以降に存在する RPMsg バスインフラストラクチャに準拠しています。 この API には、次の利点があります。 割り込みコンテキストでのデータ処理なし ブロッキング受信 APIの ゼロコピー 送受信API RTOSが提供する タイムアウト 付き受信 DDR は、コア間でメッセージを交換するために RPMsg でデフォルトで使用されることに注意してください。 実装の詳細が記載されたリンクを次に示します。 RPMsg_RTOS_Layer_User's_Guide.pdf https://www.kernel.org/doc/Documentation/rpmsg.txt その他のドキュメントはどこで入手できますか? BSPには、このテーマについて詳しく知るために読むことをお勧めするいくつかのドキュメントが実際に付属しています。 FreeRTOS_BSP_1.0.1_i.MX_7Dual_Release_Notes.pdf FreeRTOS_BSP_for_i.MX_7Dual_Demo_User's_Guide.pdf FreeRTOS_BSP_i.MX_7Dual_API_Reference_Manual.pdf Getting_Started_with_FreeRTOS_BSP_for_i.MX_7Dual.pdf ビルド手順 開発環境のセットアップ FreeRTOS BSP をビルドするには、まず ARM Cortex-M プロセッサ用のツールチェーンをダウンロードしてインストールする必要があります。 ~$ cd && mkdir ツールチェーン && cd ツールチェーン ~/toolchains$ wget https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q3-update/+download/gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 ~/toolchains$ tar xjf gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 ~/toolchains$ rm gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 FreeRTOS はビルドを cmake に依存しているため、次のパッケージがマシンにインストールされていることも確認する必要があります。 ~$ sudo apt-get install make cmake BSPのダウンロード FreeRTOS BSP v1.0.1 は、GitHub の freertos-boundary リポジトリから入手できます。 ~$ git clone https://github.com/boundarydevices/freertos-boundary.git freertos ~$ cd フリートス 使用する予定のプロセッサ/ボードによって、ブランチは異なります。 Nit6_SoloX (i.MX6SX) の場合は、imx6sx_1.0.1 ブランチを使用します。 ~/freertos$ git checkout origin/imx6sx_1.0.1 -b imx6sx_1.0.1 Nitrogen7 (i.MX7D) の場合は、imx7d_1.0.1 ブランチを使用します。 ~/freertos$ git checkout origin/imx7d_1.0.1 -b imx7d_1.0.1 最後に、 ARMGCC_DIR 変数をエクスポートして、FreeRTOS がツールチェーンの場所を認識できるようにする必要があります。 ~/freertos$ export ARMGCC_DIR=$HOME/toolchains/gcc-arm-none-eabi-4_9-2015q3/ FreeRTOS アプリの構築 まず、FreeRTOS BSP の概要を簡単に説明します。 すべてのアプリケーションは、examples フォルダの下にあります。 examples/imx6sx_nit6sx_m4/ Nit6_SoloX用 examples/imx7d_nitrogen7_m4/ 窒素用7 例として、 Nitrogen7 の helloworld アプリケーションを構築します。 ~/freertos$ cd examples/imx7d_nitrogen7_m4/demo_apps/hello_world/armgcc/ ~/freertos/examples/imx7d_nitrogen7_m4/demo_apps/hello_world/armgcc$ ./build_all.sh ~/freertos/examples/imx7d_nitrogen7_m4/demo_apps/hello_world/armgcc$ ls release/ hello_world.bin hello_world.elf hello_world.hex hello_world.map build_all.sh スクリプトは、デバッグ バイナリとリリース バイナリの両方をビルドします。デバッグに使用する JTAG がない場合は、デバッグ ターゲットを破棄できます。 その後、そのhello_world.binファームウェアをSDカードのルートにコピーしてフラッシュできます。 デモ アプリを実行する 基本セットアップ まず、 この投稿の冒頭 で提供されている画像をSDカードにフラッシュする必要があります。 SDカードには、Cortex-M4の使用を可能にするU-Bootバージョンが含まれていますので、 せっかちなセクション で説明されているように 必ず更新 してください。 デフォルトでは、ファームウェアは NOR から TCM にロードされます。NORでファームウェアをアップグレードするための m4update を実行できます。外部ストレージ(SD、USB、SATA)のルートとしてm4_fw.binという名前のファイルを探し、NORのオフセット 0x1E0000 でフラッシュします。 => m4update を実行 別の名前のファイルをフラッシュする場合は、次のように m4image 変数を変更できます。 => setenv m4image MCUでのデバッグ中に、すべてのファームウェアをNORに書き込まないようにしたい場合があるため、外部ストレージから直接M4ファームウェアをロードするコマンドを追加しました。 => setenv m4boot 'run m4boot_ext' 先に進む前に、「コンソール」とマークされたポートがU-Bootに使用され、もう1つがMCUからのデータを表示するため、2番目のシリアルポートをマシンに接続してください。 起動時にMCUを自動的に起動するには、ファームウェアをロードするように 6x_bootscript に指示する変数を設定する必要があります。これを行うには、この変数 を必ず保存 してください。 => setenv m4enabled 1 => saveenv このブログ記事では、TCMを実行用のファームウェアの場所としてのみ考慮しています。OCRAM、QSPI、DDR など、別のメモリを使用する場合は、U-Boot 変数で指定できます。 => setenv m4loadaddr => setenv m4size リンカスクリプトは、プログラムを別の場所から実行するには異なる必要があることに注意してください。また、現在NORで予約されているサイズは 128kBです。 Hello Worldアプリ Hello World プロジェクトは、BSP ソフトウェアを使用する 簡単な デモ プログラムです。BSP UARTドライバを使用して、ARM Cortex-M4端末に「Hello World」メッセージを出力します。このデモの目的は、UART の使用方法を示し、デバッグとさらなる開発のための簡単なプロジェクトを提供することです。 U-Boot で、次のように入力します。 => setenv m4image hello_world.bin => m4update を実行 => m4boot を実行 2 番目のシリアル ポートには、次の出力が表示されます。 ハローワールド! その後、その端末に何かを入力でき、 ソースコードでわかるように、シリアルポートにエコーバックされます。 RPMsg TTY demo このデモ アプリケーションは、 RPMsg リモート ピア スタックを示します。Linux RPMsg マスターピアと連携して、文字列コンテンツを相互に転送します。Linux ドライバーは、書き込み可能な tty ノードを作成します。MCUは受信した内容を表示し、確認応答と同じメッセージをエコーバックします。ARM Cortex-A コアの tty リーダーは、メッセージを受け取り、別のトランザクションを開始できます。このデモは、任意のコンテンツを送受信する RPMsg の機能を示しています。 U-Boot で、次のように入力します。 => setenv m4image rpmsg_str_echo_freertos_example.bin => m4update を実行 => ブート 2 番目のシリアル ポートには、次の出力が表示されます。 RPMSG 文字列エコー FreeRTOS RTOS API デモ... RPMSG リモートとして初期化 Linuxが起動したら、2つのコア間の通信を開始できるように、RPMsgモジュールをロードする必要があります。 # modプローブ imx_rpmsg_tty imx_rpmsg_tty rpmsg0: 新チャンネル: 0x400 -> 0x0! rpmsg tty ドライバをインストールしてください!# エコーテスト > /dev/ttyRPMSG 上記の最後のコマンドはttyノードに書き込みを行うため、Cortex-M4は2番目のシリアルポートで確認できるデータを受信しているはずです。 ネームサービスのハンドシェイクが完了し、M4 は rpmsg チャネル [0 ---> 1024] を設定しました。 マスター側からメッセージを受け取る : "test" [len : 4] マスター側から新行を取得する RPMsg ピンポンのデモ 前のデモと同様に、このデモは RPMsg 通信を示しています。通信チャネルが作成されると、Linux OS は最初の整数を FreeRTOS OS に転送します。受信側ピアは、整数に 1 を加算して転送し直します。ループは無限に続きます。 U-Boot で、次のように入力します。 => setenv m4image rpmsg_pingpong_freertos_example.bin => m4update を実行 => ブート 2 番目のシリアル ポートには、次の出力が表示されます。 RPMSG PingPong FreeRTOS RTOS APIデモ... RPMSG リモートとして初期化 Linuxが起動したら、2つのコア間の通信を開始できるように、RPMsgモジュールをロードする必要があります。 #modprobeのimx_rpmsg_pingpong imx_rpmsg_pingpong rpmsg0: 新チャンネル: 0x400 -> 0x0! # 1 を取得 (src: 0x0) 3を取得(SRC:0x0) 5を取得(SRC:0x0) ... MCUから受信したデータをメインシリアルポートで送信できますが、MPUから受信したデータをセカンダリシリアルポートで確認することもできます。 ネームサービスのハンドシェイクが完了し、M4 は rpmsg チャネル [0 ---> 1024] を設定しました。 マスター側からデータを取得する : 0 マスター側からデータを取得する : 2 マスター側からデータを取得する : 4 ... これで、ビルド、変更、実行、デバッグができるようになります 全般 Re: Boundary Devices - FreeRTOS BSP v1.0.1 for Nitrogen7 & Nit6_SoloX <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> t
記事全体を表示
S32G IPCF Mコア 専門家の皆さん、こんにちは。 IPCF関数をデバッグしていました。S32DSの例(名前を変更しました)を使用しましたが、プラットフォームはS32G399Aです。しかし、Mコアイメージを正常にロードできませんでした。何か提案をいただけますか?ありがとうございます! 回复: S32G IPCF M core こんにちは @Celeste_Liu MコアのIPCF 4.9はどうすれば入手できますか?S32DSで使用するには 回复: S32G IPCF M core 親愛なる@piaochunri、 はい、AコアとMコアのIPCFバージョンは同じであるべきだと説明しようとしていました。次の図は、両方に IPCF 4.9.0 を使用した場合の結果です。お悩みが解決してよかったです。 よろしくお願いいたします。 Celeste 回复: S32G IPCF M core はい、MコアのIPCF4.10を使用した後、問題は解決しました。 ご協力の程、よろしくお願い申し上げます。 回复: S32G IPCF M core Hello, 発生したカーネルパニックの状況については、次の方法を試して、それが役立つかどうかを確認できますか? 当初は、バイナリを最初にDDRAMにロードし、次にSRAMにロードする次の手順がありました。 fatload mmc 0:1 0x80000000 IPCF_Example_S32G274A_M7_0.bin cp.b 0x80000000 0x34300000 0x300000 ただし、上記の 2 つのコマンドを実行する代わりに、次のコマンドを実行して SRAM に直接ロードしました。 fatload mmc 0:3 0x34300000 IPCF_Example_S32G274A_M7_0.bin 効果がないかご確認ください。   よろしくお願いいたします。 Celeste 回复: S32G IPCF M core yoctoで生成されたrootfsとカーネルソースを使用しました。イメージと dtb を手動でビルドしました (phy config を修正) が、rootfs で生成された ipcf ko ファイルは変更しませんでした。そして、koファイルをインストールしたとき。それでもパニックに陥りました。 root@s32g399ardb3:/lib/modules/5.15.145-RT73+G3A3FAFB13BAA+P1/extra# INSMOD IPC-SHM-DEV.KO root@s32g399ardb3:/lib/modules/5.15.145-RT73+G3A3FAFB13BAA+P1/extra# INSMOD IPC-SHM-SAMPLE.KO [ 7.494024] pfeng 46000000.pfe:HIF2 開始 [ 7.589045] pfeng 46000000.pfe pfe2: PHY [PFEng イーサネット MDIO.2:03] ドライバー [mv88Q2112] (irq=POLL) [ 7.589070] pfeng 46000000.pfe PFE2:PHY / RGMII-IDリンクモードの構成 [ 7.591039] pfeng 46000000.pfe:HIF1 開始 [ 7.691887] pfeng 46000000.pfe pfe1: PHY [PFEng イーサネット MDIO.1:03] ドライバー [mv88Q2112] (irq=POLL) [ 7.691913] pfeng 46000000.pfe PFE1:PHY/RGMII-IDリンクモードの設定 [ 7.694032] pfeng 46000000.pfe:HIF0 開始 [ 7.694050] pfeng 46000000.pfe PFE0:固定/SGMIIリンクモードの設定 [ 7.694413] pfeng 46000000.pfe pfe0: リンクがアップ - 1Gbps/フル - フロー制御オフ [ 7.694616] IPv6: ADDRCONF(NETDEV_CHANGE): pfe0: リンクが準備可能になります [ 7.740501] pfeng 46000000.pfe pfe1: TX クロックを 125000000Hz に設定します [ 7.740539] pfeng 46000000.pfe pfe1: リンクがアップ - 1Gbps/フル - フロー制御オフ [ 7.740564] IPv6: ADDRCONF(NETDEV_CHANGE): pfe1: リンクが準備完了になります [ 41.180243] CPU1 の SError 割り込み、コード 0x00000000bf000002 -- SError [ 41.180262] CPU:1 PID:381 Comm:insmod Tainted:G O 5.15.145-rt73+g3a3fafb13baa+p1 #1 [ 41.180270] ハードウェア名:NXP S32G399A-RDB3 (DT) [ 41.180275] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 41.180281] PC : ipc_shm_init+0x424/0x8b0 [ipc_shm_dev] [ 41.180300] LR番号:ipc_shm_init+0x11c/0x8b0 [ipc_shm_dev] [ 41.180310] sp:ffffffc0096eb9d0 [ 41.180313] x29: ffffffc0096eba60 x28: ffffffc000990078 x27: 000000000000000000 [ 41.180326] x26: 0000000000000000000 x25: ffffffc000988340 x24: ffffffc00b100008 [ 41.180334] x23: ffffffc000988348 x22: 0000000000000000000000 x21: ffffffc00b100008 [ 41.180343] x20: ffffffc0009900b8 x19: 000000000000008d0 x18: ffffffffff [ 41.180352] x17: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 [ 41.180360] x14: 0000000000000001 x13: 007473696c5f7974 x12: 696e696666615f65 [ 41.180368] x11: 0000000000000040 x10: ffffffc008d91290 x9 : 0000000000000000000000 [ 41.180377 ] x8 : ffffff88011f9900 x7 : 0000000000000009 x6 : 000000000000024e [ 41.180386] x5 : 0000000000000008 x4 : ffffff880123f5c8 x3 : 0000000000000000000 [ 41.180395] x2 : 0000000000000003 x1 : 0000000000000001 x0 : ffffffc000988340 [ 41.180406] カーネルパニック - 同期しない: [ 41.180408] 非同期SError割り込み [ 42.180556] SMP:セカンダリCPUの停止 [ 42.388550] カーネル オフセット: 無効 [ 42.392015] CPU機能:0x8,00002001,20000842 [ 42.396530] メモリ制限:なし [ 42.399572] ---[ カーネルパニックの終了 - 同期しない: 非同期 SError 割り込み ]--- 回复: S32G IPCF M core Hello piaochunri, カーネルパニックの発生は、手動コンパイルに関連している可能性があります。私たちはあなたの問題をうまく再現することはできません。事前構築済みのイメージを使用して、上記の問題が引き続き発生するかどうかを確認できますか?または、モジュールを1つずつ交換することで、障害が発生しているモジュールを特定できます。 よろしくお願いいたします。 Celeste 回复: S32G IPCF M core どうもありがとうございます! 私はあなたの提案を試しました。しかし、カーネルのロードを続行することはできません。ログは以下の通りです。他に何か問題がありますか? ログ: Uブート 2022.04-dirty(2024年9月12日 - 14:17:18 +0800) SoC:NXPのS32G399Aリビジョン1.1 CPU:ARM Cortex-A53 r0p4 @最大1300 MHz モデル:NXP S32G399A-RDB3 DRAM: 3.5 GiB コア:306デバイス、25 uclass、デバイスツリー:ボード MMC:FSL_SDHC:0 MMC から環境を読み込んでいます...わかりました s32cc_serdes_phy serdes@44180000: SerDes サブシステムのモード 1 を使用 s32cc_serdes_phy serdes@44180000: XPCS0 がリセットされています s32cc_serdes_phy serdes@44180000: XPCS init が失敗しました pci_s32cc pcie@44100000: PHY 'serdes_lane0' を取得できませんでした で: serial@401c8000 アウト:serial@401c8000 エラー:serial@401c8000 取締役会の改訂:リビジョン不明:(0x717) ネット: eth0: ethernet@4033c000 PFEバージョン0x0101(S32G3)が見つかりました pfeng pfeng-base: CLASS ファームウェアのアップロード pfeng pfeng-base: EMAC0 ブロックが初期化されました pfeng pfeng-base: EMAC1 ブロックが初期化されました pfeng pfeng-base: EMAC2 ブロックが初期化されました pfeng pfeng-base: CLASS ブロックの有効化 pfeng pfeng-base: PFE プラットフォームが正常に開始されました (マスク: 7) s32cc_serdes_phy serdes@44180000: SerDes サブシステムのモード 1 を使用 s32cc_serdes_phy serdes@44180000: XPCS0 がリセットされています s32cc_serdes_phy serdes@44180000: XPCS init が失敗しました pfeng_netif pfe0: 'emac0_xpcs' PHY を取得できませんでした 、eth1:pfe0、eth2:pfe1、eth3:pfe2 自動起動を停止するには、任意のキーを押します:0 => dcache off;mw.q0x34100000 0x0 0x40000;脂肪負荷MMC 0:1 0x80000000 IPCF_FreeRTOS_S32G399A_M7_0.bin;cp.bの0x800 00000 0x34300000 0x300000;startm7 0x34500400; 2359376バイトを191ミリ秒(11.8MiB/秒)で読み取った SRAMアドレス0x34500400でコアを開始CM7_0...完成です。 => ブート パーティション#0に切り替えて、OK mmc0 は現在のデバイスです 14555144バイトを704ミリ秒(19.7MiB/秒)で読み取った mmc から起動しています ... 60860 バイトを 94 ミリ秒で読み取り (631.8KiB/s) ## Error: "fdt_fixups" not defined ## フラット化されたデバイス ツリー BLOB (83000000) fdt blob を使用して 0x83000000 で起動する デバイスツリーを0000000083000000の位置で使用し、0000000083011dbbで終了します XPCS0_0の無効化 カーネルを起動中… そして、それはここで止まりました。 回复: S32G IPCF M core 親愛なる@piaochunri、 まず、2つ目の質問にお答えしたいと思います。写真から、SDカードに入れたIPCF_M7_0_blob.binという名前のファイルが見えます。このバイナリファイルがIVTツールを使用して生成されたブロブ画像であるかどうか知りたいですか?それとも、このように名付けられているだけですか? 実際、IPCF EXAMPLEについては、ここに詳細な説明があり、次の図に示すように詳細な手順があります。ブロブ画像は必要ないことに注意してください。代わりに、直接コンパイルされた bin ファイルを使用できます。 ビルド済みのLinux bsp40イメージを使用し、上記の手順に従うことで、操作に問題はありません。 上記の情報がお役に立てば幸いです。カーネルパニックの問題については、さらに調査した後、返信します。 よろしくお願いいたします。 Celeste 回复: S32G IPCF M core そして、バージョンサプリメントを作ります。 IPCF Mコア:4.9 Linux bsp:40.0 IPCF Aコア:4.10 次の 2 つの問題があります。 1.ipc-shm-dev.koをインストールできますが、ipc-shm-sample.koをインストールするとカーネルがパニックになりました。 2.次のコマンドを使用しました:"dcache off;mw.q0x34000000 0x0 0x100000;脂肪負荷MMC 0:1 0x80000000 IPCF_FreeRTOS_S32G399A_M7_0_blob.bin;cp.qの0x80000000 0x34300000 0x60000;startm7 0x34500400;そして「boot」と入力した後、カーネルパニックが発生して続行できなくなりました。. 手伝ってくれませんか?
記事全体を表示
Understanding IEEE1588V1-V2 Simple understanding of IEEE 1588 protocol IEEE 1588 is a precision time protocol (PTP) for synchronizing clocks in computer networks. In local area networks, it can control clock accuracy in the sub-microsecond range, making it suitable for measurement and control systems. The IEEE 1588 standard defines a master-slave architecture for clock distribution, consisting of one or more network segments and one or more clocks. The time synchronization protocol in the TSN network uses the IEEE 802.1AS protocol, which is simplified and modified based on the IEEE 1588 protocol and is also called the gPTP protocol. ​ IEEE 1588 protocol is short for Precision Timing Protocol (PTP), and its full name is "Precision Clock Synchronization Protocol Standard for Network Measurement and Control Systems" (IEEE 1588 Precision Clock Synchronization Protocol). The basic principle of its operation is to send synchronized data frames between master and slave nodes, record the sending time and receiving time information of the data frames, and add the time information to the data frames. The slave node obtains this time information, calculates the time deviation between the slave node's local clock and the master clock and the transmission delay between network nodes, and corrects the local clock to synchronize it with the master node clock. There can only be one master clock in a PTP network. The PTP protocol is mainly divided into two parts to achieve clock synchronization function: 1. Establish a synchronization system: The protocol uses the Best Master Clock Algorithm (BMCA) to select a master clock, establish a master-slave topology, and then establish a synchronization system in the entire PTP network. 2. Synchronize local clock: The protocol uses the Local Clock Synchronization Algorithm (LCS) to calculate the time deviation between the local clock of each slave node and the master clock through the exchange of PTP data packets between the master and slave nodes in the network, and adjust the local clock to synchronize it with the master clock. IEEE 1588v1 ​ The clocks in the entire PTP network can be divided into ordinary clocks (OC) and boundary clocks (BC) according to the number of PTP communication ports on them: there is only one ordinary clock, while there are multiple boundary clocks. Boundary clocks are generally used at network nodes with low determinism, such as switches or routers, as shown in the figure below. PTP communication is carried out independently on each port. 1. Boundary Clock: Only one slave port is allowed on the boundary clock, which communicates with the master port of the upper node and synchronizes its local clock with the master port. The remaining ports are master ports, which communicate with the slave ports of the downstream nodes. The boundary clock can connect to different network protocols. 2. Synchronous system establishment process: ​ (1) In the initial state, each node port will listen to the Sync data frame in the network within the specified time; if a Sync data frame is received, the node port will determine the port state according to the best master clock algorithm. If no Sync data frame is received, the node state changes to Pre_Master and assumes itself as the master clock node. At this time, the node port state is the master clock, but no Sync frame is sent. ​ (2) The port status remains Pre_Master for a certain period of time: If a Sync data frame is received within the specified time of the port, the port status is determined by the best master clock algorithm. If the port is determined to be a master clock, it will periodically send Sync frames; if it is determined to be a slave clock, it will accept Sync frames, calculate the deviation, and correct the local clock. If the port does not receive a Sync data frame within this time period, the state is changed to the master clock and the Sync data frame is started to be sent regularly. ​ (3) The status of the master clock and slave clock changes with the change of clock performance and operating status. The figure below shows the state transition in BMCA. 3. Time synchronization establishment process: ​ As shown in the figure below, the PTP synchronization principle As shown in the figure, the Master is the synchronization clock source in the network, which can be considered to be infinitely close to UTC or GPS time. The Slave is the device that needs to be synchronized in the network. Assuming that the path from the Master to the Slave conforms to the symmetric path, the delay on the path is set as Delay, and the time difference between the Master and Slave devices to be synchronized is Offset, that is, the Slave is slower than the Master at the same time by Offset.         The Slave device can calibrate the local clock according to the calculated Offset. However, the 1588V1 protocol relies on the symmetry of the link, that is, the delay from Master to Slave and from Slave to Master is consistent, which is difficult to meet in actual network conditions, so an additional asymmetric algorithm is needed to calculate and compensate for the link delay difference. IEEE 1588v2 ​IEEE1588V2 has made improvements and extensions on IEEE1588V1. Mainly includes: 1. Added independent message mode for point-to-point path delay measurement. The path delay time Delay between port A and port B is: In PTPv1, the average path delay is measured by using Sync frames and Delay_Req frames, but in PTPv2, the Sync frame is not required, and the measurement is performed only through the PDelay_Req data frame series. This is an independent delay measurement process that does not rely on the participation of Sync frames and the establishment of a synchronization system, which improves the measurement accuracy and can obtain a more accurate path delay by averaging the average value after multiple measurements. On the other hand, if the synchronization system in the network changes, there is no need to recalculate the path delay between the nodes. The previously measured delay data can be used directly, which greatly enhances the efficiency of the protocol execution and makes the protocol more convenient and flexible. In PTPv2, the use of the PDelay_req data frame series has become the main method for measuring path delay. 2. Added transparent clock model In PTPv1, all the intermediate nodes in the network adopt the boundary clock model. The boundary clock connected to the only master clock in the network, that is, an ordinary clock, receives the synchronization data frame sent by the master node through its only slave port, and synchronizes with the master clock. The remaining master ports and other boundary clocks connected to them send synchronization data frames, and finally synchronize to the ordinary clock at the edge of the network, thus achieving time synchronization of the entire network. Although this method is feasible, since this method is synchronized step by step, the farther the node is from the master clock, the lower the synchronization accuracy. When some nodes in the network do not need clock synchronization or do not have synchronization function, the transparent clock model can be used. Unlike the BC/OC mode, the transparent clock does not require each node to synchronize with the master clock. Its port only forwards the protocol data frame and adds the calculated data frame retention time to the correction domain. This method makes the processing of PTP data frames simpler, reduces the difficulty of implementing the PTP protocol in the network, and improves the synchronization accuracy of each slave node. There are two models of transparent clock: end-to-end transparent clock and point-to-point transparent clock. (1) End-to-end (E2E) transparent clock The E2E transparent clock does not process ordinary data frames in the network, but only transmits them to allow them to pass normally. However, for PTP event data frames, the residence delay time from the receiving port to the sending port is accumulated to the correction field in the data frame to compensate for the delay error caused by the PTP data frame passing through itself. (2) Point-to-point (P2P) transparent clock Point-to-point (P2P) transparent clock only forwards specific PTP messages, including Sync frames, Follo_Up frames, and Announce frames. It also uses the Pdelay_Req data frame series to calculate the path delay time between each port and the port it is connected to, and then combines it with the delay time between ports and adds it to the time correction domain to compensate for the time delay of the data frame from the source port to the point-to-point transparent clock out port. 3. Adding a single-step clock model The single-step clock model solves the problem of matching Follow_Up frames with Sync frames. The basic synchronization process of the PTP protocol adopts a two-step mode, that is, the master clock node sends a Sync frame and a Follow_Up frame with the Sync frame sending time. Although this method can improve the accuracy of the Sync frame timestamp and improve the synchronization effect, when the network load is large, the data frame is likely to be lost or blocked, resulting in errors in the matching of the two data frames. Set a flag in the PTP data frame to use the single-step mode, and use the difference between the sending time of the Sync frame and the time tag in the data frame as the transmission delay, and add it to the correction field. In this way, the master clock can perform time synchronization calibration through a separate Sync frame without the need for Follow_Up. Single-step mode can reduce network traffic and improve the reliability of synchronization when the network load is large. Single-step mode requires additional auxiliary hardware to help calculate the time correction value and accumulate it into the correction domain, which has relatively high requirements on the real-time performance of the network. BMCA BMCA, or Best Master Clock Algorithm, selects the best performing clock in the network as the master clock, and uses it to establish the network topology, generate a synchronization system, and thus realize the clock synchronization function. The best master clock is selected by transmitting Announce frames in each node in the network, comparing the clock attributes on each node (such as whether the clock is designated as a master or slave clock), the clock level used to identify the accuracy, and the clock type used to identify the clock source type (such as rubidium clock, cesium clock, etc.), as well as clock characteristics such as clock offset and variance, clock address, and clock port number to select the best master clock. When other clock characteristics are the same, the protocol will use the node clock with the smallest port number as the master clock. The IEEE 1588 protocol will form a tree topology with the master clock node as the root node, and to avoid generating loops, the protocol defines those node ports that fail in competition as passive or disabled.
記事全体を表示
S32DS 3.4 の FreeMASTER CAN サンプルS32K144 Hi, MCUXpressoを持っていませんが、S32DS 3.4を使用しています。ビルド201217(Update3) S32DSを使ってFreeMasterをCANでS32K144実装してみました。 SDK の例は、UART との通信です。 S32K3xx uCにCANの例があるのを見て、S32K144に移植しようとしましたが、エラーが多すぎました。 144でCANと通信する方法を説明するのに十分な例がないようです。 私の製品は数キロ離れた場所から動作する可能性があるため、UART通信を使用できません。 S32DS上でS32K1xxを使用したCAN通信のサンプルコードを教えてください。 ありがとうございます。 Re:S32DS 3.4のFreeMASTER CAN例S32K144 Hi @CY9, FreeMASTERドライバには、複数の定義に対するガードがあります。これには、通信インターフェースの定義が含まれます( freemaster_private.h:298参照) /* only one communication link may be selected */ #if (!(FMSTR_DISABLE)) && FMSTR_COUNT_INTERFACES > 1 #error More than one communication interface selected for FreeMASTER driver. #endif コンパイラは、互換性のない定義がある場合にエラーが発生します。 また、FMSTR_USE_FLEXCANが定義されている場合は、プロジェクトにFMSTR_InitSerialシンボルが生成されないようにする必要があります。 これを確認するには、.map ファイルの内容または .elf ファイル シンボルを調べます。 この出力は、CANの場合に生成されます。 C:\NXP\S32DS.3.5\S32DS\build_tools\gcc_v6.3\gcc-6.3-arm32-eabi\arm-none-eabi\bin>readelf.exe C:\fmstr_rtd_fcan_s32k144\Debug_FLASH\fmstr_rtd_fcan_s32k144.elf -s | find "FMSTR_InitCan" 610: 00000e39 56 FUNC GLOBAL DEFAULT 3 FMSTR_InitCan C:\NXP\S32DS.3.5\S32DS\build_tools\gcc_v6.3\gcc-6.3-arm32-eabi\arm-none-eabi\bin>readelf.exe C:\fmstr_rtd_fcan_s32k144\Debug_FLASH\fmstr_rtd_fcan_s32k144.elf -s | find "FMSTR_InitSerial" 2 番目のコマンドは、空の結果を返します。 クリーンタスクが古いelfファイルを削除しないか、デバッグ構成が完全な再構築をトリガーしない可能性があると思われます。これにより、デバッグ セッションは古いバージョンの elf ファイルを再利用します。 Re:S32DS 3.4のFreeMASTER CAN例S32K144 Dear iulian_stan, プロジェクトには定義が多すぎるようですが、定義が混同されることがありますか? 参照: 私はプロジェクトでUSRTを設定および定義していませんが、定義に含まれているFMSTR_InitSerial()‵を呼び出そうとします。 #if FMSTR_USE_SERIAL /* initialize communication and start listening for commands */ if (!FMSTR_InitSerial()) return FMSTR_FALSE; #endif そして、 'FMSTR_USE_SERIAL'は今= 0です。 #define FMSTR_DISABLE 0 /* ... */ #define FMSTR_USE_LPUART 0 /* !!!!! */ #define FMSTR_USE_FLEXCAN 1 #define FMSTR_USE_PDBDM 0 //... #if (FMSTR_USE_SCI) || (FMSTR_USE_ESCI) || (FMSTR_USE_LPUART) || (FMSTR_USE_JTAG) || (FMSTR_USE_USB_CDC) || (FMSTR_USE_MQX_IO) || (FMSTR_USE_MBED) #ifndef FMSTR_USE_SERIAL #define FMSTR_USE_SERIAL 1 #else #if FMSTR_USE_SERIAL == 0 #error "FMSTR_USE_SERIAL macro cannot be configured by user, FreeMASTER serial driver functionality is not garanted." #endif #endif #else #ifndef FMSTR_USE_SERIAL #define FMSTR_USE_SERIAL 0 #endif #endif Re:S32DS 3.4のFreeMASTER CAN例S32K144 Hi @CY9, 1.これは、FreeMASTERドライバーの新しいバージョンで修正されたバグです。その割り当ては、前の{}ブロックの内側にある必要があります。 if (discard > 0U) { ... /* buffer is for sure not full */ pbuff->flags.flg.bIsFull = 0; pbuff->nRP = rp; } S32K1ファミリのライブラリを更新する予定ですが、現時点ではETAはありません。 2.まず、プロジェクトをクリーンアップし(安全のために、Debug_FLASHフォルダを手動で削除します)、再構築します。問題が解決しない場合は、新しい DS への移行中に、一部のファイルが重複したことを意味します。問題のある関数 (例: SystemInit) を検索すると、プロジェクト ファイル内の定義が重複し、冗長なソース パスが削除されます。 Re:S32DS 3.4のFreeMASTER CAN例S32K144 Dear iulian_stan , CANバスでテストします、それは動作します! よろしくお願いします。 2つの質問があります。 1.   FMSTR_PipeDiscardBytes() { if(discard > 0) { rp = ...; } pbuff->nRP = rp; } So, if (discard<=0) , rp = ?? 2.  S32DS 3.5をダウンロードして、最新のものにアップデートしました。 プロジェクトをクリーンアップして再構築しようとすると、エラーメッセージ: 建物対象:fmstr_rtd_fcan_s32k144.elf 起動時:標準S32DS Cリンカ arm-none-eabi-gcc -o "fmstr_rtd_fcan_s32k144.elf""@fmstr_rtd_fcan_s32k144.args" c:/nxp/s32ds.3.5/s32ds/build_tools/gcc_b1620/gcc-6.3-arm32-eabi/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/bin/real-ld.exeに追加します。./SDK/platform/devices/S32K144/startup/system_S32K144.o: 関数 'SystemInit' 内: D:\Project\TYC\S32DS35\fmstr_rtd_fcan_s32k144\Debug_FLASH/../SDK/platform/devices/S32K144/startup/system_S32K144.c:69: 'SystemInit' の複数の定義; ./SDK/S32K144_SDK_4.0.1/platform/devices/S32K144/startup/system_S32K144.o:D:\Project\TYC\S32DS35\fmstr_rtd_fcan_s32k144\Debug_FLASH/../SDK/S32K144_SDK_4.0.1/platform/devices/S32K144/startup/system_S32K144.c:69:ここで最初に定義 c:/nxp/s32ds.3.5/s32ds/build_tools/gcc_b1620/gcc-6.3-arm32-eabi/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/bin/real-ld.exeに追加します。./SDK/platform/devices/S32K144/startup/system_S32K144.o: 関数 'SystemCoreClockUpdate' 内: D:\Project\TYC\S32DS35\fmstr_rtd_fcan_s32k144\Debug_FLASH/../SDK/platform/devices/S32K144/startup/system_S32K144.c:128: 'SystemCoreClockUpdate' の複数の定義; ./SDK/S32K144_SDK_4.0.1/platform/devices/S32K144/startup/system_S32K144.o:D:\Project\TYC\S32DS35\fmstr_rtd_fcan_s32k144\Debug_FLASH/../SDK/S32K144_SDK_4.0.1/platform/devices/S32K144/startup/system_S32K144.c:128:ここで最初に定義 c:/nxp/s32ds.3.5/s32ds/build_tools/gcc_b1620/gcc-6.3-arm32-eabi/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/bin/real-ld.exeに追加します。./SDK/platform/devices/S32K144/startup/system_S32K144.o: 関数 'SystemSoftwareReset' 内: D:\Project\TYC\S32DS35\fmstr_rtd_fcan_s32k144\Debug_FLASH/../SDK/platform/devices/S32K144/startup/system_S32K144.c:179: 'SystemSoftwareReset' の複数の定義; ./SDK/S32K144_SDK_4.0.1/platform/devices/S32K144/startup/system_S32K144.o:D:\Project\TYC\S32DS35\fmstr_rtd_fcan_s32k144\Debug_FLASH/../SDK/S32K144_SDK_4.0.1/platform/devices/S32K144/startup/system_S32K144.c:179:ここで最初に定義 ......  ビルドに失敗しました。エラーが 57、警告が 5 件。(6秒272msかかった) 何か提案はありますか、ありがとう。 Re:S32DS 3.4のFreeMASTER CAN例S32K144 Hi @CY9,  S32 Design Studioプロジェクトに添付されています。 注: このプロジェクトは S32DS 3.5 および S32SDK 4.0.1 でビルドされました。
記事全体を表示
在 u-boot 中添加 SD/eMMC 设备和主机之间的调试消息。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 有时您会遇到 SD/eMMC 问题:“卡对电压选择没有响应!”。您可以添加调试消息来查看 SD/eMMC 与主机之间的通信。 #定义调试 #定义 CONFIG_MMC_TRACE & 在 mmc.c (driver/mmc) 中添加调试消息 int mmc_send_cmd(结构mmc *mmc,结构mmc_cmd *cmd,结构mmc_data *数据) { .. printf("CMD_SEND:%d\n",cmd->cmdidx); printf("\t\tARG\t\t\t0x%08X\n", cmd->cmdarg); .. } => mmcinfo CMD_SEND:0 阿根廷 0x00000000 MMC_RSP_NONE CMD_SEND:8 ARG                     0x000001AA           MMC_RSP_R1,5,6,7        0x00000001 命令发送:55 阿根廷 0x00000000 MMC_RSP_R1,5,6,7 0x00000001 CMD_SEND:0 阿根廷 0x00000000 MMC_RSP_NONE
記事全体を表示
i.Core M6:基于 i.MX6 的 SOM <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> i.CORE M6S/DL/D/Q i.Core M6S/DL/D/Q 是 Engicam 提供的最新强大的 i.MX6 SOM 解决方案。 i.Core M6 配备 单、双光、 双 或四 Cortex-A9 内核, 是 适用于高端多媒体应用的 最小低成本 SOM。 模块的完全可扩展性允许在很短的时间内创建具有不同性能的多种产品并推向市场。 i.Core M6 系列现已推出 Dual Light 版本以及适用于强大的低成本应用的商业版本。 特性 存储器 适用于 i.Core M6Q 的 1GB 64 位 DDR3-1066 适用于 i.Core M6D 的 512MB 64 位 DDR3-1066 适用于 i.Core M6DL 的 512MB 64 位 DDR3-800 适用于 i.Core M6S 的 256MB 32 位 DDR3-800 256 MB NAND闪存 图形和多媒体 1x并行LCD 18位输出 2个LVDS输出 1个HDMI输出 最多支持四个同时显示驱动( 仅限 i.Core M6Q/D) 最多两个同时显示驱动支持( 仅限 i.Core M6S/DL) 双显示器,最高可达 WUXGA (1920x1200) 和 HD1080 OpenGL/ES 2.x 3D加速器,支持OpenCL/EP和OpenVG1.1加速 多格式 HD1080 视频解码和编码 并行相机接口输入 触摸屏 外设 2个SD卡接口 USB OTG HS、USB HS HOST、Uart、I2C、I2S、PCI Express SATA 3Gbps(仅限 i.Core M6Q/D) 以太网10/100 尺寸 标准 SODIMM 占用空间 67,4x31.9毫米 PCB 尺寸 超薄型模块 ENGICAM - i.Core M6S/DL/D/Q 概述 回复:i.Core M6:基于 i.MX6 的 SOM <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> I.MX6Q核心模块详情 http://www.myzr.com.cn/images/I.MX6_1_en.jpg http://www.myzr.com.cn/images/I.MX6_2_en.jpg
記事全体を表示
LPCファミリ用MRTモジュールによる遅延機能の実装 1 イントロダクション このドキュメントでは、MRT(Multi-rate Timer)モジュールを使用して遅延機能を実装する方法を示しており、遅延時間はプログラム可能です。MRTにはワンショットストールモードがあり、このモードでは、MRTチャネルカウンタがカウントダウンしている間、MRTチャネルカウンタがゼロに達するまでコアがストールします。 MRT チャネル カウンタが 0 に達すると、MRT チャネルはアイドル状態になり、コアは動作し続けます。   2 遅延機能の説明 場合によっては、2つの命令間にプログラム可能な遅延があることが予想されます。 インストラクション1 遅延 インストラクション2 一般に、遅延機能は、コアに__asm ("NOP") 命令を実行させることで実装できます このコードは次のようになります。 ボイド遅延(uint32_tインターバル) { Uint32_tカウンター; Counter=ConvertTimeToCounter(インターバル);        For(uint32_t i=0; i { __asm(「NOP」といいます)        } }   マクロ convertTimeToCounter は、時間をループ数に変換するために使用されます   1. MRTの特徴 LPCファミリのMRTモジュールは、テストがLPC55S69-EVKボードに基づいているため、ワンショットストールモードと呼ばれる独自の機能を提供しているため、セクション27.5.3を参照しましたUM11126.pdfでのワンショットストールモード。 MRTには外部パッドがありません。   ワンショットストールモード: バスストールモードは、2つのソフトウェア制御の間に短い遅延が必要な場合に使用できます イベント、またはソフトウェアを続行する前に遅延が予想される場合。このモードでは MRT がカウントダウンしている間、バス トランザクションは発生せず、CPU コアは停止し、MRT カウンタが 0 に達するまで、その間に最小量の電力を消費します。したがって、MRTのワンショットストールモードは、MRTカウントダウンプロセス中にコアストールを引き起こす可能性があり、遅延機能を実装できます。   3 MRTクロックソースと遅延時間 LPC55S69の場合、MRTモジュールのクロックソースはAHBバスクロックであり、これはコアクロックと同じです。 LPC55S69例では、コア クロックを設定するコードがあります void BOARD_InitBootClocks(void) { BOARD_BootClockPLL150M(); } したがって、MRTのクロック周波数は150MHzです。       遅延時間は時間ですが、MRTはカウンターなので、遅延時間をカウンター値に変換する必要があります。カウンタ値は MRT クロック周波数に依存します。MRT クロック ソースは AHB バス クロック、またはコア クロックです。 LPC55S69コアクロック周波数は150Mhzであるため、 #define MRT_CLOCK_FREQUENCY 150MHz帯 必要な遅延時間が 2 番目の単位で変数delay_time場合、必要な MRT カウンタ値は次のようになります   MRT カウンタ値 = delay_time/(MRT クロック サイクル時間)= delay_time* MRT_CLOCK_FREQUENCY。   たとえば、必要なdelay_timeが 1mS または 1*10**(-3) Second であると仮定すると、対応するカウンタ値は 1*(10**-3)*150*(10**6)=150 000 です   MRT 遅延時間の制限。 MRTカウンタレジスタは24ビットで、最大カウンタ値は2 ** 24 = 16,777,216で、最大遅延時間は16777216 /(150 * 10** 6)= 0.111848Sまたは111mSです。     3 ソースコードの説明 MRT遅延機能のソースコードはSDKパッケージSDK_2_11_1_LPCXpresso55S69.zipに基づいており、ツールは MCUXpresso IDE v11.5.0 です。この例は LPC55S69-EVK で実行されます この例では、MRTを使用して100mS(0.1秒)遅延し、遅延後にLEDが切り替わります MRT カウンタ値は 0.1S*150*(10**6)=15 000 000 です。   mrt_init() api 関数 の場合 、MRT を初期化し、 OneShotStall モードで MRT channel0 を設定します。 コアがラインを実行すると、 MRT_StartTimer(MRT0、 kMRT_Channel_0、15000000);MRTのchannel0カウンタは15000000からカウントダウンし、カウントプロセス中にCortex-M33は失速します。カウンタが ZERO に達すると、コアはストール モードを終了し、次の行の実行を続行すると、MRT channel0 カウンタはアイドル モードになります。 /** ※@file LPC55S69_Project_mrt_stall.c * @brief アプリケーションのエントリ ポイント。  */ #include #include 「ボード.h」 #include 「周辺機器.h」 #include 「pin_mux.h」 #include 「clock_config.h」 #include 「LPC55S69_cm33_core0.h」 #include 「fsl_debug_console.h」 #include 「fsl_mrt.h」 #include 「fsl_iocon.h」 /* TODO: ここに他のインクルードファイルを挿入します。*/ #define BOARD_LED_PORT BOARD_LED_BLUE_GPIO_PORT #define BOARD_LED_PIN BOARD_LED_BLUE_GPIO_PIN /* TODO: ここに他の定義と宣言を挿入します。*/ void mrt_init(void); /* * @brief アプリケーションのエントリ ポイント。  */ int main(void) { /* ボード ハードウェアを初期化 します。*/     BOARD_InitBootPins(); BOARD_InitBootClocks(); BOARD_InitBootPeripherals(); #ifndef BOARD_INIT_DEBUG_CONSOLE_PERIPHERAL /* FSL デバッグ コンソール を初期化 します。*/     BOARD_InitDebugConsole(); #endif mrt_init(); PRINTF("Hello World\n");     for(;;)     { MRT_StartTimer(MRT0、 kMRT_Channel_0、15000000); GPIO_PortToggle(GPIO、BOARD_LED_PORT、1U << BOARD_LED_PIN);     __asm ("nop");     } /* カウンターを強制的にメモリに配置します。*/     volatile static int i = 0 ; /* 無限ループに入り、カウンターをインクリメントするだけです。*/     一方(1) { i ++の; /* 'Dummy' NOP は、ソースレベルのシングルステップを許可します。 タイトなwhile()ループ */         __asm volatile ("nop");     }     return 0 ; } uint32_t mrt_clock; mrt_config_t mrtConfig; void mrt_init(void) {         /* mrtConfig.enableMultiTask = false; */         MRT_GetDefaultConfig(&mrtConfig);         /* Init mrt module */         MRT_Init(MRT0, &mrtConfig); /* チャンネル 0 を繰り返すように設定 */         MRT_SetupChannelMode(MRT0, kMRT_Channel_0, kMRT_OneShotStallMode);         //MRT_StartTimer(MRT0, kMRT_Channel_0,  15000000); }       }                                                                                                              上記のコードが実行されている場合、ユーザーはLPC55S69-EVKボードの青色LEDのトグルを確認できます。LPC55S69-EVKにPIO1_4ピン信号(P18コネクタのピン5)を接続すると、PIO1_4信号のトグル周波数は5Hz、サイクルタイムは200mSなので、遅延は100mSです。     LPC546xx LPC55xx
記事全体を表示
After installing a new RTD package on S32DS Ver.3.5対Ver.3.4など こんにちはS32DSチーム、 2つの質問。 最近、S32DS Ver.について聞かれる方もいらっしゃいます。3.5 振る舞い。 写真1の通り、S32DS版3.5 では RTD パッケージが 1 つしか表示されませんが、Ver 3.4 では一部の RTD パッケージが表示されます。 質問1.この行動は意図的なものだったのか、それとも事故だったのか? 写真1.S32DS版3.5 および Ver.3.4 [バックグラウンド] 通常、S32DS Ver. で古い RTD パッケージと新しい RTD パッケージの階層化されたコードを比較する必要があります。3.5 お客様のために。 ただし、RTD パッケージのインストールとアンインストールには多くの時間がかかります。 例えば、SW32K3_S32M27x_RTD_R21-11_4.0.0_HF01とSW32K3_S32M27x_RTD_R21-11_4.0.0_P20のサンプルコードを比較すると、HF01をアンインストールしてP20をインストールするか、P20をアンインストールしてHF01をインストールするかということになります。 RTDパッケージはできないようです共存する。。。 質問2.私の理解は正しいですか? RTDを頻繁にインストールおよびアンインストールした後、プロジェクトがビルドできない場合がありますが、プロジェクトは以前と同じバージョンでビルドできました... 最悪の場合、すべてを再インストールする必要があります...S32DS、RTDなどをインストールするということです。 よろしくお願いいたします ふみ Eclipse IDEの使用と設定 SDK Re:S32DS版に新しいRTDパッケージをインストールした後3.5対Ver.3.4など Hi @Fumihiko_Sato, はい、新しいインスタンスをインストールする必要があります(同じインストーラーで実行できます)。2 番目のインスタンスをインストールするときは、インストール パスを目的の名前 (例: ...\S32DS_3.5_RTD400) に変更します。そして、あなたは.exeまたは .bat新しいデザインスタジオ内のファイル。 Re:S32DS版に新しいRTDパッケージをインストールした後3.5対Ver.3.4など こんにちは@Julián_AragónM、 ご支援のほど、よろしくお願いいたします。 この値は、インストールでデフォルトのパスを変更するときに、インストーラーが新しいインスタンスのパスで変更する必要があります。 ->ということですか このパスはインストーラーで自動的に変更されますか? .exeインストーラーを使用して新しいインスタンスをインストールする代わりに、構成をコピーしましたか? ->はい。S32DS.3.5(Default)フォルダをコピーし、2つのもの(写真1)を変更しました。      インストーラーを使用してS32DS.3.5_RTD_XXX(2nd)をインストールする必要がありますか? 写真1.変更されたアイテム 敬具 ふみ Re:S32DS版に新しいRTDパッケージをインストールした後3.5対Ver.3.4など Hi @Fumihiko_Sato, この値は、インストールでデフォルトのパスを変更するときに、インストーラーが新しいインスタンスのパスで変更する必要があります。 新しいインスタンスを .exe でインストールする代わりに、構成をコピーしましたかインストーラ。 Re:S32DS版に新しいRTDパッケージをインストールした後3.5対Ver.3.4など こんにちは@Julián_AragónM、 ご確認いただきありがとうございます。 あなたのアドバイスには十分ではなかったので、私はいくつかの項目を調査して修正しました。 うまくいっているようですが、1つ質問があります(写真1参照)。 この問題は、「s32ds.exe」ファイルを直接開いたときにも発生しますか? ->はい。s32ds.exeとs32ds.batで同じ結果が得られました。 これは両方のインスタンスで発生しますか (S32DS.3.5_RTDxxx と S32DS.3.5)? ●> No.コピーされた S32DS.3.5_RTDxxx。 S32DS.3.5は正しく動作します。 参考までに ステップ1. S32ds.iniに2行追加 -vm C:\NXP\S32DS.3.5_RTD_XXX\eclipse\jre\bin\javaw.exe ステップ2.jreフォルダを2種類のフォルダにコピー&ペースト 1.C:\NXP\S32DS.3.5_RTD_XXX\S32DS\tools\S32FlashTool\GUI 2.C:\NXP\S32DS.3.5_RTD_XXX\eclipse 写真1.私が何をしたのか、そして一つの疑問が浮かび上がってきました。 写真2.jreフォルダを2種類のフォルダにコピー&ペースト Best, Fumi Re:S32DS版に新しいRTDパッケージをインストールした後3.5対Ver.3.4など Hi @Fumihiko_Sato, Javaの問題を調べると、javaw.exeパスが認識されていないようです。この問題は「s32ds.exe」を開くときにも発生しますか直接ファイルしますか?これは両方のインスタンス (S32DS.3.5_RTDxxx と S32DS.3.5) で発生しますか? 次の 2 行を行の直前に追加し  -vmargs  パスを Java 11 以降の 64 ビット Java VM インストール ディレクトリに適合させると、この問題を解決できる場合があります。 -vm C:\NXP\S32DS.3.5_RTD_4.0.0\eclipse\jre\bin\javaw.exe (or java.exe)  Best regards, Julián Re:S32DS版に新しいRTDパッケージをインストールした後3.5対Ver.3.4など こんにちは@Julián_AragónM、 2nd S32DS Ver.3.5環境を準備していますが、s32ds.batを実行した後にJVM(JAVA???)のメッセージが表示されました。  1番目のC:\ NXP \ S32DS.3.5  2位 C:\NXP\S32DS.3.5_RTDxxx あなたはそれを解決する方法を知っていますか? De 「s32ds.ini」を変更する必要があります? Best, Fumi Re:S32DS版に新しいRTDパッケージをインストールした後3.5対Ver.3.4など こんにちは@Julián_AragónM、 なるほど。 ありがとうございました ふみ Re:S32DS版に新しいRTDパッケージをインストールした後3.5対Ver.3.4など Hi @Fumihiko_Sato, これはまだ解決されておらず、残念ながら、この特定の修正のリリース予定日はありません。 ご不便をおかけして申し訳ございません。 Best regards, Julián Re:S32DS版に新しいRTDパッケージをインストールした後3.5対Ver.3.4など こんにちは、@Julián_AragónM &@jiri_kral、 迅速な返信ありがとうございます! わかります。 あなたのチームは更新されたS32DS Ver 3.5 xxをリリースする予定はありますか? 最良 ふみ Re:S32DS版に新しいRTDパッケージをインストールした後3.5対Ver.3.4など Hi @Fumihiko_Sato, はい、Jiriの回答に追加するために、現在最も適切な回避策は、S32DSのさまざまなインスタンスをインストールすることです。 C:\NXP\S32DS.3.5_RTD300\ C:\NXP\S32DS.3.5_RTD400\ 次に、各インスタンスに特定の RTD をインストールします。 次に、s32ds.batファイルをショートカットとして追加するだけです。 Best regards, Julián Re:S32DS版に新しいRTDパッケージをインストールした後3.5対Ver.3.4など Hi,  これは JIRA にすでにログインしている既知の問題です。たとえば、S32DS v3.5 では、RTD v4.0.0 は既存のインストール済み RTD v3.0.0 を書き換えます。 一時的な回避策として、RTD バージョンが異なる S32DS v3.5 の 2 つのインスタンスを使用できます。
記事全体を表示
NXPマイクロコントローラ付きUSB <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> はじめに ユニバーサルシリアルバス(USB)は、今日のパーソナルコンピューティングで最も成功したインターフェイスです。高速で信頼性が高く、使いやすいこのインターフェイスは、パーソナルコンピュータ、コンピュータ周辺機器、モニタ、モバイルデバイス、オーディオおよびビデオ機器、その他ほとんどの家電製品など、あらゆる場所で見つけることができます。   NXPは、Cortex-M4、Cortex-M3、Cortex-M0、ARM9、およびARM7マイクロコントローラに80以上のオプションを提供するUSB搭載ARMマイクロコントローラで市場をリードしています(以下の比較表と製品を参照)。NXPの高速およびフルスピードのデバイス/ホスト/OTG USB対応マイクロコントローラのポートフォリオは、特別なUSB機能(オンチップHS PHYおよびROMドライバなど)、フリーソフトウェア、および包括的なサポートを提供し、設計コンセプトから生産への迅速な移行を支援します。   TechOnLine Rapid USB development on Cortex-M microcontrollers ウェビナー (2011年9月7日) NXPの利点 NXPのマイクロコントローラポートフォリオは、フルスピードおよびハイスピードのUSB 2.0デバイス、ホスト、On-The-Go(OTG)機能など、最新のUSB技術を備えています。NXPは、制御、割り込み、バルク、特にストリーミングオーディオに必要なアイソクロナスの4つの転送タイプすべてをサポートしています。NXPのMCUは、設計者にさまざまな特別なUSB機能を提供し、全体的なパフォーマンスを向上させ、市場投入までの時間を短縮します。 完全認証済みUSB製品 オンチップROMドライバ ハイスピードおよび/またはフルスピードPHYを内蔵 無料のUSBホストおよびデバイスソフトウェア 追加のUSB機能 完全認証済みUSB製品 NXPは、USB仕様を維持し、USBコンプライアンスを検証する組織であるUSB-IFの主要メンバーです。NXPのUSB搭載ARM MCUは認証申請中であるため、設計者は、自社のシステムが最高の信頼性とプラグアンドプレイ動作を提供することを確信できます。2008年末の時点で、ホストおよびデバイス機能を備えたUSB 2.0ベースのプロセッサのほとんどが認定されています。OTG 機能は処理中です。準拠製品の完全なリストは、USB-IFのWebサイトに掲載されています。 www.usb.org. オンチップUSB ROMドライバ NXPのオンボードUSB ROMドライバは、USBスタック、USBクラス、および低レベルドライバ全体をマイクロコントローラのROMに詰め込むため、この複雑なソフトウェアを自分で開発およびデバッグする必要がなくなります。USBドライバをROMに配置すると、貴重なメモリスペースが解放され、アプリケーションに使用できます。これらのドライバは、NXPおよび外部のテストハウスによって徹底的にテストされており、USB-IFの厳格なテスト要件に合格した後、USBロゴ認証を取得するために使用されます。 ハイスピードおよび/またはフルスピードPHYを内蔵 フルスピードまたはハイスピードPHYはNXPのUSBマイクロコントローラに統合されており、インターフェースのデジタル部分と変調部分の間のブリッジを提供します。マイコンにPHYを統合することで、部品のコストが節約され、システム設計が簡素化されます。たとえば、LPC1800 および LPC4300 マイクロコントローラは、2 チャネルの High-Speed USB 2.0 Host/Device/OTG をサポートし、オンチップの High-Speed PHY を備えています。 無料のUSBホストおよびデバイスソフトウェア USB開発は、高価で難しいものである必要はありません。時間とコストを節約するために、NXPは、複数のツールチェーンですぐに使用できるホストモードとデバイスモード用の完全なUSBサンプルアプリケーションを提供しています。NXP独自の無料USBパッケージに加えて、NXPは主要なソフトウェア会社と提携して、最先端のUSBファームウェアを提供しています。USBソフトウェアオプションの完全なリストについては、このページ のサポートセクションを参照してください 。 追加のUSB機能 NXPのその他のUSB機能には、次のものがあります。 ホストコントローラはOHCI/EHCIに準拠しています。 専用のDMAにより、USBインターフェースは最小限のCPU介入で動作できます。 SoftConnect™は、ソフトウェアを使用して、USBデバイスがバスに接続するタイミングを決定します。 GoodLink™は、USBデバイスがバス上で列挙および設定されたことを示すためにLEDを使用します。(電力を節約するため、サスペンド中はLEDが消灯します。 ダブルバッファリングは、バルクエンドポイントとアイソクロナスエンドポイントのスループットを最大化します。 複数の USB ポートを使用すると、デバイスをホスト、デバイス、またはその両方として構成できます。 USBデータバッファは、エンドポイントのFIFOサイズを柔軟に構成できます。 製品 NXPは、Cortex-M0、Cortex-M3、Cortex-M4、ARM9、およびARM7マイクロコントローラ向けに80を超えるUSB MCUオプションを提供しています(以下の比較表と製品を参照)。NXP MCUの特別なUSB機能には、次のものがあります。 比較表 コア 製品 オンチップコントローラ いいえ。Cntrlsの いいえ。ポート数 オンチップPHY 折り紙付き デバイス ホスト OTG ARM7TDMI-S LPC2141 FS - - 1 1 デバイス FS LPC2142 FS - - 1 1 デバイス FS LPC2144 FS - - 1 1 デバイス - LPC2146 FS - - 1 1 デバイス - LPC2148 FS - - 1 1 デバイス FS LPC2158 FS - - 1 1 デバイス - LPC2361 FS FS FS 1 1 デバイス、ホスト FS LPC2362 FS FS FS 1 1 デバイス、ホスト FS LPC2364 FS - - 1 1 デバイス FS LPC2366 FS - - 1 1 デバイス FS LPC2368 FS - - 1 1 デバイス FS LPC2378 FS - - 1 1 デバイス FS LPC2387 FS FS FS 1 1 デバイス、ホスト FS LPC2388 FS FS FS 1 2 デバイス、ホスト FS LPC2420 FS FS FS 1 2 デバイス、ホスト - LPC2458 FS FS FS 1 2 デバイス、ホスト - LPC2460 FS FS FS 1 2 デバイス、ホスト - LPC2468 FS FS FS 1 2 デバイス、ホスト FS LPC2470 FS FS FS 1 2 デバイス、ホスト - LPC2478 FS FS FS 1 2 デバイス、ホスト - LPC2880 HS - - 1 1 デバイス HS LPC2888 HS - - 1 1 デバイス HS ARM720T LH79524 FS - - 1 1 デバイス - LH79525 FS - - 1 1 デバイス - ARM922T LH7A404 FS FS - 1 3 (2 ホスト) デバイス、ホスト - LH7A400 FS - - 1 1 デバイス - ARM968の LPC2921 FS - - 1 1 デバイス - LPC2923 FS - - 1 1 デバイス - LPC2925 FS - - 1 1 デバイス - LPC2926 FS FS 1 1 デバイス LPC2927 FS - FS 1 1 デバイス - LPC2929 FS - FS 1 1 デバイス FS LPC2930 FS FS FS 1 2 デバイス、ホスト - LPC2939 FS FS FS 1 2 デバイス、ホスト - ARM926EJ-S LPC3180/01 FS FS FS 1 1 - - LPC3220 FS FS FS 1 1 - - LPC3230 FS FS FS 1 1 - - LPC3240 FS FS FS 1 1 - - LPC3250 FS FS FS 1 1 - - LPC3130 HS HS HS 1 1 デバイス、ホスト、OTG - LPC3131 HS HS HS 1 1 デバイス、ホスト、OTG HS LPC3151 HS HS HS 1 1 デバイス、ホスト、OTG - LPC3152 HS HS HS 1 1 デバイス、ホスト、OTG HS LPC3153 HS HS HS 1 1 デバイス、ホスト、OTG - LPC3154 HS HS HS 1 1 デバイス、ホスト、OTG - コーテックス-M3 LPC1342 FS - - 1 1 デバイス FS LPC1343 FS - - 1 1 デバイス FS LPC1345 FS - - 1 1 デバイス - LPC1346 FS - - 1 1 デバイス - LPC1347 FS - - 1 1 デバイス - LPC1547 FS - - 1 1 デバイス - LPC1548 FS - - 1 1 デバイス - LPC1549 FS - - 1 1 デバイス FS LPC1751 FS - - 1 1 デバイス FS LPC1752 FS - - 1 1 デバイス - LPC1754 FS FS FS 1 1 デバイス、ホスト - LPC1756 FS FS FS 1 1 デバイス、ホスト - LPC1758 FS FS FS 1 1 デバイス、ホスト - LPC1759 FS FS FS 1 1 デバイス、ホスト - LPC1764 FS - - 1 1 デバイス - LPC1765 FS FS FS 1 1 デバイス、ホスト - LPC1766 FS FS FS 1 1 デバイス、ホスト - LPC1768 FS FS FS 1 1 デバイス、ホスト FS LPC1769 FS FS FS 1 1 デバイス、ホスト - LPC1774 FS - - 1 1 デバイス - LPC1776 FS FS FS 1 1 デバイス、ホスト - LPC1777 FS FS FS 1 1 デバイス、ホスト - LPC1778 FS FS FS 1 1 デバイス、ホスト - LPC1785 FS FS FS 1 1 デバイス、ホスト - LPC1786 FS FS FS 1 1 デバイス、ホスト - LPC1787 FS FS FS 1 1 デバイス、ホスト - LPC1788 FS FS FS 1 1 デバイス、ホスト - LPC1820 HS HS HS 1 1 デバイス、ホスト - LPC1822 HS HS HS 1 1 デバイス、ホスト - LPC1823 HS HS HS 1 1 デバイス、ホスト - LPC1825 HS HS HS 1 1 デバイス、ホスト - LPC1827 HS HS HS 1 1 デバイス、ホスト - LPC1830 HS HS HS 2 2 デバイス、ホスト - LPC1833 HS HS HS 2 2 デバイス、ホスト - LPC1837 HS HS HS 2 2 デバイス、ホスト FS LPC1850 HS HS HS 2 2 デバイス、ホスト FS LPC1853 HS HS HS 2 2 デバイス、ホスト FS LPC1857 HS HS HS 2 2 デバイス、ホスト FS Cortex-M4 LPC4072 FS FS FS 1 2 デバイス、ホスト、OTG - LPC4074 FS FS FS 1 2 デバイス、ホスト、OTG - LPC4076 FS FS FS 1 2 デバイス、ホスト、OTG - LPC4078 FS FS FS 1 2 デバイス、ホスト、OTG - LPC4088 FS FS FS 1 2 デバイス、ホスト、OTG - LPC4320 HS HS HS 1 1 デバイス、ホスト、OTG - LPC4320 HS HS HS 1 1 デバイス、ホスト、OTG LPC4322 HS HS HS 1 1 デバイス、ホスト、OTG - LPC4323 HS HS HS 1 1 デバイス、ホスト、OTG - LPC4325 HS HS HS 1 1 デバイス、ホスト、OTG - LPC4327 HS HS HS 1 1 デバイス、ホスト、OTG - LPC4330 HS HS HS 2 2 デバイス、ホスト、OTG - LPC4333 HS HS HS 2 2 デバイス、ホスト、OTG - LPC4337 HS HS HS 2 2 デバイス、ホスト、OTG - LPC4350 HS HS HS 2 2 デバイス、ホスト、OTG - LPC4353 HS HS HS 2 2 デバイス、ホスト、OTG - LPC4357 HS HS HS 2 2 デバイス、ホスト、OTG - コーテックス-M0 LPC11U12 FS - - 1 1 デバイス - LPC11U13 FS - - 1 1 デバイス - LPC11U14 FS - - 1 1 デバイス FS LPC11U23 FS - - 1 1 デバイス - LPC11U24 FS - - 1 1 デバイス LS, FS LPC11U34 FS - - 1 1 デバイス - LPC11U35 FS - - 1 1 デバイス - LPC11U36 FS - - 1 1 デバイス - LPC11U37 FS - - 1 1 デバイス FS LPC11U37H FS - - 1 1 デバイス - Cortex-M0+ LPC11U67 FS - - 1 1 デバイス - LPC11U68 FS - - 1 1 デバイス LS, FS サポート ソフトウェア CMX-USBデバイススタック(CMX Systems製) CMX-USBホストスタック(CMX Systems製) emUSBデバイススタック(SEGGER製) EUSBD(Embedded USB Device)スタック(HCC-Embedded製) EUSBH(組み込みUSBホスト)スタック(HCC-Embeddedによる) I2S - USBオーディオデモ (2007年10月19日)   OT-USB USBデバイス/ホスト/OTGスタック(OnChip Technologies製) smxUSBD デバイススタック (Micro Digital 製) smxUSBHホストスタック(Micro Digital製) smxUSBO OTGソフトウェア(Micro Digital製) μC/USBデバイススタック(Micrium製) μC/USBホストスタック(Micrium製) LPC214x用USBオーディオデバイス例(Keilによる) (2006年2月6日) LPC23xx/LPC24xx の USB オーディオ デバイスの例 (by Keil) (2007年6月19日) USBデバイススタック(Thesycon製) USBホストスタック(Thesycon製) LPC214x用USBヒューマンインタフェースデバイス(HID)の例(IARシステムズ製) (2005年8月11日) LPC214xのUSBヒューマンインターフェースデバイス(HID)の例(Keilによる)( 2006年2月6日) LPC23xx/LPC24xx の USB ヒューマン インターフェイス デバイス (HID) の例 (by Keil) (2007年6月19日) LPC214x用USBマスストレージデバイス例(Keil著) (2006年2月6日) LPC23xx/LPC24xx用USBマスストレージデバイス例(Keil著) (2007年6月19日)   NXP LH7A404 用 Windows Embedded CE BSP (Adeneo) Windows Embedded CE BSP for NXP LPC3180 (Adeneo) NXP LPC32x0 用 Windows Embedded CE BSP (Adeneo) アプリケーション・ノート AN10703 NXP USBホストライト V1 (2008年7月14日) 記事 ARM7 μCs の真のフルスピード USB 機能 (電子製品) (2005 年 8 月) Cortex-M0ベースのMCUは柔軟なUSBポートを備えています(電子製品) (2011年4月11日) リンク     株式会社USBインプリメンターズフォーラム
記事全体を表示
示例 XPC564AKIT PinToggleStationery CW210 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ******************************************************************************** * 详细说明: * 应用程序执行基本初始化,将 PLL 设置为最大允许频率, * 初始化中断,通过中断闪烁一个 LED,通过软件闪烁第二个 LED * 循环,初始化并通过 UART 终端显示通知,然后通过终端 ECHO 显示通知。 * 该示例将设备配置为实现最佳性能(OPTIMIZATIONS_ON)。 * 对于 XPC564AKIT324S,它会初始化已安装的外部 SRAM 的 EBI。 * 其目的是提供除 CW 文具之外的高级启动代码。 * ------------------------------------------------------------------------------ * 测试硬件:XPC564AKIT208S 和 XPC564AKIT324S * MCU:SPC5644AMMG1,0M14X 和 SPC5644AMVZ1,0M14X *系统频率:150/132/120/12 MHz * Debugger:       Lauterbach Trace32 *                 PeMicro USB-ML-PPCNEXUS * 目标:RAM、internal_FLASH * 终端:19200-8-无奇偶校验-1 停止位-eSCI_A 上无流量控制 * EVB连接:默认 * ********************************************************************************   注意:它不能与 MPC5642A 设备一起使用,只能与 MPC5644A 和 MPC5643A 一起使用!   对于 MPC5642A 设备,请使用以下项目代替附加项目: 示例 XPC5642AKIT PinToggleStationery CW10.6 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ******************************************************************************** * 详细说明: * 应用程序执行基本初始化,将 PLL 设置为最大允许频率, * 初始化中断,通过中断闪烁一个 LED,通过软件闪烁第二个 LED * 循环,初始化并通过 UART 终端显示通知,然后通过终端 ECHO 显示通知。 * 该示例将设备配置为实现最佳性能(OPTIMIZATIONS_ON)。 * 对于 XPC564AKIT324S,它会初始化已安装的外部 SRAM 的 EBI。 * 其目的是提供除 CW 文具之外的高级启动代码。 * ------------------------------------------------------------------------------ * 测试硬件:XPC564AKIT208S 和 XPC564AKIT324S * MCU:SPC5644AMMG1,0M14X 和 SPC5644AMVZ1,0M14X *系统频率:150/132/120/12 MHz * Debugger:       Lauterbach Trace32 *                 PeMicro USB-ML-PPCNEXUS * 目标:RAM、internal_FLASH * 终端:19200-8-无奇偶校验-1 停止位-eSCI_A 上无流量控制 * EVB连接:默认 * ********************************************************************************   注意:它不能与 MPC5642A 设备一起使用,只能与 MPC5644A 和 MPC5643A 一起使用!   对于 MPC5642A 设备,请使用以下项目代替附加项目: 示例 XPC5642AKIT PinToggleStationery CW10.6 概述 回复:示例 XPC564AKIT PinToggleStationery CW210 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> CW10.6 现已涉及附加的 ZIP 文件。 回复:示例 XPC564AKIT PinToggleStationery CW210 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi David, 谢谢你的代码。我想在 CW 10.6 下运行这个项目。我计划为 MPC5644A 创建一个项目,剥离其内容并导入相应的文件(.c、.h、您的项目的 .lcf 文件,因为导入器无法处理目标配置。 有什么理由不这么做吗? 此致, Martin
記事全体を表示
Make it Challenge @ FTF 2012 (英語) <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Added by Joe Grand 日時 2012年6月21日
記事全体を表示
i.MX8Mオーディオシステムの使い方 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> NXP i.MX 8Mは、民生用家庭用オーディオから産業用ビルオートメーション、モバイルコンピュータまで、業界をリードするオーディオ、音声、ビデオ処理を提供します。 i.MX 8M Quadは、以下に示す複数のオーディオインターフェイスをサポートしています。 一般的なオーディオ入出力機能に加えて、オーディオインターフェイスは次の機能をサポートします。 - SAI-1は、384KHz/32ビットで最大16チャンネルのTX(8レーン)と16チャンネルのRX(8レーン)をサポートします。 - SAI-5は、384KHz / 32ビットで最大8チャンネルのTX(4レーン)と8チャンネルのRX(4レーン)をサポートします。 - SAI-2/3/6は、384KHz/32ビットで最大2チャンネルTX(1レーン)と2チャンネルRX(1レーン)をサポートします。 - SAI-2/3/6は、384KHz/32ビットで最大2チャンネルTX(1レーン)および2チャンネルRX(1レーン)をサポートします。 - SAI-1は、一般的なオーディオDACのPCMとDSD操作間のグルーレス切り替えをサポートします - SPDIF-1/2は、すべての入力ビットをオーディオバッファに保存できるRAWキャプチャモードをサポートしています SAI-1/2/3/5/6 と SPDIF-1 は、IOMUX を介してチップ上の GPIO パッドを共有します。オーディオインターフェースがサポートする一般的な使用例を次の表に示します(他にも多くの設定が可能です)。番号は、サポートされているデータレーンです。 各 SAI モジュールの MCLK ピンは、入力または出力として構成できます。出力として構成されている場合、CCM からのSAI_CLK_ROOTはパッド出力にルーティングされます。入力として構成すると、パッドへの外部入力は SAI にルーティングされます。MCLKは、SAIのマスタークロックとして使用できます。次の図は、SAI1を例に、両方の入力/出力オプションを示しています。 各 SAI モジュールは、最大 3 つのマスター クロック入力をサポートします。各 SAI 内の TX および RX サブモジュールは、クロック入力の 1 つをマスター クロックとして個別に選択できます。これにより、1 つの SAI の TX と RX を異なるクロック ソースから実行できます。マスタークロック入力には、次のオプションがあります。 -サイ。MCLK[1]は、CCMまたはSAIのSAI_CLK_ROOTから選択できます。IOMUXのMCLK。これは、SAI が CCM または IO パッドからの独自のクロック ソースのみを使用する、最も簡単なクロック ルーティングです。 -サイ。MCLK[2] は、次のクロック ソースから選択できます。 CCMからのSAI_CLK_ROOTのいずれか。 SAIのいずれか。IOMUXのMCLK。 SPIDFからの他のクロックソース。 -サイ。MCLK[3] には、SAI とまったく同じクロック ソース オプションがあります。MCLK[2]。これにより、TX と RX の両方が、相互に依存することなくすべてのオプションにアクセスできます。 SAI のマスター クロックのクロック オプションは、SAI-1 を例に図に示しています。 MCLK[1]のオプションは、MCLK[2]とMCLK[3]でも利用可能です。このオプションを保持する理由は、i.MX6/i.MX7 プロセッサと同様の SAI クロック構造を提供するためです。マスタークロックのMUXの構成は、IOMUXC_GPRレジスタによって制御されます。クロックの不具合を避けるために、SAI クロックを有効にする前に設定する必要があります。 注 : これらの MUX オン クロックは設計中に欠落するため、シリコンでの実際のインプリメンテーションは次の図に示すように簡略化されます。 すべての SAI インスタンスと SPDIF インスタンスは SDMA をサポートしています。オーディオデータレートを満たすために、2つのSDMAモジュールが使用されます。 SAI-2/3 と SPDIF-1/2 は高いデータスループットを必要としないため、UART/SPI などの他のペリフェラルと共有される SDMA-1 に割り当てられます。SAI-1/4/5/6は、高いサンプルレートとマルチチャンネルオーディオをサポートする必要があり、オーディオ専用のSDMAエンジンであるSDMA-2に割り当てられています。SDMA-2 の周波数は、十分なスループットを確保するために、133/66 ではなく 500/250 に増加しています。 SWがオーディオDMAの進行状況を追跡できるようにするために、SAIモジュールのTX_SYNCとRX_SYNCは外部クロック入力としてGPTにルーティングされます。合計6つのSAIモジュールがあるため、GPTに接続するときにこれらの信号は多重化されます。 - GPT-4/5/6外部クロック入力は、任意の6つのSAIモジュールのTX_SYNCまたはRX_SYNCから選択できます。 - マルチプレクサ選択はレジスタによって制御されIOMUXC_GPR。 - GPT-4/5/6 の MUX セレクト レジスタは、互いに完全に独立しています。 Re:i.MX8Mオーディオシステムの使用 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ありがとうシャオコンフー
記事全体を表示