基板を作ったけど、VCCIが通らない！

と、なったらだいたいパニックになってやたらめったら対策部品をつけたり、いろんな手をうつとおもいます。

ですが、それ、泥沼になります。

大事なこと：すべての対策部品を施してから、部品を減らしていく

これが大事です。

何も考えずにやっていると、ありとあらゆる対策の組み合わせが発生してしまい手に負えなくなります。

１，考えうるすべての対策部品を施す（シールド追加やノイズ除去フィルター追加、フェライトコア追加など）

２，その状態でVCCIに通っていることを確認する

（それでも通らなかったら解析をもっとしないと駄目です）

３，対策部品を一つずつ外していく。

４，VCCIをクリアできなくなったらやめる。

一つずつ追加しているといつまで経っても「VCCIをクリアできる正解」にたどり着けない可能性があります。

そこでまずどれだけコストがかかるかを度外視で、全部のせで「正解」を作ってしまうのです。

そして、そこから部品を取っていって、できるだけコストがかからない「正解」を見つけるのです。

これはVCCIだけでなくノイズ系のトラブルでは全般で使えるので、是非とも覚えておきましょう。

以上、小田切でした。

閑話休題的に。

アートワークというのは配線を引き回すので、回路図と違ってわかりにくくて良いのか悪いのか判断するのも難しいです。

しかし、最終的には人が見るしかないという話です。

実はアートワークを確認して自動で「ここが危ない！」とか警告してくれるチェックソフトがあります。

ところが、実際に使用してみたことがあるのですが、単純なルールで判断しているだけであまり適切とはいえませんでした。

例えば「電源ピンから◯mm離れたところにコンデンサがあったら、『パスコンが遠い』と表示する」みたいな感じです。

しかし、実際には部品の置き方には制限があるので「そう言われてもこうしかやりようがないよ」となるわけです。

それから、「この信号は速いからこういう風にしないといけないけど、この信号は遅いからそんなのいいんだよ」みたいな回路図から読み解けない条件もあります。

チェックソフトは結局一律で見ているので、そういった判断はできません。

もちろんソフトウェアは進化していくので多少は良くなっていくでしょうが、結局ルールで判断しているだけなので限界があります。

補助として使うことは出来るかもしれませんが、「あまりに悪いパターン」を見つける程度が限界のように思います。

そこそこの設計者が作ったアートワークをチェッカーソフトに入れても、先程のパスコンのように「だってどうしようもないじゃん」みたいな警告が大量に出るだけであまり意味ありません。

ということで、ソフトウェアの進化に期待しつつも、現状では設計者自身のスキルを向上していくしかありません。

以上、小田切でした。

無線を扱う回路を小さな基板に組み込んだら、受信信号にノイズが増えて性能が出ません。

という悲しいことが有りました。

無線機器というのは送信する方はパワーがあるので良いのですが、受信するときは本当にかすかな信号を捉えています。

となると、ノイズに非常に弱いわけです。

普通の感覚で設計するとVCCIなどノイズ基準を通すものは作れますが、無線機器のパフォーマンスを出すための設計となるとさらに念入りな処理が必要なようです。

今回問題となっているのはどうもGNDのようです。

評価ボードなどはGNDが大きく理想的な配線ができているためノイズレベルが非常に低いです。

しかし、新規設計した基板は面積が小さくGNDの面積が小さくなっています。

RF部のしたはGNDで埋めているので、デジタル部とRF部が直結しているわけではないのですが、それでも性能が劣化してしまうようです。

ということで、無線機器を作るときは普通の設計のように詰め込まないで、だいぶ余裕を持たせてGNDベタを張り込まないと駄目なようです。

以上、小田切でした。

電子部品というのは金属だとかプラスチックなので、湿度がどうこうなんて普通の人は考えないと思います。

しかし、じつは湿度を吸収してしまうのです。

湿度を吸収した状態でなにが問題になるかというと、加熱した時に水分が膨らんで部品を壊してしまうのです。

加熱とはどういうときか？

部品を実装するときです。

ということで、部品には「MSL(Moisture Sensitive Level)」が記載されています。

レベル１のものはほとんど気にしなくていいのですが、レベルが上がるごとにどんどん厳しくなっていきます。

レベル１以外のものは実装する前に「ベーキング」といって軽く加熱して湿度を飛ばす作業が必要になります。

例えば、抵抗だとか積層セラミックコンデンサだとか、こういうものはMSL１なので気にしなくて大丈夫です。

それから、ロジックICのような小さなICもだいたい大丈夫です。

違ってくるのは、

・CPUやメモリのような大きな部品

・LED

などです。

部品が大きくなると湿度を沢山吸湿するので、MSLのレベルが上がってきます。

そして不用意に実装ラインに入れると割れて壊れます。

ということで、MSLレベルはきちんとチェックしないと面倒なのですが、幸い一目で分かる点があります。

部品の包装です。

抵抗や小さなICなどは紙テープやプラスチックテープにぞんざいに貼り付けてあるだけです。

