WebSocketを一言で表すと、小さなサイズのデータフレームでリアルタイムに双方向通信ができるHTTPの欠点を補ったプロトコルです。

WebSocketはそう新しいプロトコルでもないのですが、使用するにはブラウザが対応していることが前提です。現在では身近なブラウザではほぼ大部分が対応しているために問題はありません。

WebSocketの汎用的な解説詳細は専門のWEBエンジニアが得意とするところで、ここではどちらかといえば番外で応用する側ですので組み込みマイコンシステムで実現するにあたり特有な部分に限定して解説します。

WebSocketを実装するにあたっては組み込み系のエンジニアにとってはHTMLとJavaScriptの使い勝手が組み込みプログラミングとは少し違うため慣れていない場合は苦労するのではないでしょうか。

WebSocketを開始するきっかけはクライアント側のブラウザからHTMLの中に埋め込んだJabaScriptで記述したWebSocketリクエストを送ることです。これはHTMLページを起動するときにリクエストを発行してもよいし、ページ内に作成した接続開始ボタンを押したときにリクエストを発行する仕様にしてもよいです。

WebSocket通信はしくみを理解するのはそう難しくはないですが、初めての実装は結構大変です。実装での最大のヤマはブラウザで発行されたWebSocketキーからブラウザへ返すアクセスキーを生成するところです。

アクセスキーさえ生成できれば、あとはHTMLとJavaScriptを駆使するだけですので組み込み系の人にとってはちょっとなじみは薄いかもしれませんがWEBプログラミングに精通している人ならばなんのことはないと思われます。

それではWebSocket通信のコネクション確立までの手順を確認していきます。

以下の図がブラウザからサーバーにアクセスするところから始まるWebSocketのコネクション確立までの流れです。

① まず通常のようにサーバーにアクセスするためにブラウザにIPアドレス/ポートを指定するとブラウザからサーバーへHTTPリクエストが送られます。

② サーバーはブラウザからGETメソッドを受けて、レスポンスを返すのですが、その中にJavaScriptで記述したWebSocketを起動するためのリクエストを埋め込んでおきます。大事なポイントはここで一旦通信を切断しておくことです。

③ 数秒おいてからブラウザはサーバーから送られたレスポンス内のJavaScriptを実行してWebSocketキーを含んだHTTPアップグレードリクエストをサーバーに送ります。

WebSocketを開始する場合はブラウザからHTTPリクエストを受け取った後にレスポンスのメッセージボディにJavaScriptでWebSocketリクエストを埋め込むところが通常の場合と異なります。

WebSocketを開始するためのコードは大体フォーマットは決まっていて、WebSocketオブジェクトを生成することから始めます。オブジェクト名は任意に指定できます。下記のサンプル例ではwsocketとしています。

下記のJavaScript記述したWebSocketリクエストのコードをリクエストのヘッダー部に埋め込んでおきます。

WebSocketイベントとメソッドはJavaScriptのコードで記述し、アプリケーションに応じた処理内容にします。

ブラウザ側でWebSocketリクエストコードを実行するとサーバー側へWebSocketキーを含んだHTTPアップグレードリクエストを送信します。

WebSocketコネクション確立のための最大のポイントがブラウザから渡されたWebSocketキーからアクセスキーを生成するところです。

囲んだ24文字のコードがWebSocketコネクションのためにブラウザが発行したキーです。 一例としてサーバーは受信したGETリクエストの空白前のヘッド部に”Sec-WebSocket-Key”があればWebSocketリクエストと認識し、その後に続く24文字分のキー(xxx...xxx==)を抽出します。

この次が最大のヤマ場であるリクエストのWebSocketキーに対するアクセスキーを生成する部分です。

アクセスキーを言葉で表現すると「リクエストで与えられたブラウザが生成したキーに固定値の"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"を連結して、SHA-1ハッシュと呼ばれる暗号化を行い、Base64エンコードを行った値」となっています。

アクセスキーを生成する手順は上記の流れですが、SHA1ハッシュ値を生成するアルゴリズムは難解のため、これすべてを自力でするのではなくどこかの汎用的なライブラリを利用すべきです。

BASE64エンコードに関しては内容はそう難解ではありませんが、これもライブラリ情報は多いため、利用するほうが得策かもしれません。

アクセスキーが生成できたら、WebSocketコネクション確立のためのHTTPアップグレードレスポンスをブラウザへ返します。

レスポンスのフォーマットは下例のとおりでよいと思います。レスポンス一行目のステータスラインは"HTTP/1.1 101 Switching Protocols"と"HTTP/1.1 101 OK"のどちらでも機能するようです。

生成したアクセスキーが有効であることがブラウザで認識されるとWebSocketコネクションが確立し、WebSocketプロトコルによる双方向通信が始まります。いわゆるサーバーとクライアント(ブラウザ)間でハンドシェイクのやり取りが成立したということになります。

確立するとopenイベントが発火し、定義したイベント内容が実行されます。例えばonopenイベントで”Websocket Connect!!"のメッセージを表示させる処理など記述しておけばよいでしょう。

WebSocketコネクションが確立すると任意のタイミングでブラウザ、サーバー間で双方向通信ができるようになります。WebSocket通信では送受信データにはテキストのみならずバイナリも扱うことができます。

データはWebSocketデータフレームとよばれるフォーマットに従ったものを送受信時に扱います。

データフレームの詳細は下記リンクのサイトで確認してみてください。

一度に送るデータが127文字以下でテキストかバイナリに限定する場合は比較的単純です。

データフレームのフォーマットは1バイト単位のブロックで構成されています。１番目のバイトブロックは通信データが最後のパケットであるかの指定およびデータの種類を指定します。２番目のバイトブロックではデータのマスク有無およびデータ長を指定します。

データのマスク有無ですが、これは決まり事でブラウザからのデータはマスクを付加し、ブラウザへのデータはマスクを付けないことになっています。

言葉での説明はわかりにくいのですが、送受信するデータの具体的な適用例で確認すれば理解しやすいと思いますので、送信、受信の場合で解説していきます。

具体的な例としてブラウザがテキスト文字列"test"を送信する場合で確認します。送受信はTCPソケット通信で行われます。

ブラウザからの送信ではsendメソッドを使用します。

4文字テキストの場合、ブラウザは10バイト分のWebSocketデータフレームを送信します。サーバー側で受信するTCPデータバッファをdata_buffer[]とすると実際にこの受信バッファに読み込まれるデータの例は以下のようになります。

4文字テキストデータは単独パケットなので1番目バイトブロックdata_buffer[0]は先頭ビットFINは1、テキストデータのためopcodeは1となるので16進数表記で0x81となります。

2番目バイトブロックdata_buffer[1]はブラウザからのデータでマスク付きなので先頭ビットMASKは1、データのpayload長は4なので16進数表記で0x84となります。

3-6番目バイトブロックdata_buffer[2]-[5] はブラウザから付加されたマスクキーです。これらは同じデータを再度送っても都度変わります。

7番目以降のバイトブロックdata_buffer[6]-[9] の文字数分がブラウザから送信するテキストデータにマスクでコード化されたものです。コード化したデータはマスクキーを使用して復号することで抽出データunmasked_str[i]を取得します。

抽出データunmasked_str[i]はMask_Key[i]とmasked_data[i]のXOR(論理演算)によりUnMask(復号)して取得します。

ブラウザは任意のテキストデータやバイナリデータ以外にも送信するコードがあります。その一例としてcloseメソッドでwsocket.close()を実行した場合のやり取りされるデータを確認してみます。

この場合のブラウザから送信されるデータ列は実データを含まない6バイト分のデータフレームです。最初のバイトブロックのopcodeがcloseメソッドを実行したときは0x8となっています。マスクキーも送信されてきますがここでは意味はありません。

サーバー側で受信した先頭のバイトブロックdata_buffer[0]が0x88であればブラウザでcloseメソッドを実行したことがわかります。

