わふうの人が書いてます。

iOSアプリケーション開発、BLEのファームウェアとハードウェア試作のフリーランスエンジニア。

電気式の圧力鍋を比較検討

売れ筋から検討してみる

価格サイトの商品ランキングから、電気式の圧力鍋を抜き出してみます。

  • パナソニック, 2万円
    • https://panasonic.jp/cook/products/SR-P37.html
    • 3.7L/1.4L, 31.5x27x29.6cm, 4.1kg, 800W。
    • 圧力は操作パネルで切り替え設定、98kPa(120度), 59kPa(低圧 113度)。低温料理可能(70/85/95度)。
    • 商品ラインナップは、SR-P37の1機種のみ。完全に、電気ヒータ付きの圧力鍋そのもの。
  • シロカ, 1.5万円
    • https://www.siroca.co.jp/kitchen/autoclave/
    • 2~6人の4リットル、1~3人の2リットル。容量2種類xスロー機能有/無で、4機種のラインナップ。
    • SP-4D151, 4L/2.6L, 90kPa, スロー機能あり, 26.5x28.2x28.3cm, 4.4kg, プリセットで、おかゆもある。蒸し台。
    • SP-D131, 2リットル/1.3リットル, 70kPa, スロー機能付き、2リットル版、22x23.8x24.9cm, 2.7kg、蒸し台。
    • スロークッカー(85度調理)。無水料理。
    • 蓋を回転させてしめる。圧力のピンが出てくるから、本当に圧力の電気鍋。

どれにするか

目的は、材料を切って調味料と一緒に入れておくだけで料理が完成すること。また、タイマー予約でアツアツの料理を楽しめることです。

電気式でも、その基本は圧力鍋でしかありませんが、マイコンがあり温度と圧力が制御されることが特徴です。料理の条件は、温度と圧力履歴で決まります。1人分でも4人分でも同じ温度と圧力履歴を与えれば、同じものができてくるはずです。ただガス火では、食材の分量が異なれば熱容量も異なりますから、その条件を人が調整するほかなくなります。電気式は、そこがマイコン制御にできるのが利点になります。また、電気式の圧力鍋は、ガス火をみておく必要がなく、温度制御で水蒸気が出るのも抑え目にもなります。

製品価格は、1万円代のものと3万円代のものの2つに分けられます。

1万円代のものは、タイマーのついた圧力鍋そのものです。電力は800Wくらいです。マイコンはついていますが、人が設定できる条件は圧力の大きさと時間くらいでしょう。シロカの製品は、メニュー選択があります。プリセットのメニューが、希望の料理に合えば良いのですが、なければ最初に沸騰させてからしばらく保温して火を通すなどの、いくつかのシーケンスの組み合わせは期待できません。

3万円代のものは、ティファールおよび象印の製品です。メニューを選択して料理のシーケンスが実行されるものです。圧力鍋というより、温度と圧力を制御できる自動調理器です。電力は1200Wくらいです。800Wのものより素早い温度上昇ができそうです。無水料理に対応していて、アクアパッツァが作れるのは楽しそうです。圧力鍋といえば定番と言える骨まで柔らかいイワシの煮物だけではなく、普通の鯛のアラや魚の煮物ができるのは、嬉しいです。

ざっと見ると、1万円代の製品は、電気式の圧力鍋で800Wくらいの加熱能力。ガス火の調整とガス火を見ている手間を省きたいなら、安価で良い。3万円代の製品は、料理のシーケンス実行装置になっている。蒸し物からスロークッキングまで多種多様な料理ができる。魚の煮付けを手軽に楽しめるのは、お魚が好きな人には嬉しいかも。

1万円代なら、デザインでシロカがよさそうですね。

3万円代で、ティファールと象印のどちらを選ぶかですが、機能自体はどちらも同じような感じですから、もう好みで選べばいいのではないでしょうか。

iMacの2015lateから2019earlyは、買い替え時期?

2019年3月でiMacのプロセッサが高速化されました。今使っている2015lateから買い換えるメリットはあるのでしょうか?

iMacの3つある種類のうち、真ん中のもので、プロセッサのベンチマークでシングルスレッド/チップ全体で、2015lateで 1947/7244、2019earlyで 2510/12631 ですから、シングルスレッドで1.3倍、チップ全体で1.7倍の演算能力。

メモリが1867MHzから2666MHzで、1.4倍ですから、プロセッサの処理能力向上分と合うメモリ帯域の向上なので、だいたい1.4倍程度の高速化でしょう。

なので、お金が余っていれば買えばいいという、よくある感じですね。

VESAマウントありのiMacが便利

iMacは本体に直接取り付けられたスタンドが付いていて、上下の角度変更はできますが、高さ調節機能はありません。
VESAマウント+ディスプレイアームにすると、高さ調節だけではなく、奥行き方向にも移動ができて、また何かに引っ掛けてiMacを落とす心配がなくなります。

Appleのサイトから、スタンドがなく背面にVESAマウントがあるiMacが購入できます。通常本体価格に +1万円 くらいになります。 https://www.apple.com/jp/shop/buy-mac/imac-vesa

ディスプレイアームは、10kg程度のものを扱えるものとなると、エルゴトロンのLXくらいでしょう。

2015lateの真ん中くらいの機種

2019early imac 真ん中の

2019earcyで、+5万円するとどのくらい?

5万円プラスで選択できるi9-9900Kだとどうなるか? シングルスレッドで1.15倍、コア全体で1.6倍になる。メモリ帯域は同じだから、マルチスレッドでキャッシュが効く状態で演算量がとにかく欲しい場合には、メリットがありそう。

参考までに今のiMac Proだとどのくらい?

Googleから、ゲームプラットホームstadiaというのが発表されたそうで

はじめに

2019年3月19日、Gather around.でGoogleが見ているこれからのゲーミングのプレゼンテーションが始まりました。

方向性は

GoogleはすでにYouTubeという大きな動画プラットホームを持っています。その動画プラットホームの中で、ゲームプレイを放映するトッププレイヤーと、その視聴者というコミュニティができています。

キーワードは、2つ。まず、秒速ですぐに入れること。ブラウザでリンクを踏めば次のサイトに行ける体験そのままに、そこにゲームを織り込むこと。次に、コミュニティ。ゲーム開発、プレイヤ、視聴者とを関連付けるプラットホームということ。

技術的には

単純なシンクライアントです。

AMDと共同開発した強力なGPUとカスタムなx86プロセッサをデータセンタに配置し、そこからゲーム動画を配信します。どのような画面にも、どのようなデバイスにも配信できます。また専用のコントローラも提供し、このコントローラはGoogleのデータセンターにインターネット・プロトコルで繋がります。

プレイの状態はGoogleのデータセンタに保持され、GPUで作り出す高精度な画像を配信する形です。Project streamingの成果を活用などとありますから、WebRTCなどの技術を活用して、動画像コーデックとプロトコル・スタックとを垂直統合したソフトウェア資産を活用して、回線品質に合わせたレイテンシーの小さな配信技術に基づくのでしょう。

OSはLinux、そこでvulkanが動いている。ゲームエンジンは、unreal engine や unity が対応。普通のゲーム開発環境ですね。

これでゲームのインフラ担当者がいらなくなるのか? と想像しても、結局はクラウド側の開発は従来と何も変わらず必要でしょう。ただ、他の大きなゲームで構築されたクラウドの知見が、Googleにより一般化されてフレームワーク/サービス化されるくらいの流れは出てくるか。

AWSできる技術者が、AWSに詳しくなるとAmazonに転職してしまうという話がありますが、ゲームのクラウド側に詳しくなった人がGoogleに転職して、そのスキルを一般化してサービス化する程度の人材流動は起きるのかも?

費用負担とレイテンシは?

10年前にiPhoneやAndroidが登場して、今やその2つのプラットホームの上で、ソーシャルゲームや電子書籍などのサービスが走っているように、新しいプラットホームは、一度軌道に乗ってしまえば、それがあるのが当たり前になりますから、メリットデメリットを考えても、意味はないかもですが。

Googleの負担費用は大きいのでは? ゲーム装置をデータセンタでホストする形ですから、その費用はすごいものでしょう。プレイヤーが増えれば、それを吸収する処理能力を持たないといけない。でも1日中ゲームをしているわけではないですし、Google自体がすでに毎秒莫大な計算量を消費している会社ですから、総量からいって、大したことないのかも?

自動車のシェアリングで、自動車の販売台数が変わっていくのか、自動車のサービス化になるのかみたいな話があるけど、ゲームが、プレイするなら本体確保、が前提としてなくなると、本体の売れ行きはどうなるのかしら。

専用プロセッサとGPUといっても、他の計算にも使えるのかもしれませんし。最近話題の機械学習の学習には使えなくても、ユーザへのサービスとしての推論には使えるでしょうし。

