お久しぶり です (Serial Debug Tool3 の開発について)

 お久しぶりです💦
最後の投稿が2019年末だったので、5年も放置状態だったのね。

2020年初に高熱、収束後は1月末まで失声（ほぼ発声できなかった💦）というのもあって、なんとなくこういうのからは遠ざかってました。。。
当時まだコロナってのが一般的ではなくて、医者からも『いつものアレルギー』っていわれたけれど、全くアレルギー薬が効かなかったし、突然の高熱と眩暈で立てなくなるなんて初めての経験。たぶんコロナだったんだろうなぁ（旅行先で外人さんに囲まれてたし💦）

閑話休題。

さて、仕事もイロイロしているけれど、マイコン系は少ないねぇ。
それでも、結構しているほうだけど。

ＰＣだと、従来のUSB-UARTをつかったシリアルポート制御なんてあたりまえにあるけれど、

加えて、GPIB、UDP、TCPでのデータ通信も増えてきた印象。
やっと次に移行するかんじなのかなぁ。。。

ということで、まいど、いろいろ専用ツールをつくって対応してきたんだけど、めんどくさいので、デバッグツールを再開発した(笑)
拙作シリアルデバッグツール２をベースにしようとおもったけれど、すでにEmbacadero C++ Builderなんて使いたくないし💦、新たにC#で作成。

いまどきなので、ついでに、UDP/TCP でも同様にできるように拡張してみた。
通信で電文の送受信する、というのは共通なので、個別の送受信ルーチンの仕様を共通化してゴゾゴソ。

しかし、Ｃ＃って偉大(笑)
Ｃ＋＋だと送信電文解析のところ、つくるだけで結構大変だったんだけど、
普通に 正規表現 とか使えるもんだから見通しスッキリだし、ThreadPoolとかちょいちょいって書けるし。

仕事ツールとしてはこれくらいできてると、そこそこ使えるかな～

今回、TCP/IPでの通信ができるようになったので、

『HTMLのアクセスってほんまはどうなん？？』
みたいなのを試してみた(笑)
SerialDebugTool3で、
TCP/IP Server Mode  Port:80
で待ち受けして、
ブラウザ側から、アドレスバーに
『localhost』
で接続開始。

あとは所定のデータをずらら～～っと入れれば

Webページが順次表示されるという、なんともわかりやすいのが確認できる(笑)
サンプルとして testResponse.txt というのを同梱しているので、
送信リスト画面から、送信してみて(笑)

現在、Vector での掲載待ちで、約2週間かかったorz
今日、新たにR1.00.2をアップしたので、来週水曜には更新されるかと。。。
シリアルデバッグツール3 (Vector紹介ページ)

ＭＤＲ がらくた置き場(笑) のほうには順次最新版をアップしていきます。
できれば、Vectorのほうからダウンロードしてもらえると、ダウンロード数がわかってうれしいけれど、ま、これも時代ってことでしかたないかなぁ💦
とりあえず、窓の杜のほうにも申請しておくかなぁ💦

 

ps.

エゴサもしてみるもんね(笑)
 ザツメモブログ さんが昨年、記事を書いててくれた模様。
ありがとうございます！(*^▽^*)

つねづね思ふこと にも(笑)
こちらは 2015年だからちょっと古いけれど。

PSoC5LP で いまさら mruby/c を試してみる その３ (お試し編) (PSoC AdventCalendar2019)

さて。
PSoC Advent Calendar 2019 での ３つめですね。

mruby/c 2.0 でうごく、サンプルはできたので
いろいろできそうだけど。

で、ちょっと気になったのは最初によんだ
利用説明書
の記述。

内蔵デバイスをいろいろ、使えるようにしてくれてるん
だろうなぁ、とか思いつつ、 読み進めていったんだけど

こういう記述があつまってるところはないかしら？

まぁ、
mutex、sleep()、relinquish()
があればタスク管理上はほぼ問題なくなるだろうし
いいんだけれど。
mruby/c で
『あれ、どう記述したらいいんだろう？？？』
ってのに対応できる資料がないのはイタイからね。


で、微妙に気になったのが、UARTについての記述。










