立石かんなのブログ一覧

いっこうに、説明がちがうよ、間違ってるよって指摘がない私、「立石かんな」ですw

どうしたら、速くなるのか教えてよ～。




さて。

なんでも、Hi-speed ROMというのは、UV-EPROMからOTP-ROMに変更すると、動作電流がかなり落ちるんだとか。


なんでも、50mAが100uAになるんだって!!


凄いよねー。1/500になるんだそうだ。


画期的～w








で、何々?

相手は、STマイクロ製品。

供給電流が50mAだって。


方や、挑戦者はマイクロチップ/アトメルのOTP-ROM


そうそう、OTPは　One Time Programmableの略ね。




どうやって、電流を1/500まで絞っているのか気になりません?

電流食わないのって、皆さん好きですよねw




さて。

画像の一覧をどこから拾ってきたのかわかりませんが、まあどっかのネット商社の画像なのかな?


で、「ばかばかしくて、やってらんないw」なんて思っておきながら、データシートを探してしまった私。


というか、マイクロチップ/アトメルだと、現状28pin DIPで見つかるのはこれしかないのよね。

http://ww1.microchip.com/downloads/en/DeviceDoc/doc0014.pdf


さて。

皆さんも開いてみましょう♪

さてさて。

開いてみると、ごちゃごちゃと書かれていますね。

2ページ目に進んでもらうと、ECUの蓋を開けたことがある人や画像を見たことがある人だとこんにちは♪したことがあると思いますが、28-Lead PDIPが良く使われるIC形状になります。

で、左側のPin configurationsの表を見てみましょう。


A0～A14は、アドレスと書いてあるように、マイコン側からアドレスを指定する入力ピンです。

O0～O7は、データが出力されるピンですね。

8bitになります。


で、今話題のCEとOEピンでこれはマイコンである主人が、PROMである爺やを動かすための出力ピンです。


NCは、No Connectつまり接続無しですね。



うーん、やはりマイコンである主人は爺やが早く戻ってきたことを知る術がありませんねー。

爺やには、データ出力ピンであるO0～O7のピン以外に主人に声を掛ける出力ピンがないようです。



ページをずるずると下にいくと、3ページ目に制御モードがありますね。

読み出し等々。



で、さらに下にいくと…。

まあ、簡単な読み出し時の環境条件がペロッと出てきます。

indとautoとなってますが、industrialとautomobileでしょうか。

つまり、工業用グレードと自動車用グレードですね。

自動車用の方が環境条件が厳しいですから、動作温度範囲が-40℃から125℃と広くなっています。


表の-45と-70の違いは…。

4ページにあるように、CEとOEがLoの条件とすると、アドレスが変化してから(指定してから)最大45nsで確定するか、最大70nsで確定するかです。


わぉ、45nsですって!w

よだれ垂らして飛びつきそうな感じですねw


CEとOEをLoぱなしで、パラパラとアドレスを変えていくと、最大45nsもしくは最大70nsでパラパラとデータが吐き出されるわけです。

もちろん、「爺や今からいうアドレスの書庫からデータを持ってきて。」とお願いしておきながら、次々と書庫のアドレスを言っていくわけです。


さらには、主人は指定の一定時間後に爺やが持ってきたデータを見ると。

まあ、できるとしても、書庫に並んでいる漫画の1巻から10巻までとかの連続データの際だと思いますが…。



で、話が逸れましたが…。


果たして、データシート上、100uAで動くことになっているのか?


それは、Table5-3に書かれていますね。

どこから引っ張ってきたかわからないような画像の中身に近いことが書いてあると思います。



さて。

このICは果たして何mAで動くのか?

えっ!?何uAではないの???



Vcc active currentを見てもらえればわかりますが、条件はあるものの最大で20mAだそうです。

あれ?100uAとか言ってなかったっけ?


条件は、f=5MHzでIout=0mA,EがLoということはCEとOEがLoということでしょうかね。

最大で20mAも流れます。

アクティブに動いている時ね。



じゃあ、100uAは?

さて、よく見てみると…。

スタンバイモードの時に100uAだそうです。

CEの信号がVcc±0.3Vですから、Hiの時。

つまり、爺やを呼ばない時は、爺やは転寝しているわけです。


転寝している爺やでも100uAは最大で消費します。



最大でってことは、100uAでアクティブに爺やが動くこともあるのかしら?

でも、そんなことどこにも書いてませんねー。


では、あの一体画像はどこから…。

根拠となる画像は…。





