いろいろ試す18

GW中は副業(本業は虹裏メイド)が糞ほど忙しかったのですがおかげで給料も
貯ま…るわけがなく円安を迎えた今はひたすら安価な小物や以前に買った
物をただひたすらに消化していきまっす！

●秋月さんとaitendoさんのi2c液晶キャラクタ液晶モジュール

ぇ？昔i2c液晶の記事書いてたやんだって？さぁ？何のことですか？
これのこと？これはキャラクタじゃなくてドットマトリクスですから別物です別物！

…さて、ホビー用途では配線の手軽さから不動の地位を確立したi2c液晶ですが
秋月さんから安価なAQM0802A-RN-GBWが発売され私もi2c液晶でびぅです♥

コントローラはST7032iというi2cインターフェースに特化したものだそうです。
BOLIMYINの提供していたサンプルのおかげで危なげなく表示出来ました！


お次はaitendoさんから販売されているバックライト付きで破格のi2c液晶たちです！
もう基板に組み込んでますが、秋月さんのと同じくST7032iのコントローラICで
簡・単・表・示…
…と思いきやO-Familyさんも遭遇したF**Kな不具合にねむいさんも遭遇し,"i2cバス
リカバリ"の重要さを思い知らされる羽目になったのでした…
(※STM32F4のFatFs実装例ではすでにi2cバスリカバリのルーチンを実装しております)

これについてはいずれ解説するであろう"i2c液晶を使ってみる"でみっちりと…


●OZSSとGLONASS対応のGPSモジュール Gms-g9

去年の冬,Gms-g6aというMT3333が乗ったモデルを使用していましたが、チップ
アンテナを使用しているため、せっかくの新モデルなのに初回補足時間/感度は
あまりよろしくありませんでした。
4月末に某送料が安い方の欧州店でパッチアンテナモデルのGms-g9が
ようやく販売され、遅ればせながら私もｹﾞｯﾂした次第です。

既に使用されている方のレポートによれば消費電流もPA6Cよりはちょっと多い
(GLONASSの処理があるから)ものの十分控えめなのでSTM32Primer2のロガーと
組み合わせても私のトレラン用途には全く問題ないようです。私はすでに
Gms-g6aで予習していたのでロガー側もGN系センテンス対応済みでそのままPA6Cと
差し替えて試せそうです。

というわけでいつものユニット化してみました。いちばん右の黒いのがGms-g9です。
PA6Cよりもパッチアンテナの面積が広いので感度はさらに上がっているでしょう。
あいにく今週から梅雨に入ったのでPA6Cとの比較試験は来週以降、トレランでの実践
投入は6月末を実施予定としています。


●ILI934x Mystery
SPIモードでDeviceCodeの読み出しができるようになるまでのお話。
Seeedstudioの中の人がいかにしてデータシートに記載されていない複雑なコマンド
体系を見つけだしたのかはいまだに謎
それとねむいさんの英語力に突っ込みを入れないように！！！




●LPCLink2

LPCXpressoに密着していたLPCLinkはirukaさんの解析によると変更不可能なOTPに
よって機能が限定されており外部から全くhackすることが出来ずどっかのSTM32では
出来たDiscoveryでVersaloonが出来ないじゃない！と判明しごくごく一部の解析大好きな
好事家からはったくNxPはｾｺｲな!とスル―してｹﾞﾌﾝされておりました‥

が、

今回デバッガハードウエア単体として販売されたLPCLink2は回路図全公開、さらに
ファームウエア変え放題でしかもCMSIS-DAPやJlinkファームウエアまで用意している
という超太っ腹なボードとなっておりました！

ねむいさんも秒速で入手しその威力を早速試してみました…

電圧変換は前回紹介した74LVCxTx45系が使用されています。LPCLink2ではDIRを
入力に切り替え疑似的にOD化し、1.2〜5.5Vの非常に幅広い電圧範囲をカバー
しているようです。


…LPC4370…？


ねむいさんの目的はJ-Linkです。ほかは一切視界に入れません。THE・シカトです。
そっこう中身のファームをDFUでJ-Linkにしようとしましたがホントの最初はドライバ
不要のHIDローダーで認識されDFUをさらに読み込むようです。この時にDFU用の
WinUSBドライバを読み込ませていないとJ-Linkへのアップデートに失敗するのでご注意を。

WinUSBドライバを読み込ませてこれでJlink化完了！



