ラベル TOCOS の投稿を表示しています。 すべての投稿を表示
ラベル TOCOS の投稿を表示しています。 すべての投稿を表示

2013年12月26日木曜日

LPC800MAX & 来年も。。。

あ~、怒濤の1年でした。。。

ことしもいろいろあったなぁ。
GR-KURUMIのキックオフでがじぇるねに参加したり、
mbed 大阪ミーティングに参加したりと、例年になくいろんなところに
首を突っ込みました(笑

それに、無線系がXBee一辺倒だったのが TOCOSのTWE-Liteが出てきて
すこし楽しめるようになったとか、

TOCOSのほうも不細工?(笑 な ユニットだけじゃなくて、
トコステなるものも出てきて、俄然イケテル感がでてくればいいなぁ、
とかおもってたりします。

ToCoStick(トコスティック)
秋月でも扱いがはじまってますね。

欲をいえば、とりあえずUART-to-無線 のサンプルが
もっとわかりやすくサンプル化してもらえるとうれしかったり。
実際につかってみて、これでいろいろする、というより
やっぱりXBeeみたいにつかいたい!ってほうが多いとおもうんだけどね。


あと、やっと仕事周りでも、PSoC3/5がつかえるようになったとか、
ちょっとづつウチの会社らしいものができるようになってきたかなぁ
という感じになりつつあります。
CQ出版からARM PSoCで作るMyスペシャル・マイコンという
PSoC5LP付き書籍がでたのも大きいね。
ただ、このボードせっかくVDDIOが切り替えられるのに
3.3Vに固定されてるのがもったいない。
そういう意味では、ITショップ えとせとら の PSoC3ボードみたいに
ちゃんと設計してほしかったなぁ、とか思わないではないけどね。

設計まわりでいうと、回路図に関しては、長らくつかってきた
D2CADからDesignSparkPCBに移行しようと画策中なんだけど
やっと時間ができて、ごそごそしてる最中です。
このあたりは年明けにでもちょっと書いてみようかなぁ。
だれか、勉強会やろ~~

そうそう、プログラマとして必須なTEXT Editorも更新してみた。
こんだけ開発環境ごとにS-JISとUTF8が混在してくると
イラっとすることも多くなってたので、緊急課題だったんだけど
1.Grep検索&タグジャンプがイケテル!
2.矩形コピペがカンタン!
3.置換で正規表現ライクにちょろちょろできる
4.1ファイルを分割表現できる(スプリットエディット)
ってのが充足されてるエディタがほしい。
いろいろつかってみたけど、たろサさん()から紹介してもらった
Programmer's Notepadがこれらを全部充足してて、即乗り換えてみた。

イケテル。たしかにいけてるわ\(^o^)/
こんな感じで、スプリット表示できるし。




















ただ、日本語表示には若干の難もあるかんじではあるけれど。
FixedSysとかにすれば日本語も普通に表示編集できるんだけど
たとえば





みたいにカーソルカレットがあるところだけ化けるんだよね。
まあ、フォントがこわれてるだけで、動かすともどるので
実害らしきものはないけれど、結構おどろく。
まぁソフト作成に限って言えば、問題ない範囲かなぁ。


閑話休題。

年末も押し迫って、NXPのキャンペーンでLPC800MAXボードが当たった\(^o^)/



LPC800シリーズだけでもおもしろいのに(だってスイッチマトリクスでIO自由自在だし)
LPC11U35でmbed化が既に完了。
しかも外部にADC/DACチップをのっけて、IOエキスパンダものっけてと大判振る舞い(笑

ちょっと何かしたくなるボードだなぁと。

Arduinoのフォームファクタなので、ナニにつかえるのか、ちょっと考えてみてるとこです。

これとPSoC5でごそごそ作ったものをルネサスナイトに持ち込んで。。。とか
訳わからん妄想を、、、な今日この頃です(笑



というわけで、みなさんも、よいお年をお迎えください。





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ボタンの
押し下げで対応できるので、問題ない。
ジャンパくらい、つけといてほしかったなぁ、というのが正直な感想。
ま、こういうこともあるよね。