Proteus 7のデモバージョンを試す（EAGLEの上にも10年）

EAGLEの上にも10年

まだ日本国内でEALGEの知名度がそんなに高くなかった頃からのノン・プロフィット・ライセンス・ユーザなのですが、最近は色んな事を考えて他のCADかあるいはライセンス形態を変更しようと検討を進めています。

具体的には

• 作った基板を販売できるようにしたい。
• 階層化設計に対応したCADを使いたい。
• もうちょっと楽に配線できたらなぁ。
• ネットリストでPCB CADにデザインを渡したい！（どんな欲求だ！）
• 実はEAGLE・・・ちょっと設計が大きくなると重い。
• その他。

など、どれも切実とは言えませんが、少し前に設計したARM Cortex-M3基板設計時に「もうちょっと楽したいなぁ。」というのが発端になっています。

EAGLEの気になるところ

どんな事がネックになったのかをちょっと整理してみましょう。
回路図はA3のシートにゆったり書いて8ページのデザインです。

気になる事の1点目はクロスリファレンスです。

複数ページに渡る図面で「いつも何か気になる事。」の1つはクロスリファレンスの扱いです。
現行のバージョン(バージョン5系)までのEAGLEにおいて、クロスリファレンスは「ULPでなんとかがんばりましょう。」というものです。ULPを使って最終的に仕上がる図面としては「それっぽく」なるのですが、所詮ULPで付けたクロスリファレンス、後からネット名を変えた日には即座に破たんです。本来であれば変更に追従して欲しいところです。

最近のバージョンでは、ネットにラベル名を付ける機能に「クロスリファレンスっぽいタグ」が選択できるようになりました。が、これは現状のバージョンでバスには使えませんでした。

次に気になるのはデザインの再利用性です。

一度設計してデバッグが完了した回路ブロックは、より大きなデザインに対しての単一モジュールとして再利用したいものです。しかし、EAGLEにそんな機能はありません。

例えば、「このオーディオ回路ブロックを再利用したいなぁ。」なんていう時、まぁなんというかコピーするしかないのです。で、よくある間違いが電源系だけ間違えたとか、そんな話です。そもそもコピーなんていうのは対処法としてお世辞にも良いと言える理由が見つかりません。

基板側は4層基板でデザインは小さい部類に入ります。

例えば、EAGLEで基板配線している時に気になるのは、DRCを通すまで重なりに気付かない事があるという点。CADにもよりますが自動的にピンなりビアなりを避けてルーティングして欲しいものです。最近はEAGLEにもFollow-me配線があるのですが、なんというかちょっと違うような気がしています。（適当な書き方ですいません。）

DRCを通さない事ありませんので良いと言えば良いのですが、本当は既存の配線に沿ってルーティングしてくれれば4層の基板を趣味とはいえ引くのに1週間もかかったりしないのでは？と考えたりしています。

Proteus 7

Proteus 7はhttp://www.labcenter.com/index.cfmが製造販売しているCADです。

スターターキットは150ユーロからと導入の敷居はかなり低そうです。

一部の機能に制限があるというデモ版をダウンロードできるようなので試してみる事にしました。

電気設計はISISという名称のツールを使います。

基板設計はARESというツールです。

基板設計側を見る

この手のツールは個人的に、電気設計側が良いと基板設計側がダメだったりとバランスが悪い印象があります。まずは基板設計側で思った通りに操作できるかどうかを確かめます。

黄色の矢印は「主にこっち側に配線が伸びているよ。」というものを示すもののようです。

ルーティングはルーティング用アイコンを選択してピンをクリックすれば始まります。

「おっと。意外にも良い感じだ。」なんてこの時点で感じました。

で、情けない話ですが・・・

引いたところでネット名が即座に確認できる！なんて感動してしまうわけです。

まぁ、EAGLEの常識がCADの常識なんてこれっぽっちも思っていないわけですが、それでも「なんだかなぁ、自分。」という感じです。

当然のようにデザインルールで定めた範囲で的確にルーティングさせるようになっています。

配線できない所には行かせません。

当然のように予めネットにつけておいたアトリビュートに従って配線幅も適切なものになるようになっています。EAGLEだと後から自分で修正したり、引く前に選択したりしていました。で、最後にDRCの結果を見て修正するなど・・・。これが時間がかかるのと神経質な操作になったりして意外にストレスになったりします。