PSoC5だと UDBの分だけ、 UARTつかえるよ！っていうのは
いいとして、PSoC5LP PrototypingKit の UART部は
KitProg2(デバッガ部)のPSoCに直結されて
PCからは、USB-CDC そのものだから、本来は
デバッグ出力用の　hal_write()  のほうに割り付けて
しまうほうがうれしいとおもんだけどなぁ。
まぁ、uartクラス的に書くのかは勉強になる。
ただ、気になるのは、
『PSoC5LP開発環境の仕様により、ボーレートの変更がソフトウェアでできません。
   標準で、19200bps固定です。』
っていう記述。

うっそーん！  できるよ、あたりまえじゃん！
これは
PSoCのこと、わかってないんじゃないの？
ってタイミングでかかれたんだろうなぁ。

たしかに、PSoC の UARTコンポーネントでは
速度を指定するAPIは生成されないですね。
ただ、できないわけではないよ。

2017年版の Advent Calendarでも 書いたので
詳細は そちらを参照してもらえばいいけれど、
要は、UARTも基準となっている、IMOのクロックに
同期してうごいているので、これを正しい分周比に
かえてやれば、好きな周波数なんて簡単に設定できますよ、
ってことですね。

=========

	#include <stdint.h>
	void setBitRate(uint32_t rate)
	{
	uint16_t div;
	div = (uint16_t)((uint32_t)BCLK__BUS_CLK__HZ / (uint32_t)((uint32_t)rate * 8)) ;
	UART_1_Stop();
	UART_1_IntClock_SetDividerRegister(div, 1); // 設定変更＋リスタート
	UART_1_Start();
	}

view raw setBitRate hosted with ❤ by GitHub

=========
こんなかんじですかね。

PSoC Creater で生成したプロジェクトを利用すると
利用するマスタークロックは  cyfitter.h というファイルに

BCLK__BUS_CLK__HZ


として定義されています。

IMO を 48MHz で定義した プロジェクト の場合であれば

#define BCLK__BUS_CLK__HZ 48000000U
ですね。
欲しい速度（bitrate）を ８倍することで Byte/Secの単位とし
それを分周比として
UART_1_IntClock_SetDividerRegister()
という関数に引き渡してやればいいだけですね。

問題は、与える分周比をどうやって算出するのか、 だけど
たとえば 115200bps がほしいのなら
  115200bps = 115.2kHz
で、１バイト分のサンプリング =　８倍 が欲しい周波数なわけです。

サンプリングを８倍した 921.6kHz が与えられれば、いいわけです。
ここまでくれば簡単で、
この921.6kHzを生成するのに、48MHzを52分周すると
近似として  923.076kHz 得られるじゃない？ってことですね。

式にすると
 52 = 48000000 / (115200 * 8)
ですね。

というわけで、この関数をmruby/c から呼べるように
用意すればいいだけです。

=========

	// 通信速度設定
	static void c_setBitRate(mrb_vm *vm, mrb_value *v, int argc)
	{
	uint32_t rate = GET_INT_ARG(1);
	setBitRate(rate);
	}
	// 通信速度設定本体
	void setBitRate(uint32_t rate)
	{
	uint16 div;
	div = (uint16_t)((uint32_t)BCLK__BUS_CLK__HZ / (uint32_t)((uint32_t)rate * 8)) ;
	hal_uart_Stop();
	hal_uart_IntClock_SetDividerRegister(div, 1); // 設定変更＋リスタート
	hal_uart_Start();
	}
	int main(void)
	{
	CyGlobalIntEnable; /* Enable global interrupts. */
	hal_uart_Start();
	/* Place your initialization/startup code here (e.g. MyInst_Start()) */
	mrbc_init(memory_pool, MEMORY_SIZE);
	isr_mrbcTick_StartEx(mrbcTick); // SYSTICKを実装
	mrbc_define_method(0, mrbc_class_object, "sw1_read", c_sw1_read);
	mrbc_define_method(0, mrbc_class_object, "led1_write", c_led1_write);
	mrbc_define_method(0, mrbc_class_object, "setBitRate", c_setBitRate);
	mrbc_create_task( sample1, 0 );
	console_print("\r\n\x1b(B\x1b)B\x1b[2JStart Program.\n");
	mrbc_run();
	return 0;
	}