しかし、MSLレベルが高い部品になると、CPUでもメモリでもLEDでも、必ずアルミコーティングされた容器に入っています。

この容器から出してすぐに実装すれば問題ありませんが、容器から出してしばらく放置すると「ベーキング」が必要になります。

ということで、アルミ包装の部品があったら「MSL」について確認してベーキングを確実に実施するようにしましょう。

以上、小田切でした。

自分はもともとソフトウェア専攻だったこともあり、

「C++やJavaなどのオブジェクト指向最高！　複雑な構造のプログラムでも抽象化してうまく設計できる！　Cとかごちゃごちゃになりやすい言語なんてくそだ！！」

と思っていました。

だって、オブジェクト指向では綺麗につくれるプログラムも、非オブジェクト指向で作るとデータと関数がごちゃごちゃになってわかりにくいんです。

ところが、組み込みの方の世界に入ってみると皆C言語で書いていました。

「なんて遅れているんだ！」

とその時は思いましたが、それなりに理由があるのです。

１，開発者がC言語に慣れている

組み込みでは長い間Cが使われているので、皆慣れています。

逆にC++は使い慣れていない人が多いです。

２，過去の資産がC言語

C言語の資産があると、C言語で開発するのが楽です

メーカが提供しているのもC言語のライブラリだったりします。

３，メモリが限られている

これがある意味一番の制限です。

オブジェクト指向など、昨今のプログラミング言語はメモリを大量に使います。

開発しやすさなどを優先して、メモリを多少無駄に使っても気にしないというスタイルです。

PCやスマホ、あるいは数百MBのメモリが載っているLinuxボードならそれでもいいのですが、

プアな組み込み環境だとメモリが数kBしかありません。

こうなると、インスタンスを作る度にメモリを確保するようなオブジェクト指向言語を動かすことは非現実的です。

とまぁ、このように、今でもC言語で開発をするのが現実的なのです。

昔の自分のように「オブジェクト指向じゃないなんて！」と怒らないようにしてください（笑）

以上、小田切でした。

CPUなどの資料を取りにメーカーのサイトに行くと、文書がたくさん並んでいます。

・データシート

・エラッタ

・アプリケーションノート

・ユーザーガイド

etc

一体何が違うんだ、どれを見ればいいんだ、となると思うので、ざっくり説明したいと思います。

データシート

対象：ハードウェア開発者

データシートは基本となる文書ですが、そのデバイスの全容を網羅的に書いています。

・電気的特性

・中身の構成

・ピンの並び順

etc

一部ソフトウェア開発者が見る部分がないこともないですが、ほとんどハードウェア的なことを書いてあります。

これを読むことで、ハードウェアの概要がわかります。

エラッタ

対象：ハードウェア開発者＆ソフトウェア開発者

半導体製品にもソフトウェアと同じようにバグが有ります。

そのバグを説明する資料です。

アプリケーションノート

対象：ハードウェア開発者＆ソフトウェア開発者

データシートは淡々と特性や中身の説明している文書ですが、

「私はこのCPUを使ってUSB通信をしたいのですが実際にどうやればいいんでしょう」

みたいなことには答えてくれません。

そこで「こういう機能はこうやって使ってね」「こういう設計するといいよ」みたいな手引書がアプリケーションノートです。

自分が実現したい構成に近いアプリケーションノートがあればラッキーです。

アプリケーションノートは、ソフトウェアとハードウェアの両方について書いて有ることが多いです。

役に立つアプリケーションノートがない場合、手引無しで作ることになるので苦労します。

ユーザーガイド

対象：ソフトウェア開発者

アプリケーションノートは機能別に手引をしてくれますが、ユーザーガイドはさらに噛み砕いた文書です。

「開発環境のインストール方法」「デモボードの使い方」みたいなことを説明しています。

極端な話、ユーザーガイドで書かれていることは専門家でもなくてもできます。

（手順通りにやればいいだけで、ほとんど知識がいらないので）

と、こんな位置づけになっています。

デバイスを選定するときには、データシートで判断して選んで、

実際に回路設計するときはアプリケーションノートとデータシートを交互に見て、

基板ができてソフトウェア開発するときには、ソフトウェア開発者がユーザーガイドを見ながら開発環境をセットアップする……というような流れです。

以上、小田切でした。

回路設計とはちょっと違うけど閑話休題的に。

自分が勤めていた会社でも自社商品というのを作っていました。

ボチボチ売れたものもありますが、ほとんど売れないものもありました。

というか全体的に見て、開発にかけたコストを回収できてないと思います。

なんでそんな風になってしまったのでしょうか。

どうも、「こういう製品を作ろう」と営業だとか役員が考えて作ってしまうのが原因のようです。

逆にある程度顧客になりそうなところにヒアリングして作ったものは、まぁまぁ使われました。

つまり、潜在顧客の意見を聞いて作ったものはよくても、こちらが思い込んで作ったものは駄目だったようです。

