小さいシステムで、メモリがぎりぎりになるようなときの事前計算が非常に苦手です。
ほどほどに余裕があればよいのですが、足りない=マイコンの変更=コストアップ!なので、ぎりぎりになりそうなくらいであれば、その前から大きめのRAMを持つマイコンにしてもらうようにしています。
だって!
後から変更がきかないのですもの!!
その時は、試作する段階があり、その段階でサイズがあまり空いていなかったのでこのRAMサイズでは厳しいよなー、というのがわかり、大きめにしてもらいました。
しかし、その段階では通常アプリの仕様もわかっていないことが多いので、「どのくらい?」と聞かれても困ります。
それに、作っている途中で要求が変わってきたり、回避できない現象が出たりするので、「間に合うかも」のサイズで実装を開始するのはよろしくないと思います。
部品代が上がると製品コストに直結するので、嫌がる人も多いのですが、じゃあそのために(ハード以外で)費やされたコストをどこで回収するのか?ということになります。
もし、最終的に足りないならば、結局ハードを変更することになるので、最初からハードを変更していた方が議論するコストなどを考えずに済みます。
ハードを変えずにRAMの消費を減らすとなると、組み込み屋さんのソースコードはそこまで無駄食いをするようなコードを書かないので、元々余力(=減らす力)はあまりなさそうに思います。
どうせこのあと、不具合だとか仕様変更とかでやることが増えるんでしょう?と思うと、あんまりピッチリしたコードを書くよりも、遊びを持たせて余裕がある作りにしておいた方が安全じゃないか、と思いつつあります。
いや、昔は、そんな余裕のあることを言っていられないほどメモリが少なくてね。。。
ということで、だいたいこういうことにしています。
- ハードがまだ確定していない場合は、めいっぱいメモリが取れる(マイコンを使ってもらえる)ようにがんばる
- ハードが確定していて、メモリが少ないなら、がんばってメモリを使わないようにする
- 機能削減も視野に入れよう
うん、がんばるところが違いますな。
そして、後者の方が大変なのは、だいたいわかります。。。
でも、前者ができない場合もあるでしょう。
そんなこんなありますが、このレベルでは圧縮が効かないので、何とかするしかありません。
つらいですね。。。
0 件のコメント:
コメントを投稿
コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。
注: コメントを投稿できるのは、このブログのメンバーだけです。