USB FX3がBulkInでハングアップする

ほとんどのPCでは大丈夫だけれども、特定のPCでは、EZ-USB FX3がBulkInでハングアップするという現象が起きてしまいます。

EZ-USB FX3からデータを入力するには、CyAPI.libを使って、

USBDevice->BulkInEndPt->XferData(data, len);

とやります。

このXferData()を実行して、ターゲットがデータを送ってこなければ指定したタイムアウトまで待待つはずです。しかし、一部のPCではターゲットがすぐにデータを返さないとFailしてしまうようなのです。

実際にFPGAからFX3に向かってデータを送信するまでの時間をマイクロ秒単位で変えていってみたところ、125μ秒を超えるとハングアップする可能性が出てくることがわかりました。

波形は上の波形で毎回同じでも、返すタイミングが伸びていくとダメなようです。

おそらく、XferData()を実行すると、INパケットが発行されるのでしょう。ここでFPGAがすぐにデータを返せばよいのですが、125μ秒を超えてしまってNAKが返った（EZ-USB　FX3が「まだデータが用意できていない」ことを示した）場合は、一部のPCでは関数がFailしてしまうのだと思います。

デバイスドライバを最新のcyusb3.sys（‎2013‎年‎6‎月‎10‎日、‏‎16:13:38　V1.2.3.3）に置き換えてみても、結果は同じでした。

本来は、EZ-USB FX3がNAKを返しても、繰り返しリトライするべきだと思うのですが・・

で、CyAPIのライブラリの中を見てみると、このXferData()という関数は、中でBeginDataXfer()、WaitForXfer()、FinishDataXfer()を呼び出しているだけなので、自分でこれらの関数を呼び出してみたのですが、結果は同じでした。

BeginDataXfer()でINパケットを発行するらしいのですが、つまり、BeginDataXfer()の時点でFX3がデータを送信する準備できていないければダメなのです。だから、データが用意できるまで待たせることができません。

これはEZ-USB FX3にFPGAをつなぐ場合だけではなく、どうやらFX3のファームウェアでパケットを作って返す場合でも同じことが起こるようです。

なお、BeginDataXfer()では、DeviceIoControlでIOCTL_ADAPT_SEND_NON_EP0_DIRECTというリクエストを発行しているようです。

    DeviceIoControl (hDevice,
        IOCTL_ADAPT_SEND_NON_EP0_DIRECT,
        pXmitBuf,
        iXmitBufSize,
        buf,
        bufLen,
        &dwReturnBytes,
        ov);

だから、これ以上の解析はドライバの中まで入ってみてみないといけないようです。

今のところ回避方法はみつかっていません。

• 問題が起きるPCではUSB2.0で接続する
• BulkIN転送では125μ秒以上、待たせないようにする

くらいの解決策しか見当たりません。

promgenでbitファイルをMCSに変換する方法

iMPACTを使わずにBitファイルをMCSファイルに変換する方法を、備忘録として書いておきます

まず、ISEのコマンドプロンプトを立ち上げます。スタートメニューの中から、Accesoriesの中にいます。

コマンドプロンプトが立ち上がったら、promgenというツールが使えるようになっています。

オプションはいろいろあるのですが、次のように打てば大丈夫です。

promgen -p mcs -b -w -u 0 フォルダ名\ファイル名.bit -o フォルダ名\ファイル名.mcs

オプションの意味は、

• -b  バイトオーダーの入れ替えをしない
• -w  上書き
• -u 0 割り当てアドレスの指定

です。

※SPI ROMからコンフィギュレーションするときには-bオプションが必要。Platform Flashに書き込む場合は-bはいらない。
※-w  事実上必須のオプション。これがないと出力ファイルが既に存在する場合にエラーになってしまう。

これでもう、iMPACTの使いにくいGUIを使わなくてもよくなります。

RX-CMSIS-DAPをリリースしました

RX-CMSIS-DAPをリリースしました。このソフトウェアを使うと、RXマイコンがCMSIS-DAPアダプタになります。

