2016年8月28日日曜日

CQ出版Interface2016年10月号の第七章にMicroPythonに関する記事を書きました

CQ出版Interface2016年10月号の第七章にMicroPythonに関する記事を書きました。

今回の記事は「とにかくソースコードと格闘してMicroPythonの世界を体験しようよ!」という内容になっています。成長中のオープンソースでこのような記事を書くと本当に生ものになってしまい、数か月後には「記事の内容と全然違う!」なんて事も多々あるので迷いましたが、「こーんな風に見ていけば良いんだよ」という雰囲気が少しでも伝わればという考えでしたためました。


ちなみに、記事のタイトルは「MicroPythonプログラミング」となっていますが、MicroPythonの中身を知るための入り口として、既存のモジュールに機能を追加する体験記事になっています。「なーんだ、ポーティングじゃないんだ」とか「プログラミングじゃないじゃん」と思われるかもしれませんが、騙されたつもりで一度体験してみて下さい。このちょっとした機能追加を体験する事が、意外にも内部構造の理解や機能拡張、更には別のプラットフォームへの展開の大きなヒントになります。


記事の中で使用したボードはNUCLEO-F401REです。
秋月電子通商さんスイッチサイエンスさんから購入できます。


ダウンロードコーナーのファイル(2016年 10月号 データ解析時代の新定番 Python)には執筆段階で使用したコードと環境構築用スクリプト(Ubuntu 16.04用)も含まれますので御利用下さい。

2016年7月31日日曜日

技術開発と製品開発とビジネス開発は全く別物だけど混同されていることが多いという話

あらまし

お仕事で様々な立場の方とお話しする機会があるわけですが、以前からどの階層にいる人にも共通した「技術開発と製品開発とビジネス開発が同時に出来るのではないかという思い込み」を持っている方が非常に多い事に気付きました。


よくある混同で起きるマズい事

例えば、おぼろげながら自分達で考えている製品像が浮かんだとしましょう。この製品像は、それこそ具体的になっているものではありませんが、必要な機能や性能やインターフェースが何となく整理できた状態になっていたとします。そこで必要になる機能を実現するための技術的な要素は、少し頑張れば実現できそうな事ばかりで、さっそく製品開発をスタートする事にしてしまいます。

このシチュエーションで起きるのは以下です。

  1. 製品の機能を仕様にまとめる
  2. 仕様が好ましいものと判断され/判断し、計画をスタートさせる
  3. 仕様を満たす機能を実現できるように設計を開始する
  4. 設計が完了したので実装を始める(ハードウェア、ファームウェア、ソフトウェアは問わない)
  5. 実装が完了したので製造する(ハードウェア、ファームウェア、ソフトウェアは問わない)
  6. 製造が完了したので評価する
  7. (以降、付随したプロセスに続く・・・)
何もマズい事が起きていないようにも見えます。が、実際に技術開発と製品開発とビジネス開発を混同している人達に起きる悲劇の一例を挙げます。
  • 出来ると思っていた技術的な要素に意外な課題があった
  • 技術的な要素に絡む問題のために実現すべき仕様の一部が実現出来なくなった
  • 仕様の一部が無くなったが、市場に出したい時期を明らかにしているので出す事にした
  • 実現できなかったのはエンジニアリング能力の低さだと誰もが落胆し真因にたどり着かない
混同によって、どれもこれもが全て中途半端になってしまうのが最大の欠点です。こういった結末に至るプロジェクトは無数にあり、共通に存在するのが技術開発、製品開発、ビジネス開発を混同してしまっている事にあります。

技術開発


当たり前の話ですが、製品を実現するために必要な技術要素について、事前に課題や実現性を吟味しておく必要があります。そうでなければ製品の実現性すら不明のままで製品開発をスタートさせる事になっていまいます。このような組織にいたっては、製品開発を行う時点でビジネスまで混同して考えてしまっているので、全部が不透明感で一杯になる事になります。

