ねむいさんのぶろぐ

いろいろ試す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"、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公式のマニュアルを参照のこと。

業務連絡：
野田様、FTDIドライバをWin8対応に更新しURLも変更しましたので直リンク先を
このページに変更願います。

書き込みが終わったら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-ROM
SST25VF032B-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.75ボルトになるはずですが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波形を入力にしています。ご覧のとおり問題なく電圧の遷移が出来て
いることが分かりますね。