気になりますね、そんなに電流が少なくなるものかと。








まあ、めぼしいものをネットの海から探すと…。



あっさりと出てきたw

どこかのページで、矢印付きで速くなるとか、消費電流が少なくなるって言ってたやつだwww


https://www.mouser.jp/ProductDetail/STMicroelectronics/M27C256B-10F1?qs=%2Fha2pyFadujrDnaNeVjdLKF2MFpHT6Pkrx6qjFj8jSB40H0VrvtZc6DFxSphSALSes79kwg41D4%3D


↑のデータシート
https://www.mouser.jp/datasheet/2/389/stmicroelectronics_cd00000515-1204492.pdf



で、速いとか言う奴。

https://www.mouser.jp/ProductDetail/Microchip-Technology-Atmel/AT27C256R-70PU?qs=lURXKZrvvXerj2LFnnLrrA%3D%3D

↑のデータシート
https://www.mouser.jp/datasheet/2/268/doc0014-1280163.pdf


マイクロチップ/アトメルは、同じデータシートだね。
最大でも20mAですね。

対して、STマイクロは、同じ条件で30mAだそうだ。
(データシートの14ページ目。)

Eは、CEみたいなので、マイクロチップ/アトメルも条件はCEがLoの時。



面白いことに、どちらもスタンバイは100uAでしたとさw




よくあるんだ、こういうネット商社の性能一覧があいまいなのってね。

そもそも、ここを信じちゃいけないwww

適当なのは、いつものこと。

ちゃんと中を見ないとね。



ちなみに、STマイクロの50mAはデータシートよりプログラム時(書き込み時)の供給電流が50mAでした。




そんな1/500になるほど変わらないじゃん。

たった、30mAが20mAに。

2/3までは減ってますけれどね。

でも、10mAでしょ。

