.net MicroFrameworkであそんできた

とうとう、春到来ですね。眼がかゆくてしかたない(T_T)
なんだか仕事に追われて、RL78やらRX621やらPSoC3やら、
もうワケワカメな状態が２週間ほどつづいています（笑




このうえ、この週末には、がじぇっと るねさすの大阪ミーティングがあり、
4月にはいると、mbed祭り＠大阪があり、とイベントずくめ。
どうやって時間つくるん？と自問自答。。。（笑
ま、なにかとたのしんでるんでいいけどね。
それぞれ特徴があるし。
にしても　GR-SAKURA　も　GR-KURUMI　もなかなかサンプル作る時間が
ないので、本格的に出すのはET-Westになっちゃうかもね。ま、それもいいか。



閑話休題。


先日(2013/3/7 &　3/11)に、なら工業技術センターで行われた

IT・RTセミナー 
『クラウドを使った遠隔監視システム工作』

に参加してきました。
内容的には
　 cosm(Pachube)をつかったデータのクラウド化
を
　.net Micro Framework(以下NETMF)をつかって実現してみよう！
という体験講座だったわけです。

cosmは、むかしPachubeと言われてたサイトで、ちょうど東日本の震災のときに
放射能データの共有などの話題で、少し有名になったかな～ってサイトです。
私の場合、NXP mbedをやり始めたときに、ネットワーク系のサンプルが
上がっていたので試したくらいの知識でした。
当時は、公開データしかできなくて、結構？？？なサイトでしたが
いまはかなり高度になって、使いやすい感じでしたヨ。

ま、こっちはおいといて。

NETMFについては、株式会社デバイスドライバーズの日高さんがこられて
概略をちょいちょいとお話になってられました（笑

ボードはGHI エレクトロニクスのGadgeteer FEZ-Spiderを。




                      スパイダーと Panda II



まぁ、よくできてはいるよね。
スパイダーというだけあって、いろんなのをコネクタくにくにとつけていくと
もう蜘蛛の足状態だし。
自分の環境でいろいろ足し込んでいくなら FEZ Panda IIのほうが
Arduino互換の足なので拡張しやすいかもなぁ。


まぁユニバーサルがそのままではつかえないのが痛いけど、
Spiderでケーブルだらけになるよりましかもしれず。

で、肝心のNETMFなんですが、ちょっと微妙かなぁ。
たしかに、VisualStudio2010と統合されて、C#でつくってデバッグできる
ってのはいいかなぁ、とおもいます。
言語仕様もはっきりしているし、なにより、PCのプログラマには
デファクトスタンダードな環境だし。


ただ、マイコン屋からみると、きわめて中途半端な仕様に映る。
イニシャルはいいとして、メインループで処理待ちをする、という
仕様になっているようで、むかしながらのタスク待ち関数をつくる
ようなイメージで、割り込みとかそういう部分が、かなり中途半端。
メッセージループはメインを出ないと、送信されないようなので、
処理にガッツリ時間をかけると、メッセージがかえらなかったりする。

まぁ、そのあたりに気をつけて書けばすむんだけど、そういう部分の
仕様がどこにドキュメントがあるのか、さっぱり検討がつかないのが
イタイ。

２日目の講習では、EthernetアダプタのMACが全機種おなじという
想像もつかない状態であることが発覚し（笑）たものの、
MACの設定方法がどこにあるか、とか、
そういう
当たり前のドキュメントさえ、どこにあるか判然としないのはいかがなモノか。
ま、会場に来ていた数名の猛者が分業しながら解決したものの
自分一人だったら、あきらめてる（苦笑
というか、これをもって、お客さんのところでデバッグなんてようしません、私。

で、幸か不幸か、オープンソースになったようで、ますますドキュメント整備が
おくれてくるんやろうなぁ、と。

せめて、日本語でサポートされるコミュニティが富士通エレくらいが立ち上げてくれると
ちょっとやってみようかなぁ、となるのに。

ET2012 雑感

あ～、今年も一足飛びに冬になりつつありますね。

急激に寒くなったので、ことしも紅葉はどうかな～？的なイメージだったのですが

杞憂だったようです。

というのも、この日曜日に、滋賀県の永源寺にいってきたんですが、

こりゃもう、見事な紅葉！

