2013年10月7日月曜日

TWELiteのアプリ生成 備忘録

なんだか、結構バタバタしてる。

Digi InternationalXBeeをもっぱら使うことがおおいのだけど、
『最近話題?のTOCOS TWELiteでいかない?』とのお誘いをうけて
こいつをつかっていました。

TWE-Lite DIP(トワイライト・ディップ)


XBeeとの違いは、OpenRISCの32ビットマイコンが載ってて
自分に使いやすいようにプログラムしなおして使う、という部分でしょうか。
もちろん、そのままでも使えはしますが、便利じゃない(;^ω^) 

アンテナ感度的には、わりとよさげ。というか結構安定している。
XBeeだと、5,6mごとにガツッって感度が変化する領域があるけれど
それがないかんじ。

問題は、ファームウエアを自分で書き換えられるんだけど、
なかなかわかりにくいことかなぁ。

オリジナルのToCoNet(トコネット)のライブラリを組み込んだTWESDK
Eclipseベースで、Cドライブのルートに解凍するかぎりにおいては
そのままで使えるお手軽さ。
ただし、2013/9月号 SDKでは、改行コードがUNIXベースのLFだけと
CR+LFの混在になってたり、いろいろするし、肝心のEclipseの立ち上げが
異様に重い、という問題が、ぼくの環境では発生する、ということで、ちょっと
めげそうになってた。
後者に関しては、中の人の助言で、
を再導入するだけで、すっきりうごいたけれど。

ここらは、悩むひとがいるかもね。

で、標準アプリのApp_TweLiteを改造していったわけだけど、
全体の見通しがわるくて、イマイチわかりにくい。

というわけで、自分的に次回のための備忘録をば。

TOCOSのHPによれば、以下の図が示される。



で、Master.cに記述される内容はほぼこれを踏襲しているんだけど、
実イベントに関する記述は実際には、書かれていないのであんまり意味がなかったりする。

つまり大事なのは右側のフローで、スタート種別が2種類あるってことが重要なわけだったりする。

===============================================================================

[コールドスタート]                                        [ウォームスタート]
void cbAppColdStart()         void cbAppWarmStart()
vConfig_UnSetAll(); -----------------
vInitHardware(FALSE); vInitHardware(FALSE);
子機親機選別 -----------------
ToCoNet_vDebugInit();(UART設定) ToCoNet_vDebugInit();(UART設定)
ToCoNet_vDebugLevel(0); ToCoNet_vDebugLevel(0);             vProcessEvCoreSlp [ 子機スリープ利用 ]
    or
    vProcessEvCorePwr [ 親機/子機/中継 ]
ToCoNet_vMacStart(); ToCoNet_vMacStart();
ToCoNet_Event_Register_State_Machine() -----------------

===============================================================================

こんな感じでルーチンがわかれてて、要は、コールドスタートなら動作モードを
分別して、イベントとして
            vProcessEvCoreSlp [ 子機スリープ利用 ]
    vProcessEvCorePwr [ 親機/子機/中継 ]
のいずれかをセットされるので以降は、このいずれかだけを問題にすればよい、というわけだ。

本体関数としては  vProcessEvCore()もあるけれど、こいつは外形だけでとくに気にする
必要はないみたい。
実体関数である、これらのなかも、実はステート管理変数が

 pEv->eState== E_STATE_RUNNING:

となっている場合のみに注意すればよいみたい。
ここでは、転送条件を判定した上で、

sAppData.sIOData_now.i16TxCbId = i16TransmitIoData(bQuick);

とすることで、無線転送処理をおこなっている。

時間処理に関しては、
void cbToCoNet_vHwEvent(uint32 u32DeviceId, uint32 u32ItemBitmap) 
case E_AHI_DEVICE_TICK_TIMER: // 基準制御周期
case E_AHI_DEVICE_TIMER0:     // タイマー0制御周期

があり、ここで、自分に必要な時間処理をおいておけば、ぬるいが判定ができる。

ハードウエアの割り込み自体は

PUBLIC uint8 cbToCoNet_u8HwInt(uint32 u32DeviceId, uint32 u32ItemBitmap)

に記述する。

sAppData.sIOData_now.au8Input

が、すべての統括をしているようにはみえるんだけど、現状のアプリだと
DI4はうまくよめていない雰囲気だ。
まぁ、僕の場合は、

uint32 Bitmap = ~u32PortReadBitmap(); // IO入力部の取得( L = 1 / H = 0 )
if (( Bitmap&0x0010000 )==0)) {
return i16Ret;
}

