Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
Installing MCUXpresso IDE and SDK (Japanese blog) 0. What is this article about? NXP's software development environment for microcontrollers, MCUXpresso , and its SDK are provided free of charge, and anyone can easily install it and start running sample code right away .😃 This blog post will show you step-by-step how to install the MCUXpresso IDE and SDK. * In this article, we will use FRDM-MCXA153 as the example board. We have released a video explaining the installation procedure. You can watch it from this link .   table of contents 0. What is this article about? 1. What is MCUXpresso IDE? 2. Log in to nxp.com 3. Installing MCUXpresso IDE 4. Installing the SDK 4.1 Starting the MCUXpresso IDE and the Workspace 4.2 SDK Installation Procedure 4.3 Ready! 5. Bonus: To test the operation of the circuit board as is... Reference materials 1. What is MCUXpresso IDE? The various sample codes for general-purpose microcontrollers provided by NXP are designed to run on MCUXpresso , a software development environment provided free of charge by NXP. MCUXpresso comes in two versions: " MCUXpresso IDE (hereinafter referred to as IDE)" and " MCUXpresso VisualStudio Code (hereinafter referred to as VSC)." IDE is an application that combines all functions into one. VSC is provided as a plugin for VisualStudio Code provided by Microsoft. In this blog, we will introduce how to install the IDE and SDK . The IDE runs on Windows, macOS, and Linux, and can be operated with the same user interface on all operating systems. To try out the sample code that runs on MCUXpresso, you must first install the IDE and then install the SDK for the microcontroller/board (target) that you want to run the code on. IDE stands for Integrated Development Environment , and is an integrated development environment application. This application includes an editor for editing source code, a toolchain such as a compiler and linker, and software that organizes code into projects and manages them together with various settings. SDK stands for Software Development Kit and contains the driver code and configuration information required for each microcontroller chip. The SDK must be installed for each microcontroller chip or board (target) you wish to create. Let's take a step-by-step guide on how to install these. This article uses macOS as an example, but the installation can be done on Windows and Linux using almost the same steps. 2. Log in to nxp.com To perform the following steps, you must first log in to nxp.com . If you don't have an nxp.com account yet, please register first and then log in. How to register for a MyNXP account 3. Installing MCUXpresso IDE Download the IDE installer from the MCUXpresso IDE download site . This download requires user registration on nxp.com, so if you haven't done so yet, please do so in advance. Go to the MCUXpresso IDE download site and press the "Download" button . The page will scroll and a link button to the download page will appear. Press this "Download" button . Click the MCUXpresso IDE link . The terms of use will be displayed. If there are no problems, press the "I Agree" button . Select the installer that matches your operating system and click the link . If you are downloading a Linux installer, download the file with the extension ".deb.bin". If you are downloading a Windows installer, download the file with the extension ".exe". The extension for macOS is “.pkg,” but note there are 2 types: Download “macOSX - aarch64” for a Mac equipped with an M1 or later M series (Arm) processor, or “macOSX - 86-64” for a Mac equipped with an Intel CPU. * If the version number is different, please adjust as needed. Once the download is complete, launch the installer and follow the instructions to complete the installation.   4. Installing the SDK   4.1 Starting the MCUXpresso IDE and the Workspace Once the installation of MCUXpresso IDE is complete, start MCUXpresso IDE . In macOS, after startup, it will ask you where you want to set your workspace ( around 2:49 in the guide video ). A workspace is a folder where you perform your work. By default, a new folder will be created inside the "Documents" folder within the user's folder. * The image below shows an example of the default settings. In this example, the user is named "demo," so the path is specified as "/Users/demo/...". You can create a workspace (folder) anywhere within your user folder. In the example below, a folder named "mcux" is created within the user folder, and a workspace named "project0" is created inside it. 4.2 SDK Installation Procedure Once you launch the application (after launching and specifying the workspace), a welcome screen like the one shown below will appear . Click on "Download and Install SDKs" within this screen. After querying the server for a while, the display will look like the one below. In this default display state, the right and bottom parts of the display are hidden, so you will need to enlarge the window size or scroll the display as needed. Expand the window size to secure the display area Enter the model number of the board or microcontroller you are using in the search field at the top right of the display. Here, we will use the FRDM-MCXA153 as an example, so we entered "A153". As a result, the FRDM-MCXA153 board was displayed as a candidate. When you select the FRDM-MCXA153 board , the "Install" button will be highlighted, so click on it. A dialog box will appear during installation. Once the installation is complete, you will be returned to the welcome screen. Close this display by clicking the tab's close button . This will be the default display state of the IDE. The installed SDKs are displayed in the Installed SDKs tab in the bottom center pane. 4.3 Ready! Now you're ready to go! In the "Project Explorer" in the upper left pane, you can create a new project or import and run a project from the SDK, GitHub, or a downloaded project. 5. Bonus: To test the operation of the circuit board as is... The SDK includes sample code . So far we have installed the SDK using the FRDM-MCXA153 as an example, so we will try out the sample code included. First, connect the board to the computer with a USB cable. For the FRDM-MCXA153, use the USB connector labeled "MCU-Link" (see photo). In the upper left pane of the IDE, click "Import SDK example(s)..." in the Project Explorer tab . The installed SDK will be displayed, so click "Next>" . A list of sample code will be displayed . An example of a blinking LED (= blinking L) can be found in " driver_examples " → " gpio " → " gpio_led_output ", so follow the hierarchy as shown below , check the boxes, and press the "Finish" button . The sample code has been imported . Click the blue bug icon (Start debugging project) . A dialog box for selecting the target will appear, so check the displayed board information and press the " OK " button. The code is built and written to the microcontroller's flash memory. The code is then paused and ready to run . Clicking on the icon consisting of a yellow square and a green triangle (Resume) will run the code on the board. This sample code alternately outputs HIGH and LOW to a GPIO (General Purpose Input/Output) pin. This pin is connected to a red LED , so the LED blinks . Reference materials Explainer video: Let's begin! MCUXpresso IDE Related information: Installing MCUXpresso for VSC and SDK (Japanese blog) Change history: 2025-05-07: First Edition 2025-06-26: Added the section "Logging in to nxp.com". 2025-10-28: Link correction 2025-11-10: Link updated 2025-11-14: Added a link to an installation procedure video / Added a section for reference materials. 2025-11-18: Added annotations to the opening image and the circuit board used. Changed the video link image. 2026-03-17: Corrected the diagram in the section "What is MCUXpresso IDE?". 2026-04-05: Added the section "Starting the MCUXpresso IDE and Workspace". 2026-07-24: Added chapter numbers and table of contents. Emphasized video introduction links within "0. What is this article about?".  ========================= We are currently unable to respond to comments in the "Comment" section of this post. We apologize for the inconvenience, but when making inquiries, please refer to `` Technical Questions to NXP - How to Contact Us( Japanese Blog) ''. (If you are already an NXP distributor or have a relationship with NXP, you may ask the person in charge directly.) MCUXpresso IDE can be used free of charge for software development for NXP's MCX series microcontrollers. Also, sample code that can be used with various MCUXpresso IDEs is provided. Here we will explain the installation procedure for the IDE and SDK. After reading this, anyone can easily install the development environment and SDK and even run the sample code! General Purpose Microcontrollers MCUXpresso MCUXpresso IDE MCX Japanese blog
View full article
MCUXpresso IDEとSDKのインストール (日本語ブログ) 0. この記事は? NXPのマイコン用ソフトウェア開発環境MCUXpressoとそのSDKは無料で提供されていて,誰でも簡単にインストール可能!すぐにサンプル・コードを動かしてみることができます.😃 このブログ記事は,MCUXpresso IDEとSDKのインストール方法をステップ・バイ・ステップで紹介します. ※ この記事では使用する基板の例としてFRDM-MCXA153を使います インストール手順の解説動画を公開しました.視聴はこちらのリンクから.   目次 0. この記事は? 1. MCUXpresso IDEって? 2. nxp.comへのログイン 3. MCUXpresso IDEのインストール 4. SDKのインストール 4.1 MCUXpresso IDEの起動とワークスペース 4.2 SDKのインストール手順 4.3 準備完了! 5. おまけ:このまま基板の動作を試してみるには 参考資料 1. MCUXpresso IDEって? NXPが提供している汎用マイコンの各種サンプル・コードは,NXPが無料で提供するソフトウェア開発環境:MCUXpressoで動作するように作られています. このMCUXpressoには「MCUXpresso IDE (以下IDE)」と「MCUXpresso VisualStudio Code (以下VSC)」の2種類があり,IDEはすべての機能をひとつにまとめたアプリケーション.VSCはMicrosoft社が提供するVisualStudio Codeのプラグインとして提供されています. このブログではこの2種類のうち,IDEとSDKのインストールの方法を紹介します. IDEはWindows,macOS,Linuxで動作し,いずれのOSでも同じユーザ・インターフェースでの操作が可能です. MCUXpressoで動作するサンプル・コードを試してみるには,まずその準備としてIDEをインストールし,さらに動作させるマイコン/基板(ターゲット)のSDKをインストールしておかなければなりません. IDEはIntegrated Development Environmentの略で,統合開発環境アプリケーションです.このアプリケーションにはソースコードを編集するエディタをはじめ,コンパイラやリンカといったツールチェーン,コードをプロジェクト単位にまとめて,さまざまな設定と一緒に管理してくれるソフトウェアなどが含まれています. SDKはSoftware Development Kitの略で,マイコン・チップ毎に必要なドライバ・コード,設定情報が含まれています.SDKは作成しようとするマイコン・チップや基板(ターゲット)ごとにインストールしておかなければなりません. ではこれらのインストール方法をステップごとに解説しましょう. この記事はmacOSを用いた例となっていますが,WindowsやLinuxでもほぼ同じ操作でインストールできます. 2. nxp.comへのログイン これ以降の作業を行うには,あらかじめnxp.comにログインしておかなくてはなりません. もしまだ nxp.com のアカウントをお持ちでない場合には,先に登録を済ませたのちにログインしてください. MyNXPアカウントの登録方法はこちら 3. MCUXpresso IDEのインストール IDEのインストーラをMCUXpresso IDEのダウンロードサイトからダウンロードします.このダウンロードにはnxp.comでのユーザ登録が必要なので,もしまだであればあらかじめ済ませておきましょう. MCUXpresso IDEのダウンロードサイト行き「ダウンロード」ボタンを押す. ページがスクロールし,ダウンロードページへのリンク・ボタンが表示される.この「ダウンロード」ボタンを押す. MCUXpresso IDEのリンクをクリック. 利用規約が表示される.問題がなければ「I Agree (同意)」ボタンを押す. 自分が使うOSに合わせたインストーラを選んでリンクをクリック. ダウンロードするインストーラはLinuxならファイル名末尾の拡張子が「.deb.bin」のものを.Windowsなら「.exe」を. macOS用は拡張子が「.pkg」ですが2種類あります.M1以降のMシリーズ(Arm)プロセッサ搭載のMacなら「MacOSX - aarch64」,インテルCPU搭載のMacなら「MacOSX - 86-64」をダウンロードします. ※ バージョン番号が違う場合は読み替えてください ダウンロードが完了したら,インストーラを起動.表示される手順に従ってインストールを完了させます.   4. SDKのインストール   4.1 MCUXpresso IDEの起動とワークスペース MCUXpresso IDEのインストールが完了したら,MCUXpresso IDEを起動します. macOSでは,起動後にワークスペースをどこにするか聞いてきます(ガイド動画2:49付近).ワークスペースとは作業を行うためのフォルダです. デフォルトではユーザ・フォルダの中の,「Documents」の中に新しいフォルダが作られます. ※ 下図はデフォルト設定表示の例.この例ではdemoというユーザ名で作業しているので「/Users/demo/..」のような指定となっています.  ワークスペース(フォルダ)はユーザ・フォルダの中なら好きな場所にできます.下図の例ではユーザ・フォルダの中に「mcux」を作り,さらにその中で「project0」という名のワークスペースが作られます. 4.2 SDKのインストール手順 起動(起動とワークスペースを指定を完了)すると,下図のようなウェルカム表示が現れるのでこの中の「Download and Install SDKs」をクリック. しばらくサーバへの問い合わせを行ったあと,下図のような表示となります.このデフォルトの表示状態では右側と下側の表示が隠れてしまっているので,ウィンドウのサイズを拡げるか,表示を適宜スクロールします. ウィンドウサイズを拡げて表示域を確保 表示右上部の検索フィールドに,使用する基板やマイコンの型番を入力. ここでは例としてFRDM-MCXA153を使うので「A153」を入力した.その結果,FRDM-MCXA153基板が候補として表示された. FRDM-MCXA153基板を選択すると「Install」ボタンがハイライト表示されるので,これをクリック インストール中はダイアログボックスが表示される インストールが完了すると,ウェルカム表示に戻る. この表示をタブのクローズボタンで閉じる. IDEのデフォルト表示状態になる. 下部中央の表示枠(ペイン)のInstalled SDKタブにインストールされたSDKが表示される 4.3 準備完了! これで準備は整いました! 左上のペイン内の「Project Explorer」で,新しいプロジェクトを作成したり,SDKやGitHubまたはダウンロードしてきたプロジェクトをインポートして実行してみることが可能です. 5. おまけ:このまま基板の動作を試してみるには SDKにはサンプル・コードが含まれています. ここまでFRDM-MCXA153を例としてSDKをインストールしたので,そのままこの中にあるサンプル・コードを試してみることにします. まず基板とコンピュータをUSBケーブルで接続しておきます.FRDM-MCXA153では「MCU-Link」の表示のあるUSBコネクタを使います(写真参照). IDEの左上ペイン内,Project Explorerタブにある「Import SDK example(s)...」をクリック. インストールされているSDKが表示されるので「Next>」をクリック. サンプル・コードのリストが表示される. LEDチカチカ(=Lチカ)の例が「driver_examples」→「gpio」→「gpio_led_output」にあるので,下図のように階層をたどってチェックマークを入れ,「Finish」ボタンを押す. サンプル・コードがインポートされた. 青い虫のアイコン(Start debugging project)をクリック. ターゲットを選択するダイアログボックスが現れるので,表示された基板の情報を確認して「OK」ボタンを押す. コードがビルドされ,マイコンのフラッシュ・メモリに書き込まれます.そのあとコードが実行できる状態で一時停止. 黄色の四角とと緑の三角が組み合わさったアイコン(Resume)をクリックすると,基板上でコードが実行されます. このサンプル・コードはGPIO(General Purpose Input/Output = 汎用入出力)ピンにHIGHとLOWを交互に出すものでした.このピンが赤色のLEDに繋がれているので,LEDが点滅します. 参考資料 解説動画:さぁはじめよう!MCUXpresso IDE 関連情報:MCUXpresso for VSCとSDKのインストール (日本語ブログ) 変更履歴: 2025-05-07:初版 2025-06-26:「nxp.comへのログイン」の項を追加 2025-10-28:リンクの訂正 2025-11-10:リンクの更新 2025-11-14:インストール手順解説動画へのリンクを追加 / 参考資料の項を追加 2025-11-18:冒頭部の画像と使用基板の注釈追加.動画リンク画像変更 2026-03-17:「MCUXpresso IDEって?」の項の図を訂正 2026-04-05:「MCUXpresso IDEの起動とワークスペース」の項を追加 2026-07-24:章番号と目次を追加.「0. この記事は?」内,動画紹介リンクの強調  ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 (既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。) NXPのマイコン:MCXシリーズのソフトウェア開発にはMCUXpresso IDEが無料で使えます. またさまざまなMCUXpresso IDEで使えるサンプル・コードが提供されています.ここではIDEとSDKのインストールの手順を解説します. これを読めば,誰でも簡単に開発環境&SDKをインストールできて,サンプル・コードまで動かすことができます! General Purpose Microcontrollers MCUXpresso MCUXpresso IDE MCX 日本語ブログ
View full article
MCUXpresso for VSCとSDKのインストール (日本語ブログ) 0. この記事は? NXPのマイコン用ソフトウェア開発環境MCUXpressoは,Microsoft社が無償で配布しているソースコード・エディタ:Visual Studio Code(以下VSC)に対応.拡張機能の「MCUXpresso for VSC」をインストールし,数ステップの手順を踏むだけで,誰でも簡単にインストール可能!すぐにサンプル・コードを動かすことができます.😃 このブログ記事は,MCUXpresso for VSCと,各マイコン用のコードを作成するためのツール:SDKのインストール方法をステップ・バイ・ステップで紹介します. ※ この記事では使用する基板の例としてFRDM-MCXA153を使います 💡 インストール手順の解説動画を公開しました.視聴はこちらのリンクから. 目次 0. この記事は? 1. MCUXpresso for Visual Studio Codeとは? 2. 下準備:macOSの場合 2.1 Homebrewのインストール 3. Visual Studio Codeのインストール 4. MCUXpresso for VSCのインストール 5. ツールチェーンのインストール 6. SDKのインポート 7. 準備完了! 8. おまけ:このまま,基板の動作を試してみるには 8.1 サンプル・プロジェクトのインポート 8.2 サンプル・プロジェクトの実行 参考資料 1. MCUXpresso for Visual Studio Codeとは? NXPが提供している汎用マイコンの各種サンプル・コードは,NXPが無料で提供するソフトウェア開発環境:MCUXpressoで動かせます.このMCUXpressoには以下の2種類があり, ①MCUXpresso for Visual Studio Codeは,VSCのプラグインとして提供されます. MCUXpressoの種類 以下略称名 提供方法 ① MCUXpresso for Visual Studio Code ①MCUXpresso-VSC VSCのプラグイン ② MCUXpresso IDE  ②MCUX-IDE すべての機能をひとつにまとめたアプリケーション このブログでは,①MCUXpresso-VSCとSDKのインストールの方法を紹介します. MCUXpresso-VSCはWindows,macOS,Linuxで動作し,いずれのOSでも同じユーザ・インターフェースでの操作が可能です. MCUXpresso-VSCでサンプル・コードを動作させるには,まず準備としてVSC,MCUXpresso-VSC(プラグイン),ツールチェーン(マイコンで動作するコードを生成)をインストールします. その上に,動作させるマイコン/基板に合わせた*SDKをインポートします. *SDKはSoftware Development Kitの略で,マイコン毎に必要なドライバ・コード,設定情報が含まれます.   SDKは作成しようとするマイコンや基板(ターゲット)ごとにインストールしておかなければなりません. ちなみに②MCUX-IDEでもMCUXpresso-VSCと同等の作業が可能です.MCUX-*IDEにはソースコードを編集するエディタをはじめ,コンパイラやリンカといったツールチェーン,コードをプロジェクト単位にまとめて,さまざまな設定と一緒に管理してくれるソフトウェアなどが含まれています. MCUXpresso-VSCと比較すると開発に必要な全てがひとつにまとまっているため,インストールから開発作業までの流れをスムーズに進めることができます.一方,MCUXpresso-VSCはMCUX-IDEに比べて必要なツールを拡張機能(プラグイン)として追加していく構造になっており,必要となるさまざまな機能をカスタマイズできます.ご自身が使いやすい・開発しやすい環境を選択いただければと思います. MCUXpresso-IDEのインストールについては「MCUXpresso IDEとSDKのインストール (日本語ブログ)」を参照 *IDEはIntegrated Development Environmentの略で,統合開発環境アプリケーションです. それでは,MCUXpresso-VSCとSDKのインストール方法をステップごとに解説しましょう. この記事はmacOSを用いた例となっていますが,WindowsやLinuxでもほぼ同じ操作でインストールできます. 2. 下準備:macOSの場合 Windows, Linux OSのユーザは次のステップの「Visual Studio Codeのインストール」へ進んでください. こちらの「下準備」は,macOSユーザーのみ必要です. macOSユーザでも,すでにHomebrewをインストール済みであれば,再インストールする必要はありません.次のステップの「Visual Studio Codeのインストール」へ進んでください.  macOSでは,MCUXpresso-VSCに必要なツール(コンパイラやリンカ:マイコン用のコードを作成するソフトウェア)や,さらにそれをインストールしたり動かしたりするソフトウェア群を管理するものとして,Homebrewを使うようになっています.Homebrewは「パッケージ・マネージャ」と呼ばれるソフトウェアで,これを先に入れておかなければなりません. 2.1 Homebrewのインストール Homebrewのサイトに行くと,インストールのためのコマンドが掲出されています.これをMac上の「アプリケーション > ユーティリティ > ターミナル」を起動してその中にコピペして実行します. Homebrewサイト  Homebrewインストール・コマンド (上記サイトから) /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" Mac上のターミナル・アプリケーション ターミナル内にペーストしたコマンド   コマンドが終了したら,画面に表示された手順に従って次のコマンドを実行 (最初のコマンド実行後の画面表示から).画面内からコピペして実行するので構いません. echo >> /Users/demo/.zprofile echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/demo/.zprofile eval "$(/opt/homebrew/bin/brew shellenv) さらにインストールができたことを確認するために「brew help」コマンドを入力し,下のような表示が出れば完了です. 表示を確認したら,ターミナルを終了して構いません. macOSだけの下準備はここまで. 3. Visual Studio Codeのインストール Visual Studio Code (VSC)は各種OS用のアプリケーションとして配布されています.まず,この配布ページへ行って,自分OSに合わせたアプリケーションをダウンロード&インストールしましょう. インストールが終わったら,VSCを起動します. この記事では画面例を見やすくするため,テーマを白地に変更しました.   4. MCUXpresso for VSCのインストール 次に拡張機能(プラグイン)のMCUXpresso for VSCをインストールします.VSC内左のアクティビティ・バーで「拡張機能」アイコンをクリックして検索,出てきたMCUXpresso for VSCのインストールボタンを押せばすぐに完了します. インストール時に「westが見つからない」というエラーが出ますが,これはこのあとすぐインストールするので無視して構いません. 5. ツールチェーンのインストール 次はMCUXpresso for VSCの中からツールチェーンのインストーラをダウンロードします. ダウンロードが終わると,インストーラは自動的に起動します.インストーラはまず,バージョンの確認と,操作性改善のためのデータ送信の許可を求めてくるので,それぞれのボタンを押します.その後,インストールする項目を選択する画面が現れます. FRDM-MCX基板を使う場合,選択項目は「MCUXpresso SDK Developper」と「LinkServer」だけで構いません.クリックすると,各項目の左端に青い帯が現れます.これらを確認したのち「Install」ボタンを押します. インストールにはしばらく時間がかかります.この記事を書くために再インストールを行なっていますが,この記事を書くにあたって下のような進捗20%の画面で4分停止していました 🤨 追記(2026-07-24): 進捗状況がウインドウ内下部のテキストメッセージで表示されるように改善されています これにかかる時間はネットの混み具合などによって多少長くなります.気長に待つ必要があります.ですがあまりに長いようであれば,いったんキャンセル・ボタンを押して再試行してみてください.  インストールが完了すると次のような画面が現れ,VSCの再起動を促されます.*これは忘れないように行いましょう! 6. SDKのインポート (前の節にも書きましたが)ツールチェーンのインストールが終わったら,いったんVSCを終了して起動し直します. 次はSDKのインポートです.今回の例ではNXPのサーバに置いてある,各種の基板用のSDK配布場所からインポートしてみます (このほかNXPのweb上にあるSDKビルダを使ってカスタムしたSDKをインポートしてくることも可能ですが,今回は一番単純な例で解説します). まず,VSC内のアクティビティ・バー(一番左端)内のMCUXpresso-VSC拡張機能アイコンがクリックされた状態にしておいて,「Import Repository」ボタンをクリック.その右側に開いたタブ内で「REMOTE ARCHIVE」を選択 タブ内上部にある「Package」欄で,いまから使う基板を検索.この中で「153」と打つとFRDM-MCXA153が表示されるのでこれを選択. そうすると同一画面内にさらに入力項目が表示されます. 「Location」フィールドでSDKのインストール先フォルダを指定します.特に決まったところはなく,好きなところを指定できますが,ファイルの書き込みができるフォルダで,パスに日本語などのマルチバイト文字を含まない方が安全です. 「Create Git Repository」のチェックは任意ですが,特に必要がなければチェックを外します.これによってPC上のディスクの節約ができます.さらに「I agree」のチェックを入れますが,その前にその上にリンクのあるSDKのライセンスに目を通しておくようにしましょう. ここまでくれば,あとは「Import」ボタンを押すだけです. 7. 準備完了! これで準備は整いました! 左上のQUICKSTART PANEL内のコマンドを使って,新しいプロジェクトを作成したり,SDKやGitHubまたはダウンロードしてきたプロジェクトをインポートして実行してみることが可能です. 8. おまけ:このまま,基板の動作を試してみるには 8.1 サンプル・プロジェクトのインポート SDKにはサンプル・コードが含まれています. ここまでFRDM-MCXA153を例としてSDKをインストールしたので,そのままこの中にあるサンプル・コードを試してみることにします. まず基板とコンピュータをUSBケーブルで接続しておきます.FRDM-MCXA153では「MCU-Link」の表示のあるUSBコネクタを使います(写真参照). ではサンプルコードをインポートします. MCUXpresso-VSCのパネル内で「Import Example from Repository」ボタンを押します. 右側に表示されたタブ内で 「Repository:」欄でインポートしたSDKを選択 「Board:」欄はFRDM-MCXA153を選択 「Template:」では表示されるリストの一番上のものを選択 します.このサンプルコードはマイコンのピン入出力動作を確認するもので,基板上のボタンが押されるとそれを認識してLEDを点灯/消灯させます. テンプレートを選択したら,続いてサンプルコードのインポート先を「Location:」で指定.このフォルダも任意です. その下はツールチェーンの選択です.もしこのようなツールのインストールが初めてなら,選択肢は1 つだけです. 最後に「Import」ボタンを押します. インポートが完了すると,PROJECTS欄に先ほどとテンプレートと同名のプロジェクトが表示されます. インポート時に「再構成」を勧められることがあります.これはコードをビルド(コンパイルやリンクなど)するための構成設定が複数あったため.この場合は無視しても構いませんが,「いますぐ構成」ボタンを押した場合には,そのいずれか(どちらでもよい)を選択しておきます.   8.2 サンプル・プロジェクトの実行 インポートしたプロジェクトの上にカーソル・ポインタを合わせると,ボタンアイコンが現れます.この中の緑色の右向き三角ボタン(デバッグ・ボタン)を押すと,デバッグ・セッションを開始します. コードのビルド(コンパイル,リンク),マイコンへの書き込みが完了すると,デバッグ・インターフェースが表示され,プログラムの実行が可能になります. デバッグ・インターフェース表示状態で,その上部に並んだアイコン・ボタンのうち,「|▷」の表示のボタンを押すとマイコンの動作が始まります. この状態で基板のSW2ボタンを押すたびにLEDの点灯/消灯が繰り返されます. もし,基板が接続されていなかった場合には,次のような画面が現れます.接続を確認して再度試してください. このLED点灯/消灯プログラムは,シリアルに出力が出ています. VSC内のシリアル・モニタを使えば,その様子を見ることもできます. 表示幅が狭い場合には「SERIAL MONITOR」表示は折りたたまれています.「PROBREMS   OUTPUT   DEBUG CONSOLE   ...」などの並びの「・・・」をクリックすると出てきます. 下図は「Start Monitoring」ボタンを押して,さらに基板上のSW2を押したあとの様子. プログラムはデバッグ画面上の「□」ボタンを押すと停止します. 参考資料 解説動画:さぁはじめよう!MCUXpresso for Visual Studio Code 関連情報:MCUXpresso IDEとSDKのインストール (日本語ブログ) 変更履歴: 2025-11-13:初版 2025-11-14:インストール手順解説動画へのリンクを追加 / 参考資料の項を追加 2026-07-24:章番号と目次を追加.「0. この記事は?」内,動画紹介を枠で囲み.「2. 下準備:macOSの場合」冒頭の案内を枠で囲み,「Visual Studio Codeのインストール」へのアンカーリンクを追加.「5. ツールチェーンのインストール」内,進捗表示による改善を追記 ========================= 本投稿の「Comment」欄にコメントをいただいても,現在返信に対応しておりません. お手数をおかけしますが,お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください. (既に弊社NXP代理店,もしくはNXPとお付き合いのある方は,直接担当者へご質問いただいてもかまいません.) NXPのマイコン:MCXシリーズのソフトウェア開発にはMCUXpresso for VSC (Visual Studio Code)が無料で使えます. またさまざまなMCUXpresso for Visual Studio Codeで使えるサンプル・コードも提供されており,動作検証だけでなく,さまざまなプロジェクトのベースにも使えます. この記事を読めば,誰でも簡単にVSC開発環境&SDKをインストールできて,サンプル・コードまで動かすことができます! introduction MCUXpresso MCUXpresso SDK MCX 日本語ブログ
View full article
安装 MCUXpresso IDE 和 SDK(日文博客) 0. 这篇文章是关于什么的? NXP 的微控制器软件开发环境MCUXpresso及其SDK均免费提供,任何人都可以轻松安装并立即开始运行示例代码。😃 这篇博客文章将一步一步地向您展示如何安装MCUXpresso IDE和 SDK。 * 在本文中,我们将使用FRDM-MCXA153作为示例板。 我们发布了一段讲解安装步骤的视频,您可以点击此链接观看。   目录 0. 这篇文章是关于什么的? 1. 什么是 MCUXpresso IDE? 2. 登录 nxp.com 3. 安装 MCUXpresso IDE 4. 安装 SDK 4.1 启动 MCUXpresso IDE 和工作区 4.2 SDK安装步骤 4.3 准备就绪! 5. 附加题:测试电路板的运行情况…… 参考资料 1. 什么是 MCUXpresso IDE? NXP 提供的通用微控制器的各种示例代码旨在MCUXpresso上运行,MCUXpresso 是 NXP 免费提供的软件开发环境。 MCUXpresso 有两个版本:“ MCUXpresso IDE (以下简称 IDE)”和“ MCUXpresso VisualStudio Code (以下简称 VSC)”。IDE 是一个集成了所有功能的应用程序。VSC 是 Microsoft Visual Studio Code 的一个插件。 在本博客中,我们将介绍如何安装 IDE 和 SDK 。 该集成开发环境可在 Windows、macOS 和 Linux 系统上运行,并且在所有操作系统上都可以使用相同的用户界面进行操作。 要尝试在 MCUXpresso 上运行的示例代码,您必须先安装 IDE,然后安装要运行该代码的微控制器/板(目标)的 SDK。 IDE代表集成开发环境,是一款集成开发环境应用程序。该应用程序包含用于编辑源代码的编辑器、编译器和链接器等工具链,以及将代码组织成项目并进行项目管理以及各种设置的软件。 SDK代表软件开发工具包,其中包含每个微控制器芯片所需的驱动程序代码和配置信息。您必须为每个要创建的微控制器芯片或电路板(目标)安装SDK 。 让我们一步一步地学习如何安装这些软件。 本文以 macOS 为例,但使用几乎相同的步骤也可以在 Windows 和 Linux 上进行安装。 2. 登录 nxp.com 要执行以下步骤,您必须先登录nxp.com 。 如果您还没有 nxp.com 帐户,请先注册,然后再登录。 如何注册 MyNXP 账户 3. 安装 MCUXpresso IDE 从MCUXpresso IDE 下载站点下载 IDE 安装程序。此下载需要您在 nxp.com 上注册用户,因此如果您尚未注册,请提前注册。 前往MCUXpresso IDE 下载网站,然后按下“下载”按钮。 页面将滚动并出现一个指向下载页面的链接按钮。点击此“下载”按钮。 点击 MCUXpresso IDE 链接。 使用条款将会显示。如果没有问题,请点击“我同意”按钮。 选择与您的操作系统匹配的安装程序,然后单击链接。 如使用Linux,下载安装程序时请选择文件名末尾带有“.deb.bin”扩展名的文件。如使用Windows,请下载文件名末尾带有“.exe”扩展名的文件。 使用macOS,文件名末尾的扩展名为“.pkg”,但有两种类型:如为M1或更高版本M系列(Arm)处理器的 Mac,请下载“MacOSX-aarch64”;如为配备英特尔CPU的 Mac,请下载“MacOSX-86-64”。 *如果版本号不同,请替换为版本号。 下载完成后,启动安装程序并按照说明完成安装。   4. 安装 SDK   4.1 启动 MCUXpresso IDE 和工作区 MCUXpresso IDE 安装完成后,启动 MCUXpresso IDE 。 在 macOS 系统中,启动后会询问您要将工作区设置在哪里(在教程视频的 2 分 49 秒左右)。工作区是指您进行工作的文件夹。 默认情况下,将在用户文件夹内的“文档”文件夹内创建一个新文件夹。 * 下图显示了默认设置示例。在本例中,用户名为“demo”,因此路径指定为“/Users/demo/...”。 您可以在用户文件夹内的任何位置创建工作区(文件夹)。在下面的示例中,在用户文件夹内创建了一个名为“mcux”的文件夹,并在该文件夹内创建了一个名为“project0”的工作区。 4.2 SDK安装步骤 启动应用程序后(启动并指定工作区后),将出现如下所示的欢迎屏幕。在此屏幕中,单击“下载并安装 SDK” 。 服务器查询一段时间后,显示界面将如下图所示。在这种默认显示状态下,屏幕的右侧和底部会被隐藏,因此您需要根据需要放大窗口或滚动屏幕。 扩大窗口尺寸以确保显示区域安全 在显示屏右上角的搜索框中输入您正在使用的电路板或微控制器的型号。 这里,我们将以FRDM-MCXA153为例,所以我们输入了“A153”。结果,FRDM-MCXA153 开发板显示为候选产品。 选择 FRDM-MCXA153 板后, “安装”按钮将高亮显示,点击即可。 安装过程中会弹出对话框。 安装完成后,您将返回欢迎界面。 点击标签页的关闭按钮即可关闭此显示。 这将是IDE的默认显示状态。 已安装的 SDK 显示在底部中央窗格的“已安装 SDK”选项卡中。 4.3 准备就绪! 现在你可以出发了! 在左上角的“项目资源管理器”中,您可以创建一个新项目,或者从 SDK、GitHub 或下载的项目导入并运行项目。 5. 附加题:测试电路板的运行情况…… SDK包含示例代码。 到目前为止,我们已经以 FRDM-MCXA153 为例安装了 SDK,所以我们将尝试一下其中包含的示例代码。 首先,使用 USB 数据线将开发板连接到计算机。对于 FRDM-MCXA153,请使用标有“MCU-Link”的 USB 接口(参见照片)。 在 IDE 的左上角窗格中,单击“项目资源管理器”选项卡中的“导入 SDK 示例...” 。 将显示已安装的 SDK,然后单击“下一步>” 。 将显示示例代码列表。 可以在“ driver_examples ”→“ gpio ”→“ gpio_led_output ”中找到闪烁 LED (= 闪烁 L)的示例,因此请按照如下所示的层次结构进行操作,选中相应的复选框,然后按“完成”按钮。 示例代码已导入。 点击蓝色小虫图标(开始调试项目) 。 此时将出现一个选择目标的对话框,请检查显示的电路板信息,然后按“确定”按钮。 代码编译完成后写入微控制器的闪存。然后代码暂停,准备运行。 点击由黄色正方形和绿色三角形组成的图标(继续),即可运行板上的代码。 这段示例代码交替向一个GPIO (通用输入/输出)引脚输出高电平和低电平。该引脚连接到一个红色 LED ,因此 LED会闪烁。 参考资料 教学视频:快来使用MCUXpresso IDE吧! 相关信息:为 VSC 和 SDK 安装 MCUXpresso(日文博客) 变更历史记录: 2025-05-07:第一版 2025-06-26:新增“登录 nxp.com”部分。 2025-10-28:链接更正 2025年11月10日:链接已更新 2025-11-14:添加了安装程序视频的链接/添加了参考资料部分。 2025年11月18日:在开篇图片和所用电路板上添加了注释。更改了视频链接图片。 2026-03-17:更正了“什么是 MCUXpresso IDE?”部分中的图表。 2026-04-05:添加了“启动 MCUXpresso IDE 和工作区”部分。 2026-07-24:添加了章节编号和目录。在“0. 本文是关于什么的?”部分中突出显示了视频介绍链接。  ========================= 我们目前无法回复此帖子“评论”部分的评论。 对于由此造成的不便,我们深表歉意。如有任何疑问,请参阅“ NXP技术问题-如何联系我们(日语博客) ”。 (如果您已经是恩智浦的分销商或与恩智浦有合作关系,您可以直接询问负责人。) MCUXpresso IDE 可免费用于 NXP MCX 系列微控制器的软件开发。 此外,我们还提供了可与各种 MCUXpresso IDE 配合使用的示例代码。接下来,我们将介绍 IDE 和 SDK 的安装步骤。 读完本文后,任何人都可以轻松安装开发环境和 SDK ,甚至可以运行示例代码! 通用微控制器 MCUXpresso MCUXpresso IDE MCX 日本博客
View full article
Installing MCUXpresso for VSC and SDK (Japanese blog) 0. What is this article about? NXP's software development environment for microcontrollers, MCUXpresso , is compatible with Visual Studio Code (VSC), a source code editor distributed free of charge by Microsoft. Anyone can easily install it by simply installing the extension "MCUXpresso for VSC" and following a few steps! You can start running sample code right away .😃 This blog post will provide a step-by-step guide on how to install MCUXpresso for VSC and the SDK , a tool for creating code for each microcontroller. * In this article, we will use FRDM-MCXA153 as the example board. 💡 We have released a video explaining the installation procedure. Click this link to watch it. table of contents 0. What is this article about? 1. What is MCUXpresso for Visual Studio Code? 2. Preparation: For macOS 2.1 Installing Homebrew 3. Installing Visual Studio Code 4. Installing MCUXpresso for VSC 5. Installing the toolchain 6. Importing the SDK 7. Ready! 8. Bonus: To test the operation of the circuit board as is... 8.1 Importing Sample Projects 8.2 Running the Sample Project Reference materials 1. What is MCUXpresso for Visual Studio Code? The various sample codes for general-purpose microcontrollers provided by NXP can be run using MCUXpresso , a software development environment provided free of charge by NXP. There are two types of MCUXpresso: 1) MCUXpresso for Visual Studio Code is provided as a plug-in for VSC. Types of MCUXpresso Below is the abbreviation How to provide ① MCUXpresso for Visual Studio Code ①MCUXpresso-VSC VSC Plug-ins ② MCUXpresso ID E ②MCUX-IDE All in one application In this blog, I will introduce how to install MCUXpresso-VSC and the SDK . MCUXpresso-VSC runs on Windows, macOS, and Linux, and can be operated with the same user interface on all operating systems. To run the sample code on MCUXpresso-VSC, first install VSC , MCUXpresso-VSC (plugin) , and toolchain (which generates code that runs on the microcontroller) . Then import the SDK * that matches the microcontroller/board you are using. *SDK stands for Software Development Kit and contains the driver code and configuration information required for each microcontroller. The SDK must be installed for each microcontroller or board (target) you want to create. By the way, ②MCUX-IDE can also perform the same tasks as MCUXpresso-VSC. MCUX-*IDE includes an editor for editing source code, a toolchain such as a compiler and linker, and software that organizes code into projects and manages them along with various settings. Compared to MCUXpresso-VSC, everything needed for development is gathered together in one place, allowing for a smoother flow from installation to development work. On the other hand, compared to MCUX-IDE, MCUXpresso-VSC has a structure where necessary tools are added as extensions (plug-ins), allowing you to customize the various functions you need. We hope you will choose the environment that is easiest for you to use and develop in. For information on installing MCUXpresso-IDE, see " Installing MCUXpresso IDE and SDK (Japanese blog) " * IDE stands for Integrated Development Environment , an integrated development environment application . Now, let's explain how to install MCUXpresso-VSC and SDK step by step. This article uses macOS as an example, but the installation can be done on Windows and Linux using almost the same steps. 2. Preparation: For macOS Windows and Linux OS users should proceed to the next step, " Installing Visual Studio Code ." This "Preparation" step is only necessary for macOS users . If you're a macOS user and have already installed Homebrew , you don't need to reinstall it. Proceed to the next step, " Installing Visual Studio Code ." On macOS, Homebrew is used to manage the tools required for MCUXpresso-VSC (compilers and linkers: software to create code for the microcontroller) and the software needed to install and run them. Homebrew is software called a "package manager," and it must be installed first. 2.1 Installing Homebrew If you go to the Homebrew website, you will find the command for installation. Open "Applications > Utilities > Terminal" on your Mac, copy and paste the command into it, and run it. Homebrew Site Homebrew installation command (from the above site) /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" Terminal application on Mac Pasted command into terminal   Once the command has finished, follow the instructions on the screen to execute the next command (starting from the screen displayed after the first command is executed). You can also copy and paste the command from the screen and execute it. echo >> /Users/demo/.zprofile echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/demo/.zprofile eval "$(/opt/homebrew/bin/brew shellenv) To confirm that the installation was successful, enter the command "brew help" and if the following message appears, the installation is complete. Once you have confirmed the display, you can exit the terminal. This concludes the preparations for macOS only. 3. Installing Visual Studio Code Visual Studio Code (VSC) is distributed as an application for various operating systems. First, go to this distribution page and download and install the application that matches your operating system. Once the installation is complete, start VSC. In this article, the theme has been changed to white to make the screen examples easier to see.   4. Installing MCUXpresso for VSC Next, install the extension (plug-in) MCUXpresso for VSC. Click the "Extensions" icon in the activity bar on the left side of VSC to search, and click the install button for MCUXpresso for VSC that appears to complete the installation process quickly. During installation, you may get an error message saying "west not found", but you can ignore this as we will install it shortly. 5. Installing the toolchain Next, download the toolchain installer from MCUXpresso for VSC. Once the download is complete, the installer will start automatically. First, the installer will check the version and ask for permission to send data to improve operability, so press the appropriate button. After that, a screen will appear where you can select the items to install. If you are using the FRDM-MCX board, you only need to select "MCUXpresso SDK Developper" and "LinkServer". When you click, a blue band will appear on the left edge of each item. After checking these, press the "Install" button. The installation will take a while. I am reinstalling it to write this article, but it was stuck at 20% progress for 4 minutes while I was writing this article 🤨 Update (2026-07-24): Progress is now displayed as a text message at the bottom of the window. This may take some time depending on the internet traffic, so please be patient. However , if it seems like it's taking too long, press the cancel button and try again . Once the installation is complete, the following screen will appear, prompting you to restart VSC. *Don't forget to do this! 6. Importing the SDK (As mentioned in the previous section) Once the toolchain installation is complete, exit VSC and then restart it . Next is importing the SDK. In this example, we will import from the SDK distribution location for various boards stored on the NXP server (it is also possible to import a custom SDK using the SDK builder on the NXP website, but this time we will explain using the simplest example). First, click on the MCUXpresso-VSC extension icon in the VSC activity bar (far left) and click on the "Import Repository" button. Select "REMOTE ARCHIVE" in the tab that opens to the right. In the "Package" column at the top of the tab, search for the board you will be using. If you type "153" in, FRDM-MCXA153 will appear, so select this. This will display additional input fields on the same screen. In the "Location" field, specify the folder where the SDK will be installed. There is no set location, so you can specify any location you like, but it is safer to use a folder where files can be written and whose path does not contain multi-byte characters such as Japanese. Checking "Create Git Repository" is optional, but if you don't need it, uncheck it. This will save disk space on your PC. Next, check "I agree," but before doing so, be sure to read the SDK license linked above it. Once you've reached this point, all you have to do is press the "Import" button. 7. Ready! Now you're ready to go! Using the commands in the QUICKSTART PANEL in the upper left, you can create a new project or import and run a project from the SDK, GitHub, or a downloaded project. 8. Bonus: To test the operation of the circuit board as is... 8.1 Importing Sample Projects The SDK includes sample code . So far we have installed the SDK using the FRDM-MCXA153 as an example, so we will try out the sample code included. First, connect the board to the computer with a USB cable. For the FRDM-MCXA153, use the USB connector labeled "MCU-Link" (see photo). Now let's import the sample code. In the MCUXpresso-VSC panel, click the "Import Example from Repository" button. In the tabs on the right Select the imported SDK in the "Repository:" field Select FRDM-MCXA153 in the "Board:" field. In "Template:", select the top one in the list This sample code checks the pin input/output operation of the microcontroller, and when a button on the board is pressed, it recognizes it and turns the LED on/off. After selecting a template, specify the location where you want to import the sample code in "Location:". This folder is also optional. Below that is the toolchain selection. If this is your first time installing such tools, there is only one option. Finally, press the "Import" button. Once the import is complete, a project with the same name as the template will appear in the PROJECTS column. You may be prompted to "reconfigure" when importing. This is because there are multiple configuration settings for building the code (compiling, linking, etc.). In this case, you can ignore it, but if you press the "Configure Now" button, select one of them (either is fine). 8.2 Running the Sample Project When you hover the cursor over the imported project, a button icon will appear. Press the green right-facing triangle button (the Debug button) to start a debug session. Once the code has been built (compiled and linked) and written to the microcontroller, the debug interface will appear and you will be able to run the program. When the debug interface is displayed, pressing the icon button with the symbol "|▷" at the top will start the microcontroller's operation. In this state, the LED will turn on and off repeatedly each time you press the SW2 button on the board. If the board is not connected , the following screen will appear. Please check the connection and try again. This LED on/off program outputs serially. You can also see this using the serial monitor in VSC. If the display width is narrow, the "SERIAL MONITOR" display will be collapsed. Click on the "..." next to "PROBREMS OUTPUT DEBUG CONSOLE..." to display it. The image below shows what happens after pressing the "Start Monitoring" button and then pressing SW2 on the board. The program will stop when you press the "□" button on the debug screen. Reference materials Tutorial video: Let's get started! MCUXpresso for Visual Studio Code Related information: Installing MCUXpresso IDE and SDK (Japanese blog) Change history: 2025-11-13: First Edition 2025-11-14: Added a link to an installation procedure video / Added a section for reference materials. 2026-07-24: Added chapter numbers and table of contents. Enclosed the video introduction in "0. What is this article about?" within a box. Enclosed the introductory instructions in "2. Preparation: For macOS" within a box and added an anchor link to "Installing Visual Studio Code". Added improvement to "5. Installing the Toolchain" by adding progress display. ========================= We are currently unable to respond to comments in the "Comment" section of this post. We apologize for the inconvenience, but when making inquiries, please refer to " Technical Questions to NXP - How to Contact Us( Japanese Blog) ". (If you are already an NXP distributor or have a relationship with NXP, you may ask your question directly to the person in charge.) MCUXpresso for VSC (Visual Studio Code) can be used free of charge for software development of NXP's MCX series microcontrollers. In addition, various sample codes that can be used with MCUXpresso for Visual Studio Code are provided, which can be used not only for operation verification but also as the basis for various projects. By reading this article, anyone can easily install the VSC development environment and SDK and even run sample code! introduction MCUXpresso MCUXpresso SDK MCX Japanese blog
View full article
安装适用于 VSC 和 SDK 的 MCUXpresso(日文博客) 0. 这篇文章是关于什么的? NXP 的微控制器软件开发环境 MCUXpresso 与 Visual Studio Code (VSC) 兼容,后者是微软免费提供的源代码编辑器 。 只需 安装“MCUXpresso for VSC”扩展程序并按照几个步骤操作, 即可轻松完成安装 ! 您可以立即开始运行示例代码 。😃 这篇博客文章将提供分步指南,介绍如何安装适用于 VSC 的 MCUXpresso和SDK ,SDK 是一个为每个微控制器创建代码的工具。 * 在本文中,我们将使用FRDM-MCXA153作为示例板。 💡 我们发布了一段视频,讲解安装步骤。点击此链接观看。 目录 0. 这篇文章是关于什么的? 1. 什么是适用于 Visual Studio Code 的 MCUXpresso? 2. 准备工作:适用于 macOS 2.1 安装 Homebrew 3. 安装 Visual Studio Code 4. 为 VSC 安装 MCUXpresso 5. 安装工具链 6. 导入 SDK 7. 准备好了! 8. 附加题:测试电路板的运行情况…… 8.1 导入示例项目 8.2 运行示例项目 参考资料 1. 什么是适用于 Visual Studio Code 的 MCUXpresso? NXP提供的各种通用微控制器示例代码可以使用MCUXpresso运行,MCUXpresso是NXP免费提供的软件开发环境。MCUXpresso有两种类型:1)MCUXpresso for Visual Studio Code,作为VSC的插件提供。 MCUXpresso 的类型 以下是缩写 如何提供 ① 适用于 Visual Studio Code 的 MCUXpresso ①MCUXpresso-VSC VSC插件 ② MCUXpresso ID E ②MCUX-IDE 一体化应用程序 在本篇博客中,我将介绍如何安装MCUXpresso-VSC和SDK。MCUXpresso -VSC可在 Windows、macOS 和 Linux 系统上运行,并且在所有操作系统上都可以使用相同的用户界面进行操作。 要在 MCUXpresso-VSC 上运行示例代码,首先需要安装VSC 、 MCUXpresso-VSC(插件)和工具链(用于生成可在微控制器上运行的代码) 。然后导入与您使用的微控制器/开发板相匹配的SDK *。 *SDK代表软件开发工具包,其中包含每个微控制器所需的驱动程序代码和配置信息。 对于要创建的每个微控制器或电路板(目标),都必须安装SDK 。 顺便一提, ②MCUX-IDE也能执行与 MCUXpresso-VSC 相同的任务。MCUX-*IDE 包括用于编辑源代码的编辑器、编译器和链接器等工具链,以及将代码组织成项目并管理它们以及各种设置的软件。 与 MCUXpresso-VSC 相比,MCUXpresso-VSC 将开发所需的一切都集中在一个地方,使从安装到开发的流程更加流畅。另一方面,与 MCUX-IDE 相比,MCUXpresso-VSC 的结构是将必要的工具以扩展(插件)的形式添加,允许您自定义所需的各种功能。我们希望您能选择最适合您使用和开发的环境。 有关安装 MCUXpresso-IDE 的信息,请参阅“安装 MCUXpresso IDE 和 SDK(日语博客) ”。 * IDE代表集成开发环境,是一款集成开发环境应用程序。 现在,让我们一步一步地解释如何安装 MCUXpresso-VSC 和 SDK。 本文以 macOS 为例,但使用几乎相同的步骤也可以在 Windows 和 Linux 上进行安装。 2. 准备工作:适用于 macOS Windows 和 Linux 操作系统用户应直接进入下一步“安装 Visual Studio Code” 。此“准备”步骤仅适用于 macOS 用户。 如果您是 macOS 用户并且已经安装了 Homebrew ,则无需重新安装。请继续执行下一步“安装 Visual Studio Code ”。 在 macOS 系统中, Homebrew 用于管理 MCUXpresso-VSC 所需的工具(编译器和链接器:用于为微控制器创建代码的软件)以及安装和运行这些工具所需的软件。Homebrew 是一款名为“软件包管理器”的软件,必须先进行安装。 2.1 安装 Homebrew 如果你访问 Homebrew 网站,就能找到安装命令。在你的 Mac 上打开“应用程序 > 实用工具 > 终端”,复制命令并粘贴进去,然后运行它。 自制啤酒网站 Homebrew 安装命令(来自上述网站) /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" Mac 上的终端应用程序 将命令粘贴到终端   命令执行完毕后,请按照屏幕上的说明执行下一个命令(从第一个命令执行完毕后显示的屏幕开始)。您也可以从屏幕上复制命令并粘贴执行。 echo >> /Users/demo/.zprofile echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/demo/.zprofile eval "$(/opt/homebrew/bin/brew shellenv) 要确认安装是否成功,请输入命令“brew help”,如果出现以下消息,则表示安装已完成。 确认显示内容后,即可退出终端。 至此,仅针对 macOS 的准备工作就完成了。 3. 安装 Visual Studio Code Visual Studio Code (VSC) 以应用程序的形式分发,支持多种操作系统。首先,请访问此分发页面,下载并安装与您的操作系统相匹配的应用程序。 安装完成后,启动 VSC。 本文中,主题已更改为白色,以便更容易看清屏幕示例。   4. 为 VSC 安装 MCUXpresso 接下来,安装适用于 VSC 的扩展程序(插件)MCUXpresso。点击 VSC 左侧活动栏中的“扩展程序”图标进行搜索,然后点击出现的适用于 VSC 的 MCUXpresso 的安装按钮,即可快速完成安装过程。 安装过程中,您可能会收到一条错误消息,提示“找不到 west”,但您可以忽略此消息,因为我们很快就会安装它。 5. 安装工具链 接下来,从 MCUXpresso 下载适用于 VSC 的工具链安装程序。 下载完成后,安装程序将自动启动。首先,安装程序会检查版本并请求发送数据以提升运行性能的权限,请点击相应的按钮。之后,会出现一个界面,您可以在其中选择要安装的项目。 如果您使用的是 FRDM-MCX 开发板,则只需选择“MCUXpresso SDK Developper”和“LinkServer”。点击后,每个选项的左侧边缘会出现蓝色条带。勾选后,点击“安装”按钮。 安装过程需要一些时间。我为了写这篇文章正在重新安装,但在我写这篇文章的时候,进度卡在 20% 足足 4 分钟🤨 更新(2026-07-24):进度现在以文本消息的形式显示在窗口底部。 这可能需要一些时间,具体取决于网络拥堵等因素,请耐心等待。如果时间过长,请按取消按钮重试。 安装完成后,将出现以下屏幕,提示您重启 VSC。*请务必执行此操作! 6. 导入 SDK (如前文所述)工具链安装完成后,退出 VSC,然后重新启动它。 接下来是导入 SDK。在本例中,我们将从 NXP 服务器上存储的各种电路板的 SDK 分发位置导入 SDK(也可以使用 NXP 网站上的 SDK 构建器导入自定义 SDK,但这次我们将使用最简单的示例进行说明)。 首先,点击 VSC 活动栏(最左侧)中的 MCUXpresso-VSC 扩展图标,然后点击“导入存储库”按钮。在右侧打开的选项卡中选择“远程归档”。 在标签页顶部的“封装”列中,搜索您将要使用的电路板。如果您输入“153”,则会出现 FRDM-MCXA153,请选择它。 这将在同一屏幕上显示额外的输入字段。 在“位置”字段中,指定 SDK 的安装文件夹。没有固定位置,您可以指定任何位置,但为了安全起见,建议使用可写入文件的文件夹,并且其路径不包含多字节字符(例如日语)。 勾选“创建 Git 仓库”是可选的,如果您不需要,请取消勾选。这样可以节省您电脑上的磁盘空间。接下来,勾选“我同意”,但在勾选之前,请务必阅读上方链接的 SDK 许可协议。 到达这一步后,您只需按下“导入”按钮即可。 7. 准备好了! 现在你可以出发了! 使用左上角“快速入门面板”中的命令,您可以创建一个新项目,或者从 SDK、GitHub 或下载的项目导入并运行项目。 8. 附加题:测试电路板的运行情况…… 8.1 导入示例项目 SDK包含示例代码。 到目前为止,我们已经以 FRDM-MCXA153 为例安装了 SDK,所以我们将尝试一下其中包含的示例代码。 首先,使用 USB 数据线将开发板连接到计算机。对于 FRDM-MCXA153,请使用标有“MCU-Link”的 USB 接口(参见照片)。 现在让我们导入示例代码。 在 MCUXpresso-VSC 面板中,单击“从存储库导入示例”按钮。 在右侧的标签页中 在“存储库:”字段中选择导入的 SDK。 在“板卡:”字段中选择 FRDM-MCXA153。 在“模板:”中,选择列表中的第一个模板。 这段示例代码检查微控制器的引脚输入/输出操作,当按下板上的按钮时,它会识别该按钮并打开/关闭 LED。 选择模板后,在“位置:”中指定要导入示例代码的位置。此文件夹也是可选的。 下方是工具链选择。如果您是第一次安装此类工具,则只有一个选项。 最后,按下“导入”按钮。 导入完成后,项目列中将出现一个与模板同名的项目。 导入时,系统可能会提示您“重新配置”。这是因为构建代码(编译、链接等)涉及多个配置设置。在这种情况下,您可以忽略此提示;但如果您点击“立即配置”按钮,请选择其中一个(两个都可以)。 8.2 运行示例项目 将光标悬停在导入的项目上时,会出现一个按钮图标。按下绿色的向右三角形按钮(调试按钮)即可启动调试会话。 代码构建(编译和链接)并写入微控制器后,调试界面将会出现,您就可以运行该程序了。 当显示调试界面时,按下顶部带有符号“|▷”的图标按钮将启动微控制器的操作。 在这种状态下,每次按下电路板上的 SW2 按钮时,LED 都会反复亮起和熄灭。 如果电路板未连接,将出现以下屏幕。请检查连接并重试。 此LED开关程序以串行方式输出。 您也可以使用 VSC 中的串口监视器查看此内容。 如果显示宽度较窄,“串口监视器”显示将会折叠。点击“问题输出调试控制台...”旁边的“...”即可将其显示出来。 下图显示了按下“开始监控”按钮,然后按下电路板上的 SW2 后发生的情况。 当您在调试屏幕上按下“□”按钮时,程序将停止运行。 参考资料 教程视频:让我们开始吧!适用于 Visual Studio Code 的 MCUXpresso 相关信息:安装 MCUXpresso IDE 和 SDK(日文博客) 变更历史记录: 2025年11月13日:第一版 2025-11-14:添加了安装程序视频的链接/添加了参考资料部分。 2026年7月24日:添加了章节编号和目录。将视频介绍放在“0. 本文内容是什么?”的方框内。将介绍性说明放在“2. 准备工作:macOS 版”的方框内,并添加了指向“安装 Visual Studio Code”的链接。改进了“5. 安装工具链”部分,添加了进度显示。 ========================= 我们目前无法回复此帖子“评论”部分的评论。 对于由此造成的不便,我们深表歉意。如有任何疑问,请参阅“ NXP技术问题-如何联系我们(日语博客) ”。 (如果您已经是恩智浦的分销商或与恩智浦有业务往来,您可以直接向负责人咨询。) MCUXpresso for VSC(Visual Studio Code)可免费用于NXP MCX系列微控制器的软件开发。 此外,还提供了可与 Visual Studio Code 的 MCUXpresso 一起使用的各种示例代码,这些代码不仅可以用于操作验证,还可以作为各种项目的基础。 通过阅读本文,任何人都可以轻松安装 VSC 开发环境和 SDK ,甚至运行示例代码! 介绍 MCUXpresso MCUXpresso SDK MCX 日本博客
View full article
SPI总线概述(日语博客) 0. 目录 目录 什么是SPI? 1.1 历史和规格 1.2 控制器/目标或主节点/子节点(子节点) 物理/电气特性 2.1 信号线数量:信号名称 2.2 推挽式。不传输时处于高阻抗状态 2.3 时钟频率 协议 3.1 模式 3.2 数据传输 连接拓扑 4.1 并行连接和带片选功能的菊花链连接 参考资料 1. 什么是SPI? 1.1 历史和规格 SPI总线是由美国摩托罗拉公司(现为恩智浦半导体公司)提出的一种串行总线规范。该规范据称于20世纪80年代中期制定。SPI代表“串行外设接口”,最初开发为一种用于连接处理器和外围芯片的四线串行总线。三线SPI总线也作为衍生规范存在,但最初的四线系统才是基础。 SPI 通信方法有多种变体,例如信号极性和数据同步时序设置,因此在使用时需要注意这一点。 与 I²C 类似,SPI 也用于在芯片之间交换数据,但两者各有优缺点,如[表 1] 所示。 SPI 适用于需要更快数据传输的应用。这是由于其电气规格不同:I²C 使用开漏驱动信号,而 SPI 使用推挽驱动信号,因此更容易实现更高的传输速度。此外,在数据传输速度方面,SPI 的特点是能够执行全双工通信,从而允许同时进行发送和接收。 另一方面,SPI也存在一些缺点。传输数据长度和时钟极性是针对每个目标设备单独指定的,这使得混合连接多种类型的设备变得困难。此外,连接多个相同类型的设备时,每个设备都需要一个片选信号,这会增加信号线的数量;而且,在级联设备时,数据传输长度也必须进行调整。   I²C SPI 行数 2 数据来源:SDA 时钟:SCL 4 数据:SDO、SDI(MOSI、MISO) 时钟:SCLK 芯片选择:CS 速度 约400kHz 根据模式不同,频率分别为 1MHz、3.4MHz 或 5MHz。 几百千赫兹到几十兆赫兹 沟通方向 双向半双工 双向全双工 连接方式 多点(并行) 多个控制器与多个目标 并行或菊花链式单控制器对多个目标 信号驱动 明渠 (需要上拉电阻) 推拉 表1:I²C和SPI的比较   1.2 控制器/目标或主节点/子节点(子节点) 在SPI协议中,数据传输也是以主从关系进行的。过去常用“主设备”和“从设备”这两个术语,但现在已改为“控制器”和“目标设备”。 它们也被称为主节点/子节点(简称“子节点”),保留了之前角色名称中的首字母“M/S”。从现在开始,本博客将特意使用“主节点/子节点”(简称“子节点”)这一术语。 在SPI协议中,不能存在多个主设备。通信始终发生在单个主设备和一个或多个目标设备之间。 2. 物理/电气特性 2.1 信号线数量:信号名称 SPI总线是一种四线同步串行接口。同步串行接口是一种利用其中一条信号线作为时钟信号,与时钟信号同步发送和接收数据的方法。 数据信号线有两条。一条用于主设备到子设备的数据传输,另一条用于子设备到主设备的数据传输。还有一条是片选信号。SPI 协议本身没有指定传输目标地址的方法。因此,片选信号用于指定目标设备[图 1]。 信号名称可能有多种叫法。以下是OSHWA使用的信号名称: SDO :数据输出 SDI :数据输入 SCK :串行时钟 CS :芯片选择:CS 在上述示例中,SDO 和 SDI 的名称是根据每个芯片上的数据输入/输出方向来命名的。在这种情况下,引脚名称很明确,但难以区分主输出和子输出之间的信号方向。 相反,电路图等中通常使用以下信号名称。本博客将遵循这些术语。 MOSI :主输出到子输出的数据(主输出 子输入) MISO :从子系统到主系统的数据(主系统输入/子系统输出) SCLK :串行时钟 CS :芯片选择:CS 在这些信号中,只有MISO信号是从子系统发往主系统的信号,其余信号都是从主系统发往子系统的信号。通信过程中信号方向保持不变。 图 1:控制器和目标。信号名称 例如,当通信只是单向进行时,为了节省信号数量,可以省略其中一条数据线。 还有一些目标设备支持时分复用传输和接收,从而只需使用一条数据线。在这种情况下,在主侧,MOSI/MISO 通过电阻短路以合并信号。 2.2 推挽式。不传输时处于高阻抗状态 信号以推挽方式输出。当没有数据传输时,MOSI 和 MISO 输出端处于高阻抗状态。这样做是为了防止多个子节点并联连接时相互干扰。 信号电压由子节点设备决定,因此必须进行相应的调整。如果主节点和子节点之间的电压不同,则需要进行电压转换。 2.3 时钟频率 关于时钟频率没有具体规定。通常使用数百 kHz 到数 MHz 范围内的时钟频率,上限由子节点器件的规格决定。需要高速数据传输的应用可能会使用数十 MHz 的时钟频率。此外,在存储器件和其他应用中,也有使用多条 MOSI 和 MISO 数据线来提高传输速率的例子。 3. 协议 数据传输协议没有严格的规定,每个子节点设备都可以自由选择协议。主微控制器具有支持各种子节点设备的设置。 基本的传输过程始于将连接到目标子节点的 CS 信号置位。当 CS 信号置空时,传输结束。CS 信号通过低电平和高电平信号置位和置空,但极性由子节点设备的规格决定。许多设备使用最高有效位 (MSB) 在前进行数据位排序,但也存在例外情况。此外,传输单元的位数也没有具体规定。我见过一些解释说传输单元是 2 到 16 位,但这并不准确,因为有些子节点使用更大的位长度作为传输单元(例如,64 位)。 3.1 模式 SPI 具有称为“模式”的设置,指的是时钟极性和边沿选择的组合,共有四种模式,每种模式有两种设置[图 2]。 时钟极性是一个名为CPOL 的设置,它决定在没有数据传输时 SCLK 是低电平还是高电平。在主电路中,将其设置为 0 会将其设置为低电平,设置为 1 则会将其设置为高电平。边沿选择(相位)称为CPHA 。此设置决定数据是在第一个时钟边沿还是第二个时钟边沿被锁存(接收)。设置为 0 选择第一个边沿,设置为 1 选择第二个边沿。CPOL 和 CPHA 有时可以组合使用,以表示模式 0 到 3 [表 2]。 另外,请注意,还有一些子节点的片选极性相反。 图 2:模式(CPOL、CPHA)     中央警察 CPHA 模式=0 0 0 模式=1 0 1 模式=2 1 0 模式=3 1 1 表 2:模式和 CPOL、CPHA 什么是“锁存数据的边缘”? 数据的发送和接收与时钟同步,但数据会在时钟的上升沿或下降沿发生变化。图 3 显示了数据在下降沿发生变化的示例。主节点的 MOSI 输出和子节点的 MISO 输出会随着主节点 SCLK 输出的下降沿而变化。下一个数据会在下一个下降沿发生变化,但在此之前,状态保持稳定。时钟的上升沿恰好出现在这段时间内,因此数据会根据这个时间点相互捕获。这就是所谓的“锁存边沿”。 图 3:数据(MOSI/MISO)和时钟(SCLK)同步 3.2 数据传输 片选信号置位后,数据会与时钟同步发送和接收。当子节点接收到自身的片选信号置位时,它会与时钟同步接收和输出数据。 图 4 展示了一个 SPI 数据传输示例。数据根据时钟信号进行交换,同时 CS 信号保持有效。熟悉逻辑电路的人会发现,这是通过一个简单的移位寄存器电路实现的。 图 4:SPI 传输示例   4. 连接拓扑 4.1 并行连接和带片选功能的菊花链连接 如图 5 所示,多个子节点连接在一起。每个子节点都提供一个片选信号,通信通过每个信号指定发送方和接收方来实现。或者,为了减少片选信号的数量,可以使用菊花链连接,并将子节点视为一个具有扩展比特长度的单个子节点来进行通信(如图 6 所示)。 如前所述,将多种类型的子节点连接到同一SPI总线时必须格外小心。正如前文所述,它们的“模式”、片选极性和数据位长度可能不同。因此,每次与每个子节点通信时,您可能都需要切换设置或在硬件中进行调整。 图 5:并联连接   图 6:菊花链连接 5. 参考资料 OSHWA 角色和信号名称[英文] 关于“SPI”的维基百科页面:本博客中的信号名称和主节点/子节点名称均基于此描述。 Interface 2024 年 3 月刊(CQ Publishing) :专题文章“从零开始的串行通信 [使用 Pico 进行 UART/I2C/SPI 通信]” NXP 系统管理 I²C、I3C、SPI 选择器指南 NXP社区博客:I3C:下一代串行总线 NXP社区博客:I²C总线概述 [本文最初发表于《Interface》杂志2024年3月刊(CQ Publishing出版),标题为“从零开始构建I2C和SPI ④……SPI通信标准”,第71-73页。本文摘录并修订了其中解释通信规范的部分。] 更改历史记录: 2025年2月3日:第一版 2025-02-25:在“5. 参考资料”部分添加了“NXP 系统管理 I²C、I3C、SPI 选择器指南”的链接。 2025-05-01:更正了目录(删除了项目),更正了第 2.2 节中的项目名称。 2026-07-24:修复了“2.1 信号线数量:信号名称”和“5. 参考资料”中指向“OSHWA 角色名称和信号名称”的损坏链接。 ========================= 我们目前无法回复此帖子“评论”部分的评论。 对于由此造成的不便,我们深表歉意。如有任何疑问,请参阅“ NXP技术问题-如何联系我们(日语博客) ”。 (如果您已经是恩智浦的分销商或与恩智浦有合作关系,您可以直接询问负责人。) SPI总线用于微控制器/处理器与外围设备之间的通信。 虽然这种串行总线应用非常广泛,但我还是想借此机会简要介绍一下它的起源。 通信标准 界面 日本博客
View full article
SPIバスの概要 (日本語ブログ) 0. 目次 目次 SPIとは 1.1 歴史とその仕様 1.2 コントローラ/ターゲット.またはメイン/サブノード(サブ) 物理的/電気的特徴 2.1 信号線数:信号名 2.2 プッシュプル.非転送時のハイ・インピーダンス状態 2.3 クロック周波数 プロトコル 3.1 モード 3.2 データ転送 接続トポロジ 4.1 チップセレクトによる並列接続とデイジーチェーン 参考資料 1. SPIとは 1.1 歴史とその仕様 SPIバスはアメリカのモトローラ(現NXPセミコンダクターズ)によって提唱されたシリアル・バス仕様です.仕様が策定されたのは1980年代半ばとされています. SPIは「Serial Peripheral Interface」の略でプロセッサと周辺チップとの接続に使われる4線式のシリアル・バスとして開発されました. この派生仕様としての3線式SPIバスも存在しますが,基本となっているのは元の4線式です. SPIでは信号の極性やデータの同期タイミング設定など,通信方法に幾つかのバリエーションがあるので,使用の際にはこれを意識する必要があります. SPIはI²Cと同じく,チップ間のデータのやり取りに使われますが,それぞれに利点と不利な点があります.これを[表1]にまとめます. SPIはより高速なデータ転送が必要な用途に使われます.これは電気的仕様の違いによるもので,I²Cではオープンドレインで信号を駆動するのに対し,SPIではプッシュプルで駆動するため高速化が容易です.さらにデータ転送速度の点では送受信を同時に行える全二重通信が行えるのが特長です. 一方,SPIにもいくつかの不利な点があります.転送のデータ長やクロックの極性は転送先デバイスごとに規定されているため,複数種類のデバイスの混在が困難な場合があります.また同種でも複数のデバイスを接続している場合には,各々のデバイスにチップセレクト信号が必要になるため信号線数が増えたり,あるいは縦続接続を行った場合にはデータ転送長の調整が必要になったりします.   I²C SPI 線数 2 データ:SDA クロック:SCL 4 データ:SDO, SDI (MOSI, MISO) クロック:SCLK チップセレクト:CS 速度 ~400kHz モードにより1MHz, 3.4MHz, 5MHz 数百kHz〜数十MHz 通信方向 双方向 半二重 双方向 全二重 接続方法 マルチドロップ(並列) 複数コントローラ 対 複数ターゲット 並列 または デイジーチェーン 単一コントローラ 対 複数ターゲット 信号駆動 オープンドレイン (プルアップ抵抗要) プッシュプル 表1:I²CとSPIの比較   1.2 コントローラ/ターゲット.またはメイン/サブノード(サブ) SPIでも主と従の関係で転送が行われます.これまでそれぞれにマスタ/スレーブの語が一般に使われていましたが,現在はコントローラ/ターゲットに改められています. また,これまでの役割名の頭文字「M/S」をそのまま当てはめてメイン/サブノード(サブ)とも呼ばれます.以降,このブログではあえてこのメイン/サブノード(サブ)を使います. SPIでは複数のメインが存在できません.必ずひとつのメインと,ひとつまたは複数のターゲット間で通信が行われます. 2. 物理的/電気的特徴 2.1 信号線数:信号名 SPIバスは4線式.同期式シリアル・インターフェースです.同期式シリアル・インターフェースとはクロック信号に同期してデータを送受する方法で,信号線のうちの1本をクロックに使います. データには2本の信号線.メインからサブへのデータとサブからメインへのデータにそれぞれ1本使います.あとのもう1本はチップ・セレクトと呼ばれる信号です.SPIでは転送対象を指定するためのアドレス指定を行う方法がありません.そのためチップセレクト信号を使って,転送対象デバイスを指定します[図1]. 信号名はさまざまな名前で呼ばれる場合があります.次の信号名はOSHWAによる呼称[英語サイト]です. SDO:データ出力 SDI:データ入力 SCK:シリアル・クロック CS:チップセレクト:CS 上記では,SDO,SDIの名称は各チップにおけるデータ入出力の方向が基準になっています.この場合,各ピン名としては明確で良いのですが,メイン/サブ間での信号の方向を示すには不便です, これに代わって回路図上などでよく使われる信号名には以下のようなものもあります.このブログではこれらの語に統一します. MOSI:メインからサブへのデータ(Main Out Sub In) MISO:サブからメインへのデータ(Main In Sub Out) SCLK:シリアル・クロック CS:チップセレクト:CS これらの信号のうちMISOだけはサブからメインへの信号で,それ以外は全てメインからサブへの信号となります.通信中に信号の方向が切り替わることはありません. 図1:コントローラとターゲット.各信号名 信号本数を節約するため,例えば片方向だけの通信が行われる場合,いずれかのデータ線が省略される場合があります. また送受信を時多重にしてデータ線を1本だけで使うことができるようにしたターゲットもも存在します.この場合,メイン側ではMOSI/MISOを抵抗を用いてショートして,信号をまとめます. 2.2 プッシュプル.非転送時のハイ・インピーダンス状態 信号はプッシュプルで出力されます.また非データ転送時のMOSI,MISOの出力はハイ・インピーダンス状態に置かれます.これは複数のサブノードが並列に接続された時に,他の通信に影響を与えないようにするためです. 信号電圧はサブノードのデバイスによって規定されているため,それに合わせてやる必要があります.メイン側とサブノードで電圧が違う場合は電圧変換が必要です. 2.3 クロック周波数 クロック周波数も特に規定はありません.通常は百kHz台から数MHz台のクロックが使われる場合が多く,上限はサブノード・デバイスの仕様によって決められます.高レートでのデータ転送が必要なアプリケーションでは数十MHzのクロックが使われることもあります. またメモリ・デバイスなどでは,MOSIやMISOのデータ線を複数用いて転送レートを上げる応用例もあります. 3. プロトコル データ転送手順を決めるプロトコルも特に厳密な決まりはなく,サブノード・デバイス毎に自由に決められています.メイン側となるマイコンでは様々なサブノード・デバイスをサポートするための設定が用意されています. 基本の転送手順は,転送先のサブノードに接続されたCSをアサートしてから転送を始めます.CSデアサートで転送が終了します.CSのアサートとデアサートはLOWとHIGHの信号で行われますが,この極性はサブノード・デバイスの仕様で規定されます. データのビット順については,多くのデバイスではMSBファーストとなっていますが,これにも例外があります.転送単位とするビット数も特に決まっていません.2ビットから16ビットとしている解説を見たことがありますが,もっと大きいビット長を単位としたサブノードも存在する(例えば64ビットなど)ためこの限りではありません. 3.1 モード SPIには「モード」と呼ばれる設定があります.これはクロックの極性とエッジの選択の組み合わせを指しており,それぞれに2つの設定で4つのモードが存在します[図2]. クロック極性(Polarity)はCPOLと呼ばれる設定で,データ非転送時のSCLKがLOWかHIGHかを決める設定です.メイン側の設定ではを0に設定するとLOW,1ならHIGHになります. エッジの選択(phase)はCPHAと呼ばれます.データのラッチ(取り込み)を最初のクロックエッジで行うか,2番目のエッジで行うかを決める設定です. 0の設定で最初のエッジ,1の設定で2番目のエッジを選択します. CPOLとCPHAを組み合わせてモード0〜3のように表す場合もあります[表2]. さらに,これに加えてチップセレクトの極性が逆のサブノードも存在するので注意が必要です. 図2:モード(CPOL,CPHA)     CPOL CPHA mode=0 0 0 mode=1 0 1 mode=2 1 0 mode=3 1 1 表2:モードとCPOL,CPHA 「データをラッチするエッジ」とは? データはクロックに同期して送受信されますが,クロックの立ち上がり,立ち下がりのどちらかひとつのエッジでデータの変化します. [図3]に立ち下がりでデータが変化する例を示して説明します.メイン側デバイスが出力するSCLKの立ち下がりのタイミングにに合わせて,メイン側はMOSIの,サブノード側はMISOの出力を変化させます.次のデータは次の立ち下がりで切り替わりますが,それまでの間は安定した状態になります.クロックの立ち上がりは,ちょうどこの期間に起こるため,このタイミングに合わせて互いのデータの取り込みを行います.これが「ラッチを行うエッジ」です. 図3:データ(MOSI/MISO)とクロック(SCLK)の同期 3.2 データ転送 チップセレクトがアサートされたのち,クロックに同期してデータを送受信します.サブノードは自身のチップセレクトがアサートされたことを受け,クロックに合わせてデータを取り込み,また出力します. [図4]はSPI転送の一例です.CSアサート中のクロックに合わせてデータがやり取りされます.ロジック回路に慣れている方なら,シフトレジスタによる単純な回路によって実現していることが見て取れると思います. 図4:SPI転送の例   4. 接続トポロジ 4.1 チップセレクトによる並列接続とデイジーチェーン 複数のサブノードは[図5]のように接続します. 各サブノード向けにチップセレクトを用意し,それぞれの信号で送受信先を指定しながら通信を行います. またはCS信号の本数を節約するために縦続接続(デイジーチェーン)を行なって,ビット長を拡張したひとつのサブノードと見做して通信を行う方法も使われます[図6]. 先にも述べましたが,複数の種類のサブノードを同じSPIバスに接続するには注意が必要です. 先に述べたような,「モード」やチップセレクトの極性,さらにデータ・ビット長が同一とは限りません.このため各サブノードへの通信の度に設定を切り替えたり,ハードウェアでの調整が必要な場合があります. 図5:並列接続   図6:デイジーチェーン接続 5. 参考資料 OSHWAによる役割名と信号名 [英語] Wikipediaによる「SPI」のページ:このブログでの信号名やメイン/サブノードのような名称はここの記述に倣った [英語] インターフェース 2024年3月号(CQ出版):特集『ゼロから作るシリアル通信[UART/I2C/SPIをPicoで]』 NXP システム・マネジメントI²C, I3C, SPIセレクタ・ガイド NXPコミュニティ・ブログ:I3C:その次のシリアルバス NXPコミュニティ・ブログ:I²Cバスの概要  [初出:インターフェース 2024年3月号(CQ出版)「I2C&SPIをゼロから作る④…SPIの通信規格」p71-73.ブログ掲載にあたり通信仕様解説部分を抜粋,加筆修正] 変更履歴: 2025-02-03:初版 2025-02-25:「5. 参考資料」の項に「NXP システム・マネジメントI²C, I3C, SPIセレクタ・ガイド」へのリンクを追加 2025-05-01:目次を訂正(項目削除),2.2節の項目名訂正 2026-07-24:「2.1 信号線数:信号名」と「5. 参考資料」内の「OSHWAによる役割名と信号名」へのリンク切れを修正 ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 (既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。) マイコン/プロセッサと周辺デバイス間の通信に使われるSPIバス. あまりに当たり前に使われるこのシリアルバスですが,あえていま,その成り立ちについてまとめてみます. communication standards Interface 日本語ブログ
View full article
SPI Bus Overview (Japanese blog) 0. Table of Contents table of contents What is SPI? 1.1 History and specifications 1.2 Controller/Target or Main/Subnode (Sub) Physical/Electrical Characteristics 2.1 Number of signal lines: Signal names 2.2 Push-pull. High impedance state when not transmitting 2.3 Clock Frequency protocol 3.1 Mode 3.2 Data Transfer Connection Topology 4.1 Parallel connection and daisy chain with chip select Reference materials 1. What is SPI? 1.1 History and specifications The SPI bus is a serial bus specification proposed by Motorola (now NXP Semiconductors) in the United States. The specification is said to have been established in the mid-1980s. SPI stands for " Serial Peripheral Interface " and was developed as a four-wire serial bus used to connect processors and peripheral chips. A three-wire SPI bus is also available as a derivative specification, but the original four-wire system is the basis. SPI has several variations in communication methods, such as signal polarity and data synchronization timing settings, so you need to be aware of this when using it. Like I²C, SPI is used to exchange data between chips, but each has its own advantages and disadvantages, as summarized in [Table 1]. SPI is used for applications that require faster data transfer . This is due to the difference in electrical specifications: I²C drives signals using open drain, while SPI drives signals using push-pull , making it easier to achieve higher speeds. Furthermore, in terms of data transfer speed, SPI is characterized by its ability to perform full-duplex communication, which allows simultaneous transmission and reception. On the other hand, SPI also has some disadvantages. The transfer data length and clock polarity are specified for each destination device, making it difficult to mix multiple types of devices. Also, when connecting multiple devices of the same type, a chip select signal is required for each device, which increases the number of signal lines, and when cascading devices, the data transfer length must be adjusted.   I²C SPI Number of lines 2 Data: SDA Clock: SCL 4 Data: SDO, SDI (MOSI, MISO) Clock: SCLK Chip select: CS speed ~400kHz 1MHz, 3.4MHz, 5MHz depending on mode Several hundred kHz to several tens of MHz Communication Direction bidirectional half duplex Bidirectional full duplex Connection Method Multidrop (parallel) Multiple Controllers vs. Multiple Targets Parallel or Daisy Chain Single Controller vs. Multiple Targets Signal Drive Open Drain (Pull-up resistor required) Push-pull Table 1: Comparison of I²C and SPI   1.2 Controller/Target or Main/Subnode (Sub) In SPI, transfers are also made in a master-slave relationship. Until now, the terms master and slave were commonly used, but these have now been changed to controller and target. They are also called main/subnodes (sub), retaining the initials "M/S" from the previous role names. From now on, this blog will deliberately use the terms main/subnodes (sub). In SPI, multiple mains cannot exist. Communication always takes place between one main and one or more targets. 2. Physical/Electrical Characteristics 2.1 Number of signal lines: Signal names The SPI bus is a four-wire synchronous serial interface. A synchronous serial interface is a method of sending and receiving data in synchronization with a clock signal, using one of the signal lines as the clock. There are two signal lines for data. One is used for data from the main to the sub and the other is used for data from the sub to the main. The other is a signal called chip select. SPI does not have a way to specify an address to specify the transfer target. Therefore, the chip select signal is used to specify the target device [Figure 1]. Signal names may be called by a variety of names. The following signal names are those used by OSHWA : SDO : Data output SDI : Data input SCK : Serial clock CS : Chip Select: CS In the above example, the names SDO and SDI are based on the direction of data input/output on each chip. In this case, the names of the pins are clear, but it is inconvenient to indicate the signal direction between the main and sub. Instead, the following signal names are commonly used on circuit diagrams, etc. This blog will stick to these terms. MOSI : Data from main to sub (Main Out Sub In) MISO : Data from sub to main (Main In Sub Out) SCLK : Serial clock CS : Chip Select: CS Of these signals, only MISO is a signal from the sub to the main, and all others are signals from the main to the sub. The signal direction does not change during communication. Figure 1: Controller and target. Signal names To save on the number of signals, for example when communication is only one way, one of the data lines may be omitted. There are also targets that allow transmission and reception to be time-multiplexed, allowing the use of only one data line. In this case, on the main side, MOSI/MISO are shorted using a resistor to combine the signals. 2.2 Push-pull. High impedance state when not transmitting Signals are output in a push-pull fashion. When no data is being transferred, the MOSI and MISO outputs are placed in a high-impedance state. This is to prevent interference with other communications when multiple subnodes are connected in parallel. The signal voltage is determined by the sub-node device, so it must be adjusted accordingly. If the voltage differs between the main and sub-nodes, voltage conversion is required. 2.3 Clock Frequency There are no specific regulations regarding clock frequencies. Clocks in the hundreds of kHz to several MHz range are typically used, with the upper limit determined by the specifications of the subnode device. Applications requiring high-rate data transfer may use clocks of several tens of MHz. In addition, in memory devices, there are also applications where multiple MOSI and MISO data lines are used to increase the transfer rate. 3. Protocol There are no strict rules regarding the protocol that determines the data transfer procedure, and it is freely determined for each subnode device. The main microcontroller has settings to support various subnode devices. The basic transfer procedure begins by asserting CS connected to the destination subnode. The transfer ends when CS is deasserted. CS is asserted and deasserted using a LOW and HIGH signal, but the polarity is dictated by the subnode device specifications. Many devices use MSB first for data bit ordering, but there are exceptions to this. There is also no specific rule about the number of bits used as the transfer unit. I have seen explanations that say it is 2 to 16 bits, but this is not the case as there are subnodes that use larger bit lengths as units (for example, 64 bits). 3.1 Mode SPI has settings called " modes ," which refer to combinations of clock polarity and edge selection, and there are four modes with two settings each [Figure 2]. Clock polarity is a setting called CPOL , which determines whether SCLK is LOW or HIGH when no data is being transferred. On the main side, setting this to 0 will make it LOW, and 1 will make it HIGH. Edge selection (phase) is called CPHA . This setting determines whether data is latched (taken in) on the first or second clock edge. A setting of 0 selects the first edge, and a setting of 1 selects the second edge. CPOL and CPHA can sometimes be combined to represent modes 0 to 3 [Table 2]. In addition, please note that there are also subnodes with reversed chip select polarity. Figure 2: Mode (CPOL, CPHA)     CPOL CPHA mode=0 0 0 mode=1 0 1 mode=2 1 0 mode=3 1 1 Table 2: Modes and CPOL, CPHA What is the "edge that latches data"? Data is sent and received in sync with the clock, but data changes on either the rising or falling edge of the clock. Figure 3 shows an example of data changing on the falling edge. The main side changes its MOSI output, and the subnode side changes its MISO output, in time with the falling edge of the SCLK output by the main side device. The next data changes on the next falling edge, but until then the state remains stable. The rising edge of the clock occurs exactly during this period, so data is captured from each other in time with this timing. This is the "latch edge." Figure 3: Data (MOSI/MISO) and clock (SCLK) synchronization 3.2 Data Transfer After the chip select is asserted, data is sent and received in synchronization with the clock. When the subnode receives that its own chip select is asserted, it takes in and outputs data in synchronization with the clock. [Figure 4] is an example of an SPI transfer. Data is exchanged in accordance with the clock while CS is asserted. Those familiar with logic circuits will see that this is achieved using a simple circuit using a shift register. Figure 4: Example of SPI transfer   4. Connection Topology 4.1 Parallel connection and daisy chain with chip select Multiple subnodes are connected as shown in [Figure 5]. A chip select is provided for each subnode, and communication is carried out by specifying the sender and receiver using each signal. Alternatively, to reduce the number of CS signals, a daisy-chain connection can be used, and communication can be carried out by treating the subnodes as a single subnode with an extended bit length [Figure 6]. As mentioned earlier, care must be taken when connecting multiple types of subnodes to the same SPI bus. As mentioned earlier, the "mode," chip select polarity, and data bit length may not be the same. For this reason, you may need to switch settings or make adjustments in the hardware each time you communicate with each subnode. Figure 5: Parallel connection   Figure 6: Daisy chain connection 5. Reference materials OSHWA Role and Signal Names [English] Wikipedia page on "SPI" : Signal names and main/subnode names in this blog are based on this description . Interface March 2024 issue (CQ Publishing) : Special feature "Serial communication from scratch [UART/I2C/SPI with Pico]" NXP System Management I²C, I3C, SPI Selector Guide NXP Community Blog: I3C: The Next Serial Bus NXP Community Blog: An Overview of the I²C Bus [Originally published in Interface, March 2024 issue (CQ Publishing), "Building I2C & SPI from Scratch ④... SPI Communication Standards," pp. 71-73. The section explaining the communication specifications has been excerpted and revised for this blog post.] Change history: 2025-02-03: First Edition 2025-02-25: Added a link to the "NXP System Management I²C, I3C, SPI Selector Guide" in section "5. Reference Materials". 2025-05-01: Corrected the table of contents (deleted items), corrected the item name in Section 2.2. 2026-07-24: Fixed broken links in "2.1 Number of Signal Lines: Signal Names" and "5. Reference Materials" to "OSHWA Role Names and Signal Names". ========================= We are currently unable to respond to comments in the "Comment" section of this post. We apologize for the inconvenience, but when making inquiries, please refer to `` Technical Questions to NXP - How to Contact Us( Japanese Blog) ''. (If you are already an NXP distributor or have a relationship with NXP, you may ask the person in charge directly.) SPI bus used for communication between microcontrollers/processors and peripheral devices. Although this serial bus is so commonly used, I would like to take this opportunity to summarize its origins. communication standards Interface Japanese blog
View full article
Hello World with the Model-Based Design Toolbox — Model. Generate. Drive. 1 Every great build starts with "Hello World" Every engineer remembers their first “Hello World” — that small, satisfying moment when an idea typed on a screen suddenly comes to life on a real machine. This series is a take on that same feeling, only this time the “machine” is a car. It’s a demonstrator that looks and behaves like a real vehicle, showcasing the combined use of tools from both the NXP and MathWorks ecosystems. This demo has been showcased at several events, including most recently at the MathWorks booth during Embedded World 2026 and MathWorks Automotive Conference, where the demo video that accompanies this series was filmed. Think of these articles as a guided tour through how the whole thing comes together, piece by piece. ▶ Watch the demo in action — presented at the MathWorks booth, Embedded World 2026 2 Table of Contents • Every great build starts with Hello World • From a model on a laptop to silicon on the bench • From the steering wheel to every node • And it grew up along the way • Built to be rebuilt — and learned from • A demonstrator, not a blueprint • The article series — one domain at a time 3 From a model on a laptop to silicon on the bench How does a car end up running on NXP silicon, starting from a model on a laptop? That’s where the NXP Model-Based Design Toolbox (MBDT) comes in. It acts as the bridge between the MathWorks ecosystem — Simulink and MATLAB — and NXP’s processors and embedded tools. An application is designed and modeled in Simulink, MBDT generates optimized code for the chosen NXP target, and that code is deployed straight onto the hardware. The main advantage of this approach is what it allows before any board is involved: an application can be validated and tuned in simulation first, and hardware that isn’t physically present can simply be simulated in its place. The results: early issue detection, shorter development cycles, and a faster time to market — backed by a toolchain that has been validated end to end. Figure 1. NXP Model-Based Design Toolbox One Pager 4 From the steering wheel to every node At the heart of the demo is a driver-in-the-loop setup: a physical steering wheel and a set of foot pedals feed signals directly into the simulation, where a virtual car is driven in simulation, into an environment developed through a RoadRunner simulated environment. From there, a clear hierarchy carries every input down to the hardware. The main node — an S32N processor — sits at the center: it communicates with the host PC running the simulation and makes the vehicle-level decisions. It then hands those decisions to a zonal node that acts as a gateway, fanning the signals out to the end nodes that handle each function — the front and rear lights, the front and rear parking sensors, the radar, and the steering rack, and, on the traction side, the battery management system and motor control. The effect is immediate and physical: steering and acceleration in the virtual world set the model on the table moving; shifting into reverse spins the motors up in the right direction; and when an obstacle appears behind the physical car, it stops on its own, with the rear lights turning red across every node — just like a production vehicle. Throughout, a live dashboard built with NXP’s FreeMASTER Lite shows the vehicle state as it happens, from the reverse camera to the parking sensors, blending signals from the virtual world with readings from the physical hardware. Figure 2. Demo architecture — main node (S32N), zonal gateway, and end nodes. 5 And it grew up along the way Behind all of these are the core functions of a real car — lighting, parking sensors, steering rack, motor control, and battery management — spread across roughly ten microcontrollers and processors and sixteen NXP evaluation boards and reference designs. There’s no need to unpack every component here, because each one earns its own dedicated article series later on. What’s worth knowing is how it all grew: this didn’t start as today’s car. It began as a battery management system (BMS), then gained cloud connectivity, then motor control — which evolved into a full traction inverter demo — and from there the remaining vehicle domains, from body and lighting to chassis and parking, were layered on one by one until it became a complete vehicle topology. In other words, existing MathWorks and model-based examples were assembled, domain by domain, into a car. 6 Built to be rebuilt — and learn from Why go to all this trouble? Mostly to document the work, share the thinking behind it, and show how to actually use MBDT. A big part of the appeal is that everything runs on NXP evaluation boards, which means the whole thing can be reproduced. There’s no need to redo a complex custom hardware design before starting; the same boards can be picked up to get going right away. That also makes the demo a hands-on learning platform: a place to explore the model-based workflow by doing one domain at a time. Note: A word on scope — this is a proof of concept that demonstrates the development workflow, not production firmware as it stands today. A great path forward is NXP’s CoreRide, which you can read more about on this page: Software-Defined Vehicle Development: NXP CoreRide Platform — but that part will not be covered in this series. Whether the field is automotive, electrification, industrial automation, or robotics — or simply an interest in model-based development — there should be something here worth taking away. 7 A demonstrator, not a blueprint One last note on how to read all of this. This car is a demonstrator, not a reference design. It was built with the hardware that happened to be on hand, so some of the boards and NXP solutions used aren’t necessarily the optimal fit for a given function — for a specific job, a different microcontroller might serve better. The point was never to say “use exactly these parts.” The point is the steps and the approach: the workflow itself, and how the pieces fit together. With that in mind, the articles below each take a part of this build and show how it’s done. Welcome to “Hello World” with the Model-Based Design Toolbox. 8 The article series — one domain at a time Each part of the demo car gets its own dedicated write-up, grouped into the twelve tracks below. As articles go live, the placeholders will be replaced with links. Bookmark this page — it will keep growing. NXP MBDT — How-To & Introduction What is Model-Based Design Toolbox? How to install Model-Based Design Toolbox? MBDT Setup and How-to run an application Develop an MBDT application workflow Create a new model and configure it for NXP Hardware Create a new configuration project using the S32CT How to MBDT Dio Port/Pins FreeMASTER & FreeMASTER Lite Introduction to FreeMASTER Using FreeMASTER block in Simulink Visualize and control variables in FreeMASTER Create web dashboard with FreeMASTER Lite Parking sensors Overview SW & HW Environment Logic Control (Main model overview) Lights Overview SW & HW Environment Logic Control (Main model overview) Motor Control Overview SW & HW Environment Logic Control (Main model overview) Battery Management Systems Overview SW & HW Environment Logic Control (Main model overview) Steering Overview SW & HW Environment Logic Control (Main model overview) Radar Overview SW & HW Environment Processing Chain - NXP Radar SDK Main Node Overview SW & HW Environment Logic Control (Main model overview) Zone Node Overview SW & HW Environment Logic Control (Main model overview) Software & Integration Creating virtual vehicle with MathWorks Overview SW & HW Environment Logic Control Creating Virtual Scenes & Scenarios with MathWorks (RoadRunner & Unreal Engine)  Processor-in-the-Loop (PIL) What is next? Export to & Debug generated code to S32 Design Studio IDE Others Getting Started with FRDM-A-S32K312 using Model-Based Design  Note: This index is updated as new articles are published.
View full article
How to PORT/PINS 1 Table of Contents • Introduction • Pins Configuration • Configure Port Component • Conclusion • References 2 Introduction Before a microcontroller can interact with external hardware, its pins must be configured correctly. Whether you want to read a button state, drive an LED, communicate with a sensor, or use a peripheral, the first step is to configure the corresponding pins. 3 Pins Configuration First, identify the pin you want to use. In this example, we will use the following pin: RGBLED0_RED PTA29 GPIO29 Note: When working in S32 Configuration Tools, the pin MSCR value (third line) is not required. However, it will be needed later if you also configure the same pins in EB tresos. Configure the pins according to their intended use: input, output, or input/output. To begin, open the Pins Tool by clicking the Pins button in the upper-right corner. In the Pins Tool, the pins are organized into Functional Groups. In the default projects provided with the Model-Based Design Toolbox, these groups are arranged based on the peripheral to which the pins are routed. For this step, focus on the Pins tab in the upper-left area of the window. Search for the pin you want to configure; in this example, PTA29. If the desired functionality is already routed to a different pin, first disable that routing by clearing the corresponding selection before assigning it to PTA29. Next, update the identifier and label as needed, then enable the routing by selecting the checkbox on the left. This opens the routing selection dialog. Select SIUL2:gpio,29 , as it matches the intended functionality. A second dialog then prompts you to select the pin direction.   In this example, the LED is configured as Input/Output, matching the configuration used by the example project. Depending on the intended use of the pin, a different direction may be required — for example, a push button is typically configured as an input. Additional examples can be found in the default projects provided with the Model-Based Design Toolbox. 4 Configure Port Component The Port component must reflect the same pin configuration defined in the Pins Tool. After returning to the Peripherals Tool, the Port component may be highlighted in red because the pin configuration was modified in the Pins Tool and has not yet been updated in the Port component.   In the default Model-Based Design Toolbox projects, PortPins are grouped into PortContainers according to their associated peripheral, such as Dio_Pins or Can_Pins . Locate the Dio_Pins PortContainer and update the PortPin entries so that they match the values configured in the Pins Tool. The pin will already contain the MSCR value inherited from the Pins configuration. Update the pin name as desired so it can be easily identified in the model, then repeat the process for each additional pin. The PortPin Id uniquely identifies each PortPin entry. The identifier must remain unique across all PortContainers. Note: If a duplicate PortPin Id value is used, the configuration will report an error. Assign a unique PortPin Id value to each configured pin. For example, a configuration containing 40 pins can use identifiers within the range described by the tool configuration. 5 Conclusion Once the pin configuration is complete and the Port component has been updated accordingly, you can continue with the configuration of the software components that will use those pins. 6 References NXP Model-Based Design Toolbox – Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344
View full article
How to DIO 1 Table of Contents • Introduction • Component Configuration  • Conclusion • References 2 Introduction Before configuring the DIO component, make sure that the pins you intend to use have already been configured in both the Pins Tool and the Port component. If not, refer to the previous articles on pins and port configuration. 3 Component Configuration In order to configure the Dio peripheral, press on the Dio component on the left side of the screen for the Dio Configuration tab to be opened. There, press on the Dio Config tab. Understanding how the DioPort and DioChannel are organized might prove useful later. The number present under the DioPort label represents the corresponding value of the Dio port that you want to access. Below you can find a table with the correspondence between the values and the registers. Register half DioPort value AL 0 AH 1 BL 2 BH 3 CL 4 CH 5 DL 6 DH 7 EL 8 EH 9 Each of those is half of a register and together every line forms a 32-bit register. For example, AL and AH contain all the pin values that are assigned to PTA. AL contains the first 16 pins and AH contains the next 16 pins. For example, the RGBLED0_RED pin is assigned to PTA29. From that we can conclude that, since 29 is higher than 15 (the 16th value of AL, since the first value is 0), the PTA29 pin must be assigned to the AH register. To reiterate, the PTA0–PTA15 pins belong to the AL register while the PTA16–PTA31 (the value must be offset by -16 when computing the Id) pins belong to the AH register, and this is true for the rest of the registers too: PTB, PTC, PTD, PTE. Note: When computing the channel Id for pins in the upper half of a port (e.g. PTA16–PTA31), subtract 16 from the pin number. To create a new channel, select the appropriate DioPort and click the + button next to DioChannel. A new channel entry will be created. Fill in the required channel information according to the pin that was previously configured in the Pins Tool and Port component. Repeat this process for each newly configured pin, ensuring that the channel is added under the correct DioPort. 4 Conclusion After configuring the required DioChannels, save the configuration and regenerate the code. The configured DIO channels can then be used by the application to access the corresponding digital inputs and outputs. 5 References NXP Model-Based Design Toolbox – Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344
View full article
Software and Hardware Setup for the S32N55 Communication Hub 1 Table of Contents • Introduction • Required Software • Required Hardware • Communication and Board-Specific Setup • References • Conclusion   2 Introduction The Main Node is the central application target used throughout this project. It sits between the simulation environment running on the host PC and the physical hardware that represents the various vehicle domains. While the previous article introduced the purpose of the Main Node and its role within the overall system, this article focuses on the environment that makes that functionality possible. Developing and validating the Main Node requires more than a target board. The application is modeled, tested, configured, deployed, and monitored using a collection of software tools that work together with the hardware platform. Understanding this environment is important for anyone interested in reproducing the setup or following the remaining articles in the series. This article describes the software components used during development, the hardware platform used to run the application, and the communication infrastructure that connects the Main Node to the rest of the system. Figure 1. Position of the Main Node within the system architecture. 3 Required Software The Main Node software environment combines MathWorks modeling tools with NXP target support and development utilities. Together, these tools provide the workflow used to model the application, generate code, configure the hardware platform, deploy the software, and observe its behavior during validation and runtime analysis. 3.1 Modeling and Application Development The Main Node application is developed as a Simulink model. MATLAB and Simulink are used to describe the behavior of the application before any software is deployed to hardware. Communication interfaces, application states, signal handling, and system-level functionality are assembled and validated within the modeling environment, allowing development to begin long before the target board is involved. The software environment used for this project includes: MATLAB R2024a or newer Simulink Simulink Coder Embedded Coder MATLAB Coder Stateflow These tools provide the code-generation workflow that transforms the model into embedded software capable of running on the target hardware. 3.2 Network Definition and Validation Communication is one of the primary responsibilities of the Main Node. It exchanges information with the simulation environment, the zonal gateways, and the remaining vehicle-domain nodes through a shared CAN network. Vehicle Network Toolbox is used to bring those communication interfaces directly into MATLAB and Simulink. By using the same DBC definitions during development and validation, communication behavior can be verified before deployment and remain consistent across the complete system. The shared DBC maintained with CANdb++ acts as a common communication contract between all participating nodes. Required tools: Vehicle Network Toolbox CANdb++ 3.1 or newer 3.3 Target Support and Code Generation The bridge between the Simulink model and the target hardware platform is provided by the required NXP Model-Based Design Toolbox package. The toolbox provides: Main target platform support Peripheral integration blocks Build integration Deployment support FreeMASTER integration Using these components, the generated software can be executed directly on the target hardware without requiring manual integration of low-level peripheral code. 3.4 Build and Configuration Environment After code generation, the application is built and deployed using the NXP software toolchain integrated inside Model-Based Design Toolbox package. These tools are used to compile, link, and deploy the generated software to the target board. In parallel, EB tresos is used to maintain the low-level configuration required by the Main Node environment. CAN communication, UART telemetry, I2C initialization, interrupt configuration, and board-level peripheral settings are all managed through this configuration flow. Together, these tools ensure that the generated software and the target configuration remain aligned throughout development. 3.5 Runtime Monitoring and Validation Once deployed, the Main Node can be observed through two complementary mechanisms. FreeMASTER Lite provides runtime visibility into application variables and internal states, while CAN analysis tools are used to inspect the communication exchanged across the network. These tools are used throughout development and validation activities to verify both application behavior and network communication. Figure 2. Development workflow used by the Main Node application. 4 Required Hardware Unlike the peripheral nodes, the Main Node is responsible for connecting the simulation environment with the physical hardware network. As a result, the hardware environment includes both the target board and the supporting infrastructure used during development, validation, and system-level execution. 4.1 S32N55 Board The Main Node application executes on an S32N55 board selected for the central application role. Within this setup, the board serves as the central application platform and hosts the software responsible for coordinating communication between the simulation environment and the zonal gateways. The board provides: CAN FD communication interfaces UART communication interfaces Debug and deployment connectivity I2C peripherals Processing resources required by the Main Node application The Main Node target board is the primary hardware platform referenced throughout this article series. 4.2 Host PC The host PC provides the environment used to interact with the full setup. Depending on the activity being performed, it may host: MATLAB and Simulink RoadRunner simulation environments FreeMASTER Lite CAN analysis software The host PC communicates with the Main Node both through the CAN network and through the dedicated telemetry interface used by FreeMASTER. 4.3 CAN Analyzer A CAN analyzer is used during development and validation to monitor network traffic exchanged between the Main Node and the zonal gateways. Beyond debugging, the analyzer also provides a convenient method of validating DBC definitions, message timing, and network integration behavior before the full setup is assembled. 5 Communication and Board-Specific Setup Several aspects of the Main Node environment are specific to the selected target board and are worth understanding before reproducing the setup. 5.1 Communication Topology The Main Node does not communicate directly with every vehicle-domain node. Instead, it exchanges information with the two zonal gateways, which distribute the relevant signals toward the corresponding vehicle-domain nodes. This arrangement keeps the system organized around a zonal architecture while allowing each subsystem to be developed and validated independently. 5.2 CAN Transceiver Initialization One hardware-specific detail of the target board concerns the external CAN transceiver. Note: Before CAN communication becomes available, the transceiver must first be switched from standby mode into normal operation. This transition is not controlled directly through a dedicated GPIO. Instead, it is performed through an I2C-connected port expander located on the board. As a result, the startup sequence requires an I2C initialization step before the FlexCAN controller can begin communication. Figure 3. CAN transceiver enable sequence on the target board. 5.3 FreeMASTER Telemetry Interface In addition to the CAN network, the Main Node exposes runtime telemetry through a dedicated UART connection used by FreeMASTER Lite. This interface is used throughout validation and runtime analysis to visualize application variables and monitor system behavior in real time. 6 References Model-Based Design Toolbox (MBDT) Community NXP S32N Vehicle Super-Integration Processors MathWorks Vehicle Network Toolbox NXP FreeMASTER Run-Time Debugging Tool 7 Conclusion This article introduced the environment used to develop, deploy, and validate the Main Node application. It described the software workflow, the hardware platform, and the communication infrastructure that connect the Main Node to both the simulation environment and the physical hardware network. Particular attention was given to the Main Node's position within the system topology, the UART-based telemetry interface used by FreeMASTER, and the I2C-controlled CAN transceiver initialization required by the target board. The next article moves beyond the enablement layer and focuses on the Main Node application itself, describing the information it receives, the processing it performs, and the outputs it publishes back into the system network.
View full article
Software & Hardware Environment for Parking Sensor System 1 Table of Contents • Introduction • Required Software • Required Hardware • References • Conclusion 2 Introduction This article focuses on the software and hardware environment required to build, deploy, and monitor the parking sensor node. On the software side, it presents the MATLAB/Simulink workflow, NXP's Model-Based Design Toolbox (MBDT) for S32K1xx devices, FreeMASTER, and the supporting build environment. On the hardware side, it describes the S32K144-Q100 evaluation board, the MaxBotix MB1020 ultrasonic sensors, the wiring approach, and the communication/debug interfaces used in the setup. The goal is to provide a clear setup foundation before moving into the next article, where the internal model architecture, control flow, and application behavior will be described in more detail. 3 Required Software The parking sensor application is developed using a model-based workflow built around MATLAB, Simulink, Stateflow, and NXP's MBDT for S32K1xx devices. The Simulink model remains the main development artifact, while the supporting toolchain is used to generate code, build the application, download it to the target board, and monitor the running system. 3.1 MATLAB, Simulink and Stateflow MATLAB and Simulink provide the main environment for developing the parking sensor application model. Simulink and Stateflow are used to organize the application structure, configure the processing blocks, and prepare the model for deployment on the S32K144 target. Figure 1. PSS top-level model in Simulink 3.2 NXP Model-Based Design Toolbox for S32K1xx NXP's Model-Based Design Toolbox (MBDT) for S32K1xx acts as the bridge between the Simulink model and the S32K144 hardware. It provides dedicated blocks for configuring and using the microcontroller peripherals required by the parking sensor node. In this project, MBDT is used for Analog-to-Digital Converter (ADC) acquisition, General-Purpose Input/Output (GPIO) control, Local Interconnect Network (LIN) communication, and FreeMASTER for real-time data visualisation. This allows the model to interact directly with the target hardware without requiring the developer to manually implement low-level peripheral code. The key point for this article is that MBDT keeps the hardware configuration close to the model. The detailed usage of each block and how the blocks are arranged inside the application will be explained in the model architecture article. 3.3 Code Generation and Deployment Flow The application is prepared for embedded deployment through the code generation flow supported by Simulink, Embedded Coder, ARM Cortex-M support, and NXP MBDT. From the developer's perspective, the main workflow remains inside Simulink: the model is configured, generated, built, and deployed to the S32K144 board. NXP's toolchain environment integrated in MBDT provides the compiler and target support used by the build process. In this setup, it does not need to be treated as a separate development step. The generated application can be downloaded to the S32K144-Q100 evaluation board through the MBDT build/deploy workflow using the on-board JTAG debug interface. This keeps the setup straightforward: once MBDT is installed, the application can be built and programmed from the Simulink workflow. 3.4 FreeMASTER FreeMASTER is used as the runtime monitoring tool during development. It provides visibility into the embedded application while it is running on the S32K144 board. In the Parking Sensors System (PSS) setup, FreeMASTER is used to monitor live ADC samples from the ultrasonic sensors, processed distance values, and selected application variables. This helps during bring-up and validation because the developer can check the behavior of the generated application without adding custom debug code. Note: The FreeMASTER channel is separate from the LIN communication used by the parking node to exchange data with the zonal controller. 3.5 Toolchain Versions The following software components are used for this demo setup: Component Version / Variant MATLAB / Simulink / Stateflow R2024a or newer Embedded Coder Matching MATLAB release ARM Cortex-M support Matching MATLAB release NXP MBDT for S32K1xx 4.3.0 FreeMASTER 3.2 or newer These versions define the reference environment used to build and deploy the parking sensor application. 4 Required Hardware The hardware setup is centered on the S32K144-Q100 evaluation board, which acts as the local parking sensor node. Four MaxBotix MB1020 ultrasonic sensors are connected to the board through analog inputs and control lines. The board also connects to the zonal controller over LIN and to the development PC through the FreeMASTER interface. Figure 2. Parking Sensor Node Hardware Setup 4.1 NXP S32K144-Q100 Evaluation Board The S32K144-Q100 evaluation board is the target hardware used for the parking sensor node. It provides the microcontroller platform required to run the generated application and includes the peripherals needed by the demo: ADC channels for the ultrasonic sensor outputs, GPIO pins for sensor control, LIN support for communication with the zonal controller, and a debug interface for programming and monitoring. In this setup, the board performs the hardware-side interaction with the sensors and communication interfaces. Figure 3. S32K144-Q100 Evaluation Board Used for the Parking Sensor Node The board configuration used by the project is summarized below. Setting Value Device S32K144 Package 100-LQFP SRAM size 64 KB External crystal 8 MHz System clock 80 MHz Memory model FLASH Debug interface JTAG The exact configuration is provided by the MBDT configuration block in the Simulink model. 4.2 MaxBotix MB1020 Ultrasonic Sensors The demo uses four MaxBotix MB1020 sensors, also known as LV-MaxSonar-EZ ultrasonic sensors. Each sensor provides an analog voltage output that varies with the measured distance, which makes the device easy to connect to the S32K144 ADC inputs. The sensor also includes an RX pin that can be used as an enable or control input. 4.3 Sensor Wiring and Pin Mapping Each MB1020 sensor is connected to the S32K144-Q100 board using two main signal types. The analog output pin is connected to one ADC input channel, while the RX pin is connected to a GPIO output and can be used by the application to control the sensor. Power and ground are distributed from the evaluation board through the breadboard. The following pin mapping comes from the PSS model connection annotation. Sensor Analog pin to S32K144 RX enable pin to S32K144 SONAR1 — Left AN → PTB2, ADC0_SE6, J2.11 RX → PTA11, J1.2 SONAR2 — Center Left AN → PTB3, ADC0_SE7, J2.9 RX → PTA17, J1.4 SONAR3 — Right AN → PTA0, ADC0_SE9, J5.7 RX → PTD10, J1.6 SONAR4 — Center Right AN → PTA1, ADC0_SE15, J5.5 RX → PTD11, J1.8 Power and ground connections are defined as follows. Signal Connection GND Breadboard black rail → J13.4 on S32K144-Q100 VCC 5 V Breadboard red rail → J3.9 on S32K144-Q100 Figure 4. Sensor Wiring Between the S32K144-Q100 Board and MB1020 Sensors 4.4 ADC Configuration The MB1020 sensors provide analog voltage outputs, so the S32K144 ADC is used to convert these signals into digital values. In the project setup, ADC0 is configured for software-triggered acquisition and uses the channels assigned to the four ultrasonic sensors. Setting Value ADC instance ADC0 Resolution 12-bit Trigger source Software trigger Voltage reference 5 V / 0 V Used channels ADC0_SE6, ADC0_SE7, ADC0_SE9, ADC0_SE15 Averaging Enabled, 4 samples This section describes only the peripheral setup. The timing of the acquisitions and the conversion from ADC values to distance measurements will be covered in the next article. 4.5 LIN Interface to the Zonal Controller The parking node communicates with the zonal controller using LIN. In this setup, the parking node is configured as a LIN slave, while the zonal controller acts as the LIN master. Setting Value Peripheral LPUART2 in LIN mode Node function Slave Baud rate 19200 bit/s Checksum Enhanced LIN 2.x LIN TX pin PTD7 LIN RX pin PTD6 The physical connection between the parking node and the zonal controller uses LIN and ground lines. Signal Zonal board pin Parking S32K144-Q100 pin LIN J31.8 J11.1 GND J31.2 J11.4 4.6 FreeMASTER Debug Channel FreeMASTER uses a dedicated serial channel that allows the developer to monitor the application on the PC while the parking node continues to communicate with the zonal controller. Setting Value Interface LPUART1 Baud rate 115200 bit/s RX pin PTC6 TX pin PTC7 Usage Runtime monitoring and variable visualization 5 References Developing a Parking Sensor System with Model-Based Design Toolbox Model-Based Design Toolbox for S32K Community Model-Based Design Toolbox for S32K How To NXP Support Package for S32K1xx NXP Model-Based Design Toolbox for S32K1 Toolbox Download NXP S32K144 Reference Manual and S32K144-Q100 evaluation board user guide MaxBotix MB1020 / LV-MaxSonar-EZ1 datasheet MathWorks documentation: MATLAB, Simulink, Stateflow, Embedded Coder, ARM Cortex-M support FreeMASTER Run-Time Debugging Tool 6 Conclusion This article described the software and hardware environment required to build and run the Parking Sensor System. The software side is based on MATLAB, Simulink, Stateflow, NXP MBDT, code generation support, and FreeMASTER. The hardware side uses the S32K144-Q100 evaluation board, four MaxBotix MB1020 ultrasonic sensors, ADC input channels, GPIO control lines, LIN communication, and a dedicated FreeMASTER serial channel. With this environment in place, the PSS model can be built, downloaded to the S32K144 board, monitored in real time, and connected to the zonal demo setup. The next article will move inside the model and explain the application architecture, including the sensor acquisition flow, model structure, distance conversion, and LIN communication behavior.
View full article
Developing a Parking Sensor System with Model-Based Design Toolbox 1 Table of Contents • Introduction • Overview • Context • References • Conclusion   2 Introduction Parking assistance systems are a familiar feature in modern vehicles, helping drivers detect nearby obstacles and maneuver the vehicle more safely. In our Hello World with MBDT project, the parking sensor subsystem provides this capability by measuring the distance to nearby objects and supplying that information to the rest of the system. Figure 1 - Physical concept This article introduces the parking sensor system and leads into the next articles in the series, where we will examine how this part of the project is developed. The Parking Sensors System (PSS) focus is set on how Model‑Based Design (MBD) enables the subsystem to be designed, simulated, tested, and deployed rapidly using MATLAB/Simulink and the NXP Model-Based Design Toolbox (MBDT).   3 Overview The role of this subsystem within the overall project describes the main elements that make up the parking sensor application and explains its purpose and behavior at a conceptual level. The article outlines how NXP's MBDT supports the development of this component and how a single model is reused for both front and rear parking modules. It also clarifies how this component fits into the larger project and how it connects to the rest of the components. The importance of this subsystem lies not only in its functional role of acquiring and processing distance information but also in how it demonstrates the efficiency of model‑based workflows. Rather than relying on traditional hand‑written embedded code, the entire application — logic, algorithms, peripheral drivers, timing behavior — can be designed graphically in Simulink. This accelerates development in several ways: Behavior can be simulated on the PC, without flashing hardware. The same model drives both simulation and embedded implementation. Peripheral interactions like Analog‑to‑Digital Converter (ADC) and Local Interconnect Network (LIN) are handled through dedicated blocks, not hand‑written code. Parameter tuning and validation are simplified through FreeMASTER, providing real-time visualization of the embedded system parameters. This accelerates development and ensures that the final embedded behavior matches the tested model. Developing an embedded sensor node application typically involves writing extensive low‑level code, configuring peripherals manually, and iterating slowly through hardware tests. This slows down development, limits experimentation, and creates fragmentation between design and implementation. The parking sensor subsystem demonstrates how Model-Based Design in Simulink solves this problem by enabling the entire feature to be built directly in Simulink. Engineers can model ADC acquisition, LIN communication, filtering logic, and threshold detection using graphical blocks rather than manual code. They can simulate the behavior instantly, refine algorithms quickly, and deploy the design to the microcontroller through automatic code generation. The MBD approach significantly improves the efficiency and reliability of developing, testing, and refining the complete parking sensor application. This series is intended for: Engineers learning Model‑Based Design with MATLAB/Simulink Developers working with NXP automotive microcontrollers Teams building rapid prototypes of embedded measurement and control features Students and researchers studying vehicle architectures Anyone interested in a full, reproducible example of embedded system development using MBDT Readers will gain a clear, step‑by‑step understanding of how a complete embedded feature is designed and implemented using a unified model‑based workflow.   4 Context A key aspect of the design is that the same PSS application developed in Simulink is used for both front and rear parking. Two separate S32K144 boards run the identical autogenerated code — one at the front of the vehicle and one at the rear. This showcases one of the major advantages of MBD: a single validated model can be scaled, cloned, and reused across multiple hardware nodes with minimal parametrization. Figure 2 - Parking System Architecture The purpose of the parking sensor subsystem is to provide a clean, consistent, and rapidly developed interface that delivers accurate distance information to the rest of the system. In the implemented setup, each ultrasonic sensor outputs an analog voltage proportional to distance. This signal is sampled by the ADC (Analog‑to‑Digital Converter) of the S32K144 microcontroller. The embedded application running on the S32K144 performs the acquisition sequence, processes the ADC values to compute distance measurements, and formats the results into a communication frame. The prepared data is then transmitted over the LIN bus to the zonal controller, where it can be further used by higher‑level vehicle functions. All functional aspects — ADC acquisition configuration, signal processing, communication formatting, and diagnostic handling — are defined directly in the Simulink model, enabling rapid refinement and immediate validation through simulation. During development, FreeMASTER is used to monitor live ADC samples from the ultrasonic sensors, observe processed distance values, and validate the behavior of the embedded application before integrating the component into the full system. The parking sensor component (front and rear) is highlighted to show its position in the project setup: Figure 3 - Parking System highlighted within the project Related articles in the series Note: Additional articles in the series, including topics such as Software & Hardware Environment, Architecture & Model Description, Deploy & Validate on Hardware, Final Results and Challenges, will be added here as they become available. Each will explore individual technical details such as ADC acquisition, model structure, filtering logic, and communication behavior introduced in this overview. 5 References Software & Hardware Environment for Parking Sensor System MathWorks Model-Based Design Toolbox for S32K Community Model-Based Design Toolbox for S32K How To NXP Support Package for S32K1xx NXP Model-Based Design Toolbox for S32K1 Toolbox Download These resources provide deeper insight into the tools and methods used to build the subsystem. 6 Conclusion The parking sensor subsystem demonstrates how Model-Based Design accelerates the development of embedded automotive features. By modeling the sensing logic in Simulink, validating behavior through simulation, downloading it automatically using MBDT and monitoring it on hardware with FreeMASTER, the entire application can be developed and deployed from within a single environment. Rather than duplicating the parking sensors logic, the application is implemented as a parameterized Simulink model. Using MBDT, the same model instance can be configured for the front or rear module by adjusting parameters such as communication identifiers. This approach enables consistent behavior across parking modules while minimizing duplication and simplifying maintenance. This article introduced the component's behavior, purpose, and development workflow. The next articles in the series will expand on specific technical aspects, building a complete understanding of the subsystem from model to deployment.
View full article
RT1170用のMCUXpresso IDEを用いた外部フラッシュの設定 現在、MIMXRT1176CVM8Bを搭載したカスタムボードを使用しています。これに加えて、部品番号W25Q01NWの外部フラッシュも使用されています。 しかし、MCUXpresso IDEのコードをこの新しいフラッシュにフラッシュすることはできません。(エラー画面のスクリーンショットを添付します) evkbmimxrt1170_flexspi_nor_config.cにも変更を加えました。 変更されたパラメータは以下のとおりです。 .sflashA1Size = 128u * 1024u * 1024u, // 変更: 新しいフラッシュサイズは 128MB であるため。 他に変更する必要のある設定パラメータはありますか? 前もって感謝します Re: Configuring external flash using MCUXpresso IDE for RT1170 1.8Vの機器なので、あなたの回路図を教えてもらえますか?ところで、フラッシュメモリとSOC間のSPIクロック周波数はどうでしょうか? Re: Configuring external flash using MCUXpresso IDE for RT1170 こんにちは、 @brundasathish さん、 MIMXRT1160/1170ハードウェア開発ガイドの表11「ROMブートローダー周辺のPinMux」に記載されている推奨のFlexSPIまたはQSPIピンを使用しているか確認していただけますか?このドキュメントの確認を強くお勧めします。そこには、ボードレイアウトの推奨事項やデザインチェックリストに関する情報が記載されており、ファーストパスの成功を確保し、ボードのブロードアップ問題を避けるための情報が含まれています。 また、 Secure Provisioning Tool v26.6 の Boot Memory Configuration 機能でフラッシュ設定をテストしてもらえますか?これはFCBの設定を確認するためのものです。 BR ハビブ Re: Configuring external flash using MCUXpresso IDE for RT1170 こんにちは、 @Habib_MS さん。 ご返信ありがとうございます。FlexSPI2をフラッシュ用に構成しました。構成済みのピンは以下のとおりです。これはMCUXpresso IDEのピン構成のスナップショットです。 セキュアプロビジョニングツールを使用してフラッシュメモリの設定を試みました。そして、これが私たちが得た反応です。 前もって感謝いたします Re: Configuring external flash using MCUXpresso IDE for RT1170 こんにちは、 @db16122 さん。 電源電圧は1.8V、クロック周波数は133MHzに設定されています。 Re: Configuring external flash using MCUXpresso IDE for RT1170 こんにちは、 @brundasathish。 FlexSPI2セカンダリピングループから起動するには、RMの表10-1「ROMブートローダー周辺ピンマルチ」に記載されている対応するeFuseを設定する必要があります。以下の画像に示されています。 eFuseのプログラミングは元に戻せない操作であることをご留意ください。対応するヒューズがこの二次的なピン群に十分に焼かれていることを裏付けていただけますか?ヒューズが正しく焼かれているなら、 ブートメモリ構成でフラッシュ設定をもう一度テストしてもらえますか? さらに、このピン構成は低速読み取り操作のみをサポートしており、DQS信号経路を提供しません。したがって、サポートされる最大周波数は、SDRモードでは60MHz、DDRモードでは30MHzです。より詳しい説明が記載されていますので、以下のコミュニティ投稿をご参照ください。 BR ハビブ Re: Configuring external flash using MCUXpresso IDE for RT1170 こんにちは、 @Habib_MS さん。 ご返信ありがとうございます。 現在、MCUのセキュアプロビジョニングツール(シリアルダウンローダー)モードを使って外部フラッシュの設定とテストに取り組んでいます。 外部ブートスイッチのBOOT_CFG[11]ピンを使ってFLEXSPI_INSTANCE=1に設定しました(FLEXSPI2が使われている通りです) FLEXSPI_PIN_GROUP_SEL を有効にするにはどうすればいいですか?MCUのSecure ProvisioningツールのOTP設定を通じてですか??? また、上記のブートスイッチの変更(シリアルダウンローダーモードおよびBOOT_CFG[11] =1)およびMCUセキュアプロビジョニングツール内の以下のブートメモリ設定を取り付けることで、 フラッシュを初期化し、フラッシュの内容を読み取ることができます。 しかし、消去も書き込みもできません。 ブートメモリの設定画面のスクリーンショットを添付します。 ありがとうございます ブルンダ・サティシュ Re: Configuring external flash using MCUXpresso IDE for RT1170 AN12183「FLEXSPI NORフラッシュのデバッグを有効にする方法」の回路図を使用した133MHz設定に関する参考情報 Re: Configuring external flash using MCUXpresso IDE for RT1170 こんにちは、 @brundasathish さん、 はい、 OTP設定 でこれを実現できます。フラッシュメモリの設定が正しく動作していれば、「Convert to Complete FCB」ボタンを使ってFCBを作成し、特に15点からの手順をコミュニティ 投稿で確認できます。そのセクションでは、セキュアプロビジョニングツールがブートメモリ構成を生成する方法についてより詳細な説明を提供しており、ツールによって生成されるパラメータと出力の理解に役立つ可能性があります。 FlexSPI2のセカンダリピングループの最大サポートクロック周波数は、SDRモードで60 MHz、DDRモードで30 MHzであることを付け加えておきます。詳細については、こちらのコミュニティ投稿をご覧ください。 現在使用されている MCUXpressoセキュアプロビジョニングツール のバージョンを教えていただけますか? 最新リリースはv26.06で、このバージョンには以前のリリースと比較して最新の機能強化、バグ修正、および全体的な改善が含まれているため、このバージョンを使用することを強くお勧めします。 BR ハビブ
View full article
IW611 RU 设置 我想请教一下如何设置RU。 对于射频测试,技术人员参照“UM11749”手册第12章进行RU设置测试。但是,当我们编辑配置文件“TF_Config_20MHz.txt”时按照第 12.6 章的示例加载后,输出波形类似于未调制信号,我们无法确认预期的波形。 由于输出的是波形,我们认为文件已正确加载。 配置文件描述如下。 =================================================================== FRAME_CTRL_TYPE=1 \\IEEE_TYPE_CONTROL FRAME_CTRL_SUBTYPE=2 \\TRIGGER 配置持续时间字段 最大持续时间 帧持续时间=5484 \\0x156C 配置触发帧的通用信息字段 HE_trigger_frame.TrigCommonField.TriggerType = BASIC_TRIGGER; \\ HE_trigger_frame.TrigCommonField.UlLen = 1000; \\ 最大限度 HE_trigger_frame.TrigCommonField.MoreTF = FALSE; HE_trigger_frame.TrigCommonField.CSRequired = FALSE; HE_trigger_frame.TrigCommonField.UlBw = TB_BW_20MHZ; HE_trigger_frame.TrigCommonField.LTFType = LTF_1_GI_1_6uS; HE_trigger_frame.TrigCommonField.LTFMode = MU_MIMO_SINGLE_STREAM; HE_trigger_frame.TrigCommonField.LTFSymbol = 0; HE_trigger_frame.TrigCommonField.UlSTBC = FALSE; HE_trigger_frame.TrigCommonField.LdpcESS = TRUE; HE_trigger_frame.TrigCommonField.ApTxPwr = 0 HE_trigger_frame.TrigCommonField.PreFecPadFct = 1; HE_trigger_frame.TrigCommonField.PeDisambig = 0; HE_trigger_frame.TrigCommonField.SpatialReuse = 65535; HE_trigger_frame.TrigCommonField.Doppler = FALSE; HE_trigger_frame.TrigCommonField.HeSig2 = 0x1FF; 保留 TrigCommonField=0;1000;0;0;0;1;0;0;0;1;0;1;0;65535;0;511 配置触发帧的用户信息字段 HE_trigger_frame.TrigUserInfoField.AID12 = (5 & 0xFFF); HE_trigger_frame.TrigUserInfoField.RUAllocReg = 0; HE_trigger_frame.TrigUserInfoField.RUAlloc = 61; 53 (106 音调) HE_trigger_frame.TrigUserInfoField.UlCodingType = CODING_TYPE_LDPC; HE_trigger_frame.TrigUserInfoField.UlMCS = 0; HE_trigger_frame.TrigUserInfoField.UlDCM = FALSE; HE_trigger_frame.TrigUserInfoField.SSAlloc = 0; HE_trigger_frame.TrigUserInfoField.UlTargetRSSI = 80; TrigUserInfoField=5;0;61;1;0;0;0;80 配置触发信号依赖用户信息字段 HE_trigger_frame.BasicTrigUserInfo.MPDU_MU_SF = MPDU_SPACING_MULT_1; \\ HE_trigger_frame.BasicTrigUserInfo.TID_AL = 0; HE_trigger_frame.BasicTrigUserInfo.AC_PL = FALSE; HE_trigger_frame.BasicTrigUserInfo.Pref_AC = TB_AC_VO; BasicTrigUserInfo=0;0;0;0 =================================================================== 如果此描述有任何错误,请告知我。 另外,如果还有其他方法(不使用文件的方法),请告诉我。
View full article
LPC54S018をSPI-MRAM(MR25H40)から起動します。 私はLPC54S018を搭載したEVB LPC54S018M-EVKを購入し、それにSPI-MRAMチップ=MR25H40を接続します。 SPI-MRAM(MR25H40)からLPC54S018にファームウェアをロードする必要があります。MRAMをFLEXCOMM9に接続しました。ファームウェアからこのMRAMへのデータの読み書きは正常にできますが、問題ありません。でもMCUを起動できません。 オシログラムでは(RESET後に)マイクロコントローラのブートROMコードがMRAMと通信し始めるのがデフォルト速度=12 MHz(起動ROMがウェイクアップコマンド(opcode = 0xAB)を送信し、その後「read JEDEC-ID」コマンドを3回送信します(opcode = 0x9F))。その後、SPI上ではそれ以上の活動は発生しない。ウェイクアップコマンドはMRAMによって正常に処理されますが、「JEDEC-ID読み取り」コマンドはメモリによってサポートされていません(MRAMのデータシートによる)。私は、ブートROMコードが「JEDEC-IDの読み取り」コマンドに対する応答を受け取らなかったため、デフォルトの速度で起動を続行するだけだと思っていました。しかし、理由は不明だが、「JEDEC-IDの読み取り」を3回試みた後、ブートプロセスがキャンセルされる。 LPC54S018のISPピンを以下の状態に設定してみました。 1) または ISP0 = high、ISP1 = high、ISP2 = high; 2) または ISP0 = high、ISP1 = low、ISP2 = high。 何も変わりません。マイクロコントローラが起動しません。 「read JEDEC-ID」コマンドへの応答を待たずに、SPIメモリからLPC54S018の起動を続行する方法はありますか? 追伸:負荷処理のオシログラムを添付します。
View full article
How to use S32 Design Studio MCP Integration How to use S32 Design Studio MCP Integration,Are there any relevant materials and documents? Re: How to use S32 Design Studio MCP Integration Hi,  unfortunately the documentation and usage examples are still in development. I hope it will be released soon for external use, but don't know the exact date. 
View full article
LX2160A: Pull down value on receiver for SerDes lanes not used Hello, Chip: LX2160A The application note AN5407 specifies pull down on SerDes lanes if not used:  If some SerDes lanes are a no-connect, pull down their receiver pins to GND. Could you tell me the pull down value please? Or should I connect the receiver pins directly to GND? Thanks. Re: LX2160A: Pull down value on receiver for SerDes lanes not used Hello, The AN5407 language "pull down their receiver pins to GND" is intentionally ambiguous about method — NXP's clarification is that a direct 0 Ω connection to GND is the correct and preferred approach. SerDes power-down Even with the RX pins tied to GND, if the SerDes block remains powered, AN5407 also recommends powering down unused lanes via firmware: configure the General Control 0 register during the PBI phase to power down unused SerDes lanes. If the entire SerDes block is already powered down, individual lane power-down is not needed Regards
View full article