携帯のダメダメ写真でもこれくらいはとれてしまったくらいですから。
ちょっと肌寒かったのと、小雨がぱらぱらと来てたのはご愛敬、というところでしょうか。
ず～～っと以前に来たことがあるはずなのに、イメージと全くかぶらなかったのは
自分が歳をとったからなのかもしれません(；＾ω＾)


閑話休題。

さてさて、先日からお伝えしていたとおり、11月14～16日の３日間、
横浜みなとみらいにておこなわれていた、

組込み総合技術展 Embedded Technology 2012（以下、ET2012）

に、出展社として行ってきました。一般財団法人関西情報センター(KiiS) の

     「関西の組込みパワフル企業」

というところの出展社のうちの１つとしてですが

ご来場いただき、本当にありがとうございました！！

ですがさすがに、しんどかった！！！（笑


最終日には、社長も来てくれたので、なんとかちょっと楽にはなったけど
さすがに、終日立ちっぱなし、食事もロクにできない状態はやばかったかも。
しかも、連日飲まずくわずのあとでの、レセプション＆ＥＴフェスタ！！
酒がまわるまわる（笑
それでも、ネット周りの初対面の知り合いがたくさんきてくれたのでうれしかったですよ。
残念だったのは、hamayanさんにお会いできたのに、舞い上がってしまって
握手してもらうのわすれたこと（汗
ええ、ぼくにとっては、業界のＡＫＢですから(；＾ω＾)

今回は、ET WESTで出展した内容をブースサイズ用に調整して、ZigBee温度測定を
追加して、２台を独自動作できるようにチューニングするなど、結構手間がかかった
わりには、大差ないものに仕上がってしまいました orz
一応、コンセント電流や、電力積算値、エネループのバッテリー残量などをグラフで
表示できてますし、会場の温調がほとんど効いていないのも、目で見てわかっていただけた
（結果として（笑））展示になりました。

最終的なブース展開。 思ったよりスペースがなくて 急遽、モニタを縦置きに変更￥(^^)￥ これは結構目を引いたみたい 何でももっていっとくもんだわ

測定動作画面。これだけの情報をうめこむには タブレット端末では役不足になっちゃう。 でも、「タブレットじゃだめ？」って 数人に聞かれました。。。 だめじゃないってば！

こちらは出展物のアップ。 モニタ横のボックスは１４Ｖホームバッテリ。 車載用のシガレットソケット経由で 車載用インバータ（1000円くらい）をつなげば 家電のバックアップくらいはできます。

 展示ブース的にはＢ入り口からまっすぐ入ったところだったので
非常にわかりやすい場所で◎だったようにおもいます。
しかも、青基調のブースが多い中で、東北と同じ赤色！！これが目立つ！！
近隣にアジレント、サイプレス、ルネサスと、目指すブースがあったのもよかったのでしょうか。
完全に個人でだしちゃうと、ノベルティとか大変なんですが、
今回はKiiS自体が、高機能万歩計を用意していてくれたのでよかったです。

展示会でありながら、実際にはあんまりほっつきあるくことができなかったんですが、
それでも得てきたところは、次回にでも。

それでは！

Android初歩勉強会(GENET分会)

さる４月１４日、荒れ模様のなか、奈良県工業技術センターで、
有志によるAndroid初歩の勉強会を行いました。

メンバーはGENETコミュニティで知り合った有志６名での
本当に小さい規模の勉強会でした。

ほぼ個人教授に近い形での開催となり、結局Eclipse開発環境上で
ボタンやテキストビューをつかって表示をつくって、挙動を確認する、
というところ（初歩の入り口部分）までで、タイムアップとはなりましたが

お花見がてらのメンバー同士の「わいわい座談会＆昼食」も
盛り上がり、結構おもしろかったです。

一応、Androidのライフサイクルも含めて、ざっくりと説明もできたし
なにより、Eclipseのコード補完を使わないと！！というところの
確認ができました。

書籍で独学、となると、ここで躓く！というところがあるので
ゆっくり、相談しながらやっていく、というのは結構いいことなのかもしれませんね。

さて、次回の予定をたてないとね。
内容もここからグレードアップ！といきたいところですけどね。

ここらまでの内容を掘り下げて、直接ソフトコーディングに
はいるのもいいかもしれないんだけど、どうなるか、今後に期待、です。

僕的には早く、組込への融合、という部分にいってほしいんだけどね。

Androidで「ものづくり」 第3回

昨日、奈良県工業技術センターで行われた
Androidで「ものづくり」　 ～ものづくりシステムへのAndroid導入法～
の第3回、つまり最終回が終了しました。