のように記述することで、DI4の状態をみたので事なきをえてるけど。
これについてはコールドスタート時に

uint32 Bitmap = ~u32PortReadBitmap(); // IO入力部の取得( L = 1 / H = 0 )
vfPrintf(&sSerStream, "!INF DIO --> %021b"LB,  Bitmap);

という表示ルーチンを適宜挿入しておいて、状態変化を観測して、確認した。
ファーム自体が、本当にうまくうごいているのか?それとも自分の書き方がわるいのか
を確認する術がないのが、微妙にイラっとする。

ま、デバッガがないのはちょっとな~~となってしまう。
ここらは外部デバイスに特化したXBeeのほうが扱いやすいな、とおもう点ではある。
だって、手慣れた環境で、扱えるからね。

手慣れた、といえば、Eclipseも、人のコードをアチコチ参照しながら読んでいくには
かなり扱いにくい、と感じる。
自分のソースだと、なにがどこにどんな形で定義されているのかは、自分がよくしってるんだけど
さすがに探しながら、となると、検索一つとってみても、なかなか。

というわけで、VisualC++ 2010Expressのプロジェクトをつくって、ソースコード編集が
できるようにしてみた。

さすがにすごくつかいやすい。

ソリューションを一つ用意して、自分のアプリのコード(*.cと*.h)を登録。
プロジェクトのプロパティで、Includeパス設定を行って、下記を登録。


C:\TWESDK\Wks_ToCoNet\MyApp_TweLite\Master\Source
C:\TWESDK\Wks_libToCoNet\libToCoNet\include\ToCoNet
C:\TWESDK\Wks_libToCoNet\libToCoNet\include\ToCoNetUtils
C:\TWESDK\Wks_libToCoNet\libToCoNet\include\ToCoNetUtils\AES
C:\TWESDK\Wks_libToCoNet\libToCoNet\include\ToCoNetUtils\fixmath
C:\TWESDK\Wks_ToCoNet\MyApp_TweLite\Common\Source
C:\TWESDK\514x\Components\HardwareApi
C:\TWESDK\514x\Components\Common\Include
C:\TWESDK\514x\Components\HardwareApi\Include

.vcxprojファイルのIncludePath指定をエディタで書き換えてもOK。

<IncludePath>C:\TWESDK\Wks_ToCoNet\MyApp_TweLite\Master\Source;C:\TWESDK\Wks_libToCoNet\libToCoNet\include\ToCoNet;C:\TWESDK\Wks_libToCoNet\libToCoNet\include\ToCoNetUtils;C:\TWESDK\Wks_libToCoNet\libToCoNet\include\ToCoNetUtils\AES;C:\TWESDK\Wks_libToCoNet\libToCoNet\include\ToCoNetUtils\fixmath;C:\TWESDK\Wks_ToCoNet\MyApp_TweLite\Common\Source;C:\TWESDK\514x\Components\HardwareApi;C:\TWESDK\514x\Components\Common\Include;C:\TWESDK\514x\Components\HardwareApi\Include;$(IncludePath)</IncludePath>

これで、コード補完が効くので、解析するにはすごく便利になる。

ま、でたばっかりのデバイスなので、行き届かない部分がかなりあるけど
おもしろいのも事実。
もっとドキュメントをわかりやすくかいてくれるとありがたいな~とか、
おもったりしています。

というわけで、今後も期待していたりして。


PS.
TWELite-DIPの話題ついでに、汎用書き込み基板TWE-Lite R(トワイライター)について。
これ、かなりイケテル。
単体書き込み器としてもいいけれど、USBシリアル変換つき基板として
TWE-LiteDIPにはそのまま使いたい気分のボード。

ただ、この基板に TWE-LiteDIP をのっけた場合、若干の不都合が生じるのに注意が必要だった。

TWE-Lite R をUSBにつながずにいると、外部電源で駆動させていてもTWE-LiteDIPがうごかない。
いろいろしらべていくとTWE-LiteDIPのリセットピンにFT232のCBUSがつなげられており、
FT232が機能していない状態ではこのピンがLに保持されており、リセットが解除されない。

というわけで、実動回路にもこの基板を流用する場合には、TWE-Lite Rに実装されている
ダイオード D1 を外してしまうことで、利用できるようになる。
副作用として、自動の書き込みはできなくなるけれど、これについてはPROG+RSTボタンの
押し下げで対応できるので、問題ない。
ジャンパくらい、つけといてほしかったなぁ、というのが正直な感想。
ま、こういうこともあるよね。








0 件のコメント:

コメントを投稿