view raw mrubyc_setBitrate hosted with ❤ by GitHub

=========
c_setBitRate関数が 実際にmrubyから呼び出しされる
関数ですね。

このプログラムでは UARTを
hal_uart
というコンポーネント名で登録したので、上記のように
なっています。
mruby から
setBitRate( 115200 )
みたいによべばいいですね。

=====================================
いろいろつかってみると、結局のところ
デバッグができるのが、PSoC 版のいいところ
なのかも。

肝心のmrubyでは、デバッグできないもん。
実際、前回のように、
いま、なぜ動かないのか？
を確認できないのはつらい。

じゃ、結局『ぜんぶCでかきゃ、いいじゃん！』ってなりそうなものだけど、
マルチタスク的にコンパクトにいろいろやりたいとなると
案外Cだと骨が折れるんですよ。
基本になる挙動は、 Cで関数単位で記述しておいて
タスク起動と同期を mruby で制御、ってのが
もっともお手軽なのかもしれません。
実装サイズがコンパクトなRTOS的につかう！
のが最適なのか、とおもいますね。

さて、ちょっとmruby の文法、勉強しないと。。。

PSoC5LP で いまさら mruby/c を試してみる その２ (テスト編) (PSoC AdventCalendar2019)

前回、見事に撃沈したので、リベンジ に勤しんでみる。

要は、mruby/c もわからんのに、IDEをつかうのがまずい？
ってのがあるので、本筋に従って、きちんとすすめてみるのが吉なのだね。
そもそも、ほかのマイコンと違って、ペリフェラルが可変のPSoCでは
PSoC Createrから切り離して、どうやってIDEするつもりだったのか
よくわからないって段階で、踏み込む必要がなかったわけだ。

先日の Embedded Technology 2019 で、某きむしゅさんから
rubyへの『愛がたらない』と言われたしなぁ（笑

てわけで、環境を構築してみる。

mruby/c チュートリアル
https://www.s-itoc.jp/activity/research/mrubyc/mrubyc_tutorial/

田中せんせのQiita
https://qiita.com/kazuaki_tanaka/items/daff64b84c4108a6dfc3

という二つのコースがあるけれど、田中せんせのやつは、
あとからみればしっくりくるけれど、最初にやると？？？となりそうなので
チュートリアルの１と２を、取り纏めながら進める。

PSoC Createrで PSoC5LPを選んで作り始める。
 後々のために
-----
Project > Build Settings にて
ARM GCC -> Compiler -> General     Use newlib-nano Float Formatting = True
にして実数利用を許容dwrのSystemタブで   HeapSizeを0x400に拡張   
-----
しておきます。
回路図入力で、Clockを1kHz で interrupt として取り出しておきます。
システムのTickとして利用するので、isr_mrbcTickと命名しました。

SouceFiles のところに
src
フォルダを追加しておく。

ファイルマネージャでソースファイルのフォルダに
mrubyc-release2.0 の srcフォルダをそのままコピーする。

フォルダ構成はこんなかんじですね。
-----

├─src
│ ├─hal_org
│ └─hal
└─TopDesign

-----

src フォルダ内の hal フォルダを hal_org にリネームして
hal_psoc5lp  を  hal  にリネームする


PSoC Creator に追加作成した  srcフォルダを選択したうえで
右クリックで、Add > Existing Item を選びます。

さきほど、コピーした srcフォルダ内のファイルをすべて追加します。


これで、準備完了ですね。

https://www.s-itoc.jp/activity/research/mrubyc/mrubyc_tutorial/735
に記載されている、mrubyc のサンプル をそのままつかいます。

	led = 0
	while true
	if led == 1
	led = 0
	else
	led = 1
	end
	if sw1_read() == 0
	led = 1
	end
	led1_write( led )
	sleep 1
	end

view raw mruby_sample1 hosted with ❤ by GitHub