こういう感じの変なサイトを立ち上げました。マイコンに書き込むMOTファイルやBINファイルは、同サイトからダウンロードできます。

現在、GR-SAKURA、秋月のRX62ボード、RaXino、RaXino-i、究極のRX62Nボードに対応しています。

皆様がすでにお持ちのRXマイコンボードを有効に活用していただければ幸いです。

じつは、このサイトは、CMSで作っています。CMSというのはコンテンツマネージメントシステムのことで、ブログやWordPressのようにWebサイト上でWebサイトを書き換えできるシステムのことです。

管理者ページはこういうふうになっていて、Webサイトの中でWYSIWGエディタが立ち上がって、その中で書き換えできるようになっています。だから、更新が楽！

もうFTPする必要もないし、どこからでもサイトの更新ができます。横のナビゲーションボタンも自動的に生成しています。今までしっくりくるCMSのシステムがなかったので、自作してしまいました。なお、段組みやボタンなどの部品はBootStrapを使用しています。

18bitADC装置でほぼ満足のいく性能が出た

18bit ADCボードがようやく完成に近づいてきました。

まず、昨日までの装置で、入力をGNDに接続した状態でキャプチャした波形はこんな感じでした。

青いのがCh1で、赤いのがCh2です。Ch1は、だいたい±2くらいの範囲(≒60μV)で揺れているのですが、Ch2はその揺れは約2倍あるので太く見えます。また周期的な成分も見えます。標準偏差を電圧に換算してみると、46.89uVと69.25uVでした。

　ノイズの原因

波形の揺れの原因は、隣にあるDACの駆動用信号から混入してきているノイズでした。DACを止めたところ、ぴたりノイズが止まって線が細くなったのです。Ch2のほうがDACに近いため、ディジタルの信号線からノイズを受けたのでしょう。

DACを止めたときのキャプチャ波形はこんな感じです。

線の太さはほぼ同じになりました。ホワイトノイズは同じくらいになったようです。標準偏差を電圧に換算してみると、42.8uVと46.71uVでした。

ヒストグラムを取ってみても、かなり理想的です。

　周波数解析してみよう

でも、まだCh2には周期的な成分が見えています。そこでFFTしてみます。

この図は、周波数の最大値が1MHzです。信号を入れていないのでだいたい-140dBくらいになっているのですが、40kHzくらいのところに-130dBくらいのピークが見えます。これが、Ch2で見えていた周期的な揺らぎの成分です。

この40kHzというノイズは、オンボードの超低ノイズスイッチング電源「LT3439」によるものです。およそ2LSBくらいの揺れを生じさせています。Ch1にはこの成分は見えないので、電源ラインを伝わってきているのではなく、トランスからの電磁誘導によって引き起こされているのだと考えられます。

つまり、ノイズは電源ラインから来ているのではなく、空間を飛んできていると推測されます。この対策は基板の改版時に検討してみることにします。

　ディジタルフィルタをONしたらすごい性能！

ちなみに、FPGAの内部に作ったディジタルフィルタをONにすると、こうなります。1LSBが30μVですから、すごい精度です。18bitADCの性能が出せたと考えています。

　窓関数の効果

さて、こんどはファンクションジェネレータから20kHzの正弦波を入れてみました。

裾野が広がっていて美しくありません。-80dB以下は見えなくなってしまっているので、18bit ADCの意味がありません。

そこで教科書通り窓関数をかけてみることにします。

まずはハミング窓。

-100dBまで下がりました。

Wikipediaによるとナットール窓とかブラックマンハリス窓というのが周波数分解能がよさそうなので、ナットール窓を使ってみました。

すると・・・

わお！　すごくクリアに見えたではないですか。

なんだか高調波もいっぱい見えていますが、きっとファンクションジェネレータの性能でしょう。現在使っているファンクションジェネレータは、高調波ひずみが-55dBcという性能です。つまり、搬送波が-30dBなので、高調波は-85dBくらいあってもおかしくない、という性能です。だから、この高調波は、ADCボード上のプリアンプやADCの性能ではない可能性が高いと思われます。