WebSocketのopcodeには、他に0x9(Ping), 0xA(Pong)がよく使用されます。切断したときの処理などに利用できます。

実際にやり取りされる具体的なデータで確認していくとすぐに理解できたのではないでしょうか。次はサーバーからの送信を確認していきます。

今度はサーバー内のテキスト文字列"test"をブラウザに送信する場合で動作を確認します。サーバーからの場合はマスクを必要としないのできわめてシンプルです。

サーバー内のテキストデータ*str_send="test"をブラウザに送信して表示させる場合で確認していきます。

4文字テキストを送信する場合はマスクは使用せず、WebSocketデータフレームの1番目と2番目バイトブロックに送信するデータのフォーマットを指定して、つづいてテキストデータを送信するだけです。

HTTPプロトコルに比べて送信時は特にヘッダが小さいため送信する情報量が小さくてすむのが特徴です。送信データが小さいものほど差は顕著です。

ブラウザへはTCPのsend関数(TCP処理系により異なる)で送信します。

ブラウザではデータを受信したときにonmessageイベントが発火しますので、テキストを表示させるなど実施したい処理を設定しておいてください。

これらの送信ブロックを任意のタイミングで送信してブラウザに反映させることができるのがWebSoketの特徴です。

これまでの内容を実機で確認する場合の配線はこれまでと同じです。

ブラウザからサーバーのIPアドレス/ポートを指定するとボディメッセージに記述したHTMLページが開きます。

WebSocketコネクションを確立するために"Connect"ボタンを押します。このサンプルでは”Connect"ボタンを押してからWebSocketリクエストを送っています。

WebSocketコネクションが確立すると発火するopenイベント内に"Websocket Connectioned!!"を表示するようにしています。

HTMLのスライダーを操作するとJavaSriptで設定したデータ範囲の数値が"Slider output"に表示されます。これはブラウザ側で生成した値で送信するデータですのでWebSocketコネクション確立にかかわらず表示されます。

WebSocketコネクションが確立した状態でスライダーを操作すると同時に"NUCLEO Loopback"に数値が表示されます。これはサーバーが受信したデータをそのままブラウザに送り返しているデータですので双方のデータはほぼリアルタイムに連動しているところがWebSocketによる双方向通信の特徴です。

"Close"ボタンを押すとcloseメソッドを実行してコネクションを切断するようになっています。Closeイベントが発火すると"Websocket DisConnected.."を表示するようにしています。

ひとたびWebSocketコネクションが確立するとWebsocketプロトコルによる双方向通信は比較的シンプルに実現できます。ただ、実際の運転においてはTCPソケット通信に比べて通信が不安定になりがちですので安定した通信を実現するにはあと一工夫必要です。

次のデモ動画はサーバー内の変数をブラウザに送って表示させるものです。送信のサンプリングレートは100msです。

これくらいの表示速度であれば動作を伴うセンサー値などのリアルタイムモニターに応用できるのではないでしょうか。

送信周期を100ms以下にすると不安定で、組み込み機器のリアルタイム通信としてはこの速度では少し物足りずWebSocketの利点が活かされていないようですが、現状ではこんなものかもしれません。フリーズや切断する原因を特定して可能であればより安定して高速な通信の実現を今後の課題としておきます。

これに関しては解説記事が世に溢れているため、詳細解説はここではあえてしません。マイコンでWEBサーバーを構成するにあたってつまずきやすいポイントにしぼって最低限必要な知識の要点をまとめるように努めています。

HTTPはTCPの上位にあるプロトコルでHTTPリクエストとHTTPレスポンスと呼ばれるHTTPメッセージでやり取りしているのですが、目に見えない水面下ではTCPによるデータ通信を行っています。

通常、WEBサーバーはファイルシステムをもっているコンピュータシステムにHTMLで記述したページ、CGIプログラム、さらに画像ファイル等を保存しておき、クライアントからの指示に従ってページを渡したり、プログラムを実行したりブラウザへ応答するものです。

対して、ファイルシステムを持たないマイコンの場合はサーバーは個々のファイルが作成できないために、かわりにすべてのデータを静的な文字列にコード化(ハードコーディング)して配列に格納して文字列の送信でブラウザに表示させます。　

ファイルシステムがないサーバーは画像ファイルが扱えないために、見た目のシンプルな簡易的なものに限られますが、最低限の機能でもブラウザからマイコンにアクセスできてリモート管理等できることは大きな意義があります。

HTTPはWEB専用でブラウザとサーバの間でやりとりするプロトコルです。クライアントであるブラウザがリクエストメッセージ(要求メッセージ)をだしてWEBサーバーはレスポンスメッセージ(応答メッセージ)を返します。

HTTPプロトコルはテキストで記述したヘッダーを送受信したいデータに加えたフォーマットになっています。

下のコードはアクセスしたいWEBサーバーのURLをブラウザから入力したときのリクエストメッセージです。一行目はリクエストラインでメソッドGETから始まりアクセスしたいURL等が続きます。

ついでメッセージヘッダでブラウザの情報を伝えています。このリクエストにはデータはありませんのでボディーは空です。

上記コードはGETメソッドでURLが192.168.3.100:50000へのアクセスリクエストです。 URLにはアクセスしたいファイルのパス名まで入れることもありますが、省略したときはトップページのHTMLを要求していることになります。

HTTPプロトコルの規定ポート番号80以外の場合にはポート番号を明記します。

HTTPレスポンスにはWEBサーバーの情報を記述します。ヘッダ項目でHTMLで記述したページを送りたい場合はContent-Typeにtext/htmlとします。次のContent-Lengthはメッセージボディのデータ長を指定します。これらの設定はブラウザに内容を正しく表示する上で重要です。

メッセージボディはHTMLで記述したページ等の内容です。上記のコードはマイコンからブラウザへHTMLをコード化(ハードコーディング)した文字列を送信した内容でファイルシステムでのHTMLファイルを送るのと同じものになります。

ブラウザからの入力フォームで送信ボタンにGETメソッドを指定(method="get")しています。

HTTPメソッドとはクライアントがWEBサーバーに要求する処理のことで、数種類ありますがブラウザとマイコンとのやり取りでは主にGETメソッドとPOSTメソッドの2種類を扱います。

ブラウザがサーバーからHTMLファイルなどを取得する場合にはGETメソッドを、ブラウザからサーバーにデータを送信する場合はPOSTメソッドを使います。GETメソッドはPOSTメソッドのようにデータ送信にも使えますが、その場合はURLの後ろにデータを付けて送信します。

標準的なGETメソッドの用法です。ブラウザ(クライアント)はWEBページのURLを入力するとまずはじめにサーバーへTCP接続を要求します。

サーバー側がクライアント側からのTCP接続要求を受け入れて接続(コネクション)が確立するとHTTPプロトコルでのやり取りがはじまります。

ブラウザはGETメソッドリクエストラインから始まるリクエストメッセージをサーバーに送信します。

サーバーはGETリクエストを受けて次のレスポンスを返します。

ブラウザはGETリクエストの内容によりHTMLページを開いたり、指定されたファイルにアクセスします。

GETメソッドを使ったデータ送信フォーマットです。ブラウザのアドレス欄にURL末尾に「?」をつけて「データ=xxx」を送ります。

サーバーは下記のようなフォーマットでリクエストメッセージを受信データとして取得できますのでメソッド「GET」とデータ「ABC」を処理して抽出すればよいだけです。

GETメソッドによるデータの送信はとても簡単な方法ですが、URL欄に履歴が残るために機密データを送信するには問題があります。

基本的にデータの送信にはPOSTメソッドを使います。GETメソッドとは違いブラウザの履歴は残りません。

サーバーは下記のようなフォーマットでリクエストメッセージを受信データとして取得できます。データはリクエストヘッダが終了した空行のあとのボディにあります。

