7月ですね。ここ1週間ぐらいで急に暑くなって辛い。
モンハンのサンブレイクが流行ってますね。

先週まではゴリゴリXopsAddonCreatorを作ってましたが、今週は一転して
電子工作ネタでプリント基板設計してました。

内容としては去年4～5月頃に作っていた、高速信号系の基板です。
　回路引いたり部品買ったり基板起こしたり（2021.04.19）
　モーターが回りました（2021.05.18）
　　※紛らわしいですが、同時期にやっていたパワエレとは無関係です。
去年作った基板は、某所の現場（？）でも使われていますが、場合によっては
うまく使えないことがありました。
騙し騙し使い続けていましたが、流石に使い勝手が悪いので改良版の開発に着手
した次第です。


不具合が出る原因は正確には分かっていないのですが、当初は高速信号のライン
・構成が悪いのかと疑っていたものの、
電源部分に数百uFの電解コンデンサーを付けると改善方向になることから、電源
ラインが悪そうだと目星を付けています。
今思うと、基板全体で流れる電流量に対して、電源ラインのパターンが細すぎ
たのと、GNDのベタパターンもルートが悪かったりと、色々と詰めの甘い基板
設計だったので、その辺の電源・GND周りのパターンを見直すのが今回のメイン
ミッションです。

今回、運よく使用技術の規格書が入手できたので、参考にしつつ可能な限り
規格準拠を目指して回路図やパターンを作り直していました。
もちろん規格完全準拠ではないのですが、別に外に出すものではなく某所の
クローズドな環境で使用するものなので問題ないです。
当たり前ですが、既存製品を調べ上げて それっぽく再現することに比べれば、
一次ソースである規格書を参考にできるのは強いです。

あとは、不必要なパターン・部品を取っ払い、逆に使いそうな回路を新たに実装
して、設計全体の最適化を狙っています。

基板設計に加えて、機構設計（？）も やや改善を試みるつもりです。
前回は「機構？　なにそれ、おいしいの？（＾＾」状態で、部品の固定を
殆ど考慮しないで作ったため、使用中は物理的にも安定性に欠けていました。
今回は、ある程度は部品の固定も考慮するつもりではいます。

使用する部品は発注したので、部品が届き次第 部品と合わせて基板設計の最終
チェックを行い、基板を発注する予定です。
基板をどこに頼むかは決まっていませんが、前回と同じ中国の製造メーカー
に発注しようかとは思っています。安いですし。


本当は、写真なども加えてもう少し詳しい話ができれば良いのですが、ネット上
で一般公開している記事である以上、どこで誰が見ているか分からないので、
詳しい説明は伏せようと思います。

それにしても、プログラミングでXopsAddonCreatorを弄るのも楽しいですが、
回路設計・基板設計も楽しいですね。良い休日を過ごせました（＾＾

ちょっとしたマイコン制御をする用事が湧き出てきたため、
新年明け一発目である この休日は、主にAVRマイコンを触っていました。


去年8～9月頃にPSoC 1触った際（※当時の記事）に思ったことで、
開発環境がWindows10で動かなくなったわ、チップが次々ディスコンになり
年を追うごとに入手性が悪化してきているわ、こりゃそろそろメイン使いの
マイコンを乗り換えないとダメかなと。
後継のチップ（PSoC 3/4/5LP）もあるにはありますが、DIPパッケージがなく、
言うほど入手性が良い訳でもないため、他マイコンを探しました。

「入手性が高い」「情報量が多い」「DIPパッケージがある」「比較的安価」
という点を重視し、AVRにしました。
PICでも良かったのですが、もう同じMicrochipですし。

過去のブログ記事によると、2017年3月頃に一度AVRをやろうとしたようです。
本当に・・・？　モノもないし開発環境もないし、全く覚えていないのだが。
もしかしてArduinoの間違いじゃないだろうか。

先日、とある試験を数年ぶりにオンラインで受験したところ、壊滅的で悲惨な結果
でした。まぁある程度は想定したのですが。

この週末は電子工作をやっていました。
部屋を片付けていたところ、2020年春ごろに電子工作で使ってみようと衝動買いした
モノを偶然見つけたことが発端です。
せっかく見つけたので、この度触ってみることにしました。


XOPSとは全く関係ないですし、改めて他所で別名義で出すかもしれないので多くは
語りませんが、
最大の肝は、スイッチ入力により音を再生するのが味噌になる回路です。
（味噌も何も、ほぼそれが全てなのですが。。）
音は、圧電スピーカーではなく、ちゃんとしたスピーカーを使います。