技術開発は、製品開発とは性格の異なるもので、将来何に役立つのかわからないが、魅力的な物事について事前に研究開発しておくものです。大抵の場合、これらは現場の技術者の個人的な興味に由来していたり、過去に失敗した製品の残骸からゾンビのように生き返って組織に残っているようなものだったりします。

そして、非常に重要な点ですが、これらは一般に組織的に必要性を認められることは少なく、たいていの場合アンダーグラウンドで活動する事すら認められないようなものだったりします。(そんな事をやっている暇があるのなら、別の事をやれというやつです。)

もちろん、ニーズを的確に察知して必要になりそうな技術要素について研究開発する事も多いのですが、実際にそれらはビジネスへの発展を事前に考慮しているので、思わぬ発展に至るケースは少ないように思います。

いずれにせよ、重要な点はその時点で何の役に立つのかわからない、けれども興味のある物事を実現できるようにしておくというのが技術開発です。


製品開発

製品開発は、商品やサービスを実際に市場に出すために行う活動で、通常はビジネス開発との関係も持ちながら行われます。売れないものを作っても何もならないので、売れる前提でモノを作る事になります。つまり、実現性が非常に重要な点で、この時に初めて技術開発の成果物が価値を持ってきます。

製品開発の段階では、明らかになった技術要素を用いる事ができるようになっていると失敗のリスクを低減できます。

最近は様々な物事が安易に進む傾向があるようで、お金を積めば実現できると思っている方も多いのですが、実際に製品開発をするならば事前に積み重ねられた技術開発が伴っていなければなりません。そうでなければ博打にもなりかねません。動くと思うけどどうかなー。なんて嫌ですよね。

ビジネス開発

ビジネス開発では製品やサービスだけでなく、市場の動向や人々の趣味嗜好、その他さまざまな要素を踏まえて見えるものや見えないものまで作っていきます。

重要な点ですが、技術開発はそれ自身が当初品質が低く、実現形態も最終品ではないので曖昧で、結果的にビジネス開発側では具体的な製品のイメージを持ちにくい性質のものです。ビジネス開発側に自分が位置している場合には、目の前で実現できているモノが、技術開発の成果物なのか、製品開発の成果物なのか、十分に理解した上でモノを見なければなりません。その点を見誤ると、将来の大事な要素を自ら見捨ててしまう結果になってしまいます。

まとめじゃないまとめ

沢山の失敗するプロジェクトと少しの成功するプロジェクトを眺めていると、ある一定の共通項が見えてきました。その結論の一つが上記の、技術開発と製品開発とビジネス開発を混同しない事。です。

技術開発と製品開発を混同している組織は、製品開発で必ず失敗しています。そして、その失敗の原因を現場の担当に押し付けてしまいます。しかし、実際に組織で起きているのは、単に十把一絡げに物事を混同してしまう思想の雑さ加減にあるのです。もちろん、製品開発とビジネス開発も同様で、開発担当現場に一緒にビジネスまで開発させようとする組織すら存在しますが、エンジニアはスーパーマンではないので、小さなビジネスでまとめるなら別ですが、通常はうまくいかないでしょう。

モノを作るのが大好きな日本人ですが、世界中で見ると創造性や生産性は高くないのが現状です。そして、うまくいかなくても分析すらままなりません。結局は「社員の能力」などと言い放つ方すらいるのですが、それでは問題が解決しないようなぁと考える今日この頃なのです。

2016年6月29日水曜日

ドキュメント生成にSphinxを用いる

色々と思う事があって、最近はドキュメントをきちんと書こうという気持ちになっているのですが、最初に書き始めるまでに膨大な時間がかかってしまいます。ソースコードを書き始めるのは心理的な抵抗が無いのにも関わらず、ドキュメントを書き始めるのに時間がかかってしまうのは何故なんでしょうか?

そんな事を考えていてウェブを調べてみると、ちょっと良さそうなドキュメント生成ツールを見つけました。なんだか有名なツールのようですが、私が知ったのはつい最近。