電気設計側を見る

基板設計側が「パッ見て」良さそうなので電気設計側も見てみる事にしました。

既存の電気図面にシートを1枚追加して、コンポーネントを適当に配置し、配線してみます。

配線したネットにネット名を付けて「デザインエクスプローラ」なるものでネットの配線状況を確認してみました。

どこのCADとは言いませんがネットに名前を付ける程度で戸惑うようなユーザインターフェースになっているCADも少なくありません。まともに機能しないというのもその一つです。

ですが、少なくともISISにはそういった点は見つかりませんでした。

事前調査に進む為の第1関門突破といったところでしょうか。

そして、嬉しいのが階層化設計が表現できる機能。
回路ブロックを定義し、「Goto Child Sheet」でそのブロックに飛べるようになっています。

子シートに飛ぶと内部設計が表示されますね。

これが実現できているのですから、きっとクロスリファレンスもうまくやってくるでしょうと期待してしまいます。

いずれにせよ

そうは言ってもEAGLEは私にとって身分相応のCADで、費用対効果はこれまでの実績から十分なものと言えるでしょう。本当に小規模な設計であれば、道具として使えない事は全くありません。道具は使う人によって生きたり死んだりしますから、CADの選択が全てを決めるわけではないというのは言うまでもありません。

今回のProteus 7の評価は最初の一歩ですが、時間を見てもう少し触ってみたいものです。

番外編

このCADにはシミュレーション機能もあるのですが、これが気持ち悪い。

どうやって実現しているのかまだよくわかっていませんが、例えばuClinuxが走ります。

私個人的には「自分で作ったライブラリ類」でできない限り、この手の機能は「ふーん。」程度にしか見ないのですが、それにしても気になります。

3D表示はなかなか使えそうです。

設計基板にアクリルを付けてお洒落度アップ！「アクリ屋ドットコム」さんにアクリルを発注してみる。

外装にも少しは気を配りたい

おもてなしの心は日本人の得意分野かと思っていましたが、コスト削減要求の嵐の中そんなことは忘れ去られてしまったかのように見える今日。
ちょっとした評価基板の天面にアクリル板なんかが載っていると思わず「おぉー。」なんて思ってしまうのも情けない話です。

例えば、Terasic Technologiesのボードなんかの仕上がりは、かなり私好みです。

それはともかく、今回設計したLPCXpresso Clockでは、予め簡単な外装を付ける事を前提に設計を進めていました。

アクリルなどで簡単な養生があるだけでも何かのメリットがあるわけです。

• 基板の隅々に埃が被るような事がない。
• 埃が被りにくいので「何か古臭くなったなぁ」なんて感じる事がない。
• 水滴が飛んでもある程度大丈夫。
• 少しおしゃれ。
• その他。

少し無理矢理ですが色々なメリットが考えられますね。

アクリ屋ドットコムさん

基板製造が海外で数十ドルから出来るようになった今、相対的に外装にかかる費用は大きくなっていると言わざるを得ないのが現状です。

そんな中、国内で面白いサービスを展開されている企業があります。
私は今回「アクリ屋ドットコム」さんにアクリルの加工依頼をしてみました。

アクリル板加工でセミオーダー形式でウェブから注文ができるサービスを展開しています。
ちょっとした加工までをウェブから行う事ができ、その場で値段がわかるのが特徴です。

LPCXpresso Clockの場合

「アクリ屋ドットコム」さんのセミオーダーの場合、穴位置などの指定単位が0.5mm単位です。
また、アクリル端からの穴位置に若干の制約があります。

LPCXpresso Clockの場合、以下のようにして対応しました。

• 穴位置はアクリル板の端面からの距離で指定することになっている。
• 0.5mm単位のグリッドに載せると若干ずれる。
• 穴位置が許容される誤差に収まるようにアクリル板のサイズを調整する。

要するに穴位置がアクリル板の端からの位置で決まるので、アクリル板のサイズを調整して許容される範囲に穴位置を調整しようという対応です。（こんなのは機械屋さんから見ると最低だろうと思うのですが、私は機械に関して詳しいとは言えないのでよくわかりません。）

