(toppers-users 3901) Re: DEF_RPRIを無くすご提案

[高橋和浩@nifty]

内山様　皆様　こんにちは　アライブビジョンソフトウエアの高橋です。

インラインにてコメントします。

On Wed, 8 Feb 2012 10:19:16 +0900
"内山　敏和" <uchiyama-1415 ＠ ntk-g.co.jp> wrote:

> 高橋様 皆様
> 
> おはようございます。新潟通信機の内山です。
> 
> 高橋様へ
> 私の事例に対してコメント頂きありがとうございます。
> 意図もご理解頂けた様で、安心しております。
> 

どういたしまして、特に排他についてはそれで理解できました。ありがとうございます。

> 
> 以下に、頂いたコメントについて思うところがある部分を書きます。
> 
> 
> >というのは、例示のシステムを設計者は相当タスク設計については理解している必要がありますが
> >これがメンテナンスになって、RTOSをこれから勉強しようというつまり前述の1)の人が引き継いだ場合
> >には、おそらくデグレードをすると考えます。
> 先の事例を考えている最中、私も同様に感じてました。
> ドキュメント類の整備や開発スタイルにも関係しそうですね。

同様に感じている方がいることで安心しました。　「これは、高橋さんのご意見としては理解しました」
ということが続くと凹みますので、

> 
> 例えば修正が発生する際、
> (A)いきなりソースコードを見ながら修正する
> (B)ドキュメントを見て修正箇所を判断、ドキュメント修正後、ソースコード修正する
> 　各段階でレビューも実施
> どちらのスタイルが良いとか悪いとか言う気は毛頭ありません。
> それぞれの状況で、一番良いと思う方法が良いのだと思います。
> 
特に(A)の場合はDEF_EPRIの効果とその作用について、SSPの独自仕様でもあり、さらにcfgファイルにたぶん1行書かれるだけです。
また、cfgファイルもRTOSユーザーでも知らない人がいても不思議でもありません。μITRON4.0以降での仕様になります。
ですので前述1)の人の場合にそこを最初にみない可能性が高いと思います。
また、想定するユーザーについては、今さらですが、プレスリリースに書かれていますね。

現在リアルタイムOS を用いていないような小規模な組込みシス
テムにも適用できるように開発したものです。また、仕様が小規模であるため、リアルタ
イムOS の入門者や学生のエントリ教育向けにも最適です。


> 
> >これで、タスクDは無くなるので、タスクCからもっともスタックが浅くなったところから関数呼び出し
> >すれば、スタックが減らせるのは同じ効果があります。
> これも同感です。
> 私も（自分で言うのも何ですが）もう少し策は無いかと考えると思います。
> 
> でも、逆にタスクにこだわる場合もあります。
> （一般論になるので、先の事例との関連性は薄いことをご容赦下さい）
> 下位機種から上位機種までの製品展開があり、
> 下位機種では、同系のワンチップCPUながら、RAM容量が少なく、タスク数分のスタック領域確保は困難。
> しかし、なるべく機種間で共通する部分は、同じタスクを再利用したいので、
> 積極的に省スタック化を活用、タスクとして動作させたいと考えます。
> 
全く同感です。私の認識ではTRONの元々の発端はスケーラビリティにあると思っています。そこに立ち戻るという
のかそれはすでに踏襲されているのかそれはわかりませんが、スケーラビリティのための互換性を持つことが
望まれることだと思います。
たとえば上位のASPのあるモジュールがSSPで移植が容易にできるなどのことは望ましいことだと思っています。

---
アライブビジョンソフトウエア株式会社
高橋和浩
673-0005兵庫県明石市小久保2-2-7幹線ビル4F
Email:takahashi_kazuhiro ＠ nifty.com
http://homepage3.nifty.com/ALVS/