IoT MCU汎用Baseboard

弊社が考えるIoT MCU向き汎用Baseboardを示します。要件は、(1)IoT MCU向き、(2)低価格、(3)入手性の良さです。

Arduino UNOプロトタイプシールド ブレッドボード付き(¥480)と、従来から使ってきたBaseboardを併用した汎用Baseboardの特徴、FRDM-KL25Zを使った3.3V MCUと5V LCDのCMOSデバイス直結適用例を示します。

図1 Arduino UNO プロトタイプ シールド ブレッドボード 付き
図1 Arduino UNO プロトタイプ シールド ブレッドボード 付き

NXP IoT Module Baseboard

“IoT Baseboard”で検索すると、NXPのIoT Module Baseboard($160)が現れます。これは、右下にLPC54018(Cortex-M4/180MHz)をAdd-onし、EthernetやSD Card等の機能追加を行う「専用」Baseboardです。Baseboardに加え、ArduinoコネクタでもLPC54108へ機能追加できることが判ります。

図2 IoT Module Baseboard(UM11079に加筆)
図2 IoT Module Baseboard(UM11079に加筆)

LPC54018専用Baseboardで$160と高価ですが、Arduinoシールドが追加できる点が重要です。つまり、IoT Module Baseboardで基本機能追加、開発用途に応じた機能追加はArduinoシールドやPmodで行うという2通りの機能追加方式です。

Arduinoシールドで、様々なプロトタイピング開発に対応できる訳です。

Arduinoシールド

多くのMCU評価ボードは、上記LPC54018専用Baseboardと同様、Arduinoコネクタで機能追加が可能です。安価で豊富な種類のArduinoセンサシールドが販売中であることがその理由です。

弊社IoT MCU汎用Baseboardも、Arduinoシールドで機能追加できることをポイントと考えました。FRDM-KL25Zを例に説明します。

FRDM-KL25Zは、Arduinoコネクタが未実装ですのでコネクタを追加したのが図3です。Arduinoコネクタは、複数シールドをスタッカブルに装着するため、上側がメス、下側がオスの貫通ピンで構成されます。

図3 Arduinoコネクタ追加のFRDM-KL25Z
図3 Arduinoコネクタ追加のFRDM-KL25Z

Arduinoコネクタピン(青色)と、FRDM-KL25Zピン(赤色)の対応表です。例えば、右下のPTA1は、D0に対応するなど、MCU評価ボード開発時は赤色ピン、これがArduinoコネクタ利用時は青色ピンへ変わります。

図4 Arduinoコネクタピン(青色)とFRDM-KL25Zピン(赤色)対応表
図4 Arduinoコネクタピン(青色)とFRDM-KL25Zピン(赤色)対応表

MCU評価ボードにはArduinoピンのシルク印刷はありません。開発するMCU評価ボードのArduinoコネクタ対応表をよく見て、MCU評価ボードピンとArduinoピンマッピングを間違わないように注意する必要があります。

Arduino UNOプロトタイプシールド プレッドボード付き

図1のArduino UNOプロトタイプシールドは、MCUボード上に装着してもFRDM-KL25Zのタッチセンススライダの操作はできます。また、評価ボード上のLED動作は、プロトタイプシールドのスルーホールから目視できます。

さらに、プロトタイプシールドには、評価ボードRESETに並列接続済みリセットボタンと2個のLED、1個のSWが実装されています(図1回路図参照)。

プロトタイプシールドのLEDとSWは、評価ボードとは未接続ですが、付属のブレッドボードを使って配線すれば、LチカなどのMCU動作確認にも便利に使えます。

※Arduino UNOプロトタイプシールド プレッドボード付きの動作は、5章:3.3V MCUと3.3V LCD接続で示します。

IoT MCU汎用Baseboardと適用例

以上のようにArduino UNOプロトタイプシールドは、Arduinoコネクタを持つMCU評価ボードの機能追加や動作テストに便利に出来ています。

そこで、このプロトタイプシールドを、弊社が従来から使ってきた5V動作Baseboardと併用します。

MCU評価ボードへのIoTセンサやセキュリティ機能などはArduinoシールドで追加、LCDやポテンショメータなどの機能は5V動作Baseboardにより追加、この2通り機能追加で「汎用開発」に使えるIoT MCU Baseboardになります。

MCU評価ボードとして3.3V動作FRDM-KL25Zと、Baseboard実装の「5V動作LCD」とをCMOSデバイス直結で接続した適用例を示します(CMOSデバイス直結は、関連投稿を参照してください)。

図5 IoT MCU汎用BaseboardのFRDM-KL25Z適用例
図5 IoT MCU汎用BaseboardのFRDM-KL25Z適用例

※IoTセンサシールド等を追加する場合は、MCU評価ボード(FRDM-KL25Z)の直上、または直下へスタック装着を想定しています。図5は、IoTセンサシールド等を省略した例と考えてください。

3.3V MCUと3.3V LCD接続

プロトタイプシールドを装着したFRDM-KL25Zへ、前章の「5V動作LCD」の代わりに「3.3V動作LCD」を接続した例も示します。FRDM-KL25Zソフトウェアは、どちらも同じものです。

関連投稿では未検証であった3.3V MCU開発ソフトウェア動作確認に、CMOSデバイス直結を利用し5V動作Baseboardが利用できることが、LCD表示が同じであることにより実証できました。

図6 プロトタイプシールド利用の3.3V MCU評価ボードと3.3V LCD接続例
図6 プロトタイプシールド利用の3.3V MCU評価ボードと3.3V LCD接続例

ブレッドボードに実装したのは、LCD表示コントラスト調整用スライド抵抗です。5V系センサ等と3.3V MCU評価ボードをCMOSデバイス直結時に必須となるMCU入力電流保護抵抗は、ブレッドボードへ実装し対応できます。

まとめ

Arduinoプロトタイプシールドと、従来から弊社が使ってきた5V Baseboard併用の、IoT MCU汎用 Baseboardを示しました。IoT関連の機能追加はArduinoシールドで、LCD等の機能追加は5V Baseboardで行い、低価格、入手性が良く、様々なIoT MCUプロトタイピングに使えます。

最低限必要なロジックをプロトタイプシールド付属ブレッドボードへ実装すれば、3.3V系MCU評価ボードと5V系ハードウェアの制御ソフトウェア開発に、CMOSデバイス直結が使えることを実証しました。

本稿で示したFRDM-KL25Z とIoT MCU汎用Baseboardを使ったKinetis Lテンプレートは、年内に発売予定です。ご期待ください。


FRDM-KL25Z GPIOの使い方

5V耐圧GPIOピンが無い3.3V動作FRDM-KL25Zへ、5V LCDをCMOSデバイス直結で接続し、その動作確認ソフトウェアを開発中です(CMOSデバイス直結は、関連投稿:3.3V MCUと5Vデバイスインタフェースを参照してください)。

開発途中、FRDM-KL25Z搭載MCUのKinetis KL25ファミリに、GPIOの拡張とも言える興味深いFGPIO機能、BME機能を見つけたのでFRDM-KL25Z GPIOの使い方に加え解説します。両機能は、Kinetis KL25の高速化に効果があります。