低ひずみな発振器がほしい・・

というわけで、ADCボードはほぼ完成に近づきました。来月には発売できるように詰めの作業を頑張ります！

RXマイコンでCMSIS-DAPができた！

先日から開発していた「RXマイコンでCMSIS-DAP」がついにできました！

とりあえずは動画をご覧ください。

現在、KEILのMDK-ARMからトラ技付録のLPC810ボードに、プログラムをダウンロードしたり、デバッグしたりできるようになりました。

KEILで使っているときの画面はこんな感じです。

LPCXpressoでも使いたい・・

ところが、このCMSIS-DAPをLPCXpressoから認識させることはできません。なぜなら、LPCXpressoは特定のVIDとPIDでないと認識しないためです。そこで、ちょっとごにょごにょとしたら・・

はい。LPCXpressoからでもRX-CMSIS-DAPを認識してLPC810をデバッグできるようになりました。

このCMSIS-DAPデバッガは、LPC810専用ではありません。LPC-Link2に入っているLPC4370などもデバッグできます。

けっこう苦労した

そりゃCMSIS-DAPだからCortex-Mは全部対応だろ、と言われそうですが、結構難しいのです。デバイスによってCMSIS-DAPで使われるコマンドが違ったりするし、マイナーなものまで使われるので「使わなそうな機能」を端折って実装すると、特定のデバイスで動かないなんてことになります。

開発のときには、KEILのMDK-ARMからデバッガを起動して、送られてくるパケットを見ながらデバッグをしていました。

CMSIS-DAPの実装でハマッた点を述べておきます。

1. APからReadするときにはPOST動作となる。つまり、APから読み出すためのコマンドを最初にSWDで転送して、次の転送でDPのRDBUFF(0x0e)を読み出す。
2. APからReadするとき、最後にDPのRDBUFFを読むようにしておかないと、（つまり、Postのリクエストが中に残っていると）、誤動作する
3. DAP ReadでWAITやFAULTが返ったときに、33bitのデータ+パリティを読み出してはいけない。（別途コマンドで「常に読み出す」を指定した場合は除く）
4. DAP ReadでMatchという動作がある。MASKを設定して、読み出したデータでMASKでANDした値が、MatchValueになるまで待つというもの。Match動作のときには読み出した値をホストに送らなくてよい。
5. デバイスによって、Matchのときの繰り返し回数は異なるので、ちゃんと実装すること。
6. Abortという動作は、ABORTレジスタ（DPのアドレス0）に書き込むことをいう

パケットをずーっと見ていて思ったのは、おそらく、Cortexのデバッグのやり方は、ARM7やARM9の頃と同じく「コード片」を送り込んでいるのだろうなということです。バウンダリスキャンのINTESTコマンドで送り込む代わりに、アクセスポート経由で送り込んでいるのでしょう。

その点はあまり変わっていない気がしました。

機能

結局、真面目にCMSIS-DAPのほとんどの機能を実装しました。

• NXPのLPC810（トラ技のおまけ）
• NXPのLPC4370(LPC-Link2のCPU)
• STMicroelectronicsのSTM F3Discovery
• FreeScaleのFRDM-KL25Z

で動作確認できました。

このRX-CMSIS-DAPは、

• GR-SAKURA
• RaXino
• 究極のRX62Nボード
• 秋月RX621ボード
• Interface付録RX62N
• マルツで売っている青いRX63N

で動くようにして、今週末の公開を目指します。

RXマイコンで動くCMSIS-DAPを開発しています

この土日の間に、RXマイコンで動くCMSIS-DAPを開発していました。CMSIS-DAPというのは、ARMのCortexシリーズ用のUSB-JTAG/SWDデバッガのことです。ARM標準の規格なので、今後、様々な統合開発環境がサポートしてくれるでしょう。