…ぇっとOpenOCDとかで使ってみましたが‥JTAGKey2と比べるとワンテンポほど
反応が遅くてちょっと微妙な感じです。無理にOSSで使うよりSegger提供のツール
使った方がいいかもしれません。ファームウエア(spifiに格納される)はいくらでも
書き換え出来るのでいろいろやってみましょう。
…そう自分で作成したプログラムも…
20130603追：
やっぱりJlinkエミュレーションのファームヤバかったようで
修正版が2013.05.31にUpしてます…。

で、LPCLink2にはTargetのJTAG端子のほかにLPCLink2の心臓部のLPC4370からも
JTAGが引き出されています。LPC4370って検索しても2013年5月末現在は詳しい
資料全く出ていないしLPC4350系のメモリ多い版かしらと思って何気なくUrJTAGで引っ掛けて
みると…


なんとコアが3つありました…
CortexM4とCortexM0が2つの合計3コア…
トリプルコアなの！？



次回に続く！！

Amontec夜逃げ記念☆JTAGKey2互換回路をもっと使ってみる2

20150514追:
2015年現在、JTAGKey2CompatibleのRev.5まで
上がっています。自作される場合はこちらを参考にしてください。
20150514追:



数年前、FT2232Hを利用したJTAGkey2Cloneの紹介をしました。しかしちょっと自分で
も回路上で疑問を感じる点が多く、かねてから再製作の構想は考えておりました。
昨今のロジックICの性能向上も相まって2013年の今、再び満を持しての再製作となり
ました…最初に書いたのもう3年前か…もう3年も経ったの…さんねんも……


ｹﾞﾌﾝ失礼、前回は単に回路図と実に抽象的な使用例を紹介しただけでしたが今回は
どうしてそういう部品選定or回路に至ったかのねむいさん的ポリシーも述べます!

●肝心な回路図は…
実は少し前から公開していたのですが…以下のリンク先"JTAGKey2"のディレクトリ内
にあるpdfファイルが新しいJTAGKey2互換回路の回路図となります。
FT2232Dを使ったJTAGKey無印の互換回路も2009年当初のままですが下記リンク先の
"JTAGKey"のディレクトリに収録していますので同じくご参考までに。
JTAGKey or JTAGKey2Compatible Circuits

神木さんのJTAGKey2互換を参考にして作ったねむいさんのJTAGKey2互換を参考に
して作ったjujurouさんのJTAGKey2互換を参考にした最終形です！

そして以前使用していた"Clone"という単語は以下の理由でそぐわないのでもう使わ
ないようにしました。これからは"互換(Compatible)"で統一といたします。

●オリジナルのJTAGKey2との差異
夜逃げしたAmontecから販売されていたJTAGKey2純正品とは機能面で差異があります。

1．暗号化EEPROM(DS2432)の有無
　これはオリジナルではFT2232のB側のバスのどれかに接続され、Amontec社が
　提供しているamthal.dllはここから書き込まれた情報を読み出し正規品判定を
　行っています。
　digilentの"JTAG HS-1"もそれと似た仕組みで判定を行っているようです。

2. LEDインジケーターの設定
　ねむいさんのJTAGKey2CompatibleのLEDの設定はJTAGKey無印をベースに
　しています。JTAGKey2で変更になったLED表示とは全く合っていません。

3. Lattice-ISPVMの使用可否(OE強制制御)
　Lattice"さん"提供のISPVMは数年前にFT2232系デバイスからでも書き込みが
　できるように神対応をして下さいました！！しかし純正のJTAGKey2からはOEの
　手動コントロールが不可能(MPSSEを強制直結状態にできない)のため蓋を
　こじ開けてジャンパを飛ばさない限り使用不可能です。

OpenOCDやUrJTAG等のフリーなツールでは純正/互換品に関わらず同じ"JTAGKEY"
として扱われるのでまったく問題なく使用が可能です♥


●回路解説
いくつかのブロックに分けて主要部の解説をします。

　1.FT2232H周辺
　　JTAGKey2互換初号機と同じくDLPDesignのDLP-USB1232Hを使用しています。
　　面倒なUSB-HS周辺やFT2232系で必須なEEPROM等の周辺部品を搭載し
　　モジュール化されており非常に簡単に扱うことができます。
　　今だとUM-232H等のFT232Hを使ったモジュールなども使用可能と思われます。
　　ただTx/RxバッファがFT2232Hよりも少なく処理速度に影響しますので、
　　その点はご留意ください。