出来上がってきたアクリルを付けると以下のようになります。

基板だけの時と比べると、与える印象がまるで違いますね。

今回のアクリルパネルは一枚で約700円程度です。
基板の原価と同じくらいの費用が外装にかかるわけですが、実際に完成してみると良い効果を生み出していると言えるのではないでしょうか。

LPCXpresso Clockに部品を搭載して動作させてみる

動作させてみる

先日到着したLPCXpresso Clock基板に部品を搭載してLED周辺回路の動作確認を行いました。
点灯させた状態で以下のようになります。

まだ基板だけの状態なのです。
これにアクリルパネルを取り付けて外装の完成となる予定です。

もちろんLPCXpresso IDEを使ったデバッグを行うこともできます。

LPCXpresso IDEでデバッグもできる他、外部電源で独立運転もできるように設計しました。
デバッグを楽しんだ後は普通に時計として使用する事ができるようになっています。

Eagle3D + POV-RayによるCGとの比較

折角なので先日Eagle3D + POV-Rayで作ったCGとも見比べてみましょう。

そっくりですね。
Eagle3D + POV-Rayでの確認は、なかなか有用そうです。

Eagle3D + POV-Rayをもっと活用してリアルな完成イメージ図を得る

Eagle3Dって何だっけ？

Eagle3Dは、EAGLEで設計した基板データから写真で撮影したようなリアルな３次元CG画像を作る事のできるツールです。
実際に基板製造をする前に完成イメージ図が得られますので、好んで使用しています。

リアルな３次元CG画像を得るためには３次元モデルが欠かせませんが、EAGLEに標準で添付されているライブラリの多くに対応しているのもEagle3Dが人気の理由の一つになっています。

裏を返すと、標準で添付されていないような自作ライブラリなどの部品は、生成された３次元CG画像に含まれないことになります。
何を隠そう私も先日まで「面倒だなぁ。」とか「良いんですよ、基板の感じが掴めれば。」とか思う事にして、自作ライブラリに対するケアは全くしていない状態でした。
そして、自作ライブラリだけ歯抜けになっているとかっこ悪いので、「部品を載せない」設定にして出力です。

ですから、以下のように何か足りない寂しい出力になっていたわけです。

しかし、所詮は四角や丸の多い電子部品の３次元モデル。
POV-Rayのスクリプトを実装するのもそんなに難しいはずがありません。

基板だけの出力に甘んじている現状にも我慢できなくなってきたので「もっと活用してリアルな完成イメージ図を得る」という目標を立てて実践する事にしました。

Eagle3Dの処理構成

Eagle3Dの処理構成についておさらいしてみましょう。

大まかにみると２段階の構成になっていて、EAGLE上でPOV-Rayで実行するレンダリング用スクリプトファイルを生成し、POV-Rayで実際にレンダリングを実行するという形になっています。

整理すると

• EAGLE側：部品のパッケージ名とレンダリング処理の関連付け。
• POV-Ray側：レンダリング処理の実行。

ということになります。

コンポーネントの追加

EAGLE

Eagle3Dを展開するとulpディレクトリがあります。
この中にある3dusrpac.datというファイルがユーザパッケージ情報を定義することのできるファイルとして用意されています。
ここにパッケージ名とレンダリング処理を関連付けるための記述を1行追加します。

