2016年09月29日

Open.Theremin@Teensy3.xへの移植が難航する

Teensyにおける内蔵Timerのハンドリング方法の解明が必要なのだが、探しても必要な情報になかなか行きつけない。

Teensy3.2にはFTM(フレキシブル・タイマー)が3系統×8ch装備されていて、このうちFTM0は16bitのデータを扱う。

現在、トリガーによってタイマーの数値をキャプチャーする(筈の)ダミーのスケッチを試しているが、何故か「構文の不備」を指摘されてしまってコンパイルが完了しない。 実質的な処理を何も行わず、エントリーレベルで拒否されている原因は何故なのか? また別にマクロが組まれているパターンかもしれないので、ひとまずはここを漁ってみることにしている。

一方、Timerを使用するには立ち上げ時のセットアップが必須なのだが、その点に関してはこの記事がヒントになりそう。

http://www.digitalmisery.com/2013/06/timer-input-capture-on-teensy-3-0/

追記;


M4系に搭載されたTimerのキャプチャー入力について。 アップエッジでトリガーが掛かるように設定できる。

WS000707.JPG

端子は328系のものと同じく固定だった。 従って、チップの機種依存は確定的で、Teensy3.2/3.6間に互換性の維持は難しい事が判明した。

3.2に搭載されているチップのマニュアルから、オシレーターの入力が行えるカウンタ FTM0 関連の入力端子が、ALT4のファンクション設定においてPC0からPC3 に限定されることが判った。 

WS000708.JPG

これに対応する物理配線は#9・10・22・23pinで、基板の配線もこの4つに仕切りなおした。 なお、ALT3でもFTM系列の端子を引き出すことができるが、Teensyでは該当する端子がMCU/KL02に接続されているために、使用は不可となる。

WS000704.JPG

現時点ではTeensy3.6の回路図が発表されていないため、物理的な配線の詳細は不明。 よって、端子の共用は困難となったが、基板上の配線の引き回しが限界にあることもあり、折衷案としてジャンパー線で端子を選択できるように工夫している。

WS000705.JPG

スケッチの方も、DACの出力を2pin分ズラす形に変更となった。 こういった場合に、ピン配列が抽象化されたマクロは便利だが、その場合も回路図は必須。

WS000706.JPG
posted by Yasuski at 23:39| open.Theremin

Open.ThereminOnArduinoMega@INT0をICP4に付け替える

昨日からの勢いで、回路を改変して実験を行ったところ、一発で動いた。 なお、アンテナが仮設なので演奏内容はメタメタ。



改変した内容は、余っていたカウンターの入力を活かして、ヴォリューム側の差分データを読み込む回路の構成で、まず最初に端子の状態をプリセットするためのデータをレジスタに書き込むことから始めた。

#define PC_STATE (PINL&(1<<PORTL1)) //mega ICP5
#define PC_STATE2 (PINL&(1<<PORTL0)) //mega ICP4


下談のPC_STATE2が新たに書き加えたコードで、ヴォリューム側の入力ポートをINT0からICP4に変更している。

次に、レジスタの設定を行うが、ここもコピペしたあとで指定するレジスタの数字を書き換えるだけでOK。

TCCR5A = 0;
TCCR5B = (1<<ICES5)|(1<<CS50);
TIMSK5 = (1<<ICIE5);

TCCR4A = 0;
TCCR4B = (1<<ICES4)|(1<<CS40);
TIMSK4 = (1<<ICIE4);


最後に、ディテクトを行う部分のコードを書き換えるが、これもピッチ側のコードをコピペした後、対応する数字と文字列 pitchvolume に変えるだけ。

if (PC_STATE2) deb_v++;
if (deb_v==3) {
cli();
vol_counter=ICR4;

vol=(vol_counter-vol_counter_l);
vol_counter_l=vol_counter;
};
if (deb_v==5) {
flag_vol=true;
};

ISR (TIMER4_CAPT_vect)
{
deb_p=0;
};


以上の作業で、入力端子ICP4でヴォリュームアンテナに対応することができた。

このメソッドを応用してTeensyにシステムを移植出来れば良いのだが、、、。
posted by Yasuski at 08:50| open.Theremin

Open.Theremin@「半分デジタル」なソフトウエア側の構成を今一度復習する

