CuBeatSystems

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の見直しなども含めて考えたくなってきました。

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


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

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

あらまし

Standard Commands for Programmable Instruments(SCPI)

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

KiCadティップスコーナー

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

ちょっと思い立ってKiCadを使い始める事にしました。


もうだいぶ長い間EAGLEを使っていたので、乗り換えるにあたってツールが前提としているワークフローの違いについても見ておかなければなりません。KiCadのウェブページを見るとGetting Startedのページに御丁寧に説明が書いてありましたの紹介します。


EAGLEの場合、ライブラリファイルの中にシンボルとフットプリントが一緒に管理されていました。
世界中で広く使われている一般的な電気系CADの場合、シンボルとフットプリントが一緒に管理される事は滅多になく、通常は別々の管理になっています。EAGLEに慣れた人がKiCadだけを見ると特異なものに見えてしまうかもしれませんが、実際にはEAGLEの方が特別なケースと言えるでしょう。


ということで、チマチマとワークフローを辿って操作を学習していく事にします。
何か実際に設計するための題材が欲しいなぁ、何にしようかなぁ。

CQ出版社Interface 2015年11月号「レベルアップ！フリーのCプログラミング道具箱」の第2章「シンプル・便利・基本的！フリー・ソフトで高品質プログラミング」にも関連する内容で、「製品開発におけるソフトウェアの品質保証」と題して、酔漢さんの主催するワークショップでプレゼンテーションを実施させて頂きました。


近年、幾つかのプロジェクトを見ていて感じている事ですが、製品品質を確保する上で本質的に欠かせない内容に触れる事なく、何か別の（形式上の）作業に振り回されているうちに、肝心の品質保証が不十分になってしまうケースがあるようです。今回のプレゼンテーションでは、現代的な製品に欠かす事のできないソフトウェアの品質保証について、実際に現場で起きた事をざっくりデフォルメして説明させて頂きました。


先日のInterfaceの記事でも少し触れましたが、設計がどうして必要なのか、実装は何に対するものなのか、実装の正しさは何によって証明すべきものなのか、など、これらの関係について明確な思想を持っておく事が非常に重要です。


しかし、実際に現場で色々な作業成果物を見てみると、何とも残念な結果になっている事が少なくありません。それらがどのような背景で起きるのかについて触れるとともに、どのようなアプローチが実際に現場で有効であるのかについて、ヒントを示すような内容としました。

例えば、製品の見た目や大きさで設計対象物の大きさを判断しない事、など、少し考えてみれば当たり前の事ですが、混乱が繰り返し起こるような現場では有用な示唆になると思います。この「物事は見た目ほど単純ではない」というのは、色々な場面で使えます。


資料は、後日酔漢さんのウェブページで公開予定ですのでお楽しみに。
https://signalbottom.wordpress.com/

2015年12月16日追記：(リンク)
https://signalbottom.wordpress.com/2015/12/13/2015%E5%B9%B411%E6%9C%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%83%E3%83%97%E3%81%BE%E3%81%A8%E3%82%81/ に公開頂きました。

2015年12月29日追記：(要約)
製品の品質を担保するための活動は、その製品の企画構想、仕様、設計、実装、内部検証、外部検証、文章化、クロージングなど、製品開発の全てのフェーズに渡るのが通例である。しかしながら、実際の開発現場では、各フェーズの関連性を見い出せず、結果的に品質保証の視点が完成したシステムに対する外から見た挙動を評価する事に終始するようなケースもみられる。このような背景を踏まえた上で、本発表ではシステムの内部品質にフォーカスし、特定の指標を用いた設計や実装の品質保証について概略を述べる。

スイッチサイエンスさんで人気沸騰中のちょっとすごいロガー(NinjaScan-Light) スイッチサイエンス版を購入しました。基板好きにはこの凝縮感がたまりません。

早速ですが、気軽に外に持ち出せるようにと何らかのケースに入れる事にしました。部屋の中を見回して色々な小物ケースを探したのですが、しっくりはまったのはフリスクのケース。


ただ、ケースの中で基板がガタガタ動いてしまってはセンサの値に影響を与えます。かといって、両面テープでがっちり固定する気にもなれなかったので、今回はスコッチが出しているジェル状の接着物を使用する事にしました。

残念ながら耐熱温度仕様などは書かれていません。もしかしたら後でまずいことになるかもしれませんので、同じようにやってみようという方は自己責任でお願いします。


当初はu-bloxのモジュールが上を向く形で実装するつもりでしたが、この面を接着面として使った方が具合が良いと判断。u-bloxのモジュールに接着物を貼り付けてフリスクケースに固定します。


これでばっちりケースに入りました。CON1がケースの蓋に当たるので、蓋の肉厚を調整して対処します。


USBのコネクタを外に出すために穴もあけておいて下さい。
私の場合・・・もっと綺麗にやり直したい。バリとか取っておかないと後で色々困ります・・・俺。