(1)mbedとは

mbedとは

  • プロトタイプ・ツール(試作道具)、開発プラットフォームです。
  • mbed NXP LPC1768の箱には"Rapid Prototyping for Microcontrollers"と記述されています。
  • mbed.orgにも"Development Platform for Devices"と記述されています。
  • mbedはツールであり、道具です。
  • 半田ごて、テスター、オシロスコープ、ブレッドボードと同類です。
  • mbedは新種の道具です。
  • mbedは電子工作の三種の神器に数えられるようになるでしょう。
  • 従来のマイコンを置き換えるものではありません。
  • たとえばmbed NXP LPC1768の価格は約6000円です。
  • PIC12F1822(約100円)、LPC810(約100円)などのマイコンを置き換えるものではありません。
  • mbedにも低価格なSTM32 Nucleo(約1500円)が登場してきましたが、それでも価格が見合いません。
  • 100円のmbedが登場したら、従来のマイコンの置き換えになるかもしれません。
  • 物理的なサイズも小さくする必要があります。小型mbedが登場すると面白いかもしれません。
  • mbedは従来のマイコンの置き換えではなく、新たな道具であるからこそ存在価値があります。

/media/uploads/yasuyuki/tools.jpg

mbedのコンセプト

  • 従来にないコンセプトです。mbedのコンセプトを抑えておくことは重要です。
  • (ただしコンセプトが拡張、変更される可能性があります。)
  • (mbed v3.0ではmbed OSやConnectivityに注目しているようです。)
  • (コンセプトに一貫性があるか、注視していく必要があります。)
  • 実現性を検証するためのデモ・ツールです。
  • 相手を説得するためのプレゼンテーション・ツールともいえます。
  • 一般的にアイデアを製品化する前に、試作をします。
  • 試作もしないでいきなり製品化することはありません。
  • 見通しを立てる必要があります。
  • いきなり製品にしてみたものの失敗だったでは、時間もお金も無駄になります。
  • 本当に実現できるのか、致命的な問題はないのか、上司を説得できるのかなど確認作業が必要です。
  • 試作段階では時間も手間もあまり掛けられません。
  • とにかく、時間も手間もかけずに、実現性をデモンストレーションする必要があります。
  • 実現性がなければ断念しなければなりません。アイデアを選別する必要があります。
  • この段階で、多くのアイデアはボツになります。
  • 電子工作でも製作する前に、ブレッドボードなどを使って試します。
  • このように見通しを立てることが重要です。
  • mbedでは面倒なことを極力排除し、いち早く試作を実現します。
  • 開発環境のインストールや専用プログラム書き込み装置さえも排除しています。
  • mbedを使えば、試作検証が容易です。

/media/uploads/yasuyuki/box.jpg

mbedの利用例

  • mbedを使ってDSPラジオを試作し、最終的にはLPC810を使ってDSPラジオを実現しました。
  • このように、最終的には別のマイコンになるのが一般的です。
  • 現在、どのマイコンもC言語で開発するため、mbedでの試作プログラムを再利用できます。
  • いきなり、LPC810を使って試作することもできますが、それは製品の製作と同じ手間がかかります。
  • mbedであれば、試作は簡単です。

デメリット情報の掲載は批判ではない

  • バグ情報などを掲載するとメーカーから批判や揚げ足取りと受け取られるときがあります。
  • しかしその考えは間違っています。ユーザ目線を欠いています。
  • ユーザの立場にしてみればバグ情報は有益な情報です。
  • オープンソース(ソースを公開)とうたっておきながら、クローズバグ(バグを非公開)では都合が良すぎます。
  • バグがあらかじめわかっていれば、ユーザは回避できます。
  • バグに悩まされることもなく、時間や労力を省略することができ、さらには危険も回避できます。
  • バグ情報を知らないと、危険な使い方をしてしまう可能性もあります。
  • 薬を例にしましょう。
  • 風邪薬には効能もありますが、大小の違いはあれ必ず副作用があります。
  • 副作用=デメリット=薬のバグです。
  • 注意書きに「服用後、乗物又は機械類の運転操作をしないでください」と明記されています。
  • 風邪薬の多くには眠気という副作用があります。
  • この副作用を知らずに、自動車を運転し、居眠り運転で事故死してはなんのための風邪薬かわかりません。
  • 薬の使用者に危険が及びます。
  • 架空の話ではありません。現実に起こります。
  • 副作用があらかじめわかっているなら、危険を回避することができます。
  • そもそも風邪薬を飲まないとか、自動車を運転しないなど回避できます。
  • このようにデメリットである副作用を知っておくことはユーザにとって有益です。
  • ユーザは死なずに済みます。
  • デメリットを知らないと死ぬかもしれません。
  • メーカーも注意喚起義務を怠った罪に問われることもないでしょう。
  • 自動車の欠陥隠しも重大な事故を招く可能性があります。
  • 実際にリコール隠しで死亡事故が発生し、社会問題化しています。
  • このようにデメリット情報の開示はユーザにとってもメーカーにとってもメリットがあります。
  • ユーザ目線を欠いてしまうと、mbedは市場に受け入れてもらえないでしょう。
  • ユーザの信頼を失うでしょう。
  • ユーザの利益を考えるならデメリット情報は重要です。
  • バグ情報が公開されていないと、面倒が増え、mbedの存在価値さえなくなってしまいます。