基本的には、オシレーター間に発生する差分をカウントする部分が重要で、そのカウンターはチップの内部に存在する物理的な存在だ。

ソフトウエアに記述されている処理を単純化すると、まず外部から入力されるトリガー信号のアップエッジのタイミングでカウンターの値がキャプチャーされる。 つまり、トリガーの間隔が周波数のズレとして計数されて、その数値を元に波形データの読み出し速度を「音程」に変換する仕組みだ。

UNOにおける主要な入力端子は、CLK0INT0INT1 の3つで、このうちオシレーター間で発生する差分の計測を担当するのが、ピッチ側がCLK0、ヴォリューム側がINT0。残るINT1にはオーディオのサンプルクロックが入力されている。 このうち、データを直接ハンドリング出来るのはCLK0のみで、残りはインターラプトを起動する機能だけを持つ。

ARDUINO_V2.png 

信号間の差分を計測するという点で、ピッチ/ヴォリュームの計測パートは共に同じ処理を行っているが、ヴォリューム側はこれを音量の制御に使っている。 このように、Open.ThereminではEtherwave等の共振周波数をピックアップする方式とは違って「純粋にピッチの差分を測っている」ので、2音ポリフォニック化も理屈の上で不可能ではない構造といえる。

問題は、328系のArduinoにおいて「物理カウンター」を制御できるポートがCLK0に限定されていることで、カウンターから直に数値を引っ張って来れない分、コードが無駄にトリッキーな構造になっているように見える。 

今回の復習によって得られた改装のヒントは、ズバリ「コードの単純化」だ。 端子の配置を自由に行えるM3/4系のチップは、物理カウンターと入力ピンの関係が固定されていないところが大きなアドバンテージといえる。 つまり、外部から制御できる物理カウンターの選択という制約が存在しないので、差分を検出する部分のプログラムには「ほぼ同じ構造のもの」を準備すれば良いことになる。 

同様に、制御レジスタの初期設定も単純化できるので、オリジナルのプログラムが持つ構造の忠実な再現を目指すよりも、出来るだけ「仕組みを単純化する方向」で考えていくべきなのだろう。

追記:

ちなみに、移植が成功しているMegaには、外部操作が可能なカウンタ"Timer4"が存在しているが、スケッチを作成した当時は「コードの再現性」に拘るあまり、それの持つ可能性を失念していた。

image.jpg

Teensy移植前のエクササイズとして、ICP4に入力端子を変更するVolume系の改変はハードウエアの準備を含めて最適だと思われるので、この部分のコーディングを最初の目標としていきたい。
posted by Yasuski at 02:42| open.Theremin

2016年09月26日

Arduino@CorTexM系チップが搭載されたボードのDirectPortAccessに関して

今日はArduino工作の初歩の初歩、LEDチカを出力ピンにデータをダイレクトアクセスして実行するスケッチを使って、コンパイルの実験を行っていた。

IMG_6384.JPG

スケッチはご覧のように小学生の高学年レベルで楽勝な内容ではあるが、これがArduinoMega等AT328系のボードでは動作を確認できた。

WS000693.JPG

出力ピンにデータのダイレクトアクセスを行う意味は、異なるボード毎に通訳を行う「通常の命令セット」よりも格段にスピードが稼げることにあり、その分ボードの種類毎に違ったポート/ピン番号を入力する必要が生じる。

ところが、DueやTeensy等のCorTexM系ボードで同様の操作を行ったところ、コンパイルは通るものの、機能を全く実現できないことが判明した。

これは、すでに去年末の段階においてDue上で確認していた不具合だったが、全く修正が行われていない案件であり、早速Teensyのフォーラムに一件を書き込んでおいた。

まあ、クロックがAT328よりも5倍以上速いM3やM4で、時間を稼ぐ必要があるのか?と言われたらソレまでで、実際 digitalRead(Write)Fast なる命令セットも存在するわけだが、「マージンは稼げるところで稼ぐべき」という考え方も一面で真実と言えるので、もちっと粘ってみることにする。

追記:


その後、GPIOに直セスアクセスする命令セットを思い出して試してみたところ、、、

WS000694.JPG

出力は可能だったものの、入力のPDIR(PortDataInputRegister)は相変わらずの動作不能だった。

9月27日追記1:

フォーラムに質問を投げたところ、マクロセットの使用を提言する回答をもらった。

