図のCR回路において、スイッチをONした時の電流i(t)を求めてみよう。
まずは方程式をたてる。
R i(t) + q(t)/C = E(t)
これが解くべき微分方程式である。
ラプラス変換すると
RI＋Q/C＝E/s ----- ①［E(t)は単位応答］
電荷q(t)と電流i(t)の関係は
dq(t)/dt = i(t)
両辺をラプラス変換すると
ｓQ－q(0)＝I
Q＝I/s＋q(0)/s 初期値q(0)＝0であるから
Q＝I/s これを式①に代入すると
RI＋I/sC＝E/s
(R＋1/sC)I＝E/s
I＝E/s / (R＋1/sC) 分母分子にsをかける
I＝E/(sR＋1/C) 分母分子をRで割れば
I＝E/R /(s+1/CR) ----- ②
さて、逆ラプラス変換する準備ができた。
e^at →ラプラス変換→ 1/ (s-a) ［変換表より］
であるから、式②を逆ラプラス変換すると
i(t)＝E/R e^-(1/CR) t となる。
スイッチをONしてから時定数（CR）後の電流値は
i(t)＝E/R e^-1 であるから
i(t)＝E/R ×0.368 である。
つまり最大電流E/Rの36.8％になっている。ということはこの時点においてE/Rの63.2%が電荷として蓄えられCの端子電圧になっているということになる。
関連記事：
時定数の別解 2009-05-25
微分法則 2009-05-13
まずは方程式をたてる。
R i(t) + q(t)/C = E(t)
これが解くべき微分方程式である。
ラプラス変換すると
RI＋Q/C＝E/s ----- ①［E(t)は単位応答］
電荷q(t)と電流i(t)の関係は
dq(t)/dt = i(t)
両辺をラプラス変換すると
ｓQ－q(0)＝I
Q＝I/s＋q(0)/s 初期値q(0)＝0であるから
Q＝I/s これを式①に代入すると
RI＋I/sC＝E/s
(R＋1/sC)I＝E/s
I＝E/s / (R＋1/sC) 分母分子にsをかける
I＝E/(sR＋1/C) 分母分子をRで割れば
I＝E/R /(s+1/CR) ----- ②
さて、逆ラプラス変換する準備ができた。
e^at →ラプラス変換→ 1/ (s-a) ［変換表より］
であるから、式②を逆ラプラス変換すると
i(t)＝E/R e^-(1/CR) t となる。
スイッチをONしてから時定数（CR）後の電流値は
i(t)＝E/R e^-1 であるから
i(t)＝E/R ×0.368 である。
つまり最大電流E/Rの36.8％になっている。ということはこの時点においてE/Rの63.2%が電荷として蓄えられCの端子電圧になっているということになる。
関連記事：
時定数の別解 2009-05-25
微分法則 2009-05-13
コロナ社刊・電子工学
まあ私が少し本格的にやりはじめたのは30前でしたから、昔と言うより今なのかも知れません。真空管もまったく知らないですしね。
あの歯の上の斜面部分はＣＲの包絡線状だったのです、昔のヤツは・・・。
だから、モトローラのＲＧＢコンバータはそいつのことを「ランプ曲線」と表現していました。型番は忘れましたけど、内部の等価回路は完全なバイポーラタイプだったと記憶しています。
２０年以上前のことですけどね！
でも垂直に立ち上がるノコギリ波って作るの難しいと思いません？サイン波は発振で得られるし、サイン波をコンパレートすれば矩形波ですよね。矩形波を積分すれば三角波。しかしノコギリ波（ランプ波）は．．．、どうやって作るの？あくまでもアナログでということで。近いのなら幾つか思いつきますがねえ。
どうしてもＣＲが介在するので、ランプ系の歪み（？）は避けられないと思います。
デジタルでオールソフトもしくはＤＳＰ、ＦＰＧＡ、ＣＰＬＤ等でＨＤＬ記述でハードを構成するしかないと思います。
デジタルでフィルタも構成できますからね！
ただ、ここでいうデジタルにはＴＴＬやＣＭＯＳゲートなどは含まれていない・・・ということです。
ＣＰＵのカラクリを身に付けるには、自分でつくるのが一番いいです。とはいっても、ゲートを組み合わせていたのでは１年かかっても達成できないかもしません。
ＨＤＬって、古くからのハード屋さんにとっては、ものすごく大きなハードルです。私もわかりませんでした。
キーワードはやっぱり「Ｃ言語」ですね！
「Ｃ言語」を扱うプログラマになって仕事するようになってからＨＤＬにもトライしたらわかるようになりました。
今やハードもソフトも同じ領域なのですよ！
ですから、ＰＣ上でいいですから「Ｃ言語」を自在に扱えるようになれるようなトレーニングをされるといいと思いますよ！
１０年前に私がやっていたのはまさにソレでした。
プーしている時に必死で「Ｗｉｎｄｏｗｓプログラミング」をやっていました。Ｗｉｎｄｏｗｓ３．１でまともにできなかった私がＷｉｎｄｏｗｓの３２ビット環境で動作するプログラミングを学習してたワケです。
おかげで、そのときに「Ｗｉｎ１６」と「Ｗｉｎ３２」の違いがよぉ～っくわかりましたけど・・・。
ＭＳ－ＤＯＳ時代から、アセンブラ（ＭＡＳＭ）やＣは使っていたので、そのような土台があったのは確かですが、それがＷｉｎｄｏｗｓプログラミングに役立つということはないです。
むしろ、組み込みプログラミングですね、ＭＳ－ＤＯＳ時代のテクニックは・・・。
Ｗｉｎｄｏｗｓ９８～Ｗｉｎｄｏｗｓ２０００の頃は、ＰＣ－ＵＮＩＸで遊んでいて、このときにかなり体を悪くしました。４０になる前のことです。
Ｃ言語はＵＮＩＸでたくさんやるハメになりました。動作しないドライバに自分で手パッチすることになったり、バイナリが動作でなかったため、ソースを入手してコンパイルしてたり・・・一応、基本はここでつかんでいたのかもしれませんが・・・。
もし、「これからやろう！」という気があるのであれば「Ｗｉｎｄｏｗｓ」で「コンソールベース」の「Ｃ言語プログラミング」をおすすめします。組み込み方面にも応用が利きますし・・・。
そんな時は一旦やめます、私は。
とつぜん「フッ！」と思い出したかのように、その後解決できちゃうことが多かったですね！
シグマデルタのときなんか、１年近く放置してました・・・仕事ではないんで、それでよかったのですが、エンドが決まっているとそうもしてられませんけど・・・。
これも「性」ですかね？（おぉ～、佐賀！なんちって。）
さて、いろいろアドバイスありがとうございます。まさに今の私にぴったりというか、たぶん本質的問題なんでしょうね。とにかくC言語を自分の腕のように使いこなせるようになれば、いろいろなものが見えてくるわけですね。たぶんその通りなんだと思います。その意味では私はまだまだですね。H8を使ったといっても、まずCPUに何をさせたいかというのがあって、その目的を実現できる部分をネットや書籍から端折って取り出してくる。それを積み重ねてとりあえずの最終目的に達しましたので、C言語を使ったといってもボロボロの歯抜け状態です。それに、もう1年近く離れてしまったので、またほぼ白紙の状態からスタートです。C言語は一旦腰を据えて、頭の中に一本新しい線を入れ込んでしまわなければいけませんなあ。
CPUを作るというのは、確かその手の本（漫画本）もありましたよね。あと20歳若くて時間と暇があればぜひやってみたいと思いますが、今からでは無理だしあまり意味もないでしょうね。
「今やハードもソフトも同じ領域なのですよ！」
このあたりも核心部ですよね。よく分かる気がします。ともに片方だけでは成り立たないんですよね。相補性があるということでしょうね。恐らく。
「熱くなっているときは案外見つからないことが多い。そんな時は一旦やめる」
これも身をもってわかりますねえ。私もよく外を散歩したり、テレビゲームをしたりしながら進みました。「ときめきメモリアル4」というゲームにはまって、結局完成までに費やした時間は「ときメモ4」の方が多かったですね。