シビアなゲームだとレイテンシで実施できないのでは。操作に対して画面が更新される遅れがゲーム体験を損なうというのは、フレームを競う一部の対戦ゲームではそうかもしれないけど、そんなゲームばかりではないでしょうし。

ただ、このゲームプラットホームって、コミュニティを前提としたプラットホームだから、仮に二人対戦のゲームだとしても、それを見ている観客がいる形になるだろうから、レイテンシを前読みして操作するくらいのプレイヤーの進歩が出てくるだけだと思う。

技術的に遅延をもたらすのは、ネットワークのレイテンシ、データセンタでの処理時間、そして動画像の転送時間。ネットワークのレイテンシは究極は光の速度だから、それはもう仕方ない。データセンターの処理時間はゲーム機の処理時間そのものだからそれは従来と変わらない。動画像の転送時間は、将来的に120+fpsを転送する程度で、フレーム間圧縮で2フレームほど食われたとして、1/60秒程度か。

リンクで素早い体験ってFlashのゲーム?

昔に、Flashでゲームを作り自分のブログで公開する体験が、日本で結構盛り上がったことがあった。リンクを踏んだら即ゲームって、その体験そのものっぽいのでは?

クリエータどこいった? 今ではそんな個人制作のゲームは、夏のイベントで同人ゲームを販売している方々はいますが少なくともウェブでは、もう見かけない。かつてFlashゲームを作っていた方でも、ソシャゲの会社で働いていたりとか。収益源がないから、継続しないし、個人で作れるボリュームはさほどはないから話題になったらボリュームをあっという間に消費して、話題としてちゃんと忘れ去られる。

リンクでプレイを共有したり、状態保存したり、アドバイスもらったり

ゲームで行き詰まると、ちょっと質問すると、Googleアシスタントがヒントをくれたりとか、ゲームの状態を保存してリンク共有とか。PS HOMEでもプレイ動画共有とかあるけど、全てがデータセンターにあるなら、一層そういった共有的なものが強く出てくるのかも。

今でも、ゲーム攻略サイトがあるのだから、ちょっと詰まった時に質問したらヒント(あるいは、解答そのもの)がもらえる体験が当たり前になるのは、それはそれでありになるのかも。難しいことを難しいままクリアできるか、ヒントをもらってちょびっと上達するか、上達せずクリアできました体験だけするのかは、選択の自由なのかも。

モバイルデバイスのその先?

今のソシャゲは、モバイル向けは動画転送量的に利用者が使わないだろう。よほどの大容量で安価な料金プランでもない限りは。

ブラウザ的になることで、iOSデバイス向けにも配信できる、つまり課金ができるのかも?

ゲーム以外の視点

技術的にはこれ、シンクライアントそのものですよね。ゲームだけじゃなく汎用性があるでしょうから。

未来的な映画とかの設計シーンで、3D CADを動かして、VRのヘッドマウントディスプレイでモデルを見ながら協調設計して、空洞シミュを動かしたりとか出てきますけど、そういうのが普通にできる程度に。

YouTubeの操作できる動画としてみなすなら、バーチャルYouTuberもあるけど、モデルデータの選択とステージ選択さえあれば、そのまま配信できちゃうだろうし。いろんな概念が、1つの仕組みで統合されていく感じはするのかも?

hexoの設定メモ

新規にhexoをインストールして設定を見直したので、そのメモ。hexoのバージョンは 3.8.0。

画像リソースをpostごとに管理する

これまでは、記事でしか使わない画像を、グローバルアセットとして使っていました。画像ファイルを post/post_imageに置いて、記事のMarkdownのテキストの中で { % img /post_images/画像ファイル名 %} と参照していました。記事名と同じフォルダの中に画像をまとめることで、記事と画像の紐づけはなんとかできるのですが、フォルダのある場所が異なるので、ちょっと気持ち悪さがありました。

3.8.0 だと、記事だけで参照できるローカルなアセットが使えるみたいです。ドキュメント https://hexo.io/docs/asset-folders.html にある通り、_configure.ymlpost_asset_foler: true にすると、hexo new {記事名}をすると、postフォルダの下に、記事名と同じフォルダが作成されます。

このフォルダの下に画像ファイルを置いて、asset_img マクロで参照すればよいわけです。imgマクロで参照すると、記事の中では画像が表示されますが、インデックス画面(hexoで生成したサイトを表示した時に表示される、複数の記事をまとめてインデックス表示しているあれ)で画像が表示されません。URLのパスの位置が違うからですね。asset_imgを使えば、インデックスでも画像が表示されます。

1
2
{% asset_img example.jpg This is an example image %}
{% asset_img "spaced asset.jpg" "spaced title" %}

デプロイをshellにする

記事はAWS S3に置いて、CloudFrontで配布しています。hexoのs3プラグインなどがありますが、何か動きがおかしかったり、シークレットキーをソースの中にベタがきしたり、環境変数に設定したりと、ちょっと微妙なものばかりです。あと、CloudFrontのキャッシュの無効化が必要なのですが、s3関連のプラグインにそんな機能はないみたいです。

そこで、aws cliをshellで呼び出して使います。こんな感じの設定を_configure.ymlにしています。

1
2
3
4
5
# Deployment
## Docs: https://hexo.io/docs/deployment.html
deploy:
type: shell
command: /usr/local/bin/aws s3 sync --acl public-read --delete {hexoのpublicのフォルダ} s3://{バケット名} --exclude '*.DS_Store';aws cloudfront create-invalidation --distribution-id {識別子} --paths '/*'

Nature remoをiOS ショートカットアプリとSiriで活用する

家にあるエアコンや照明などの多くの家電は赤外線リモコンがあります。 Nature remo https://nature.global は、赤外線信号の送信と、気温などのセンサーを備えた数千円から1万円のデバイスと、クラウドからデバイスを操作する機能を提供します。

Nature remoで、アプリを設定して家に近づいたりなどの条件で機器をオンオフしたり、Amazon AlexaやGoogle Homeと連携して、音声での家電操作ができます。しかし、Nature remoの説明には、Siriとの連携がありません。