記述は以下のように行う。 bitの指定が必須ではあるが、ボードによって異なるGPIOのグループを参照しなくて良い点が便利だ。


#define LED_ON (CORE_PIN13_PORTSET = (1<<5))
#define LED_OFF (CORE_PIN13_PORTCLEAR = (1<<5))


ついでに入力レジスタにアクセスする

#define buttonState GPIOD_PDIR & (1 << 7)

および

#define buttonState (CORE_PIN5_PINREG & (1<<7))

の動作を確認した。  を取るのは、ポートレジスタにおける目的するBitの状態を抽出するため。

次に、ピンへの入力でLEDの点灯を行うスケッチに関して。

当初は回路の物理的な不備(DigitalPinがハイインピーダンスで放置)が原因と思われたが、

if(state1 == HIGH) {LED_ON};

とした場合、相変わらずLEDが点灯しない。

判定回路を

void loop() {
state1 = buttonState;
  if(state1 == LOW) {LED_OFF;}
  else {LED_ON;};
}


と判定の条件を反転することで、PINの読み込みを確認出来た。 

なお、プルダウンを行う前のピンの状態はかなり不安定で、全ての入力は予めソフト上でプルダウンしておくべきだろう。

今回は同時に attachInterrupt の動作確認を行った。

attachInterrupt(buttonPin01, blink, RISING);

この場合、blink がインターラプトのディスティネーションで、

void blink() {
LED_ON ; // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
LED_OFF ; // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}


のように、分岐先に処理を記述しておく。分岐先のサブルーチン化の手法がいまいち解らず、これの解明が今後の課題。

9月27日追記2:

AttatchInterrupt の状態判定を HIGH / LO 何れかの継続状態に設定することでサブルーチンのループ化が可能と解った。

WS000696.JPG

これを RISING / FALLING に設定すると、サブルーチンの処理は単発に行われ、ループは発生しない模様。
posted by Yasuski at 21:32| Arduino

2016年09月25日

Arduino@USBH_MIDIが更新される

ArduinoでUSBホストを実現できるUSBH_MIDI関連のファイルが更新されたので、以前トライしてダメだったiRigのキーボードのマウントに再挑戦することにした。

スペース効率の改善を考えて、今回はLeonardoにスケッチを書き込んでみる。

IMG_6381.JPG

IMG_6383.JPG

結果は、KORG系とiRig系は問題なく認識できたが、LaunchPadMiniは相変わらず沈黙状態だった。

LaunchPad系では、LaunchPad"S"専用のスケッチが発表されており、期待値が高かったのだが、残念ながら前述したようにUSBH_MIDIでは未だ認識が行えず、LaunchPadMiniのスタンドアロン化はまたもや見送りとなった。

ただ、Hubを通すと認識できるという話もあるので、とりあえず激安い2又のHubを購入して様子を見ることになる。

今回、iRigが使用可能になったことは大きな進歩で、以後、動作する機種は限定されてはいるものの、USB系の楽器をワイヤレスで使えることになった。
posted by Yasuski at 19:11| Arduino

2016年09月24日

資材発注の記録

高精度タイプの半固定抵抗が欠品気味になってきたので、High Precision 3296 Variable Resistors 10K OHM を20個発注した。

VRT.JPG
posted by Yasuski at 18:59| Diary

2016年09月23日

ArduinoベースのPitchToMidi回路に関する覚え書き

数年前に作り掛けて放置していた案件を今一度検討する。

元ネタはこの記事で、Arduinoを使ってPitch検出を行い、対応する midi note を出力する仕掛けで、作者からコードと製作マニュアルのセットを購入した。

製作マニュアルではシリアル出力ポートに関する言及が曖昧だったので、コードを調べ直したところ AFSoftSerial SSerial(9); という記述がそれに該当する。 要は、D9(チップの 15番ピンに相当する) からLCD駆動用のシリアルデータが出力されている。 

なお、Arduinoのスケッチは拡張子が .pde の時代の産物なので、現行版ではコンパイル不能。 コードを書き換えるのが億劫なのでこのまま放置しているが、チップを焼く場合は、旧アルファ版 arduino0023 のIDEをインストールしなければならない。 複数台を製作するような場合は、念のためにコンパイル済のバイナリコードを保持しておいたほうが良いだろう。

今回は、製造に手間がかかるプリント基板を自作せずに、ユニバーサル基板に回路を組む方向で作業を進めている。

WS000688.JPG

ユニバーサル基板で回路を製作する場合、電源関連とグランドの配線が煩雑になってしまうが、単品を製造する場合はエッチングと孔開けを省略できるこの方法が一番だろう。

WS000689.JPG



posted by Yasuski at 16:39| Arduino

2016年09月21日

資材発注の記録

オーディオ・クロック生成用の発振源として、VECTRON 27MHz 3.3V CMOS CDTGCP-27MHz, 5x7mm, Qty.10 を発注した。

Vectron27MHz.jpg
posted by Yasuski at 18:57| Diary

2016年09月20日

Open.Theremin@Teensy対応ボードの製作

先日、KickStarterで機能が大幅に強化されたTeensy3.6が発表された。 

eca6f3896c292ca814915550e69f6eb5_original.png

そろそろ開発を停止しているTeensy対応のOpen.Thereminに手を付ける頃合いなのだろうか、、、。

ということで、ソフトウエア開発には動作の検証に必要なハードウエアの開発が必須、と考えを改め、放置中だった基盤のデザインを再開することにした。

去年末に開発を停止した時点では「音声をADATフォーマットで送出する」ことを考えていたが、実現の可能性が読めないファクターを平行して手掛けるのは無謀と反省し、今一度シンプルな構成の開発用プラットフォームを再検討することにした。

WS000663.JPG

ハードウエアに要求されるディテールは、

1)周波数ドリフトを相殺するために同一構造のアナログオシレーターを2ペア=高周波発振器を4基実装 
2)CV出力に転用可能な16bit精度のDACを2台搭載 
3)オーディオクロックにはそれなりのクオリティーのものを用意 
4)Teensy3.2/3.6両モデルへの対応 