このコードを sample1.rb という名前で、
main.cのあるフォルダにコピーしておきます。
ついでに、mrbc.exe も ここにコピーしておきましょうか。
      （ここでmruby IDEのなかのmrbc.exeをつかって悲劇を呼ぶのだが。。。）
cmdプロンプトから

mrbc.exe -E -Bsample1 sample1.rb

とすれば、　main.c とおなじフォルダに
sample1.c
が生成されます。
試しに sample1.c をエディタで開いてみると

こんなかんじになります。
どうやら、mrbc は mrubyのソースコードを バイナリの配列に入れてくれる
プログラムってわけですね。
試しに
mrbc.exe -E -Barry sample1.rb
とすると、 sample1.rb の中の配列名が
arry[] =
となることから
mrbcでの 　引数 -Bの後の文字列が配列名であることはわかりますね。


で、PSoCのサンプルソースコードはこんなかんじになります。
躓き処が満載ではあるんだけど、いまはこれが全容かな。
    mrbc_create_task( sample1, 0 );
の行で、タスクとなるmrubyコードが呼ばれるのはわかりますねぇ。

--------

	#include "project.h"
	#include "./src/mrubyc.h"
	#include "sample1.c" // mruby/c サンプルバイナリ
	#define MEMORY_SIZE (1024*30)
	static uint8_t memory_pool[MEMORY_SIZE];
	//================================================================
	// オンボードSW 現在状態の読み込み
	static void c_sw1_read(mrb_vm *vm, mrb_value *v, int argc)
	{
	int sw1 = SW1_Read();
	SET_INT_RETURN(sw1);
	}
	//================================================================
	// オンボードLED ON/OFF
	static void c_led1_write(mrb_vm *vm, mrb_value *v, int argc)
	{
	LED1_Write(GET_INT_ARG(1));
	}
	//================================================================
	int hal_write(int fd, const void *buf, int nbytes)
	{
	return 0;
	}
	int hal_flush(int fd)
	{
	return 0;
	}
	CY_ISR(mrbcTick)
	{
	mrbc_tick();
	}
	int main(void)
	{
	CyGlobalIntEnable; /* Enable global interrupts. */
	/* Place your initialization/startup code here (e.g. MyInst_Start()) */
	mrbc_init(memory_pool, MEMORY_SIZE);
	isr_mrbcTick_StartEx(mrbcTick); // SYSTICKを実装
	mrbc_define_method(0, mrbc_class_object, "sw1_read", c_sw1_read);
	mrbc_define_method(0, mrbc_class_object, "led1_write", c_led1_write);
	mrbc_create_task( sample1, 0 );
	mrbc_run();
	return 0;
	}

view raw mrubyc_test1 hosted with ❤ by GitHub

--------

なんとなく、全容がみえてきた(≧▽≦)

さて、ここから、いろいろやってみましょうか。
mruby自体のデバッグってどうやるのか、とおもったら
PSoC Createrのデバッグ機能がつかえるから、
mrubyはタスクスイッチャとしてつかうのなら
おおむねデバッグはできそう。

さて、で、実際デバッグ実行してみると、うごかない。。。

はぁ？

ブレイクかけながら追いかけてみると、関数がよばれず、
そもそも mruby コードがうごいていない？疑惑浮上。。。
適当にブレイクかけながら試していると

class.c の mrbc_load_mrb関数内で  mrubyのバイナリチェックを行う

  static int load_header(struct VM *vm, const uint8_t **pos)

