RL78 SmartConfiguratorで気になった点とか改善する案とか報告してみるスレッド

こんにちは。NoMaYです。

いま2つ気になっています。

(1) ICCRL78とLLVM-RL78(とGNURL78)でワーニングレベルを上げるとワーニングがとてもたくさん出る
(2) RL78スマートコンフィグレータGUI上でオンチップデバッグトレースを使用する設定にしても予約RAM領域を空けていない

Parents
  • チョコです。

    IICA関係のプログラムを眺めていたので、もう1件です。

    IICAに限らず、従来のコード生成の通信系はそのままでは、通信が完了したかどうかを確認できません。Arduinoが幅を利かせてきて、ベアメタル型の裏で割り込みを待つのが一般常識でなくなってきています。ここらの終了条件が不明確なために、SendやReceiveのAPIを呼び出して、戻ってきたら処理は完了してるいると誤解して、次の通信処理を起動していいるユーザがかふぇルネに結構見受けられました。ここらをフラグでも準備してきちんと対応するように鈴木さんにはぼやいていたのですが、SCでも変わっていないようです。

    上記のようなユーザがいるのに、Master_SendやMaster_ReceiveのAPIでは、以下のようにバスのことしかケアしないでスタートコンディションを発行しています。前の通信が完了していることをきちんとチェックしてから次の処理を起動すべきです。これは、通信全体をきちんと見ていないからではないでしょうか。

    このエラー処理を追加するだけでもユーザはエラーの原因を考えるヒントになるかもしれません。

    最後に、失礼な表現が多数あったであろうことをお詫びしておきます。ぜひ、改善をよろしくお願いします。

Reply
  • チョコです。

    IICA関係のプログラムを眺めていたので、もう1件です。

    IICAに限らず、従来のコード生成の通信系はそのままでは、通信が完了したかどうかを確認できません。Arduinoが幅を利かせてきて、ベアメタル型の裏で割り込みを待つのが一般常識でなくなってきています。ここらの終了条件が不明確なために、SendやReceiveのAPIを呼び出して、戻ってきたら処理は完了してるいると誤解して、次の通信処理を起動していいるユーザがかふぇルネに結構見受けられました。ここらをフラグでも準備してきちんと対応するように鈴木さんにはぼやいていたのですが、SCでも変わっていないようです。

    上記のようなユーザがいるのに、Master_SendやMaster_ReceiveのAPIでは、以下のようにバスのことしかケアしないでスタートコンディションを発行しています。前の通信が完了していることをきちんとチェックしてから次の処理を起動すべきです。これは、通信全体をきちんと見ていないからではないでしょうか。

    このエラー処理を追加するだけでもユーザはエラーの原因を考えるヒントになるかもしれません。

    最後に、失礼な表現が多数あったであろうことをお詫びしておきます。ぜひ、改善をよろしくお願いします。

Children
No Data