この4点となる。

まず、システムの基幹となる高周波発振器に関して、基本的な回路はOpen.ThereminのC-MOSロジックICを使用したものを踏襲している。 ただし、オシレーター同士の相互干渉を低減するために、DIPパッケージに回路が同梱された汎用ロジックICは使用せず、シングルゲートのチップを選択している。 発振器のセパレーションは電源ラインの構造にも拘り、発振器毎にライン・フィルターを挿入した。

ディテクターは、Open.Thereminの回路に準拠してD-FFを使ったデューティーサイクル比をタイマーで計測する方式を採用している。 ただし、それぞれの発振器から元振を個別に取り出せるように信号ラインを整備している。 Teensy側で差分を「アナログライクな方法で」ディテクトする方式(実現化はしていない)を選択することが可能。 

今回の開発再開にあたって、まずは発振器のレイアウトを検討し、これを変更することにした。

WS000664.JPG

旧デザインは、アンテナを基盤中央に配置していたが、発振回路全体を180°転回させて、アンテナ端子を基盤左端に移設した。

同時に、Teensyを挟んで対称に配置していたDACをTeensyのデジタルポートが集中する側に移動した。

WS000667.JPG

Teensyに関する端子の互換性を確かめながら、2種類のボードに出来るだけ対応するように配線を進めていく。 同時に、接続可能な入力ポートの端子を増設していく。 DACにはバッファーアンプを追加し、電源ラインの入力端子を配線する。

WS000668.JPG

端子間の配線が込み入ってくると、期せずして部品の「島」が出来て仕舞い、グランドラインが途切れがちになる。 作業が進んでからの変更は手間が増えるので、常に「島」の存在を確認しながらデザインを検討していく。 

WS000670.JPG

未設だった高周波発振器からの信号ラインを仮設してみたが、高周波回路のセオリーから外れる配線法は干渉が気になってしまう。 シンプルに考えて発振器毎にU-FL端子を追加し、同軸ケーブルで信号を送ることにした。

WS000675.JPG

合計で4系統もの信号ラインが存在するが、うち2ラインはアナログ・ディテクト方式を試すためのオプション扱いとなる。 受け側のポートはD2〜D5とした。

WS000674.JPG

最後に、Teensy3.2と3.6の共通端子を精査して、可能な限り互換性をもたせる形で配線を行っていく。

WS000676.JPG

この時点で、肝心の電源ラインの配線を忘れていたので、できるだけ太いラインを使って回路を繋いでいく。

WS000678.JPG