※FGPIO:Fast GPIO、高速処理でGPIO記述ソースコードからの変更容易。
※BME:Bit Manipulation Engineはレジスタ読書きとビット操作が同時可能なMCU内蔵ハードウェア。コードサイズ削減と高速処理が同時に可能。

FRDM-KL25Z GPIOの使い方

FRDM-KL25ZのGPIO API一覧が下記です。MCUXpresso IDEのソースコード上でgpio_と入力し「Ctrl+スペースキー」を押すと、GPIO_で始まるAPIが一覧表示されます。これが、Content Assist機能です。

MCUXpresso IDEのContent Assistを利用したGPIOの使い方
MCUXpresso IDEのContent Assistを利用したGPIOの使い方

先頭〇がGPIO_API関数、#がdefineで定義したマクロです。GPIO_API本体は、fsl_gpio.hで定義されています。

例えば、GPIO_ClearPinsOutputを選ぶと、残りの変数:GPIO_Type *baseとunit32_t maskを入力すればソースコード上でGPIO_ClearPinsOutput APIの入力完了です。

*baseは、GPIOAやGPIOBなどのポート名、maskは、制御対象ピン以外のマスクです。GPIOBの18番ピンが対象なら、GPIO_ClearPinsOutput(GPIOB, 1<<18)と記述します。

Content Assistの一覧表示リストを見ると、FRDM-KL25ZのGPIO APIに特に変わったAPIはありません。ごく一般的なGPIOの使い方であることが判ります。

GPIOに限らずContent Assistは、APIレファレンスマニュアルを参照するよりAPI選択と変数のソースコード入力が早く便利にできます。もちろん、ユーザが追加定義したマクロでも自動的にリスト表示されます。

FRDM-KL25Z FGPIOの使い方

KL25 Sub-Family Reference Manualの図3-9は、MCUからGPIO Controllerへの経路が、下記2種類あることを示しています。

FGPIOとGPIOアクセスの違い(出展:KL25 Sub-Family Reference Manual)
FGPIOとGPIOアクセスの違い(出展:KL25 Sub-Family Reference Manual)

GPIO:MCUからPeripheral Bridge経由のGPIO Controller制御
FGPIO:MCUからGPIO Controller直接制御(Single-cycle I/Oとも呼ばれる)

特筆すべきは、レジスタ構成がGPIOとFGPIOで全く同じなので、GPIOソースコード記述が、
GPIOB_PTOR = (1<<18);    //  GPIOでFRDM-KL25Zの赤LED:PTB18をトグル
の場合、これをFGPIOへ変える場合は、
FGPIOB_PTOR = (1<<18);  // FGPIOでFRDM-KL25Zの赤LED:PTB18をトグル
とGPIOをFGPIOへ変更すれば済むことです。

※GPIOB_PTOR = (1<<18)は、レジスタ明示記述、同じことをGPIO_APIで記述すれば、GPIO_TogglePinsOutput(GPIOB, 1<<18)となります。どちらもContent Assistが使えます。

但し、2サイクルアクセスGPIOの半分、FGPIOの1サイクルアクセス実効速度を得るには、コンパイラ最適化オプションを、デフォルト最適化なし:None(-O0)から、Optimize (-O1)、または、それ以上にする必要があります。

FRDM-KL25Z BMEの使い方

前章GPIO経路の途中にBMEハードウェアがあります。BMEを使うと、Peripheralsレジスタの読書きとビット操作を同時、つまり、ソースコード記述1個で可能になります。

BMEを使うソースコードは、下記5種類です。

書込み時
・Store Logical AND/OR/XOR (AND/OR/XOR)
・Store Bit Field Insert (BFI)

読込み時
・Load-and-Clear 1 bit (LAC1)
・Load-and-Set 1 bit (LAS1)
・Load Unsigned Bit Filed Extract (UBFX)

アセンブラ記述に似ています。詳細は、KL25 Sub-Family Reference Manualの17章BMEを参照してください。

BMEを使うと、ソースコード記述が減るので、処理時間とコードサイズの両方を軽減でき高速化可能です。

一般的なGPIOソースコードで記述した周辺回路の初期設定や無限ループ内処理をあらためて見直すと、BMEが使える箇所が見つかります。

GPIO、FGPIO、BMEの使い方

最初に1章で示した一般的なGPIO記述でソフトウェアを開発し、最後の高速化手段としてFGPIOやBMEを使うのが良いと思います。理由は、FGPIOは最適化、BMEはソースコード内にレジスタ読書きとビット操作の両方が必要な個所があることが前提だからです。

FGPIOはGPIO記述ソースコードからの変更が容易です。コンパイラデフォルトの最適化なし:None(-O0)でコード変更し、求める高速要件が満たされれば、利用価値は高いでしょう。この場合は、100%の1サイクルアクセス実効速度までは得られませんが、FGPIO高速化ができます。

経験上、最適化利用に筆者は消極的です。様々な副作用もあるからです。

最適化よりも超低消費電力/低コストが特徴のFRDM-KL25Z(Cortex-M0+/48MHz)開発ソフトウェアの再利用が可能で、より高速なFRDM-K64F(Cortex-M4/120MHz)などへMCU変更が可能なら、この方法をお勧めします。

但し、MCU変更ができない時の効果的な高速化手段として、本稿説明のFGPIOとBMEを知っておくことは重要です。

FGPIOやBMEは、低価格で入手性も良いFRDM-KL25Zに初めから実装済みです。Kinetis KL25ファミリMCUの汎用性と高い拡張性を示す良い例だと思います。

旧Freescaleから2013年頃発売と少し古い感もあるMCUですが、十分現役で使えます。

あとがき:3.3V MCUと5V CMOSデバイス直結動作確認完了

STM32G0xテンプレートに使用した3.3V動作MCU:STM32G071RBも5V耐圧GPIOピンは持ちません。しかし、CMOSデバイス直結で5V LCDを駆動し、安定動作を確認しました。

訂正:STM32G071RBには5V耐圧ピンがあります。お詫びして訂正いたします

ソフトウェア開発中の3.3V動作FRDM-KL25Zと5V LCDのCMOSデバイス直結も、同様に問題なく動作するハズです。

FRDM-KL25Z タッチスライダの使い方

FRDM-KL25Z評価ボードのタッチスライダ(Capacitive Touch Slider)の使い方を説明します。

タッチスライダ動作にはのMCU内蔵TSIが必須(出展:Fig1データシート、Fi2ユーザズマニュアル)
タッチスライダ動作にはのMCU内蔵TSIが必須(出展:Fig1データシート、Fi2ユーザズマニュアル)

タッチスライダ

CypressのPSoC 4000S/4100S/4100PSテンプレートでも使用中の指によるタッチユーザインタフェースは、MCU入力手段として人気があります。

NXPの多くのFRDM評価ボードにもFigure2のようにCapacitive Touch Sliderが実装済みですが、これをタッチスライダとして動作させるには、MCU内蔵TSIハードウェアと、これを制御するTSIライブラリの両方が必須です。
※TSI:Touch Sensor Input。