　2.電圧変換(電圧レベルトランスレータ&バッファ)
　　JTAGKey2互換回路の心臓部です。ここで+1.4V〜+5.5Vまでの幅広いターゲット
　　電圧に対応します。前回は+1.65Vからでしたが昨今のロジックICの性能向上に
　　伴いサポートされる電圧範囲の保証される下限がさらに下がりました。
　　それ故に型番どころか製造メーカ指定まで必須となります。ねむいさんの
　　ぶろぐ見てる人は同じ74シリーズの同型番でも製造メーカー間で性能が
　　微妙に違うという昔からよく知られている事実は常識中の常識のはずなので
　　理解していただけるかと思います。
　　DIODES Inc. Semiconductor の74LVCE1G125"、
　　Nexperia(旧NxP)の"74LVC2T45DC"を指定して使ってください。
　　他メーカーの同型番は駄目です！

　　また、各バッファICに繋がりFT2232Hから制御されるOEの制御線は必ず+5V
　　(回路図中ではVbus)で攣ってください。JTAGKey2をPCと接続したときの
　　これらは入力/Lo出力の疑似的なOD扱いで制御するPC側アプリが多く、
　　+5V系で攣っていないと+2.5V付近の中間電圧が掛かってしまい動作不良の
　　原因を作ってしまいます。

　　jujurouさんが指摘していた+5V系の動作の考察についてはさらに掘り下げて
　　別枠で考察させていただきます。


　3.ターゲット電圧検知
　　こちらに関してはJTAGKey互換のころと同じく元NEC現ルネサス製のデジトラを
　　使用しています(ねむいさん的定番部品です)。
　　↑Rev.4でルネサスを排除しました。使い勝手良かったのですが…さらばFB1A4M。
　　　代替としてROHMのデジトラDTD123YKT146を指定しております。
　　↑Rev.5に回路が変わりました！

　4.OE強制制御
　　切り替えスイッチで無理やりバッファのOEをGNDに落としてMPSSEで使用される
　　ポートをターゲットと常に直結状態にします。これは上述のとおりLatticeのISPVM
　　やデバッグ用途で活躍します。3Pの少信号用SWならなんでも使用可能です。


●実際に組んでみよう


今回はアイテムラボさんのパワーメッシュユニバーサル基板を採用しました。
本来ならVCCに使うべきレーンもすべてGNDに割り当て高速信号の扱いを意識して
配線を行いました…行 っ た つ も り で す ！ ！


前回はFT2232Hのモジュール上部が吹きさらしで打撃を喰らいやすい危険な
構造でした。今回からアクリル板を加工して屋根を設けました。
いい感じですね♥


10MHz越えの高速信号を外に引き出すので信号線とGNDが交互に来るフラットケーブル
は必須です。さらにSEIWA製コの字型フェライトコアを設けて外来/輻射ノイズを殺す
ようにしています。

もともとチップバリスタも基板上に実装するつもりでしたがフェライトコアだけで
100V/1uSecのインパルスノイズ耐量試験を余裕でpassしてしまったのでチップ
バリスタは未実装のオプション扱いにしました。

一からJTAGKey2Compatibleを作る場合は初めにPCと接続したときにVID/PIDが
FTDIの素のFT2232Hとして認識されます。FT2232Hモジュール上のEEPROMに
データを書き込むために先ずはFTDIのドライバを認識させてください。
JTAGKey/JTAGkey2製作用に特別にinfに書き加えたものを用意しましたので
必ずこちらを使用してドライバを読み込ませてください。
2じゃない方のJTAGKeyを作りたい方もこのドライバを使用可能です。


JTAGKey2Compatibleとして動かすためにはEEPROMのデータを書き込んで
化かさなければなりません。従来はMProgを使用してデータを書き込むように
していましたが、現在はFT_Progに統一されましたのでこちらを使用してEEPROMに
JTAGKey2になるためのデータ(xml)を書き込みます。
上のドライバにはJTAGKey/JTAGKey2用のxml
データもJTAGKey_XML.7zとして収録していますのでこれを使用し書き込みを行って
ください。FT_Progの使用法についてはFTDI公式のマニュアルを参照のこと。

書き込みが終わったらUSBケーブルPC一度抜いてさし直してください。成功したら今度
は"Amontec JTAGKey2"として認識されます。

その後はlibusb系を使いたい場合はおなじみZadigでインストールを、FTDIのドライバを
使いたい場合はそのままとしてください。

