IoT機器の組み込みソフトウェア開発において、Linux環境で高速で安定した無線通信を実現することは不可欠です。特に、多様なIoTデバイスとの連携を支える、Wi-Fi技術の高度な活用は、開発現場では重要なテーマになっています。
Wi-Fiモジュールには、Host-basedと呼ばれるタイプのモジュールがあります。Host-basedタイプのモジュールは、無線通信のソフトウェアスタックを外部プロセッサー（Host
CPU）側に実装します。この構成は、モジュール側の処理負荷を軽減できるため、ホスト側で高度な制御やカスタマイズが可能になります。結果として、アプリケーション要件に応じた柔軟な機能拡張や最適化が可能となります。Host-basedタイプのモジュールを採用すれば、IoT機器や産業用途での多様なニーズに対応しやすくなります。しかし、その一方で、開発環境の構築やビルドプロセスには独自のノウハウが求められます。
本記事では、u-blox社JODY-W3シリーズWi-FiモジュールとNXP社i.MX8評価ボードを例に、Yoctoプロジェクトを活用したLinux開発環境の構築手順を詳しく解説します。ドライバーやファームウェアの統合、ビルド、イメージ書き込み、起動デバッグまで、現場で役立つ実践的なノウハウをご紹介します。
u-blox JODY-W3シリーズがECU開発で選ばれる理由と主要スペック
無線モジュールの 「Host-basedタイプ」と「Standaloneタイプ」の違い
u-bloxは、GNSS測位やWi-Fi・Bluetooth技術を核に、車載向け高精度無線ソリューションを提供するスイスの企業です。u-blox社の無線モジュールには大きく分けて「Host-basedタイプ」と「Standaloneタイプ」の2種類があります。Standaloneタイプはさらに「u-connectタイプ」と「Open CPUタイプ」に分かれます。
Host-basedタイプ
特徴：
モジュール内部にワイヤレスチップセットを搭載し、無線通信のソフトウェアスタックは外部のHost CPU（例：i.MXなど）に実装する方式です。
メリット：
- Host CPU側で高度な制御やカスタマイズが可能
- アプリケーション要件に応じた柔軟な機能拡張や最適化が容易
- 複数の無線規格や独自機能の統合が容易
デメリット：
- 開発環境の構築やビルドプロセスに専門的なノウハウが必要
- Host CPU側のリソース消費が増える
Standalone： u-connect タイプ（ATコマンドベース)
特徴：
無線通信のソフトウェアスタックをモジュール内部に持ち、Host CPUとはUARTなどでATコマンドを使って制御します。
メリット：
- Host CPU側はシンプルなAPIで制御でき、開発負荷が低い
- Host CPUのリソース消費が少なく、組み込みが容易
- 評価や導入が比較的短期間で可能
デメリット：
- カスタマイズ性や拡張性はHost-based型より制限される
- 特殊な要件や高度な制御には不向きな場合がある
Standalone： Open CPUタイプ（ZephyrなどRTOSベース）
特徴：
モジュール内部にCPUを搭載し、無線通信のソフトウェアスタックはRTOS（例：Zephyr）上で動作します。ユーザーアプリケーションやカスタムファームウェアを直接モジュール内に実装できるため、外部Host
CPUなしで単独動作が可能です。
メリット：
- モジュール単体で動作し、外部Host CPUが不要
- 独自アプリケーションや高度な制御ロジックを実装可能
デメリット：
- RTOSやファームウェア開発の知識が必要
- モジュールのリソース制約がある
- Host-based型に比べるとアプリケーションの幅が制限される
u-blox社の無線モジュールの概説は下記Short range radio product overviewの資料をご参照ください。
Host-basedタイプの無線通信モジュールu-blox JODY-W3シリーズを紹介
本記事では、Wi-Fiモジュールとしてu-blox社のHost-basedタイプのJODY-W3シリーズを使用しました。JODY-W3シリーズはNXP製チップセット88Q9098を搭載し、Wi-Fi 6（802.11ax）/ Bluetooth 5.3、車載グレードに対応したハイエンドクラスの無線モジュールです。JODY-W3シリーズはHost-basedタイプに該当し、柔軟なカスタマイズ性と高い性能を活かして、車載や産業用途で幅広く採用されています。
※JODY-W3はBluetooth機能も搭載しているため、正確にはWi-Fi/Bluetoothモジュールですが、本記事ではWi-Fi機能に焦点を当てて解説するため、「Wi-Fiモジュール」と表記を統一します。
u-blox社 M.2タイプのWi-Fiモジュール M2-JODY-377仕様
| 項目 | 内容 |
|---|---|
| モデル名 | M2-JODY-W377 |
| チップセット | 88Q9098 (NXP) |
| Wi-Fi IEEE Standard | Wi-Fi 6 (802.11ac/ax) |
| Wi-Fi Radio Frequency | 2.4GHz / 5GHz |
| Bluetooth | Bluetooth BR/EDR, BLE |
| Bluetooth Qualification | v5.3 |
| Bluetooth profile | HCI |
| インターフェイス | UART PCIe SDIO I2S(PCM) |
u-blox社 M.2タイプのWi-FiモジュールM2-JODY-377外観とブロック図
※M.2タイプはインターフェイス規格の名称で、SSDやWi-FiやBluetoothなどの拡張カード用の小型フォームファクターです。
NXP i.MX8評価ボードとYoctoプロジェクトの魅力
Host-basedタイプのモジュールに最適なNXP i.MX8評価ボードを紹介
NXPは、車載・産業・IoT分野に向けて、Linux対応のアプリケーションプロセッサー（i.MXシリーズ）や無線通信、セキュリティー機能を統合した半導体ソリューションを提供するオランダの企業です。NXP社のi.MX評価ボードは、Armベースの高性能プロセッサーを搭載し、PCIeやSDIO、USBなど豊富なインターフェイスを備えた柔軟な拡張性が特徴です。i.MX評価ボードは、Host-basedタイプのu-blox Wi-Fiモジュールとも容易に接続でき、IoTや組み込みLinux開発に最適な環境を提供します。さらに、Yoctoプロジェクト対応のBSP（Board Support Package）がGitHubで公開されており、ドライバー統合やカスタムイメージのビルドを効率的に進められる点も大きな利点です。
本記事で使用したi.MX8シリーズ評価ボードの特徴は次の通りです。
NXP社 i.MX8シリーズ評価ボード MCIM8QXP-CPU仕様
| 項目 | 内容 |
|---|---|
| モデル名 | MCIMX8QXP-CPU |
| CPU | i.MX 8QuadXPlus 4x Cortex-A35 @ up to 1.2 GHz |
| OS | Linux, Android, FreeRTOS |
| DDRメモリー | 3 GB LPDDR4 memory×32 |
| 不揮発性メモリー | 32 GB eMMC 5.0, 64 MB Octal SPI Flash |
| デバッグ用インターフェイス | Serial to USB connector, JTAG, |
| M.2コネクター | PCIe, USB, UART, I2C, I2S |
| その他コネクター | 10/100/1000 Ethernet port, USB3.0 TypeC, SD/MMC slot |
NXP社 i.MX8シリーズ評価ボード MCIM8QXP-CPU外観
組み込み開発におけるYoctoプロジェクトとは？
Yoctoプロジェクトは、組み込みLinuxシステムを効率的かつ柔軟に構築するためのオープンソースプロジェクトです。
レイヤー構造とBitBakeによるレシピ管理を活用することで、再現性の高いビルドと高度なカスタマイズが可能になります。
主な特徴は以下の通りです。
- カスタマイズ性の高いLinuxディストリビューションを構築可能
- BSPにより特定ハードウェア向け環境を提供
- Bitbakeとレシピ（.bbファイル）でパッケージやイメージを構築
- meta-layer構造で機能追加やモジュール統合を柔軟対応
特に組み込み分野では、製品ごとに異なるハードウェア構成に対応する必要があるため、Yoctoのような柔軟なビルド環境が広く利用されています。
なお、i.MXにYoctoビルド環境を構築する手順や、使用するPCの性能要件については、ネクスティ
エレクトロニクスの技術コラムで詳しく解説されていますので、参考にしてください。
TIPS 組み込みLinuxビルド環境の落とし穴：メモリー容量とスレッド数の関係
Yoctoプロジェクトで組み込みLinuxのビルド環境を構築する場合は、PCのメモリー容量に注意が必要です。Yoctoビルドは膨大な並列処理を行うため、メモリー不足は致命的です。
本記事で使用したPCは当初8GBメモリーでしたが、スレッド数を制限しないとビルドエラーが頻発しました。メモリーを32GBに増設したところ、スレッド制限なしでも安定してビルドが成功するようになりました。
開発環境構築する際には、PCのメモリーは最低16GB以上、可能なら32GB以上を推奨します。
参考までに、本記事で使用したPCスペックは以下の通りです。
本コラムで使用したビルドPCのスペック（参考）
- モデル名：STYLE-S06M-124-UH3X（IIYAMA製デスクトップPC）
- CPU：Intel® Core™ i5-12400（6コア／12スレッド、最大4.4GHz）
- メモリー：32GB（8GBからDDR増設）
- ストレージ：2.5TB（500GBからSSD増設）
- OS構成：Windows 11（200GB）、Ubuntu 20.04.6 LTS（700GB）
Ubuntu 22.04.5 LTS（300GB）のトリプルブート構成 - WLAN：USB WLANアダプター（WDC-150SU2MWH、IEEE802.11b/g/n対応）
Host-basedタイプのソフトウェアアーキテクチャー
一方、モジュール側は通信機能に専念することができるので、リアルタイムな無線処理を効率的に実行することができます。
※ソフトウェアアーキテクチャーの詳細はu-bloxのJODY-W3シリーズのSystem integration manualの3.4 Software architectureに説明されています。
u-blox社JODY-W3シリーズは、Wi-FiおよびBluetooth機能を備えた高性能無線モジュールであり、Host-basedアーキテクチャーを採用しています。この構成では、無線通信の制御やアプリケーションの実行はホストシステム側（例：NXP社i.MXシリーズ）で行われ、JODY-W3モジュールは主に物理層およびMAC層の処理を担います。
本章では、Host-basedアーキテクチャーの構成要素を、ホストシステム側とモジュール側に分けて解説します。LinuxベースのOS上で動作するプロトコルスタックやデバイスドライバー、ファームウェア管理の仕組み、そしてJODY-W3モジュール内部の無線処理機能について、技術的な観点から詳しく紹介します。
Host-basedタイプu-blox社JODY-W3シリーズのソフトウェアアーキテクチャー
左：ホストシステム、右：モジュール（JODY-W3）
ホストシステム部
アプリケーション層（User application）
ユーザーアプリケーションやサービスがこの層で動作し、Wi-FiやBluetoothを用いたネットワーク通信を実現します。IoTゲートウェイや産業機器など、用途に応じたアプリケーションがここに配置されます。
OS/プロトコルスタック（Host OS/XXX stack）
LinuxカーネルのTCP/IPスタックやcfg80211サブシステムがWi-Fi通信を支え、Bluetooth通信にはBlueZスタックが用いられます。これらのスタックは、標準化されたAPIを通じてアプリケーションと連携し、安定した通信を提供します。
デバイスドライバー層（XXX driver）
Wi-Fi用には、NXP製チップセット向けの専用ドライバー（例：moal/MLANカーネルモジュール）がロードされ、Bluetooth用にはhci_uartドライバーが使用されます。これらのドライバーは、ホスト側にモジュールとの通信インターフェイスを提供し、ファームウェアとの連携を可能にします。
ファームウェア（XXX firmware）
JODY-W3シリーズのようなHost-basedタイプの無線モジュールでは、Wi-FiとBluetoothの制御ファームウェアがホスト側からモジュールへダウンロードされて動作します。ホスト側で管理されるファームウェアは、Wi-FiおよびBluetoothの両機能を統合した「コンボファームウェア（combo firmware）」として提供されます。コンボファームウェアは、Wi-FiとBluetooth両方の無線通信機能を一体で制御するためのコード群で、同一モジュール内で異なる通信方式の同時通信を可能にします。このファームウェアは、モジュール起動時にPCIeやUART経由でロードされます。これにより、モジュールは最新の機能やセキュリティーパッチを反映した状態で動作します。
JODY-W3モジュール部
OTPメモリー
キャリブレーションデータやMACアドレスなど、モジュール固有の情報が格納されており、通信の安定性と識別性を確保します。
ファームウェア（Firmware）
ホストからダウンロードされたファームウェアが動作し、無線通信の制御を担います。なお、ユーザーアプリケーションはホスト側で動作し、JODY-W3モジュール単体ではアプリケーションを実行しません。
【実践】Yocto開発環境の構築手順
Yoctoプロジェクトでi.MXシリーズのビルド環境を構築する際は、Ubuntu上に必要な開発ツールやユーティリティを事前にインストールする必要があります。これにより、クロスコンパイルやパッケージ管理、イメージ生成などのビルドプロセスをスムーズに進められます。 本記事では詳細は割愛しますが、Ubuntuへ開発ツールやユーティリティのインストールから、ビルド環境の構築からビルドディレクトリ作成までの大まかな手順は次の通りです。
1. 各種基本アプリケーションパッケージをインストール（初回のみ）
初回のみ、Ubuntuに必要な開発ツールやユーティリティをインストールします。
$ sudo apt-get install build-essential chrpath cpio debianutils diffstat file gawk gcc git iputils-ping libacl1 liblz4-tool locales python3 python3-git python3-jinja2 python3-pexpect python3-pip python3-subunit socat texinfo unzip wget xzutils
zstd efitoolsエラーメッセージが出なければインストールは正常に完了しています。
2. repoユーティリティをインストール
Yoctoプロジェクトのソース管理に必要なrepoユーティリティをインストールします。
$ sudo apt update
$ sudo apt install curl
$ mkdir -p ~/bin
$ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
$ chmod a+x ~/bin/repo
$ nano .bashrc
$ source ~/.bashrc
nanoコマンドのエディタ機能よって.bashrcファイル(テキスト)の最終行に以下の行を追加します。
export PATH=~/bin:$PATH
cat .bashrcでファイルの中身を確認できます。
エラーメッセージが出なければインストールは正常に完了しています。
3. ローカルGitユーザー情報の設定
BSPをダウンロードするため、PCのローカルGitユーザー名情報を設定します。
git configコマンドで、Gitユーザー名とメールアドレスを設定します。正しく確認されたかを確認するために、git config
–listコマンドでローカルGitユーザー名の設定を確認します。コマンドは以下の通りです。
※ここではGitHubのユーザーアカウント登録の説明は割愛します。
$ git config --global user.name "Your Name"
$ git config --global user.email "Your Email"
$ git config –list実行例は以下の通りです。
$ git config --global user.name "Nexty"
$ git config --global user.email " nexty@nexty-ele.com "
$ git config --list
user.name=Nexty
user.email=nexty@nexty-ele.com
4. Yocto BSPの取得
repoユーティリティを使用して、GitHubからi.MX向けYoctoプロジェクトBSPをダウンロードします。
以下はカーネルバージョン6.1.36-2.1.0
リリース名mickledoreのBSPを指定した例です。
$ mkdir imx-yocto-bsp
$ cd imx-yocto-bsp
$ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-mickledore -m imx-6.1.36-2.1.0.xml$ nano .bashrc
$ repo sync※Linuxカーネルバージョンを変更する場合は、再度BSP構成を行います。
最終的に実行したrepo syncで成功ログが返ってくれば完了です。
repo sync has finished successfully5. ビルドディレクトリの作成
distroコマンドでビルド用ディレクトリを作成します。クリーンビルドを行う場合は、新しいディレクトリを作成してください。
＄cd imx-yocto-bsp
＄DISTRO=fsl-imx-xwayland MACHINE=imx8qxpc0mek source imx-setup-release.sh -b bld-imx8qxpc0mek8ビルドディレクトリ作成コマンドの構文のパラメーターについて以下に説明します。
$ DISTRO=<使用するビルド環境の名前> MACHINE=<ターゲットボードの種類> source imx-setup-release.sh -b <生成するビルドディレクトリ名(任意)>
以下の実施例のようにエラーメッセージなくDISTROコマンドで設定した「生成するビルドディレクトリ名(任意)」のディレクトリに移動して＄に戻って来れば完了。
ディレクトリ「~/imx-yocto-bsp_6136210」でDISTROコマンドを実行し完了すると、配下のディレクトリ「~/imx-yocto-bsp_6136210/bld-imx8qxpc0mek_06」で戻る。
~/imx-yocto-bsp_6136210$ DISTRO=fsl-imx-xwayland MACHINE=imx8qxpc0mek source imx-setup-release.sh -b bld-imx8qxpc0mek_06
Build directory is bld-imx8qxpc0mek_06
Some BSPs depend on libraries and packages which are covered by NXP's
End User License Agreement (EULA). To have the right to use these binaries in
your images, you need to read and accept the following...
中略
Your build environment has been configured with:
MACHINE=imx8qxpc0mek
SDKMACHINE=i686
DISTRO=fsl-imx-xwayland
EULA=
BSPDIR=
BUILD_DIR=.
meta-freescale directory found
~/imx-yocto-bsp_6136210/bld-imx8qxpc0mek_06$
これらの手順は、NXP公式ユーザーズ・ガイド「i.MX Yocto Project User's Guide」に準拠しています。
また、詳細な手順はネクスティ エレクトロニクスの技術コラムでも解説されていますので、参考にしてください。
TIPS Yocto BSPダウンロード時のrepo sync fetchエラー対処法とEULA承認の注意点
Yoctoプロジェクトでi.MXプラットフォーム向けBSPをダウンロードする際、repo syncコマンドでfetchエラーが発生する場合があります。これは、並列処理による負荷やネットワーク不安定が原因です。以下の方法で対処してください。
対処法
repo sync -j1 --fail-fastオプションを使用
並列処理を1スレッドに制限し、エラー発生時に即停止することで、同期を確実に行えます。
EULA承認の注意点
Distroコマンド実行後にEULA（エンドユーザーライセンス契約）の承認を求められた場合は、進捗が100%になるまでyキーを押し続けてください。承認が完了しないとビルドが開始されません。
u-bloxモジュールを組み込む為のビルド環境構築
i.MX8評価ボードでu-bloxモジュールを動作させるには、Yoctoプロジェクトにu-bloxモジュール用のドライバーやファームウェアを統合し、Linuxイメージをビルドする必要があります。本章では、BSP構造の理解から設定ファイルの編集、u-bloxモジュールのソフトウェアリソースの配置方法を解説します。
はじめに、u-bloxモジュールのLinuxイメージをビルドするために、Yoctoプロジェクトに追加・編集したファイル名と機能説明と作業内容をまとめました。
ビルドに必要なファイル名と作業内容
| 項目 | ファイル名 | 機能説明 | 作業内容 |
|---|---|---|---|
| ビルド設定ファイル | bblayers.conf | BBlayersによって、どのmeta-layer(レシピ、設定、クラス、パッチなどを集約した構成単位)をビルド対象にするかを指定 | u-bloxのYoctoレシピを参照するディレクトリの指定 |
| ビルド設定ファイル | local.conf | どのボード向けか（MACHINE）、どんなパッケージやアプリケーションを入れるか（IMAGE_INSTALL）など“ビルド内容”を指定 | u-bloxパッケージグループと機種指定 各種アプリケーションのインストール指定 |
| u-bloxモジュール JODY-W3シリーズ向けドライバー・ファームウェア | PCIE-WLAN-UART-BT-9098-U16-X86-17.68.1.p149.55-17.26.1.p149.55- MXM5X17405_P42_V0V1-MGPL.zip | JODY-W3シリーズのドライバーとファームウェアのパッケージ | BSP内のdownloadsディレクトリに配置 |
| u-blox JODY-W3シリーズ用 RF試験用ツール | 9098_Bridge_and_Native_Labtool_MFG_FW_p230.zip | JODY-W3シリーズのRF試験用MFGパッケージ RF試験用ファームウェア, ブリッジアプリケーション mfgbridge、RF試験アプリケーション Labtoolが含まれる | BSP内のdownloadsディレクトリに配置 |
| u-bloxモジュール統合用Yoctoレシピ | meta-ublox-modulesー2025-05-05 | ドライバーやツールのビルド手順を記述した.bbファイル群。 | opt/Yocto/Archiveディレクトリに配置 |
本章の解説の流れは次の通りです。
1. i.MX Yocto BSPのディレクトリ構造
repoユーティリティによってダウンロードしたBSP内のディレクトリ群の詳細を解説
2. u-bloxモジュールのソフトウェアリソース配置
ドライバー・ファームウェアはdownloadsディレクトリに配置、Yoctoレシピはopt/Yocto/Archiveディレクトリに配置
3. 設定ファイル編集のポイント
- local.conf：u-bloxパッケージグループと機種指定と各種アプリケーションのインストール指定の具体的な方法
- bblayers.conf：u-bloxのYoctoレシピを参照するディレクトリの指定の具体的な方法
4. レシピ編集
u-bloxのYoctoレシピの構造と編集例を解説
Yoctoレシピとは？
Yoctoレシピとは、組み込みLinux開発において、Yoctoプロジェクトで使用されるビルド定義ファイルのことです。Yoctoプロジェクトは、カスタマイズ可能なLinuxディストリビューションを構築するためのオープンソースプロジェクトで、レシピはその中心的な構成要素です。
Yoctoレシピは、以下のような情報を記述するファイルです：
- どのソースコードを使うか（Gitリポジトリ、tarballなど）
- どのようにビルドするか（configure、makeなどの手順）
- どのようにインストールするか（ファイルの配置先など）
- 依存関係（他のレシピとの関係）
- ライセンス情報（GPL、MITなど）
レシピファイルの拡張子は通常
.bb（BitBake）です。
レシピにすべてのビルド手順・依存関係が明記されているため、誰がどこでビルドしても同じ結果が得られるのが最大のメリットです。Yoctoレシピを活用すれば、ビルドの再現性が高まり、依存関係やライセンスの管理が容易になります。また、柔軟なカスタマイズが可能で、製品開発の効率と品質向上に貢献します。複数のアーキテクチャーや開発環境に対応できる点も大きな利点です。
１．i.MX向けYoctoプロジェクトのBSPディレクトリ構造
ここでは、NXPのi.MXシリーズ向けYoctoプロジェクトのBSPディレクトリ構造と、その役割をわかりやすく解説します。ビルドディレクトリ、sourcesディレクトリ、downloadsディレクトリの特徴や用途を整理し、開発者が効率的にビルド環境を構築できるようにすることを目的としています。
本記事で使用するBSPは、repoユーティリティを使ってダウンロードした
imx-linux-mickledore
のマニフェストファイル「imx-6.1.36-2.1.0」を基に構成されています。
このBSPは、「imx-Yocto-bsp_6136210」というディレクトリに格納されています。ファイル名に含まれる「6.1.36」はLinuxカーネルのバージョンを示します。
i.MXのBSPについて
i.MXのBSPは、GitHubのnxp-imx(NXP i.MX Linux BSP Software)配下のnxp-manifestに、現在までのカーネルバージョンのBSPが公開されています。
前章にて
repoユーティリティを用いて上記URLからダウンロードすることは解説しました。
実際にURLを開くと、以下の様にデフォルトでは最新のカーネルバージョンのマニフェストが表示さます。
本記事ではマニュフェストのBranchであるimx-linux-micledoreを使用しています。Branchは、下図の赤枠のプルアダウンで選択できます。
ここには、i.MXプロセッサー向けのマニフェストファイル群を提供しており、YoctoプロジェクトのBSPを構築する際に必要な、レイヤー構成やバージョン情報が記述されたXMLファイルが含まれています。
BSPディレクトリ構造と相関図
BSPディレクトリには、ビルドディレクトリ、sourcesディレクトリ、downloadsディレクトリが配置されています。
下図は本記事で解説するファイルやディレクトリがBSPの各部とどのように相関しているかを矢印で示しています。
上位のディレクトリの役割は次の通りです：
・ビルドディレクトリ（bld-imx8qxpc0mek_XX）
DISTROコマンド実行時に生成されるディレクトリで、生成したビルド結果を格納し、confディレクトリ内にビルド設定ファイル（bblayers.confとlocal.conf）を格納。
※XXはビルドのバージョン番号。
・sourcesディレクトリ
BSPを構成するソースコードや設定ファイルを格納。OS、ドライバー、ミドルウェアなどビルドに必要な要素が含まれる。
・downloadsディレクトリ
インターネットから取得した外部ファイルや、手動で追加したパッケージを保存する領域。
ここからは、コマンドを使って実際のディレクトリ構造を確認します。
BSPディレクトリ構造
BSPディレクトリの構造をtreeコマンドで確認します。
bld-imx8qxpc0mek_XXディレクトリ（XXはビルドのバージョン番号）は、DISTROコマンドを実行した際に生成されるビルドディレクトリです。
nexty@nexty:~/imx-yocto-bsp_6136210$ tree -L 1
.
├── README -> sources/base/README
├── README-IMXBSP -> sources/meta-imx/README
├── bld-imx8qxpc0mek_00
├── bld-imx8qxpc0mek_01
├── bld-imx8qxpc0mek_02
├── bld-imx8qxpc0mek_03
├── bld-imx8qxpc0mek_04
├── bld-imx8qxpc0mek_05
├── bld-imx8qxpc0mek_06
├── bld-imx8qxpc0mek_07
├── bld-imx8qxpc0mek_08
├── bld-imx8qxpc0mek_09
├── bld-imx8qxpc0mek_10
├── bld-imx8qxpc0mek_11
├── bld-imx8qxpc0mek_12
├── bld-imx8qxpc0mek_13
├── downloads
├── imx-setup-release.sh -> sources/meta-imx/tools/imx-setup-release.sh
├── setup-environment -> sources/base/setup-environment
└── sourcesビルド前のビルドディレクトリ構造
confディレクトリには、ビルド設定ファイルであるbblayers.confとlocal.confが格納されています。
confディレクトリの構造をtreeコマンドで確認します。
nexty@nexty:~/imx-yocto-bsp_6136210$ cd bld-imx8qxpc0mek_06
nexty@nexty:~/imx-yocto-bsp_6136210/bld-imx8qxpc0mek_06$ tree -L 2
.
└── conf
├── bblayers.conf
├── bblayers.conf.org
├── conf-notes.txt
├── local.conf
├── local.conf.org
├── local.conf.sample
└── templateconf.cfgsourcesディレクトリ構造
sourcesディレクトリには、BSPを構成するためのソースコードや設定ファイルが格納されています。OSやドライバー、ミドルウェアなど、ビルドに必要なファイルが含まれています。
sourcesディレクトリの構造をtreeコマンドで確認します。
nexty@nexty:~/imx-yocto-bsp_6136210$ cd sources/
nexty@nexty:~/imx-yocto-bsp_6136210/sources$ tree -L 1
.
├── base
├── meta-arm
├── meta-browser
├── meta-clang
├── meta-freescale
├── meta-freescale-3rdparty
├── meta-freescale-distro
├── meta-imx
├── meta-nxp-demo-experience
├── meta-openembedded
├── meta-qt6
├── meta-security
├── meta-timesys
├── meta-virtualization
└── pokydownloadsのディレクトリ構造の一部
downloadsディレクトリには、ビルドに必要な外部ファイルやパッケージが保存されます。インターネットから取得したファイルや、手動で追加したファイルが格納されています。
downloadsディレクトリの構造をtreeコマンドで確認します。
nexty@nexty:~$ cd imx-yocto-bsp_6136210
nexty@nexty:~/imx-yocto-bsp_6136210/downloads$ tree -L 1
.
├── 9098_Bridge_and_Native_Labtool_MFG_FW_p230.zip
├── 9098_Bridge_and_Native_Labtool_MFG_FW_p230.zip.done
├── Error-0.17029.tar.gz
├── Error-0.17029.tar.gz.done
├── Inflector-0.11.4.crate
├── Inflector-0.11.4.crate.done
├── Jinja2-3.1.2.tar.gz
├── Jinja2-3.1.2.tar.gz.done
├── Linux-PAM-1.5.2.tar.xz
├── Linux-PAM-1.5.2.tar.xz.done
├── Mako-1.2.4.tar.gz
├── Mako-1.2.4.tar.gz.done
├── MarkupSafe-2.1.2.tar.gz
├── MarkupSafe-2.1.2.tar.gz.done
├── NetworkManager-1.42.4.tar.xz
├── NetworkManager-1.42.4.tar.xz.done２．u-blox モジュールのソフトウェアリソース配置
u-blox JODY-WE3シリーズは、NXP製ワイヤレスチップセット88Q9098を搭載しています。BSPディレクトリ配下に、チップセット88Q9098用の次の３つのファイルを配置します：
- Wi-Fi用ドライバーとファームウェア
- RF試験用のMFGパッケージ (試験用のため必要に応じて）
- u-bloxモジュールの統合用Yoctoレシピ
これらのファイルを入手するには、u-blox社とe-LULAと呼ばれるソフトウェアライセンス契約の締結が必要になります。
e-LULA（Electronic u-blox License User Agreement）とは？
u-blox製品（GNSS、セルラー、Wi-Fi、BluetoothなどのモジュールやIC）に付属するソフトウェアやファームウェアを使用する際には、ユーザーはソフトウェアライセンス契約に同意する必要があります。従来の紙ベースの契約と異なり、e-LULAは電子署名に対応しており、Web上で簡単に契約締結が可能になっています。u-blox社とe-LULAを締結するには代理店によるサポートが必要となっています。e-LULAの締結が必要なファイルの入手をご検討の際には、ネクスティエレクトロ二クスまでお問い合わせください。
Wi-Fi用ドライバー・ファームウェア
ファイル名：PCIE-WLAN-UART-BT-9098-U16-X86-17.68.1.p149.55-17.26.1.p149.55-MXM5X17405_P42_V0V1-MGPL.zip
内容：NXP製ワイヤレスチップセット88Q9098向けのWi-FiおよびBluetooth用ドライバーとファームウェアを含むパッケージです。
配置場所：BSPのdownloadsディレクトリに配置しています。
RF試験用のMFGパッケージ
ファイル名：9098_Bridge_and_Native_Labtool_MFG_FW_p230.zip
内容：NXP製ワイヤレスチップセット88Q9098向けのRF試験用ファームウェアおよびブリッジアプリケーション「mfgbridge
」とRF試験アプリケーション「Labtool」を含むパッケージです。これらのドライバーは、技適などの電波認証やアンテナ放射パターン測定などで使用されるものでオプションになります。ユーザーの必要に応じて配置してください。
配置場所：BSPのdownloadsディレクトリに配置しています。
ここで、実際に「Wi-Fi用ドライバー・ファームウェア」と「RF試験用のMFGパッケージ」を配置した後のdownloadsディレクトリ構造をtreeコマンドで確認してみます。図中の黄色枠が配置した２つのファイルです。
u-bloxモジュールの統合用Yoctoレシピ
ディレクトリ名：meta-ublox-modules-2025-05-05
内容：u-bloxモジュールのドライバー、ファームウェア、ツールなどをYoctoビルドに統合するためのレシピ群です。
配置場所：ルートディレクトリ配下のopt/Yocto/Archiveディレクトリに配置しています。
３. 設定ファイルlocal.confとbblayers.confを編集する
distroコマンドで生成されたビルドディレクトリ配下のconfディレクトリには、local.confとbblayers.conf という2つの設定ファイルがあります。これから、これらのファイルを編集し、デフォルト設定にu-bloxモジュールをYoctoに組み込むための設定を追加していきます。
local.confの編集ポイント
local.confファイルに追加が必要な設定は次の通りです。
- u-bloxモジュール用パッケージグループのインストール
- JODY-W3シリーズの機種指定
- 各種アプリケーションのインストール (iperf, hostapd, networkmanagerなど)
- イメージファイルのタイプ指定（wic拡張子のファイル）
- パッケージバージョンの指定
下記が編集後のlocal.confファイルの内容で、赤枠部分が追加した箇所です。
bblayers.conf編集のポイント
bblayers.confファイルに追加が必要な設定は次の通りです。
- u-bloxモジュール用レシピを格納するディレクトリ指定
下記が編集後のbblayers.confの内容で、赤枠部分が追加した箇所です。
４．レシピから不要なモデル向けのファイルを削除する
u-bloxが提供するデフォルトのYoctoレシピには、複数のモジュール（例：JODY-W3、TOBY、LARAなど）に対応するファイルが含まれています。本記事では不要なファイルによるビルドエラーを避けるために、JODY-W3以外の他モデル向けのファイルを削除しました。
レシピの細かな解説は割愛しますが、ファイルの内容をコメントで記載していますので参考にしてください。編集後のレシピ meta-ublox-modulesレイヤーの主なディレクトリ構成は次の通りです。
/opt/Yocto/Archive/meta-ublox-modules-2025-05-05$ tree -L 3
├── CHANGELOG.md ＃変更履歴
├── LICENSE ＃ライセンス情報
├── README.md ＃説明書
├── RELEASE_NOTES.md ＃リリースノート
├── classes ＃ビルド用クラスファイル
│ ├── ubx-compile-qa.bbclass
│ ├── ubx-getversion.bbclass
│ ├── ubx-mrvl-txpowerlimits.bbclass
│ ├── ubx-nxp-txpowerlimits.bbclass
│ └── ubx-sanitize.bbclass
├── conf ＃レイヤー設定ファイル
│ └── layer.conf
├── files ＃追加ライセンスやファームウェア
│ └── additional-licenses
├── recipes-connectivity # hostapdやwpa-supplicantなど無線通信関連レシピ
│ ├── brcm-patchram-plus
│ ├── hostapd
│ ├── mrvl-nci
│ ├── wapi-ap-app
│ ├── wireless-regdb
│ ├── wpa-supplicant
│ └── wpa-supplicant-mrvl-wapi
├── recipes-core ＃u-bloxモジュール用パッケージグループ定義
│ └── packagegroups
├── recipes-devtools ＃LabtoolやMFG パッケージのレシピ
│ ├── jody-w3-labtool ＃JODY-W3用Labtoolのレシピ
│ └── jody-w3-mfg ＃JODY-W3用MFG パッケージのレシピ
└── recipes-kernel #ドライバー関連レシピ
└── jody-w3-driver-pcieuart ＃JODY-W3用ドライバーのレシピ【実践】YoctoプロジェクトにLinuxイメージをビルドする
ここまでの手順を終えたら、u-bloxモジュールを組み込んだYoctoプロジェクトのビルドを実行します。ビルドコマンドはbitbakeです。
ビルドコマンドの詳細については、NXPのユーザーズ・ガイド「i.MX
Yocto Project User's Guide」やネクスティ エレクトロニクスの技術コラムも参考にしてください。
ビルド実行例を以下に示します。
ビルド実行例
nexty@fnexty:~/imx-Yocto-bsp_6136210/bld-imx8qxpc0mek_09$ bitbake core-image-minimal
ビルド成功時ログ抜粋
Loading cache: 100% |
| ETA: --:--:--
Loaded 0 entries from dependency cache.
Parsing recipes: 100%
Time: 0:00:50
Parsing of 3448 .bb files complete (0 cached, 3448 parsed). 5311 targets, 375 skipped, 18 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "2.4.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "ubuntu-20.04"
TARGET_SYS = "aarch64-poky-linux"
MACHINE = "imx8qxpc0mek"
DISTRO = "fsl-imx-xwayland"
DISTRO_VERSION = "6.1-mickledore"
中略
0: linux-imx-6.1.36+gitAUTOINC+04b05c5527-r0 do_compile - 38m49s (pid 990326)
1: rust-llvm-native-1.68.2-r0 do_compile - 34m13s (pid 1101364) 32%
2: mesa-2_23.0.3-r0 do_compile - 5m32s (pid 2254232) 52% |######################################################################
Setscene tasks: 1849 of 1849
WARNING: linux-imx-6.1.36+gitAUTOINC+04b05c5527-r0 do_package_qa: QA Issue: File /usr/src/debug/linux-imx/6.1.36+gitAUTOINC+04b05c5527-r0/drivers/tty/vt/consolemap_deftbl.c in package linux-imx-src contains reference to TMPDIR
File /usr/src/debug/linux-imx/6.1.36+gitAUTOINC+04b05c5527-r0/drivers/video/logo/logo_linux_clut224.c in package linux-imx-src contains reference to TMPDIR
File /usr/src/debug/linux-imx/6.1.36+gitAUTOINC+04b05c5527-r0/lib/oid_registry_data.c in package linux-imx-src contains reference to TMPDIR [buildpaths]
NOTE: Tasks Summary: Attempted 4589 tasks of which 0 didn't need to be rerun and all succeeded.上記のログは全タスクが正常に完了したことを示しています。今回は、ビルド完了まで約2時間を要しました。
TIPS ビルドエラーが発生したときは生成AIを活用しよう！
ビルド中にエラーが発生した場合は、まず表示されたログを確認し、原因を特定することが重要です。近年では、生成AIを活用してログを解析する方法も有効です。エラー内容をAIに入力することで、原因や対策のヒントを得ることができます。
エラー解析に生成AIを活用した例をご紹介します。
Yoctoビルドでfetch系エラーが発生してビルドが中断された？！
Yoctoビルドでは、ネットワーク障害やリポジトリの変更などにより、必要なソースファイルのダウンロードに失敗するfetch系エラーが発生し、ビルドが中断することがあります。実際に、以下のようなエラーログが表示されました。
NOTE: Tasks Summary: Attempted 250 tasks of which 17 didn't need to be rerun and 3 failed.
Summary: 3 tasks failed:
virtual:native:/home/fukumoto/imx-Yocto-bsp_6136210/sources/poky/meta/recipes-devtools/perl/perl_5.36.0.bb:do_fetch
virtual:native:/home/fukumoto/imx-Yocto-bsp_6136210/sources/poky/meta/recipes-devtools/perl-cross/perlcross_1.4.bb:do_fetch
virtual:native:/home/fukumoto/imx-Yocto-bsp_6136210/sources/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_fetch
Summary: There were 7 WARNING messages.
Summary: There were 6 ERROR messages, returning a non-zero exit code.
生成AIにエラーログを入力して対策方法を尋ねたところ、以下のような回答が得られました。
生成AIの回答概要
- エラー解析結果：perl-5.36.0.tar.gz、bzip2-1.0.8.tar.gzなど複数のソースファイル（tar.gz）がURLから取得できない状況。
- 解決策の提案：①ネットワーク接続の確認、②URLの有効性チェック、③必要なファイルを手動でダウンロードし、Yoctoのdownloadsディレクトリに配置、④MIRRORS設定の活用やプロキシ設定の見直し
実際の対処例
提案された解決策のうち、必要なファイルを手動でダウンロードしてYoctoのdownloadsディレクトリに配置する方法を採用したところ、エラーが解消し、ビルドが成功しました。
TIPS ビルド後のイメージファイルはどこにある？！
Yoctoのビルドを実行すると、ビルドディレクトリ（bld-imx8qxpc0mek_XX）が生成されます。ビルド結果は、このビルドディレクトリの中にある複数のサブディレクトリに分散して保存されます。主な保存先は以下の通りです：
主なビルド成果物の保存場所
| ディレクトリ | 内容 |
|---|---|
| tmp/deploy/images/<machine> | 最終的なLinuxイメージ（例：rootfs、kernel、bootloaderなど） |
| tmp/work/<recipe>/<version>/ | 各レシピのビルド中間ファイル、ログ、インストール済みファイルなど |
| tmp/deploy/sdk/ | SDK（クロスコンパイル環境）の成果物 |
| tmp/sysroots/ | ビルド対象のシステムルート（依存ライブラリなど） |
| tmp/sysroots/ | 再利用可能なビルドキャッシュ（高速化に使用） |
<machine> はターゲットボード名（例：imx8qxpc0mekなど）です。
mp/work 以下には、レシピごとのビルドログやインストール内容が詳細に記録されており、トラブルシュートにも役立ちます。
Yoctoビルドを実行すると、tmp/deploy/images/imx8qxpc0mekディレクトリにイメージファイルcore-image-minimal-imx8qxpc0mek-20250623221121.rootfs.wicが生成されたことを確認できます（赤枠）。
ビルド後のディレクトリ構成例（treeコマンド出力）
【実践】ビルドしたYoctoイメージの書き込みから起動とデバッグまで
YoctoのビルドイメージをuuuコマンドでeMMCに書き込む
YoctoでビルドしたLinuxイメージを、i.MX8評価ボードのeMMCに書き込む手順を解説します。
今回使用したi.MX8評価ボード、M.2-JODY-W377モジュール、デバッグPC、ビルドPCの接続構成は以下の通りです。ビルドPC（Ubuntu）は、YoctoでLinuxイメージを生成し、uuuコマンドを使って評価ボードのeMMCへ書き込みます。デバッグPC（Windows）は、Micro
USB経由で評価ボードのデバッグポートに接続し、起動時や書き込み時のログをリアルタイムでモニタリングします。書き込み失敗や起動不良時に、ログ解析をして原因を特定するのに役立ちます。
i.MX8評価ボードへのイメージ書き込みのためのシステム構成図
i.MX8評価ボードへのイメージ書き込みのためのシステム環境の実際の様子
i.MX8評価ボードへのイメージ書き込ためのハードウェアセッティングおよびコマンドの実行の手順は次の通りです：
1．ビルドPC（Ubuntu）とi.MX8評価ボードをUSB Type-Cケーブルで接続します。この接続により、ビルドしたイメージをeMMCへ直接書き込むことができます。
2．デバッグPC（Windows）とi.MX8評価ボードのMicro USBデバッグ端子を接続し、書き込みや起動時のシリアルログをリアルタイムでモニタリングできるようにします。
3．イメージ書き込み前に、M.2-JODY-W377モジュールをi.MX8評価ボードのM.2コネクターへ装着してください。
4．イメージ書き込み時は、i.MX8評価ボードのBOOT MODEスイッチを「SERIAL」に設定します。これにより、USB経由での書き込みモードに切り替わります。
BOOT MODEスイッチのSERIAL設定
5．i.MX8評価ボードの電源を投入後、ビルドPC（Ubuntu）上でイメージファイルが格納されているディレクトリに移動します。
nexty@nexty:~$ cd imx-Yocto-bsp_6136210/bld-imx8qxpc0mek_09/tmp/deploy/images/imx8qxpc0mek6．「uuu」コマンド（NXP社が提供するUniversal Update Utility）を実行し、eMMCへLinuxイメージを書き込みます。
sudo uuu -b emmc_all イメージファイル名
実際にビルドPC（Ubuntu）でuuuコマンドを実行し、i.MX8評価ボードのeMMCへLinuxイメージを書き込みが成功したログの例は次の通りです。
nexty@nexty:~/imx-Yocto-bsp_6136210/bld-imx8qxpc0mek_09/tmp/deploy/images/imx8qxpc0mek$ sudo uuu -b emmc_all core-image-minimal-imx8qxpc0mek-20250623221121.rootfs.wic
[sudo] nexty のパスワード:
uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.182-0-gda3cd53
Success 1 Failure 0
1:113- 3/ 3 [=================100%=================] SDPV: jump -scanlimited 0x800000
1:113-D16810 8/ 8 [Done
「Success 1 Failure 0」と表示されれば、イメージ書き込みは正常に完了しています。失敗した場合は、接続やBOOT MODE設定を再確認してください。
uuuコマンドのインストール方法と詳細な使い方やトラブルシュートについては、ネクスティ エレクトロニクス技術コラム（uuu編）をご参照ください。
i.MX8評価ボードのデバッグ方法：USBシリアル接続とイーサネットSSHの活用術
u-blox JODY-W3を搭載したi.MX8評価ボードのデバッグには、USBシリアル接続とイーサネットSSH接続の2つの方法があります。本記事では、それぞれの手順とポイントをわかりやすく解説します。
共通準備：BOOT MODE設定
デバッグ前に、評価ボードのBOOT MODEスイッチを「eMMC」に設定してください。これにより、eMMCに書き込まれたイメージからLinuxシステムが起動します。
イメージ書き込み後のi.MX8評価ボードのデバッグ環境システムの実際の様子とBOOT MODEスイッチのeMMC設定
1. USBシリアル接続によるデバッグ
この方法は、起動ログをリアルタイムで確認したい場合に有効です。
構成概要
接続方法：デバッグPC（Windows）と評価ボードをMicro USBケーブルで接続
使用ツール：Tera Term（シリアル通信ソフト）
i.MX8評価ボードのUSBシリアルによるデバッグ接続構成
手順
1．デバッグPCとi.MX8評価ボード間をMicro USBで接続します。
2．i.MX8評価ボードの電源を投入します。
3．デバッグPCのデバイスマネージャーで、i.MX8評価ボードがCOMポートとして認識されていることを確認します。
4．Tera Termを起動し、新しいシリアル接続を作成し、該当するCOMポートを選択します。
5．シリアル接続のボーレートを115200bpsに設定します。
6．login:」プロンプトが表示されたら、ユーザー名「root」でログインします。
7．「~#」プロンプトが表示されれば、i.MX８評価ボード上で書き込みイメージによるLinuxシステムが正常に起動しています。
imx8qxpc0mek login: root
root@imx8qxpc0mek:~#8．シャットダウンする際は必ずpoweroffコマンドを実行してから電源を切ります。
root@imx8qxpc0mek:~#poweroff9．初期からの起動ログを確認するには、改めて電源を投入すると初期からの起動ログを確認できます。
2. イーサネットSSH接続によるデバッグ
ネットワーク経由でログインし、より柔軟な操作を行いたい場合に有効です。
構成概要
接続方法：デバッグPCと評価ボードをLANケーブルで接続
使用ツール：Tera Term（SSH接続）
i.MX8評価ボードのイーサネットSSHログインによるデバッグ接続構成
手順
1．デバッグPCとi.MX8評価ボードをLANケーブルで接続します。
2．i.MX８評価ボードに電源を投入します。
3．デバッグPCの「ネットワークと共有センター」を開きます。画面左の「アダプターの設定の変更」をクリックします。
4．インターネット接続の一覧が表示されるので、有線LANである「イーサーネット」のアイコンをダブルクリックします。動作状況の「プロパティ」をクリックすると、「イーサーネットのプロパティ」ウィンドウが開きます。「ネットワーク」タブの「インターネットプロトコルバージョン4 (TCP/IPv4)」を選択して「プロパティ」をクリックします。「インターネットプロトコルバージョン4 (TCP/IPv4)」ウィンドウが開くので、タブ「全般」の「次のIPアドレスを使う」にチェックを入れ、IPアドレス、サブネットマスクを入力してデフォルトゲートウェイとしての固定IPアドレスを設定します。
5．「Wi-Fiのプロパティ」ウィンドウを開き、「共有」タブの「インターネット接続の共有」にチェックを入れWi-Fiとイーサネットのサブネットワークをブリッジします。
6．設定後、一度LANケーブルを抜いて、挿し直します。
7．デバッグPCでPowerShellを起動し、arp -aコマンドを実行します。コマンド出力から、i.MX８評価ボードにDHCPで割り振られたイーサネットのIPアドレスを確認します。図中の赤枠がイーサネットのIPアドレスです。
※IPアドレスが取得できない場合はイーサネットのプロパティ「インターネット接続の共有」のチェックを外してOKした後、手順5～７を試します。
8．Tera Termで新しい接続を作成し、TCP/IP設定で先程取得したi.MX８評価ボードのIPアドレスを入力し、接続します。
9．セキュリティー警告画面が表示された場合は「続行」をクリックします。SSH認証画面が表示されたら、ユーザー名に「root」を入力してOKをクリックします。
10．「~#」プロンプトが表示されれば、i.MX８評価ボードへのイメージ書き込みは成功し、Linuxシステムが正常に起動しています。
11．シャットダウンする際は必ずpoweroffコマンドを実行してから電源を切ります。
root@imx8qxpc0mek:~#poweroffまとめ
本記事では、u-blox社JODY-W3シリーズWi-FiモジュールとNXP社のi.MX8評価ボードを使って、Yoctoプロジェクトを活用したLinux開発環境の構築手順を解説しました。ドライバー・ファームウェアの統合、ビルド、イメージ書き込み、起動デバッグまでの一連の流れや、Host-basedタイプWi-Fiモジュール特有のノウハウについても詳しく紹介しています。
本記事の内容が、組み込みLinux開発やWi-Fiモジュールの導入を検討されている方々の参考になれば幸いです。
導入や評価のご相談はネクスティ
エレクトロニクスまでお気軽にどうぞ！
関連情報
ネクスティ エレクトロニクス 取扱いメーカー：u-blox、NXP
ネクスティ エレクトロニクス 関連記事
お問い合わせ
関連技術コラム
関連製品情報
ソフトウェア保護・暗号化とライセンシングソリューション
Wibu-SystemsのCodeMeterは、ソフトウェアの違法コピー対策、知的財産保護、収益化を強力に実現するソリューションです。
- WIBU-SYSTEMS AG
- ICT・インダストリアル
- スマートファクトリー・ロボティクス
- ソフトウェア
エッジ処理による消費電力低減 第3世代MEMSセンサー
加速度＋ジャイロのモノリシック集積センサ iNEMO™慣性モジュールのご紹介です。センサー内で一定のデータ処理が可能なほか、機能実装を容易に行えます。
- STMicroelectronics
- NEXT Mobility
- ICT・インダストリアル
- スマートファクトリー・ロボティクス
CO2センサーデモシステム
当社開発のCO2センサーデモシステムは、測定したCO2測定値をBLE経由で専用のAndroidアプリへ送信し、測定結果をグラフ表示可能です。
- Infineon Technologies AG
- ICT・インダストリアル
- スマートファクトリー・ロボティクス
Lantronix - Qualcomm IoT Application Processors搭載 System on Module
Lantronixは、Qualcomm IoTプロセッサを搭載したSoMを提供し、AIや5Gを活用したエンドツーエンドソリューションを提供しています。
- LANTRONIX, INC.
- ICT・インダストリアル
- スマートファクトリー・ロボティクス
Qualcomm Automotive Connectivity Solution
Qualcommは、4G/5G、C-V2X、Wi-Fi、Bluetoothを活用した車載インフォテイメント向けの接続ソリューションを提供します。
- Qualcomm Technologies, Inc.
- NEXT Mobility
- ICT・インダストリアル
- スマートファクトリー・ロボティクス
インカーコミュニケーションシステム（ICC）のご紹介 (アナログ・デバイセズ製品ユースケース)
当社が開発したインカーコミュニケーションシステムは、音声信号処理技術により走行中の車内でも同乗者の声が明瞭に聞こえます。
- Analog Devices, Inc.
- NEXT Mobility