例えば、FRDM-KE02Z40Mでは、TSIハードウェアがMCU非内蔵なためタッチスライダは動作しません。

MCUXpresso SDKのTSI:Touch Sensor Inputサンプルプロジェクト

MCUXpresso SDKのTSIサンプルプロジェクトは、driver_examples>tsi_v4>normalにあります。MCUXpresso SDKの使い方は、関連投稿を参照してください。

MCUXpresso SDKのTSIサンプルプロジェクト
MCUXpresso SDKのTSIサンプルプロジェクト

以降は、サンプルプロジェクトのソースコードを横目で見ながら本稿を読んで頂くと良く分かると思います。が、ソースコードが無い場合には、まとめ章へスキップしてください。

tsi_v4_normal.cを見ると、このサンプルプロジェクトは、MCU内蔵TSIハードウェアをキャリブレーション(L127)後、下記3つの方法でTSIを制御しているサンプルであることが解ります。
※キャリブレーションとは、測定系ハードウェアの測定精度を上げる処理で、ADCなどでも必要です。

  1. (L136)SOFTWARE TRIIGER SACN USING POLLING METHOD
  2. (L159)SOFTWARE TRIIGER SACN USING INTERRUPT METHOD
  3. (L178)HARDWARE TRIIGER SACN

1や2でもTSIソフトウェアライブラリ単独制御ではなく、TSIハードウェア/ライブラリ両方が必須であることに注意してください。3も同様です。

サンプルプロジェクトでは、1~3の方法を順に処理し、各方法の最後にPRINTFで取得値xxxxをConsoleへ出力します。その出力例がreadme.txtにあります。

MCUXpresso SDKのTSIサンプルプロジェクト3方法の動作出力例
MCUXpresso SDKのTSIサンプルプロジェクト3方法の動作出力例

3番目のハードウェア割込み方法設定後、無限ループへ入ります。

このサンプルプロジェクトソースコードは、本来は3サンプルプロジェクトに分離すべきものを、1つにまとめた書き方をしています。つまり、TSIソフトウェアポーリングプロジェクト、TSIソフトウェア割込みプロジェクト、TSIハードウェア割込みプロジェクトを1つにまとめています(ので、少々解りにくいかもしれません)。

TSIソフトウェアポーリングプロジェクト

そこで、TSIソフトウェアポーリングプロジェクトのみを抽出します。

先ずは、ソフトウェアポーリング処理後、他の2方法を飛ばして無限ループへジャンプさせます。例えば、L157のTSI_ClearStatusFlags()の後にgoto LOOP;を追加し、無限ループの前に飛び先ラベルLOOP:を加えます。すると、ポーリング方法のみの処理結果がConsoleへ正常出力されます。

つまり、ソフトウェアポーリングのみで、1回TSI制御ができることが確認できました。

組込み処理は、初期設定と無限ループ内の繰返し処理の2つに分けて考えるのが常套手段です。そこで、ソフトウェアポーリングの方法も、初期設定と繰返し処理の2つへ分けます。

L101~L143がソフトウェアポーリングの初期設定、L143~L157が繰返し処理です(※L143がダブっているのは間違いではありません)。この繰返し処理先頭L143に無限ループに付加したラベルLOOP:を移動し、無限ループ化します(無限ループに加えたラベルは削除してください)。

動作させ、TSIソフトウェアポーリングプロジェクトのみの抽出と連続ポーリング処理が完成です。

他の2方法、TSIソフトウェア割込みプロジェクトや、TSIハードウェア割込みプロジェクトのみを抽出する場合も同様です。3プロジェクトに分離すると、各方法の理解がより深まります。

※FRDM-KL25Zは、TSI channel 9と10の両方を使っています。両チャネルを使うメリットは、2つあります。1つは、その取得値変化から、指がスライダの左右どちらへ移動したかが解ることです。抽出プロジェクトで、その取得値変化の様子を実際に試してください。

TSIタッチスライダパッドの2チャネルの使い方
TSIタッチスライダパッドの2チャネルの使い方

※もう1つのメリットは、タッチ感度が上がることです。上図のように、各チャネルカバー範囲は相補的ですので、片チャネルでタッチ検出するよりも両チャネル検出の方が、より高感度になります。

FRDM-KL25Z タッチスライダの使い方

前章までで、FRDM-KL25ZタッチスライダのSDKサンプルプロジェクト3制御方法を解説しました。

本章は、もっと実用的なタッチスライダの使い方を説明します。

前章のTSIソフトウェアポーリング方法で、TSIチャネル9のみを使い、タッチスライダを物理スイッチの代わりに動作させる使い方です。

この動作は、オリジナルサンプルプロジェクトのTSIハードウェア割込み方法で、タッチスライダを指で触るとLEDがトグル点滅、つまり、スライダではなくタッチパッドとして動作するのと同様です。物理スイッチではないので、経年変化が少ないことが特徴です。

FRDM-KL25Z の性能を100%使ったTSIサンプルプロジェクトでは、タッチスライダ動作も十分可能です。

しかし、FRDM-KL25ZでTSI処理以外にも様々な処理を行う場合は、このタッチパッド的使い方が実用的だと筆者は思います。オリジナルサンプルプロジェクトも、この事を暗に示しているのかもしれません。

FRDM-KL25Z タッチスライダの初期設定

初期設定は、抽出したTSIソフトウェアポーリングプロジェクトの初期設定からチャネル10設定分を削除します。

FRDM-KL25Z タッチスライダの無限ループ内処理

抽出プロジェクトは、無限ループ内でチャネル9と10を「連続計測」しConsole出力しました。実用的な処理では、タッチスライダ処理以外の様々な他の処理を1個のMCUで行うため、この計測処理は(他の様々な処理が間に挟まるため)「離散的」になります。

離散計測処理を行う際の注意点は、チャタリング対策です。

指によるタッチであっても、本当にタッチしたのか、または、たまたま触っただけなのかをソフトウェア側で判断する必要があり、これをチャタリング対策(=入力ノイズ対策)と言います。

例えば、複数回の離散タッチ検出ならば本当のタッチ、1回のみのタッチ検出ならば、触っただけのノイズでタッチと判断しない等です。

まとめ

FRDM-KL25Z評価ボード付属タッチスライダ制御を、MCUXpresso SDK TSIサンプルプロジェクトのソフトウェアポーリング、ソフトウェア割込み、ハードウェア割込みの3方法から解説し、タッチスライダを物理スイッチの代わりに動作させるタッチパッド的な使い方を説明しました。

3方法をまとめたオリジナルサンプルプロジェクトを、方法別に分離プロジェクト化し、初期設定と無限ループ内処理の2つに分け、ループ内処理のソフトウェアチャタリング対策を説明しました。

開発中のKinetis Lテンプレートには、本稿で示したチャタリング対策済みの応用例を添付します。

FRDM-KL25Z VCOMの使い方

FRDM-KL25ZのUARTとPC を、USB経由のVCOM:Virtual COM port接続する方法を説明します。