リクエストすべてを受信してからのメソッド「POST」とボディ内のデータ「ABC」を処理して抽出することになるため、「GET」のときに比べて受信データ量は大きなものになります。

WEBサーバーを搭載してもプログラムの基本的な流れはTCPサーバーの時とあまり変わりません。送受信データにHTTPプロトコル特有の多少の尾ひれがつくのでその処理が追加になります。

STM32マイコンにWEBサーバーを搭載したプログラム概要です。HTTPプロトコル特有の内容はモジュールhttp_server.cに記述しておき、ヘッダファイル http_server.h を読み込んでおきます。

ここではサーバー内でのデータをブラウザで表示するデモ用プログラムとしてRTOSのタスクprvTask_monitorを一つ追加してその中でデータ値を１秒間に１カウントアップしています。

下のWEBサーバーモジュールは今回のデモ用WEBサーバーの中核となる部分です。ブラウザでURLを入力して起動するトップページは配列top_document[]の内容です。GETメソッドリクエストにデータが含まれない場合のページです。

送信した文字列があらかじめ設定した文字列"ABC"と一致したときと不一致のときのメッセージを表示する別ページは配列top_document2[]の内容です。GETメソッドリクエストにデータが含まれる場合のページです。

HTMLファイルをコード化して配列に格納するにあたって最も重要なポイントは変化のない静的なコードと内容により異なるコード長データ"len_top_document"など動的なコードをsprintf関数で結合しているところです。これを利用すると静的なファイルであるはずのHTMLが動的な要素を含んだページになります。

ブラウザからのリクエストメッセージにはGETやPOSTなどのメッセージおよびデータが含まれていますので、それらをまず正確に抽出する処理が必要です。これらはタスクprvTask_TCP内で処理を行っています。

今回のデモプログラムではデータ送信にGETメソッドを使用しているために「GET」をコマンドとして受信した場合にリクエストがデータなしかデータ付きかで処理を分岐しています。

Nucleo-F103RBにWEBサーバーを搭載したところで実際にブラウザにURLのIPアドレスとポートを入力してアクセスしてみます。

URLを入力するとサーバーとのコネクションが確立して以下のページに切替わります。配列top_document[]にコード化した内容です。 左下の数値はマイコン内で１秒毎にカウントアップしているデータを表示したものです。現在値を確認するにはブラウザを手動で更新します。

以下のフォーム画面で文字を入力してGETメソッドでサーバーに送ります。文字"ABC"を入力して送信ボタン(Send)を押します。このボタンはGETメソッドに設定しています。

送信ボタンを押すとブラウザのアドレス欄にURL/?cmd=ABCが自動的に入り、ページが配列top_document2[]に格納したHTMLページに切替わります。入力した文字が“ABC”と一致すると下記のメッセージが表示されます。

今度は"abc"を入力して送信ボタンを押すとブラウザのアドレス欄にURL/?cmd=abcが自動的に入り、ページが切替わります。入力した文字が“ABC”と不一致であると下記のメッセージが表示されます。

以上、ブラウザからマイコンにアクセスして文字列を送信する様子とマイコンからのデータを表示することを確認しました。このデモプログラムは、機能は単純ですがこれらを自由自在に扱いこなせるとマイコンをブラウザからリモート管理することができる重要な要素を納めていますので是非実践してみてください。C言語で文字列を扱うトレーニングにもなります。

インターネット情報には無数の解説記事が存在するためにここでは詳細の解説は割愛しますが、簡潔にまとめますとソケット通信はサーバーとクライアントが互いに確認しながら通信を行うTCPプロトコルに基づいた方式です。互いにやりとりすることからハンドシェイク方式とも呼ばれます。

ソケット通信は電話による会話に似ていて会話の出入り口である受話器、耳、口に相当するものをソケットと呼びます。相手が応答して初めて会話(通信)が成立し、途中で相手やこちらで切断すると会話も終了します。また、相手が接続中(受話器を上げたままの状態)のときは、こちらからの接続要求に応答しません。

トランスポート層に属するプロトコルには他にUDPがありますが、これはサーバーがクライアントに確認せずに一方的に情報を与える方式です。動画などのストリーミングで内容に多少の不備があっても問題がない多量の情報を送るのに適しています。

下図はソケット通信で標準的なバークレーソケット（BSD unixに実装されたネットワーク用API）に基づいた通信のフローチャートです。サーバー、クライアントともにあらかじめソケットを作成しておき、クライアント側から必要時に接続要求をだして、サーバーが応答して通信を確立します。一度確立すると、どちら側から切断しないかぎり、任意のタイミングで送受信できるのがソケット通信の特徴です。

ドライバsoket.cでは標準インターフェースのBSDソケットに準じた関数をまとめていますがここではドライバ内に定義された関数の一部のみを使用したソケット通信のサンプルを紹介しています。

サンプルプログラムではTCPサーバーをサンプリングタイム5msで実行する専用タスクprvTask_Tcpに構成しています。

ドライバのソケット標準関数を使用して一般的なTCPサーバーを作成することもできますが、ここではサンプリングタイム毎にモニターしたソケット状態に応じた処理をドライバのレジスタ操作関数を使って実行します。

ソケットの状態は主に
「SOCK_CLOSED」ソケット閉鎖
「SOCK_LISTEN」ソケット待機
「SOCK_ESTABLISHED」ソケット確立
「SOCK_CLOSING」ソケット閉鎖中
の4種類があり、これらの状態をソケット番号SNに応じてgetSn_SR(SN)関数でソケットのレジスタ値を読み込みます。

プログラム起動直後のソケットは「SOCK_CLOSED」ですのでまずソケットをsocket()関数で生成します。

関数の第1引数はソケット番号SNで、SNは自作関数をまとめたヘッダファイルnet_conf.hで1に定義しています。

第2引数はプロトコルは設定でTCPプロトコルを指定しています。第3引数はPORT番号を指定し、第4引数ではnon-blockを指定し、ノンブロッキングソケットとしています。

ソケットが作成されるとlisten(SN)関数を実行し、SOCK_LISTEN状態に遷移してクライアントからの接続待ち状態で待機します。

ソケットの状態がSOCK_LISTENの待機時にクライアントのターミナルからIPアドレスおよびポートを指定して接続の要求をし、接続が確立するとSOCK_ESTABLISHEDになります。接続が確立しクライアントのターミナルにサーバーのIPアドレスが表示されると任意のタイミングで送受信ができるようになります。

データ受信にはrecv関数を使用します。第1引数はソケット番号、第2引数は受信バッファのポインタ、第3引数はデータ長を指定します。データを受信するとデータ長を返します。

データ送信にはsend関数を使用します。第1引数はソケット番号、第2引数は送信バッファのポインタ、第3引数はデータ長を指定します。

通信用バッファメモリである送信TXおよび受信RXバッファはそれぞれ16Kバイトのブロックで構成されています。

setSn_CR関数はsocket.c内に定義されている関数でソケットを制御するものです。第1引数はソケット番号、第2引数はソケットの状態を指定します。Sn_CR_CLOSEを指定するとソケットを閉鎖(close)します。

その他ソケットの”OPEN", ”LISTEN", "CONNECT", "DISCON", "SEND", "SEND_MAC", "SEND_KEEP", "RECV"等があります。詳細はドライバのソケット定義ファイルsocket.cを確認してください。

TCPサーバーのソケット状態遷移をまとめると上図のようになります。W5500ではソケット状態は他にもありますが、とりあえず主な4つの状態をコントロールしておけば機能します。

ソケット通信の状態を電話による会話に例えると下図のようなイメージなります。この通信状態を想定しながら実際にソケット通信を実施して動作を確認してみます。

クライアントではターミナルソフトを使用します。ここでもTera Termを使用しています。これに限らず慣れたツールを使用してください。