このデバッガを作る目的は、トラ技のLPC810マイコンをデバッグする環境を整えるためです。3月号にはCMSIS-DAPの「トラ技ARMライタ」基板が付属しますが、それを待ちきれない人も多いと思います。

そこで、みなさまが既にお持ちと思われるRXマイコンボード※を使ってCMSIS-DAPを実現しようとしているわけです。

※ たとえば、特電のRaXinoや秋月のRX621ボード。Interface付録のRX62N基板。マルツで売っている青いボード。もちろんGR-SAKURAも

開発はGR-SAKURAとRXduinoライブラリを使って行っています。GR-SAKURAを使うのはマスストレージに見える機能が便利だからです。

GR-SAKURAのUSB機能はUSB仮想COMポートに固定されてしまっているので、ライブラリに手を加えて、HIDを喋れるようにしています。

作ったRXマイコンのファームウェアをGR-SAKURAに書き込んで、GR-SAKURAにLPC810をSWDで接続します。GR-SAKURAにつながっている緑の基板はRS232Cのレベルコンバータです。RS232CからCMSIS-DAPのパケット解析結果を吐き出します。

MDK-ARMからCMSIS-DAPの設定を開くと・・・

CMSIS-DAPのパケットアナライザのようなものができました。

最低限の機能を実装しただけですが、MDK-ARMのデバッガ設定画面の中のCMSIS-DAPの設定で、このように「RX-CMSIS-DAP」という名前のアダプタが検出されました。

0x0BC11477と、IDCODEが読み出せています。

次は、デバッグができるように、CMSIS-DAPの残りの機能を作っていきたいと思います。

さて、CMSIS-DAPというと、mbedやNXPさんの評価ボードで動作させることが多いと思うのですが、それらはNXPさんのアプリケーションノートAN11321を参考にして作られています。AN11321をビルドするには、MDK-ARMのProfessional版が必要になりますが、Professional版はとても高価です。また、AN11321はライセンス的にも自由にできないようです。

そういうわけで、RXマイコンを使ってゼロからフルスクラッチでCMSIS-DAPのプロトコルを実装することにしました。もちろん、AN11321のコードは一切見ずにやっています。

RXマイコンからCoreSightにSWDでアクセス

RXマイコンを使ってCMSIS-DAPを実現しようと考えています。

手始めに、GR-SAKURAからSWDの信号を出して、DAPの中にあるレジスタを読んでみました。ARMのマイコンボードはSTMicroのSTM32F3 Discoveryを使いました。

ARMのCoreSightアーキテクチャでは、DAPといって、デバッガからJTAGまたはSWDでアクセスするインタフェースが規格化されています。DAPは、デバッガから接続される外側のデバッグポート(DP)と、SoCの内側の様々なコンポーネントに接続するアクセスポート(AP)で構成されています。

SWDの規格は、このDAPにアクセスするために最適化されたパケットベースのプロトコルになっています。

RXマイコンから、JTAG To SWDのシーケンスと、RegisterReadのプロトコルを発行してみました。すると、

このように2BA01477という、DPのIDCODEが読めました。

IDCODE以外のレジスタが読めない理由はまだ分かりません。これから調べていきます。

ADCボードのFFT表示と初歩のディジタルフィルタ

ExcelでADCからのキャプチャデータを取得し、解析するVBAマクロを開発中です。

こんなデータをFFTすると・・

こういう風に表示されるわけです。

上の波形は、入力にリード線をつなぎ、リード線の先にポテンショメータをつないでいます。アンチエイリアシングフィルタが壊れている（コンデンサがはんだの熱で溶けて容量が減っている）ため、ノイズが多目に出ています。

AD変換器から正弦波を出して、それをキャプチャしてFFTしてみると、

このようにノイズやら高調波やらいっぱい見えます。DACは1MHz動作なので、相当カクカクしているのです。だから仕方がありません。

XorShiftという乱数発生回路を使って、DACからホワイトノイズを出して、それをADCでキャプチャしてみました。