FRDM-KL25ZのUARTとVCOM接続中のTera Term画面
FRDM-KL25ZのUARTとVCOM接続中のTera Term画面

VCOM:Virtual COM port

MCU評価ボードとPC間は、USBで接続されており、このUSB経由でターゲットMCUのプログラミングやデバッグを行います。前稿説明のJ-TAGハードウェアデバッガの代わりが、評価ボード付属デバッガで、FRDM-KL25Zの場合は、OpenSDAと呼びます。

本ブログ掲載の評価ボード付属デバッガが下表です。ベンダ毎に付属デバッガの呼び名は異なりますが、どれも機能的には同じです(Renesasは、別途E2 Lite/E2ハードウェアデバッガで機能提供します)。

ベンダ毎に呼び名が異なる評価ボード付属デバッガ
ベンダ 評価ボード付属デバッガ 評価ボード例 MCU – PC間通信
NXP OpenSDA/CMSIS-DAP FRDM-KL25Z/LPCXpresso54114 UART
STM ST-Link STM32G071RB UART
Cypress KitProg CY8CKIT-145 UARTとI2C
TI XDS110-ET MSP-EXP432P401R LaunchPad UART
Renesas なし(E2 Lite/E2必須) BlueBoard-RL78G13-64 UART

評価ボード付属デバッガには、ターゲットMCUのプログラミング/デバッグ機能に加え、MCUのUARTとPCのUSB間を橋渡し(=接続)する機能があります。これをVCOM:Virtual COM port接続といい、Tera Termなどのシリアル通信ソフトウェアをPCにインストールすれば、いとも簡単にMCUの UART通信ソフトウェア送受信の動作確認ができます。

※Tera Termの代わりにMCUXpresso IDEプリインストールのSerial Terminalも使えます。

MCUXpresso IDEのTerminalによるTera Termの代用
MCUXpresso IDEのTerminalによるTera Termの代用

UART:Universal Asynchronous Receiver/Transmitter

UARTは、最重要MCU周辺回路です。

古くから装置組込み済みMCUの再プログラミング手段としてUARTは利用されてきました。最新IoT MCUでも、セキュア・ブート、セキュア・ファームウェア更新に使える手段はUARTのみです(関連投稿:STM32G0/G4のRoot of Trustなどを参照してください)。

さらに、MCUXpresso SDKの評価ボード新規プロジェクト作成時でも、最初からActiveな周辺回路はUART0だけです(※UARTの“0”に注意してください)。ボード実装済みのLEDさえ初期値はInactiveです。つまり、UARTを動作させないMCUは無いと言えるでしょう。

UARTソフトウェアの動作確認には、送・受信機能を持つため通信相手が必要で、VCOM接続によりPCが通信相手になるため、最重要周辺回路:UARTソフトウェアの動作確認ができる訳です。

FRDM-KL25ZのVCOM接続方法

前置きが長くなりました。本章から評価ボード:FRDM-KL25Z をOpenSDA経由でVCOM接続する方法を説明します。

結論から言うと、FRDM-KL25ZのVCOM接続には評価ボードに2配線追加が必要です。2配線を追加しTera Termを使ったUART送受信中の画面が写真1です。

  • J1-2とJ2-20配線・・・・・・・UART0_TX:PTA1とUART1_TX:PTE0接続
  • J1-1とJ2-18配線・・・・・・・UART0_RX:PTA2とUART1_RX:PTE1接続

FRDM-KL25Z関連資料は不親切で、この必須配線が分かりにくいので順を追って説明します。が、配線さえ追加すれば、全てのSDK UARTサンプルプロジェクトが正常動作しますので、急ぐ方は、まとめ章へスキップしてください。

MCUXpresso SDK UARTサンプルプロジェクトと回路図

FRDM-KL25ZのMCUXpresso SDK UARTサンプルプロジェクトは、どれもUART0ではなくUART1を使った処理例です。readme.txtには、“USB to Com Converter:USB2COM”をJ2-20/18と配線せよと記載されています。もちろん、別途USB to Com Converterを用意し、このとおり接続すればサンプル動作確認ができるでしょう。

しかし、OpenSDAにUSB to Com Converter と同じVCOM機能が備わっているのにこれを使わない手はありません。

そこで、FRDM-KL25Z回路図Rev.EのSheet 3を見ると、OpenSDAとMCUはUART0で接続済みで、R5とR6でUART1とも並列接続済みなのが判ります。本来ならUSB to Com Converterが無くてもそのままUART1サンプルプロジェクトが動作するハズです。

試しに、サンプルプロジェクトのUART1をUART0へ変更すると、コンパイル時に妙なワーニングが発生しますが、VCOM接続でUART0が動作します(UART0からUART1への変更にはMCUXpresso Config Toolsの使い方を参照してください)。つまり、UART0とOpenSDAは、回路図どおり接続済みな訳です。

R5とR6は実装されていますが、この代わり追加したのが2配線です。

その結果、UART1で全てのサンプルプロジェクトが正常動作します。また、UART0で発生した妙なワーニングもありません。

つまり、SDK付属UART1サンプルプロジェクトの正常動作には、J1-2とJ2-20、J1-1とJ2-18の2配線が必要です。この時UART0は、並列接続を避けるためInactiveにします。

※サンプルプロジェクトは、元々UART0がInactiveです。新規プロジェクト作成の時は、デフォルトActiveなUART0をInactive、UART1をActiveへ変更すると、サンプルプロジェクトがそのまま流用できます。

※評価ボード回路図最新版がRev.Eです。FRDM-KL25Z評価ボード裏側にシールが貼ってあり、回路図版数Rev.Eと一致、R5とR6も実装済みですが正常動作には追加配線が必要でした。回路図と実評価ボードの版数には、留意してください。

まとめ、新開発汎用Kinetis Lテンプレート

UARTとVCOM接続の重要性を示し、FRDM-KL25Z評価ボードで、VCOM接続を使ってMCUXpresso SDK UART1サンプルプロジェクトを正常動作させるには、評価ボードへ2配線を追加する使い方、各種注意点を説明しました。

このFRDM-KL25Z(Cortex-M0+/48MHz、General Purpose = Main Stream)を使って開発中の汎用Kinetis Lテンプレートは、新規プロジェクト作成時のデフォルトActiveなUART0をUART1へ変更済みで、本稿で示したような開発つまずきを回避する各種情報なども添付します。

写真1は、最も簡単なテンプレート応用例のVCOM動作で、評価ボードの赤/緑/青LEDやタッチスライダ、低消費電力動作のKinetis Lソフトウェアを簡単に開発できるテンプレートです。

3.3V動作新Baseboard

Cortex-M0+のKinetis Lは1.71Vから3.6 V動作で、従来弊社が扱ってきた5V Baseboard接続への5V耐圧端子が残念ながらありません。100MHzクラスで3.3V動作のCortex-M4テンプレート開発なども考慮すると、3.3V/1.8V動作用の新しいBaseboardを探し、テンプレート応用例に適用させたいと考えております。

OpenSDA接続トラブル解決方法