という関数がエラーを返している。

  if( memcmp(p, "RITE0006", 8) != 0 ) {

となっていて、mrubyのバイナリバージョンが 0006 であることを
想定しているけれど、
今回得られてる、sample1[] の内容は
0x52,0x49,0x54,0x45,0x30,0x30,0x30,0x34　= RITE0004
だから、はねられてる、ってとこかな。

は！ そうか！ mrbc コンパイラが生成するバイナリ自体もちがうのか。

そんなんしらんがな。

なるほど、サイトをよくみると、

mruby Stable版v2.0.1 Windows版（コンパイル済バイナリ）
「mrubyコンパイラ2.0」（ZIP：1.5MB）

が必要なのね。

これで、再度mrbcかけて、再コンパイルしたら、うごいた！
Ｌチカ！ 完了。 

ううむ。そういうことなら、気色わるいので
mrbcフォルダをつくって、そのなかに、mruby Stable版v2.0.1一式を解凍して
mrbc.bat だけを、ソースフォルダのなかに置いた。
フォルダが変わったので、このbatファイルの中で

set MRBC=.\mrbc\mrbc.exe

に変更したけれど。

これで、コマンドプロンプトから
mrbc
ってやるだけで、rbファイルが一括コンパイルできるようになったよ。

しかし！。

まぁ、もうちょっと、わかりやすく手順を説明してほしいなぁ。サイトも統一感なさすぎる。


なるほど、こりゃ流行らんよねぇ。。。



<つづく>

PSoC5LP で いまさら mruby/c を試してみる その１ (失敗編) (PSoC AdventCalendar2019)

あー、さぼり気味なのにもほどがあるな（笑
最終書き込みから２年とは。。。

ほんとうは、昨年のAdventCalender 2018での記事の予定だったんだが
多忙になったのにかまけて、お蔵入りになった。

というわけで、１年越しのリベンジということで。。。(≧▽≦)
詳しくは
PSoC Advent Calendar 2019
をみてね
ではさっそく。

私的には、
  BASIC -> Pascal ->C/C++ -> C# -> Python
といろんなのをやってきたわけだけど、 Web系では ruby と PHP が競っていたときに
PHPに行ったわけですよ。
で、 ruby  、なんだか小難しいなぁ、とおもっているうちに、マイコン用に
mruby 登場！となった経緯は知ってはいたし、ちょろっとかじったりもしたけれど
言語の資料もほぼないし、情報もないし、ってのが続いていて今に至るわけです。

毎年恒例の 横浜で行われる、Embedded Techology 展で
ruby フォーラム の 面々から、脅迫？めいた勧誘に耐え兼ねて、
ちょっとやってみようかと。
ちょうど、島根の田中先生が、 PSoC5でうごく、mruby/c というのを
開発したところだったので、いいタイミングかな～と思ったわけです。

ruby はよく知らないけれど、
mruby は
『マイコンでも動くように機能を絞ったバージョン』
ということです。（しらんけど

じゃ、
mruby/c って なに？
というのは、実はよくわからない。
まぁ、誤解をおそれずにいえば、

1)インタープリタな部分を排除、rubyVMだけにして、コンパクトな実行サイズにする
2)rubyコードは予めPC上でバイナリにしておいて、VMにこのバイナリを食わせる
3)食わせる部分は、ターゲットマイコンのC/C++で記述

ということかな。

ということで、まずは、お手軽？らしく見える、IDEから、ちょろっと遊んでみよう。


しまねソフト研究開発センターのHPに mruby/c が纏めてある。

トップからは分かりにくいが
トップ / 活動内容 / 研究活動
という中に存在する。
できれば、トップにmruby/cのバナーがあるんだから
そこにリンクくらい張ってくれてもよさそうなものなのに（笑

まずはダウンロードページで、それらしいのを全部手元に取っておく。

おお～、

利用説明書

ってのがあるじゃん。
mruby/c IDEなるものがあれば、簡単じゃね？

最初のとっつきにはよさそうなので、まずはこれに沿って、やってみる。

ふむふむ。IDEから mrbc.exe と mrbwrite.exe を指定するのね。
よくわからんけど、一応、フォルダ内に同名ファイルがあるから登録してみる。

適当に読み進めていくと
デバグ用コンソールの起動（任意）
基板左サイドのUSB端子から、デバッグ用メッセージが表示されますので、開発時は接続しておくと便利です。
任意のターミナルソフトを利用して、ボーレート57600bpsで接続します。』