考えてみれば当たり前ですが、世間で流布している俗説などが悪い気がしています。

名経営者の伝記などで「世の中の人に調査しても新しいものは生まれない。新しい需要を作り出すつもりで新しいものを作れ」的な事が書いてあります。

これを信じれば、思いついた製品を作るのは悪くないように思えてしまいます。

なにが間違っているんでしょうね。

第一に、企画の本気度が違うんだと思います。

ホンダの創業者の伝記でも「俺はこれを作るんだ！俺はこれを信じているんだ！」みたい熱いパッションで作っています。

ですが、世の中の企画というのは「まぁ、こんなもん作れば売れるんじゃないかなぁ。別に自分はそんなに思い入れ無いけど」みたいなのが多いわけです。

これだけ本気度が違えば失敗するでしょう。

第二に、実際の開発ではほとんど新しい物を作ってないということです。

高度成長期に全く新しいジャンルの製品（ウォークマンとか）を作っていればたしかに新しいです。

これはリサーチしても作れない製品だったと思います。

しかし、世の中の殆どの企画というのは類似品があるわけです。

すでにある商品とちょこっとだけ違うものを作っているだけなんです。

だったらリサーチできるので、リサーチを活用したほうがいいですよねって話。

とまぁ、こんな感じで、伝説になっているような製品の開発の話というのは特例だと思うんです。

すべての製品の開発でそんな考え方をしていてもうまくいかないと思うんですよね。

なので、「人生をかけていない製品」「類似品がある製品」だったら素直に潜在顧客の意見を聞いてニーズに合わせて開発したほうが上手く行くと思います。

まぁ、人生をかけているような熱い製品が見つかれば、そのパッションで貫いちゃってもいいかもしれません。

以上、小田切でした。

たまにハードウェア開発もその上のソフトウェア開発も全部やるという人が居ますが、普通は別々の人が行います。

そんな立場のハードウェア開発者がプログラミングの知識が必要か？という話題です。

いきなり、結論。

ある程度は必要。

ある一定以上があると便利。

◯必要な部分

ハードウェア開発者というのは特に組込系になると、ソフトウェア開発者と密なやり取りをします。

その時に「え、なにそれ？」状態では話が進みません。

プログラミングの基本的な知識は絶対に必要です。

変数や関数、割り込み、スタック、等の知識は必須です。

なので、教科書的な用語の意味を知った上で、チュートリアル程度でもいいのでC言語でプログラムを書いて動かすという経験があるべきです。

◯便利な部分

ハードウェア開発では部品表だとか、アートワークで提出されるデータだとか、結構大量のリストを扱います。

基本はテキストファイルです。

ハードウェア開発では、時に大量のリストを照合したりコピペしたりといった作業が発生します。

しかも、同じような作業が何度も発生します。

そういったときに、テキストファイルをちょちょっと処理できるプログラムが書けると効率が劇的によくなります。

ということで、rubyやperlなど、テキストを簡単に使えるスクリプト言語を扱えると非常に楽になります。

あとはEXCELのVBAも扱えると更に便利です。

ということで、ハードウェア開発者だからといってプログラミングを避けずに勉強しましょう！

以上、小田切でした。

またもや信頼性試験ネタ。

温度をかけたり、落としてみたり、静電気かけてみたりと、いろんなことをやるのが信頼性試験ですが、自分で決める立場になると難しいものです。

いったい、信頼性試験の中身やレベルってどうやって決めるんでしょうか。

開発を受ける立場で「こういう試験をやってくれ」と言われて実施するなら困りませんが、決める方になると途方に暮れます。

そもそも、信頼性試験の立場は法律でもなんでもありません。

電波法やPSEなど法律と関係する試験もありますが、ほとんどの信頼性試験は法律と全く関係ありません。

また、信頼性試験の様々なことがJISで定められていますが、JISは規格であって法律ではありません。

だから、「これをやればOK」みたいな絶対的なものがありません。

つまり、信頼性試験というのは「業界慣例」だとか「会社のリスク回避」でしかないのです。

極端な話、電波法などが関係する部分以外はやらなくても法的な問題はないのです。

実際の所、信頼性試験なんてほとんどやらないで出荷してしまうとこもあります・・・

さすがに全くやらないのは危険ですので、やるべきです。

全く確認ができてないわけですから、出荷した途端にトラブルが多発してしまいます。

もしその製品の業界で基準となっているものがあれば、そのレベルの試験をしたほうがよいです。

もしそういったものがないときは、実際に扱われる場面を想定して試験の基準を決めないといけません。

ここの話は大変なのでいつかそのうち・・・

以上、小田切でした。

ESD試験の基準はだいたい他所からの要求で決めるものですが、自分で決める立場になると決めるのが結構難しいです。

そうしたら、なんかいい表を見つけてしまいました。

ネット上にあるものではないので、内容だけ紹介します。

これはあくまで目安なので、参考程度にお願いします。

これを基準にどこまで厳しくするか、という考えでよいように思います。

以上、小田切でした。