注:LibUSBKはドライバの入れ替え無しに0.1系と1.0系APIが同時使用可能な便利な
　　ドライバですがWindowsXP下ではあらかじめ0.1系のドライバをインストールし
　　ていないと動作が不安定になるようです。一度0.1系でインストールしすぐに
　　LibUSBKに戻せば問題なく使用可能です。この操作もZadigを使うと楽ちんです



製作したJTAGKey2の動作確認を簡単にしたい場合はOpenOCDよりもUrJTAG
が便利です。ターゲットデバイスに接続して"cable jtagkey"->"detect"の
たった二つのコマンドでJTAGチェインが見えればチェック完了となります。
さらにpodコマンドでSRST,TRSTを含めたJTAGの信号線単体の個別コントロールも
可能なのでトラブルシュートにも役立ちます♥


●ちょっとしたデザインレビュー
20150512追:
以下の検証はRev.4以前のモロが問題だった頃の回路の内容です。
Rev.5にてオリジナルJTAGKey2のサポート電圧範囲に忠実になりましたので
現在はモロで問題有りません。
20150512追:






さて、実際に信用に足るJTAG用デバッガとして使うためにはいくつかクリティカルな
条件を設け試験する必要があります。JTAGkey2互換回路では大きく分けで2つの考慮
すべき点があり、どちらも回路図中の電圧レベル変換ブロックに集中しています。


1.電圧入力レベルに関する点
FT2232HのI/Oの電圧はMAX30Mbpsの高速信号を扱うため+3.3V系のLVTTLと呼ばれる
電圧レベルで固定化されています。(FT2232D系だと3.3V〜5Vで可変だったのですが)
これを考慮してかFT2232Hは+5VI/Oトレラントとなっており+5V系の入出力に対して
耐性を持っています。ですのでFT2232Hの+3.3V出力に10kohmで+5Vにプルアップ
する程度の衝突ならびくともしません
(この荒業は疑似的なOD制御の時に役に立ちます)。
また、SRST,TRST,JTAG各信号線のゲーティングをしているバッファICのOE端子は
FT2232H側が疑似的にOD出力の形で操作しているため、常に+5Vで吊るのが正しい
です。(FT2232H,74LVCE1G125,74LVC2T45のいずれも+5Vの入力トレラントを持つ)


本回路中で使用されている74LVC2T45DCは+1.2〜+5.5V,74LVCE1G125は
+1.4〜+5.5Vまでカバーしており、何れも+5V入力トレラントも保証しています。
つまり+1.4〜+3.3Vまでの回路の場合は電圧入出力とも全く問題はありません。
しかしターゲットが+5V系のケースでは74LVCE1G125のHレベル入力下限(3.5V)を
満たしません。
こちらについてはjujurouさんの情報をもとに74AHCT541(※)を挟み、
LVTTLから+5VCMOSの電圧変換を行うことによって電圧レベルの問題は一旦は
解消としました……しかし…

(※…NxP製の物は74AHCT541と74VHCT541の特性は全く同じ)


2.信号の伝達遅延に関する点

74AHCT541を挟んだことによって同素子内部のゲートを通過する際の遅延が余分に
追加されることになりますが、最初に組んだときは204MHz動作のLPC4330と
TCK=15MHzで接続し、周囲温度も十分振って安定して書き込みデバッグできたので
問題なし！としていました。


ですが純正JTAGkey2がサポートしてるのが30Mbpsだったのを思い出し"本当に
30Mbpsで通信できるのか？"と感じ、購入後放置していた公証80MHzまで使用可能な
SPI-ROMSST25VF032B-80-4I-S2AFとFlashROMを使ってTCK=30MHzで読み出し
試験してみました。
が、リードしたデータがすべて1bitずれた状態となってしまい玉砕orz
…というわけで真面目に伝達遅延の影響について考察を開始しました。


ターゲット電圧3.3VでTCK=30MHzで通信した際に一クロックサイクルは33.33nSec
であり、FT2232HのTCKからでたクロックがターゲットのTCKに届き、それに準じて
ターゲットMISOからの出力とFT2232HのTDO(SI)に届くまでの時間の合計が
33.33nSecを超えてしまうとビットシフトした状態でデータが取り込まれアウトに
なってしまいます。

データシート記載の使用温度環境-40~+125度で動作させた場合(データシート上で
明記されてないものは一番条件が絞れてる温度範囲)のパラメータを抽出して計算
すると上図のように33.33nSecを余裕で超える遅延が発生することになり74AHCT541
を挟むと30Mbpsの通信が理論上ですら不可能なのが判明orz


