.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に出展しますぅ～！ ＆ その他近況報告

なんだか、急に冷え込んできましたね。
まだ、１１月にもなってないのに(；＾ω＾)

さてさて、またも放置プレイ状態になってました。申し訳ない。

その間にもGENETつながりで、
組込デバイス勉強会 ＃３
画像処理分科会　＃２、
GENETコミュニティ例会　＃６
と、
結構いろいろあったんですね。


組込デバイス勉強会 ＃３は、９／２９に奈良県工業技術センターで行いました。
ず～っとアンドロイドばっかりやってるんですが、さすがに１ヶ月以上開けて
開催してるんで、最初のほうは、プロジェクトの作り方初歩、ってところから
やるわけですど（笑
それまでの2回で、概ねボタンやパーツなどの画面作成とイベント処理の
基礎はできたので、今回の第3回では、スレッドモデルの作成を集中的に
やりました。

Androidの基礎本なんかでは、ちら～～としか触れてないんだけど、
外部との通信など、組込では必須の機能なので、避けて通れないので
まとめてみました。

最初はThreadのつくりかたとか、同期のための、Handlerとか。
で、面倒くさい感をしっかり味わっていただいて（笑
AsyncTaskで、すっきり感をご賞味いただく、という２段構成に。
それなりに準備と説明が大変だったんですが、概ねわかってもらえたようで
なにより。

次回くらいからはテキストを徐々に離れて、マイコンなど外部デバイス通信に
入っていこうかな？ってところでしょうか。
まあ、そのまえにインテントを説明しないとダメッぽいので、現実的には
その次になるかもしれないけれど。
まあ、このあたりは理解度を深めながら、ゆっくり進めていこうかなと。


画像処理分科会 ＃２のほうは、１０／２５に。
いきなり、「画像の特徴量について調べてこい！」的ゼミ風になって
びっくりしたけど、僕的にはこういう場当たり方式のほうが、ガッチリ座学よりも
性に合ってるかも、と再認識。
たぶん、テクノスの利弘さんもたぶん、そのほうが楽？なんだろうなぁ、と。
だって、急な質問に対するドキドキ感、すきそうやもんね。
金魚認識の案件という、話題もでておもしろかったですよ。
実際、これの実現のために、こっちの勉強会とのコラボ企画があっても
おもしろいな、と。


GENETコミュニティー例会 ＃６は、１０／２９にクリエイションコア東大阪で
開催されました。
まあ、発表はそれなり（笑）。 それよりも富士通さんが３人も！来られてて、
懇親会のほうは非常におもしろかったです！
ＦＭ３の販促目的だとはおもうんですが、僕の
『開発環境やデバッガの無償版とか評価版がないのはダメだよね』
とかのダメ出しにもにこやかに対応してもらえたのは好印象。
実際ＡＲＭに手を出さない最大の理由はデバッガを含む開発環境に
異様にお金がかかることだし。
８ＫＢや１６ＫＢでナニをつくれっていうんだろう？
まあ、これについては言外に対応を臭わせてくれたんで、
期待してまとうかな？という気分にはさせてもらえたし。
実際、ARMで５Ｖ対応品ってなると、極端に減ってしまうし。
ある意味期待はしてるんだけどね。

閑話休題。

来る、１１／１４～１６の３日間、横浜みなとみらいにて行われる

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

に、出展することになりました～！

といっても、単独出展ではなくて、

一般財団法人関西情報センター(KiiS) の

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

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

うちの会社も、ここに参加していまして

紹介ＰＤＦもあがっています。

ひょんなことからお声がけをいただいて、急遽出展がきまったので、

現在出展物の作成？と調整を続行中です。

さて、どんな展示になるか、乞うご期待？＼(^o^)／

ちなみに、ブースはＢ－５２です。みなさん、よろしければ、是非！お越しください！

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の技術がつかえるなどのメリットもあるかも
    しれないけど、新たなバグの入り込む余地が爆発的にふえるにも関わらず、
    十分なデバッグ手法があるようにも思えないのが、最大の理由。
    つまり、どうしてもＮＤＫをつかわないとダメか、という判断の上で決断すべきとおもう。
    機種（ＣＰＵ）依存という新たな足かせも発生するというデメリットもおおきくなり
    アンドロイドという汎用ＯＳをつかうメリットを失わせる危険もある

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