何やら独自のマークアップ言語で記述すればhtmlやlatexやepubやなんだかんだに変換が出来るという・・・一見するとよく見る類のものに見えます。そして、いつものように試してガッカリするんだろうなと期待せずにチュートリアル的な内容をこなしてビックリ。なかなか綺麗な出力が得られることがわかりました。

例えば、sphinx-quickstartで作ったプロジェクトのファイルに日本語を入力してUTF-8で保存し、make latexpdfjaした時の出力が以下。


もちろんSphinx自体のサイトもSphinxで作られていて、これがなかなか綺麗な仕上がりです。
http://www.sphinx-doc.org/en/stable/contents.html

ソースコードの類を書く人にとって、WordのようなWYSIWYGはやはり辛いんでしょうか。よく考えてみるとソースコードの整形だってエディタやツールにやらせています。よほどの事情(とにかく気分転換したいので単純作業とかしたい・・・とか?)が無い限り、手で一文字一文字整形する人は稀でしょう。このノリで考えると、文章を整形しながら書くというのは、ソースコードを書く人の感覚と少し異なるのかもしれません。「整形は後で」って思っていても、そもそもソースコードを書く人は綺麗好きな人が多いので、やっぱり整形作業も始めちゃうというジレンマがあるのかも。

という事で、ひとまず道具を開拓してみただけなのですが、実際に説明不足のプロジェクトが山のようにあるので、何かのプロジェクトで使ってみたいと(今は)考えています。

2016年5月31日火曜日

NT-Monitorの外部オブジェクト参照にバグがあるんじゃないかという話

NT-Monitorとは、CQ出版社が出版しているInterface2013年1月号に掲載されたマイコン用のモニタプログラムです。シェルの部分はNT-Shellを用い、その上にモニタプログラムとしてNT-Monitorが乗る形を想定しました。記事掲載時点ではFM3マイコンに対するモニタプログラムとして構成し、その時点ではコールバックに渡される外部オブジェクト参照を使用しない実装になっていました。

2013年から約三年後の2016年現在、そういえば久しぶりに懐かしいコードを引っ張り出してみようと見てみたところ、限りなく怪しい香りのする実装が幾つも見られます。そのひとつがタイプセーフではない外部オブジェクト参照の実装。ちょっと載せてみたいシステムがあったので使ってみたところ、インターフェースに渡したはずのオブジェクトへのポインタが、異なるアドレスを指す何かに代わってコールバックされます。「あー、何だこりゃ」というのが事の始まり。


NT-Monitorは、元々単一スレッド上で永久に動作し続けるものであるとの前提で設計しました。唯一のAPIは上記に示すntm_executeで、シェルオブジェクトとシリアルI/O関数へのポインタを渡すと後は勝手にシェルを駆動しながら処理してくれるというものです。

システム内部に複数のシリアルインターフェースが存在し、かつそれらを別々のモニタープログラムが使用する事も念頭に入れ、UARTなどのインターフェースに対するハンドラへのポインタなどを格納できるようにしたのがextobjです。

が、ここにどうしようもない情けないバグがあるんじゃないかとコードを眺めていて気付きました。

まず、NT-Monitorの最上位階層であるntmモジュールを見たユーザは、当然のように自分がextobjへ渡したオブジェクトへのポインタが、そのままserial_readやserial_writeへ渡されることを期待します。そうでなければ、それが一体なんであるのか上記のAPIから知る由もありません。

しかし、実際にNT-Monitorの実装を見るとのっけから次のようなコードが見えます。何やら突然現れたntmcmd_extobj_tにserial_readとserial_writeを格納し、更にはユーザが上位のAPIで与えたextobjをuser_extobjとして保存しています。そして、この準備の終わった新しい外部参照用オブジェクトへのポインタをシェルモジュールであるntmshellに渡しています。


このままセオリー通りに事が進むと、ntmshellから呼び出されるserial_readとserial_writeは、最上位でユーザーが渡したextobjとは異なるものになってしまいそうな気もします。確認してみると・・・