74AHCT541を省くと7.0nSec分遅延がなくなるため30MHzでもビットシフトは
起こらない計算になり、実際に74AHCT541を省いたモロにするとSST25VF032Bと通信
(DeviceIDの取得,書き込み,ベリファイ)が問題なくできることを確認しましたorz
やはりモロでなければだめだったのですorz

それと配線の引き回しも非常に重要です。10cmを超えるような引き回しをすると
上記のモロでも駄目でした。また、FT2232Hモジュールからレベル変換ICを何も
挟まないガチの直結も試しましたが10cm以上を超えるとやっぱりだめです。
30Mbpsで安定して通信を行うためには高速クロックで動作する回路を意識しないと
いけませんね。

PicoScope3206AでTCKの波形取得してみましたが74AHCT541付きの波形は
見るからにちょっときつくなってますね…。

↑15MHzの時のSPI-ROMのTCK波形(74AHCT541付)

↑15MHzの時のSPI-ROMのTCK波形(モロ)


↑30MHzの時のSPI-ROMのTCK波形(74AHCT541付)

↑30MHzの時のSPI-ROMのTCK波形(モロ)


ここでちょっと疑問に思ったのですが市販のFT2232H系のJTAGハードウェアは
本当に30Mbpsで動かせられるのか？という点です。10MHz以下までTCK速度を
落とさないとOlimexのARM-USB-OCD-Hでは安定して書き込みできないという報告
もあり、もしかしてそれらはレベル変換にFT2232D系で使用されていた低速な
LV系バッファが使われ続けているのではないのかと訝しんでしまいます。
純正のJTAGKey2ではどうなんでしょ?？さすがにできるはずですが…???


3.モロへの誘い
で、ここで74AHCT541外したら3年前作ったのと全く同じじゃん！
とお思いの方が多い筈です。
それは引っ込みがつかなくなったねむいさん本人が一番強く感じています。

というわけで癪なのでモロで動かしたときに+5V系で本当に問題が
ないのかの実力検証を行いました。

使用MCU:
　->ATMEGA1284P
動作電圧:
　->+5.65V
　　(安定化電源にてAVRの推奨上限+5.5Vにさらに+0.15Vのマージンを加える)
試験環境温度:
　->-15度~+70度
　　(-15度はコールドスプレーでJTAGKey2互換回路基板上をくまなく冷却,
　　　+70度はドライヤーで同基板上をくまなく加熱)
試験内容:
　->試験環境温度下でATMEGA1284pにOpenOCDを試用しJTAGモード(TCK=10MHz)
　　で100kByte程のプログラムの書き込み動作を行いその動作中にJTAGの
　　通信エラーやフラッシュの書き損じが一切出ないことの確認。

　　JTAGモードにした理由はAVRの場合はコア電圧/クロックに関わらず10MHzの
　　高クロックでAVR内のOCDブロックとの通信が可能なためです。

結果:
　->全く問題なし。
　　現行のAVRドライバはread動作を行うとOpenOCDごと落ちるｽﾃｷ仕様なので上記
　　環境下でJTAGKey2をISP端子につなぎ変えたうえでAVRDUDEにてISPモードで
　　読み出しを行い、さらに読みだしたhexをOpenOCDでJTAGモードでフラッシュの
　　全領域消去->書き込み。
　　そこから再びAVRDUDEでISPモードで読み出しを行いhexファイルの完全一致の
　　確認をもって問題無しと判断しました。


てわけで電圧/温度/TCK速度とも一番厳しい状況を作り試しましたが全く問題は
ありませんでした！試験で使用したOpenOCDはatmega1284pのフラッシュ書き込みに
対応させた奴使ってます。ログは↓こんな感じです。

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/atmegaxxx4p_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.8.0-dev-00011-g70a2ffa-dirty (2013-05-11-14:47)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

adapter speed: 10000 kHz

srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst

adapter_nsrst_delay: 100

verify Capture-IR is disabled

Info : max TCK change to: 30000 kHz

Info : clock speed 10000 kHz

Info : JTAG tap: avr.cpu tap/device found: 0x1970503f (mfg: 0x01f, part: 0x9705, ver: 0x1)

Info : JTAG tap: avr.cpu tap/device found: 0x1970503f (mfg: 0x01f, part: 0x9705, ver: 0x1)