Open.Thereminのオーディオ・クロックは、27MHzのXtal発振器を専用のPLL-ICと同期型カウンタを使って生成しているが、Xtal発振器の電源電圧には+5Vが必要なことを失念していた。 システム全体を、Teensyと共通の電圧仕様とするために3.3V仕様のXtalユニットを買い足すことになるが、部品の検索を行っている過程で2桁オーダーで性能は劣るが3.3Vで動作が可能なSMD形式のデバイスを発見した。 性能がそこそこではあっても小サイズの部品は魅力的なので、基盤にはどちらのデバイスの装着にも対応できるようにランドを追加した。

WS000679.JPG

最後に、高周波回路の配線パターンを「丸め」て、電源の取り回しをリファインした。

WS000680.JPG

以上、久しぶりに基盤のデザインを行ってきたが、ソフトウエア側の開発が停滞しているのが大問題で、まずはTeensy3.2準拠のコードを検討しなければならない。

9月22日追記:

グチャグチャだった回路図をまとめた。

WS000681.JPG

Teensy3.6の端子D24〜D30を引出した。 これで、DIP配列に設定された入出力端子を全て引き出すことが出来た。

WS000682.JPG

オシレーターバンク毎の距離マージンを稼ぐために回路にオフセットを掛けつつ、シールドを強化するためにスルーホールのグランドポイント群を追加した。

WS000685.JPG

9月26日追記:

遊んでる端子が見つかったので、単独で”D33”として追加した。

WS000692.JPG

この端子の持つ問題は、Teensy3.2と3.6では重複するポートの扱いが異なることで、混乱を避けるために独立させることになった。 3.2で使用する場合は、ロータリーエンコーダー等の入力となる予定。

9月27日追記:

今日は、DACに接続されているマイコンの信号ラインに、配線用のランドを追加した。

WS000698.JPG

これは、在庫しているDIPパッケージのDACを試作時に使えない問題を解消するための追加措置。 追加したランドは、SMDパッケージのDACを使う場合には不要となる。

大混乱状態の基板上に、「3.5ミリのオーディオジャック」を追加。

WS000700.JPG

部品はTeensyボード直下の結構タイトな位置に配置しているが、出力はTeensy3.6のDAC/出力2chと、外付けDAC/AD420×2chをランドの選択で行う。 DAC出力は、ともにDCが出せる親切設計。 

WS000701.JPG

オンボードDACをオーディオ信号出力として扱う場合は、一旦オペアンプの入力にジャンパ線で接続する必要があるが、選択肢が増えることは良いことだ。

混線状態の基板上に信号ラインを追加するのは相当に無理があるが、フォン端子出力はあくまでもオプション扱いなので、スペック面は追求しないことにした。

とはいうものの、オーディオアウトにLPFを通さない素通し設計は一寸アレなので、そこはショボくても良いから1次フィルターくらいは追加したいところ、、、。

試作ボードとしての利便性を追求した結論がこの形なのだが、アチラを立てれば、、、といった状態に陥らないようにしなければ。 
posted by Yasuski at 19:48| open.Theremin

2016年09月19日

MacbookPro15吋の不調

熱暴走が発生したのか、在庫管理ソフトがシステム毎クラッシュした結果、Macbookの再起動が不可能となってしまった。

熱ダレの雰囲気から、マザーボードが逝った可能性が高そうだが、中古でボードを買って交換するかどうかは、微妙なところだ。

ということで、トラブルに対処すべく筐体を開腹することになった。 最初はセオリー通りにメモリーの不調を疑ってみたが、試験を行った結果、この部分に問題は見つけられなかった。

次に、1stHDDに存在する不可視領域から復旧ディスク立ち上げるも、作業の途中で画面の表示がおかしくなる現象が発生する。 

WS000665.JPG

不穏な雰囲気のなか、DiskUtility で診断と Permission の修復を行うが、とりあえず物理・ソフト両面で大きな故障は確認できない。 次に、内蔵HDDを取り外したところ、DVDDと置換した2ndHDDからシステムの立ち上げを成功した。 ところが、確認のために再起動を試みた以降は正常にOSが立ち上がることがなくなり、起動不能の状態に陥ってしまった。

ここで、全ドライヴの取り外しを決意することになったのだが、運の悪いことにDVDDのエリア直近に位置するWiFIアンテナの配線を纏めたフレームの取り付けスクリューのアタマが潰れてしまっていることを発見した。