ntmshell_executeで呼び出されるp->func_writeは、最上位で言うところのserial_writeです。そして、そのシリアル出力関数に渡される外部参照オブジェクトへのポインタはp->extobjを示しており、これは先ほどの確認にあったようにNT-Monitorの内部で定義されたntmcmd_extobj_tである事がわかります。ということで、のっけからユーザーが渡したものと違うアドレスがコールバック関数に渡ってしまう事になります。あらら。

一方で更に物事を無駄に複雑にしているのが以下の記述です。



なんと、シリアル書き込み関数に対してマクロが用意されており、そのマクロを使用した箇所に関しては、user_extobjが渡るようになっています。どうしてここは正しいんだ。と過去の自分に言いたい。

つまり、同じシリアル通信関数でも、呼び出される個所によって期待するアドレスが渡ったり、はたまた間違ったアドレスが渡ったりします。

実はこの話、凡ミスのようにも見えますが、問題の根本には全体設計のまずさがあります。そもそも、シェルインターフェースを提供するNT-Shellと、モニタ機能を提供するNT-Monitorのシステム境界が曖昧です。本来であればシェルの機能とモニタの機能は完全に分離できるはずですが、あまり綺麗に分離できているとは言い難く、結果的にこれらの二層に渡るオブジェクトの取り違えにまで発展してしまっています。

冒頭「シェルの部分はNT-Shellを用い、その上にモニタプログラムとしてNT-Monitorが乗る形を想定しました。」と書いている事からもわかるように、本来の依存関係はNT-MonitorからNT-Shellへの使用依存ですが、実装を見ると内包になっています。これも気持ちが悪い。

ということで、NT-ShellもNT-MonitorもそろそろAPIの見直しなども含めて考えたくなってきました。

2016年4月30日土曜日

Natural Tiny Shell (NT-Shell)の新しいリリースパッケージVersion 0.3.1を発行しました。

Natural Tiny Shell (NT-Shell)の新しいリリース・パッケージVersion 0.3.1を発行しました。
http://cubeatsystems.com/ntshell/ のダウンロード・ページからダウンロードできます。


ET展のTOPPERSブースでプレゼンテーションをさせて頂いた時の資料に書かせて頂いた「ユーザーコマンド」なるものを実現する例として、NXP LPC824を題材にしたサンプル・プロジェクトを追加してあります。
https://www.toppers.jp/docs/contest/presen2011_NaturalTinyShellTask.pdf#search='toppers+ntshell'

今回のパッケージ・アップデートはざわさんのコメントを発端にしています。ざわさん、貴重なフィードバックをありがとうございます。

2016年3月31日木曜日

組込み機器の制御にStandard Commands for Programmable Instruments(SCPI)を用いる事を考える

あらまし

組込み機器を設計すると、小さな規模の装置でも数十から数百を超える操作が簡単に生まれてしまいます。設計実装した機器が確かに意図したとおりに機能しているのかを確認しようと考えた場合、それら全ての操作に対して考え得る全ての組み合わせで実行しない限り、予期しない動作が生まれない保証はありません。特に機器側に何らかの状態を持つような設計が含まれる場合、人間が操作したのでは到底網羅出来ない数の組み合わせが存在する事になります。


さて、エンジニアとしては自分の設計と実装が期待通りの動作をしているのか確認してから枕を高くして眠りたいところですが、その操作インターフェースが独自コマンド体系になっていると色々な弊害が出てきます。例えば、「そもそも操作を自動化できるコマンド体系になっていない」、「独自の概念に基づく操作が並べられており第三者の理解が難しい」、「機器側の状態にコマンドの実行結果が依存しすぎる」など。ついつい作ってしまう独自コマンド体系によって自動化が困難な状況も自ら作り出してしまう事になります。おろろ・・・これでは枕を高くして眠れない・・・。

ということで、「何か代替案はないかなぁ」と調べ始めたのが今日のお話。

Standard Commands for Programmable Instruments(SCPI)

