思考のサルベージ(その５)
各工程で心がけたい思想を掘り起こしてみる
「ハードウェアインターフェースの確認」を取り上げましょう。 組み込み開発では、ハードウェアもオリジナルというのが普通ですね。ソフトウェア開発側の視点でハードウェア機能の確認について考えてみます。
どんな機能が欲しいですか
開発のかなり早い段階で、ソフトウェアチームからハードウェアチームにどんな機能が欲しいか、どのように使いたいかを整理して伝える必要があります。まだ機能設計もできない状態でソフトと相性のいいハードウェアインターフェースを考えなければいけません。システム全体で「必要かもしれない」と思う機能については、遠慮なく要求しましょう。満額OKとならないかもしれませんが、要求を出さなければ、要不要の議論もできません。 ここで徹底的に議論しておかないと、こんな機能があればよかった、この機能はいらなかったと後で後悔することになります。
インターフェースの確定
ハードウェアのインターフェースが確定したら、念入りに確認しましょう。
- 実装合意した機能が記載されているか
- 使い勝手のよいインターフェースになているか
ソフトウェアと違い、ハードウェアは後工程での改修はできなくなります。問題点に気が付いたら早めに声をあげましょう。各種制約についてもしっかり確認しておきましょう。ハードウェアの制約でよくあるのは - 同時起動の制約 - レジスタ参照タイミングの制約 とかですかね。制約違反をしてしまうと、ハードを動かせなかったり、想定外の値をレジスタから読み込めなかったり、システムが正常に動作しなくなります。
逐次確認
設計工程、実装工程ではインターフェースを逐次確認しながら進めましょう。レビューの場で突き合わせをして、インターフェース違反、制約違反を発見し、バグを早期段階でつぶしておきましょう。テスト工程でハードウェアの絡んだ不具合を踏むとかなり厄介です。
何か掘り起こせた？
- 初期段階で徹底的に議論する
- ハードチーム、ソフトチーム間で常に情報交換できる環境を作る。
おしまい
組み込み開発は、ハード開発、ソフト開発の共同作業です。両者の関係が風通しの良いものになっているとやりやすいです。そのうえで、互いの主張を建設的に議論できると、より良いものができるんでしょうね。
オープンソースの勉強会＆イベントに参加してみよう！
突如現れたハッシュタグ #KOF2019 って一体何！？？
先週末、Twitterを何気なく覗いていると、突如『#KOF2019』などという謎のハッシュタグを見かけた方がいらっしゃるのではないでしょうか？
はて、格闘ゲームのイベント！？？ ……などと思われる方が圧倒的多数ではないかと思いますが、実はこれ、毎年大阪で開かれているIT系イベント 『関西オープンフォーラム』 の略称だったりします。特に某格闘ゲームの大会が開かれていたわけではないってことですね……
今年の関西オープンフォーラムの写真は迂闊にも撮り忘れてしまいましたが（実行委員の皆さんごめんなさい）、関西オープンフォーラムに限らず、IT系のイベントや勉強会は日本各地で頻繁に開催されています。
上の写真は、オープンソースカンファレンス浜松行われていたデモの写真です。
雑誌で見かけたことがある方はいらっしゃると思いますが、きゅうりの選別をTensorFlowを使って行うというものですね。こんな展示を生で見れたり、その開発者と生で話ができたりと、IT系イベントに参加すると新しい発見が見つかることも多いと思います。
今回はそんなオープンソースのイベントや勉強会についてご紹介します。
続きを読む信号処理とMIPS
MIPS 【 Million Instructions Per Second 】 とは
信号処理や組み込みの分野では、アルゴリズムを提供するソフトウェア（ファームウェア）が、どれくらいの処理量（演算量）が必要なのか問われます。例えば、信号処理の性能を示すものには、処理された結果の品質があると思います。良い品質が提供できるとした時、もう一つ重要な指標に演算量があります。高品質な結果を提供するソフトウェアでも、スーパーコンピューターが必要では非現実的になってしまいます。
信号処理のソフトウェアの演算量を示す指標として、MIPSが良く使われています。
MIPS
コンピューターの処理能力を表す単位。コンピューターが1秒間に何百万回命令を実行できるかを示す。
MIPSとは、このように説明されていることが多いです。確かにこの通りなのですが、ハードウェアの性能を示すものとして説明されている場合がほとんどです。
分かりやすいところでは、CPUのデータシートに、動作クロック100MHz, 100MIPS などと書かれていた場合は、CPUの処理性能を示しています。
| 動作クロック100MHzで100MIPSとは | １サイクルで１命令実行できる |
|---|---|
| 100,000,000命令 / 100,000,000Hz = １命令 | 100MHz × 1命令 = 100MIPS |
思考のサルベージ(その４)
各工程で心がけたい思想を掘り起こしてみる
「問題解析、山積み編」です。不具合解析が1件また1件と、どんどん溜まっていくと焦りますね。たいがいそんなときは、ミスをしがちです、私は。
優先順位
システムテストチームから解析依頼がまとめて4件。焦るなと心を落ち着かせて、まずは、対応する優先順位を決めます。順位付けの判断基準としては
- その不具合で、他のテスト項目が多数消化できない。(これは、テストチームが速く解決しろと言ってきますね)
- 正常系ど真ん中。
- 準正常系や異常系
とかですね。「こないだ直したはず？？」なんてのも結構ハイプライオリティです。
ひとつづつ、確実に
優先順位に従って、ひとつづつ解析しましょう。自分の力と、自分に足りない部分は他の人の協力を総動員です。何件溜まっていても、1件ごとにやるべきことは何も変わりません。
すべて解決
私が実際にしでかしたことは、(はい、1度や2度ではありません)1件目、2件目はポンポンと解決して、3件目にやや時間がかかり、4件目を見ると、、、。なんだ、担当外のモジュールがエラー返しているからうまく動いてないんだ。と判断し、そのモジュールの担当に解析作業を振って、すべて解決。その結果。
いつの間にか「解決したい」が「終わらせたい」に
しばらくすると、解析依頼を振ったモジュール担当から、「そっちのモジュールからの入力値に従って処理した結果のエラーです。で、細かく調べてみたらてみたら、云々・・・・。」親切丁寧に説明をいただき、ようやくこちらの問題と気づきました。反省しきりです。やはり、焦っていたようです。「解決したい」という心構えが、いつの間にか「終わらせたい」にすり替わっていました。
何か掘り起こせた？
- 解決するという基本姿勢を崩さない
- 終わらせるは絶対に駄目、解決しよう
おしまい
基本に従い作業に取り込むことを常に心がけているつもりなんですけどね。人間性ですかね。自己嫌悪に陥るのも解析作業のときが一番多いです。 山本有三の小説に出てきた言葉が、身に沁みます。 「真実一路の旅なれど、真実、鈴ふり、思い出す。」