WS000666.JPG

この2本のプラスネジを外さないとDVDDのエリアにアクセスすることが出来ないので、仕方なく潰れたネジの頭をドリルで潰すことになった。 修復のためにはボディーにM2.5程度の細いネジを切り直す作業が必要だが、細いネジ径を切る工程をクリアするのはハードルが高く、ここは諦めてアンテナパーツの再固定を行わずに復旧作業を継続していく。 

ここまで体験した諸々の現象からハードウエアのトラブルが疑われるので、試しに最近メインで使っていた1stHDDをDVDポートに移植して起動してみた。 が、この過程でDVDポートに接続したHDDがシステムに認識されないことが発覚する。 どうも2011年版 MacbookPro のDVDポートは1TB以上の容量を受け付けないようだ。

この時点で外部バス・内部バス共に、起動を行っても灰色の画面に固定されてしまう状態に陥る。酷い時はブルースクリーンがお出ましになるヤバさだ。 被害が拡大するとても嫌な雰囲気になってきたが、ここでブレイクを設けることにして、筐体の熱を冷ましつつ別のMacbookでHDD自体の起動の可否を外付けドライヴを使ってテストしてみることにした。

幸いなことにテストの結果問題は発生しなかったので、これを機会に「Permissionの修復」を行いつつ3箇所のフォルダに存在するシステム・キャッシュを徹底的にクリアしておく。

再度、2ndHDDをDVDポートに移植して起動実験を行うが、反応が無い。 ここで、ハードウエア系のリセットを行うことを思い付き、shift + control + option + 電源キーでSMCリセットを行った後、PROMクリアをして起動にトライした結果、青息吐息状態ではあるが、2ndHDDからの起動を確認できた。

この時点で、起動ディスクをDVDDが接続されていた内部バスに接続したSATAドライヴに変更し、本来1stHDDがマウントされている場所はカラの状態で放置することになった。

行き場を失った1stHDDは外付けのケースに移設していたが、幸いなことにUSB経由からの起動も確認できた。 不便はあるものの、これで「復旧作業は一時終了」ということにした。

振り返ると、、、今日は昼から延々と作業をしていたわけだが、結局はHDDのキャッシュが悪さをしていたように思える。 怪しげなキャッシュを更新してハードウエアのリセットを掛けた結果、ようやくHDDが認識されるようになった。

その後、1stHDDを定位置に復帰することが出来たが、システム終了時にフリーズを疑われる無反応に遭遇しても、焦らず気長にシャットダウンを待たなければならない。 そういえば、17吋でも似たような経験があったことを思い出したので、これを教訓として「キャッシュの清掃をしてくれるアプリ」を常駐させることにした。 ただし、あの怪しげな雰囲気はキャッシュの不具合ばかりとは思えず、熱暴走の可能性を忘れないことにする。

今回行った不毛な作業の中にあって、「唯一の収穫」は、DVDDのポートが1TBの容量に対応出来ないことの発見にある。 SSDを導入する際は、まず低容量のものをDVDDのポートに繋ぐことになるだろう。 

9月19日追記:

リカバリ領域からDiscUtilityを起動した際に発生したディスプレイの縦縞模様&ブルースクリーンで再起不能のパターンはグラフィックチップの剥がれが原因の可能性が大という記事を見つけた。 該当機種の番号もドンピシャで一致しているので、これは既に共有されたトラブルなようだ。

http://laptoprepairblog.com/problem-macbook-pro-a1286-does-not-light

日本でも一部で問題は共有されているようだが、AppleSupportの修理代金の上限が4万程度に収まるというのは新たな発見だった。

http://kosuke.cc/apple/macbookpro17-broken/

斯様な記事を連発で見つけた手前、Macbookの状態が大変心配になって来るのが人情で、確認のためにThunderbolt 端子に HDMI変換ケーブル を接続してTVに画像を出力してみたが、通電時間1H程度の加熱だったためか問題は発生しなかった。

今回問題の再現はなかったが、基盤の歪みが原因でマザボが死ぬ現象は大型Thinkpadでも体験済みの現象なので、今後は強制空冷を行うなりの方法を含めて加熱を防ぐことで Macbook の延命を考えていくべきなのだろう、、、。
posted by Yasuski at 00:09| AudioElectronics