起動後、TCPソケット通信ですのでサーバーに登録したIPアドレスおよびポート番号を入力し"OK"を押します。

画面左上にサーバーのIPアドレスが表示されると設定ポートが開いてクライアントとサーバーが接続したことになります。

TCPサーバーに対してコマンドを与えて通信できるかを確認します。通信テスト用の応答メッセージを返す処理、ソケットの閉鎖(close)および接続切断(disconnect)するコマンドをまとめたファイルを作成して実行しています。

まず文字列"ABC"を入力します。受信バッファに格納された文字列が"ABC"で一致すると”Matched‼"と応答します。応答はsend関数を使用しています。

文字列"abc"を入力すると"ABC"と一致しませんので”Error"と応答します。

ソケットが接続確立しているところで新たに別の接続を試みます。

すでにポートが開いているために接続が拒否されました。電話では相手の受話器が上がっていて話し中の状態です。

ソケットを閉じるためにコマンド"scls"を入力すると"socket close"メーセージを返してCRレジスタにSn_CR_CLOSEを送信してからソケットを閉鎖(close)します。結果、未接続となります。

また新たに接続を試みると今度はソケットが閉じているため再びポートが開き接続できます。

最後に接続自体を遮断するため、コマンド"srst"を入力します。CRレジスタにSn_CR_DISCONを送信し、切断処理(disconnect)を実行します。

画面左上が未接続となり接続が遮断されたことが確認できます。

以上、テスト用コマンドを入力してソケット通信の様子を確認しました。実際のソケット通信ではプログラミング次第でコマンドをさらに多様化してコマンドにより様々な処理を実施させることになります。

TCPソケット通信はサーバーとクライアント間でリアルタイムでデータをやりとりできることが特徴ですので組み込み機器にTCPサーバーを搭載しておけばIoTとしてリアルタイムでインターネットを介してデータのリモート管理ができるようになります。

ネットワークには様々な規格の装置・機器が接続されているのですが、ネットワークの規格は以下のOSC参照モデルで共通化されていますのでどのような装置・機器でも共通規格であれば通信できるようになります。

イーサネットは有線LANの一つで最も普及している規格でありIEEE802.3で定義されたものです。

規格に従って、物理層のLANケーブルから例えばウェブブラウザを使用したHTTPアプリケーション層までの通信システムを構築することになります。データリンク層までは大抵ハードウェアで構成され、それ以降はソフトウェアで構成されます。

イーサネット通信に関してマイコンを大別すると3種類あり、下記のように分類できます。

1番めの汎用マイコンはイーサネットコントローラが非搭載ですのでMAC/PHYデバイスコントローラを外付けして汎用バスであるSPI、I2Cなどをインターフェースとして通信を行います。今回扱うNucleo-F103RBのマイコンはこれに当たります。

２番めのマイコンはイーサネットMACデバイスを内蔵したもので例えばSTM32F407がこれに当たります。PHYデバイスコントローラを外付けしてマイコン内蔵のMACデバイスとMII/RMIIとよばれる方式で通信を行います。

３番めのマイコンはイーサネットに必要なデバイスMACおよびPHYを内蔵したもので、追加部品はパルストランス内蔵のRJ-45のみです。

マイコンと組み合わせてイーサネット対応にするコントローラで一般的に使用されていて取得性のよいものを紹介します。

イーサネットの知識がなくてもWiFiのときに使用したESP32のように汎用シリアル通信をインターフェースとしたコントローラでシリアル通信感覚で使用できます。

最も簡易的なIoT対応コントローラとして選択できます。シリアル通信のみ対応の既存の機器に外付けするだけなのはメリットですが、メーカー提供のドライバに従うため汎用性が高いとはいえないことと、既存の製品に組み込むのは他の手段に比べコスト的に採用しにくいことがデメリットです。

ENC28J60コントローラはイーサネットコントローラ非搭載のマイコンでもSPI通信を持っていればイーサネット対応にできます。

TCP／IPプロトコルスタックを自分で組み込まなければなりませんのでSTM32F1シリーズでは実施例の資料が少なく大変そうです。移植するには選択したTCP/IPプロトコルスタックの中身を理解する必要がありますが、そこに時間をかけたくない場合は次のW5500がおすすめです。

ENC28J60コントローラの場合と同じくイーサネットコントローラ非搭載のマイコンでSPI通信を持っている場合に適用できます。両者の大きな違いはW5500はTCP/IPプロトコルスタックをハードウェアに内蔵していることで搭載のわずらわしさがなくコネクションが安定しています。

そのため、TCP/IPプロトコル・スタックについての知識がなくても使用できることに加え、ソフトウェア負荷が小さいのでメモリの小さなマイコンに搭載できることも大きな利点です。

Nucleo-F103RBのSTM32マイコンに対して外付け部品も少なくてすみ、TCPプロトコルを利用したソケット通信やさらに上位のHTTPプロトコルを利用したブラウザからの通信にも発展できるバランスのとれたコントローラです。

STM32F407マイコンのようにイーサネット対応MACを内蔵したものにはPHYデバイスのみを持つLAN8720やDP83848等のコントローラがよりマイコンの機能を活かせます。

上位機種であるCortex-M4コアを内蔵するSTM32F407を新規に採用する場合はもはやライブラリはSPLにこだわるのではなくHALやLLドライバを使用したほうが手っ取り早いです。

開発環境STM32CubeIDEを使用すれば開発プロジェクトを作成する段階で自動生成機能を利用するとTCP/IPプロトコル（LwIP）も簡単に組みこめ、トランスポート層のTCPやUDPプロトコルまで実装できてしまいます。

はじめからネットワーク機器向け製品を設計する場合はネットワーク内蔵のマイコンを選択するのが良いのではないでしょうか。

イーサネットコントローラ非搭載のマイコンSTM32F1シリーズでイーサネット対応にするには汎用性を考えるとW5500かENC28J60あたりになります。

TCP/IPプロトコルスタックをハードウェアに内蔵しているW5500はとりわけネットワーク仕様としての性能は申し分なく気軽にマイコンをネットワーク化対応にできるためこちらを選択することにします。

TCP/IPプロトコルスタックについては規格に準じたものなので内部詳細をあえて理解する必要性はあまり感じられず既成のモジュールとして割り切ってもよいのではないでしょうか。

外付けでW5500でNucleo-F103RBをネットワークにつなげるにはここでは市販W5500ボードを利用します。ボードは安価で最低限の周辺部品が備わっていますがMACアドレスがないボードも多いです。

製品開発をする場合にはこの市販W5500ボードに使用されている最低限の周辺部品の他にMACアドレスを保持するためのEEPROM等メモリが必要になります。

Nucleoとの接続は割り込みや外部リセットを使わないのであれば電源とSPI通信部のみで機能します。リセットはソフトウェアで実行するのであればなくても機能はしますがW5500はパワーオンリセットではないので、リセットの確実性を高めるため特に製品化の場合にはハードウェアリセットは使用すべきです。今回はSPI2を使用するため下図のような接続になります。

W5500はIC内部のレジスタをSPI通信で操作して通信を行います。レジスタの詳細はW5500データシートに詳細が記載していますが、プログラミングにおいてはメーカーが提供するドライバ類をライブラリ(ioLibrary_BSD)として登録しておき、必要に応じて関数類を呼び出して使用します。

STM32マイコンとのSPI通信のインターフェースにあたる関数をまとめたファイルがwizchip_conf.c/wizchip_conf.hです。このファイルでは使用するコントローラICチップ(W5500)の指定や、レジスタアドレス等が登録されています。マイコンとのインターフェースカスタマイズで一部修正する必要はあります。

w5500.c/w5500.hはコントローラW5500で使用するマイコンとの送受信関数を定義してまとめたものです。

socket.c/socket.hはTCPソケット通信で使用する関数群をまとめたものです。バークレーソケット(BSDソケット)に準じた関数となっています。

