RL78マイコン基板(RL78/G13)｜KurumiWriter V1.00(ソース公開版)で不安定動作の暫定修正

以前のエントリで遭遇したKurumiWriterの不安定動作(少なくとも私のパソコンでは)ですが、Visual Studioで
デバッグしてみました。(もっとも、残念ながら、ソースコードが公開されているのはKurumiWriter V1.00のみ
ですので、最新版のV2.10ではなく公開されているV1.00でのことです。V1.00も同様に動作が不安定でした。)

困惑したのは、Windowsという汎用マルチタスクオペレーティングシステム(LinuxやMac OS X等も同類)上の
ユーザーモードアプリケーションであるにも関わらず、100ms～数100msというオーダーのタイムアウト判定が
行われていたことです。普通に経験があることだと思うのですが、同時に動かしている他のアプリケーションに
CPU時間が奪われたことで、今まさに作業をしているアプリケーションの反応が数秒間無くなってしまうことも
あるぐらいであり、通常の状態でも、数10msというオーダーでアプリケーションが切り替わっていきますので、
100ms～数100msというオーダーのタイムアウト判定は誤動作してしまう可能性が充分にあります。実際、その
タイムアウト判定処理を暫定的に外してみたところ、あっさり安定して動作するようになりました。(もっとも、
タイムアウト判定処理を単に無くしてしまうだけでは異常が本当に起きた場合にはハングアップしてしまいます
ので、あくまで暫定的に外してみたというところです。) (追記 : タイムアウト判定処理を全く外してしまうのは
やめて、タイムアウト判定時間に3秒の下駄を履かせるようにしてみました。)

ファイル: SequenceProcessor.cpp
暫定修正内容: 赤字の箇所を追加 (薄字の箇所は無視して下さい)

//----------------------------------------------------------------------------- // @outline データの受信待ちを行います。 // @explanation データの受信待ちを行います。 // @param [out]*dwLength 受信したデータの長さを格納します。 // [in]dwTimeout タイムアウト時間を指定します。(msec) // @return 正常に受信できた場合には 0 を、受信できなかった場合には 0 以外を返します。 //----------------------------------------------------------------------------- DWORD CSequenceProcessor::waitStatusFrames(DWORD* dwLength, DWORD dwTimeout) { DWORD dwRet = SW_SUCCESS; DWORD dwReceiveLength = 0UL; DWORD dwStartTime = 0UL; DWORD dwPassTime = 0UL; BYTE bStx = 0x00; DWORD dwLen = 0UL; *dwLength = 0UL; // 処理開始時間を取得 dwStartTime = timeGetTime(); do { // 受信データのサイズを取得する。 dwReceiveLength = m_ComPort.GetReceiveDataLength(); // 2バイト以上受信していれば解析可能 if (2 <= dwReceiveLength) { // STXとLENデータを取得 dwRet = m_ComPort.CheckDataFrame(&bStx, &dwLen); // チェック完了且つSTXデータの場合 if (SW_SUCCESS == dwRet && STX == bStx) { // LENの内容から解析するフレーム全体のサイズを取得する。 // LENの内容 + 4バイト分（STX、LEN、SUM、ETX or ETB） *dwLength = dwLen + 4; } } // 経過時間を取得する。 dwPassTime = timeGetTime() - dwStartTime; // タイムアウト判定 //#if 0 // delete! (workaroud by MON-80) if (dwPassTime > dwTimeout + 3000) { // Add 3000ms by MON-80 dwRet = SW_ERROR_RECV_TIMEOUT; break; } //#endif } while (0UL == dwReceiveLength || 0UL == *dwLength || *dwLength > dwReceiveLength); return dwRet; }

ちなみに、タイムアウトした時の一例は以下のようなものです。(タイムアウト判定処理は元に戻してありますが、
そのままのソースコードではデバッグビルドが通りませんので、以前のエントリで試した修正をしてあります。)

追記 : 補足

以前のエントリのFT232RLのWindowsドライバの設定を変更することである程度改善出来たこととの因果関係は
正直なところ良く分かりません。

追記 : 補足

RL78/G10にUSBシリアル変換モジュールによる自作書き込み回路を使いRenesas Flash Programmer V3.01で
書き込む時に動作が不安定だった時にも同じような対症療法的対応策があるのですが、同じようなことになって
いないか気になります。

Applilet EZ PL for RL78でUSBシリアル変換モジュールによる自作書き込み回路を使う際の注意点
http://japan.renesasrulz.com/cafe_rene/f/82/p/3504/17327.aspx#17327

追記 : メモ

KURUMI Writer for Win V1.00 Source
http://japan.renesasrulz.com/gr_user_forum_japanese/m/mediagallery/119.aspx

KURUMI Writer for Mac V1.00 source
http://japan.renesasrulz.com/gr_user_forum_japanese/m/mediagallery/120.aspx

関連記事