auto erase enabled

Info : device id = 0x1970503f

Info : target device is atmega1284p

wrote 113408 bytes from file main.elf in 4.453210s (24.870 KiB/s)

Info : JTAG tap: avr.cpu tap/device found: 0x1970503f (mfg: 0x01f, part: 0x9705, ver: 0x1)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:05


同じくAVRDUDEはFT2232系MPSSEに正式対応した6.0RC1をビルドして使用
しております。JTAGKey2があれば難しい設定もワークアラウンドも必要なく
ARMもAVRも余裕で書き込みできるようになっていい時代となりました♥


+5V系でAHCTバッファ挟まなくても問題なかった理由は、74LVCE1G125のVthが
実際は中間電位の+2.5Vで切られていてそれさえ跨げばちゃんとレベルが遷移
できていたからと推測します。データシート上の規約におもいくそ違反して
ますが実力/マージン共に十分あることが確認でき自分が理解して使用する
範囲ならモロでも全く問題なしと判断しました。
(↑売り物の製品の設計の時はちゃんとデータシートに記載された
指示/定格をすべて守ったうえでみっっっちり動作テストを行うのが大前提です！)

もちろん保証の範囲外なので、他のメーカの同種型番のIC等では入力に
ヒステリシスが設けられて全く動かないかもしれません。真似して製作される
方は回路図中でねむいさんが指定したICを必ず選定してください。
｢違うメーカのレベル変換ICをどうしても使うんだーぃ！｣という方はご自身で
動作検証を念入りにした上で使用してください！！！！！！！
念入りというのは回数だけ無意味に重ねるだけではなく温度と電圧くらいは
最低限振れという意味です。ベストな環境だけで満足すると
後で絶対にしっぺ返しがきますから…。

ということで74AHCT541はオプション扱いにとどめ、TCK=15MHz以下でしか
使用しなくて電圧的に心配な人だけ付けてね！ていう風にして冒頭の回路図に
最終的に落ち着く運びとなりました。めでたしめでたし。


20150210追：
+5V系の時の74LVCE1G125の挙動をもう少しガン掘るトしてみました。

VCC=+5.5Vにして入力をわざとゆっくりと上げ下げした時に実際に何Ｖで
出力信号が遷移するかという実験をしました。

先ずは立ち上がり。2.5Vできっちり信号が変化しだしているのが分かり
ますね。2.5V以降の途中で波形が乱れている件は後で解説します。

お次は立下り。こちらも2.5Vで信号が変化しだしています。

本来ならばCMOSロジックの場合はVthはVCCの中点で本実験の+5V系上限値
+5.5Vの場合は2.75VになるはずですがLoレベル寄りの2.5Vとなっていました。
実際に使われる+5.0Vで換算すると74LVCE1G125の真のVthは2.27V付近となる
ことが容易に分かります。FT2232Hの+3.3V出力直結モロでもドライブ能力を
十分に強化して電圧降下を起こさなければVthをまたいで1V近くのマージンを確保
できるので電気的には全く問題がないことが分かります
(※FT2232HのI/Oドライブ能力を最弱の4mA設定にしても30MHzでぶん
回しても問題ありませんでした)。

そんな訳でホビー用途ならAHCTバッファ無しのモロで十分であるという結論と
させていただきます。逆に売り物にする場合は今回のロジックICに限らずデータ
シートに記載されている事項をすべて守った上で周囲環境条件を十分に振って
みっっっっちり
テストしまくって最終的にどういう仕様に落とし込むかを慎重に決めてください。
大切な事なので二度言いました。
｢ねむいさんのぶろぐに書いてある通りに作ったおれはしらん｣とかいう奴に
エンジニアの資格は無いです。

また両者の波形とも遷移直後に大きく出力波形が乱れていますがこれは入力
スルーレートの規約(5V時5ns/V)に違反しているからで、遅すぎる速度の入力に
よって発振が起こっています。上記の測定結果は入力をオープン(殆どのケースで
中間電位になる)にしていると出力が発振を起こして予期せぬ誤動作に繋がる
という重要な事柄も示しています。
CMOSの入力は吊るか落とすかどっちかはっきりと！


最後にスルーレート規約も守ったうえでVCC=5Vで3.3Vドライブした時の波形の
例を。VersaloonのSWCLK波形を入力にしています。
ご覧のとおり問題なく電圧の遷移が出来ていることが分かりますね。

Go to top of page