どうやってスイッチ入力に応じて音を出すか。
（今となっては）やり方は無数にありますが、手っ取り早くArduinoを使うことに
しました。
PCやスマホにスイッチを繋げて、PC・スマホから音を出す構成にした方が、圧倒的
に楽なのは分かっていますが、できれば装置単体で動かしたいなと。
わざわざFPGAを引っ張り出すまでもないレベルで、この程度ならマイコンで十分です。
PSoCでも良かったのですが、Arduinoの方が情報が多くて作りやすそうなので。
Raspberry Piでは、ちょっとオーバースペックなんです。
色々調べた結果、音のデータはFAT形式でフォーマットしたSDカードに入れて、
レベルシフターを使ってSDカードとArduinoを接続し、
Arduino上ではTMRpcmを使うのが良さそうだということが分かりました。
スピーカーとはArduino直結で行けるか、オペアンプを挟まないとダメかどうか・・
っといった具合です。

これで行けると思っていました。行けるはずでした。
やってみたら全然だめでした（；；

まず、SDカードの初期化に高確率でコケます。これが最も謎で良く分かりません。
一番疑わしいのは回路の接触不良です。ブレッドボード上に組み上げたのですが、
全体的に電気的な接触が怪しく、SDカードの挙動に影響が出ているようです。
あと、思った以上に音質が悪い。これはブレッドボードの問題というより、
Arduinoとして動いているAVRマイコンのHWか、Arduinoのプログラムの問題か、
または元の電源が良くないのか・・・、これもよく分かりません。
スピーカー自体も小さくてパワーの弱い安物なのですが、10年前に別件で使った
時は、もう少しマシな音質だったと思うのですが・・・。

おい、ぜんぜんサクっとできないじゃねーか。思っていたのと違うぞ（汗

いや、しっかりと腰を据えてガッツリとやればいくらでも手を掛けられる話で、
例えばFPGAでゴリゴリ作り始めたら　あっという間に何週間も掛けられる世界
ですが、
あくまで片手間で手を出しただけであり、そこまで本気でやる気は全くありません
でした。
なので、ネット上の情報をかき集め、Arduinoでサクッと作ってみて終わらせる
気でおり、丸一日程度である程度プロトタイプまで作り上げるつもりでした。
ところが、いざやってみると苦戦を強いられ全然だめでした。

まぁ（ほぼ確実に）できると分かっていることを作業的にこなしているわけでは
なく、
Arduinoという言うほど使いこなせていないものを持ち込んで挑戦しているので、
うまくいかないのは当然なんですけどね。
当然なんですが、こうもうまく行かないとなぁ・・・。


あまりガチになって攻めるつもりはなかったので、（この記事の一件は）一旦
終わりにするつもりです。
どうも当初の予想に反して片手間で適当にやって できるものではないと分かった
ので、今度いつか時間を作ってじっくりやってみるつもりです。
優先度は低いですし、いつになるか分かりませんけど。

それにしても、単に『スイッチの入力に合わせて音を出す』ってだけでも、
自身の中でも色々選択肢があるのは、適材適所で使える手札が多いってことで
良いことですよね。

他所（XOPSとは無縁）で、ちょっとしたマイコン制御の基板を至急作る
必要があり、例のごとくPSoC1を使いました。
　※相変わらずサイトが重い...
ちょうど2年前にも別件でマイコンを使う用事があり、その時もPSoC 1を
使いましたが、今回も めでたく採用です。（当時の記事）

前回どんなPC環境で開発したのか記憶になかったがゆえ、なんの疑いもなく
Windows10が入ったメインPCを使おうとしたのですが、同マイコンの開発
環境である「PSoC Designer 5.4 SP1」がWindows10で動作しませんでした。

開発環境を動かすためには、インストール時に同時にAdobe SVG Viewerを
入れる必要があり、通常は自動的に入るはずなのですが、
どうもWindows10では同ソフトウェアが正しくインストールできず、開発
環境がまともに動きません。
Cypress（現：Infineon）の公式案内ではAdobe SVG Viewerを手動でインストール
するよう求められています。
　・PSoC Designer 5.4 SP1とWindows10との互換性 - KBA228632
ところが、Adobeのページに行ってもサーバーエラーで入手できません。
　・SVG Tools Download Area
非公式ですが
『PSoC Designer 5.4のAdobe SVG ViewerがWindows10非対応になった』
との情報がありました。
どうも最近のWindows10では開発環境が動かないようです。
（古いVerであれば動くらしい・・）
　・PSoCの部屋へようこそ

一瞬「あっ、終わったわ....　（；；」と思ったのですが、オドオドしている
時間もなかったので、ひとまず取り急ぎWindows7が入ったサブノートPCを
引っ張り出して使うことで、事なきを得ました。
（てかWin7のサブノートPCには開発環境が入れっぱなしだった。）
やっぱり使い慣れたマイコンはイイナー。実家のような安心感（＾＾


とは言っても、そろそろPSoC 1からは乗り換えないといけない気がして
きています。

既に、初代PSoC 1の後継に当たる、PSoC 6 / PSoC 5LP / PSoC 4、そして
PSoC 3が登場しており、CypressとしてはPSoC 1は終息させる方向です。
デバイスが次々生産終了になり、ここ数年で一気に入手性が悪くなりました
が、おまけに今回Windows10で開発環境がまともに動かないことが発覚
しました。