これらを最低限ドライバとしてioLibrary_driverフォルダ内に登録しておき、他はDHCPに関するものなど必要に応じて追加するのが良いと思います。

LANコントローラW5500には書き込み/読み込み等の操作、IPアドレス等パラメータ、プロトコル指定など仕様を設定するためのコモンレジスタブロック、およびソケット通信で使用するソケットレジスタブロックがあります。

レジスタの詳細はW5500の取説に解説しており、かなりきめ細かな設定ができるようになっていますが、一般的な用途では使用するのは一部だけです。

これらのレジスタブロックを操作するためにSPI通信をインターフェースとしてマイコンとやり取りしますのでこの部分を確立できればほぼできたようなものです。

ドライバのインターフェースのファイル（ｗizchip_func.ｃ)に手を加えてSTM32マイコン仕様にするのはほんの一部だけです。実際のプログラミングにおいてはドライバ内で定義した関数が使用できますので一度ポイントを理解してしまえば手間はほとんどかかりません 。

実際にどのような仕組みでレジスタを操作しているかを一度は取説を見ながらドライバ内の関数を順に追ってみるのがよいと思います。

W5500でのspi通信のフレームフォーマットでは1バイト(8ビット)ごとのブロックで下図に示す３フェイズで構成されます。上位・下位２バイト分のアドレスフェイズ、１バイトのコントロールフェイズ、そしてデータフェイズです。

STM32マイコンで定義するSPI関連の関数（チップセレクト、送受信）をW5500ドライバに紐付けるためのカスタマイズです。

SPIインターフェース(ｗizchip_conf.c)で下記の赤色で囲った部分を追加登録します。チップセレクト関数SPI_CS1_Select()/ SPI_CS1_Deselect() はSTM32Nucleo用に自作したものです。

自作した送受信関数SPI_Send_Receive() も同様に追加登録します。

内容が異なる場合は上図で追加定義したSPI送受信関数を下図のようにドライバ定義の関数に紐付けします。

実際、ドライバに追加したり、書き換える重要な部分はこれだけです。その他、ビルドの際にそのままではエラーとなりますがインクルードするファイルパスを修正すればよいだけです。

自作したSPI関連関数を定義したファイルをSPIインターフェース(ｗizchip_conf.c)のヘッダファイルにインクルードさせてリンクできるようにするのを忘れないでください。

SPI通信でのインターフェースが準備できたら実際のプログラミングではドライバ内で定義している関数を利用して初期設定をします。.

初期化フローチャートはプログラム内では下記のようにW5500_ini()関数にまとめています。レジスタ操作するための関数はドライバのヘッダファイルW5500.hで定義しています。

W5500はマルチキャストなど高度な設定もできますがここでは簡単なシングルキャストの基本設定で初期化をします。

