開発の記録

今回はI2Cシミュレータのハードウェアの話です。 Windows/Mac/RasPiからアクセスするのに便利なUSBインターフェイス経由でI2Cセンサーを操作しようとしているわけですが、RasPiに組み込みたい場合、USBインターフェースは冗長ですね。 そこで、I2CシミュレータはUSB-シリアル変換部と、I2C I/Fを持つメインマイコン部に分離できるようにしておきます。開発時にはUSB-シリアル変換を使うが、RasPiに組み込む時はこれを外してシリアルインターフェース同士で直結するようにする。 以前はI2Cインターフェースで直結しようとしていましたから、コマンド解釈のためのマイコンが途中に挟まることになります。開発効率や発展性を考えるとこれくらいは許してもらいたいものです。

腕に覚えのある人はすぐ自分で色々やりたがりますが（私もそうです）、仕事を先に進めるためには、自分で手を加えるところは最小限度にすべきです。今回は自作の回路とプログラム、しかもmasterとslaveの二組あるので１本の信号の動きを確認するだけでも大変でした。特にブレッドボードは曲者です。ジャンパ線は多くても数本程度にすべきでしょう。最後は信号ピンの定義が間違っていたことと電圧降下で動かないことがわかるまで時間がかかってしまいました。今回は予想外に大規模になったのが失敗の元でした。 明日は予定があってこの仕事はできませんので、明後日、確認の取れた部分は半田付け回路に固定してトラブルを抑えようと考えています。 今日はここまで。

いわゆるメーカーズを標榜する各社が、センサーの物理I/Fの標準規格を提案しています。代表的なものに SparkfunのQwiic SeeedのGrove DigilentのPmod MikroElektronikaのmikrobus DFRobotのGravity <-- '18.11.26追記 スイッチサイエンスのConta 等があり、考え方がそれぞれ違います。当社の考えは (1) 通信の規格はI2Cに限定する 当社のやりたいことはI2Cで実現できるからです。他の規格、例えばSPIなどが必要になった時に考えます。必要のないときに余計な規格を決める必要はないでしょう。 (2) メイン基板を固定してセンサーを各種取り替えながら開発する可能性を考えると、基板同士を繋ぐ規格は欲しいが、センサーには設置条件とか取り付け方法があるのでセンサー基板をメイン基板に直に固定する構造を取れるかどうかを予め決められない。例えばイメージセンサーはケースに固定したいし、温度センサーはケーブルで引き出したい、等が考えられる。と言うわけで、メイン基板に載せるコネクタ（メス）だけ決めることにする。そのコネクタ以降センサーまで、電線が繋がればどんな規格でもいいことになります。 (3) コネクタを決める際に考慮すべきなのは、(a)信号の種類（数）、(b)寸法・形状、であるが、今までの経験から次のようにする。 ・I2Cのみの対応で大抵のことは実現できる。従って信号はVDD, GND, SCL, SDAの４本にする。 ・VDDの電圧は決めない。5V対応のコネクタには5V対応のセンサーを刺せば良いだけだからだ。ここではコネクタ内のピン位置だけ決める。対応する電圧はコネクタ毎、基板にシルクで明示が必要だろう。 ・試作では未だ主流の2.54mmピッチに合わせる。 ※ DFRobot社のGravity 4pin cableは2.0mmピッチのコネクタと2.54mmピッチのコネクタを両端に持っているようです <-- '18.11.26追記 ・実用化を視野に入れると、脱落しないようロック機構は欲しい。 ※コネクタを各種見てきましたが、XHシリーズが一番当社の目的に適っていると思います。 これだけ決めておけばメイン基板の設計ができます。

初版のコードは書き上げました。これからデバッグしたいのですがデバッグのために既製のI2Cセンサーを使うのは操作性が悪く（ロジアナやオシロを使うことになる）、またカバー率も良くない（既製品が全てのプロトコルを実現しているわけではない）ので、今後繋ぐ可能性のあるI2Cセンサーのシミュレータを作ってみようと思います。ただし、ここでもこれを作るのが本業・本筋ではないので、完璧を目指すようなことはしません。というわけで開発方針は １．スタートスモールで始める。今回の目的からスレーブモードのみとする。1byte read/write等の簡単なプロトコルで動かし始め、必要になったら複雑なプロトコルを追加できるようにする。ホストCPUのターミナルやプログラムから動かすのが目的なので、必要以上に完璧を目指すことはしない。 ２．タイミング規定については専用の計測器を頼ることにする。 となります。次はこのシミュレータの仕様を考えます。

2018.11現在、第３版になっています。 こちらからどうぞ。 ＝＝＝ 第１版から変更した箇所は 下線で示す 。 ＝＝＝ １．名称： I2C-COM ２．文字： 0|1|2|3|4|5|6|7|8|9|A|B|C|D|E|F|S|P|R|W|T|K|N| a|b|c|d|e|f|s|p|r|w|t|k|n の36文字。その他は全て区切り記号として 使われる。 ３．数値文字： 0|1|2|3|4|5|6|7|8|9|A|B|C|D|E|F| a|b|c|d|e|f の22文字。 ４．バイト： 数値文字２桁で表す。範囲は0x00~0xFFである。 ５．スレーブアドレス： 7bitを数値文字２桁で表す。範囲は0x00~0x7Fである。 ６．制御文字： S|P|R|W|T|K|N| s|p|r|w|t|k|n の14文字。以下にそれぞれの機能を説明する。 前提として、１つのトランザクション（ひとまとまりの流れ）はS |s で始まりP |p で終わる。その途中に再度S |s があってもよい。 S |s ・I2C信号線上にSTART条件を出す。リプライはない。エラーもない。 P |p ・I2C信号線上にSTOP条件を出す。リプライはない。エラーもない。 K |k ・I2C信号線上でslaveから8bit受信した後ACK条件を出す。8bit受信できなかったらタイムアウトエラーになる。（タイムアウトになる条件は後日） N |k ・I2C信号線上でslaveから8bit受信した後NACK条件を出す。8bit受信できなかったらタイムアウトエラーになる。（タイムアウトになる条件は後日） R |r ・スレーブアドレスが後に続く。Pを出すまでデータの向きはslave -> masterである。slaveからACKが返らないとタイムアウトエラーになる。（タイムアウトになる条件は後日） 例）R29 W |w ・スレーブアドレスが後に続く。Pを出すまでデータの向きはmaster -> slaveである。slaveからACKが返らないとタイムアウトエラーになる。（タイムアウトになる条件は後日） 例）W29 T |t ・バイトが後に続く。Pを出すまでデータの向きはmaster -&g