このように周波数が上がるにつれて伝達関数が下がっていく特性が見えます。ただ、これがDAC-ADC系の生の特性というわけではないと思います。

今回開発しているADC装置の目的として、ディジタルフィルタをいろいろ実験してみたいものがあります。ADCからのデータをFPGAで受けているので、USBに渡す前にいろいろ計算できます。

計測と同時に元の波形と、１つ遅延、２つ遅延、３つ遅延を足し合わせて４で割った波形を計算させてみました。つまり、

(1+Z^-1+Z^-2+Z^-3)/4

です。すると、

ちゃんと、ノッチの効いた特性になりました。

なぜそうなるかというと、サンプリング周波数fsとすると、Z=2jωf/fsです。

fs/4の周波数においては、Z^-1=j、Z^-2=-1、Z^-3=-jとなります。

だから、(1+Z^-1+Z^-2+Z^-3)/4=0になるわけです。複素平面で考えればわかりやすいですね。4つの点を足し合わせると0になる。だから、fs/4で伝達関数はゼロになります。

たとえば、fs/8だと、こうなります。

Excelの図形描画で矢印を描いてベクトルを足し合わせて求めていますが、偏角は67.5°のところになると思います。ゲインは0.6くらいでしょうか。

こういう実験を生のデータでやりたくて18bit ADC＋FPGAの装置を作っているのです。

以下、様々な簡単なフィルタを試してみました。

・フィルタなしと、(1+Z^-1)/2

単純に1個前と足し合わせたものです。高域での減衰が見えますが、だらしない特性です。

・フィルタなしと、(1+Z^-2)/2

ちゃんとfs/4のノッチが見えています。

・フィルタなしと、(1+Z^-3)/2

fs/6=333kHzのところにノッチができました。

・フィルタなしと、(1+z^-1+Z^-2)/4

666kHzのところにあるようです。

当たり前の結果ですが、自分で作った回路で、シミュレーションではなく実機で、こういう理論通りの結果が出るとなかなか面白いものです。

スタンドアローンなJTAG検査装置

今年の目玉となる新製品として、電池で動作可能なスタンドアローンなJTAG検査装置というのを計画しています。

ルネサスRXマイコンを使ってそのプロトタイプ１号を作っています。

上の写真の左側のボードが、JTAGのホストコントローラとなるRX62Nボードで、右側のボードはターゲットとなるSpartan-6ボードです。

このRX62Nの中にMITOUJTAGのライブラリを移植しようとしています。

まずハマったのが、BSDLファイルの読み込みです。RX62Nマイコンには64kBしか内蔵メモリがありません。BSDLファイルを読み込んで解析するにあたって、この容量じゃ足りないのです。

たとえば、1000個のピンがあるBGAならば、バウンダリスキャンレジスタは3000個あります。レジスタ1個あたり20バイトしか使えません。これじゃちょっと無理。BSDLファイルの読み込みすらできません。

そういうわけですので、やはりRXマイコンのほかにSDRAMが必要です。RX62Nの外付けSDRAMをイネーブルにして動作させたところちゃんと動作するようになりました。

RX62N基板上の青いボタンを押すと、DETECTと表示されて、

このとおり、１個のデバイスが認識されました。

見つかったデバイスのIDCODEと部品名が表示されています。

RXマイコンでJTAGライブラリがちゃんと動いたようです。

アナデバのAD7986評価ボードがDigikeyから届いた

先日、AD7986の値ジャンプの原因がどうしてもわからなかったので、アナデバの純正評価ボード「EVAL-AD7986EBZ-ND」をDigikeyに注文してしまいました。

1月3日(金)に注文して、1月6日(月)に届くとはさすがDigikey。アメリカ人はお正月をあまり休まないのかもしれませんね。

しかし、注文した直後に値ジャンプの問題が解決してしまったというのもよくありそうな話ではあります。

そのため、この評価ボードを使う機会はなくなってしまったのですが、せっかくなので眺めることにします。

まず外観。