mbedのデメリット

  • mbedには大きなメリットがありますが、デメリットがないわけではありません。
  • デメリットを知っていれば、回避できるかもしれません。
  • まずは、あまり複雑な処理や高速処理をmbedに期待してはいけません。
  • PCのような処理能力を期待してはいけません。
  • あくまでも実現の可能性を模索するための試作道具です。
  • 細かい部分にこだわらず、割り切って使う必要があります。
  • デバッグ機能もありますが、そもそも試作にデバッグが必要ならmbedの価値はありません。
  • 本来、面倒で時間も労力も必要なデバッグなどしたくありません。
  • そもそもプログラム作業、デバッグ作業は手段であって、試作することが目的です。
  • 目的を達成するために、面倒な手段をとりたくありません。そのためのmbedです。
  • 目的と手段を取り違えてはいけません。
  • mbedの開発はクラウド環境であるため、インターネット接続が必要です。
  • 会社によってはセキュリティ(データの漏洩やウィルス感染)の関係で開発環境のインターネット接続を禁止している場合があります。
  • インターネット接続が禁止されているため、mbed開発そのものができません。
  • mbedのサーバ機器が故障していると開発できません。実際2度、経験しています。今後もないとは言い切れません。
  • 開発したいときに開発できないほどフラストレーションがたまることはありません。感情的にならないように気をつけましょう。
  • プロジェクトの進行に影響が出たり、納期に間に合わないかもしれません。
  • またインターネット回線の故障、メンテナンス時も開発できません。
  • インターネット・プロバイダは年に何度かメンテナンスのために、回線を停止します。
  • 見落としがちですが、mbedの開発環境の提供終了がmbed製品の寿命です。以降開発できません。
  • mbedの提供会社の経営状況などに左右されます。10年後までmbedの開発環境が存在する保証はありません。
  • 手元に開発環境があれば回避できます。
  • このようにクラウド環境であるがゆえのデメリットもあります。
  • 自己都合ではなく相手都合であるため、対処方法は限られています。心構えをしておきましょう。
  • コンパイラ、ライブラリにはバグもあります。
  • 実際、未知のバグに引っかかり、思い通りに試作が進まないことがありました。
  • バグの再現方法を提示し、直してもらうまでに数日かかりました。
  • 未知のバグに遭遇するとこうした手間がかかります。mbedのメリットを生かすことができません。
  • 既存のバグであるなら回避できますが、未知のバグには悩まされます。
  • mbedの情報は基本英語のため、英語力が必要です。バグ情報などの出所はすべて英語です。
  • mbedにはデメリットもありますが、それを考慮してもメリットが上回ります。
  • mbedを上手に利用しましょう。

利用は簡単

  • mbedを利用して、試作をする立場からすると、これほど簡単な開発方法はないでしょう。
  • ふとアイデアを思いついてから、すぐに実験できます。
  • 電子工作の道具として手放せないものになるでしょう。
  • 最小限のハードウェア知識、ソフトウェア知識さえあればすぐに利用することができます。
  • 高性能を求めたり、使用したいデバイスのライブラリがないなど細かいこだわりを捨てます。
  • とりあえずあるもので代用します。

提供は大変

  • 一方で、デバイス(IC)を利用してもらうためのmbedライブラリ開発は非常に大変です。
  • たとえば、XBeeやSi4735のmbedライブラリ開発は大変です。
  • C++のクラスの考え方(オブジェクト指向)を理解しておく必要があり、ソフトウェアの上級開発能力が必要です。
  • さらにデバイスのデータシートを理解し、ライブラリに落とし込んでいく作業が必要になります。
  • ライブラリの利便性は開発者の技量、センスに左右されます。
  • ハードウェアにもソフトウェアにも精通している必要があります。


Please log in to post comments.