A-551UB:0:1:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:DIODE_LED_7SEG_A551UB(::

上記の場合、「A-551UB」というパッケージと「DIODE_LED_7SEG_A551UB」というレンダリング処理が関連付けられた事になります。

これでEAGLE側の準備は完了です。
早速Eagle3DのULPを実行してPOVファイルを生成します。

POV-Ray

POV-Ray側は指定されたレンダリング処理に対する実装が必要です。
Eagle3Dを展開したディレクトリにあるe3d_user.incがユーザ拡張用に設けられたファイルです。

先ほどDIODE_LED_7SEG_A551UBというレンダリング処理と結びつけたので、ここにマクロとして実装します。

#declare e3d_environment = off;

#macro DIODE_LED_7SEG_A551UB(value)

    // ピンオブジェクトを定義する。
    #local leg = object{
 cylinder {<0,-3,0>,<0,1,0>,0.25 texture{col_silver}}
    }

    // コーナーを作る。
    #local corner = object{
 box {<0,0,0><2.5,1,2.5> pigment{White}}
    }

    union{
 // ピンを配置する。
 object{ leg translate< -5.08,0,7.935>}
 object{ leg translate< -2.54,0,7.935>}
 object{ leg translate<     0,0,7.935>}
 object{ leg translate<  2.54,0,7.935>}
 object{ leg translate<  5.08,0,7.935>}
 object{ leg translate< -5.08,0,-7.935>}
 object{ leg translate< -2.54,0,-7.935>}
 object{ leg translate<     0,0,-7.935>}
 object{ leg translate<  2.54,0,-7.935>}
 object{ leg translate<  5.08,0,-7.935>}

 // 本体を作る。
 box {
     <-6.35,1,-9.5>,<6.35,8,9.5> pigment{White}
 }

 // ４つのコーナーを配置する。
 object{ corner translate<-6.35,0,-9.5>}
 object{ corner rotate<0,90,0> translate<-6.35,0,9.5>}
 object{ corner rotate<0,180,0> translate<6.35,0,9.5>}
 object{ corner rotate<0,270,0> translate<6.35,0,-9.5>}

 // 本体の上面に７セグメントLEDの画像ファイルを貼る。
 box {
     <-6.35,8,-9.5>,<6.35,8.1,9.5>
     pigment{
  image_map{png "a551ub.png" once}  rotate<90,0,0> scale<12.7,0,19> 
  // 左下に画像を貼ってから全てのオブジェクトを移動させて中心にもっていく。
  translate<-6.35,0,-9.5>
     }
 }
    }
#end

こんな風に２つのファイルを編集するだけで、手軽に自作コンポーネントに対する３次元モデルを生成できるようになります。
部品面の描画を記述するのが面倒なら、部品をデジタルカメラなどで撮影し、その映像を貼りつけるだけで構いません。

先ほどの例では以下のような画像を部品本体に貼りつけています。

上記の手順を経て得られた出力画像を見てみましょう。

これで先日までの基板だけの完成イメージよりもリアリティを感じられるようになりました。

動画

POV-Rayではレンダリング用のiniファイルを作ってアニメーションを生成するための複数画像ファイル生成ができるようになっています。

例えば、以下のようなiniファイルを作ってPOV-Rayで使用してみます。

Initial_Frame = 1
Final_Frame = 360
Initial_Clock = 0
Final_Clock = 360
Cyclic_Animation=off

ここでポイントとなるのは、POVファイルの変更です。
clockという変数は描画毎にカウントアップされる値で、これを基板の回転変数に入れる事で基板を回転させて見る事ができるようになります。
先ほどのiniファイルでは「初期クロック=0」、「最終クロック=360」としました。

今回はPCBをX軸を中心に回転させてみました。

画像は複数枚のBMPファイルになって出てきます。
これを動画に変換してみたものが以下です。

動画にすることで更に実在する物体として認識しやすくなりました。
基板を製造に出す前に「どんな感じになるのかなぁ。」と体感したい時に便利ですね。

更なる応用も可能

今回は手始めに自作部品に対するレンダリングについてのみ触れました。
実はPOV-Rayのレンダリングスクリプトをもっと有効に活用すれば、任意の表示パターンを作るようにできたりします。
これを使えば取り扱い説明書の画像を作ったり、オペレーションガイドのような動画を生成したりすることもできるでしょう。
使いこなせば従来ではできなかった品質をドキュメントの領域でも発揮できるかもしれません。

僕たちのファームウェア戦略 (LPCXpresso Clockを使って、組み込み機器開発特有の問題解決を楽しもう！)

戦略なしではいられない

LPCXpresso Clockは、現状でほぼ全てのLPCXpressoにドッキングする事を考えています。
この時、LPCXpressoの各モデルに対するライブラリを個別に提供しても構わないのですが、管理や設計から見ると美しいとは言えません。

例えば・・・

• 「このウルトラミラクル輝度制御機能は全モデルに搭載されている機能なんだけど、あのモデルでは"ABC"になっていて、このモデルでは"DEF"になっている。」
• 「あぁ、そのモデルは全然保守されていなくて、別のインターフェースになっているんだ。」
• 「え？このモデルでしか動かせないハッピータイマー機能を加えたけどだめだった？」