ブログ読者様のおかげで、不明だったFRDM評価ボードOpenSDAとMCUXpresso IDE間の接続トラブル解決方法が判明しました。本稿は、このOpenSDA接続トラブル解決方法と、昨今の激しいMCU開発環境変化への開発者対応私案を示します。

OpenSDA v1/v2差

前投稿当日、弊社ブログ読者様からFRDM評価ボードOpenSDA処理トラブル時のJ-Linkハードウェアデバッガによる解決方法と、その根拠となったNXP Communityリンク、さらに、同様のトラブルを抱えた方々向けに、ご提供情報を弊社ブログで共有してくださいとのメールを頂きました。

この場を借りて御礼申し上げます。ありがとうございます。

ご提供情報を基に、FRDM評価ボードOpenSDA v1/v2の差をまとめたのが、下表です。

OpenSDA v1/v2とFRDM評価ボードのまとめ
OpenSDA版数 評価ボード例 開発者 トラブル状況 トラブル解決方法
OpenSDA v1.0 FRDM-KE02Z40M P&E Micro社

(Proprietary)

弊社あり OpenSDA処理MCUをハードウェアデバッガで書換えれば解決の可能性あり
FRDM-KL25Z 弊社なし
OpenSDA v2.0 FRDM-K64F ARM/mbed.org

(Open source)

Community内あり OpenSDA処理MCUをハードウェアデバッガ:SEGGER J-Linkなどで書換えて解決(情報提供者様の解決実績あり)
OpenSDA v2.1以上 FRDM-K22F

OpenSDAにはv1系とv2系があり、v1.0は開発会社:P&E MicroのProprietary製品、v2系はARM/mbed.org開発のオープンソースです。また、新しいFRDM評価ボードの多くはv2.1以上を搭載済みで、v1.0やv2.0は古くからあるFRDM-K64Fなどです(Getting Start with MCUXpresso SDK, Rev.3, 03/2017のTable 1掲載ボードでの比較。この表になぜかFRDM-KE02Z40Mの記載はありません)。

Getting Start with MCUXpresso SDK Rev. 3 03-2017のTable 1
Getting Start with MCUXpresso SDK Rev. 3 03-2017のTable 1

OpenSDA接続トラブル解決方法

OpenSDA v2系のブートローダ更新失敗などにより生じたMCUXpresso IDE接続トラブルは、SEGGER J-Linkなどのハードウェアデバッガを使って、OpenSDA処理MCU:Kinetis K20(Cortex-M4)を、評価ボードのJ-TAGコネクタ経由でユーザが直接再プログラミングすれば解決します。再プログラミング用コードも、オープンソースです(情報提供者様の解決実績もあります)。

しかし残念ながら、弊社トラブル中のFRDM-KE02Z40Mは、OpenSDA v1.0です。OpenSDA 1.0は、処理ソフトウェアがProprietary(非オープンソース)ですので、この処理部分のユーザによる再プログラミングが可能かはCase-by-caseです。

通常Proprietaryソフトウェアは、下記理由で再プログラミングができない場合が多いと思います。

理由:前稿で示したユーザ(筆者)が、Windows 10ストレージサービスを一時停止しなかったブートローダ更新は、MCU側にとってはProprietary処理ソフトウェアの悪意侵害と判断される可能性があります。
侵害と判断された場合には、セキュリティ防御手段としてMCU書込みプロテクトをかけ、再プログラミングはできなくなります。また、Proprietaryなので初めからMCU書換えプロテクト済みの可能性もあります。

※USB経由で行うブートローダ更新と、J-TAG経由のOpenSDA処理MCUソフトウェア書換えは、別物であることに注意してください。

FRDM-KE02Z40M Proprietary OpenSDA v1.0再プログラミングは、トラブル実機で試す必要があります。Proprietaryソフトウェアのため、書換え障壁はオープンソースOpenSDA v2系よりも当然高いと思われます。

J-TAGハードウェアデバッガメリット

評価ボードOpenSDA v1.0再プログラミングに必要となるJ-TAGハードウェアデバッガ価格は、例えばSEGGER J-Linkなら最低€300から、円換算で約¥37,000(2020年7月)からです。

同じ金額で10枚程度の最新MCU評価ボードが購入できるので、個人レベルのJ-TAGハードウェアデバッガ購入は勇気がいります。

J-TAGハードウェアデバッガのメリットは、旧Freescale)Bertrand Deleris氏の組込み向けデバッグ技術の基本(2007年3月:EDN)が良く解ります。マルチコアMCUデバッグや、ハードウェア/ソフトウェアブレークポイント差、セキュリティとDebug/Releaseの関係など参考になりますので、一読をお勧めします。

半導体ライフサイクルとMCU開発者対応私案

半導体製品のライフサイクルと製造中止(EOL)対策(2020年7月、EE Times)によると、多くの半導体製品の平均寿命は、3~5年だそうです。

MCUベンダ各社は、10~15年の安定供給を保証しますが、製品搭載済みMCUの賞味期限は、我々開発者が製品化に1年要したとして、発売後5年程度だと個人的には思います。

※MCU賞味期限≒MCUの差別化特徴を活かした製品が競合他社より優位な期間。IoTセキュリティ、AI機能実装や製造プロセス細分化など今後MCUは激変するハズなので、より短くなると思います。

丁度、新車購入後、2回目の車検(3年+2年=5年)で名目上の減価償却する自動車と同程度です。

COVID-19の影響で少し鈍る可能性もありますが、ADAS(先進運転支援システム)が引っ張る自動車と同様、“MCU製品も5年目安で世代交代を考えるべきだ”と思います。

また、「日本製品」が海外で売れなくなった根本原因(2020年7月、東洋経済オンライン)を読むと、「加点型の完璧主義」の世界基準に対して、日本人の「盆栽のような減点型のミニマムな完璧ものづくり」が日本敗因の1つです。プラス側メリットやそれに費やした見えない労力などは無視する一方、マイナス側の過度な批判は、日本特有かもしれません。

“基準を減点型→加点型へ180度変える努力が日本は必要”になりそうです。

MCU開発環境は、PC OSも含めて常に変化・進化します。そして、それらの環境変化は全て世界基準です。

MCUXpresso IDEは、7月9日にv11.2.0へ、MCUXpresso SDKの多くは、7月19日にv2.8.0へ更新されました。次々に生まれる新MCUや環境変化に対応するためですが、逆にこれら変化・進化に馴染まない従来MCUや減点型対応者も生じます。これらは、徐々に進化と逆らい「ガラパゴス化」している訳です。

MCU開発者は、変化・進化する環境に対して、開発中、または顧客稼働中のMCUが進化に馴染まなくなる兆候・前兆を素早く捉え、最終利用者と協議の上、従来から180度変えた“加点型対応策を取ることが、ワールドワイドなMCU開発者との競争に生き残り、その結果、日本製品も生き残れる方法”だと思います。

ガラパゴス化が全て悪い訳ではありません。しかし、日本MCU開発者がガラパゴス化すれば、その生存確率は確実に下がります。

まとめ、新開発汎用Kinetis Lテンプレート

