Digi InternationalのXBeeをもっぱら使うことがおおいのだけど、
『最近話題？のTOCOS TWELiteでいかない？』とのお誘いをうけて
こいつをつかっていました。
XBeeとの違いは、OpenRISCの32ビットマイコンが載ってて
自分に使いやすいようにプログラムしなおして使う、という部分でしょうか。
もちろん、そのままでも使えはしますが、便利じゃない(；＾ω＾)
アンテナ感度的には、わりとよさげ。というか結構安定している。
XBeeだと、５，６ｍごとにガツッって感度が変化する領域があるけれど
それがないかんじ。
問題は、ファームウエアを自分で書き換えられるんだけど、
なかなかわかりにくいことかなぁ。
オリジナルのToCoNet（トコネット）のライブラリを組み込んだTWESDKは
Eclipseベースで、Cドライブのルートに解凍するかぎりにおいては
そのままで使えるお手軽さ。
ただし、２０１３／９月号 ＳＤＫでは、改行コードがUNIXベースのLFだけと
CR+LFの混在になってたり、いろいろするし、肝心のEclipseの立ち上げが
異様に重い、という問題が、ぼくの環境では発生する、ということで、ちょっと
めげそうになってた。
後者に関しては、中の人の助言で、
Eclipse Pleiades All in One 4.2.2a CDT 32bit Full Edition
を再導入するだけで、すっきりうごいたけれど。
ここらは、悩むひとがいるかもね。
で、標準アプリのApp_TweLiteを改造していったわけだけど、
全体の見通しがわるくて、イマイチわかりにくい。
というわけで、自分的に次回のための備忘録をば。
TOCOSのHPによれば、以下の図が示される。
で、Master.cに記述される内容はほぼこれを踏襲しているんだけど、
実イベントに関する記述は実際には、書かれていないのであんまり意味がなかったりする。
つまり大事なのは右側のフローで、スタート種別が２種類あるってことが重要なわけだったりする。
===============================================================================
[コールドスタート] [ウォームスタート]
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指定をエディタで書き換えてもＯＫ。
<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(トワイライター)について。
これ、かなりイケテル。
単体書き込み器としてもいいけれど、ＵＳＢシリアル変換つき基板として
TWE-LiteDIPにはそのまま使いたい気分のボード。
ただ、この基板に TWE-LiteDIP をのっけた場合、若干の不都合が生じるのに注意が必要だった。
TWE-Lite R をUSBにつながずにいると、外部電源で駆動させていてもTWE-LiteDIPがうごかない。
いろいろしらべていくとTWE-LiteDIPのリセットピンにFT232のCBUSがつなげられており、
FT232が機能していない状態ではこのピンがＬに保持されており、リセットが解除されない。
というわけで、実動回路にもこの基板を流用する場合には、TWE-Lite Rに実装されている
ダイオード D1 を外してしまうことで、利用できるようになる。
副作用として、自動の書き込みはできなくなるけれど、これについてはPROG+RSTボタンの
押し下げで対応できるので、問題ない。
ジャンパくらい、つけといてほしかったなぁ、というのが正直な感想。
ま、こういうこともあるよね。
0 件のコメント:
コメントを投稿