公式ブログで、iftttというサービスを中継してSiriで家電操作をする方法 (iOS12のショートカットを使い、SiriからRemoを操作する)[https://nature.global/jp/ifttt-setup/ios12siriremo] が紹介されています。

しかし、複数のサービスを中継するのは、1つでもサーバーが落ちていたら利用できなくなる不安感だけではなく、なんとなく嫌です。そこで、Nature remoを使い、iOSのショートカットアプリを活用して公式のウェブサービスを直接叩いて、Siriから機器操作をしてみます。

手順は:

  1. Nature remoのAPIで使う、エアコンや赤外線信号を表す識別子を取得する
  2. iOS ショートカットアプリから、Nature remoのAPIを叩く
  3. SiriからiOSショートカットアプリが実行されるように、音声コマンドを紐づける
    の3つです。

Nature remoのアプリでの設定

まず、Nature remoの設定説明に従い、エアコンと照明の設定を行います。まず、エアコンを設定します。Nature remoの説明通りに、エアコンの赤外線リモコンの信号を読み込むと、メーカー名を自動判別して、アプリにエアコンの設定画面が追加されます。照明は、赤外線リモコンのボタン1つ1つを読み込んで、それぞれアプリのボタンとして登録していきます。

エアコンと照明の設定が終わると、アプリにはこのような画面ができているでしょう。

外出時などに、エアコンと照明をまとめて消したいなど、複数の機器を操作したい時には、Nature remoのアプリの”シーン”を使うと便利です。例えば、エアコンと照明をまとめてオンにする場合は、このようなシーンを作成します。オフにするシーンも同様に、機器をオフにする項目をまとめたもので作れます。

Nature remoのアプリで、ルールを追加して、家電製品の振る舞いを作れます。例えば、ルールの家から離れる、家に近づくに、エアコンのオフオンを関連づけておけば、いわゆるスマートホームのデモンストレーションでよく使われる、家に帰ってくるとエアコンが動いていてすでに暖かい、などができます。

Nature remoのセンサーの値と紐付けておくこともできます。私は、室温がある温度以下になったらエアコンをオンにするルールを追加しています。睡眠時にエアコンの動作音がするのが嫌で、寝る前にエアコンを切るのですが、朝起きた時に部屋が寒いのも嫌なので、室温がある温度以下になったら、エアコンを入れるという使い方です。

機種は、1万円程度のNature Remoと、7000円代とより安価な Nature Remo mini があります。それぞれの違いは搭載しているセンサーの種類です。Nature Remoは、温度、湿度、照度、人感センサーがあります。Nature Remo miniは、温度センサーだけがあります。人がいたら、あるいは照度や湿度がある値になったらというルールを作るなら、Nature Remoが必要です。そのようなルールが必要ない、例えば先ほどの例のようにある温度以下になったらエアコンを入れるように温度だけしか使わないなら、Nature Remoがよいでしょう。

Nature remoのAPIで使う、エアコンや赤外線信号を表す識別子を取得する

Nature remoは、ネットワークから機器を操作するAPIを提供しています。このAPIを使うには、ユーザーの認証トークンと、機器あるいは信号の識別子が必要です。これらを取得しましょう。

開発者サイト https://developer.nature.global を見ると、APIにはローカルAPIとクラウドAPIとがあります。どこにいても機器を操作したいので、ここではクラウドAPIを使っていきます。

ローカルAPIは、家のWiFiなど同じネットワークに繋がっている時に呼び出せるAPIで、赤外線のパターンの生信号そのものを取得/送信するものがあります。クラウドAPIは、エアコンや機器の識別子を使って、温度設定などができます。おそらくNature remoの機器自体には、ローカルAPIの赤外線の信号そのものを扱う機能だけが実装されていて、メーカごとのエアコンの赤外線信号を組み立てる機能は、クラウドつまりサーバー側に実装されているのでしょう。

Nature remoの機器にアクセスするための、認証トークンを取得します。 https://home.nature.global で、左下にある”Generate access token”を押すと、トークンが生成されて画面にそれが表示されます。このトークンは生成したその時だけしか表示されませんから、メモ帳か何かでもいいと思いますが、どこか自分しか読み書きできないところに一時的に保存しておきます。

ネットワークサービスを使う時にユーザ名とパスワードとを決めますが、このトークンは、そのユーザ名とパスワードと同じようなものです。このトークンは、ユーザしか知らないはずです。ですから、このトークンがあれば、今APIを使おうとしている人が、正規のユーザだと思い込めるわけです。もしも、トークンが誰かに知られて、いたずらされるようなことになったら、そのトークンを削除して無効化します。

認証トークンを使い、機器や赤外線信号を表す識別子を取得していきます。もしもNature remoAuがOAuth2に対応でもしていれば、 http://http://swagger.nature.global/ からAPIを呼び出して、機器のリストが取れるのですが、そんな対応はしていないので、ターミナルから次のコマンドを実行してAPIを叩きます。

$ curl -X GET “https://api.nature.global/1/appliances" -H “accept: application/json” -H “Authorization: Bearer {ここにアクセストークンの文字列を入れる}”

認証トークンはヘッダに与えます。アクセスができれば、何やら文字列がわーっと表示されるはずです。認証トークンの設定など何か間違えていると、’’ {“code”:401001,”message”:”Unauthorized”} ‘’ という表示が出ます。これは認証ができなかったという意味です。トークンを間違えているか何かでしょう。

このわーっと出てきたテキストは、JSONという形式での機器一覧です。このままでは読みにくいので、一度このわーっと出てきたテキスト部分をコピーして、適当なJSON整形サイトなりで整形して読める形にします。

ざっと見ていくと、エアコンにつけた名前付近に、”ID”という項目があります。これがエアコンを示す識別子です。

照明の赤外線信号につけた名前付近を見ていくと、やはり”ID”という項目があります。これが赤外線信号を示す識別子です。これらの識別子を、どこかに記録しておきます。

iOS ショートカットアプリから、Nature remoのAPIを叩く

iOSショートカットアプリから、Nature remoを経由してエアコンと照明を操作します。まずiOS のショートカットアプリをインストールしておきましょう。https://itunes.apple.com/jp/app/id915249334

Nature remoのAPIは、APIのリスト http://http://swagger.nature.global/ にあるように、エアコンはエアコン特有のAPIに、赤外線信号を送信するだけの機種は信号を送受信するAPIが、それぞれ提供されています。

まずエアコンを設定します。まず、オンの設定を追加しましょう。ショートカットアプリで、”+ショートカットを作成”をタップして、メニューから”URL”を選択します。次に “URLの内容を取得”を選択します。

ここで、エアコンのオンの設定を次のように入力します。文字列を入力するのは手間ですから、Macがあるなら、Mac側でテキストをコピーすれば、iPhoneの方にその文字列をペーストできますから、その機能を利用するとよいです。設定ができれば、今開いている編集画面のヘッダ中央にある”▷”ボタンを押します。エアコンがオンになれば設定ができています。動かない場合は、例えば次の画像は、認証トークンの値を間違えている場合の画面ですが、このようにサーバーが失敗した理由を返しているので、それを見て修正します。

同じようにしてオフの設定を入力します。オンの設定との違いは、本文を要求という項目が増えることだけです。ですから、ですからオンのボタンを複製すると設定の手間が少ないでしょう。ここで”本文を要求”の設定を間違えている(buttonのスペルを間違えてbutonにしているなど)場合は、APIはオフではなくオンとして動きます。

  • 本文を要求: フォーム
  • button: power-off

次に照明のオンオフを設定します。専用のAPIがあるエアコンとは違い、今度は任意の電化製品の赤外線リモコンの送信コードを送信するAPIを使います。照明オフの設定は、URLの赤外線信号の識別子を、オフの赤外線信号の識別子に置き換えるだけです。

SiriからiOSショートカットアプリのショートカットを実行させる

ここまでの長い道のりで、やっといよいよSiriからの操作ができます。

その前に、エアコンや照明を1つ1つ設定するのも面倒です。1つ1つのAPIごとに設定したショートカットをまとめるショートカットを作っておきます。ショートカットの作成で、”ショートカット”で検索すると、すでに登録されているショートカットを呼び出す項目が表示されます。これを複数配置して、必要な動作を1つのショートカットにまとめます。

あとは、ショートカットの右上にある、完了の下にあるボタンを押してSiriに連携させます。”照明をつけて”などだと、HomeKitの方に処理を持って行かれます。ぶつからないフレーズとして、電気を入れて、と設定しています。

ホーム場面に追加をしておくと、ホーム画面のアイコンのタップだけで、操作ができるようになって便利です。ショートカットの共有は、このショートカットの設定に認証トークンや機器の識別子など、ユーザだけが知り得る情報が入ってしまっているので、すべきではありません。もしも公開したら、世界の誰かが共有されているショートカットを使えば、自分の家の機器が動いてしまいます。

最後に

Nature remoを、iOSのショートカットアプリ、そしてSiriから操作する手順をまとめてみました。今回はAPIを直接叩くようにしましたが、Google HomeやAmazon Alexaを使っているならば、それらのサービスのiOSアプリを活用するか、あるいはショートカットアプから、それらのサービスごとのアプリの機能を利用するのがよいのかもしれません。

とにかく、設定はめんどくさいですが、動いてしまえば、ちょっと便利ではあります。設定の労力に見合うかといえば、人によるかもしれません。微妙ですね。

PushKitでデバイストークンが取れない。

PushKitでデバイストークンが取れなくて、困っていました。原因は、バックグラウンドのオプション指定に、VoIPが含まれていないことです。

Xcode ver9.2では、アプリケーションターゲットのバックグラウンド・モードにVoIPがなくなっています。ですが、アプリケーション内部ではVoIPのオプションを見ています。Infoタグで、Info.plistの編集で手動で、バックグラウンドにVoIPを含めるようにします。

Capabilitiesタブのバックグラウンドを変更するたびに、この手動で追加したVoIPは、Xcodeにより消されます。なので、忘れずに手動で再度VoIPを、バックグラウンドに追加します。

micro:bitは業務に使える? 加速度を表示するiOSアプリを作ってみる

何したの?

加速度の大きさで信号を出力するものを試作する案件に、micro:bitが使えるかと思い、試作に用いてみました。HEXファイル、iOSアプリのソースコード、アプリの動いている動画などのリソースは https://github.com/reinforce-lab/microbit_accs_siwtch にあります。

マイコンというハードウェアへのファームウェア書き込みは、書き込み装置が必要で、書き込み手順を覚えなければならず、誰でもできるものではありません。このマイコンボードであれば、誰でもファームウェア更新ができます。これなら、ファームウェアを書き込んだハードウェアを送付しなくても、HEXファイルを送るだけですむかもしれません。

どんな情報があるの?

自分で作るiOSアプリケーションと、micro:bitとの間の、任意の情報のやり取りの実装方法があります。iOSアプリケーションの表示画面は、このようになっています:

micro:bitで、文字列に組み立てた加速度や内部設定値、そしてIOの情報を、BLEを経由してiOSアプリに伝えています。iOSアプリで、それをグラフ表示しています。
iOSアプリから、設定値をBLEでmicro:bitに伝えて、micro:bitのプログラムで、その値を該当する変数に格納しています。

micro:bitに最初からあるIOサービスを使い、BLE経由でセンサやスイッチの情報を読み取るサンプルはたくさんありますが、自分のプログラムで処理した内容を外部に伝えたいときのスタートポイントになるでしょう。また、外部からmicro:bitへ情報を伝える方法の解説が、なぜか、見かけませんが、BLE UARTを使った情報の渡し方の解説になっているでしょう。

micro:bitって?

micro:bit http://microbit.org/ja/ は、プログラミング教育の教材で、Nordic Semiconductor社のnRF51822を使ったマイコンボードです。

グラフィカルにブロックを並べてプログラムを組み立てられるビジュアル・プログラミング環境があります。またBluetooth low energy(BLE)でスマートホンと通信できるので、スマートホンやタブレットで作ったプログラムをBLEで書き込んだり、スマートホンとマイコンボードとで通信ができます。

nRF51822は、RAM容量が16kバイトと32kバイトの2品種がありますが、micro:bitに使われているマイコンボードは16kバイトのものです。BLEをまったく使わない場合は、16kバイトのRAMを全てユーザのアプリケーションに使えます。BLEを有効にすると、BLEのスタックが12kバイトのRAMを使うので、ユーザのアプリケーションに使えるRAM容量は4kバイトになります。スタックに最低2kバイトが必要ですから、実際に使える容量は2kバイトです。

プログラミング環境

micro:bitの開発環境は、TypeScriptを用いるものと、Pythonを用いるものの2つがあります。いずれもビジュアルプログラミング環境が提供されていますが、テキストでソースコードを書くこともできます。Pythonの開発環境では、BLEは使えません。その代わりに、Nordic Semiconductor社の独自プロトコルの無線通信機能のみが使えます https://lancaster-university.github.io/microbit-docs/ubit/radio/ 。この独自プロトコルの無線通信は、micro:bitのボード間の通信はできますが、BLEではないので、スマートホンとは通信できません。

TypeScriptを用いるものは、Microsoft社のmake:codeで提供されています。下層は、arm mbedとNordic nrf51を使ったC/C++開発ランタイム https://lancaster-university.github.io/microbit-docs/ です。TypeScriptで書いたソースコードが、このランタイムのAPIを呼び出す形になります。

TypeScriptは、Microsoft社が開発している、JavaScriptに静的型付けとクラスベースのオブジェクト指向を加えたJavaScriptのスーパーセットになるよう定義された言語です。make:codeのプロジェクトは、TypeScriptのサブセットでプログラミングができます。TypeScriptで書いたソースコードは、ウェブブラウザの内部で構文解析されて、Arm thumbコードに変換されて、HEXファイルが生成されます。ローカルで、機械語とHEXファイルの生成まで行い、ユーザのコンパイルがローカルで完結してサーバーを必要としない作りになっています。

Pythonを使うものは、省略します。Pythonのバイトコードを実行するために、ある程度のRAM容量が必要になりますが、BLEを有効にすると必要なRAM容量が確保できないみたいです。BLEを有効にすると実行に必要なRAM容量が取れないため、Pythonのmicro:bit環境では、Nordic Semi.社の独自プロトコルの無線通信は提供されていますが、BLEは使えません。

foreverブロック

アプリケーションはforeverが繰り返し呼び出されます。

foreverブロックは図の通りです。加速度を取得して、しきい値を超えればP0/P1のピンにHIGHを出力にする、また閾値や加速度の値をBLEでスマートホンに伝えるメインルーチンを書いてみました。加速度の大きさを変数”accs”に取得して、それを”plot”ブロックで、micro:bitのLEDアレイに表示させています。文字列は”join”で連結して作っています。最後にBLE UARTで、スマートホンに文字列を伝えます。また、ルーチン呼び出し頻度を確認するために、ルーチン呼び出しごとにmicro:bitのP2をトグルさせます。

この時のP2の波形を示します。

BLEでスマートホンと接続していない時の波形:

BLEでスマートホンと接続した時の波形:

です。

BLEと接続していない時は、foreverが30ミリ秒ごとに呼び出されます。micro:bitはプログラミング教材ですから、ブロック崩しなど、micro:bit背面のLEDアレイとタクトスイッチだけで入出力が完結した、見た目に動作がわかりやすいゲーム作りが、教材として使われます。メインルーチンが30ミリ秒ごとに呼びされるので、スイッチの状態を都度画面に反映する関数をforeverにべた書きするだけで、そのようなゲームが作れます。もしもforeverが、while文で永久ループで繰り返し実行されるものならば、sleep()か何か、適当な遅延時間を自分で入れないと、画面の表示速度が速すぎて、ゲームにならないでしょう。プログラミング教材として、時間を気にしなくても良いように、適当な周期でこのルーチンを呼び出しているのでしょう。

BLEと接続すると、foreverが55ミリ秒ごとに呼び出されています。BLEの接続の有無で、ルーチン呼び出し周期が変わってしまうのは、ちょっと、なにそれ?と思います。下層はmbedなので、mbedのイベント呼び出しの作りを見れば、どうしてこうなるのかがわかると思いますが、例えばforeverのルーチンを呼び出して、30ミリ秒して次の呼び出しでBLE関連の処理を呼び出して、また30ミリ秒後にforeverルーチンを呼び出す作りなら、そうなるかもしれませんが、普通、タイマーイベントに登録して、どのルーチンも30ミリ秒ごとに呼び出すように作る気がしますけど、mbedだし、気にしないことにしましょう。

スマートホンからデバイスへのデータ書き込み

make:codeのブロックは、例えばカンマで文字列を分割するような、文字列を解析する処理ブロックがありません。BLE UARTには、デリミタまで文字列を読みだして、読みだした文字列を返すブロックがあります。

この”bluetooth uart read until”の振る舞いは、BLEで1つのパケットで受信した文字列で、文字列にデリミタが含まれていたら、発見した最後のデリミタの前の文字列を返します。

例えば、read untilで”:”をデリミタに指定したとします。スマートホンから、BLEの1つのパケットで、”123:456:”を送信した場合、このブロックは”123:456”を返します。

シリアル通信だから、BLEのパケットを意識しない、文字列ストリームで、デリミタの検出で文字列を分割して結果を返してくると思い込むと、まず”123”が返ってきて、次の呼び出しで”456”を返すように思いますが、違います。BLEの1回のパケットで書き込まれた文字列で、デリミタが含まれていたら、そのデリミタの前の文字列を返す、という振る舞いをします。

渡したいパラメータが複数種類ある場合は、パラメータのスタートを示すデリミタを送ってから、1つつづパラメータにデリミタをつけてパケットを送ります。図では、念のため、パラメータの種類ごとに違うデリミタを指定して、もしもパケットを読み落としてパラメータの読み出し順番がずれても、誤ってパラメータとして受信処理をしないようにしています。

BLEの書き込みは、write with response、write without responseのいずれでも使えます。ただ、write without responseで書き込むと、パラメータに0が設定されていたりして、詳しく見てないですが、パケットをボロボロ落としているような気がします。

グラフ表示

senstickというBLEセンサーデバイスのiOSアプリを流用して、作ってみました。iPadがあればplaygroundを使えば、簡単にグラフ表示できるのかもしれませんが。

micro:bitは受託開発に使えるのか?

試作のための動作確認をやりとりする場面で、頻繁にファームを変更して動作を確認しなければならいが、相手が遠隔にいるため、相手にファーム更新をしてもらわなければならない場面では、利用できると思います。

USBのマスストレージで、ファーム更新ができることに価値を見出すなら、その書き込み回路だけを使えばよいことです。micro:bitの開発環境を使わねばならない理由はありません。

BLEの接続状態でforeverルーチンの呼び出し周期が異なる、BLEを切断するとファームが固まりリセットしなければならない、ファームウェアを更新するたびにiOSデバイスとのボンディングをやり直さなければならないなど、不要な手間がいっぱいありすぎます。

micro:bitは不用意に他人のmicro:bitにつながらないように、まずボンディングをしてから、BLEが使えるようになる作りになっています。教育教材としては正しいのですが、試作ではとりあえずデバイスに接続したいだけなので、ボンディングが必須なのは、めんどくさいです。

また、BLEの接続や切断でファームが固まる、BLEの接続状態でforeverのルーチン呼び出し周期が変化するなど、変なところがあります。デバッグ手段はUARTでprintfデバッグになり、めんどくさいです。

make:codeの開発環境は素晴らしいのですが、その下層にあるプラットホームが微妙すぎます。

WWDC2017から、次のハードウェアを考えてみる?

WWDC2017から、次のハードウェアを考えてみるというお題で話す機会をもらったので、そこで話した内容をメモ書き的に残してみる。

Apple社のWWDC世界開発者会議も、毎年年を重ねるにつれて、非常にオープンになってきている。そこから、今後のスマートフォンの流れをハードウェアの視点から見てみようと思う。

そもそもだけど、なぜ次を知りたがるのか。それは単に趣味で新しいものが好きだから。根拠の理由説明の必要がなくて身も蓋もないけど。だけど個人の立場からは、新しいものが出てくるって言う瞬間はとても大きなチャンスだから。誰もが同じスタート地点で、早くに学習すればするほど先行者利得でその後の数年間、強い立場あるいは利益を得られる立場になれる。だから新しいハードウェアが登場するのは、非常においしいタイミングでもある。

でも、ハードウェアの新しいものが来るだろうか。多分来ない。新しいものをもたらす新技術や部品の開発は、今のスマートフォン年間2億台を生産するレベルに到達しようとすれば、研究開発に10年、量産までに10年の長い期間がかかると思えばいい。だからiOSとして出てくるハードウェアは、サムスンのGalaxyの1年か2年は遅れたハードウェア要素が採用されたもの、だろう。

スマートホン以外のハードウェアはどうか。ヘッドヘッドマウントディスプレイとか、VRとかいろんなハードが新しく出てきている。それらは、スマートホンでトップシェアが取れないサードの会社が次の可能性を求めて挑戦している分野でもあるけれども、そういった分野にアップルが入ってくるのかどうか。つまり他社にすでにあるようなハードウェアをアップルが扱い始めるかどうか。次のハードウェアは来るのか? という問いかけは、実は、すでに挑戦者たちが挑んでいる新しいハードウェアがいろいろあるけれども、Apple社がそこに参入するだろうか?というのが、本当の問いかけるべきことだろう。

じゃ、新しいハードウェアがもたらすものは何か。新しいものを買って喜ぶ、という理由の説明の要らないものだけじゃない。結局、価値の流通経路の切り替えだということだ。ガラケーの時代からスマートフォンになったときに、その価値の経路が切り替わったために、例えば日本にある企業の中には、1年で売り上げが半分になったところがある。あるいは、ブラウザベースのソーシャルゲームでプラットフォームであった会社が、ネイティブアプリに切り替わった時に、それまでのような強いプラットフォームではいられなくなった瞬間があった。そして、人間との接点はいつもハードウェアだから、ハードウェアが変化したと言うのは、そういった価値の流れの切り替えが1年から2年のうちに起きる可能性がある、そういう意味でとても大きな関心を持つのだろう。

ただ価値を扱うのは人間である限り、20世紀にあったビジネスを21世紀のやり方で焼き直すのが、延々と繰り返されるだけだ。人間は、新しい価値をそんなにすばやく理解しない。人工知能がすごく話題になっているが、それで何ができるのかといえば、できること自体は人間を雇ってできる事と何も変わらない。ただ電力だけで長時間疲れもせずに働くと言う特性を使って、生身の人間では不可能であった何かを素早く事業立ち上げて、価値の経路の切り替えをやってくる人たち、新しいサービスを立ち上げる人たち、そういったのは出てくるだろう。人工知能により、それまでの人間の価値の消費量が2倍になるような、そんな新規性は、まずないだろう。当面は、目の前にある大きさの限られたパイの争奪戦だろう。

今の21世紀のハードウェア価値の切り替えと言う視点で見るときには、常にそこに印刷って言う要素が入ってくる。これはとても面白いことだと思う。20世紀の車の大量製造は、今も日本の大きな経済の原動力になっている。それはプレスあるいは射出という同じものを大量に複製する技術がベースになっている。

例えば高度な半導体と言うのは、これは印刷技術の塊だ。シリコンの半導体の上に複雑な回路パタンを印刷していくそれが今の集積回路クラウドの大量製造印刷の性質を持っている。アカウント思っていれば、そのアカウントの上で購入をすることで、いろんなコンテンツの利用権のアカウントに集約して紐付けられる。愛下名塩にアカウントが中止になる。われわれはリアルな人間だから、道に何も実態持っていない。ネット側の我々の存在に対応する実態はアカウントである。コンテンツはもはやコピーすることなくアカウント

こうして見ていると最初の5時にとってハードウェア新しいもの、に対する興味の価値とは何だろうかちょっと焼き直し必要な感じがする。結局は人が今消費しているのは何かしら形のないコンテンツであるつまりコンテンツが最強な時代なんだ。そういえばiOSの黎明期、開発者たちは今バーチャルリアリティーで新しい可能性に挑戦している人たちがいる。今のバーチャルリアリティーのハードウェアの市場規模は単体でApple Watchているんだけれども、そういったコンテンツに関わるところ2常に立場を変えていくというのはすごく大きな流れだろう。

例えば高度な半導体と言うのは、これは印刷技術の塊だ。シリコンの半導体の上に複雑な回路パターンを印刷していく。それが今の集積回路。また、デジタルデータは容易にコピーできてコストがかからない、まさに印刷の性質を持っている。クラウドであれば、アカウントの上で購入をして、コンテンツの利用権のアカウントに集約して紐付けられる。われわれはリアルな人間だから、ネット側に何も実体がない。ネット側の我々の存在に対応する実体はアカウントである。

こうして見ていると最初の、個人にとってハードウェア新しいもの、に対する興味の価値とは何だろうかちょっと焼き直し必要な感じがする。結局は人が今消費しているのは何かしら形のないコンテンツである。つまりコンテンツが最強な時代なんだ。そういえばiOSの黎明期に活躍した開発者たちの、ある人達は、今バーチャルリアリティーで新しい可能性に挑戦している。今のバーチャルリアリティーのハードウェアの市場規模はApple Watch単体規模と、まだ小さいのだけど、そういったコンテンツに関わるところに常に立場を変えていくというのは、個人ならではの攻め方だろう。

ハードの話をしよう。スプラトゥーン2と言うゲームが発売されたそうで、ソーシャルメディアを見ていると、ゲーム機が購入できないと言うツイートがたくさん並んでいた。

そのツイート見ていてなんとなく伝わってくる雰囲気が、前に新書で出した、ハードウェアはなぜゴミでしかないのか、っていう話とすごく近い感じがした。誰もゲーム機本体を見ていない。ゲームがしたいんだけれども、ゲームをするために本体が必須だから本体が欲しいと言っている。もしもこれが、iPadでゲームができるんだったら、みんなiPadを買ってゲームをダウンロードして遊んでるだろう。ハードウェアで環境が囲われている、しかもそのハードウェアが買うお金があるのに買えないから、みんな不満を表明している。もちろんゲームとして素晴らしく完成されたハードなのだけど、誰もハードを見ていない。

ちょっと、じゃあ昔のハードウェアはどうだったのか、昔を見直してみよう。このトヨタ式生産方式は、カンバン方式の生みの親が書いた本だ。読んでみると結構面白い。これから作れば売れる時代は終わり、低成長な社会が来ると言っている。まぁその低成長と言うのが、今の我々から見れば高度成長経済と呼ぶ時代なんだけど。

だから、これまでの大量生産ではなく、人々の趣味嗜好に合わせた、ものを少数多品種で売れるだけを都度作る、そのためにかんばん方式って言うものを考えたっていうのが。まぁ、その趣味嗜好に合わせた製造社会っていうのが、我々から見た高度成長社会なんだけど。

アメリカから購入した最新鋭のプレス機は、いかに大量に生産するかに特化している。だからカンバン方式には合わない。午前にある機種を製造、午後に違う品種の製造をしようと思えば、その間に金型の組み換えや調整をしないといけない。でも、アメリカから購入した最新鋭機だと、それに1日かかってしまったりする。だからカンバン方式にあうプレス機と言うと素早く違う金型に切り替えられないと。そういった加工装置を得るのに10年ぐらい時間をかけてやってた。

じゃ、iPhoneのハードウェアを見てみよう。この要素を削り落としたらiPhoneではなくなるっていう要素がいっぱいある。

でも面白いのはアップル自体は、電池にしろ液晶にしろ半導体製造にしろ、そういったキーテクノロジーを自社で持たない。カメラモジュールは例外的にソニーから買っているけれども、必ず複数の会社から調達する。量の確保と部品価格を競争での低減を狙ったものだろうけれども、

しかし、LLVMと言うコンパイラ、というかコンパイラ・インフラストラクチャだけど、があるけれどもこういったものは自社で早くから開発している。コンパイラと言うのは、開発言語をプロセッサで実行できる機械語に変換するものだけれども、実はそういった部品というわけではなくて、iOSの開発の全体に影響する大きな存在に今はなっている。

1文字1文字入力するたびにコンパイラが動いて、非常にスマートに次はこういう入力をするのというの提案してくる。それがあるから高度なアプリを短時間で開発できてる。もう人間単体の記憶力で出来るような世界じゃないですから。今のアプリはストア提出がVMのバイトコード、中間コードで提出する。だから今後例えばプロセッサのアーキテクチャが大きく変わって機械語ががまるで別のものになったとしても、アップルが中間言語を新しいターゲットにビルドし直すことで、どんな新しいハードウェアにでもアプリケーション動かすことができる、そういう仕組みに切り替わっている。今のハードウェアの可能性を引き出すかなめとなるものは自社でしっかり開発している。

ハードウェアを製造する部分は自社で持たないけど、集積回路の設計技能と言うのも社内で早くから持っている。ARMと言うプロセッサを独自に設計開発するチームを買収したり、そして今年はGPUも独自設計するんじゃないか、あるいは電力制御を統合してくるのではないかとやっている。今の半導体はとても大きな1つの集積回路に全ての機能を載せることができる。それがより電池を食わなく、高性能なもの作る必然でもあるのだけど。そういったところでも、ハードウェアの部品自体は外部調達だけど、その上に乗せるコンテンツとしての表現能力の要は、自社で抱えていると。

iOSの開発者って今どこにいるんだろう。

例えば今までiOSの新しいものが出るたびに、その機能を紹介した本が必ず出版されていた。今年はちょっと毛色が違う。iOS11の本が、クラウドファウンディングでプロジェクトが立ち上がった。今までは、出版されていたのに、今は最初にクラウドファウンディング。売れ数飲み込みが立たないのか。

今見てみると592人がそれに出資している。アプリ開発者の年収を考えたら本業の開発者が5,000円程度の出費を絞るわけがない。多分この600人と言うのは日本のアプリ開発者の目安、全数の3分の1とか4分の1とかはここにいるなら、日本の開発者数っていうのは1,000人から2000人の間位だろうか。

開発者はどこにいるのか。会社の中に入る。アプリの上で大きなお金が動いているのは、ソーシャルゲームであったり、資本を集めてやるものばかり。アンドロイドのプロジェクトも同じように立ち上がってるが、やっぱり600人には届かない程度。

ARKit

ARKitの機能は、特徴点の検出と3次元空間でのそのマッピング。マッピングした特徴点の集合から平面を推定する機能と、特徴点群と平面とのヒットテスト、そして周囲の照明を推定する機能の3つしかない。YouTubeで検索すると、色んな人のデモンストレーションが結構いい感じで出ている。コンテンツを作るためのキラー機能としてのとしての存在感を感じさせる。

次のハード?

じゃあ次のハードウェアってなんだろう。もうこんな問いかけをするまでもなく、家に常に置いてある端末で激しい競争が起きている。Google、アマゾン、アップル。スピーカを内蔵してネットワークに常につながっている何かと言うのを出している。でも会社によってその性質はまるで違う。Googleは家電を制御できるよと言うのをキラーアプリにしている。アマゾンだと間買い物ができるという機能、いろんなアプリケーションのハブになると言う機能。アップルのは、これからだからわからないけれども、見た目音楽を聞くための機能のスピーカーにしか見えない。Siriと連携したりホームキットと連携するのは当然の機能になるんだろうけど。

VRとか?

もう一つがVR、リアルの世界だけれども、今世界2017年の1Qで世界の販売台数は2,000,000台位。対してApple Watchがそれ単体で3,500,000台。だからとして市場の規模が小さい。

人は、今まで人が見たことがないようなものを、他人の目があるところで身につける事はありえない。だから、これらが普及するとしても常識になるのは10年先だろう。これらが使われるのは、仕事、もしくは家の中。そういった使わざるを得ない状況か、他人の目がない場所でのゲームあるいは会議のツールとか。

コンテンツが最強と言う視点からは当面はゲームが主体、動画を見るのが主体、の中にバーチャルリアリティーをビジネス利用みたいなベンチャー開発が出てくる。

半導体の面積

面白いのはiPhoneの半導体の面積で見ていくと言うことだ。

例えばiPhone 4からiPhone 7までのチップ面積のプロセスを並べてみる。iPhone 7に至るとチップの面積はiMac 27インチMacに搭載されているCore i5のプロセッサの面積より大きい。インテルのはプロセッサしか入ってないけれども、iPhoneのものはプロセッサ以外の全ての機能が1つのチップに集約されているから、面積を見るだけではしょうがないのだけど。

で、パソコンの世界出荷台数2016年が2.7億、アップルの出荷台数が2.2億台位だから、ものすごく荒い言い方をすれば、アップル1社で世界中のパソコンに使われている半導体と同じだけの面積を、iPhoneで使っている。VRにしても、機械学習にしてもそれには莫大な計算能力が必要になる。世界中の計算機と言うリソースをプラットフォームとして、アプリ開発者に提供していると考えれば。またアプリ利用者が増えると、利用者が増えた分だけ自然にスケールする。そのハードウェアは非常に高額だけど、ユーザが自分のお金で購入してくれる。しかもiOSのサポート期間が切れていくから、市場の最低処理能力は自動的に更新される。

とても強いビジネスだと思う。これがGoogleだったらどうだろう。結構クラウドが主体の会社だから、世界中のパソコンに使われてるのと同じ半導体位の面積を、自社のクラウドサービスのデータセンターに使うかもしれない。莫大な投資だ。莫大な投資に見合うサービスでないと、提供できなくなるのかも。人のデータを使うのであればアップルの立場と言うのは強い。ただ利用者全てのデータを集約して初めてできる何かがあるのならば、クラウドファーストって言うやり方を取るしかないから、それはそういうやり方の方が強いのかもしれん。でも2億台からもれなく全てデータを取る必要、母集団からのサンプリング定理を思い出すまでもなく、まずなさそうだけど。

Macで執筆進捗の記録をしてみる。

あまりに執筆が遅いのではと思ったので、遅いと思うか早いと思うかは別として、作業量の記録をしてみようと思いました。
やったことは:

  • 執筆ファイルのバイト量をファイルに1行追記するシェル・スクリプトを作成する。
  • launchctrlで、そのスクリプトを毎日午前4時に動かす。
    です。
    できたデータファイルは、適当な表計算ソフトでグラフ化することにします。

シェルスクリプトの内容は以下のものです。
適当なデータファイル(progress_data.txt)に、日時と、執筆ファイルのバイト数を1行記録していきます。
執筆ファイル名は、”ch”+章番号+拡張子”adoc”としています。

1
2
3
4
5
#!/bin/sh
cd $WORKING_DIRECTORY(ファイルがあるディレクトリ名を設定する)
date '+%F' | tr -d "\n" >> progress_data.txt
echo ' ' | tr -d "\n" >> progress_data.txt
wc ch*adoc | tail -n 1 | tr -s ' ' | cut -d ' ' -f4 >> progress_data.txt

このシェルスクリプトを、”watching_progress.sh”として保存。

1
2
% chmod +x watching_progress.sh , 実行権限を与える
% cp /dev/null progress_data.txt , 空の出力ファイルを用意する

次にこれを毎日午前4時に実行させます。Macではlaunchctrlというコマンドが使えます。

com.reinforce-lab.com.watch-progress.plist という次のような内容のファイルを作ります。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.reinforce-lab.com.watch-progress.plist</string>
<key>Program</key>
<string>/(作業ディレクトリのフルパス、自分の環境に合わせて)/watching_progress.sh</string>
<key>StartCalendarInterval</key>
<array>
<dict>
<key>Minute</key>
<integer>0</integer>
<key>Hour</key>
<integer>4</integer>
</dict>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>

このファイルをロードして、登録できていることを確認します。plistを編集して再読込するときは、unloadしてからloadし直します。
ロード時にシェルスクリプトが動くはずなので、データファイルに出力があるかを確認します。

1
2
3
% launchctl load com.reinforce-lab.com.watch-progress.plist 
% launchctl list | grep com.reinforce-lab.com.watch-progress
% ls -a watching_progress.sh

アンロードするときのコマンド。

1
% launchctl unload com.reinforce-lab.com.watch-progress.plist

再起動したときに、plistが読み込まれるように、”~/Library/LaunchAgents/“で先程のplistファイルが見えるようにシンボリック・リンクを作成します。

1
2
% cd ~/Library/LaunchAgents/
% ln -s $(作業ディレクトリ)/com.reinforce-lab.com.watch-progress.plist ./

グラフ化してみる

CSVデータをグラフ化するのにNumbersの別ファイルを用意した。そこに日々更新されるCSVデータをコピペするのに、apple scriptでこのようにした。
この処理は、csvファイル名は、progress_data.csv。このファイルをnumbersで開くとカラムA:Bにデータがある。それをグラフ化するファイル progress_data.numbersを事前に用意しておく。そのファイルのカラムA:Bにコピーしたデータをペーストして、ファイルを閉じる。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
(*
CSVデータをnumbersのファイルに貼り付けるスクリプト。
2017年4月26日 上原 昭宏
*)

tell application "Numbers"
activate

-- CSVのデータをコピー。
open "Your Working Directory/progress_data.csv"
tell table 1 of sheet 1 of document 1
set selection range to range "a:b"
delay 2.0
tell application "System Events" to keystroke "c" using command down -- copy
end tell
close document 1

-- 対象ファイルにペースト。
open "Your Working Directory/progress_data.numbers"
tell table 1 of sheet 1 of document 1
set selection range to range "a1"
tell application "System Events" to keystroke "v" using command down -- paste
end tell
close document 1 saving yes

end tell

CSVを吐き出したあとに、シェル・スクリプトで、このapple scriptを実行するコマンドを追加。

1
osascript progress_data.scpt

nRF5で使えるリアルタイムオペレティングシステムを見てみる

ポエムです

nRF5で使えるリアルタイムオペレティングシステム(RTOS)を見てみました。RTOSとか、全然知識ないです。なので、ポエムです。

SenStick http://senstick.com を開発していて、イベント駆動の開発をC言語で自分で関数を組み合わせて作るのが辛くなってきたので、今時の開発ライブラリあるいはRTOSを使えば先人の苦労の結晶の恩恵で、楽ができるのかなと思ってRTOSを探してみました。

今時のRTOSは、IPv6なTCP/IPスタックやHTTPSやCoAPなどのプロトコルを提供しているから、RTOSをベースにしておけば、将来的にIP系の技術を使うときに安心だとも思います。こういう、今使わないけど将来使うかもしれないっていうのは、将来もずっと使うことはない定番ですから、多分意味ないですけど。

nRF52対応なRTOS

オープンソースなnRF5対応RTOSをぐぐってみると:

があります。

BLEスタックを独自で持っているか、持たないか

nRF5対応RTOSは、BLEスタックを独自で持っているか、Nordicのソフトデバイスを使っているかの2つに分類できます。

nRF5のソフトデバイスは、ユーザのファームウェアの処理にかかわらず、BLEの通信を扱うために、BLEの通信処理が必ず最優先で実行される作りになっていて、またユーザのアプリケーションが暴走してもBLEのの通信スタックには影響しないよう、割り込みやメモリ領域のアクセスレベルを設定します。

RTOSは、タスクのプリエンプション(実行の横取り)など、割り込みを利用するものは、特権モードが使えること前提のコードもあります。そういった仕組みだと、特権モードはソフトデバイスが持っているので、RTOSをそこに入れることができません。

やるとすれば、BLEスタック自体を独自開発してソフトデバイスの役割を自前で持つか、特権モードを使わないで作るかになります。特権モードがないと、メモリアクセス保護は使えませんが、ソフトウェア割り込みはソフトウェアデバイスがユーザアプリに開放していますから、プリエンプションの実装などはそれらを使えば実装も可能でしょう。

nRF5はBLEのパケットをマイコンで処理するため、マイクロ秒単位の応答速度が必要です。そして、1チップでBLEの通信とユーザのアプリケーションが実行される構成で、スタックがBLEの認証を取るためには、ユーザのコードがどれほど馬鹿なことをしても、BLEの通信に影響しない作りが求められます。また通信スタックが使っているメモリ領域を外部から変更して破壊されないためには、メモリ領域の保護が必要です。

Nordicのソフトデバイスは、nRF5が採用しているCortex-Mの実行モードを利用して実装しています。Nordicのソフトデバイスは、ハンドラモードで実行され、ユーザのファームウェアはスレッドモードで実行されます。ハンドラモードは全ての特権モードへのフルアクセスができ、メモリアクセス権限も設定できます。スレッドモードで実行されるユーザのファームウェアは、許されていない割り込みへのアクセスや、ソフトデバイスが使うメモリ領域へのアクセスなどができないようになっています。 Cortex-Mの動作及び実行モード http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0203hj/Cihhfga3.html

BLEスタックを独自に持つのが、zephyr と mynewt 。それ以外はBLEスタックにソフトデバイスを使います。ですから前者であれば割り込みやメモリ保護など特権モードを活用した実装ができます。後者では特権モードは使えず、スレッドモードの範囲で実装したものになります。

zephyr

インテルが主導してLinuxファウンデーションの活動を通じてコミュニティで作られているRTOSです。ライセンスは、Apache 2.0 license。

ターゲットはIntel Edisonなどがあるので、x86やIntel Curieの中にある独自32ビットプロセッサARC、それにnRF52やTI社のWiFiモジュールCC3200があります。

カーネルの割り込みや特権モードの機能は、それぞれのプロセッサの種類ごとarchごとに、アセンブラコードとC言語のソースファイルがあります。Cortex-MのソースコードはWindRiverの名義になっていますが、WindRiverはIntelに買収されているので、その資産がここにあるのでしょう。

ドキュメントもしっかりしていますし、ソースコードを読んでもきれいなコードだと思います。BLEのスタック部分は、無線通信のハードウェアに直接関わる部分はNordicの中の人が参加してソースコードを書いているようです。L2CAPよりも上のレイヤはインテル名義になっています。nRF52以外でBLEを使えるように、HCIでシリアル通信でコントローラを接続しても使えるようになっています。スタックのQIDは取得しているっぽい?

プロジェクトを見る限り、RTOSを作りました、それ以上でもそれ以下でもないです。Linuxで同じことができるけれども、Linuxが動くメモリも豊富なリッチなものでも、メモリが64kBのものでも、1つのOSのAPIで開発を統合できる、そんな感じに見えます。

Intelは、Intel EdisonやCurieなどを出してIoTの時代に向けた自社半導体製品の販売に力を入れています。IoT系は、Linuxを走らせられないメモリの小さな数多くのデバイスと、それらを統合してイン−ネット側との橋渡しをするLinuxも走らせられるほどリッチなハブデバイスの2つに別れるでしょう。その2つの開発基盤として、これまで買収したRTOSのリソースを公開、また発展させていくコミュニティとして位置づけているのかしら?

でもnRF51のI2Cがサポートされていないっぽい? 移植してBLE通信ができましただけしか確認していないのじゃないかな。

本当にRTOSでしかないので、Intelが組込みやっぱり辞めましたになると、プロジェクトが止まるのかなと思えます。

mynewt

ApacheのインキュベーションにあるRTOSです。nRF51/nRF52/RISC-Vなどをサポートしています。

NimBLEという独自のBLEスタックを持っていて、Nordicのソフトウェアデバイスよりも2倍同時接続数が多いなど、その特性の高さをアピールしています。BLEの規格を決めている中心メンバーのNordicが作っている半導体を使って、そのBLEスタックであるソフトウェアデバイスに対して、何も真正面から喧嘩売るようなアピールしなくてもと思うのですが、そうらしい。

米国の runtime.io という会社が主体になって開発しているようです。デバッグどうするのかな?と思ったら、社内ではEclipseを使ってデバッグしているそうですが、その環境構築手順はまだ解説を書いていない、そのうち書くかもと、メーリングリストで2017年1月にやり取りされていました。めちゃくちゃうちわっぽい。

このプロジェクトの立ち上げのきっかけが、ネットで制御できるIoTな街灯をATMELのマイコンで開発したら、その制御ハードウェアの種類がいくつもできたり、ファームウェアのバージョン管理の手間が爆発したりと、管理面で散々なことになったことらしいです。

ソースコードを見ると、徹底してモジュールにして管理していて、しかもモジュールごとにGitのレポジトリを参照させている。テストコードがけっこう多い。そしてファームウェアの更新にブートローダがあり、署名したファームウェアを受取り更新する。デバイスの管理ツールもある。ネットに繋がったデバイスを管理するところからスタートしたのだろうなと思わせるコードです。

Cortex-Mのスレッド/ハンドラモードは使っていないっぽい。32-bitマイコンで動きますというのは、優先権限がない場合でも移植できるよという意味なのかも。Segger SystemView対応が入っている。開発環境はDockerで提供されている。実機のUSBデバッグは、gdbとかのツールがDockerで動くからVirtualBoxの拡張パックでUSBポートを追加して、仮想化したのがUSBにアクセスできるようにして、という手順。ビルド環境はすぐ手に入るけど、デバッグ環境がめんどくさい。

バイナリのビルドで、ブートローダ、カーネル、それとアプリケーションをそれぞれ分割してバイナリにして配置できる。ブートローダがカーネルもアプリケーションも更新できる仕組み。今時のネットの環境だと、ファーム更新は必ず入れておきたいから、こういうのが根っこで提供されているのは、よいと感じる。自分で作ったら、もしも何かあっても文鎮化しないかのテストって、めちゃくちゃしんどいだろうし。自分のアプリケーションは自分しか使わないから自分が開発する他ないけど、ブートローダみたいなものは、誰かが1回開発したら全員使うものは同じものなのだから、根っこで提供されていればいい。

ARMはソフトバンクグループになりましたが、このプロジェクトはRISC−Vをサポートしているので、そういう面での勢力にもなれるのかしら。

contiki-os

スイス?の大学のセンサネットワークの開発で20年近く使われているみたいです。とにかくメモリを使わない、書き間違いをしにくい平易なコードが書ける工夫がされている感じのコードだなと思います。シンプルですが、見ていると、いい感じです。

特徴的なのは、プロトスレッドという仕組みです。通常のスレッドは実行中のレジスタとメソッド呼び出しのスタックを保持するメモリ領域を確保します。これだとスレッド(あるいは処理単位、タスク)の数だけスタック割り当て(たいてい200バイト程度?)が必要になります。

ContikiOSのプロトスレッドは、そのスレッドの実行場所がどこかを記録する1ワード(実体はポインタです)を保持するだけで、スタックなどは確保しません。すべての実行は1つのスタックで行われます。プロトスレッドは、それぞれのタスクが実行した丁度いい頃合いにリターンして、CPU処理時間を気を利かせて渡し合う、協調的実行をスレッドとしてコードで表現できる仕組みとみると、スッキリします。

組込みでのC言語のソースコードには、データ処理の流れと、時間軸での処理の流れの2つが入ります。例えば、センサーからデータを取得してフラッシュに保存する処理を考えます。処理の流れは、まずI2Cバスに接続したセンサーからデータを取得して、次にSPI接続されたフラッシュに記録する処理です。実際のコードは、これに時間的な処理、例えばI2Cバスからデータを読み出す、プロセッサを待ち状態にするにはもったいない程度に長い時間を別のコンカレントに実行されている処理に渡すとか、が入ります。

データの処理の流れと時間の流れの処理は別の処理ですが、1つのソースコードに入れるために、例えば支時間のかかる処理の終了通知を受け取るために、コールバック関数を使い、そのために処理関数を分割して、さらに関数ポインタを扱う、なんていうややこしいことになります。

プロトスレッドは、そういった時間の流れの処理の記述を、データ処理の流れと統一してシンプルにコードで表現できる、間違いをしにくいコードを書ける、よい仕組みだと思います。

CoAPクライアントのサンプルをnRF52ターゲットにビルドしてみると、text 37kバイト、data 552バイト、bss 15,700バイトでした。nRF52は64kバイトのメモリがあり、ソフトウェアデバイスに13kバイト取られても61kバイトが使えます。通常のスレッドの実装でも十分に足りるメモリ量がありますから、bss16kバイトというのは、特徴的ですが意味はありません。

しかし、NordicのIoTキットはver.0.9でnRF51のサポートを切りました。nRF51はメモリが16kBのものと32kBのものがあります。ソフトウェアデバイスに13kB取られたら、使えるメモリは、それぞれ3kBと19kBです。マウスなどに使うなら16kB版でも足ります。しかしIP層に使うには、32kB版でも19kBでは通常は実装できません。そういう場面で、ContikiOSなら実装できるのは、特徴かもしれません。

ContikiOSのソースコードを見ていると、ファミコンに使われているZ80互換のプロセッサ向けに、通常の意味での、コンテキストスイッチとスタックを実装したスレッドが実装されています。きっと研究を始めた頃は、普通のスレッドで開発していたけれども、研究で超低消費電力にするにはメモリ量が小さいものしか使えないでしょうし、それを打破するためにプロトスレッドを編み出したのかなと、勝手に思いました。

一般的なRTOSとは言えないけれども、プロトスレッドの仕組みは、実行順序を管理するライブラリとして組み込むことも可能です。非常にシンプルで、変わり種だけれども、よくできているなと思います。

FreeRTOS

古くからオープンであるRTOSらしい。GPLライセンスと商用ライセンスのダブルライセンス。今の最新版のver9は全面的にソースコードを書き直したらしい。メソッド名や変数名に、その値型がわかる命名規則を使っているので、ちょっと微妙な名前に見えるけれども、スマートなコード補完機能がないエディタを使っている環境でも安心なのだろうと思う。

FreeRTOSはtickレスモードに対応した。nRF51は、クロックカウンタであるsystick(Cortex-M0+ではsystickはオプション)がないので、このモードがでて初めてnRF51で使えるようになった。nRF52にはsystickがもちろんある。

FreeRTOSをnRF5で使う必要性は、IP層が欲しい時くらい。NordicのSDKにはメールボックスやセマフォそしてスケジューラがライブラリである。だからFreeRTOSをわざわざ使わなくても、協調的な処理でアプリケーションは作れる。ただIP層が欲しい時は、それらがRTOSをベースに作られているから、FreeRTOSを使うことになるだろう。

移植性が得られる(かもしれない)のは、あるかもしれない。他社のBLE半導体で、FreeRTOSベースのSDKを提供しているところへ移植するときに、BLEのAPIは異なるから書き換えが必要だけれども、自分のアプリケーション部分はそのまま使えるだろう。

mbed os

mbedプラットホームはすごいと思うけれども、mbed osは、何をやりたいのかわからない中途半端なものに思える。KeilについてくるARMのRTXというRTOSにC++ラッパを追加して提供している。ソースコードまであるのは、とてもよい。mbed cliが提供されていて、ローカル開発環境が手軽に構築できる。ただし、ローカルではツールチェーンはgccになる。

mbedプラットホームは、オンラインのIDEに純正ARMコンパイラをセットにして提供していて、アカウントを作ってサンプルコードをフォークすれば、できたHEXファイルをUSBストレージに見えるマイコンボードに転送するだけで、コード実行ができる。ユーザのコードはレポジトリで管理されるので、一度mbedプラットホームを使えば、開発環境構築の手間どころが必要性がなくなり、かつコードの開発履歴が自動的に保存される現代的なソフトウェア開発環境に、自動的にとりこまれるのが素晴らしいと思う。

一方で、mbed osは、mbedプラットホームにOSとネット側の監理サーバを加えて、OS側は、超低消費電力に必須なイベント駆動、ネットワークでのデバイス管理の仕組みを備えているものらしい。その意味でmynewtに似ているけれども、その監理のネットワーク・プロトコルはLWM2M、またIoT向け通信プロトコルとして、CoAP, HTTP, MQTT などのサポートが並ぶ。

LWM2Mの仕様は公開されているので見に行くと、めちゃくちゃたくさんの文章があって、私には把握できない。サーバ側のコードは公開していないみたい。

SPIドライバのソースコードをみると、メンバ関数がif defで定義されていた。イベント駆動で動かすマイコンでは、ペリフェラルは指定したメモリ領域にデータを溜め込んでから割り込みをかけてくる程度にはスマートに動くので、非同期処理をよく使う。でも初期化処理の時は、非同期を入れるとコールバック関数+状態変数で管理するバグりやすい手間なコードを書くはめになるから、ブロック呼び出しの関数を使ったりする。

SPIに限らず、ペリフェラルはノンブロッキング(非同期)とブロッキング(同期)を混じって使ったり、あるいはノンブロッキングはハードウェアとしてサポートがなかったりと、いろいろあるから、if defを使いたい気持ちはわかるけれども、C言語ではなくてC++なのだから、アブストラクトクラスで基本関数を定義して、ブロキングなSPIとノンブロッキングなSPIそれぞれ継承してクラス化する方法があったのではとも思う。

とりあえず、C++で if def が使われていて、その理由がよくわからないので、これはかかわらないでおこう、そう思った。あとは、ネットワーク対応というわりに、ファームウェア更新に大事なブートローダの機能が見当たらない。カーネルはカーネルでしかないから、ブートローダは別のコードになるはずに思えるけど、何処か別のところにあるのかもしれないけど。ブートローダを使うためには、カーネルとユーザアプリケーションのバイナリは個別アドレスで配置しないと更新できないと思うけど(カーネルとファームウェアを1つのバイナリにして更新するのもありだけど、その場合はブートローダがカーネルを使えないからネットワーク実装全てもたせることになって、バイナリサイズが大きくなるだろうし)、そういうアドレス分割でのファームウェア生成もあるのかよくわからず。探せばあるのかしら。

あとは、mbedのBLEのライブラリの評判が、まず悪い。APIがよく変わる、動作がおかしいみたいな。NordicのBLEのAPIのラッパーだと思うから、そんな変なものにはならないと思うだけど、まず口々に使えないというから、あまりよくないのだろう(伝聞)。

mbed osには、いろいろ、関わらないでおこうと思った。

まとめ

そんな感じ。