これまでの章内容をまとめます。

  • 壊れたFRDM-KE02Z40のOpenSDA v1.0 Proprietary再プログラミングには、J-TAGハードウェアデバッガ:37,000円が必要で、OpenSDA v2系とは異なるProprietaryソフトウェアのため、書換え可能かはトラブル実機検証が必須。
  • J-TAGハードウェアデバッガは、MCUコア/ベンダに依存しない強力デバッグツール。
  • 激変MCU環境に対して、加点型へ進化しないと日本MCU開発者はガラパゴス化する。

これらから、FRDM-KE02Z40(Cortex-M0+/40MHz、5V Robust)のOpenSDA v1.0 Proprietary再プログラミングはあきらめ、5V耐圧が特徴であるKinetis Eテンプレートv2改版開発は中止、新たにFRDM-KL25Z(Cortex-M0+/48MHz、General Purpose = Main Stream)を用いた汎用Kinetis Lテンプレート開発に着手しようと考えております。

5V耐圧の代案は、一般的になってきたレベルシフタを用いる方法でKinetis Eテンプレートの最終利用者様への対応をお願いいたします(関連投稿:MCUの5V耐圧ピンを参考にしてください)。

5V耐圧を失う代わりに、FRDM-KE02Z40Mでは実装していましたが動作しないTouch pad (Slider)が、FRDM-KL25Zでは動作します。Touch pad (Slider)動作には、MCU内蔵Touch Sense Input:TSIハードウェアが必須です。FRDM-KE02Z40Mは内蔵されていません。TSIライブラリソフトウェアのみでは動作しないことは、2015年開発のKinetis Eテンプレート v1で確認済みです。

新開発の汎用Kinetis Lテンプレートは、このFRDM-KL25Z内蔵TSIハードウェアとライブラリ使いTouch pad (Slider)を、外付けSW入力の代わりに用います。

FRDM-KL25Z Block Diagram(出典:ユーザズマニュアル)
FRDM-KL25Z Block Diagram(出典:ユーザズマニュアル)

※FRDM-KL25Z搭載のMCU:MKL25Z128VLK4 (Cortex-M0+/48MHz、Flash:128KB、RAM:16KB、66:IOs)は最新MCUとは言えませんが、「低価格、入手性良し、汎用性(Main Stream)、応用範囲の広さ、OpenSDAトラブル無し」が、新規汎用テンプレート開発採用にプラスに働きました。

さいごに

多彩な情報満載のCommunityですが、逆に欲しい答え発見までにかなりの時間・労力がかかるのもCommunityです。

ブログ読者様ご提供Communityリンクのおかげで、短期間で効率的に問題解決法を見つけることができ、さらにJ-TAGハードウェアデバッガなどの関連情報収集、現状テンプレート開発見直しもできました。

ここにあらためて心より感謝いたします。ありがとうございました。

MCUXpresso SDKの使い方

NXP MCUXpresso IDEを使ったFRDM-KE02Z40Mテンプレートv2開発にあたり、MCUXpresso SDKベースのMCUソフトウェアの開発方法を示します。

MCUXpresso SDK全般の使い方

MCUXpresso SDKの全般的な使い方は、IDE付属のGetting Started with MCUXpresso SDKコチラの動画で判ります。どちらも初めてSDK:Software Development Kitを使う時には役立ちますが、具体的にSDKを使ってMCUソフトウェア開発をするにはどうすれば良いのかの説明はありません。

「導入説明だけで活用説明がない」典型例です。

MCUXpresso SDK構造

本稿はソフトウェア開発初心者が、一番知りたいハズだと思うSDKの具体的な使い方:活用の説明をします。SDK全般の使い方:導入説明に関しては、上記リンク先を参照してください。

OpenSDA接続問題

現時点では、FRDM-KE02Z40M(Cortex-M0+/40MHz、5V Robust)のOpenSDAとIDEデバッガ間が接続できない問題があり、代わりにFRDM-KL25Z(Cortex-M0+/48MHz、General Purpose)も使います。FRDM-KL25Zには、接続問題はありません。

※FRDM-KE02Z40MのOpenSDA接続問題は、内容とその解決策を次回以降投稿予定です。

SDK Version

Installed SDK Version (2020-07)
Installed SDK Version (2020-07)

投稿時点のSDK_2.x_FRDM-KE02Z40M(Version 2.7.0)とSDK_2.x_FRDM-KL25Z(Version 2.2.0)が上図です。MCUXpresso IDEへインストールされたSDK Versionが異なることには注意が必要です。

Versionが異なると、SDK提供サンプルプロジェクトやその中身が異なることがあるからです。多くの評価ボードの最新SDK Versionは2.7.0ですので、テンプレートもSDK Version 2.7.0を前提とします。

Hello_worldサンプルプロジェクトと新規作成プロジェクト

Hello_worldサンプルプロジェクト(左)と新規作成Templateプロジェクト(右)
Hello_worldサンプルプロジェクト(左)と新規作成Templateプロジェクト(右)

FRDM-KE02Z40Mのhello_worldプロジェクトが上図(左)です。CMSISやboardなど多くのフォルダがあり、その中にcソースファイルと、hヘッダファイルが混在しています。sourceフォルダ内にhello_world.cとmain関数があります。

このsourceフォルダが、ユーザの開発するc/hファイルを格納する場所で、他のboardフォルダなどは当面無視して構いません。New Projectをクリックし新たなプロジェクト(プロジェクト名:Template)を作成すると、この理由が判ります。

上図(右)が新規作成したTemplateプロジェクトです。sourceフォルダ以外は、hello_worldと同じ構造です。sourceフォルダ内のTemplate.c内に、コメント:/* TODO: inset other… */が2か所あることも判ります。この青色TODOコメントのソース位置は、ソースウインド右端の上下スライダに青で明示されています。

青色TODOコメントは、ソースコードのユーザ追記場所を示します。

最初のTODOコメントの下にユーザ追記インクルードファイルを、次のTODOコメントの下にユーザ宣言や定義を追記し、main関数内にユーザ処理を追記すればTemplateプロジェクトが完成します。

※main関数内にユーザ処理を追記するのは当然のことですので、main関数内にあるべき青色TODOコメントは、省略されています。

MCUXpresso SDK活用のMCUソフトウェア開発方法

前章までのSDK構造をまとめます。

  • ユーザが新規に開発(追記)するソース/ヘッダファイルは、全てsourceフォルダ内に配置
  • IDEが生成したsourceフォルダ>プロジェクト名.cのユーザ追記場所は、目印として青色TODOコメントがあり、上下スライダにも明示される
  • sourceフォルダ以外は、IDEがSDK Versionに応じて自動生成するライブラリフォルダ
  • ライブラリフォルダの中身は、ユーザ編集は不要

SDK付属のサンプルプロジェクトは、SDK構造に基づいてNXPが作成した周辺回路の利用例です。
※サンプルプロジェクトでは、青色TODOコメントは全て省略されています。

MCUが異なっても、同じ処理を行う場合は、sourceフォルダ内のユーザ追記処理も同じハズです。例えば、FRDM-KE02Z40MとFRDM-KL25Zのhello_worldプロジェクト>sourceフォルダ>hello_world.cは、全く同じソースコードで実現できています。