確かにPSoC 1自体は、非常に優れたマイコンで気に入っていますし、
完全にプライベートで「ちょっとマイコンを触ってみよう」ならば、まだ
使用する理屈がある（弁解・解釈のしようがある）のですが、
ある程度 他所で明確な使用予定・用途があり、のんきなスケジュールでは
動いてられないような場合、
『デバイスも満足に手に入らない、開発環境がWindows10で動作しない』
みたいなマイコンが活動の足かせになるようでは困ります。

PSoC 3やPSoC 5は所有しており使用経験もありますが、PSoC 1以上に
開発環境が魅力的で使いやすいものの、チップ単体の入手性が低く、
なんせ標準でDIPパッケージがないので、2.54ミリピッチのユニバーサル
基板でちょっと何かを作るときには、シンプルに作ることができず、
かなり面倒くさいです。
mbedやRaspberry Piではちょっとオーバースペックな場合もあり、
Arduinoは基板サイズが大きく2.54ミリの普通の基板がそのまま刺さらな
かったり（そうでもない派生基板もあるが）するので、
次乗り換えるなら、
　・DIPパッケージがある
　・チップの入手性が良く特別高価でない
　・極端に超マイナーチップではない
という条件のもと、PIC か AVR かなと思っています。（要調査）

「使用するマイコンを乗り換える」って、言うほど簡単ではありません。
「とりあえず触ってみる」であれば、適当にチップなり評価基板なりと
参考書を買ってくればOKですが、
「（PSoC並に）急な要求にも即座に応えられるレベルで使いこなす」
となると、数日・数回触るレベルではダメで、一通りの使い方はマスター
してチップの限界を把握しておかなければならず、おそらく数週間～
数ヶ月レベルで掛かります。
FPGAの件とか　OpenXOPSの件とか　色々控えているので、使用マイコン
乗り換え調査＆プロジェクトは、ちょっと先になりそうです。
でも、また何か案件が湧いたときに、PSoCが...　とか言ってると遅いんだ
よなぁ。

もう過ぎてしまいましたが、8月17日は「みかん箱」誕生15周年だった
のですね。今年は（今年も？）何もできませんでした。ごめんなさい。
15周年ということで思うこともありますが、次回以降 改めて書きます。


FPGAでのギガビット・トランシーバーによるGbps通信ですが、ゴール
（最終ゴールではなく、正しくは第一部のゴールで全体の中間地点）
が見えてきているものの、まだ最後が詰め切れていません。

今ある大きな課題は、
　１、初期化シーケンスがうまく行かない場合がある。
　２、FPGA内でデータが化ける場合がある。
です。


『１、初期化シーケンスがうまく行かない場合がある。』というのは、
前の記事でも触れた通り、通信を初期化する際に不規則に初期化処理が
コケて通信が開始できない場合があるのです。。

ロジックアナライザーやプロトコルアナライザーで解析する限りは、
FPGAから出てきている信号は正しい「はず」で、通信相手のデバイスが
決められた応答が返ってこない状況です。
状況的には「デバイス側の問題だ」と断定したいところですが、他の
メーカーのデバイスに交換しても、やっぱり動かないことがあるので、
問題発生の前後含め、何かしらFPGA側の信号に非があると考えられます。
こっち（FPGA側）は規格通りに動いているはずなんだけどなぁ。
んー謎だ。。よく分からん。


『２、FPGA内でデータが化ける場合がある。』というのは、FPGA側
の送受信処理時に通信データが化けたり、意図しない通信サイズに変化
してしまう（だいたい増える）現象が発生します。
前の記事では『特定のコマンドの組み合わせが通らない』と書きましたが、
これも中の通信データが化けることで、プロトコルとして成立しない
のが原因でした。

これは何となく原因が予想できており、おそらくプロトコルの制御部分
か、またはFPGA内に実装したキャッシュメモリーの挙動が怪しいのでは
ないかと思っています。
別途シミュレーションを実行しても問題なく、タイミング解析上でも
エラーは出ていませんが、
プロトコルとメモリーの制御周りのロジック動作が非常にシビアで、
わずかな信号・動作遅延により、プロトコルの入出力処理が崩れ、
メモリー内のデータが破壊されているのではないかと推測しています。

ただ、直すのは至難の業です。
一番単純な解決方法は、動作クロック周波数を（例えば倍に）上げて
1クロックあたりの実行ステップを減らすことで安定性を高めることですが、
FPGAの動作速度にも限界があり、これ以上動作クロックを上げることは
できなさそうです。
こりゃ、アーキテクチャ自体を見直さないとダメだろうか・・・。


おそらく上記１・２をクリアーすれば、（中間地点へ）無事ゴールできる
と思っていますが、
一方は全体の見直しが必要な可能性があり、もう一方は原因すら掴めて
いないので、ここから前進するのは難航するかもしれません。

XOPS関係など他にリソースを充てたい関係で、可能であれば8月中、
遅くとも9月中には、何かしらの目途を付けたいです。