CircuitMaker | PCB設計ソリューション

最適なフラッシュメモリストレージソリューション：NORとNAND、どちらがあなたのプロジェクトに最適ですか？

Frank Duggan: マイクロアーキテクチャーとMITでの目標 1 min OnTrack Frank Dugganと氏の父親からNYCメーカーフェアで、BEEBAについて学んだこと Judy Warner: あなたが、離散ロジックを使用する独自のマイクロアーキテクチャーを開発しようと最初に思った動機は何ですか? Frank Duggan: 私は小さい頃から、具体的な内容は知らなくても、これをやりたいと思っていました。私は自分のスナップ回路電子機器キットに熱中し、色々な機能を果たす回路を作る課題に取り組むのが好きでした。いつの頃からか、コンピューターを作り上げるのが究極の課題であると、私は決意しました。これはおそらく、コンピューターがとてもミステリアスに見えたからでしょう。そして私は、コンピューターがどのように実現されているのか理解できなかったので、設計は非常に難しいに違いないと結論しました。 Warner: 他のデバイス用のアセンブリ言語プログラミングを行ったことはありますか?もしそうなら、変更したいと思った部分はありますか、その理由は? Duggan: 他のアセンブリ言語でプログラムしたことはありません。ただ、ARMのアセンブリについて多少知っています。私がBEEBAアセンブリ言語を作成したとき、既存のアセンブリ言語の設計は考慮に入れませんでした。ただ、ハードウェアの実行する命令セットを見て、それをテキストで表現する方法を立案しました。 Warner: BEEBAのRev 2を開発するとき、最も大きな課題は何でしたか? BEEBA Duggan: 最大の課題は、命令デコーダーの設計でした。分岐とループの動作を可能にする方法を見つける必要がありました。16ビット命令では、命令のジャンプ先や、そこへのジャンプを行うかどうかを決定するための読み出し先アドレスを指定するために十分な幅がありません。しばらく案を考えた結果、システム内でデータをある場所から別の場所へコピーして動作するソリューションを思い付きました。書き込み可能な3つの場所を使用して、命令位置のバッファ処理を行います。書き込み可能な4つめの場所は、バッファされた場所へのジャンプを行うかどうかを決定するために使用されます。その場所に奇数が送信された場合、命令コンピューターはバッファされた場所をプログラムカウンターにコピーします。その場所に偶数が送信された場合、コンピューターは何も行わず、シーケンスの次の命令に進みます。これは電子的に実装が単純で、命令デコーダー基板の限られた面積に収納可能でした。 Warner: 基板のデバッグには、どのような技法を使用しましたか

マイクロコントローラーの故障モード: 発生理由と回避方法 1 min Thought Leadership 設計の成功の大部分は大学にかかっています。実験室の実験でコンデンサーを誤って爆発させる原因を学んだからではなく、思いもよらないときにマーフィーの法則が当てはまることがあると学んだからです。Warcraftゲームに参加して終わりのない任務の遂行に明け暮れていた私は、常にコンピューターに依存して活動していました。その当時、コンピューターの性能はかなり低く、悪名高いWindowsの「死のブルースクリーン」ポップアップが時々表示されるのは珍しいことではありませんでした。Warcraftゲームが中断されることはイライラの種であり、遂行した任務がシステムに保存されず数時間が無駄になる一方で、私はコンピュータークラッシュにより重度のパニック発作を引き起こしたものです。設計者であれば、現場でマイクロコントローラーに障害が発生した場合に、同様のパニックを経験したことがあるかもしれません。マイクロコントローラーの故障モードがシステムに与える影響組み込みシステムでは、マイクロコントローラー（MCU）の障害は、業務の締め切りに遅れた場合よりも悪い影響が出る可能性があります。多くの場合、MCUは、決済端末、医療機器、セキュリティーシステムなどの用途における心臓部です。これらのシステムは高い安定性を必要とし、たいていはシステム障害に強くありません。 MCUが故障すると、場合によってはシステムの稼働が完全に停止します。この状況は、ユーザーに迷惑をかけたり、重要な使用現場において安全上のリスクを引き起こす可能性があります。クライアントにとって、信頼性の低いシステムは運用能力に影響を与え、収益の損失につながる可能性があります。設計者にとっては、何百もの製品が現場で常に故障していることは、私たちの誇りに大きな打撃を与え、評判に影響することが考えられます。マイクロコントローラーの故障の理由とその責任信頼性のある組み込みシステムには、ハードウェア設計者とファームウェアプログラマの協力が必要です。一部の設計エラーは開発段階で検知されず、導入後にやっと問題が顕在化します。この場合、その責任の大部分を誰が負うべきなのでしょうか。指をさす前に、マイクロコントローラーが故障する一般的な理由を考えてみましょう。 1. メモリスタックオーバーフローマイクロコントローラーのメモリスタックは、一時的な使用を目的とした内部RAMの指定領域です。メモリスタックのサイズは制限されており、MCUによって異なります。ファームウェアプログラマがスタックサイズより大きい変数を割り当てると、ランタイム中にスタックオーバーフローが発生し、ファームウェアに問題が生じる場合があります。 2. 不正なポインター MCUファームウェアプログラミングでは、変数、またはプログラム関数のアドレスを示すために、通常

Midnight Sunソーラー設計チームが開発した未来のソーラーカー 1 min Engineering News World Solar Challenge（WSC）に参戦するWaterloo大学のMidnight Sunソーラーチーム 1988年度以降、 Waterloo大学のMidnight Sunソーラーチームは、顧問のGordon Savage教授の指導の下、ソーラーカーを製造し、American Solar Challenge （ASC）およびWorld Solar Challenge （WSC ）に参加しています。これらの大会は、1年おきに交互に開催されます。電気系統チームの舵取りは、Minghou Ji（エンジニアリングマネージャー）、Yifei Li（ハードウェアエンジニア）、およびTaiping Li（ハードウェア設計者リーダー）が行っています。