MCU差やSDK Version差は、sourceフォルダ以外のSDK構造部分で吸収されます。導入説明:Getting Started with MCUXpresso SDKの図1は、このことを図示したものです。

MCUXpresso SDK Laysers(出典:Getting Started with MCUXpresso SDK, Rev. 10_06_2019)
MCUXpresso SDK Laysers(出典:Getting Started with MCUXpresso SDK)

もちろん、旧SDK Versionで未提供なAPIが、新SDK Versionで新たに提供される場合もあります。ただ基本的なAPIは、新旧SDKで共通に提供済みです。

FRDM-KE02Z40MのSDK VersionとFRDM-KL25ZのSDK Versionは現時点で異なるため、IDEが自動生成するフォルダ数は異なります。しかし、ユーザ開発(追記)処理が、sourceフォルダ内で全て完結するSDK構造は同じです。

これが、hello_worldサンプルプロジェクトのようにFRDM-KE02Z40MとFRDM-KL25Z両方に共通で記述できるユーザ処理(Application Code)がある理由です。

SDK構造に沿ったsourceフォルダへのユーザ処理追記と、基本的API利用により、汎用的で効率的なMCUソフトウェア開発が出来ることがご理解できたと思います。

あとがき

2章で、「具体的にSDKを使ってMCUソフトウェア開発をするにはどうすれば良いのかの説明はない」と書きました。しかし、本稿で示したSDK活用説明は、ソフトウェア開発者は当然知っていること・・・だから説明がないとも言えます😅。

このように組込みMCU関連の資料は、前提とするソフトウェア知識・経験をどの読者も既に持っており、本稿記述の当たり前の活用説明は省略する(≒すっ飛ばす)傾向があります。

弊社マイコンテンプレートは、初心者~中級レベルの開発者を対象としており、提供テンプレートも本稿で示したSDK活用方法で開発します。ご購入者様が、なぜこのようなテンプレートになったのか疑問を持った時、それに答えるため、このすっ飛ばした省略部分を補う説明を本稿ではあえて加えました😌。

マイコンデータシートの見かた(最終回)

現役STマイクロエレクトロニクスの「メーカエンジニアの立場」から記載された、ユーザ質問の多かった事項を中心にマイコンデータシートの見かたを解説する記事(連載3回目)の最終回を紹介します。

全3回の連載記事内容

第1回:凡例、絶対最大定格、一般動作条件、電源電圧立上り/立下り(2017年10月1日投稿済み
第2回:消費電流、低消費電力モードからの復帰時間、発振回路特性(2017年10月29日投稿済み
第3回:フラッシュメモリ特性、ラッチアップ/EMS/EMI/ESD、汎用IO、リセット回路(←今回の投稿)

マイコンデータシートの見かた

3回分割のマイコン個別機能データシートの見かた、最終回ではSPIとADCの記載データ見かたが当初予定に追加されました。SPIは、接続デバイスがASICやFPGAの場合の注意点、ADCは、アナログ回路なので消費電流が大きくなる点に注意すべきだと記載されています。

当然のことですがデータシートは、データ値の羅列です。従って、そのデータ値の意味と解釈の仕方は、例えば記事図9の赤囲みコメントで付記されたようにすべきです。しかし、普通は残念ながら赤囲みコメントは、データシートには付いていません。

サンプル&ホールドタイプのA-Dコンバーターの電気的特性
サンプル&ホールドタイプのA-Dコンバーターの電気的特性(記事、図9より)

従って、この赤囲みコメントが自然に頭に浮かぶような勉強、半導体の基礎知識がマイコンを使うには必要で、その知識を背景にデータ値を読むことを記事は求めています。

連載3回範囲のデータシート見かたまとめ

  • フラッシュメモリは、高温使用時、データ保持年数が短くなる。データシート記載値は、MCU内部書込み/消去時間であり、書込み開始~終了までの作業時間ではない。書き換えビットが増えると消費電流も増える。
  • EMS/EMI/ESDは、MCUを実装した基板や使用環境に依存。データシート記載値は、MCU「単体の能力」。
  • 汎用IOは、電源電圧を下げると端子駆動能力も下がり、立上り/立下り時間が長くなる。しかし、STM32MCUは、駆動能力をレジスタで設定できるので遅くなることを抑えることができる。
  • MCUリセット回路設計時は、フィルタリング信号幅のグレーゾーンを避けることが必須。
  • SPIは、接続デバイスがASICやFPGAの場合、十分なタイミングマージンが必要。
  • ADCは、アナログ回路のバイアス電流のため消費電流が大きくなる。また電流変動で変換誤差が増える。

全て学んだ後の開発着手では遅い!

開発者に求められるのは、「開発したもの」です。

そして、多くの場合、短い期限付きです。問題は、この期限内で、なにがしかの結果、成果を出さなければ、開発者としてはNGなことです。しかし、成果を出すには勉強、知識も必要です。

初心者は、この勉強、知識の入力時間と、成果の出力時間の配分が上手くありません。ベテランになると知識も増えますが、入出力の時間配分が上手く、結局何らかの成果も生みます。特に開発者は、全行程の自己マネジメント(時間配分)にも注意を払う必要があります。

例を挙げると、夏休みの自由課題を何にし、休み中にどのように仕上げるか、です。もし提出物が無ければ、課題に取り組んでいないのと(殆ど)同じです。

残業時間制約も厳しく、開発者にとっての作業環境は厳しくなる一方です。弊社マイコンテンプレートとMCUベンダ評価ボードとの組合せは、開発者が求められる出力を早期に生み出すツールになると思います。

マイコンデータシートの見かた(その2)

現役STマイクロエレクトロニクスの「メーカエンジニアの立場」から記載された、ユーザ質問の多かった事項を中心にマイコンデータシートの見かたを解説する記事(連載2回目)を紹介します。

全3回の連載記事内容

第1回:凡例、絶対最大定格、一般動作条件、電源電圧立上り/立下り(2017年10月1日投稿済み
第2回:消費電流、低消費電力モードからの復帰時間、発振回路特性(← 今回の投稿)
第3回:フラッシュメモリ特性、ラッチアップ/EMS/EMI/ESD、汎用IO、リセット回路

記事タイトル:データシート数値の “裏の条件” とは

先入観を与える前に、記事を読んでください。消費電流、復帰時間、発振回路特性の留意点が記述されています。記事タイトルの “裏の条件” とは何でしょうか?

私は、データシート数値は、理想的動作環境のマイコン単体の最高数値、これが裏の条件と理解しています。
例えば、車の性能を燃費で比較する方は、普通の運転では絶対に達成できないカタログ燃費で車を評価します。マイコンも同じです。データシート数値は、このカタログ燃費相当だと思います。

カタログ燃費(出典:日本自動車工業会)
カタログ燃費(出典:日本自動車工業会)

実際は、この最高数値にマージンを入れて考える必要があります。どの程度のマージンを入れるかが問題で、安全側評価ならデューティ50%、つまり性能半分位が良いと思います。

但し、これもマイコン単体の話で、マイコン:MCUと電源、発信器や必須周辺回路を含めた制御系で考えると、どの程度マージンを入れるかは複雑怪奇になります。

そこで、ベンダ開発の評価ボードを手本とする考え、つまり、10月1日投稿で示した評価ボードをハードウエアテンプレートとして用いる考え方を、私は提案しています。

10月15日記事のように、評価ボードでもWi-Fi起動時電流に電源部品の余裕が(短時間ですが)少ないものもありますが、大方のベンダ評価ボードは、実用に耐えられる厳選部品が実装済みです。そこで、プロトタイピング時には、この評価ボードで制御系を作り、実装部品のマージンが十分かを評価するのです。

マージンが足りない場合には、同じ評価ボードへ、より高性能な部品を載せ替えるなどの対策が簡単にできます。制御される側もこのようなモジュールで開発しておけば、モジュール単位の設計、変更が可能です。

ソフトウエアも同様です。評価ボードを使えば、少なくとも最低限のソフト動作環境は整いますので、プロトタイピングのソフトをなるべく早く開発し、動作マージンを確認しておきましょう。

完成・出荷時には、ソフトへ様々な機能が後追加されるので、プロトタイピング時はハード同様デューティ50%、つまりROM/RAMの残りに50%位は残しておくと安心です。

ソフトウエアのプロトタイピング開発には、弊社マイコンテンプレートが最適です。

連載第2回範囲のデータシートの見かたまとめ

  • 水晶振動子のMCUクロック供給は、発振波形が正弦波に近いため貫通電流が増え消費電流大となる。
  • 未使用GPIO端子は、外来ノイズ対策に10k~100kプルアップorダウンし、電位固定が望ましい。
  • データシート低消費電力復帰時間がクロックサイクル規定の場合はそのまま使え、㎲規定の場合は参考値。
  • 外付け水晶振動子の利用時は、ベンダ推薦部品を使う。
  • 内蔵発振回路の利用時に、MCU温度変化やリフローによる機械的応力による周波数変動が無視できない場合は、周波数トリミングソフトを組込む。
  • PLL動作最低/最高周波数の設定ミスは多いが、マージンがありそのまま動作するので注意。

マイコンデータシートの見かた(その1)

現役STマイクロエレクトロニクスの「メーカエンジニアの立場」から記載された、ユーザ質問の多かった事項を中心にSTM32マイコンデータシートの見かたを解説する記事(連載1回目)を紹介します。

全3回の連載記事内容

予定されている第2回、第3回の解説内容が下記です。

第1回:凡例、絶対最大定格、一般動作条件、電源電圧立上り/立下り(← 今回の記事)
第2回:消費電流、低消費電力モードからの復帰時間、発振回路特性
第3回:フラッシュメモリ特性、ラッチアップ/EMS/EMI/ESD、汎用IO、リセット回路

今回の第1回を読むと、データシートの読み誤り易いポイントが説明されており、興味深いです。ハードウエアに興味がある、または、ハードも自分で設計するソフトウエア開発者は、読むことをお勧めします。

マイコンハード開発を数回経験すると、おおよその感触とデータシートの見る箇所が解ってきます。私も新人の頃は、網羅されたデータシートの、”どこの何を見れば良いかが判らず”困惑したものでした。

ハードウエアテンプレートは評価ボードがお勧め

私は、使用するマイコンの評価ボードを、ハードウエアのテンプレートとして使います。
例えば、STM32F072RB(=NUCLEO STM32F072RB)は、配線パターン(=gerber files)や使用部品リスト(=BOM)もサイトに公開されています。

これらのデータは、「短納期を要求される開発者の立場」なら、網羅的記載のデータシートよりも、効率よく回路設計をする手助けとなります。

データシートを見ることは、間違いなく重要です。

しかし、具体的にハードウエア設計をする時は、評価ボードのような既に設計済みの「ブツ」を参考にしながら、なぜこの部分はこうなっているのか?などの疑問を持ってデータシートを見る方が、効率が良く、しかも、分厚いデータシートのポイントを理解するのにも役立ちます。

アナログとデジタル電源の1点接地や、パスコン実装位置などは、文字で注意書きをいくらされても解り難くいものです。この点、実物は、文字に勝ります。

ソフトウエアテンプレートはマイコンテンプレートがお勧め

ソフトウエア開発は、マイコンテンプレートの宣伝をするな!と思われた、勘のいい読者の方は、コチラのサイトを参照してください。

サンプルソフトは、”メーカ立場での提供ブツですが、”開発者の立場からの実物として、STM32ファミリ、サイプレスPSoC、NXPのLPC8xx/LPC111x/Kinetis、ルネサスRL78/G1xの各種マイコンテンプレートを、ソフトウエア開発者様向けに提供中です。

連載第1回範囲のデータシートの見かたまとめ

第1回記事の範囲で、マイコンハード開発ノウハウをまとめると、以下になります。

  • マイコン外部接続ハード駆動能力は、I2C、USART、数点のLED直接駆動可能端子を除いては極小で基本的には直接駆動はしない。
  • 外部接続ハードの駆動と接続方法は、Baseboard(mbed – Xpresso Baseboard)や、各種Arduinoシールドを参考にする。
  • マイコン電源は、評価ボードのパターン、実装部品も含めてまねる。
  • 開発製品版の未使用(空き)端子処理は悩ましいが、ソフトはデフォルト、ハードはソルダーブリッジ経由で接地。

私は、今後の連載を読んで、未使用(空き)端子処理の見識などを深めたいと思っています。

半導体メーカM&Aと技術シナジー

本ブログでも関心があったFreescaleをNXPが買収し、そのNXPをQualcommが買収するという半導体メーカのM&Aは、終息に向かうようです。Runesasもアナログ、ミックスドシグナル半導体を得意とするIntersil(インターシル)の買収を完了しました。
※QualcommのNXP買収は、未だに決着がついていない買収案件だそうです。

一方で、AtmelとMicrochipに見る、半導体企業M&Aの難しさという記事を読むと、M&A完了後も企業の技術的シナジーが生まれるには時間がかかりそうです。

以前記載しましたが、NXP)LPC8xxのLPCOpenライブラリv3.01の状況を観ると、この記事内容は頷けるものがあります。MCU部門だけを比較すると、実はNXPよりもFreescaleの方が規模は大きく、また、Cortex-M0/M0+ MCUで比較すると、2社で重複する製品があるので、既成製品(LPC8xx、LPC111xやKinetisシリーズ)の将来は、明確には判らないのが現状だと思います。

統合開発環境:IDEは、旧FreescaleのKinetis Design Studio+Processor Expertと旧NXPのLPCXpresso+LPCOpenライブラリが、新NXPではMCUXpresso+SDK+Config Toolsとなり、一見、新しい開発環境に統合されたように見えます。

しかし、買収完了後の新発売MCU開発以外は、個人的には旧開発環境の方がどちらの既成製品開発にも適している気がします。

9月28日現在、LPC8xx用のLPCOpenライブラリv3.01は、残念ながら更新されていません