１，２回がAndroidの組込ボードへのポーティングとＮＤＫによるドライバレベルの実装、
という観点からのテーマでＯＥＳＦのテキストに従って行われたのに対して
最終回である今回は、ふつ～にAndroidアプリを開発して、WifiのUDPダイアグラムで
自走模型をうごかしてみる、という内容。
つまり７月２９日に行われた、奈良高専主催のアンドロイドワークショップの焼き直し
版でした。
ワークショップのときは午前の２時間、ということで時間切れ続出だったのと
自分自身にもアンドロイドの経験値がほとんどなかったので、こういう小難しいものなのか～
という印象しかなかったんですが、さすがに３ヶ月も経過するとその間の経験値上昇分で
いろいろ見えてくるモノがありました。

ダメだしする気は毛頭無いけど、ちょっとサンプルがお粗末だったかなぁ、というのが
正直なところ。３～４ヶ月あったにも関わらず、ほとんどコーディングが見直されておらず
個人的な印象では
「こりゃダメじゃん」（あくまで個人的印象ですよ）
なところが盛りだくさん。

まず、基本的なところで、フォームにボタン貼り付けてそれぞれの
コードを記述する、という部分。
いろんな本をよんだり、話をしていて一般的なのは
１．onCreateのなかで
    button.setOnClickListener(
          new View.OnClickListener(){
                 public void onClick( View v ){
                      ......
                 }
          }
     }
    みたいに記述する。

２．アクティビティの先頭で、implements View.OnClickListener を記述して
    onCreate内部で、
           Button.setOnClickListener(this);
    を実装した上で
    public void onClick( View v) {
         if ( v.getId() == R.id.Button1 ){
              .....
         }
    }
    を記述する。

３．XMLの<Button　>のなかに、android:onClickで関数名を記述して
    アクティビティのコード内に直接関数記述する方法

の３種にほぼ集約されるとおもいます。
おそらく、これ以外の方法を公然となさっているパターンは少ないんじゃないかと。


で、今回の会ではこのいずれでもない状態で進んでしまいます（汗）
どうするかというと

メインのアクティビティのonCreateで
   Button.setOnClickListener( new XButtonListener() );
と記述した上で、当然、newしたリスナの実体がないので、
 　Create class
して、実体を別クラスに生成するという荒技をつかいます。
初期のうちはこれでもちゃんと動作しますし、ソースが分割されていく、
というのを是とすれば、別に問題なくうごきます。

ただ、このあと別の画面へのインテントやWiport模型への各種コマンド発行ボタン
を実装したときに徐々に破綻していきます。
別の画面で設定変更を行って、メインのイベントに内蔵された機構にアクセスする
ときにクラスが分かれており、その都度生成を繰り返すため、
すべてのソースに同じ記述を繰り返すほか、本来必要でないfinal 宣言までつけないと
ダメとか、もうハチャメチャ。

すべては、必要のない記述と新規クラス生成をおこなったことを追認しようとして
穴埋めした結果におもえてしまう。

うごけばいいや、的な発想で教えられてもこまるんだよなぁ。
ことに、高専の先生であることが最大にイタイ。

まあ、コードの設計によって、最終コードの品質がここまでかわるんだ！ってのが
実感できたのは収穫だったけど。


このあたりのことも含めて反省会なんかでコードレビューも含めて座談会なんかが
開かれたらおもしろいなぁ。


総括としては
１．前２回のポーティング作業で、NDKで開発するのは問題ないとしても
    デバッグ等が結構面倒で、必要最小限にとどめるべきじゃないか？というのが
    得られた感触。
    ＮＤＫつかえば、たしかに高速化やLinuxの技術がつかえるなどのメリットもあるかも
    しれないけど、新たなバグの入り込む余地が爆発的にふえるにも関わらず、
    十分なデバッグ手法があるようにも思えないのが、最大の理由。
    つまり、どうしてもＮＤＫをつかわないとダメか、という判断の上で決断すべきとおもう。
    機種（ＣＰＵ）依存という新たな足かせも発生するというデメリットもおおきくなり
    アンドロイドという汎用ＯＳをつかうメリットを失わせる危険もある

２．ＳＤＫによるアプリ開発のほうは、できるだけ標準的な手法に基づくほうが望ましい。
    特殊なやり方を推し進めようとすると、破綻する可能性が高い！