レジスタのリセット(MR_RST)発行を行い、PHY初期化、送信元(サーバー側）のMACアドレス、IPアドレス、そしてKeepAlive,タイムアウト等を登録します。

これまでの初期設定を完了させるとネットワーク層までの通信環境が整ったことになります。プログラム全容は下記のようになります。

初期化関数W5500_ini()やネット関連の自作関数等は別途モジュールnet_func.cにまとめていてそのヘッダファイルをインクルードしています。

プログラムを実行させると、設定したIPアドレスに属するネットワークアドレスをもったLANに接続することができます。

ここではネットワークアドレスが192.168.3でIPアドレスを192.168.3.100に設定しています。

PCのコマンドプロンプト画面から「ping」コマンドを実行してネットワーク内で認識されているかを確認します。 "ping 192.168.3.100"と入力した場合の応答を確認します。

下記のような画面の場合は何らかの原因で不備がありpingが通っていない状態を示しています。

このような場合は大抵、ケーブルに不備があったり設定したIPアドレスと異なったものを入力していたり何らかの原因があります。

プログラミング直後の初接続時にping応答がこのような場合はプログラムに何らかの不備がある可能性があるため、バグの原因を突き止めることになります。特にspi通信関連の動作確認とドライバ関連ファイルのパスは大切です。一度機能すれば大丈夫です。

プログラムが正常に機能すると下の画面が現れます。この状態ではpingが通っているため、無事ネットワークに参加することができたことを示しています。

pingコマンドはICMPプロトコルのものなのでOSI参照モデルのネットワーク層まで通信システムが確立したことになります。

pingコマンドだけでは通信チェック以外には何の仕事もできないのですが、ここまでのネットワークを確立できると、あとは上位のTCPプロトコルによるソケット通信やさらにその上位のHTTPプロトコルを搭載してwebサーバーを作成してブラウザからアクセスできるようになります。

今回はIPアドレスはメモリに保存した固定値"192.168.3.100"を使用しています。ここでは解説しませんが、DHCP機能を搭載するとDHCPサーバーから自動的に割り当てられたIPアドレスを使用できるようになります。

次回は上位プロトコルであるTCPを実装してソケット通信を実現します。

X,Y,Z3軸傾斜角をはじめから求めようとするとかなり複雑のため、この記事では1軸分(Y軸)まわりの傾斜角を加速度センサおよびジャイロセンサから算出する方法を解説します。

MPU-6050では下図の向きにX、Y、Z軸を設定しています。

加速度センサでY軸まわりにθ_y傾斜する場合はZ軸方向およびX軸方向の重力比率より傾斜角θ_yは逆三角関数を使用すると算出できます。

加速度センサアプリでも説明しましたが、加速度センサの重力(1G)成分による各軸の値a_x,a_y,a_zは重力に対する抗力の向きとなりますので、下図のようにY軸中心に座標を正方向θ_Y傾斜したとき、重力Z軸成分(1G_Z)の抗力a_zは正値で、X軸成分(1G_X)の抗力a_xは負値となります。

ここでは動作による加速度は考えていませんので算出データは地上に対して傾斜させて静止した角度(絶対角度)となります。

算出した絶対角度にオフセットθ_offset分を差し引くと、任意の角度で基準0°にプリセットできるので基準からの相対角度とすることができます。逆三角関数を使用した場合の角度は単位がradのため、必要に応じて°に変換します。

ジャイロセンサの場合、データg_yはY軸まわりの回転時の角速度のため、角度を得るにはプログラム内で積分して算出する必要があります。

まず得られた16ビットデータをスケールに応じた角速度（°/s）に変換します。それからオフセットがある場合は予め差し引いておいてから積分して角度を算出します。

プログラム内での積分は離散化した近似です。最もシンプルな積分は下図のアルゴリズムです。サンプリングタイムTsが十分小さい場合はこれでも問題はありません。

MPU-6050をNucleo-F103RBに接続して使用する場合の配線例を下図に示します。

センサボードGY-521の電源にはLDOレギュレータを内蔵していますので5Vを接続します。

データ出力インターフェースはI²C通信のため、STM32側ではI²C2に接続します。I²CのI/Oはオープンドレインに設定しますので通常ではプルアップ抵抗が必要ですが、センサボードGY-521には予め含まれています。

まず、はじめの関門はI²C通信の設定およびデータ読み書きを正常に実現することです。データを任意に安定して読み込めることができればあとはこれまでに解説した方法でデータを演算して角度を算出するだけです。

I²C通信デバイスを使用するために、I2C2_Configuration()でまず初期設定をします。これは他のI²Cデバイスと同様です。詳細はシリアル通信I2C【STM32のI2C詳細】を参照してください。

I2C2の初期設定のあとはMPU-6050の設定をします。設定はレジスタに値を書き込みます。すべてデフォルトで使用する場合は必要ありませんが、デバイスに内蔵のデジタルフィルタを使用したり、データのフルスケールを変更設定する場合には必要です。

I²C通信では1バイト単位でデータを読み書きするのですが、データ読み込みでは個々のバイトデータを単独で読み込むのではなく、一度に複数バイトを読み込む方が効率的です。

そうなると読み込みデータアドレスは加速度センサのX軸のデータアドレス3Bから14バイト分を読み込んでデータを配列に格納するだけでよいのです。

話は前後しますが、所望のレジスタに1バイトデータを書き込むための関数は自作します。

ここでのポイントはスレーブアドレスで、I²Cのアドレス送信関数I2C_Send7bitAddress()ではアドレスは1バイト枠で左詰め7ビット分です。これに最下位ビットに送信か受信フラグを付加した１バイトデータとして扱います。

ライブラリ関数の中身を確認して動作をたどると理解できると思います。

例えばI²Cデバイスのスレーブアドレスが0x68の場合は1ビット分左シフトした0xD0を送信関数I2C_Send7bitAddress()に与えるアドレスとします。

データ読み込みは書き込みの延長のようなものですが、複数バイトデータも連続して読み込むことができます。

これも自作の複数バイト読み込み関数ですが、データが複数ある場合は最後のバイトデータ受信直前でACKを返さないNACKとすることがポイントです。

MPU-6050 は初期設定としてレジスタへセンサへのクロック源を設定したり、加速度センサ、ジャイロセンサのフルスケールや出力へのフィルタを設定します。

加速度センサおよびジャイロセンサにより角度を取得するだけならばデフォルト設定でも使えますが取扱うレジスタはせいぜい下記の程度です。

クロック源を指定することで MPU-6050は機能始めます。クロック源はレジスタアドレス6Bの下位3ビット分に設定します。電源投入時のデフォルトでは内部発振8MHzとなっています。

MPU-6050には出力にノイズ対策のローパスフィルタを設定することができます。必要に応じてレジスタアドレス1Aの下位3ビットに0から6までの値を設定します。

レジスタアドレス1Bではジャイロセンサフルスケールを0から3までの値で設定します。デフォルトでは±250°/sです。

レジスタアドレス1Cでは加速度センサフルスケールを0から3までの値で設定します。デフォルトでは±2gです。

加速度センサの各軸データは16ビットですが、データ格納アドレスは8ビットですので上位8ビット、下位8ビットで構成されます。X軸、Y軸、Z軸のデータはレジスタアドレス3BよりX軸上位、下位...と順に格納されます。

データについては例えばフルスケールが±2gの場合は、+2g時に32768となるので1g当たり16384となります。

ジャイロセンサの各軸データも加速度センサと同様にX軸、Y軸、Z軸のデータはレジスタアドレス43よりX軸上位、下位...と順に格納されます。

データについては例えばフルスケールが±250°/sの場合は、+250°/s 時に32768となるので1°/s当たり131となります。

加速度およびジャイロセンサからのデータが取得できるようになるといよいよそれぞれのデータから角度を算出できるようになります。

I2C_Read_multibyte()関数による複数バイト読み込みで格納したデータにより加速度およびジャイロセンサ各軸の16ビット値が取得できます。

取得できた値により加速度センサによる角度およびジャイロセンサによる角度が算出できます。

ジャイロセンサからの角速度データを積分して角度を算出するためのサンプリングタイムを正確に5msとするためにRTOSの機能を利用しています。詳細はFreeRTOSタスク管理の基本を参照してください。

加速度センサおよびジャイロセンサから単独で算出された角度はそれぞれ一長一短あり安定しません。そこで、両センサの長所である部分をいいとこ取りするための手段に相補フィルタというものを使います。

加速度センサでは重力変化による傾斜角度が得られるので特に静止状態の場合の絶対的な角度変化は信頼性がありますが、情報にノイズが含まれていたり、動作が伴うと重力以外の成分も加わることにもなります。

対して、ジャイロセンサでは回転を検知した角速度が得られるので動作の伴う角度の変化には信頼性がありますが、プログラム内で積分をしているので誤差も同時に累積しドリフトを発生してしまうことになります。

そこで相補フィルタを使用して、加速度センサ出力にはローパルフィルタ(LPF)により低周波部分だけをとりだし、ジャイロセンサ出力にはハイパスフィルタ(HPF)により、ドリフト分をキャンセルすることができます。

相補フィルタの式だけをみると、至ってシンプルなのですが、奥が深いので別途、相補フィルタのしくみを解明してみる【加速度・ジャイロセンサ】で詳細を解説しています。

下図は加速度センサ、ジャイロセンサおよび相補フィルタを通した出力による角度変化の様子をグラフ化したものです。横軸は経過時間(s)、縦軸は角度(°)です。

加速度センサによる角度は細かなノイズが含まれていますが絶対的な角度を示すのでドリフトは発生していません。

ジャイロセンサによる角度はプログラム内で積分したものなのでノイズもなく滑らかですが、累積誤差によるドリフトが発生しています。

相補フィルタを通した出力では加速度センサによる出力とジャイロセンサによる出力の長所のみを引き継いだものになっていて安定して信頼性があります。相補フィルタのカットオフ周波数は2Hzに設定したものです。

相補フィルタのカットオフ周波数によりどのような違いがあるのかを確認するために4Hzと2Hzで比べてみました。

カットオフ周波数を4Hzに設定した場合はジャイロセンサによるドリフトの影響はないのですが、加速度センサの敏感なノイズ成分が多少含まれています。加速度センサ寄りの影響を受けた出力になっています。

カットオフ周波数を2Hzに設定した場合は加速度センサのノイズ成分はほぼキャンセルされ、ジャイロセンサ寄りの影響を受けた出力になっています。ジャイロセンサ出力からドリフト分だけをキャンセルした出力となっています。

下の図はカットオフ周波数を2Hzの場合で、少し速い動作をさせてみた出力結果です。

加速度センサでは速い動きほどノイズ成分が顕著に現れ、ジャイロセンサではドリフト成分によるオフセットが突然大きくなったりでこのままでは使用できません。

対して、相補フィルタを通した出力ではこのような動作でも遅れは見られずしっかりと追従し、ドリフトの影響もなくほぼ理想の状態となっていてフィルタ効果が確認できます。

相補フィルタをブロック線図で表すと下図のようになります。

加速度センサではノイズ成分を除去した低周波領域の情報がほしいためにローパスフィルタ(LPF)を通します。

ジャイロセンサでは累積するドリフト成分を除去するためにハイパスフィルタ（HPF)を通すと情報のドリフトによるオフセット分をキャンセルできます。

加速度センサあるいはジャイロセンサ単独にそれぞれフィルタを通すだけでなく、組み合わせることでいわゆる互いにいいとこ取りしあうところから相補フィルタと呼ばれます。

相補フィルタに使用するLPFとHPFには条件があり、任意の周波数でフィルタゲインの和が1であることです。