へ？  PSoC5の USBポートだよね？
USB-CDC だし、PC側の通信速度、ってなんでもよくね？    ( ,,`･ω･´)ﾝﾝﾝ？

てか、そもそもファーム、どれ？

ということで、この方法は一番にひらいちゃダメなところだったようだ。。。

mruby/cとは というリンクの中にある、田中せんせのQiitaをベースに
やってみないとダメなようだ。
よくみると、
チュートリアル
というページも、概ね同内容？的。
ふむふむ。そういうことか。
でも
初心者がどこから入ればいいのか、迷うのはいただけないよねぇ。。。orz

というわけで、別の方法を試してみる。。。orz 


＜つづく＞

PSoC5LP で USB-HIDデバイスでもしてみるか。。。( PSoC Advent Calender2017 )

PSoC Advent Calender 2017 の 記事の２こめです。

PSoC5LPにはUSB がついています。
これ、案外USB UARTくらいしかつかっていないんですが
普通にHIDデバイスとしても作ることができます。

今回はMouseにしてみます。
といっても、マウスなら、ちゃんとサンプルが用意されているんですよね。

スケマティックにUSBFSを配置して、右クリックメニューから出る
Find Code Example ...
を実行します。

すでにUSBFSが選ばれているので、関連するものがでてますね。
今回はとりあえず
USBFS_HID
を選択します。

3-Button mouseって書いてあるので、大丈夫そうですね。
よければ、Create Project を押します。

ん！エラー？ はぁ？？？
このメッセージわかりにくいよね。まったく。
要はこれは
『そのままではインポートされていないので、Webからとってきてね！』
というメッセージ。じゃ、どうするの？ってなるんだけど、
左はしの地球のアイコンをクリックすると、勝手にダウンロードされてくるので
そのままプロジェクトをつくります。

できたプロジェクトはデバイスが PSoC3になっているので
利用するPSoC5の型番に変更します。
PrototypingKitでは、CY8C5888LTI-LP097ですね。

WorkSpace Explorerの Project部で右クリックして
Device Selecter
を出し、ここで選択しなおします。

 できたら、ビルドします。
 スケマティックをみても、USBFSしか配置されていないので、基本は
これでエラーもでないはずです。
自動でピン配置もUSBピンはセレクトされているはずなので
大丈夫なはず。

添付のPDFの最後のところに
================================
Expected Results
You should see that the device is recognized as a 3-button mouse. The mouse is continuously moving back and forth horizontally.
================================
ってなっているので、マウスになってカーソルを水平移動でうごかすよ。
ってよめますね。

うごきましたか？
で、この設定、どこできまるんだ？ってことなんですが
一番わかりにくいのは HID Report Descriptersなんですよね。

なんじゃそら、と。

Device Class Definition for HID 1.11 (PDF)

を参照してみてください。
page81 (表題ページ番号71)にマウスの定義サンプルが挙げられています。

ね、このとおりの定義を書いてるだけですね。

あとは ３バイト用意して、一定のタイミングで
値をセットしておくりかえせばいいんですね。

このやりかたをしっておくと、JoyStickもキーボードもつくれますね！

Uartのボーレートチェンジを実装してみる( PSoC Advent Calender2017 )

とうとうこんな季節になってしまった。
いまだに炎上案件抱えてひーひーゆうてるのに。

PSoC Advent Calender 2017 の 記事を！って頼まれたのでそれをば。

さて、PSoC のUARTってコンポーネント、ポンっ！ってかんじで
いいので、とっても簡単なんですがね、ほかのマイコンなら
途中でボーレートチェンジ！なんて簡単にできるのに

この部分はAPIとしてはParityは公開されているけれど、
肝心の速度は公開されてないので、なんともならない。


きっかけは MonoWirelessのTWELiteの書き込みがPSoCからしたいよね！的な
ところから始まったんだけど。

 PC <--USB--> PSoC <--UART-->TWELite

っていう感じでつかって、モード変更で書き込み対応したいとか。


で、やってみた。

Design Wide Resources (.cydwr)をひらいて Clockタブを見てみる。

やっぱり、UART_1_IntClockを引き込んでいる。
今回は115200bps = 115.2kHzがほしい設定なので
サンプリングを８倍した 921.6kHzを生成してるわけですね。（最下行）
この921.6kHzを生成するのに、64MHzを69分周して近似の
927.536kHzを出してるというのはわかる。
ということなら

このDividerを変更したらよくね？
UART_1のコードの下に、UART_1_IntClock.cというのができてる。

このなかに SetDividerRegister()関数という、もうそのままのネーミングの
関数あるじゃんと。
これをよべばよさげですよね。

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

	void setBitRate(uint32 rate)
	{
	uint16 div;
	switch( rate ){
	case 57600: div = HS57600; break;
	case 38400: div = HS38400; break;
	case 19200: div = HS19200; break;
	case 9600: div = HS9600; break;
	case 115200:
	default:
	div = HS115200;
	break;
	}
	UART_1_Stop();
	UART_1_IntClock_SetDividerRegister(div, 1); // 設定変更＋リスタート
	UART_1_Start();
	}

view raw gistfile1.txt hosted with ❤ by GitHub

===================================
ぼくの場合だと
#define  HS115200    69
#define  HS57600    139
#define  HS38400    208
#define  HS19200    417
#define  HS9600     833
ってかんじですかね。
ここらは計算でする方法もあるし、あるていど決め打ちでもいいかも
ですね。
 64000(kHz) / (欲しい周波数(kHz) * 8) = divider
ってかんじですね。

TWELite-RED

久々に更新。

MonoWirelessのTWELiteに高出力版のREDが追加されました。

うちもいろいろと使っているので、
『どのくらい変化するんかな？』
というのが、気になるところ。

うちの場合、双方向でバリバリ通信したい！ってのは少なくて
デバイス側からデータをとにかく送りたい！的な用途なので
距離が伸びてくれるのはありがたいんだけど、
まだ、TWELiteのチップだけ、ってのは発売されてない。
とりあえず、TWELiteDIPでテストしてみた。

MonoStick-RED  <---- TWELiteDIP-RED 　　　　ざっくり50mくらい
MonoStick-RED  <---- TWELite(CHIP) + BLUE    ざっくり20mくらい

MonoStick-BLUE  <---- TWELite(CHIP) + BLUE    ざっくり15mくらい

という印象。
REDxREDの組み合わせで、おおお！ってなるくらい飛ぶのは
ある意味予測していたけれど、スティック側だけREDにしても5～６mは
距離が延びるのはちょっと意外。
しかも、RED自体の処理が安定している印象で、
BLUEだと離れるにしたがって受信がギコギコするような感じになるのに
REDだとほぼ安定状態が継続する、というかんじで、安心感がある。

すくなくとも、MonoStick側だけでもREDにする価値はありそう。

で、REDがラインナップに追加されたのにともない、
開発ツール類も TWESDKからMWSDKに変更になっている。
まぁ、TWEってのをMWにしたくらいしか見た目は変わりない。

ただ、問題は、MWSDKで提供されるファーム群のコンパイルは
そのままではTWESDKとなんら変わりなく、RED用にはならないこと。

ぼくのばあいは、ほとんど独自にファームを改変しているので
これは結構困る。。。

で、M社のO氏に教えてもらって、なんとかRED用ファームを
つくることができるようになったので、その備忘録として、
記録しておく。

１．Eclipseは
      c:\MWSDK\ECLIPSE.cmd
    を実行することで、おこなう！（これ重要）
２．Wks_TWELITEフォルダをワークスペースにする。
３．生成したいプロジェクトをひらく。
４．生成したいプロジェクトの右クリックでプロパティをひらき
     (1) C/C++ ビルド => ビルドコマンド[ビルダー設定]を
                 make TWELITE=RED APP_UART_CONFIG=CONFIG_NORMAL
         にする。BLUEの場合は
                 make TWELITE=BLUE APP_UART_CONFIG=CONFIG_NORMAL

     (2) C/C++ ビルド => ビルドコマンド[振る舞い]で
                 Enable parallel build
         のチェックをはずす。

     (3) C/C++ ビルド => 環境  で
             PATH
          をえらんで、削除ボタンをおす。
          すると、値の部分が新たに設定される。

ここまでできていればOKなのであとは、プロジェクトにもどって
ビルドすれば、xxx-REDというバイナリ（BLUEの場合はそれなり）が生成される。

ねー。めんどくさい。

モノワイヤレスさん、もうすこし、親切にしてほしいなぁ(笑)