うっ！ まさか12Vと±5Vを外から入れなければならないのか？コネクタもSMAではなさそう。もっとスリムなやつです。

これがメインとなるAD変換IC。

C80というのが極めて重要なコンデンサ。このコンデンサにはリファレンス電圧の4.096Vが蓄えられます。

昨今のA/D変換器は、サンプリングするときにアナログ入力から電荷を強烈に引き抜くため過渡応答に耐えられるように、アナログ入力にはコンデンサを入れなければなりませんが、それはリファレンス入力にも同様にいえることです。このC80の容量が小さかったり特性が悪いと激しく間違った変換をしてくれます。

驚いたのが、このボードにはALTERAのCyclone2とEPCSも乗っているということ。

これがCyclone2ではなくSpartan-3だったらすぐに試せたのですが残念。

GNDの引き回しとか心行くまでパターンを眺めて、参考にできるところは参考にしたいと思います。

ADCの値ジャンプが解決できた

ようやくADCの値ジャンプが解決でき、18bitのADCの性能を堪能できるようになってきました。

まず、0Vを横切る正弦波

常に0Vを下回る正弦波

何が原因だったかというと、ADCに入力される差動信号のコモン電圧でした。

ほとんどの高性能ADCは差動信号で入力を与えることになっていて、この２つの差動信号の平均値をコモン電圧というのですが、AD7986のデータシートでは何Vが良いと明確に定められていなかったので、軽い気持ちでREFINに使っている1.2Vを入れていました。

VIN₊が1.2V+xで、VIN_-が1.2V-xで振れることになっていたわけですが、なぜかVIN₊ - VIN_-が-0.01Vくらいのところでは、うまく動かなかったのです。

別にVIN₊やVIN_-が0Vを下回ったりしたわけではないのですが不思議です。

このコモン電圧を2.5Vにしたらうまくいったというわけです。

もはや最初の回路が原型をとどめないほどに修正されてしまいました。

実はこれ、両面基板なのです。18bitのADCでもパターンに十分気を使って設計したら両面基板でできてしまいました。

ポテンショメータなどをつないで固定電圧を与えたときのキャプチャした波形。

2つあるチャンネルのうちCH0(青)のほうがバラツキが少ないのが謎です。

標準偏差を取ってみると、CH0(青)が49uV（≒1.5LSB）、CH1(赤)が100uVでした。

CH0のほうでヒストグラムを取ってみると、

LSB4個分にほとんどが収まっていることがわかります。これはAD7986のデータシートと比較しても、遜色ないレベルです。

考えてみれば、VCM=1.2Vだと、V-=0、V+=2.4VとV+=0、V-=2.4Vが入力できる電圧の最大値になるわけですから、フルスケールまで使えないですよね？

VCMの値は本来は任意のはずなのですが、ADCによっては予期しない動作をするのかもしれません。このAD7986では、一番良いのはVCM=1/2VREFなのでしょう。

なぜ1.2Vで作ってしまったかというと、以前Texas Instrumentsの石で設計した24bit ADC(オーディオ用の安いADCではなく計測用の高価なもの)がそういう設定にしていたからだと思います。思い込みやうまくいった経験というのは怖いものです。

AD7986で値がジャンプしてしまう

AD7986を使った18bit ADCの開発を鋭意進めています。

最高速度2Mbit/sでのサンプリングや、サンプリング値のばらつき(標準偏差)を65μV程度に収めるという課題はクリアできるようになってきました。

しかし、どうしても解決できていない問題が1つあります。

0Vよりちょっと下のあたりで値がジャンプするのです。正弦波を入れてみると一目瞭然です。

拡大してみるとだいたい1000くらいの値をジャンプしていますから、30mVくらいです。

正弦波をやめ、このあたりの固定電圧を入力してみてみると・・・

値が激しく行き来しているのですが、この中間の値というものが出てきません。つまり、-15mVの電圧がうまくサンプリングできないのではなく、マイナス方向にバイアスがかかってしまって、この間が飛んでしまっているのではないかと思われます。