など、実際の製品開発においては、シリーズとして相応しいインターフェースを提供しているのかなどの検討も欠かせないのです。
「あのモデルのためにABCインターフェースを追加したら、別のモデルで致命的な矛盾が生じた。」なんて笑うに笑えないわけです。

今回の設計に関して言うと、殆どの機能は共通なのですから、アプリケーションロジックは共通にしておきたいところです。そのためには、下層ライブラリを適切なインターフェースで切って、実体を抽象的に扱う事が欠かせません。これは今後触れていくであろう「僕たちのクロスプラットフォーム戦略」にも関連があります。

考えられる様々な要求を簡単に箇条書きにしてみましょう。

• 使いやすいライブラリを提供して欲しい。(ユーザ要求)
• インターフェースの学習コストを最小限にしたい。(ユーザ要求)
• アプリケーションロジックは共通化して、開発コスト対効果を最大限に高めたい。(ユーザ要求)
• 優先度の高いモデルや機能から実装して、要求に応じて他のモデルも開発したい。(開発者要求)
• 「私はCで書きたいんだ。」、「私はC++で書きたいんだ。」(ユーザ要求)
• その他

他にも様々な要求が考えられるわけです。
要求は、顧客から来るもの、設計から来るもの、実装から来るもの、様々です。

いずれにせよ言えるのは重複するような内容が物事に含まれている場合、何かと問題が生じるという事実です。

ここを美しく解決する事が「僕たちのファームウェア戦略」であり、１つの製品設計で複数のラインナップを揃える事のできる土台となるわけです。

設計の土台を作る(分割し、整理し、統治する)

では、具体的にどうすれば良いのかという話になります。
基本的には「分割し、整理し、統治する」という流れです。

分割(あるいは統合)

同じものと違うものを分割します。あるいは同じものを統合します。
分類に迷ったら、基準となる視点を定めて分割するか統合するかを判定します。

例えば、LPCXpresso Clockの場合、分割可能な要素の例には以下の２つがあります。

• LPCXpresso Clock基板固有の機能。 (時計のインターフェースを実現するハードウェア。)
• ドッキングさせるLPCXpresso基板固有の機能。 (時計の制御を実現するハードウェア。)

簡単ですね？
ドッキングして使用するのですが、2つの基板の役割は明確にわかれています。

LPCXpresso Clock基板+LPCXpresso基板=LPCXpresso Clockですから、上記の視点は非常にシンプルなものです。
(一見下らない要素を大げさに取り上げているように見えるかもしれませんが、これが後々の設計と綿密な関わりを持ってきます。)

整理(あるいは破棄)

分割した要素の詳細を整理します。
詳細といっても実装レベルの詳細ではなく、「だいたいこんな感じかなぁ？」程度の整理で構いません。

例えば、LPCXpresso Clockの場合、以下のような感じです。

• LPCXpresso Clock基板
• 7セグメントLED (出力)
• 赤外線受信回路 (入力)
• 照度センサ (入力)
• スイッチ (入力)
• LPCXpresso基板
• GPIO (入出力)
• RTC (入力) - 無いモデルもある。

統治(あるいは留保)

統治の段階でインターフェースを定義してみます。

Cならヘッダファイルにインターフェースを定義します。
C++ならヘッダファイルにクラスを定義します。

この時点で統治できないような内容があっても構いません。
意味不明な物体は、この時点で無理して統治する必要はありません。
少し変な名前を付けて残したりすれば良いです。

これは検討の方向性を確認するためのプロトタイプ実装です。
実際に動作させるところまで持っていく必要はありません。

これが「僕たちのファームウェア戦略」における実用的な出発点です。

そ・れ・で・？

子供騙しのような整理をしてどうなるのか？と感じる方もいるでしょう。
でも、上記の３ステップの整理をするだけで

• システムが何を提供しようとしているのかが明確になる。
• シリーズ並行展開の視野を身につける事ができる。
• 自身の設計が何のプラットフォームに依存しているのかを明確に認識できる。
• その他

様々な効果が得られます。

今回は「僕たちのファームウェア戦略」の出発点を示し、その効果について概略を解説しました。