機械語なら俺に質問しろ!その2
■ このスレッドは過去ログ倉庫に格納されています
漏れは今までにC、C++、Pascal、HSP、JS、VBなど
数々の言語を極めてきたがやはり一番手にしっくりくる言語は機械語だ。
だから、機械語のことなら何でも質問しろ!
ただプログラムのコードなんかは長くなるがな。 あ、ASMの話でもいいよ。 >>116
ROMリライト中に動く前提のプログラムってのがまず理解できない。
ROMを書き直す=プログラムを更新するってことだから、その時点で
割り込みベクタテーブルに処理が飛んでくる可能性はゼロではないの。
後だしでプチプチ情報出されても振り回されるだけだよ。 ROMリライト中に動いちゃまずい機能は
ROMリライトの処理中は行わないようにすべきじゃ 風呂に入ってデバッグしてきた。なんとなく状況は理解できたと思う。
1)ROMの一部を書き換える組み込みアプリを作りたい
2)ROM書き換え中はROMへのリードアクセスは禁止
3)ゆえにコードをRAMにコピーしてRAM上で動作させたい
4)リンカーの出力するバイナリはROMからの相対アドレスである
5)RAMにコピーしたコードの関数アドレスを手作業でリロケーションはできない
6)さてどうしたものか
まず2が真の時点でROM上でコードを動作させるのは不可能だから
全てのコードをRAMにコピーする前提で考える。
普通はロケーターを使うんだろうけど、話の雰囲気ではロケーターも
使えないっぽいからそれは考えない。
ならば全ての関数呼び出しを関数テーブル経由にするしかない。
第一段階としてブートストラップローダーを作る。こいつの仕事はROMの
コードを全てRAMにコピーすることと、関数呼び出し用に全ての関数を
呼び出すためのコールテーブルを作ること。もちろんコールテーブルの
関数アドレスはRAM先頭のオフセットを加える。
割り込みベクタテーブルもブートストラップが作成する。
もちろんブートストラップ動作中は割り込み禁止。
次に、関数呼び出しを統括するスーパーバイザー関数を作る。この関数
はブートストラップがRAM上に作った関数テーブルを元に、引数で指定
された関数を呼び出す。こうすることで、関数名=アドレス値がコードに
ビルトインされるのを防ぐ。
ここまで終わったら、ブートストラップがメイン処理に制御を移すだけ。
全ての処理は関数呼び出しに関数名は使わず、スーパーバイザー関数
に対して RAMが狭小で、フルイメージRAMに来れないんじゃないかとエスパー
機械語っていうか、石の話だが、関連雑談だな >>119 おつきあい下さりありがとうございます。10数年前、H8/16bitでそのような物を
作りました。その時はブートローダーの場所はイレーズしない・ROM書き換え/イレーズ
する関数のみRAMに置く、という手法でした。ブートローダーは割込を一切使わず動く
ように作りました。今回は、RAMはブートローダー全部を載せるぐらいたくさんあります。
ブートの目的は、ROMイレーズ・アプリをROMに焼くこと、焼かれたアプリはふつうに
ROMで動作します。電源ONで動くのはブートなので、アプリがROMに入っているか
チェックして、アプリに分岐するか、ROM焼きモードでブートの中で待つかします。
この方式だと、121後半の設定は不要ですね。ブート動作中は割込を使わないのは
今回も採用することになると思います。
>>123 そうなんです。ROM256/RAM32 とか、機種で多少はありますがそんな感じ。
ブートが固定ベクタを占有しちゃうんで、焼かれるアプリは固定ベクタを持たないこと。
ROM実装サイズがいろいろだが末尾に寄せて実装されている。FFFF0000〜FFFFFFFF
とか、FFFC0000〜FFFFFFFF とか。なので、ブートからアプリにジャンプする際には
「固定の先頭番地」 という過去の手法が使えないので、固定の末尾付近(ベクタのすぐ前)
を使うことになるのかな、と考えています。
後出し小出しが嫌われるのは承知していますが、課題全部はまだ承ってないし、
承っても1,2レスで列挙できるものでもないので、そこはご容赦くださいませ。
目下の選択は、ブートはROMで動く事にするか、ブートの主要部をRAMに転送するかで、
前者は実績があります。後者だと121の前半みたいなお膳立てをPGがやるわけですね。
う〜ん、厄介そうだなあ。 インテルの再配置ローダーみたいなツールがあればいいのに。 組み込みじゃなくてすまんが、ローダ付きのCOMファイルみたいのを連想するw > インテルの再配置ローダーみたいなツール
転送時点で再配置しとけばいいだけでしょ
読み込んでから再配置しようとか、難しく考えてるような EXEファイルと違ってROM上の実行コードには再配置情報は残っていません。
私が過去に実現したのは、再配置情報を含まないことが確認済みの関数だけを
RAMに転送してコールするという手法でした。 hexファイルに再配置情報がないのだから
移動先のアドレスで動くhexファイルを作っておいたらってことだけど
移動先に移動させる仕掛けはどっかに必要だけどね
ROM、RAM領域のアドレスが移動できるarmで
boot時にROMは0から見えるけど
最終的には上位番地でROMの実行コードが走ることをやったことある
(RAM領域は最終的に0番地から見える) reloc情報つきのモジュールを置いて、それを自前ローダにくわせてはだめなんか
超小型車輪の自社開発みたいになるが
感覚的には
void* loader(void* _code, int _codesize, WORD* _relocs, int _relocssize); >>128 実行空間と格納空間を別に指定できるLINKの仕方がHewにあるかどうか
なのですよ。ビルド−ツールチェイン−リンカのタブにそれっぽいのが無いみたい。
それがあれば、例えばFFFF0000番地にロードするイメージを00100000番地に格納
みたいなことができるのですけどね。ただ、コンパイラのマニュアルにpic,pidオプション
ってのがある所から見ると、copyしても動くようなオプションつけてビルドしなさいと読める FFFF0000番地にロードするイメージのhexファイルを一度作って
00100000番地に格納出来るhexファイルに加工するほうが
悩まなくて済むような いや、だからそれは再配置情報が失われているって(w コンパイラマニュアルのリンケージエディタの使い方:セクションオプションの章を見ると
>>130 みたいな割り付け方法は無さそう。なので一般的な手法としては pic,pid 指定を
付けてビルドし、130の例で言えば00100000番地でリンク、実行時にFFFF0000番地へ
copyして実行、という流れになると思います。固定ベクタのResetVect(再末尾)は
ROMの実行開始部を指し、そこは最低限RAMへcopyしてジャンプするコードを置く。
Hardwaresetup( ) の部分なんかはRAMで実行する必然性は無いので、reset時ROMで
実行してもかまわないでしょう。ただ、「RAMで実行することが必然」 な機能が何かという
ことを考えてゆくと、以前の仕事みたいにROMとRAMを行き来する手法もありかな、と。
後者の利点は、CODEを置くためのRAMが少量で済むこと・再配置情報が無いルーチン
だけを置くことで再配置問題を回避できること。 開始アドレスだけかえて複数のhexファイルつくって、
比較して、reloc情報を起こせばいいんじゃないかと
そんなので済むかって?
そんなので済むように書けるのが、機械語じゃないかw 以前書いたブートコードは、割り込みを使わずuartはポーリングで書いたのですが、
今回の石ではその手法は使えないことが判りました。なんと、uartのステータスregに
RXRDY,TXRDYのフラグが無いの(*o*) だから受信・送信のトリガーは必ず割り込みで
取らないといけない。 これで解らないのがベクタとpic,pid機能との関連。
ベクタ(=割り込み処理コードのアドレス)、処理(=ROMの10000番地に実行コード)
このベクタと処理をRAMの100000番地に書き写したとしても、ベクタの指す先はやはり
10000番地のままだから、割り込みが発生したら10000番地が実行されてしまうよね。 UARTをいつも見張ってると、CPUの手がそんだけ取られてるような ROMとRAMが同じアドレス空間にマップされるというマッピングが
そもそもあり得ないんだけど。かりに意図してそうしているのなら
何らかのバンク切り替えメカニズムもあるはずだよね。 >>138
ああRAMは0が1個多いのか。
で、ROMのコードを実行する意図でないのならベクタの中身も
書き換えてRAMでrunさせるのは当然じゃないの。 >>100 の疑問の答が貰えました。やはり>>117で正解でした。メーカーの人って
頑張るかと思ったけど、意外に素直にマニュアル間違ってますと認めちゃうんですね。 PICを吐くようコンパイラに指示してビルドしたけど、ベクタの中身は変わりませんでした。
原理的には想像はついてたんだけど、実際に出会ってみるとガッカリ。
ポジションインディペンデントであってセルフリロケーティングなわけじゃないもんね。
命令中の実アドレスは(再配置を要するものは)一切ダメ、ってルールブックに書いて
おけばいいのに、そこの所をマニュアルではぼかして書いてあるの。 そんなもんコード上で書き換えないと変わるわけないじゃん。
そんな至れり尽くせりのコンパイラなんかどこにもないぞ。 これは実際に製品にするので、その辺をどうするか手探りしているところです。
石はRX210、内蔵ROM/RAM=128〜512/16〜64 ぐらい、cコンパイラの拡張機能で
専用の特殊regをいじる組込関数が提供されてます。set/get_btbl( ),set/get_psw( )等
RAMの実装番地は0番地からなので、copyしたら0番地に飛ばす、あるいは特定の低い
番地に飛ばすのは可能ですね。
古代のメインフレームでは BALR USING という手法でセルフリロケーティングなコードを
書きやすくしてくれたのですが、メモリが激安の現代にそんな手法がなぜ無いのだろう・・・
あ! ROMライタにはそういう機能があったなあ。コードは0番地で動くようにLINKして、
ROMに焼くときに元のコードのロードアドレスにFFFF0000を足して転送、という機能。
(昔のライタなので8桁はムリだったかも) ルネ提供のライタにそういう機能があるかな。 ちょっとどうかなと思う発想もあるが、正直よその石のことは想像でしか聞けないし、
雑談ネタを投下してくれてると思って流し読みすればおk 打診が来てから3ヶ月、未だに仕様のカケラも来ません。仕方なく石のマニュアルから
お試しコードと、過去の情報からアプリの下書きを書いてます。こういうのがあると
仕様が来だしたときちょっとした手直しで目的のコードにできるから。
ソフト会社だと仕様が来てから動くしかないから、こんな時点では動けないし、
仕様が来たときには納期が破綻してるというケースばかりでした。
>>137 通信以外には何も無い、内蔵ROMライターみたいなアプリでした。
ROMに書いてレディを待つ貼りつきの間、割り込みが使えないのでそこでポーリング。 それってまだお金もらってないってことだよね。
そんなんで先行投資しちゃっていいの?
こっちが心配することじゃないけどさ。 お金はいずれ貰えます。ハード屋さんは私に発注することを上司に承認取った上で
少し高い石を選びました。 ハードが一段落したらソフト要求仕様を書き上げそこで
一般のソフト会社に投げるネタになります。そこから見積もり依頼→見積もり→承認。
出来レースにしないために相見積もりしてもらうのもかまいません。partの合間なので
フルタイムなら1人月分ぐらいの先行かな。生活のためではなく面白いからやってるだけ
で、自分が今のソフト屋と比べて仕事がのろいのは自覚してるから、本決まりになって
から間に合うように、先回りできる分野は先に片づけるようにしてます。
本格start以降の期間には、ダンピングの非難が出ない程度のお金は貰います。
>>130-135 辺りの問題は、石の設計思想にその解決手法が用意されているようです。
内蔵ROMの空間が2とおり用意されていて、小さい方の空間で実行している時もう一方
の大きい空間のイレーズや書き込みを実行すればアクセス違反が出ないとの事らしい。
マニュアルの自然言語の表現で、ある文脈のROMがどちらを指すのかあいまいなので
そこを再確認待ちです。 私はRAM空間用にLINKしたコードを小さい空間に焼いて、
起動時RAMにコピーしてそこへ分岐、という手法を試していましたが、これでラッキー。 >>148 の再確認はOK貰えました。 以前はROMがbyte書込だったので問題ない事が
今回はword書込で問題になることが見つかりました。
S30AFF7FC080EF773B1D0E6B 最後C084 に ライト、
S315FF7FC0885645523F00000000A4C57FFF522000009F C088からライト
S314FF7FD26023F3601158117125FF405102660102BA D260〜D26Eにライト、
S315FF7FD26F7F957F957F957F957F957F967F957F958A D26Fからライト
1行目の末尾 C084の0Eは、0EFFにして書き込まなければならない。
3行目の末尾 D26Eの02は、02FFを書いてはならない。その次の行の
D26Fの7Fが来た時点で初めてD26Eに027Fを書いてよい。
どのように実装しようか考え中です。 なんつーんだっけ? Sファイル?
そいつを運用で奇数バイトから始まるものは受け付けないってできないの?
そういう折衝する可能性も考えずに言われたままにほいほい実装するの?
つーか、そもそもそ半端なワード(2バイト領域)はROMから読み出してから
書き戻せばいいんじゃないの? クリア済みが保障されているならクリア値で
埋めればいいんじゃないの?
土方は何も考えない分気楽でいいなぁ。 そう。モトローラのSフォーマットファイル。ふつうのリンカが出力したファイルですよ。
それを運用で焼いてあげませんって処理系に言われたらヤでしょ。
クリア値で埋めるのも、パソコンなら1MB用意してもいいでしょうが、
ROM16KB/RAM16KB ぐらいの空間で動くように実装するんです。
したがって流れの中で解決する必要があります。イレーズは全部いっぺん、
ライトはアドレス・データであちこちに書けますが、2度書きはできない (しない) のが
原則ですね。 ROMの性質上、xxFFのワードにxxyyを上書きするのは可能だろうと
思いますが、マニュアルで保証されてはいません。
半端なバイトを取っておくようなアルゴリズムを書いてみたのですが、いまいちすっきり
しません。ROMから読み出すアルゴリズムのほうがスマートなのは確かなので、
xxFF→xxyy FFvv→xxyy の重ね焼きが可能か、メーカーに質問投げてみますね。 >>103 へうでのリンカスクリプトの使い方がやっと判って、スタックの割り付けも臨む
場所にできました。ビルド−ツールチェイン−最適化リンカタブの中の、セクション
カテゴリーを開くと、アドレスとセクション名の対応が表になっていて、それを編集
するのですね。-start=B_1,R_1,B_2,R_2,B,R/06000,SI/07D00,PResetPRG/0FF7FC000,
C_1,C_2,C,C$*,D_1,D_2,D,P,PIntPRG,W*,L/0FF7FC080,FIXEDVECT/0FFFFFFD0
自分でこういう制御文をコマンドラインに書くのに慣れていたので、どこにそういうの書く
のだろう??と。
へう推奨のセクション割り付けパターンが、アライメント1,2,4の順なのですね。
これがまた違和感。従来はアライメント4,2,1でした。勿論自分でそういう指定に
直すことはできるのですが、この推奨パターンにはどんな意味があるのでしょう?
あと、コード部配置順も、resetprgが先頭、以下定数、実行コード、割り込みコード、
ラベル、文字リテラル という推奨順なのですが、何で定数の間にコードを挟むのか
理解しずらいんですよ。 ×臨む
○望む
×理解しずらい
△理解しづらい
○理解しにくい 校正どうもです。 のぞむなんてどこで書いたか忘れて探してしまった(w 打診のときは移植みたいな話だったのに、機器がみなネットワーク対応になってるから
ネットワークプロトコル実装しなくちゃいけないっぽい・・・アプリ本体よりそっちのが余程
でかいじゃん。 >>135 で、ポーリングは使えないと書いたんですが、RXRDYのステータスをポーリング
あうるのではなく、受信割り込みがあったことをポーリングすればその手法自体は書ける
ことに気が付きました。 「入力が入り次第すぐそれを使う」 という点で一貫してるので、
単純なプログラムを書くには適した手法でした。わざわざその手法で書き直す必然性は
ないので後戻りはしませんけど。
RXシリーズは、石の設計思想にコンパイラやOSの存在が組み込まれていますね。
SIとSU(割り込みスタックとユーザースタック)が別 とか、特権命令があって、PSWの
スーパーバーザーモードとユーザーモードを区別するbitにより例外を発生させるとか。
でもMAX50MHzでWinみたいなマルチタスクを実現するわけでもないし、OS無しで
単純ループで書いてるだけだとこの設計思想のありがたみは感じないなあ・・・
電源でなぜいつも苦労するのかは、どなたか判りますか? LAN通信機能は不要だそうです。serialのみ。 これならなんとかなるかな。 飛び込みで8085の仕事が来た・・・CPU以外にも 8251 8253 8255 どうやって石調達
してるんだろ? 結局ここで推敲してもらったstpcpy( )は使わなくなってしまいました。 >8251 8253 8255 どうやって石調達してるんだろ?
量産でなければ普通に手に入る。秋葉原の店頭でもまだ見掛けるし。 汎用チップの需要って案外ワンオフとかであったりするんで
ロット納品とかでなければ普通に売ってるよ。 チップバラで買ってハンダ付け名人のおばちゃんが組み立てるのか〜・・・
手作りはお互い様ですね。今朝HEXを送信しました。 256のROMまだあるのかな? その後4回手直ししてHEXを送付しました。全部パツイチで動きました。
ふつうのソフト会社なら30分の仕事にする所、暇なので16hもかけてしまって\3マソ(w
明日から本業のRXに戻れるかな uartに割り込み来ない・・・と思ったら、PMR,PDRより前に
マルチファンクションピンコントローラのレジスタ設定が必要だったorz
しかもこっちの章が後なのに設定は先とか・・・もうね、意地悪! まだ割り込み来ない・・・やったこと:hwsetupで、マルチファンクションピンコントローラの
P20〜P33PFSでTXD/RXD端子に設定、PORT3.PMRとPORT2.PMRでTXD/RXD使用、
ICU.IPR[218]と[226]=優先度2、IER[27]と[28]=0Fと3C(SCI1,6のERI,RXI,TXI,TEI許可)
リセット直後でINTBに可変ベクタテーブルの先頭設定、hwsetup( )から戻った所で
set_psw( )でPSWのIbitをオン。SCI1と6のSMR,BRR設定してSCRに50h(REとRIE)書いた。
これでシリアルにデータ入れても割り込み来ない。uartのレジスタの辺りダンプすると
みんな00になってる。BRRやSCRやRDRは非ゼロが見えるはずなのに・・・
何かまだ設定忘れてる?? と、思ったら、モジュールストップレジスタというのがあって、ユニット毎に動作を開始
しなきゃいけないようになてましたね〜 >>167さん、基本中の基本をご存じなら
>>166あたりで指摘してほしかったですね〜 結果はもうじき来ます。 基本中の基本って言われたら
基本を調べるよなふつう つーか、私だって全てのCPUのレジスタ構成を把握しているわけじゃないもん。
自分が使うCPUならレジスタ構成を把握するのが基本だろって話だよ。 自分が使うユニットの章しか読まないでコードしてもなんとか動いたんですよ、H8Sとか。
概要の章に、何章までは全部読んで理解しないと使えないよ的な前置きが欲しかったな。
1600ページもあるの、全部なんか読んでられないわ。 モジュールストップ解除したら動きました。やれやれ・・・
タイマ割り込みが来ないのもこれのせいでした。この石は省電力が売りなので、
使わないユニットにはクロックを送らないことで省電力を実現してるんでしょうね。
これでやっと本来のアプリのデバックに入れます。 評価セット借りてきて、自分のパソコンにつなぎました。
ドライバのインスコで神経すり減らしたけど、動いたら快適。
DATAflashの書き込みと読み出しがうまく行きました\(^o^)/
同じ手法で内蔵fROMの書き込みもしてるので、この先Sレコードの書き込みも
うまく行きそうです。デバック用にWDTリフレッシュ殺して動かしてますが、
うまく通信できてます。 で、忘れた頃にWDT入れたら、真っ青になるとw
# 茶化してるだけねw FFFFFFFC番地に入っているアドレスに飛ばすc文はどう書けばいいですか?
( (void*)(0xFFFFFFFC) )( ); ってやると、FFFFFFFC番地に飛ぶ命令が出ちゃう。 >>177
ポインタサイズが32bitと仮定すると
unsigned long pl;
void (*func)(void);
pl = *((unsigned long *)(0xFFFFFFFC));
func = (void *)pl; 普通にこうすりゃいいだろ
((void (*)(void))0xFFFFFFFC)();
分かり辛いなら
void (*func)(void) = (void (*)(void))0xFFFFFFFC;
func(); (*((void(*)(void))(*(unsigned long *)0xFFFFFFFC)))();
こうかな…?手元に環境が無いのでちょっと自信ない >>180
斜め読みしてたすまん
こうだな
(*(void (**)(void))0xFFFFFFFC)() 機械語スレでCごとき高級言語とか
# デスクトップでも__asm は試作で重宝してる asmすらこのスレにはふさわしくないんだよなあ
emitしないと >>182さんので通りました。 ありがとうございます。
MOV.L #0FFFFFFFCH,R4
MOV.L [R4],R5
JMP R5
このcはasmの行を挟み込む機能は無くて、asmのインライン関数を吐かせるんです。
判らなかったら、#pragma inline_asm func
void func(void) { } の中に上の3行を挟んで書こうと思っていました。
「ポインタのポインタ」 で理解するより3行のasmのほうが私には理解し易いですね。 分かり辛いなら
typedef void (*funcptr_t)(void);
funcptr_t* p_func = (funcptr_t*)0xFFFFFFFC;
(*p_func)();
とか >>185
ポインタのポインタが解りにくいというより
C言語の関数ポインタの書式が分かりにくくしてる原因だと思う そうですね。asmでの理解ならすんなりいくのに。
ユーザーブート領域のプログラムをデバックしようと思って、その空間でLINKした
コードをダウンロードして、リセットベクタをそこを指すようにして実行してみると、
対象領域がみんなFFになってる。未実装として読まれてるみたいです。
端子2つと特定番地の内容でブートモードになる、とマニュアルに書かれていたけど、
なるほどこういうことだったのか。リセットベクタを含む固定ベクタはアプリにだけLINK
するものですね。起動時にそういう端子入力ができるようにハードを直してもらいます。 機械語オーライなら、もちろん、call convention は気にするよな?
組み込みのCの処理系がどうとなってるか詳しくないが、
typedef int (__cdecl* myfuncptr_t)(int, int);
とかって書くようにしてるぞ。 __cdecl がデフォルトだったと思うので
__stdcall しか書かないな SCIの受信とDMACを連携して動作させられるじゃないですか。あれってバイト数は
DMACに設定するんだから、何バイト来るか判っている場合にしか使えませんよね? DMACは基本的に固定長のデータ転送に使うものだから
不定長のデータには使えない。 watms(int ms) 関数が素通りしてるっぽい・・・ RX210
void waitms(int ms) { hwsetup( ) で MSTP_CMT1 = 0; はやってる。
// 入力:ミリ秒単位の数値(50mSまで)。誤差の少ないwait関数。
CMT3.CMCOR = PCLK/128/1000*ms; // 1KHz(1mS)の分周値*mS
CMT3.CMCR.WORD = 0x00C2; // Φ/128 セレクト,CMIE3許可
CMT.CMSTR1.BIT.STR3 = 1; // カウントUP start
// do { } while( CMT3.CMCNT ); // 一致を待つ
// ↑CPUマニュアル 25.2.4には、一致するとCMCNTは0になると書かれているが
// 0である128clkの間、別の割込で他の箇所を実行しているかもしれない。
// そこで下記の割り込みを待つようにする。
do { } while( CMT3.CMCR.WORD & 0x40 ); // 割り込みを待つ
}
#pragma interrupt(Excep_CMTU1_CMT3(vect=VECT_CMT3_CMI3))
void Excep_CMTU1_CMT3(void) { // 1mSタイマ割込み処理 13.02.28
CMT3.CMCR.WORD = 0x0082; // Φ/32 セレクト,CMIE3禁止
CMT.CMSTR1.BIT.STR3 = 0; // カウントUP stop
} これで1msのn倍waitできると思ったんだけど、すぐリターンしてくるみたいなの volatile?
機械語じゃなくね?w
保守してくれてるとおもって気にしてないが 素通りしてるとか言う前に吐かれたマシンコードを見るのが
先じゃないのかな。 ああ、「マシンコード」か。見慣れない字面だから空目してびっくりしたわ。 マシンコードは見たんですよ〜 すぐ気が付くようなミスは無かったと思う。
CMT3.CMCOR = PCLK/128/1000*ms; // 1KHz(1mS)の分周値*mS
MOV.L #00088000H,R4
MUL #90H,R1
MOV.W R1,1CH[R4]
CMT3.CMCR.WORD = 0x00C2; // Φ/128 セレクト,CMIE3許可
MOV.W #00C2H,18H[R4]
CMT.CMSTR1.BIT.STR3 = 1; // カウントUP start
MOVU.W 0H[R4],R5
BSET 01H,R5
MOV.W R5,10H[R4]
do { } while( CMT3.CMCR.WORD & 0x40 ); // 割り込みを待つ
L26: MOVU.W 18H[R4],R5
BTST #06H,R5
BNE L26
RTS void Excep_CMTU1_CMT3(void) { // 1mSタイマ割込み処理
PUSHM R4-R5
CMT3.CMCR.WORD = 0x0082; // Φ/32 セレクト,CMIE3禁止
MOV.L #00088000H,R4
MOV.W #0082H,18H[R4]
CMT.CMSTR1.BIT.STR3 = 0; // カウントUP stop
MOVU.W 10H[R4],R5
BCLR #01H,R5
MOV.W R5,10H[R4]
POPM R4-R5
RTE do whileの脱出条件が間違っているようにしか見えない。
そもそもなぜdoなのか。通常のwhileではできない理由があるのか。
そこらへんが理解できないな。
あとコンパイラによってはdo { }が空文だと最適化でコードにしない
ものがあったりするので(昔のMS-Cとかね)最適化オプションは
全てオフにしてから確認するといいかもね。 >>198 で、18h[R4]にC2hを入れてから、L26:の所でそこのbit6が1の間ループ。
>>199 の割り込み処理で 18h[R4]を 82h にしてます。 あ、書いてる途中でレスが・・・ while { } だと前判定、do { } whileだと後判定になるから。
今のケースの場合は一緒ですけどね。前判定だとBZ で脱出、その後ろに B 続行
ってなるのがイヤだから、ってのもあります。 見つけた〜!とおもう。hwsetup( )で MSTP_CMT1 = 0; // CMT unit1のクロックON
とコメントに書いてあるけど、これがウソで MSTP_CMT2 に0を書くべきでした。
SCIで体験した事だと、ユニットにクロックを与えないとレジスタにイネーブルを
書けなかったから、コンペアマッチタイマもそうだとおもう。
今基板帰してるから、また借りたら確認しますね。 基板につける原クロックって水晶ですよね。CPU内蔵のクロック発振器ってどんな
原理なんでしょう? RC 発振器 でぐぐったらwikiが先頭に来たけど、余計解らない語句ばかり出てきた(w
何となくだけど、どの原理もLSI内部に納めるほど微小化できるのかな?とは思った。
基板は、ユーザーブート領域に焼く方法の所で引っかかってるみたいです。 >>204
CPU内蔵ならクリスタルじゃなくてPLLじゃないの。
たぶんクリスタルよりPLLのほうが正確だし。 あ、なんかPLLも基準周波数にクリスタルがいるらしい。
勘違いだったかも。 CPU内蔵のPLLは、基準周波数を分周または逓倍するために使いますね。
204の話は、CPUみたいなLSIの内部に焼き付けられる原クロック回路は、
クリスタルみたいなデカいものじゃなさそうに思えるけど、どんなものなのかなあ・・・ ユーザーブート領域のコードが動いたらしいです。私が確認に行けるのは木曜ですが x86-64の64ビットモードで動かない32ビットx86の命令ってどんなものがありますか? DAAとかなくなったんでなかったっけ?
あとLAHFとか。 ユーザーブート領域のコードが動いたのは誤報でした。FF7FC000〜の空間には
コードが焼けない/読めない状態のままです。困ったなあ・・・ RX210 規制の間に本番用の基板でデバックが進みました。
デバック用の基板ではユーザ空間しか焼けませんでした。
ユーザーブート領域に焼いても、そこで実行したコードでROMアクセス違反は
発生します。ROMを焼くコードだけRAMにコピーしてそこを呼ぶ手法を採りました。
欲しい機能の実装はだいたい確認。引き合い時2人月だったお金も、3.5人月
もらえました。36度の書斎でのデバックは2,3日で済みました。やれやれ・・・ 汗が基盤に垂れなかったのだろうか
いや、液状のほうの汗なw 書斎が32度以上のときは、アイスノンを頭に巻いて
30分ごとにリビングに避難しながらやってました。メインは未明の頃。 8085ではメモリマップトI/O(ex:F000番地が8251のTXD/RXD)しか
やったことがないのですが、8085にもIN/OUT命令はありますよね。
オペランドは8bitのアドレス。
このIN/OUT命令を使うときはハードをどのように組むのですか? もうちょっとくやしくお願い。名前からすると「メモリじゃないよ」という信号みたい
ですね。 IN 04h と書くと、メモリではない04番地からリードですね。
そのとき8251を04番地に配線?すると上と同じ機能が得られるのですか?
私が出会ったのは217のようなシステムばかりでしたが、それは偶々?
8251側ではRD/WR信号とアドレスのLSBでI/Oレジスタを区別していましたが
IN/OUTを使おうと思うとその辺はどうなるのでしょう?
LDA/STAは3バイトだけど、IN/OUTは2バイトだからこっちのほうが小さいけど
そういう理由ではハードは決めないのですか? ■ このスレッドは過去ログ倉庫に格納されています