相補フィルタのLPFとHPFでカットオフ周波数を2Hzとした場合の特性を周波数領域のボード線図で表すと下図のようになります。縦軸はゲインを表していて単位はdB(デシベル）ですが、この条件ではLPFとHPFのゲインは足すと全領域で1となります。

LPFはカットオフ周波数fc以上の高周波成分を除去しますので加速度センサからの情報は低周波部分のみが残ります。

HPFはカットオフ周波数fc以下の低周波成分を除去しますのでジャイロセンサからの情報はゆっくりしたドリフトによるオフセット分が除去されます。

カットオフ周波数fcが2Hzとした場合はほぼジャイロセンサによる情報が優勢になります。最終的には出力を見ながらfcを微調整をすればよいと思います。

相補フィルタは結果の式だけ知っていれば使用はできるのですが、式の意味を知らなければなんとなくの当てずっぽうで係数等のパラメータ値を決めることになります。

相補フィルタを使用するのであればやはりある程度式の内容は理解しておきたいものです。

以下の算出過程には難解な理論は使用していないのですが理解するには最低限の古典制御理論の基礎知識が必要ですので、当サイトのフィードバック制御のための基礎知識【準備編】【解析編】を参照してください。

ここでは1次遅れフィルタ、ラプラス変換などの概念がわかっていれば理解できます。

ようやくよく目にする相補フィルタの式を導きました。これは１次フィルタの場合です。これで重み係数Kの意味もわかると思います。

係数Kはカットオフ周波数fcとサンプリングタイムT_S で決まるものです。

一般的に出回っている相補フィルタ情報の中には加速度センサとジャイロセンサの出力に係数Kを重みとしてかけた解釈のものもありますが、これでは意味をなしません。

これまで シリアル通信などでマイコンに取り込んだセンサデータなどはターミナルアプリを使って、PCなどのモニターに出力して表示してきました。これらのデータはリアルタイムで確認できるのですが、数値の表示ですのでデータ変化の様子はつかみにくいです。

特に、動きのあるもの、例えばモータの回転速度や位置など経時変化するデータは数値だけでなく変化の様子などをグラフ表示などで視覚できれば開発途中の解析や、性能のチェック評価などができるようになります。

センサなどから 電気信号を取り込んで、計測・収集したデジタルデータをモニター表示したり、記録したりする装置はデータロガーと呼ばれていて、さまざまなメーカーが製品として提供しています。ここでは簡易的なデータロガーとして、シリアル通信による送信データをリアルタイムでグラフ表示させて、同時にマイクロソフトExcelファイル(csvフォーマット）に保存できるフリーソフトを使うことにします。

私自身も、以前はVB(Visual Basic)やC#などでWindowsアプリとしてシリアル通信で受信したデータをグラフ表示したりする特化したものをプログラミングして自作したものですが、都度特化したもの作成するのも煩わしく、計測目的だけの場合は汎用的なアプリがフリーソフトとして利用できればそれを利用しない手はないです。

直感的に簡単に操作できるデータロガーアプリを探したところ、 データテクノ社のリアルタイムグラフソフト CPLT（ダウンロード先ホームページ）がお勧めです。

初期設定として通信および、縦軸、横軸のスケーリングだけをすれば、すぐに使用できるとてもシンプルで実用的なアプリでフリーで提供いただけることに感謝します。

アプリ CPLT Version xxx の圧縮ファイルをダウンロードしてから解凍し、実行ファイルをダブルクリックするとアプリは起動します。

実際にセンサからデータを取り込んでモニターさせるアプリケーションとしてSTM32マイコン Nucleoボードを使った温度計 を使用し、温度およびサーミスタ抵抗値をモニターすることにします。

回路は上図のとおりで、設定(S)でCOMポート はUSBで認識したもの、 通信条件は プログラム内で設定したもの(9800,8bit,パリティなし,ストップビット1)に合わせます。

チャネル数は２とし、１つ目はサーミスタ抵抗値で2つ目は温度に指定します。各チャネルの属性でそれぞれ名前、単位および目盛りあたりのデータ値（スケール）を指定します。横軸には１目盛りあたりのデータ数を指定します。例えば、1プロットを0.5s間隔で送信している場合は1目盛りあたりのデータ数を10とすると1目盛りが5sに相当します。

温度計アプリプログラム(temp monitor.c)のシリアル送信部のみデータロガー用に修正します。

複数のチャネルを指定するときの注意点として、複数データはカンマ区切りでひとまとめしたものを送ります。数値でも文字列でもアプリで判別するようです。C言語標準関数spirntfを使用する場合はstdio.hをインクルードしておいてください。

これまでのとおり、まずターミナルアプリで送信データを確認してみてください。下図のようにカンマ区切りであればデータ順にCH1、CH2...と認識されます。これで準備は整いましたのでさっそくデータロガーアプリでリアルタイムのグラフ表示を開始してみましょう。

アプリCPLTを起動してからデータモニターは「ファイル」-「ロギング」でデータ収集用ファイル名を指定すると開始します。問題なければCH1,CH2のデータのグラフ表示が始まります。

データプロットの間隔は横軸の設定で調整できますので適当なものに調整してください。グラフ表示されたデータは同時にチャネルごとにExcelファイル(csvフォーマット）に収集されていますので、解析、評価用データとして利用できます。

データロガーが使えるようになると実際のデータがリアルタイムでグラフ化できますのでデータ変化を解析することができるようになります。特に、モーションコントロールでのモータ速度や位置制御のアプリケーションでは実際の動作を確認することが不可欠です。

ホビー用途でも、動作の妥当性を評価するのにデータロガーがあれば電気のアナログ信号をオシロスコープで確認するような感覚でマイコンに取り込んだり処理したデジタル値をモニターに視覚化でき、アプリケーション開発の強力なツールになることでしょう。

マイコンの電源は電池で供給する場合もありますが、ここでは交流電源から電源電圧を供給することについて解説していきます。

標準的なマイコン電源電圧であるDC3.3Vを供給する場合の構成についてみていきます。マイコンのなかにはスマホのようなポータブル機器向けに乾電池一本分のDC1.5V付近で動作するものもあるようです。

日本国内の場合は一般的な電源は交流AC100Vですので、まずAC100Vの電圧を下げて直流に変換する装置（AC-DCコンバータ）が必要です。AC-DC コンバータ はスイッチングレギュレータタイプが主流で、入力電圧を大幅にさげると同時に交流から直流に変換するデバイスです。家電製品に付属のACアダプタもこれにあたります。

マイコンだけを使用する場合にはマイコン電源電圧近くまで直接スイッチングレギュレータで電圧を落とし、例えばDC５Vをつくることもありますが、ここでは 市販のセンサ等用電源のようなマイコン電源電圧よりも高い電圧が必要な場合も考えて、中間のDC12VやDC24Vの電源をつくることにします。

次に中間のDC12VやDC24Vの電源 をマイコン電源近くまで落とすためにDC-DCコンバータという部品を使用します。このDC-DCコンバータも原理はスイッチングレギュレータと同じもので直接マイコン電源のDC3.3をつくってもよさそうなのですが、スイッチング・レギュレータで発生するノイズを考慮して、リニアレギュレータと呼ばれる部品を更に1段追加して使用することにします。

ダイオードとの組み合わせによる半波または全波整流回路と平滑コンデンサを組み合わせた方式や負荷に直列にトランジスタなどの素子で負荷電圧をコントロールするシリーズレギュレータ方式があります。 これらは交流入力電源をトランスを介して降圧してからダイオードブリッジによる整流するところまでは共通です。

最も簡易的な直流電源です。チョークコイルと平滑コンデンサで出力電圧をならしても多少変動リプル分は残っています。

前述の回路に負荷電圧が常に一定になるようにフィードバック素子を設けてコントロールしています。この方式の直流安定化電源はとても安定しておりノイズが発生しないなどの長所がありますが、トランスを使用していますので電圧の降下分が損失となりサイズがやや大きくなります。

俗にスイッチングレギュレータ、スイッチングパワーサプライやACアダプタとよばれるもので今や家庭でも目につかないことがないほどありふれたデバイスです。樹脂でモールドされたものは比較的小さな容量で家電製品にも付属するもので、産業機器用のものは容量も大きなものが選択でき、放熱も考慮した金属製のフレームとなっています。

このスイッチングパワーサプライは商用電源を入力として半導体のスイッチング素子でいわばパルス幅変調PWM(Pulse Width Modulation)の原理で平均電圧をコントロールしているものです。このため、リニアレギュレータ方式では降圧のためにトランスを使用するのに対して、スイッチング方式ではトランスを用いなくても降圧できるため、サイズを小さくでき、軽量化も図れるのが特徴です。最大の特徴はリニアレギュレータ方式に比べ発熱が小さく、効率が高いことです。

反面、高速でスイッチング動作させることによる高調波のノイズが発生し、出力電圧にもリップルとして現れ、入力側にも悪影響をおよぼしますので、しっかりしたノイズ対策が必要な場合があることを理解して使用します。

マイコンに限らずスイッチングパワーサプライを選定する際のポイントは、負荷側で最大どれくらいの容量（電流）が必要かを算定しておき、不足しない大きめなものを選ぶようにしましょう。

直流電圧をマイコン電源近くまで落とすためにはDC-DCコンバータという部品を使用します。このDC-DCコンバータは直流を直流に変換するスイッチング方式で降圧のみならず昇圧ができるタイプもあります。変換したい電圧差があまり大きくない場合は、次に説明するリニアレギュレータ（三端子レギュレータ）と呼ばれる部品が安価で気楽に利用できるのですが、電圧差が大きい場合には負荷で使用できうる最大電流による発熱を考慮してDC-DCコンバータを使用するのが無難です。

DC-DCコンバータはいろいろなメーカーから製品がだされていますが、入力と出力が電気的に絶縁しているタイプやリニアレギュレータと互換製のあるピン配置のタイプもあります。

前者の絶縁DC-DCコンバータは入力側を出力側から電気的に切り離すことで安全製を確保したり、ノイズ対策とすることができます。後者の DC-DCコンバータ はリニアレギュレータと互換性があるので発熱等で不安がある場合に簡単に置き換えることができます。三端子レギュレータの感覚で、例えば、入力DC24V/出力DC5Vのような大きな降圧差がある場合で出力に500mAほどの負荷電流をとれるものでも放熱板なしで使えるところが便利です。

一般に三端子レギュレータと呼ばれる定電圧回路を簡単に構成するための電子部品です。このうち入力電圧と出力電圧の差が小さくても(１V程度）動作するタイプはLDO（Low Drop Out)レギュレータと呼ばれています。スイッチングレギュレータ、DC-DCコンバータおよびPCのUSB電源などによる直流電源を入力としてマイコン仕様にあった電源電圧出力をつくるのに使われます。

入力と出力の関係がリニアつまり線形であることからリニアレギュレータと呼ばれています。入出力間に負荷電圧をコントロールする素子が直列で構成されていることからシリーズレギュレータとも呼ばれます。

リニアレギュレータは入出力の電圧差が大きいと損失も大きくなることから発熱も大きくなるものですが、スイッチングレギュレータのような高速スイッチングを行っていないためノイズが発生しなく出力電圧はとても安定しています。特にLDOでは入出力の電圧差が小さくても動作するため、マイコンの電源用として最適です。

使用するにあたってはレギュレータの機能を安定させるために入力側、出力側の各端子とGND間にコンデンサを付加します。

何らかのトラブルで出力側に発生したサージ分を入力側に逃がしてレギュレータを破壊から守るために保護ダイオードを付ける場合もあります。

マイコンを電池で駆動する場合は直接マイコンに接続するか、リニアレギュレータ（LDO)だけを使ってマイコン仕様の電源をつくります。LDOレギュレータを使用するとマイコン電源電圧に対して約１V以上高い入力電圧であることは必要ですが最低限の部品で電源回路が構成できます。

電源回路につきものの部品にコンデンサがあります。コンデンサといっても容量、耐圧、周波数特性などさまざまなタイプがありますが、電源周辺で使用するものではアルミ電解コンデンサ、タンタル電解コンデンサおよびセラミックコンデンサの３種類を知っておけばよいでしょう。

コンデンサの選定では種類、容量の他、耐圧、さらに周波数特性を考慮する場合もあります。特に高い周波数の用途では等価抵抗ESRや等価直列インダクタンスESLといったパラメータも重要となりますが、マイコンの電源用途ではそう神経質になるものではありません。

マイコンでの製品化するにあたっては電源周辺に仕様書に記載しているコンデンサを配置して電源を安定化させることが重要です。この役目のコンデンサは バイパス (デカップリング)コンデンサと呼ばれます。

スイッチングレギュレータ、DC-DCコンバータ、そしてリニアレギュレータを介してマイコン電源は作られるのですが、実際の回路にはプリントパターンなどが複雑に入り組んでいます。そのため、仕様通りの電源電圧をマイコンにあたえていて理論上では問題なくても、いろいろなノイズの影響などでマイコン電圧が不安定になることがありえます。

そこで、仕様書に記載されている容量のコンデンサをマイコンの電源端子のできるだけ近い位置に配置します。プラス側V_DDとGND側V_SSはマイコンによりますが、５組から10組程度あり、すべての組に0.1uF程度の周波数特性のよいセラミックコンデンサを細かな変動を抑える目的で配置します。

電源のおおもとには4.7uFから10uF程度のアルミ電解コンデンサ、タンタル電解コンデンサあるいはセラミックコンデンサを大きな変動を抑える目的で配置します。

最近のマイコンでは抵抗器RとコンデンサCで構成されるRC発振回路を内蔵していますので、マイコンの外部にわざわざ振動子を設けなくてもシステムクロックを内部クロックとして発生させることができます。

STM32マイコンでもシステムクロックに内部クロックを使用する設定にすると外付けの振動子を使用しなくても動作させることができ、部品点数を減らせることで、スペースやコストの節約が実現できる利点があります。

ただし、内部クロックは水晶振動子によるクロックに比べて周波数精度が劣ることに加え、製品ごとのばらつきや温度、動作電圧など周辺環境により周波数が変化することもあるため、アプリケーションにより使い分ける判断が必要です。

例えば、非同期式シリアル通信UARTなどは他の機器に同調させるために正確なクロックによるボーレートの設定が不可欠ですので精度の高い外部クロックを使用するのが無難です。

水晶振動子には従来のメタルパッケージのものと樹脂モールドパッケージによるものがあります。一昔まえのものに比べるとずっと安定して発振するものですが、電源電圧が低いアプリや電圧変動があるようなアプリでは注意が必要です。

一般的なメタルパッケージの標準的な水晶振動子であれば物理的なサイズの余裕もあるので比較的安定していますが、表面実装タイプ（SMD)でサイズの小さいものなどを使用する場合は十分な検証が必要かもしれません。

外部クロックには水晶振動子の他にセラミック振動子と呼ばれるものもあります。これは水晶振動子と同じく機械的な共振によるもので周辺温度などの影響を受けにくく水晶振動子に比べると多少精度は下がりますが内部クロックによるものよりも精度は高いものです。

セラミック振動子によるクロックは水晶振動子によるものと内部発振回路によるものの中間的なもので、安価なうえに、発振回路に必要なコンデンサを内蔵している３端子タイプを使用すると気楽に選定できます。

３端子タイプでは上図の点線で囲んだ部分を一つの部品に置き換えることができるので省スペースも図れます。

水晶振動子やセラミック振動子は電圧を与えて機械的な共振を発生させるタイプですので、パラメータ選定に誤りがあったり、マイコンとの相性が良くない場合にはクロックが停止してしまうことがないとは言えません。

そこで、振動子ではなく発振回路が内蔵した発振器を振動子の代わりに接続する方法もあります。部品の単価は上がり、サイズも大きくなりますが電源入力だけでパルスを発生する確実な方法であるといえます。発振器出力をマイコンの外部クロックの入力側（STM32マイコンではOSC_IN）に接続するだけです。

STM32F1xxシリーズのファームウェアではデフォルトで8MHzの外部クロックを使用することになっています。そのため、Nucleoボードを始め、多くの評価基板では8MHzの水晶振動子を使用していることが多いです。

例外的に、STM32F103VEを搭載したSTBeeボードでは12MHzの水晶振動子が搭載されていますので、設定し直さなければ例えば、シリアル通信などではボーレートが他の機器とは合わなくなってしまいます。そこで、外部クロックの周波数を変更する箇所を見ていきましょう。

外部クロック周波数はstm32f10x.h内でHSE_VALUEと定義されていますので、この値をデフォルトの80000000から使用する周波数、例えば12MHzの場合は12000000に変更すればよいだけです。