無駄なアクセサリを外した方が、余程電気食わないような…(^^;



さて。

電流もそうですが…。

70nsで速いとか言ったら、普通に45nsが出てきたw

なおかつ、STマイクロのUV-EPROMについては、45nsモデルもあるーwww

あれー、ワンタイムROMの方がすごいんじゃなかったっけー?w


まあ、手に入るのはマイクロチップ/アトメルの45nsモデルです。





なぜ70nsモデルを薦めたのかは神のみぞ知るw

単純に調べ方の問題か、付けて動かなかったから70nsモデルの方を選んだかw

そりゃそうだわね(^^;






上記を覗いてみてわかるかと思いますが…。

なんとなく、つじつま合わないでしょ?

データシートにも間違いがないかといえば、更新もされるので100%ではありませんが、でもネットの情報って意外と適当だということがわかると思います。

そんなに劇的に変わらんてw



画像をみて、"へーっ"って思うことはあっても、そこにも違和感がありますね。

例えば、意図的に隠されているものとかね。
(画像を良く見るとわかります。)

なぜ、それなのか?とかね。





重要なのは、それが本当に確からしいことなのか、きちんと確認することです。

たまたま?

私が普段そういう仕事だから?


いやいや、世の中そんなにおいしい話ってのは無いのですよ。

劇的に電流が少なくなったりとか、簡単に速くなったりとか。




まあー、高いお勉強代とセッティングプログラムデータ費用、書き込み作業費と思うことですね。

ある種、詐欺に近いと私は思いますけれどねw



どこが、どうなのかきちんと納得のいく説明をしてもらいたいものですね。



ちなみに、FC3S後期のN374は、BD27C256が付いてました。

データシートを探してみてみると、面白い発見があるかもしれませんよっ♪

やっぱりそうだよねー。



前回のブログはM27C256B系と、FCでも、当時の車でも良く使われているEPROM。

なんでも、これをワンタイムPROMのアクセスタイムが短いものに交換すると速くなるとか。

性能向上?


なんでも、Hi-Speed ROMとかいって、RX-7のROM交換が流行っているらしい。


通常、M27C256B系はCE(チップ・イネーブル)とOE(アウトプット・イネーブル)をLo(つまり、2進の0で0V)とすると、一定時間後にデータがデータピンに出てくる仕組みです。

凄く簡単にいうと、マイコン(CPU：主人)がEPROM(爺や)を呼んで(CE)、データを頂戴(OE)と言うと、EPROM(爺や)が書庫からはいっ!とデータを渡してくれる(データの出力)。



ここで。

登場人物であるマイコン(CPU：主人)は、毎日毎日規則正しい生活をしています。

彼は、心臓である水晶振動子(内部だったり外部だったり)の鼓動のタイミングでしか動けません。

水晶振動子は、Hi(2進数の1)とLo(2進数の0)を規則正しく繰り返します。

マイコン(CPU：主人)は、クロック(水晶振動子)の立ち上がり(0→1)か、立下がり(1→0)か、もしくはその両方でしか動けません。

なので、水晶振動子のタイミングで動きます。


クロックのない時、私のような不整脈では通常動きませんw


一般的には、装置の電源が入る(朝になる)と、寝ぼけて起きたマイコン(CPU：主人)は、そばにあるリセットICに"起きろ!"と思いっきり頭を引っ叩かれます。

また、マイコン(CPU：主人)を常に監視する愛犬(ウォッチドッグタイマ)がいて、"ワン!"と吠えてから、マイコン(CPU：主人)が一定時間内に頭を撫でないと、主人がトチ狂ったと判断して、"がぶっ!!"とこれでもかってくらい思いっきり噛みつきリセットさせられます。






さて、ある時マイコン(CPU：主人)はEPROM(爺や)に、データを取ってくれといいます。
EPROM(爺や)はマイコン(CPU：主人)に言われた通り書庫からデータを持ってくるわけですが、部屋が離れているのでEPROM(爺や)が書庫からデータを持ってくるには時間がかかります。

いつもEPROM(爺や)は10クロック後にデータを持ってきてくれる。

そうプログラムされているマイコン(CPU：主人)は、10数えてから机の上に置かれたデータを見るわけです。


で…。


ある時、EPROM(爺や)が戻ってくるのが早く、机の上に5クロック後にデータを置いたとします。
(いわゆる、アクセスタイムが速いタイプ。)


ですが、マイコン(CPU：主人)はいつも通り10数えている最中なので、机の上に5クロックでデータが置かれたことを知らず、いつもどおり10数えてからデータを見ます。


5クロックで机の上にデータが置かれているのに、10クロック経たないとデータを見ません。


マイコン(CPU：主人)が、"早く戻ってきたなら、そう言ってくれよ!"とかEPROM(爺や)が"データを持ってまいりました。"とか言わないわけです。

ハード的に、EPROM(爺や)がマイコン(CPU：主人)に信号を伝えるピンも無ければ、そもそも"早く戻ってきたなら、そう言ってくれよ!"ともプログラムは組まれていないので。


EPROM(爺や)がいつも通りデータを持ってこようと、早く持ってこようと、データを見るのはいつも一緒。

水晶振動子で決められた周波数で、決められたクロック数でデータを読みます。

私情や人間の思惑、勝手な妄想等は挟みません。


もちろん、EPROM(爺や)が戻ってくるのが遅いと大変。

机の上にデータがないのに、机の上にデータがあるものとして変なデータを読むことになります。

"どれどれ?ん!?データがないじゃないかーい!"とか言いません。



本当に速く動作させたいならば、下記が考えられます。

①彼らが住む世界の時間を早くする(クロックを上げる。)
②PROM(爺や)が、"データを持ってまいりました。"と言えるように、
　そしてマイコン(CPU：主人)がそれを聞こえるように、ピンを追加する。
③プログラムの中身を書き換えて、10数えるところを5数えて読みこむようにする。


なんでも、売りはそのまま載せ替えて、同じデータ(実際は現車セッティングデータ?)で速くなるってらしいのでw

ということは、①も②もダメ。

①は昔でいう(今もやる?)オーバークロックみたいなものでしょうか。
ただ、それは周囲のクロックで動くICとそれにつられて動くICがすべて対応しなければいけないので、まあほぼ無理でしょう。

②はもっと無理。基板作り直し。





じゃあ、③だね。

データ書き換えるんだから、出来るじゃん!

工賃取って、ICをワンタイムに換えてって。



まあ、できなかぁ無いけれど、これは非常に難しい。

何故か。


これは、根本的な問題で、EPROMにデータを書き込む際にプログラムの領域とデータの領域を分けて書き込むのですよ、通常。


良く、ECU書き換えっていうのは、後者のデータ領域の書き換えだと思います。

あの、なんとかマップって名前の付いているやつね。

EPROM自体で分けている場合も、EPROM内で分けている場合も、またプログラム自体はマイコン(CPU：主人)に書かれている場合もあります。


プログラムの構造上、必要となるデータのいれものを用意してアドレスを振ると思います。
EPROM(爺や)がデータを取りに行く書庫ね。


通常、ECUであれば、点火データとか燃料データとか、あとは入れるとすると条件分岐のスイッチ(フラグ)が保管されていて、必要な時にそのアドレスからデータを持ってくる感じかしら。



問題は2つかな。

①タイマー設定の値が、わざわざデータ領域に記載されているのか?
②HEXファイル(バイナリデータ)を人間が見た時に、どこにタイマーの値が書かれているのか?


普通、何クロック後にとかの設定は、プログラムの記述でタイマーを使って(作って。)カウントダウンもしくはカウントアップしてから指定クロック後にデータを読みに行くと思います。

"i<=i+1で、i=xならデータを読んで、i<=0"みたいな。


(このブログは素人が書いているので、実際はもっと違う記述だと思うけれどw)


じゃあ、この時にわざわざxの値をデータ領域にアドレスを振って保管しておくかっていうと、たぶんしないと思います。
面倒くさいし、わざわざタイマーの値全て並べる必要もあまりないし。
(パラパラと変わる値ではないので。)


じゃあ、"i<=i+1で、i=xならデータを読む"をプログラム領域から探す?

"i<=i+1で、i=xならデータを読む"というのは人間の言語なのでわかるけれど、実際にはバイナリデータで羅列された、わけのわからない機械言語。

コンパイル前のデータがあればいいけれど、コンパイル後のデータから逆コンパイルできるスキルがあればできなくはないですが、ピンに出力される条件分岐と違って、これは相当難易度が高い。

動作とPCのエミューレータでパラパラと動くの見てればわかるってレベルではないですよ(^^;
あれは、あくまでもマップでわかりやすく並んでてとか、フラグの位置がわかって同じようなところを毎回読んでるから見えるって話。


人間が見られるバイナリデータから読まないといけないからね。
どこが、タイマーの値かピンポイントで狙わないといけない。
そこまでできていたら凄いもんだと思うけれど、そう簡単にはいかない。

そもそも、他に影響を与えないとも限らないし。


タイマーそのものの設定を変えちゃうのも手だけれど、そうすると同じタイマーを使っている他も変わっちゃうし、設定はおおざっぱだし。




もっとも…。

100nsが70nsになったところで、どれだけ変わるかって話もあります。

100nsの時間て周波数だと10MHzで、70nsの時間て周波数だと14MHz。

当時のマイコンがどれくらいで動いていたかわからないけれど、10MHzで動いていたとすれば、1クロック後もしくは2クロック後にデータを読むように設計者はプログラムしているはずで、書き換えたとしても70nsでもたった1クロックしか変わらない。

20MHzで動いていたとすれば、書き換えたとしても3クロックが2クロックにしかならない。


さらには、動作周波数が違えば、タイマーの値をいくつにしているかも変わってくるので知らないといけないし。




もっと余計な事言えば、現状計算や読み出しが車の動作に間に合ってないということはないということ。

わざわざ計算や動作速度が間に合わないECUなんぞ、使わんじゃろ。





いや、普通に考えて欲しいんだなぁ。


必要なのは、エンジンに入っている空気量に最適な燃料と点火なんだよね?基本。

例えば、じゃあ最新のコンピュータで同じ入出力でエンジンを動かしたとしても、エンジンの回転数とエンジンに入っている空気の量は変わるの?

エンジンに今入っている空気は、エアフロを通過しているわけだけれど、エアフロで採った値の空気量は遅延してエンジンに入るわけじゃない?

コンピューターが"うおぉぉぉぉぉぉぉぉっ!"って言いながらw、リアルタイムにパラパラと計算しても、結局空気を計量してから点火と燃料噴射のタイミングは変わっていないわけで。

ぶっちゃけた話、次の点火までに細かく分割して計算したところで、途中の計算は中途半端に更新して捨てられてるわけで。


大きくプログラムや入出力を変更しない限りは、まったくもって無駄なことだと思いません?
たかだか、数十nsはやくなったところで。


だって、極端な話、昔のパソコンでメモ帳使っても、最新のパソコンでメモ帳使っても変わらんでしょ?





あくまでも、データ要求してから確定までが速い(アクセスタイムが短い、爺やがデータを持ってきて机の上に置くのが早い)だけであって、他が変わらなければ何にも変わらないのですよ。


マイコンは、EPROMに待たされるのではなく、自分で待っているのです。
"遅いなぁ…"とか言いませんし、データが来たからって動きませんからw


間違っているのであれば、そして、これこれこういう理由で速くなると理屈がわかる方、御指摘どうぞ。