I2C-COM（コマンド言語の名称）のパーサを実際ターミナルから動かしながらデバッグしていて、使用感が悪いことに気づいたので仕様を見直そうと思います。 (1) 大文字が入力しづらい capital lockすればいいのですが、そう言う習慣がなく、いちいち切り替えるのが面倒なので大文字でも小文字でもいいことにしようと思います。 (2) キー入力直後に動作することに違和感がある 現状の仕様では、例えば"S"と入力したら入力した直後に動作し、"W01"と入力する場合は最後の"1"を入力すると同時に動作するわけですね。ターミナルから使うことを考慮すると、入力した１文字毎にエコーバックして、"W01"の次にEnterを押した後に実行するのがいいと思います。将来的には間違いがあったら直せるのがベターだと思いますが実装に時間がかかりそうなので後回しにします。 (3) (2)に関連しますが、将来的にはプログラムから直接駆動もしたいので、ターミナルから使う場合はターミナルモードに入ってから使うようにしようと思います。ターミナルモードに入らない場合はバイナリモードになるかもしれません。実装は後日になります。

オリジナルは こちら char convertCharToHex(char ch) {   char returnType;   switch(ch)   {     case '0':     returnType = 0;     break;     case  '1' :     returnType = 1;     break;     case  '2':     returnType = 2;     break;     case  '3':     returnType = 3;     break;     case  '4' :     returnType = 4;     break;     case  '5':     returnType = 5;     break;     case  '6':     returnType = 6;     break;     case  '7':     returnType = 7;     break;     case  '8':     returnType = 8;     break;     case  '9':     returnType = 9;     break;     case  'A':     returnType = 10;     break;     case  'B':     returnType = 11;     break;     case  'C':     returnType = 12;     break;     case  'D':     returnType = 13;     break;     case  'E':     returnType = 14;     break;     case  'F' :     returnType = 15;     b

ArduinoをMacにUSBポートで繋いで、ターミナルから操作できることを確認します。 ＝＝＝ オリジナルスケッチは こちら です。 void setup() { Serial.begin(9600); } void loop() {   if(Serial.available() > 0){     char ch = Serial.read();       Serial.write(ch);   } } ＝＝＝ Arduinoに上記スケッチを書いたら、Mac/Linuxのターミナルから cd /dev でシリアルポートを探し、 screen /dev/*** 等で、叩いたキーがそのまま表示されるか確認します。終了はctrl+a, ctrl+k, yです。 ここまで

コマンドパーサとは、コマンドを解釈するルーチンのことですが、Arduinoのスケッチではloop内に実装します。以下、概略を示します。 ＝＝＝ シリアル受信した１文字が 'S'ならstart()を出しておしまい。 'P'ならstop()を出しておしまい。 'W'なら後に続く２文字(hexa)を受信して左に1bitシフトして、write(bit)を8回実行し、read()でACK/NACKを返す。 'R'なら後に続く２文字(hexa)を受信して左に1bitシフトして1bを加え、read()を8回実行し、9回目のread()でACK/NACKを読んで返す。 'T'なら後に続く２文字(hexa)を受信してMSBからwrite(bit)を8回実行し、read()でACK/NACKを返す。 'K'ならwrite(0)を出しておしまい。0=ACKを意味する。 'N'ならwrite(1)を出しておしまい。1=NACKを意味する。 ＝＝＝ ここまで

start/stop/read/writeの各関数を書いていきます。"tSU_STA"等は規定時間以上待つことを意味します。 void start(void) {sda(1); scl(1); tSU_STA; sda(0); tHD_STA; scl(0); tLOW;} void stop(void) {sda(0); scl(0); tLOW; scl(1); tSU_STO; sda(1); tBUF;} データ転送関数は、関数に入ってくる時の状態がバラバラなので、次の規則を設けて時間を保証することにする。考え方は、 ・関数に入って出るまでにSCLがlow->high->lowの１サイクル動く。この時間をtLOW1, tHIGH1, tLOW2で表す。tLOW1>tSU_DAT, tHIGH1>=tHIGH, tLOW2>tVD_DAT、とする。 ・writeは関数に入った直後、readは関数に入ってくるとき、SDAは確定していることを前提とする。そのため、関数から抜けるときに次の転送サイクルのSDAが確定しているようにする。 void write(byte data) {sda(data); scl(0); tLOW1; scl(1); tHIGH1; scl(0); tLOW2;} byte read(void) {scl(0); tLOW1; scl(1); temp=SDA; tHIGH; scl(0); tLOW2; return temp;} ここまで

start/stop/read/writeの各関数を書き下す前に、SCL, SDAの各信号を操作する関数を作ります。 ＝＝＝ void scl(byte) ※引数の形式はbyteであるが、0x00の時はSCL=low、それ以外の時high-impedanceにします。SCL信号はpull upされているのでhighになります（slaveはhigh-impedanceであることが前提）。 byte sda(byte) ※引数の形式はbyteであるが、0x00の時はSCL=low、それ以外の時high-impedanceにします。SDA信号はpull upされているのでslave出力がlowならlow、highもしくはhigh-impedanceならhighになります。 ※返り値の形式はbyteであるが、0x00かそれ以外で判断すること。 ここまで

関数のイメージを作るためにI2Cバスプロトコルを最小単位に分解してみます。 1. START: SCL=high, SDA=fall 2. STOP: SCL=high, SDA=rise 3. write_low: SDA=low, SCL=low>high>low。ACKをmasterから出すときもこれ。 4. write_high: SDA=high, SCL=low>high>low。NACKをmasterから出すときもこれ。 5. read: SCL=low>high>lowの時SDAを読む。slaveから出るACK/NACKもこれ。 できるだけ関数は減らすことを考えます。引数を持つようにすれば関数の数は減りますが、引数に固定値を入れるくらいなら関数を分けるのと同じなので、引数に変数を使うメリットがあるかどうかで考えます。 ・1と2は引数を使って一緒にすると分かりにくく間違いが起きそうなので一緒にはしない。 ・3と4は変数引数を使えると便利なので一緒にする。 よって関数は次の４つを作ることにします。 1. void start(void) 2. void stop(void) 3. void write(byte) ※引数の形式はbyteであるが、0x00の時は0b(ACK)、それ以外の時は1b(NACK)を書く。 4. byte read(void) ※返り値の形式はbyteであるが、実際には1bitであり、0x00(ACK)か否か(NACK)で判断すること。 ここまで

ここからいよいよI2C-COMを実装して行きます。 当面Arduinoのスケッチを書くことになるのですが、その準備作業としてSCL、SDAを操作する関数を作ることにします。ここで考慮したいのが、関数にどこまで機能を持たせるかです。高機能で書きやすいのと低機能で細かく制御できるのとのバランスをどこに置くかと言ういつもの問題です。底辺の最初の設計を間違うと後々まで響くので慎重に検討します。 ＝＝＝ まず、後で困らないようにSCL, SDAのタイミング規定を確認しておきます。Standard-mode CLK=max.100kHzを前提とします。 ここではSCLはmasterからだけ出力し、SDAもmasterから出力するときの規定だけ気にすれば良いので（slaveが規定を逸脱したらどこかでエラーになることを期待する）、守らねばならない規定は次のようになります。 (1) SCL自身の規定 0<fCLK<100kHz, tLOW>4.7us, tHIGH>4.0us (2) SCLとSDAの関係に関する規定 小解説： set up timeとは、信号Aのある時点に対して信号Bが前もって確定しておかねばならない時間 hold timeとは、信号Aのある時点以降も信号Bが確定しておかねばならない時間 ＝＝＝ プログラムで意識しやすいように、タイミング規定を(1) SDA -> SCL、(2) SCL -> SDA、に分類します。 (1) SDA -> SCL tHD.STA>4.0us：START condition時、SDA=fallからSCL=fallまで tSU.DAT>250ns：データ転送時、SDAが確定してからSCL=riseまで (2) SCL -> SDA tSU.STA>4.7us：REPEATED START condition時、SCL=riseからSDA=fallまで tHD.DAT>0：データ転送時、SCL=fallからSDAが次に変化するまで tSU.STO>4.0us：STOP condition時、SCL=riseからSDA=riseまで ＝＝＝ 長くなるのでここまで

I2C制御コマンドを実装する下準備として、I2C制御コマンドの書式を正確に定義しておきます。 ＝＝＝ １．仮称： I2C-COM ２．文字： 0|1|2|3|4|5|6|7|8|9|A|B|C|D|E|F|S|P|R|W|T|K|N の23文字。その他は全て区切り記号として読み飛ばされる。 ３．数値文字： 0|1|2|3|4|5|6|7|8|9|A|B|C|D|E|F の１６文字。 ４．バイト： 数値文字２桁で表す。範囲は0x00~0xFFである。 ５．スレーブアドレス： 7bitを数値文字２桁で表す。範囲は0x00~0x7Fである。 ６．制御文字： S|P|R|W|T|K|N の７文字であり、以下にそれぞれ説明する。 前提として、１つのトランザクション（ひとまとまりの流れ）はSで始まりPで終わる。その途中に再度Sがあってもよい。 S ・I2C信号線上にSTART条件を出す。リプライはない。エラーもない。 P ・I2C信号線上にSTOP条件を出す。リプライはない。エラーもない。 K ・I2C信号線上でslaveから8bit受信した後ACK条件を出す。8bit受信できなかったらタイムアウトエラーになる。（タイムアウトになる条件は後日） N ・I2C信号線上でslaveから8bit受信した後NACK条件を出す。8bit受信できなかったらタイムアウトエラーになる。（タイムアウトになる条件は後日） R ・スレーブアドレスが後に続く。Pを出すまでデータの向きはslave -> masterである。slaveからACKが返らないとタイムアウトエラーになる。（タイムアウトになる条件は後日） 例）R29 W ・スレーブアドレスが後に続く。Pを出すまでデータの向きはmaster -> slaveである。slaveからACKが返らないとタイムアウトエラーになる。（タイムアウトになる条件は後日） 例）W29 T ・バイトが後に続く。Pを出すまでデータの向きはmaster -> slaveである。slaveからACKが返らないとタイムアウトエラーになる。（タイムアウトになる条件は後日） 例）W8A 以上

今日は休日ですが、早く方向性を出したかったのでSoftI2CMasterを使って見ました。 結論から申しますと、SoftI2CMasterは使わず、SCL, SDA信号を直接制御することにしました。一から作るのは大変なことは百も承知ですが、土台がしっかりしていないといくらその上層部が綺麗にお化粧されていたところで動きがよくわからず、問題があった時デバッグも修正も拡張もできないことがわかったからです（こんなこと書くのこれで何度目だ）。 いきなりアセンブラやCで書き始めるのは無理があるので、当面はArduinoのdigitalWrite/digitalReadでどこまで対応できるかやってみることにします。 ＝＝＝ 最初に気づくのは、SCL, SDAを制御するには双方向なことです。ArduinoのピンはpinModeでinputかoutputのどちらかしか定義できませんからArduinoの外部に3-stateバッファを外付けすることを考えないと行けません。 もう一つ気になるのは、Arduinoのスケッチで書いてI2Cのスピードが出なかったときどうするかです。I2C制御をするだけのためにArduinoを高いCPUに置き換えることは考えにくいのですが、メインCPU（RasPiを想定している）にI2C信号を直結すればスピードの問題は解消するかも知れません。その際に一度書いたプログラムがそれほど大きく書き換えなくていいことが望ましいのは言うまでもありません。 I2C+uC->USB->メインCPU、の流れにしておけば、メインCPUはMac/Windows/Raspi等々何でも使えるので、I2Cセンサーをちょっと使ってみる、ソフトの初期開発をする、等の際には便利でいいと思っていました。もし仮に、実用化の際にuC->USBの部分を端折って、I2CをメインCPUに直結せねばならない時が来ても、I2Cプロトコルを一旦コマンドにしておく、と言う流れは変えなくて良いので、今後無駄にはならないのではないかと思います。

次にどう実装するかを考えます。当然今までの検討は実装することをイメージして進めているわけですが、最終段階で、できると思ってたことができなかったりすると後戻りが大きいので、一つのレイヤーの実装イメージができたら実際に動作を確認してから次のレイヤーの構想・開発に進めることが大事です。 前回までで、以下に示す７種の動作をI2Cで実現する(1)のと、これらを使って言語で使い勝手の良い関数を作る(2)ことを進めれば良いことがわかります。本稿では(1)を進めます。 S:START P:STOP R:7bitのslave addressにRと識別する1bitをつけて1byte writeしてACKを待つ W:7bitのslave addressにWと識別する1bitをつけて1byte writeしてACKを待つ T:8bitのregister address/dataを1byte writeしてACKを待つ K:slaveから8bit送ってきたらACKを返す N:slaveから8bit送ってきたらNACKを返す 上記のS, P,,,Nの動作をI2Cに落とし込むのに、ここではArduinoをベースに考えます。「一気通貫に動くところまで進めてから後のことを考える。一個一個を完璧にするようなことはしない」と言う方針に則り、手元にあってIDEに習熟して動作が簡単に確認できる物を使います。もちろんどんなCPU、言語、を使っても構いませんし、やってくれる人がいると嬉しいのですが。 ArduinoでI2Cを動作させるのに、 Wireライブラリ があることがわかります。ところがこのライブラリの関数には以下のようなものがあるのですが、いたって使い勝手が悪いのです。ここまで読み進めていただいた方にはお分かりでしょうからクドクド申しません。 ＝＝＝ begin() requestFrom() beginTransmission() endTransmission() write() available() read() SetClock() onReceive() onRequest() ＝＝＝ せっかくI2Cプロトコルを一番primitiveなところまで分解したのにまた高級言語の壁に突き当たってしまいました。

本稿からいよいよコマンドからI2Cの制御ができるようにしていきます。 ここで考慮したいのが使い勝手と処理スピードのバランスです。例えばPythonから直接SCL, SDAが見えて制御できれば何でもできるわけですが、あまりにも非効率なのは議論を待たないでしょう。しかし今あるライブラリの関数だとデバッグ性も拡張性も低い。ではどこら辺りが落としどころなのか？ ここでもう一度、I2Cプロトコルのおさらいをしますと、 ＝＝＝ (1) データ転送は、SCL=highの時SDAを安定させ、SCL=lowの時SDAを変化させて行うのが基本。 (2) SCL=highの時SDAをhigh->lowとしたらSTART、SCL=highの時SDAをlow->highとしたらSTOP。全てのトランザクションはSTARTで始まりSTOPで終わる。START->STOPの間にSTARTが再びあっても良い。START/STOPはマスター側からしか起こさない。 (3) 送信側が8bitデータを転送した直後、受信側がACK or NACKを返す。マスターが送信側の時はスレーブが受信側だがその逆もある。ACK (NACK)とは、SCL=highの時SDA=low(high)で示す。 ＝＝＝ 以上を踏まえてプロトコルを次のように分類します。 ＝＝＝ (1) マスターから一方通行でリプライのないアクション。 (2) マスターからアクションを起こしてリプライを待つ。 (3) マスターが予期しないときスレーブからの割り込み動作は考慮しない。 ＝＝＝ (1)には、START, STOPが入ります。 (2)を更に整理すると (2-1)マスターから1byteデータを送ってスレーブからのACKを待つ。1byteデータには、7bitのslave address+R/W識別bit、8bitデータ、のバリエーションがある。１つのコマンドでは使いにくいので３つに分ける。シェルからコマンド打つとき、頭の中でアドレスを1bitシフトしてR/Wの1bitをつけて、は面倒だと思った。 (2-2)「マスターから何らかのアクション」を起こされてスレーブからデータを送るシーケンスが始まる。データ受信後マスターがACKを返せば継続、NACKを返せばそこで終了。「マスターから何らかの

前稿でI2Cプロトコルをおさらいしました。今回はこれをソフトにどう見せたら使い勝手が良いのか考えてみることにします。 今まで見てきたI2C制御のライブラリは、コマンド・関数の実装の中でI2Cを参照・制御している部分がブラックボックスになっており、信号の動きが想像しづらくてデバッグ性が低く、拡張性もない、のが気に入らないのです。 そこで、I2C制御に出来るだけ１対１に対応するコマンドを設定して、シェルから直接コマンドを叩くもよし、このコマンドを使ってもっと高度で複雑な関数を作るもよし、にしようと考えました。 と言うわけで、まずは前稿のI2Cプロトコルをどんなコマンドにしたら良いかを検討することにします。

本稿が参照しているのは 「I2Cバス仕様およびユーザーマニュアルRev.5.0J-2012年10月9日」 の日本語翻訳11月2日 ですが、I2Cバスの全仕様を実装するのが目的ではないので、以下を前提とします。 (1) マスターは１個で固定。スレーブは複数あって良い。マルチマスターは考慮しない。 (2) SCLはマスターが駆動する。SCLをスレーブが駆動する処理は考慮しない。 と言う前提でI2Cプロトコルを要約すると (1) データ転送は、SCL=highの時SDAを安定させ、SCL=lowの時SDAを変化させて行うのが基本。 (2) SCL=highの時SDAをhigh->lowとしたらSTART、SCL=highの時SDAをlow->highとしたらSTOP。全てのトランザクションはSTARTで始まりSTOPで終わる。START->STOPの間にSTARTが再びあっても良い。START/STOPはマスター側からしか起こさない。 (3) 送信側が8bitデータを転送した直後、受信側がACK or NACKを返す。マスターが送信側の時はスレーブが受信側だがその逆もある。ACK (NACK)とは、SCL=highの時SDA=low(high)で示す。 これらを前提に、コマンドとか関数にはどう見えるのが使い勝手がいいのか考えることにします。

前回まで、PythonからI2C制御をする方向で進めてきましたが、開発環境が整わず隔靴掻痒の感があります。コマンド・関数とI2Cの信号の動きの関係が取りづらいのです。 そこでこの際、自分が使いやすい環境を整えることにしました。「環境を整えるのが自分の仕事ではない」と言いつつ、言うこととやっていることが矛盾してるじゃないか、と思われるでしょうが、どうも「I2Cの開発環境を整える」のが自分の仕事かもしれない、と感じ始めました。 前置きはここまでにして、概略次の方針で進めることにします。 (1) I2Cの動きを過度に隠蔽しない 高度なコマンドや関数を作ってデバッグ性や拡張性を犠牲にしないと言うことです。今まで見てきたものへの批判です。 (2) 開発スピード、実用性を重視する 開発環境が完璧にできあがっても使えない、使いづらい、ような結果になるのを避ける。使えるところまで積み上げたら最初から見直す、ようなこともありうると言うことです。 ＝＝＝ と言うわけで、まずは次回、I2Cプロトコルのおさらいから始めます。

いずれPython3にしないといけないとはわかってはいるのですが開発環境が整うまで、Python2でできるところまで進めることにします。 ＝＝ さて、前回までにi2c-toolsとpython-smbus をインストールしたので、pythonのコマンドラインからI2Cインターフェースにアクセスしてみます。挙動が既知で諸々の作法が不要な（要するにコマンドが最小限で動く）I2Cセンサーがあると良いのですが、手元にそういうものがなかったので、Arduino互換のSeeeduino基板に"slave-receiver"というスケッチを入れてI2Cセンサーの代わりをさせることにしました。 RasPi(Python) <--I2C-->Seeeduino(slave-receiver) --> Mac/Arduino IDE(シリアルモニタ） という構成です。RasPiからPythonコマンドを叩いた結果がMacのシリアルモニタから出力されるのを確認しました。 $python >>>import smbus >>>bus = smbus.SMBus(1) >>>bus.read_byte(0x80) 0 >>>bus.read_word_byte(0x80, 0x00) 65280 ... （この間シリアルモニタを観測している） と言う具合です。 ここでpython-smbusパッケージで用意されているfunctionには2byteアドレスがサポートされていないことに気づきました。私がこれから使おうとしているI2Cデバイスにはデバイスアドレス（デバイス内のレジスタをアクセスするためのアドレス）が2byte必要なのです。次はここを解決しようと思います。 今日はここまで ＝＝ 備忘録 ・SeeeduinoのI2Cコネクタは5VなのでRasPiに直結してはいけません（やってしまった、ということ）。運良くRasPiボードは死ななかったものの、ACアダプタが死にました。

PythonからI2Cを制御する際の、コマンド（ファンクション）の一覧を備忘録として残しておきます。SMBusとはI2Cのサブセットです。 Using the I2C Interface 以下、addressは7bit、つまりread/write bitは含まれません。 SMbus Functions long write_quick(int addr) R/W bitを出すのみ long read_byte(int addr) デバイスアドレス指定なしに1byte読む long write_byte(int addr, char val) デバイスアドレス指定なしに1byte書く long read_byte_data(int addr, char cmd) long write_byte_data(int addr, char cmd, char val) long read_word_data(int addr, char cmd) long write_word_data(int addr, char cmd, int val) long process_call(int addr, char cmd, int val) long[] read_block_data(int addr, char cmd) write_block_data(int addr, char cmd, long vals[]) long[] block_process_call(int addr, char cmd, long vals[]) I2C Access Funstions long[] read_i2c_block_data(int addr, char cmd) write_i2c_block_data(int addr, char cmd, long vals[]) Code Example #!/usr/bin/python import smbus bus = smbus.SMBus(1) # 0 = /dev/i2c-0 (port I2C0), 1 = /dev/i2c-1 (port I2C1) DEVICE_ADDRESS = 0x15 #7 bit address (will be

今後はPythonでI2C制御することを考えており、その際に存在が隠れてしまうi2c-toolsについて何かあったときのために情報を手繰れるようにしておきます。 シェルコマンドからi2c-toolsのコマンドを叩いたときのI2C信号の動きを解説したサイトは以下です。 Raspberry PIのI2Cコマンド詳解 Usage: i2cget [-f] [-y] I2CBUS CHIP-ADDRESS [DATA-ADDRESS [MODE]]   I2CBUS is an integer or an I2C bus name   ADDRESS is an integer (0x03 - 0x77)   MODE is one of:     b (read byte data, default)     w (read word data)     c (write byte/read byte)     Append p for SMBus PEC ex.) i2cget -y 1 0x08 0x00 c（-y optionで入力待ちをしないようにしています） Usage: i2cset [-f] [-y] [-m MASK] [-r] I2CBUS CHIP-ADDRESS DATA-ADDRESS [VALUE] ... [MODE]   I2CBUS is an integer or an I2C bus name   ADDRESS is an integer (0x03 - 0x77)   MODE is one of:     c (byte, no value)     b (byte data, default)     w (word data)     i (I2C block data)     s (SMBus block data)     Append p for SMBus PEC Usage: i2cdump [-f] [-y] [-r first-last] I2CBUS ADDRESS [MODE [BANK [BANKREG]]]   I2CBUS is an integer or an I2C bus name   ADDRESS is an integer (

ここに至るまで紆余曲折がありましたが、とりあえず無事にRaspberry PiのI2Cインタフェースが開通したので備忘録を留めておきます。 (1) 当初、Macでアルゴリズムを開発してRasPiにそのまま移植することを目論み、Adafruit社から出ているFT232Hのbreakout boardを動かそうとしました。 (2) ところが、Macの環境構築がAdafruit社のサイトにある説明通りにやっても動かない。これは説明やインストールのためのスクリプト等々がPython2のままupdateされていないことが原因ではないかとの疑いがあり、これ以上追求するのを止めました。 (3) MacからRasPiに移植するのではなくRasPiで直に開発すべく、同じくAdafruit社のサイトの通りにやってもまた動かない。これもPython2のままなのが問題である疑いがあり、I2C->USB変換を諦め、I2Cのインタフェースを直にRasPiに直結することにしました。 (4) RasPiにI2Cを直結するに当たり、Bluebacksの「実例で学ぶRaspberry Pi電子工作」を参考にしました。直結したあと動作を確認したいのですが、sudo i2cdetectが動かない。エラーメッセージを見るに、/dev以下にi2c-1等が見えないのがそもそも問題と判明。RasPiのOSがだいぶ新しくなっており、P.95の「8. Advanced Options」がないためこのステップは必要ないと判断したのが問題だったと睨んで最初からやり直すことにした。 (5) sudo raspi-configに「5. Interfacing Options」があることを発見、ここで「Would you like the ARM I2C interface to be enabled?」に「はい」を選択。 (6) 開通の確認をしたいのだが、sudo i2cdetectが使えることを知り、I2Cのアドレスが表示され、無事開通したことを確認しました。 こんな紆余曲折は良いから最短でRasPiにI2Cを繋ぎたい、と言う人は以下を参照ください。 ＝＝＝＝ 次のサイトを参考にしました。 Raspberry Pi で I2C を利用するための設定 (1) I2CのVDD, GN

その昔所属していたところで、RISC-CPUの出始めに、開発環境を整えるのにご執心のマネージャーがおりました。大勢で効率よくオリジナルのハードウェアとそこに乗るOS、アプリケーションソフトウェアを開発したいのですが、市販に良いツールがなく、内部で開発しようとしておりました。 今だから言えるのかもしれませんが、開発環境は付加価値を産むものではなく、一度作ってそれを維持するのにもコストがのし掛かってくるものです。メインフレームの設計でCAD部隊を社内に持ってオリジナルの設計言語を開発し維持していたのも同じ状況にあります。最終的にはVHDLとかVerilogとかの設計言語に取って代わられてしまいました。その前にメインフレーム自体がなくなりましたけど。 今当社でも似た状況にあり、そんな昔のことを思い出しました。市販のツールでは開発が効率悪いとしても、ツールを作るのが本来の仕事ではないのです。 自社の開発リソースをどこに振り向けるべきなのか？は明らかです。

今まで約１０年、無線スイッチ・無線センサーを手がけてきました。可能性と今後の方向性が見えてきたように思います。 無線スイッチ・無線センサーの進化の方向性として次の要素があると思います。 (1) 無線方式、プロトコル・・・周波数帯とかプロトコルを変える、追加する。ここはメジャープレーヤーがわんさといますから自社で手がけるようなところではありません。ありがたく使わせていただくところです。 (2) 省電力方式・・・エナジーハーベストをやってきましたが、取れる電力の進歩がそれほど早くないことがわかってきました。ソーラーセルの発電効率とか押したり踏んだりする力などの限界でスイッチやセンサーでやれることがそれほど多くないと言うことです。 (3) クラウド・サービス・・・AIが実用域に入ってきたので今後はIoTで集まってくる物理的な情報をいかに料理するかが腕の見せ所になるのでしょう。ただこの領域は大勢のプレーヤーが狙っているところなので、敢えて自社が手がけるのかどうかはよく考えないといけません。 (4) センサー・・・私はもともと計測技術者なのですが、我田引水的にもセンサーが一番有望そうな気がしてきます。 と言うわけで、当社の次の１０年は「センサー」がキーワードになると思います。

今日10/23付日経最終面に、４０年前一世を風靡したスペースインベーダーの開発者が寄稿していました。 そこで興味深かったのは、ゲームメーカーの一技術者が、ディジタル技術、マイコン技術を習得する過程です。みんなが面白いと思ってくれるものを作ろう、自分たちが面白いことをやろう、という精神です。 楽しさ、面白さは、使命感、義務感で仕事をするよりはるかに効率が高い。と言っては身も蓋もないが、新しいことを立ち上げる突破口になりうる要素だろうと思います。 Facebookを立ち上げる時に創業者が狂ったように働いた話は映画にもなりました。その昔Linuxを始めたLinus Torvalds氏もなぜ始めたのかと問われてただ楽しかったからと答えたそうです。 創業は面白さ、楽しさがなければ続かないでしょう。普通の人がしないこと、できないことをするんですから。

外からの情報が乏しく部門内の情報でビジネスをしていると「個別最適」に陥りがちです。「個別最適」が分かりづらい人のためにこんな例を挙げておきます。 「戦国時代、自分の領地だけに通用する法律を一生懸命整備した大名がいた。ところがその後隣国と戦って領地を失ってしまった」。現代社会、会社内でこんなこと良くありますよね？その事業を成り立たせるための効率化を追求していたが、そのうちその事業がなくなってしまった、というような。 特に技術開発部門は開発途上にあるものを公にはしないのが普通なので、公にできる状態、つまり販売開始まで開発方針を大きくは変えられない宿命を背負っています。IT業界にはもう一つ「互換性」と言う足かせもあって、世間の方向性が見えていても違う方向に舵を切りにくい性格もあります。 自部門、または自社内に閉じた最適化は所詮「個別最適」に過ぎません。事業が生き延びようとすれば、世界全体、超長期に渡る「全体最適、もしくは長期最適」を目指すべきだと思います。

無線の仕事をしていると世界市場のことがすっかり頭から消えていることに気づきます。無線には各国それぞれの規制があり、一個の商品で全ての国をカバーすることは不可能なので、国内市場で使える無線チップを使う製品を企画していると必然的に日本市場だけを向いてしまいがちです。 無線デバイスからセンサーデバイスに頭を切り替えた途端、世界市場を視野に入れるべきとの意識が芽生えてきました。なんせ、ネット販売サイトで世界を相手に売ることが容易な時代になったのです。日本に閉じこもってる場合じゃない。

事業を立ち上げる際には、自社が努力できるところ、努力する価値のあるところ、をきちんと見極めておく必要があります。 これからサービスを開始しようと言うのに、そう言うサービスは既に世の中にあった、なんて言うのは論外ですが、知らず知らずの間にそれに近いことをしてないでしょうか。「XX技術」を標榜しているのに単なる組み立て工場だった、つまりその本質となる技術は関係ない、と言うような会社をよく見ます。 同業で"IoT/M2M"を標榜する会社は数多くありますが、得意なのは、そしてその会社が付加価値をつけているのは何なのか、です。 コンピュータを設計しようと入社した会社が実は毎日NAND回路を書くだけ、プリンタを設計できると思ってたら毎日ひたすら印字サンプルを測色するだけ、無線事業をやれると思ったら毎日ネジを締める仕事だった、等々は従業員個人としてはよく聞く話です。会社に高尚な理念があれば自分の仕事はその一部、と納得できるかもしれませんが。 個人はともかく経営トップは経営理念に自社の付加価値をどう考えているのか、それで市場・技術動向にどう対応したいのか、すべきと考えているのか、を入れた方がいい。あるお菓子の老舗の経営理念は「美味しいお菓子を作る」だそうです。時代が変わって美味しく感じるお菓子が変わっても美味しさを追求し続けよ、と言うこと。特定のレシピを永久に守れ、ではないのです。

事業が大きくなってくると、創業者が創業時に抱いた思いが薄れ、本質を外していく会社をよく見かけます。本質を語ることは亜流で頑張っている方々に不快感を抱かせますがそこはご容赦を。 私が属した１社目。メインフレーム（大型計算機）設計の本質は「digital回路を正確に組み上げる」でした。経営陣がどんなに綺麗事を言って社内を奮い立たせようとしてもその本質は変わりませんでした。つまり、基本は誰でもできることだから、複雑・大規模化するしか生き残れる道がない。 片やメインフレームが廃れるのと入れ替わりに成長したマイクロソフトのスローガンは「あらゆる机にコンピュータを」、アップルは「Think different」、アマゾンは「顧客最優先」、グーグルは「世界中のあらゆる情報を整理して素早く届ける」だそうです。これ以上は言いますまい。 二社目。関係者が現役なのであまり刺激的なことは書けませんが本質はどうあがいても「インクをたくさん売る」です。それ以外、相当複雑で大規模なことをやってても所詮は脇役でしかない。 三社目。ここも関係者が未だおられるので短めに済ませますが、仕事の本質は「言われたことを正確にやる」です。それを新興国ができるようになれば自ずと仕事は減ります。 そして自ら創業した当社はと言えば。表向き「無線装置の輸入・開発・製造・販売」と言っていますが、本質は「センサーをネットワークに繋ぐ」です。 無線の会社じゃないんだ、と遅ればせながら自ら気づきました。

サラリーマンの場合、通常意識していないかもしれませんが、「顧客は働いている会社」です。営業マンなら「顧客って製品を買ってくれるお客さんでしょ？」と言う人もいるでしょうが、ここで言う「顧客」とは、「自分にお金をくれる人」のことです。 副業してない限り、属している会社は普通１つで、上司も一人です。その１つ、一人に全人生を無意識にでも賭けているわけで、相当なリスクを負っていると言うことです。 成りは小さくとも商売をしている人はいつも意識していることですが、新規顧客を獲得すること、そして顧客を大事にしてリピーターになってもらうこと、が大事な仕事になります。 反面、お得意様を獲得していくことも大事ですが、あまり過度に依存してしまうと、下請け化して、サラリーマンと同じ思考パターンになってしまいます。つまり新規顧客開拓を怠っているといきなり注文を切られて売上ゼロ、と言う危機に直面するわけです。新規顧客を開拓し、その中からお得意様になっていただき、なるべく長期のお付き合いをしていただく、と言うプロセスを続けるのが商売の基本になります。 特に技術者など、サラリーマン時代と仕事内容がそれほど変わりなくとも、決定的に違うのがそう言う思考パターンです。

開発の記録、と銘打ちながら販売の話も並行してせねばなりません。 新ジャンルの商品を作って売ることを考えている場合、どう言うチャネルでエンドユーザーに商品を届けるか？を見極めるのが非常に大事です。と言うことを新事業を始めてから思い知ることになりました。まさか地方の一零細企業が全国行脚して対面販売などできませんから。 販売チャネルとは、日用雑貨や食料品を思い浮かべてもらうと想像つくでしょう。雑貨や食品メーカは、コンビニ、スーパー、専門店、等々に並ぶように、コンビニなら本部のような卸業者に卸せばいいのだなと想像がつきます。 では無線チップなどの部品、無線センサー単体の完成品、システム、等々は？IoT業界は立ち上がり中なのと、ネット販売の潮流で非常に悩ましいのです。 クラウドサービスや保守サービスまで含めた販売は、自分がシステム屋になるつもりがなければそれを生業にしている人に売ってもらう、つまり販売代理店を募集するのが基本だと思います。大手キャリアやゲートウェイを扱っている業者さんも含まれるでしょう。ただこの方式を取ると、下請けに入ることを意味します。価格も数量も時としてブランド名も決められてしまう、と言うことです。自分の場合はこれを良しとはしませんでした。あくまで自社商品で、価格決定権も握ったまま勝負したい。無謀ですが。 もう一つ注目すべき点として、部品、単体の完成品、はネット通販が幅を利かせてきたと言うことがあります。システム売りもこちらに移行していくことを前提にした方が良いと思っています。どうやればいいのか？が腕の見せ所です。 新ジャンル商品の立ち上がり時期であり、かつ、ネット販売へのシフト。この２つが同時並行に進んでいるのでIoTの商品開発・販売はその戦略が大事なのです。

大規模な開発によく見られるのは、本質から外れていることに時間を費やしてしまう、過ちがあります。自分が作るべきなのか、持ってくる or 買ってくるべき部分なのかの見極めが遅れてしまうような。特に自分が時間を費やした部分には愛着があり、なかなか捨てられないものですが、将来性に疑問があるなら早めに見切りをつけることも大事な判断です。細い糸でも一本をゴールに早く到達させるのが、その後の全体の成功の秘訣です。まずかったら違う道を辿り直せばいい。ゴールに到達するかどうかわからない時点で道草を食っているべきではないのです。 また、大組織でありがちなことですが、競合する似たような技術開発を複数のグループで競ってしまうケースがあります。上層部からしたら保険を掛けたい気持ちもわからないではないですが、やらされている方、特に最後選ばれなかった方はたまったもんじゃありません。上司の特権で早くどちらか選んで全社を挙げて集中して取り組むべきです。 一人の場合は、謝る相手はいませんから、いつまでもグジグジ悩んでないで前向きになった方が成功は早いでしょう。

無線センサー・スイッチに手を染めたのが、最初はレストランでよく見かけるオーダーベルと称する呼び出しスイッチです。また次に目をつけたのがエナジーハーベスト無線です。 長年この低出力無線デバイスの業界にいると、このまま例えば十年後も同じ姿でいられるだろうか？と不安になります。要するに付加価値が考えにくく価格競争になっていくのが見えているからです。 サラリーマンだったら定年まで頑張ればいい、後のことは後の人が考えれば良い、というスタンスもありうると思いますが、自分の場合せっかく会社を起こしたのだし、会社というものは永続的に事業継続するのが当たり前で、それを目指した経営理念というものが必要です。 というわけで、永久は言い過ぎとしても、数十年に渡って進化し続ける事業をイメージすると、１ビットのON/OFFを電波に乗せるだけのデバイスよりは、少なくとも数バイト以上、欲を言えば画像を送れるようなセンサーデバイスを目指すべきとの考えに至ります。

温度や湿度等の環境センサーでない企業向けのセンサー、となるとどんなものが有望なのか？ ここから先は企業秘密になります。ヒントは、必要なセンサーは企業によって違う。企業の目指すもの、企業の性格による、です。これこそ顧客回りをしてニーズを掘り起こす、地味な活動が功を奏する腕の見せ所な訳です。 ここには書きませんが、近いうちにその成果の一端をお見せすることになると思います。

今まで無線センサーを長いことやって来ました。技術側からすれば、温度、湿度、気圧、照度、等々のセンサーがすぐ思いつき、商品化もしてきました。理由は「簡単に作れるから」です。センサーデバイスが安く手に入り、無線チップに繋げばすぐ動きますから。実用的か？と言われるとそれは全く別の話です。 ここまでが商品企画の話に出てきた「商品の種」です。とりあえず形があって動くものがあればお客さんに見せられますから。 数多く顧客回りをしてきた結果は「デバイスが容易に手に入るもので無線センサーを作っても需要がない」と言うことです。そう言う環境センサーは既にエアコンに内蔵されています。新しい環境センサー（例えばガスセンサーや騒音センサー）が出てもエアコンに内蔵されていくことでしょう。 当社はセンサーデバイスのメーカではなく、まして家電メーカでもありません。ではどこに活路を見出すのか？　センサーが単独で存在しうる市場を目指すべきだと考えました。結果的に、家庭には目を向けず、企業向け、B to Bのビジネスを目指すことになります。家庭に入り込んでいるメーカ、業者はわんさとおり、センサーもそこに入り込んでいくことは見えているからです。

私の２０代は、メインフレーム、と言ってもわからない人が増えて来たかもしれませんが、部屋を占有して専用の空調が必要な大型計算機を設計していました。 当時、マイクロプロセッサも出始めており、インテルとモトローラがアーキテクチャを競っている時代でした。マイクロプロセッサがメインフレームを完全に打ち負かすようになるとまでは予想しませんでしたが、ワークステーションやミニコンは置き換わるだろうな、とは薄々感じていました。 今やインテルとアームがCPUの覇権を競う時代になりましたが、それらのメイン市場はサーバとスマホですから、しばらくは棲み分けになるでしょう。その覇権争いに入り込む余地は他の業者にはほぼない、と言っていいでしょう。 というような話をなぜここでしているかと言うと。シリコンデバイス一個が世界を変えて来た時代を生きてきて、どんなデバイスが主流になるかで自分の立場、仕事が全く変わってしまうことを体験したので、今後のトレンドに相当敏感になったのです。 と言うわけで、展示会とかネットとか、実際メーカの人と直にお話しするなどして感じるのは、今後のIT業界を左右するのは「センサー」との感覚を得ています。もう一つ、「無線チップ」に今まで注目して来たのですが、そろそろプレイヤーは固定化して来た感があります。近距離は言うまでもなくWi-FiとBluetoothですね。長距離の5Gはキャリアの仕事なので我々のような業者は出る幕がありません。LPWAも基地局を持った方が勝ちで、ありがたく使わせていただくだけです。 「無線」は標準化してシェアを取る競争が全てです。お互い同じ方式でないと繋がりませんから。それに比較すると「センサー」には多様性と裾野の広がり、そして中小零細の出る幕が感じられ、我々のような業者には魅力的です。

大企業で商品企画をさせてもらえる部署・人はほんの一握りの人でしょう。しかも大組織となると、元々は何をしていた人なのか、技術者なのかはよくわかりません。オーケストラで言えば、楽器の演奏はできない、指揮だけ勉強して指揮者になったような人がやるのでしょうか。 では根っからの技術者が商品企画をすることは可能なのか？ 一番いいのは自分が起業することだろうと思います。技術も市場も理解し、自分が全ての決断を下す。そこに商品企画の醍醐味があり、それに憧れ、目指して、私は起業しました。 最終的に成功できるかどうか。神のみぞ知る、ですが、失敗してもそれはそれで満足です。自分で全てを決めて来たんですから。

私がなぜこんなに商品企画、商品企画と叫ぶのか。それには深い理由と長い歴史があります。 一つにはロールモデルとしている、誰もが知っているアップルの共同創業者、スティーブ・ジョブズの存在があります。彼は技術者のスティーブ・ウォズニアックと組んでアップル１、２というコンピュータを世に出すところから頭角を現して行くわけですが、ジョブズは技術者ではありませんでした。企画・マーケティング担当なんでしょう。というモデルがいる。 二つには、愚かな、とか稚拙な、と言っては失礼だが、そんな商品企画のもとで辛酸を舐めたことが多々あり、自分が企画せねば浮かばれない、と思ったのが大きな理由でしょう。技術者だった父親も犠牲者の一人かもしれません。 三つめ。商品企画とは技術と市場の接点であり、理詰めだけでもなく、感性とか博打とかの要素も多分にあるところに何とも言えない「アート」の要素が魅力的でもあります。 もしスティーブ・ジョブズがいなかったら。アップル社は既に世に無く、携帯電話も違った形で進化したであろうと思います。

前回までは、まず技術ありきの商品企画の進め方について書いて見ました。 要約すると、 （１）まず初めに、お客さんに見せられるような「商品の種」を用意する （２）お客さんへのヒアリングを続けて「市場の本当のニーズ」を掴む （３）そのニーズに合致した改良を施す。もしくはそれに隣接した「商品の種」を探す （４）（２）に戻る を繰り返すわけですね。では逆に市場ニーズがわかっていて、そこから技術を探す、技術開発を始める、ような商品企画はあり得るのか？ 以前それで大失敗した事例をいくつも見て来ました。最新の、将来性のある、実現性のある技術、というものに理解の浅い人が商品企画をすると的外れな発言で社内が迷走し、とんでもないものが出来上がります。出来上がればまだましでしょうけど。 今現在市場にないことは技術がわからなくても調べられるでしょうが、実現可能かどうか、その技術に将来性があるか、社員が人生を賭ける価値があると思えるかどうか、が判断できないと投資が無駄になります。 私は技術者の端くれとして現役技術者にエールを送りたい。技術者はもっと商品企画に口出しし、発言力を持って、もっと自分の技術の商品化を頑張るべきだと思います。

前回の投稿に一つ付け加えることがあります。 お客さんに持参する「種」が、お客さんに取ってどういう金銭的メリットがあるのか、訴求できる点を早く掴むのがコツということです。端的に言えば、決裁権のある人が、お金を出しても良い、と判断できるような情報を提供できるようにすると次に繋がりやすい、ということです。 簡単に言うと「我が社の製品はXX円ですが、これを買うとYY円の得になります」と言えるようにするのがベスト、ということ。当然YY>XXが前提です。 相手をしてくれる人はペーペーの担当者かもしれませんが、買うと決める人はその上司、そのまた上司、、、で最終的にはその会社の株主です。株主は株価が、つまり会社の価値が上がることを毎日考えています。そこに貢献できるのがいい商品です。

当社の商品企画の一端をお話ししましょう。この手の話は普通は企業秘密なので当然全部を明かす訳には行きませんが、似たような手法を取っているところがあるのと、それを大学の講義で行なっている講師の方がいらっしゃることを知ったので、隠して置くようなことでもないかなと最近思い始めたからです。 事業を立ち上げる最初のステップとして、市場に問う、簡単に言えばお客さんに紹介できるような「種」が必要です。自分自身が作ったものがあるならベストですが、そこまで行かずとも世に広まる前の商品なら他社製品でも構わないでしょう。 最初は手当たり次第に顧客訪問するのも致し方ないですが、そのうちに興味を示してくれるお客さんの傾向が見えてきます。お客さんから得られた情報を集約して行くと、今、そして将来、どんな商品をお客さん予備軍が欲しているのかが掴めてきます。 そしてお客さんが本当に欲しいものが持参したものか、自分の持っているものならベストですが、そうでないなら次の開発に繋げる、もしくは探してくる、ことになります。 そしてできた暁には再び顧客回りを再開するのです。 ここまでやれば、自分の持ち駒とお客さんのニーズが繋がったことになり、この細い糸を太くして行く努力を継続すればいいことになります。 よく聞くのは自分の持ち駒が市場に即していないとわかるとすぐそこで諦めて次の全く違うジャンルの製品にシフトしてしまうことがありがちのようですが、成功の秘訣は自分の持ち駒からそう離れずとも近い商品（開発）を模索し続けることではないかと思います。

今日はお客さんのところに訪問するついでに、東京ビッグサイトと幕張メッセで行われている展示会に寄って見ました。 以前、展示会に行くときは、手当たり次第にブースに寄っていたのですが、あまりに非効率なことに気が付いて、最近は興味のある展示を絞り、事前に寄るブースを決めてから行くようにしています。 最近は、新しい、珍しいセンサーの出展に注目しています。なぜなら、そういうセンサーの開発が行われているということは、そういうセンシングに需要があると言う裏付けだし、しばらくしてそのセンサー単体のサンプルが手に入るようになれば完成体にするのをビジネスチャンスと見ているからです。 当然同じことを考える人たちとの競争がスタートするわけですが、そこに自分の持ち味が加えられないか？と考え始めます。

2018,11,1 updated このブログを立ち上げた後、紆余曲折があって、「I2Cのタイミングチャートを読み込んでソフトウエアを書くのが辛い技術者のための開発ツール」を企画開発することにしました。 ＝＝＝以下2018.10.16 これから開発しようとしているのはいわゆるIoTというジャンルに入るものです。IoTとは センサーノード＞ゲートウェイ＞クラウド＞端末 という構成が一般的だと思いますが、それぞれにファームウェア・ソフトウェアが必要になります。 チームを組んでこれらを並列に進めることができる場合は各人が得意な開発環境でそれぞれ開発すれば良いわけですが、早急に立ち上げて実証実験を繰り返したいような場合、一人で大部分の面倒を見ないと行けない場合もあるでしょう。 そんなとき４種類も別々の開発環境で開発すると間違いや混乱で設計品質が落ちることが予想されるので、可能な限り開発環境、言語は１つか多くて２つにはしたいところです。 行き当たりばったりで色んな開発環境に手を出して保守出来なくなる前に、全体の開発計画を立ててから取り掛かることにしたいと考えています。