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
デバッグしてみました。(もっとも、残念ながら、ソースコードが公開されているのは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
- 関連記事
-
- RL78マイコン基板(RL78/G13)|rl78flashで書き込んでPython+pySerialでシリアル通信する設定
- RL78マイコン基板(RL78/G13)|TeraTermでログにタイムスタンプを付けて自動保存してくれる機能
- RL78マイコン基板(RL78/G13)|WebコンパイラのSerial.printに日本語出力させてTeraTermで表示
- RL78マイコン|日立/RSDの人のCC-RLの論文が情報処理学会の優秀論文(全54編)の1つに選ばれていた
- RL78マイコン基板(RL78/G13)|rl78flashで書き込んでTeraTermでシリアル通信する設定
- RL78マイコン基板(RL78/G13)|KurumiWriter V1.00(ソース公開版)とrl78flashの書き込み時間の比較
- RL78マイコン基板(RL78/G13)|rl78flashの書き込みボーレート変更不具合の暫定修正('workaround')
- RL78マイコン基板(RL78/G13)|KurumiWriter V1.00(ソース公開版)で不安定動作の暫定修正
- RL78マイコン基板(RL78/G13)|KurumiWriterで書き込んでTeraTermでシリアル通信する設定
- RL78マイコン基板(RL78/G13)|rl78flashで秋月のR5F100LGAFB搭載変換モジュールに書き込み
- RL78マイコン基板(RL78/G13)|KurumiWriterで秋月のR5F100LGAFB搭載変換モジュールに書き込み
- RL78マイコン基板(RL78/G13)|GR-COTTONのフラッシュ書き込み回路は抵抗のみ
- RL78マイコン基板(RL78/G13)|Webコンパイラで秋月のR5F100LGAFB搭載変換モジュールを使う
- RL78マイコン(RL78/G10)|Applilet EZ PL for RL78のフラッシュ書き込みタイムアウト時間は長い
- RL78マイコン(RL78/G10)|力技でApplilet EZ PL for RL78からrl78g10flashを使う(動作保証外ですが)
2016/09/12 blog-entry-809 category: RL78 /* 16bit,8bit CISC */
| h o m e |