いろいろ原因究明の努力はしてみました。

• オシロでADCの入力を見ればこんな波形にはなっていないから、AD変換の際に何かを間違ってしまっているわけです。
• プリアンプがレールツーレールなので、上と下が切り替わるところで変なことが起きているのでは・・・と思って、プリアンプを外してみたけど状況は同じでした。
• また、0Vよりちょっと下(111111xxxxxxxxxxxx)のところで多数ビットが同時に切り替わることによる電源の問題かとも思ったのですが、そうでもなさそうです。
• 2つのCHで同じように起きているので、たまたまAD7986が壊れていたということでもなさそう。

どうやらリファレンス電圧と関係していることがわかってきました。REFという端子の電圧を標準ではない電圧にしたりすると、この値ジャンプが消えて滑らかになります。

あと、考えられることといえば、AINのコモンモード電圧の範囲に制約があるとか、かもしれません。

引き続き調査してみます。

WordPressを試してみた結果・・・

特電のWebサイトをリニューアルしようと思って、この年末年始の間にWordPressの本を読み、実際に触ってみました。

とりあえず、現状のトップページをそのまま貼り付けてみた結果です。

レイアウトが崩れているのは、まぁ、大した問題ではない。

それで会社概要のページとか、製品情報とか、仮に移植してみました。

トップ - 会社紹介 + 沿革
       |          - 出版物
       |          - 代表者経歴
       |          - ・・・
       |
       + 製品情報 + Artix7   + 機能と仕様
       |          |          - ダウンロード
       |          |
       |          - Spartan6 + ・・・
       |

とりあえずこんな感じの構造にしてみようと思いました。

会社紹介のページはhttp://・・・/company/

製品情報のページはhttp://・・・/products/

すると、会社紹介の下にある沿革のページはhttp://・・・/company/history/というところに入ります。

製品情報の下にあるArtix-7のページはhttp://・・・/products/art7/ になりますが、現在のWebサイトの構造ではhttp://・・・/art7/にあるので、URLが変わってしまうことになります。

どうやら、ナビゲーションの階層とURLのディレクトリが1:1に対応してしまっているので、現在のWebサイトの構造をそのまま移行することができないことがわかりました。

それから、URLの/company/とかが嫌なので、/company.htmlにしたいと思って、いろいろプラグインを試しました。

まずは定番ともいえる.html on PAGESです。これを入れると確かにパーマリンクに.htmlを入れることができるようになります。

階層の下になっている場合は、

このようにhttp://・・・/product/art7/index.html になるように設定しました。

しかし、index.htmlを省略して、http://・・・/product/art7/ではアクセスできません。http://・・・/product/art7.html/というURLになったりします。

このあたりのルールはよくわかりません（使うプラグインによる？）が、/art7.html/ というディレクトリになったりするので、あまり良いことではありません。

それに、ページごとに.phpにしたり.htmにしたり、と変えることはできず、全部一括で変わってしまうようです。

いろいろ実験して分かったことでは、WordPressのURLは、そのURLの場所に何かのファイルがあるわけではなく、index.php?p=の後ろに付いている文字列を適当な手段で解釈して見せているようなので、フェイクなわけです。

ページの階層構造とURLが関連付けられて固定してしまっているということと、パーマリンクのファイル名が自由にならない、ということでWordPressを使うのは見送ることにします。（プラグインによってはできるのかもしれませんが・・）

そういうわけで、特電Webサイトのリニューアル用として次はBootStrapを勉強することにしました。

あけましておめでとうございます

やり残したことがいっぱいあったけど、2014年になってしまいました。

今年の抱負は、

• 特電のホームページ更新して現代風にする
• 人（スタッフ）を増やす
• 自社のIPコア(PCIe、SATA、USB3)をAXIに対応させる
• 汎用のFPGA評価ボードはもう作らない
• JTAGをより多くの人に使ってもらえるような新製品を作る

です。

そろそろ本気出そうと思います。