Standard Commands for Programmable Instruments(SCPI)とは、プログラマブルな計測器をコマンドで操作するために作られた規格です。独自の操作体系で作られた数多くの機器を制御するのが難しかった背景から策定されたもので
  1. 同種の二つの計測器が存在した場合、同一の制御方法を持つ(垂直互換性)
  2. 二つの測定器では計測手法が何であるのかに依らず同じ計測が可能である(水平互換性)
  3. 同じ機能を持つ二つの計測器では同じコマンドで操作できる(機能互換性)
という3つのコンセプトがベースになっています。


実際に規格に書かれたプログラマブル計測器のモデルを見ると計測器のみならず、様々な組込み機器でも再利用可能に思えてきました。上記のモデルで言うと、Measurement Functionは入力系統、メモリは文字通り、Signal Generationは出力系統です。要するに入力された信号がメモリに入り、計算されて出力されるというコンピュータシステムそのものなのです。

例えば、オーディオを処理するような装置を仮に作った場合、上記モデルで言うところの上段は入力(録音)系統、下段は出力(再生)系統になるわけです。実際、規格文書の例は車台ダイナモメータのモデルが示されたおり、ちょっとやってみたくなる素材としても面白い内容になっています。どのような装置であっても、広義の意味で測定器と言えるのでその応用の範囲は広そうです。


という事で、何か作ってみたくなる素材のお話しでした。

2016年2月8日月曜日

KiCadのコンポーネントエディタにまつわるティップス

先日からKiCad (Version: 4.0.1-stable release build)への移行を始めました。
EAGLEからKiCadへ移行する方への参考になればと、「おぉ!これは!」と思ったポイントをまとめてみましたので御紹介します。

コンポーネントに対するドキュメント

私の場合、後から設計情報を見た時に何を根拠に設計したのか明らかにする意味で、採用した部品のデータシートを必ずリポジトリに入れることにしています。

KiCadでは、コンポーネントエディタで「ドキュメントファイル名」を指定しておく事で、回路図から直接ドキュメントを開く事ができるようになります。


部品点数が多くなってくると、ドキュメントを開くのも億劫になってしまいますので、この手のちょっと便利な機能は、膨大な時間を節約する事に繋がります。これは便利。

残念な外観のコンポーネント

コンポーネントを作り始めてから数日後、何か違和感あるよなぁと思いました。

最初、それが何かわからなかったのですが、よくよく他人の回路図と比べるとコンポーネントの外観がとても残念です。

調べてみると、コンポーネントの枠に対して背景色で塗りつぶすという選択がある事に気づきました。回路図上でコンポーネントが格段に見やすくなりますのでお勧め。




3Dシェイプのデータパス

これはどちらかというと「どうやってやるんだ?」な話。

コンポーネントに対して3Dモデルを割り当てられるのですが、どうしても固有環境のパスが入ってしまいます。これでは、他の環境でチェックアウトして作業・・・なんて芸当が出来ません。

実際には、ダイアログが自動的に挿入するパスから手動でKiCadが内部で持つ環境変数名を入れてやれば良い事がわかりました。



コンポーネントに対する説明

KiCadでは、コンポーネントに対する説明を加えておく事で、部品選択ダイアログで絞り込み検索が可能です。既存ライブラリなどの説明を見ていると、「あぁ、これだと検索にかからないよなぁ。」なんて書き方があります。自前のライブラリを作る場合、データシートに書かれたDescriptionからテキストをコピーするのがお勧めです。



コンポーネントのピン編集作業

コンポーネントエディタでピンを追加する場合、ピンを置きたい位置にマウスをクリックし、出現したダイアログに情報を入力・・・というのが通常のやり方です。が、そんな事を何度も繰り返していると、さすがに「これは不便なんじゃないか?」と疑問を感じ始めます。

KiCadの場合、キーボードの操作だけでピンを追加できるように操作系が工夫されています。



KiCadティップスコーナー

Twitter上で「今朝のKiCadティップスコーナー」を更新中ですのであわせて御覧下さい。