【Renesas】ルネサス総合 part12
■ このスレッドは過去ログ倉庫に格納されています
そんでもRenesasさんは、ギャグかとおもって笑えるレベルだからいいけど、 旧Freescale (現NXP) は、まじで周辺回路デバッグしてねえんちゃうか?ってのもあったからなあ。 Renesasさんの製品や会社が、 もうちょい、オープンソースに慣れきっちゃった、 ソフトウェア屋と相性のよくなれるようになるといいなと、オネガイシマス。 >>339 マジレスすると修正版や拡張版に対するものに対してgithubに置けない仕組みは すぐにでも撤廃して見直すべきだな。何のメリットもない。 正直今の時代はハードだけじゃ売れないから生き残るためにソフト面を充実していかなきゃいけないんだけど、 俺個人としては内製ソフトの販売をやめてルネサスの自社デバイスに特化した ドライバソフトの開発をOSSとして提供する事を大々的にやるべきだと思ってる。 これのメリットとしては 1.内製ソフトの販売に伴う品質縛りが軽くなり人的リソースの問題が大きく緩和される 2.各方面からのフィードバックをすぐに吸い上げる事ができる 3.開発が主体となる事によって若手のモチベーションアップに繋がり流出が抑えられる 4.継続的な開発によって時間とともに良質なドライバソフトが出来上がってくる 5.クソ高いだけのルネサス製ソフトがOSSで手に入り顧客が手を付けやすくなる。結果として自社デバイスが売れる 6.各ベンダーがこのOSSを使って別プロダクトを構築してくれる。結果として自社デバイスが売れる 使いやすいソフトができれば客が群がるはずというシンプルなロジックだし 会社のマンパワー不足の現状にマッチングしてるとも思ってる。 そして売上上がれば俺の給料が跳ね上がる!!! もうね高くて売れないソフトのために意味不明なドキュメントを無駄に工数浪費して作るの嫌なんだよ・・w だったらOSSに逃げてマニュアル代わりのホワイトペーパー充実していったほうが 絶対デバイス売れてシェア伸びるし社会貢献的にも100倍マシ ツールチェインが有償の純正とレガシーなgccのみってところでもうね。効率の良いclang使えない 今RXで命令の実行に伴うメモリライトのタイミングとADCの各動作のタイミングで頭抱えている マニュアルに書いてありそうだがはっきりと書いていないんだなこれが サンプリング中にポートを操作したいんだがよく判らん。ADCとGPIOを繋いで実験しろと?w ソースの再配布は、修正したものや拡張したものに対して許可みたいな、ケチい条件すら緩和して、 最初っからルネサス公式githubアカウントにMITやLGPLライセンスで置いてくれるといいね。 そうでもしないと、修正したってpull-requestしてあげられないからね。 昔の(半)はCRTCとかの周辺LSIもメジャーだったけども今はそういう製品あるん? そんなオープンアーキのCPU欲しいかな? 命令セットの数から言ってもRISC-Vが諸手挙げて喜べるCPUではとても見えない コンパイラに例えると所詮gcc並 すなわち、ないよりマシレベルでメーカー設計の足下にも及ばない出来じゃないのか? そらシナは喜んで採用するんだろなwwww あとNiosの代わりとかさ。 日本人の特徴 出来ない理由を探す 米国人の特徴 出来る理由を探す >346 >辞めてまえ おっと、今年も希望退職の募集が始まり、老害の、熾烈な、退職金の争奪戦が勃発w >>349 実績あるオープンになったMIPSコアならええんか? オープンソースになったMIPSはMIPS32R6やMIPS64R6でしょう? MIPS32R6やMIPS64R6はMIPS32R5やMIPS64R5までのMIPSとは 命令セットを整理しててバイナリ互換性がない 命令セットは遅延スロットがないジャンプ命令が追加されてたり PC相対のアドレスを読み込む命令があったり 乗算、除算で使ってたHIおよびLOレジスタがなくなったりといろいろ新しくなってるが 昔からのMIPSとバイナリ互換性がないのが痛い だからソフトウェア面が全然整備されてないぞ >>351 キャリアチェンジサポートプログラムというなのパワハラ退職は間接部門が対象で6月30日退職期限デシ。 呉社長も間接部門なのでキャリアチェンジサポートプログラムで6月25日に消えてきました。 Synergyって売れ行きどうなんですか? (会社で買ってくれないから、増税前に勉強用にSynergyKit買うか悩んでてさ、) マイクロソフトに買収されたExpress LogicのThreadXがどんなもんか気になってるんだよね。 がじぇるねだと付属してこないから。 がじぇるねも部品箱にはいってるけどGR-KURUMIなんだよなw >>345 サンプリング中にポート操作? ごく普通に考えりゃ、ADC変換中は変換完了フラグ待たずに、 変換中にポート操作って、正しく値取るつもりあるんかと?、どういう状態やね!? 気になる。 >>360 普通はそうだけど欲しいのは動的な値。精度は重要ではない その値を取るにはちょうど良いタイミングでGPIOを操作しなければならない。早すぎても遅すぎても× ADST=1でADCの変換動作が開始することになっているけど RXは5段パイプラインだからペリフェラルのレジスタが書き換わるまで時間がかかる レジスタが書き換わってから実際に変換動作が開始されるまでにも時間がかかるかもしれない GPIOも同じで命令がフェッチされてからポートの出力が変化するまでどのくらいかかるかはマニュアルに書いていないように見える ADC入力と適当なGPIO出力を繋いで総当たりすれば判るだろうけどめんどくせーw なぬぅぅぅw 動作クロック(50とか100MHz=10nsや20ns)くらいにシビアなADCのサンプルホールドってw C言語のこの時代に、アセンブラ1ステップの処理タイミング計算! ハードウェア回路で何とかしろって気がするw >>363 32MHzで実験中。サンプリングの時間はひとまずデフォルトで400nsくらいかな GPIOポートの変化がサンプリング期間から数クロック前にずれただけでゴミ値しか得られなかったよ 論理の理解が間違っていて自分が組んだ回路がバグっているのかと思った 現状一応有効そうな値を得られるようにはなってきてはいるけどもっと詰めたい アセンブラ命令とクロックを並べてマニュアルの情報を元に、ある程度当たりは付けられているけど 「サンプリングされているのはここからここまで」とは特定できていない 仮にも量産を睨んでいる物なのでチップを増やすのは最終手段w あとRXv2コア搭載マイコンのマニュアルからパイプラインの説明が削除されているけどなんなんだろうな 実験して400nsとか書いてるけど、 メーカーの保障値どうせ満たしてないんじゃないかな? ADCとCPUクロックの間のクロックディバイダーによる差や、 チップ毎の入力ピンのキャパシタ成分なんやらで変動するものだし、 実験毎に結果がが違ったりしてなw ルネサスのドキュメントの悪い問題じゃなくて使い方が悪い予感しかしない。 俺仕事の気分転換にこのスレに来てるのに、気持ちよく、夜の作業とりかかれないじゃんよぉwwww >>364 とりあえずSYNC命令ぶっこんでパイプラインを即座にゲロっとけばいいんじゃね? ADCは専門外で使ったことないからよくわからねえけどサンプリングデータの取得にDMA使ってるんだっけ? メモリキャッシュが存在するならflushやinvalidate気にしないとDMA転送がうまくできなくてゴミしか得られないんじゃないか? つーか多分RXv2ならRX71とか64とかその辺なのかもしれんから命令キャッシュはあってもメモリキャッシュはなさそうだな。 もうゴミみたいな少数の命令だけが増えてるだけのRXv3になってるRX72とか使ったらどうよw 後は単純にオーバーヘッドの問題なら命令キャッシュ気にしてコード書いてキャッシュ内に収まるように展開させるとか。 サンプリング取得のところっていってるからIPからCPU間のやり取りでうまくいってないような気がするけど。。。 >>365 デフォルトのサンプリング回数は13回で32MHzだから400nsくらいになるはず。マニュアルに書いてあるし一応信頼に足る数値だと思うけど 早めだとかすりもしないと言うことは回路の応答に対してサンプリング時間が長すぎる可能性を示唆してそうに思うんだよな 本当にそうかは調べる必要があるけど >>367 ADC計測値はADCのレジスタを直接読んでいるのでコピー中に壊れた可能性はないと思う マイコンはRX230シリーズ。32MHzなのはノーウェイトで動く上限だから MOV ←ADST書き込み。ADC動作開始 NOP ・・・ NOP MOV ←PODR書き込み。GPIO変化 みたいなコードを書いてGPIOを操作するタイミングを変えていったら有効そうな値が取れだしたという段階 パイプラインがらみはRXv1搭載マイコンのマニュアルにはストアのパイプライン動作の例が書いてあって IF D E M1(ノーウェイトの場合) らしい。フェッチ後4クロック目にバスへ値が書き込まれることになるけどこれはCPUから見た動作であって 内部周辺バスにはライトバッファがあるしペリフェラルがその値を受け取るのがいつになるか判らないって話 >>369 SYNCなんて命令見覚えないぞ・・・っと思ったらRH850じゃないっすか RXにそんな命令はないのです >>371 すまない。俺も今ざっとRXv2のアーキテクチャのハードウェアマニュアルと RX200シリーズのハードウェアマニュアル読んでて 「あ、同期命令ないしアウトオブオーダー実行も明記されてないわ」と思って書き込もうとしてたw そうなると自分でタイミング測って同期化するしかないってことか 聞いてる感じだとポーリングでソフト的に頑張ってるみたいだけど割り込み発生契機からの DMA転送や割り込み発生時のレジスタ読み込みでは無理そうなのかい? ここから先はADCのIPの知識とか必要になってきそうだからあんまり力になれそうにないが。 >>372 タイマ&DMACの利用は一応考えてはいますが、使い方もよく判っていないので保留中です せいぜい数十クロックの話なのにそのためにタイマとDMACを潰すのはもったいない感もあります あとバスの動作に必要なクロック数が不明なままではCPUと大差ないと言えます DMAC→バスマスタとしての動作しか書いていない(バスへ書き込むタイミングしか書いていない。CPUと同じ) バス→ライトバッファがあると書いてある(図はあるんだけど見方がよく判らない) ADC→変換開始のトリガがかかってからのクロック数しか書いていない バスマスタがバスに書いてからADCのトリガがかかるまでに何クロック使うのか?が判らない ←イマココ 現状はこんな感じかな 以下余談 このRX230シリーズはRX200シリーズのくせにCPUコアはRX600と同一仕様っぽくてFPUが使える しかも電源耐圧は5.5V。つまりArduino互換ボードにかなり都合の良い仕様に見える ARMを積んだ高性能Arduino互換ボードも多数あるがその大半は5Vトレラントが関の山だし GR-SAKURAより遙かに使いやすそう >>373 まあ確かにチャネル数を消費しちゃうもんな メリットはあるけどDMAコントローラ使うのが面倒なのは同意 >>368 質問です。 1命令あたりを考えてADCのレジスタを書くため、頑張ってるようだが、 その間、CPUは割込禁止とかを考えてるの? >>368 嫌な予感的中! 余計な口出しだが、 マイコンの使い方の基本がなってないの。 Arduinoで高速プロトタイプ開発とかいって、 何年たっても、中華品質以下のプロトタイプしか作れない人達と変わらないの。 これで量産とか無理。 大麻とかDMAくらい使ってみなさい。 RTOSだってFreeRTOSなんかあるんだし軽くは勉強しなさい。 新しい体験で、世の中を知りなさい。 > せいぜい数十クロックの話なのにそのためにタイマとDMACを潰すのはもったいない感もあります 数十クロックに対して割り込み禁止かけて命令送り込んで、リアルタイム性の保証を犠牲にするとかw もったいない感もありますw タイミング合わせるのにnop数十発いれるとかで、低消費電力とか高い演算性能を持つRXの良さを潰すとかw もったいない感もありますw タイマー知らずに無駄な時間つかってw もったいない感もありますw > バスマスタがバスに書いてからADCのトリガがかかるまでに何クロック使うのか?が判らない 10ns単位での時間のずれが問題になる次元なら、別の高速ADCチップ使ったりすべき。 マイコン内臓ADCで頑張るなら、外部トリガ・タイマーをうまく使い、必要に応じてサンプルホールド回路を使う。 メーカーに問い合わせればルネサスは教えてもらえるかもしれないが、そもそもマイコンの使い方やソフトウェア設計が悪いことに変わらず、知ったところで意味があるかとw 学生なら今から勉強すればいいから頑張ってくれ、ただし間違った勉強の方向で時間を無駄にすんな。時には他人にソースコードやに回路を見てもらえ。 ルネサス社員で50代の管理職なら、とっとと退職しろやw。 大麻とかMDMAくらい使ってみなさい Σ(゚д゚||) 長いよ 人に説教するなら、もうちょっとまともな文章書こうよ フレームワークありきのArduino勢が○clockでタイミングを調整なんて発想に至るとは思えんが そういう方法を実行するのは8bitをベアメタルでゴリゴリやったことのある人ではなかろうか ArduinoはOSも無いし、元はAVRだしベアメタルになりやすいし無理もない。 >>345 謎は 効率の良いclang使えない と申してますが、なぜか? ι(´Д`υ) >>379 説教もなにも マニュアル読めば当然わかるADの正しい使い方すら出来てないから言われてるんだろ。 変換途中でレジスタ見に行って失敗こいてましたて アホかよwww 正しい使い方って何なんだろうね 「メーカーがドライバやサンプルを用意している使い方が以外は認めない(キリッ」とかなんだろうか メーカーが認めたもの以外は認めないという考えは、 それもそれで、頭硬いバカだと思うが、 ドキュメントすら読まずにオレサマ流な人や、 メーカーが認めた範囲外を歩むにも、 さじ加減すら知らんのもおる。悩ましい問題だな。 もっともバカは周りの指摘すら理解できず、すぐに否定や言い訳ばかりで、 なにひとつチャレンジも成長も出来ないヤツらだ。 昨日のやりとりによればGPIOで発生させた単発のイベントをADCで取りたいという話だと解釈している そのためにはADCとGPIOの同期が必要だと。マイコン単体でやる人は少なそうだがそんなにおかしい使い方か? >>383 お前も糞みたいな文章だから指摘されんだろ 今時草付けた書き込みするとかガイジかよ ADなんてFPGAで20MHZオーバーサンプリングすればルネサスマイコン内のデルタシグマよかよっぽど性能いいだろうよ なんか違う気がするんだが。 今回のケースにおいてマイコンの使い方が正しいかどうか なんていう議論はあまり重要じゃないだろ? 目的がありどうやったらやりたいことを解決できるか、という試行錯誤と 新しい事を発見したときの知的好奇心が満たされる事への欲求とワクワク感が この話の流れの本質的な部分だったんじゃないかと俺は思っていたのだけど。 こういうのって技術力を上げていく上でかなり重要だし 少なくとも技術好きな人達はこういう実験チックなことを 何度も泥臭く試して失敗して成長に繋げてると思っていたんだが違うのかw マジレス長文すまん。 マイコンの使い方どうこうもあるけど、チャレンジする368は偉いやろ。 しかしだ、1命令〇クロックで〇us進むとかでゴリゴリコードを書いて悩む前に、 368もドツボにハマってるようだから、そのドツボぬけられるような指摘とおもったのや。 (1) マイコンにRX230で、 タイマー類(MTU,TPU)の同期トリガ、または、外部端子のトリガ、割り込みコントローラ(ICU)も搭載されてる。 だから、なんでそっち使わないや?ってことや (2) そんで (a) を解決させるため、外部トリガとか割り込み使った時点で、割り込みは必須。 そうなってくれば、今のベアメタルなプログラミングを進めれば、ソースコードはスパゲッティなコードになっていき、何の修行ですか?って言われる始末。 よって、マルチタスクなコード書いてや!勉強してや!となるわけだ。 (3) さらには、ADCはS/H回路でアナログ値をサンプリングしてて、その時間が400usって書いてるし、 これはこれで、そこそこ、悪くない数値結果と思うが、 そこピンポイントで狙ってる事に疑問をもつわけだ。 実際に設計する上では、S/H回路のコンデンサ容量など考慮して、誤差まで含めて安全な設計出来てるかどうか俺は不安だ。 (4) 上記の(3) のシビアなサンプリングをやるにも (2) の開発手法が取り入れられなければ 割込禁止でプログラム書くという、さらなる修行をするつもりかですか? ってなていき、たぶんここまでくると、我々の知らぬ新世界やな。 結局 (1)〜(4) まで考えると、メーカーのマニュアル以前に、マイコンでの開発手法はなんちゃるかという、文化みたいな話にもなってくるのだ。 誤記ね: (a) を解決させるため --> (1) を解決させるため >>388 >>377 は別人だ 馬鹿たれ >>391 違うのはテメエだ寝言ほざくな。 LSIは、メーカの想定した使い方を設計者に強いる製品だ それに異論を唱えるならチップの全データをテメエで測定できるのか?って話 だいたい、メーカの用意したマニュアル通り使えないやつはそいつ自身が使えねぇんだよ糞が。 >>344 ルネサスの中の人は、ルネサスがサードパーティを見殺しにしていることついて 問題意識はないの。 イエローソフトとかあの時代にH8/SH用の自社コンパイラや自社デバッガを開発 して日立マイコンの拡販におおいに貢献した。倒産廃業するときに、なにか支援が あったようには見えない。 オープンソースの開発者だって霞を喰っているわけでないので、見返りがないと 誰もついてこない。その種の「日本国内の」会社にルネサスが出資したとか 聞いたことがない。 協力企業を対等なパートナーと見ないのは日本の大企業の悪習で、ルネサスに 限った話ではないのだろうが、マイコンはファンを増やす競争になっており、 正社員だけを身内と見なす日本の習慣はマイナスに働いていると思う。 >>392 >タイマー類(MTU,TPU)の同期トリガ、または、外部端子のトリガ、割り込みコントローラ(ICU)も搭載されてる。 >だから、なんでそっち使わないや?ってことや 論点がおかしくね?373で書かれているがトリガを掛けてから実際に物理的な動作が開始されるまでの遅延が判らないって話でないの GPIOとの同期が必要みたいだしGPIOも同様。クロック単位で合わせようと思ったらその遅延量が判らないとタイマーを使おうが解決しない あとICUやDMAを使ったらこれらの動作にかかる遅延を考える必要が出てくる >>398 GPIO使わず、タイマーの出力ピンではならんのか? でないとするならば、387では、何を想定されているのか、もうちょいと詳しく。 タイマーとAD開始トリガ、割り込みイベント、DMAの4つの使い方で相違があると思われる。 あと誰も動いていないなんて書いていないしハマっているわけでもないようだが的外れでイキっている人はなんなんだろうね 動いてはいるがどのようなタイミングで動作しているのか不明なのでブラックボックスになってしまっている 部分をあきらかにしたいみたいな話に見える >>400 変換完了もしてないのにレジスタ読んで動いてねぇんだよアホ 変換完了割込みで取得すればいい話をタイマ?wwww 死ねよアホは わかってねぇのはテメエだ無能 >392 >チャレンジする368は偉いやろ。 チャレンジなんていうかよ馬鹿 車輪の再開発そのもの。 これこそアホの骨頂つうんだ低能 >>399 詳細は本人待ちだけど タイマーでADCを開始できる、ポートのON/OFFも出来る。がそれらをどうやって同期させるんだ? 本人が悩んでいるのはそこじゃないのか TGRAでADCを開始する。TGRAを仮に0とする。TGRBで波形を出力する。仮にそのエッジを サンプリング時間の後から-nクロックにしたい場合TGRBをいくつにすればいいのか もしその数字をソース付きで示せるなら大いに368の参考になると思うけど 自分もユーザーズマニュアルを見てみたけど確かにクロック付きのタイミングチャートは少ないんだよな >>396 >>383 はお前だろ、日本語の流れも読めないのかよ知恵遅れめ >>397 オープンソースの連中に開発させてやってるんだから、感謝するべきでは。 >>397 >限った話ではないのだろうが、マイコンはファンを増やす競争になっており ものすごく同意するわ 俺個人はまさにそう思ってるからオープンソースに積極的に参入して情報公開するべき なのと、情報公開してくれるホビーユーザーの囲い込みを頑張るべきだと思ってるんだけど 会社としての判断が前時代的すぎてなw ホビーなんて客にならねえとかいう思考のやつもいるしバカじゃねえのと思うよ STがあんなに伸びてるのは何故なのか真剣に考えたほうがいい。 >協力企業を対等なパートナーと見ないのは日本の大企業の悪習で 協業企業に対してうちの営業が態度でかくて高飛車で偉そうだっていう噂はよく聞く。 影で「ボロボロで失敗ばかりのクソ雑魚企業なくせに何偉そうにしてんの」ってボロクソ言われてるのわかってないのかな営業w もちろんそうじゃなくて立場わきまえている営業もいるんだろうけどね。 >>403 余計な仕事が増えたわw rx230 ユーザーズマニュアル はじめてよんだわw https://www.renesas.com/jp/ja/doc/products/mpumcu/doc/rx_family/r01uh0496jj0120-rx231.pdf このへんみりゃ、書いてある ・23.2.9タイマA/D変換開始要求コントロールレジスタ(TADCR) ・23.2.10タイマA/D変換開始要求周期設定レジスタA、B (TADCORA, TADCORB) ・23.2.11タイマA/D変換開始要求周期設定バッファレジスタA、B ・23.7 MTU出力端子の初期化方法 ・24.ポートアウトプットイネーブル2(POE2a) ソース付きとか言ってるが、 そもそも、お前らドキュメントろくに読んでるとは思えねえ(怒 rx230 ユーザーズマニュアルは、まだ丁寧に書いてるほうや。 お前らの都合よくドンピシャで、波形図なんか書いてある事のほうが奇跡。 これすら読めなきゃモーター1個ろくに回せねえわけで、読むの当たり前。 お前らドキュメント読まねえ → マイコンや周辺回路の基本的な考え、文化すら知ることもねえ → 究極のw ソース付きサンプル請求wって技術を身に着ける → 老害への道を進む → 結論、とっとと退職しろやw >>407 Qiita とかに 「ルネのチップで速攻でIoTデバイスを作る7つの習慣」とか で原稿料もらえるなら、速攻で記事かいたりgithubにコードおいとくで。 「 〜〜〜〜〜長文略〜〜〜〜 いかがだったでしょうか? 」 で締めくってやるぜwww ルネサスのマニュアルの品質はもっと評価されていい 情報が探しづらいのは難点だが(笑) >>397 毎年、社員の下2割を解雇して減った分を中途採用。 5年でだいたい総入れ替え。 これで今のルネサスの問題が解決する予感。 >>408 問題はそこじゃねぇと書いてあるのが理解できんのか タイマーでADCの変換を開始したり波形出力できるなんて事はユーザーズマニュアルに書いてあり読めば判る 問題になっているのはその動作タイミングが判らないって話じゃないのか MTUもTPUも動作タイミングが書いてあるがADCの変換開始タイミングや波形の出力タイミングに関する記載は見あたらない あなたはクロック付きのタイミングチャートを書けるのかと。これを外から調べるつったって簡単じゃねーぞ RXのRはルネサスのRとか思ってるやつ多過ぎ RXはLexus専用チップってこと理解しろよ池沼ども LとRを区別できないルネサス社員が Rexusと思い込んでたんだと >>413 ADコンバータ(12ADE)や電気的特性の頁もに必要事項は書いてありますね。 貴方のおっしゃる、サンプル開始とサンプル終了およびAD変換完了、MTUパルス波形の出力については、明記されていましたよ。 文書を読み、ご自身でチャートを書き起こせませんか? レジスタのアクセスに必要なクロック数はI/Oレジスタのところに書いてあった。わっかんねーよw 使い方を調べるためにDMACのところを読んでいたらI/Oレジスタのところを参照せよって書いてあった ついでにSYNCさせる方法も書いてあった。書き込んだレジスタを読み出して計算に使えばSYNCされるらしい ADCとGPIOと繋いでNOPを並べてサンプリングされているタイミングを調べる実験をしてみたけど実質失敗 しょうがないのでDMACとTPUでADCの消費クロックを数えることに。TPU0はPCLK/1で回しDMACをTPU0のカウンタをコピーするように設定。ADCの完了割り込みでDMACを起動 MOV ←CST0書き込み。TPU0動作開始 NOP ←あってもなくても結果は変わらない。2個入れると+1 MOV ←ADST書き込み。ADC動作開始 で得られた値は73。書き込み動作に2クロック必要なのは確定のようだ マニュアルから読み取れる値は DMACの読み出しに4〜5クロック ADCの動作開始から変換の完了までに64クロック(tD=4+tDIS=15+tSPL=13+tASM=32=64) CPUがバスに書き込むまでに4クロック 書き込みが完了するまでに2(〜3)クロック で全部足すと74クロック 大外しはしていないようだがチャートを書いてみると未知のクロック消費がいくつかあるように見える 現状の不明点というか誤差要因 DMACが読み出す値はいつの物なのか。マニュアルによれば2クロック使うことになっているが1クロック目の値なのか2クロック目の値なのか不明 CPUとバスの関係。アクセスに必要なクロックは2クロックとあるが1クロック目=M1ステージという解釈で良いのか不明 ADCが割り込みを送出するタイミング。図を見る限りtCONV終了の次のクロックで送出されるように見えるが名言されていない 割り込みがADCからICUへ送られる時の遅延。常識的に考えればせいぜい1クロック程度だと思うがらしい記述は見つけられない 続けてこんな実験をしてみた MOV ←CST0書き込み。TPU0動作開始 NOP NOP NOP MOV ←TPU0.TCNT読み出し これで読み出されるカウンタの値は1。NOPが2個だと0。これを説明できる条件って結構難しい リードサイクルの1クロック目で値が読み出されていると仮定しても M1ステージの次から2クロック目でペリフェラルのレジスタに書き込まれる。実際に動作するのはさらにその次のクロックから みたいになってしまう リードサイクルの2クロック目で値が読み出されると仮定するとカウンタのカウントアップ開始が1クロック遅延しているとかじゃないと説明がつかない ADCの変換開始をCPUではなくTPU0にやらせてみた。CPUが絡まない分カウント値が減るかと思ったらTGRA+75で増えやがった。どうなっているのw 同期トリガーだから+2増えてADCは66クロック。75-66=9クロック。DMACが4〜5クロックと仮定しても。CPUと無関係な部分で4〜5クロック使われている計算に >>417 パイプライン処理で、レジスタ書き込み要求受付後、レジスタ書き込み完了までの間に次のNOP実行してるからでは? DMACとかはCPUバスが寝てるときに動くから、 いつ寝ていつ起きるかのステップ計算するなんてw まさかw >>420 NOPって何もせずに1クロック消費するだけだと思ったけど違うのか? >>421 マニュアルによれば逆。バス使用の優先度はDMACが最高でCPUが最低 CPUが使用中でない限りDMACは優先的にバスを使用できる >>422 RX使ったことないから、今H/Wマニュアル読んでいるんだけど、 16.2.5 ライトバッファ機能(内部周辺バス) 内部周辺バスはライトバッファ機能を持っており、ライトアクセスの場合は、 動作の終了を待たずに、次のアクセスを受け付けることができます。 ・・・ ここでは、周辺ライトと同時に次命令のRAMリードが行われる例だけど、 バスアクセスに関係ないNOPも同様に周辺ライトと並列実行されると思う。 実験してないし適当なこといってるかもしれないけど 内部周辺バスはライトバッファ機能を持っており、ライトアクセスの場合は、動作の終了を待たずに、 次のアクセスを受け付けることができます。 なお、複数のレジスタに書き込みを行った後、それら書き込みの完了を待ってから後続の命令を実行させ たい場合は、最後に書き込みを行ったI/O レジスタを対象に読み出しと演算を実行してください。書き込み を行ったすべてのレジスタを対象にして実行する必要はありません。 って書いてるから下記ではいけないの? MOV ←CST0書き込み。(ライトバッファに入っただけで、この時点ではペリフェラル動作していない) MOV ←CST0読み込み。TPU0動作開始(周辺バスへの読み込みアクセスは動作終了を待つから結果として、先行しているライトアクセスを完全終了させる → ここからペリフェラルが動く) MOV ←TPU0.TCNT読み出し MOV ←CST0書き込み。 MOV ←CST0読み込み。TPU0動作開始 MOV ←ADST書き込み。 MOV ←ADST読み込み。ADC動作開始 MOV ←CST0書き込み。(ライトバッファへReq) MOV ←ADST書き込み。(ライトバッファへReq) MOV ←ADST読み込み。TPU0動作開始およびADC動作開始 とか 演算やれって書いてるからレジスタ書き込みを確定させるためには ダミーリード単体(ロード命令)だけじゃレジスタ書き込みを確定させるのはもしかすると駄目かもな volatile xxx dummy; ? reg = write_bit(ストア命令 → ライトバッファが絡んで非同期) dummy = reg(リード命令 → ライトバッファが絡まないから同期) ○(演算が必要?) reg = write_bit do { dummy = reg } while ((dummy & write_bit) == 0); 擬似コード書いてないからマニュアルわかりづらいって言われてるんだわ 文字だけじゃ伝わらないっつーのw >>424 自分もその認識。バスアクセスが衝突したりしない限り並列して動作できると考えている >>425 マニュアルのIOレジスタのところに書いてあるSYNC方法?を計ってみたら MOV ←CST0書き込み。TPU0動作開始 CMP ←メモリソースオペランドでCST0を含むTSTR読み出し&演算 MOV ←TPU0.TCNT読み出し で5になった。>>417 の結果と整合するパイプラインとバスアクセスの動作状況を上手く説明できそうにない 現状だとI/Oレジスタへのアクセスは3クロック消費するようだ MOV ←CST0書き込み。TPU0動作開始 MOV ←メモリソースオペランド適当なレジスタを読み出し MOV ←TPU0.TCNT読み出し で3 MOV ←CST0書き込み。TPU0動作開始 MOV ←メモリソースオペランド適当なレジスタ1を読み出し MOV ←メモリソースオペランド適当なレジスタ2を読み出し MOV ←TPU0.TCNT読み出し で6になる。書き込みも同じように見える。ただ2〜3クロックって書いてあるから何かの拍子に2クロックになるタイミングがあるのかもしれない >>430 それパイプラインハザードか何かによるバブル発生が起こって消費クロックが変動しているんじゃないか? (3) I/O レジスタアクセスサイクル数 ・・・ 周辺機能部ではICLK ≧ PCLK(またはFCLK)の周波数関係の場合、内部メインバス1 のバスサイクル 数と分周クロック同期化サイクル数を合わせると、PCLK(またはFCLK)で最大1 サイクルとなるため、 表5.1 では1PCLK(またはFCLK)の幅を持たせて記載しています。 ・・・ 何を言っているのか、理解できない。 日本語wiki https://ja.wikipedia.org/wiki/%E5%91%BD%E4%BB%A4%E3%83%91%E3%82%A4%E3%83%97%E3%83%A9%E3%82%A4%E3%83%B3 本家wiki https://en.wikipedia.org/wiki/Instruction_pipelining#Pipeline_bubble In the illustration at right, in cycle 3, the processor cannot decode the purple instruction, perhaps because the processor determines that decoding depends on results produced by the execution of the green instruction. 日本語wikiは発生原理の例があいまい(何らかの中断〜)な書き方していて中途半端だけど、 本家wikiの方は上記の様に 「3サイクル目で5行目のデコードができていないよ、それは4行目の実行結果に依存して5行目がデコードされるから1クロック遅れるんだよ(たぶんね)」 みたいな事が書いてるね。俺の専門分野じゃないから明言できないけどクロックが1ずれていくのは そういう部分も影響しているんじゃないかな。後は>>432 が書いているデバイス依存による制約とか。 まあ、現代のマイコンスペックでソフトでそこまで突き詰める必要があるかっていわれると微妙というかほぼ趣味の世界だがw >>431 I/Oレジスタはノーウェイトじゃないみたいなのでアクセスする命令を並べるとパイプラインが乱れるはず RX63NとかRXv1コア搭載マイコンのマニュアルにはパイプラインの動作例が書いてあって ノーウェイト以外のメモリアクセス時にパイプラインがストールして後続の命令が待たされる例が示されている >>430 の場合 レジスタ1へのアクセスがIF D E M1 M2 M2 WB レジスタ2へのアクセスが IF D .E - - M1 M2 M2 WB ←「-」はストール バスアクセスがM1を含めて3クロック消費のリードアクセスが2連続 とすると3クロック差とパイプラインとバスの動作状況を上手く説明できる >>432 それ、自分もよく判らない。が2〜3クロックと書いてある以上3クロック前提で書けば書いたとおりに動いてくれそうではある 周辺機能が消費するクロックは相変わらず不明だが >>417 実験する前にマニュアル読めバカ てかさ、なんでペリフェラル使うときにCode Genを使わないんだ。 CodeGen使うかどうか別にして、あのソースを理解することは最低限必要だ 僕ら理科の子 科学の子 今日もみんなで実験の時間だよ?! RTOS使わない、割込使わない、C言語も使わない。一筆書き。最狂wのエンジニア 相対的だが後端がほぼ確定かな MOV ←CST0書き込み。TPU0動作開始 NOP NOP MOV ←ADST書き込み。ADC動作開始 でスタートさせて後ろ付近でTPU0.TCNT、IR102、ADSTを読み出し。安全のためNOPは2つ挿入 TCNT ADST IR102 DMAC 66 1 0 - 67 1 0 - 68 0 0 - 69 0 1 - 70 0 ? 起動要求 こうっぽい。この先はDMACの動作タイミング通りでよさそう。データが出てくるのは2クロック目と仮定するとDMACがコピーしてくる73という数字と一致する ADCが出す割り込み要求は変換を終了した次のクロックでICUがそれをとらえるのはさらにその次のクロックということらしい ループのクロック数を調べていたら謎現象 MOV ←CST0書き込み。TPU0動作開始 NOP NOP NOP MOV ←TPU0.TCNT読み出し これで1なのは>>417 の通り。これをこうしてみた MOV.L #01h, R2 MOV ←CST0書き込み。TPU0動作開始 NOP NOP NOP ?: SUB #01h, R2 BNE.B ?- MOV ←TPU0.TCNT読み出し これで2。マニュアルによればSUBも分岐不成立Bも各1クロックで合計2クロックのはずだが1クロック行方不明になったw R2を2以上にした時の増加分は+4クロック。SUBが1クロック、Bが3クロックでマニュアル通りの値になる ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる