投稿

投稿日:

TrueCryptでディスクを暗号化 （１）インストール編

雑多なデータはやはりWindows上にあることが多いので、Windowsから暗号化できないと面倒である。仕方がないので、Windows側にTrueCrypｔを導入して、暗号化パーティションを作成することにした。TrueCrypt（http://www.truecrypt.org/）は「オープンソースの暗号化された仮想ディスクを作成・利用するソフトウェア」（Wikipediaによる）である。詳しくは、Wikipediaの方を参照されたい。

単純にWindowsであればOSの暗号化機能でも良さそうな気もするが、ディスク自体は外付けであり、過去にOSの再インストール時に読めなくなったことがある（このときは他にバックアップがあって助かった）ので、やっぱり外だしのツールのほうが安心かも、ということである。

そんなこんなで、まずダウンロードする。TrueCryptのダウンロードのページにいくと、ダウンロードのリンクとPGP signatureのリンクがある。ダウンロードしたファイルの検証方法は PGP Signature のリンクを押すと表示されるが、Windows版の場合は電子署名を確認してもＯＫだよ、ということみたいである。よって、ダウンロードしたファイルをエクスプローラで右クリックして、プロパティを表示して確認していく。

プロパティを開いたところ。デジタル署名のタブをクリックする。

 

すでに選んであるが、TrueCrypt Fundation の署名を選択して「詳細」を押す

 

ここで「このデジタル署名は問題ありません」と出れば、OKみたいである。

引き続き、実行形式のファイルをダブルクリックして、インストールを行う。

お約束のライセンス確認である。中身を読んでチェックを入れて「Accept」を押す。

 

インストールするのか、展開だけなのかを選ぶ。
展開だけを行う場合は、「システムドライブの暗号化を行う場合」と
「ポータブルモードで動作させる場合」のようである。
展開したファイルの実行形式をダブルクリックすると
ポータブルモードで動作するらしい。

 

セットアップオプションを選ぶ。標準のままにした。

 

インストールの過程が表示される。
完了すると、完了のメッセージが出る。

 

「初めて使うんだったら、チュートリアルを読むことをお勧めするよ、
チュートリアル見たい？」ということなので、「はい」を押す。

 

「はい」を押すと、TrueCryptのチュートリアルのページが開く

ということで、インストール自体はいたってシンプル。あっさり終わりました。

投稿日:

Ubuntuでディレクトリを暗号化

この時期になると、年賀状などを書かなくてはならないだが、年賀状は個人情報の塊でもある。

これまではNAS（玄箱PRO＋Debian）に保管していたが、結局無防備な状態であった。調べてみると、Ｕｂｕｎｔｕでも暗号化ディレクトリが作れるということなので、試してみることにした。
  1. Cryptkeeperのインストール
    Cryptkeeperは、暗号化ディレクトリを生成する encfs のGUIとのこと。
    例によって、Synapticでサクッとcryptkeeperを検索して、インストールする。
  2. 適当にディレクトリを２つ作る。１つは暗号化されたディレクトリの実体（データ格納場所）、もう1つは暗号化されないデータを見せるマウントポイント。
    ここでは、/home/encryptedが暗号化されたデータの格納場所、/home/enc-mtptがマウントポイントとした。それぞれ、chown コマンドで group/owner を自分に変えてある。
  3. 以下の方法で暗号化されたディレクトリを実体にマウントする。 
    $ encfs /home/encrypted /home/enc-mtpt
新しい暗号化ボリュームを作成します。
Please choose from one of the following options:
enter "x" for expert configuration mode,
enter "p" for pre-configured paranoia mode,
anything else, or an empty line will select standard mode.
>　（ただリターンキーを押す）

Standard configuration selected.

設定が完了しました。以下のプロパティのファイルシステムが
作成されます:
ファイルシステム暗号アルゴリズム: "ssl/aes", バージョン 2:2:1
Filename encoding: "nameio/block", version 3:0:1
鍵サイズ: 192 ビット
Block Size: 1024 bytes
Each file contains 8 byte header with unique IV data.
Filenames encoded using IV chaining mode.
File holes passed through to ciphertext.

Now you will need to enter a password for your filesystem.
You will need to remember this password, as there is absolutely
no recovery mechanism. However, the password can be changed
later using encfsctl.

新しい Encfs パスワード:
Encfs パスワードの確認: 
$ 

    これで /home/enc-mtpt にアクセスすると、暗号化されたデータにアクセスできた。

  4. アンマウントは 
    $ fusermount -u enc-mtpt

    でアンマウントできた。

・・・が、ここで問題。EncFSで mount したディレクトリは、どうやら共有できない模様。Windowsからアクセスするディレクトリにするつもりだったので、ガックリである・・・。

投稿日:

PIC24USBでUSBシリアルに挑戦 （４）送信バッファ組込み

アナライザとしてPIC24USBを使う場合、大量のデータがPIC24USBからPCに上がってくることになるが、Microchip社が提供するUSB Frameworkでは送信バッファがそのままUSBコントローラに渡されるため、送信データは毎回ブロッキングされてしまう。これではちょっと都合が悪いので、ソフトウェアのバッファを噛ませることにした。
１ＫＢのソフトバッファをかませたうえでのＵＳＢ－ＣＤＣの通信速度は約200～250Kbpsといったところのようである。PIC24USBからSOF割り込みの回数カウント値とデータ表示回数をカウントした値をｓｐｒｉｎｔｆで表示したものを、PC側でTeraTermProでひたすら表示しているだけである。
XBeeとAVRの間は9600bpsなので、上り下りで約20Kbpsである。凝った解釈をしなければなんとか表示できると思うのだが・・・。

投稿日:

VMware上にUbuntu10.04LTSとXubuntu10.10をインストール

Chromeブラウザのアルファ版を試してみたくなった。しかし、普段の環境にインストールすると後で往々にしてハマることが多いので、VMware上にインストールすることにした。

まずは、Ubuntu10.04LTSをインストール。インストールISOイメージを持ってくる（ダウンロードする）間に、仮想マシンを debian32bit で生成。仮想CDROMにインストールISOイメージをマウントして、仮想マシンを起動。インストールISOイメージを仮想ディスクとは別のHDDにいれていることと、仮想ディスクへのライトキャッシュを許可してあることからか、インストールはあっという間に終わってしまう。次に、アップデートマネージャを起動すると、数百MB分のアップデートが要るということで、かなりの時間を要してしまった。
VMware toolsのインストールも、共有ディスクを生成していないことでエラーが出るのと、vmxネットワークドライバのコンパイルでエラーになるが、操作性とグラフィックスの改善ができたのでよしとする。（しかし、実際には、VMwareについているVMware toolsよりも、ここで紹介されているopen-vm-toolsの方が良いのかもしれない。）
それはさておき、Ubuntuのインストール中に見つけた、軽量版のXubuntuが気になってしまった。（Ubuntuでも十分に軽いのだが）
同様にインストールISOイメージを持ってくる（ダウンロードする）間に、仮想マシンを debian32bit で生成。仮想CDROMにインストールISOイメージをマウントして、仮想マシンを起動。インストールISOイメージを仮想ディスクとは別のHDDにいれていることと、仮想ディスクへのライトキャッシュを許可してあることからか、インストールはあっという間に終わってしまう。こちらのインストール時は繁体字（中国語）まじりの日本語になっているが、インストール後の日本語の文字はＵｂｕｎｔｕ10.04と大差は無い。（ただし、メニュー自体は一部英語のままになっている）
次のアップデートもUbuntuと同様だったが、その次のVMware toolsのインストールで嵌ってしまった。結局、調べていくと、VMwareについているVMware toolsではなく、ここで紹介されているopen-vm-toolsを

$ sudo apt-get install open-vms-tools

でサクッとインストールするだけでよいことがわかった。
次にＣｈｒｏｍｅブラウザをインストールした。デスクトップやランチャメニューに追加するには、Ｕｂｕｎｔｕの場合にはマウス操作でできたのだが、Xubuntuはそうはいかず、ランチャを一つずつ追加するしかなさそうである。
機能的にはやや劣るものの、ＸｕｂｕｎｔｕはUbuntuと比べても非常に軽い。そして概ね日本語化ができていて、フォントも（インストーラを除けば）Ubuntuのものと同じ綺麗なものが使われている。・・・と思ったら、XubuntuでChromeを使うとUIと異なるちょっと貧相なフォントが使われてしまうのが残念。Chromeの設定自体は同じようなので不思議なのだが・・・。


12/23追伸
Chromeのアルファ版はWindows版しかないのであった。がっくり。

投稿日:

PIC24USBでUSBシリアルに挑戦 （３）ソースを改造してみる

USB Frameworkは無事に動作したのだが、ループの中で常にCDCTxService()を呼び出し続けなければならない構造になっていて、改造しにくい。できればそんなものは割り込みなどで監視してほしいものである。

なので、もう少しコードを眺めてみることにした。そこでわかったこと、試してみたことは、

  • usb_config.h の中に、
    #define USB_INTERRUPTがあり、PIC24FJ256GB106ではUSBは割り込みで動作している。
  • main.c の最後に、BOOL USER_USB_CALLBACK_EVENT_HANDLER()という関数があり、そこでUSB割り込み発生後のユーザー用のハンドラを記述できる。
    EVENT_TRANSFERがパケット転送後、EVENT_TRANSFER_TERMINATEDがパケット転送中断後のイベントのようである。Start of Frame は EVENT_SOF 。
  • 問題の面倒くさい処理 CDCTxService()は、usb_function_cdc.c の最後にある。
    細かくは見ていないが、USBHandleBusy(CDCDataInHandle)を確認し、BUSYでなければ送信データをエンドポイントのサイズに分割しながらメモリ中にコピーして、USBTxOnePacket()を呼び出している。このUSBTxOnePacket()は、usb_device.h の中で
    #define USBTxOnePacket(ep,data,len) USBTransferOnePacket(ep,IN_TO_HOST,data,len)
    となっている。
  • putUSBUART()は、mUSBUSARTTxRam()を呼び出している。その際、cdc_trf_stateがCDC_TX_READYかどうかをチェックしていて、CDC_TX_READYでない場合には、何もせずに帰ってくる。即ち、送信しようとしたデータは捨てられることになるが、事前にUSBUSARTIsTxTrfReady()をチェックしていれば、そのようなことは起きないはず。
  • cdc_trf_stateはエンドポイントの初期化でCDC_TX_READYにセット、CDC_TX_COMPLETINGの状態でCDCTxService()が呼ばれるとCDC_TX_READYにセット、mUSBUSARTTxRam()などを呼ばれるとCDC_TX_BUSYにセットされるようである。整理すると、「CDC_TX_READY」→「（送信データセットで）CDC_TX_BUSY」→「（データの終わりのZeroLengthPacket送信で）CDC_TX_ZLP（省略あり）」→「CDC_TX_COMPLETING」→「CDC_TX_READY」となるようである。
  • mUSBUSARTTxRam()は渡されたデータのポインタ（アドレス）、長さなどをモジュール内のグローバル宣言の構造体や変数などにコピーするだけ。実際の転送処理はCDCTxService()に任される形になる。

つまり、putUSBUART()などから送信データをポインタ渡しされたら、そのポインタをコピーしておき、CDCTxService()が呼ばれる度に状態をチェックして、送信データをエンドポイントのサイズに分割しながらコピー、送信する、という動作のようである。

これらのことから、以下のようにすれば概ね上手く行くのではないかと考えた。

  • 送信データをセットする前に、USBUSARTIsTxTrfReady()をチェックして、CDCTxService()が抱えている未送信データの有無をチェックする。（CDC_TX_READYかチェックする）
  • 送信データを準備し、putUSBUART()でそのポインタを教えてやる
  • その直後に、一度だけCDCTxService()を呼び出し、送信を開始する。CDCTxService()はデータをエンドポイントのサイズに切り出して最初のパケットを送信する。
  • USER_USB_CALLBACK_EVENT_HANDLER()の中のEVENT_TRANSFERのところに、CDCTxService()を追加して、１パケット送信ごとに自動的にCDCTxService()が呼ばれるようにする。割り込み処理内なのでネストしてしまうリスクがあるが、USBUSARTIsTxTrfReady()を実行してから送信処理をしていれば大丈夫なはず・・・。

ということで、実際に試してみた。確認のため、usb_config.hの

#define CDC_DATA_OUT_EP_SIZE 64
#define CDC_DATA_IN_EP_SIZE 64
を共に４に変更してみたところ、送信（PCから見ると受信）に関しては問題ないようである。
しかし、逆方向はファイルを流し込むと送受信を同時に行った際にデータを取りこぼしてしまう。もう少し調べなければ・・・。
投稿日:

PIC24USBでUSBシリアルに挑戦 （１）準備編

ずっと前に買ったオプティマイズのPIC24USBを引っ張り出してきた。
このボードに搭載されているPIC24FJ256GB106にはＵＳＢデバイスインタフェースとシリアルポートが４チャンネルあるので、これらを使ってシリアルラインモニタを作ろうと考えている。シリアルラインモニタを使って、XBeeのプロトコルをモニタする作戦である。

ＵＳＢプロトコルの処理は、Microchip Technology社から提供されているMicrochip Application Librariesの中のUSB Frameworkを使うつもりである。Microchip Application Librariesは、MicrochipのホームページのSoftware Librariesの中からダウンロードできる。

ダウンロードしてインストールすると、Microchip Solutionsというフォルダができるので、その中の「USB Device – CDC – Basic Demo」フォルダの中の、「CDC – Basic Demo – Firmware」フォルダの中の、「USB Device – CDC – Basic Demo – C30.mcw」をダブルクリックすると、MPLABが立ち上がり、プロジェクトが開く。

ここで、「Configure」→「Select Device」でPIC24FJ256GB106を選択し、さらに「Project」→「Package in .zip」を選択すると、ビルドに必要なファイルだけが「USB Device – CDC – Basic Demo – C30.zip」という名称でZIPに圧縮して保存される。これを別のフォルダで展開したものを作業のベースとすることにした。

試しに、「Project」→「Build All」すると、ちゃんとHEXファイルが生成されることを確認できる。

投稿日:

PIC24USBでUSBシリアルに挑戦 （２）サンプルソースを動かしてみる

まず、回路図を比較してみる。後述の通り、PIC24FJ256GB106を使うボードのターゲットはPIC24F Starter Kitである。こいつの回路図はMicrochip社のWebサイトで入手できた。PIC２４USBとの主な差分は、

  • Starter Kitのクロックは、PIC18F67J5（デバッグ用のPICか？こいつのクリスタルは12MHzとなっている。）から供給されているので、周波数がよくわからない。一方で、PIC24USBのクリスタルは１６MHz。
  • Starter Kitには32kHzのクリスタルがついている。
  • Starter KitはPGEC2/PGED2にICSP端子がつながるようになっているが、PIC24USBはPGEC1/PGED1にICSP端子がつながるようになっている。

であった。さらにソースを一通り眺めてみた。

  • 「main.c」からは「HardwareProfile.h」がインクルードされている。
  • 「HardwareProfile.h」を見ると、PIC24FJ256GB106を選択すると「Hardware Profile – PIC24F Starter Kit.h」がインクルードされることがわかる。
  • 「Hardware Profile – PIC24F Starter Kit.h」をみると、９１行目で「PIC24F_STARTER_KIT」がdefineされる。
  • 再び「main.c」を見ると、213行目でCONFIGビットの設定が記述されていることがわかる。
    _CONFIG1( JTAGEN_OFF & GCP_OFF & GWRP_OFF & COE_OFF & FWDTEN_OFF & ICS_PGx2)
    _CONFIG2( 0xF7FF & IESO_OFF & FCKSM_CSDCMD & OSCIOFNC_ON & POSCMOD_HS & FNOSC_PRIPLL & PLLDIV_DIV3 & IOL1WAY_ON)
    CONFIG1は、JTAG禁止、コードプロテクトOFF、ライトプロテクトOFF、Clip-on Emulatorイネーブル、ウォッチドッグタイマOFF、さらに「ICS_PGx2」でPGEC2/PGED2とICSP端子をシェアする設定になっているので、ここを「ICS_PGx1」に変更する必要がありそう。
  • CＯＮＦＩＧ２はTwo Speed Start UpがOFF、Clock Switch & Monitorが両方OFF、OSCO端子機能はRC15、HS oscillator、Primary oscillarot w/ PLL、RPレジスタへの書込み制限無しで、さらに「PLLDIV_DIV3」はオシレータの周波数が12MHzの時の設定だから、ここは「PLLDIV_DIV4」へ変更が必要と思われる。
  • 再び「Hardware Profile – PIC24F Starter Kit.h」をみると、95行めから１２２行目でデモボード上のLEDやスイッチに関する入出力の記述がある。

ということがわかった。

そこで、「HardwareProfile – PIC24F Starter Kit.h」の９４行めから１２３行めのLEDとSWのマクロ定義の中身を適当に修正する。ポート読出し用は０か１固定、ポート書込み用は中身を空にすることにした。この状態だと、「main.c」のProcessIO()関数の中身によれば、入力されたASCIIコードに１を足したものをエコーする（つまり、AをタイプするとBを表示する）プログラムとなるようだ。

修正してコンパイルしたところ問題なくコンパイルが通ることが確認できた。

これをPICkit2で書き込んでリセット解除すると、新しいCDCクラスのデバイスとして認識され、「USB Device – CDC – Basic Demo」フォルダの下の「inf」フォルダ内のｉｎｆファイルをインストールすると、ＣＯＭ１２ポートが生成された。TeraTermでＣＯＭ１２を開いて、キーを入力すると、期待通りタイプしたキーのASCIIコードに１を足した文字が表示された。

投稿日:

ATmegaとのシリアル通信～AVRLibのtimerのテスト

同様に、AVRlibのタイマーのテストを行いました。修正箇所は、

  1. プロジェクトディレクトリの global.h のCPU動作周波数を８ＭＨｚに修正
  2. プロジェクトディレクトリの Makefile のROM書込みに関する部分を追加変更前は、 
    ########### change this lines according to your project ##################
#put the name of the target mcu here (at90s8515, at90s8535, attiny22, atmega603 etc.)
# MCU = atmega8515
MCU = atmega163
# MCU = atmega323
# MCU = atmega161
# MCU = atmega128

    変更後は、

    ########### change this lines according to your project ##################
#put the name of the target mcu here (at90s8515, at90s8535, attiny22, atmega603 etc.)
# MCU = atmega8515
# MCU = atmega163
# MCU = atmega323
# MCU = atmega161
# MCU = atmega128
MCU = atmega88

# FUSE BIT for ATMEGA88/168(default is E=0x01/H=0xDF/L=0x62)
EFUSE = 0x01
HFUSE = 0xDF
# LHUSE = 0x62
LHUSE = 0xe2

# WRITER parameter
WRITER = -c avrispmkII -P usb
WRITER_MCU = m88

#directory of AVRLib
AVRLIB = /（適切に・・・）/avrlib
  3. 同じく Makefile のソースファイルに関する部分を変更
    変更前は、

    #put your C sourcefiles here
# Here you must list any C source files which are used by your target file.
# They will be compiled in the order you list them, so it's probably best
# to list $(TRG).c, your top-level target file, last.

SRC = $(AVRLIB)/buffer.c $(AVRLIB)/uart.c $(AVRLIB)/rprintf.c $(AVRLIB)/timer.c $(TRG).c

    変更後は、

    # put your C sourcefiles here
# Here you must list any C source files which are used by your target file.
# They will be compiled in the order you list them, so it's probably best
# to list $(TRG).c, your top-level target file, last.

SRC = $(AVRLIB)/buffer.c $(AVRLIB)/uart.c $(AVRLIB)/rprintf.c $(AVRLIB)/timerx8.c $(TRG).c
  4. 同じく Makefile の依存関係に関する部分を変更
    変更前は、

    timer.o : timer.c timer.h global.h

    変更後は、

    timer.o : timerx8.c timerx8.h global.h

結局、タイマー周りの修正が要る、ってことですね。
これで一応シリアルの表示上は動いている（ポーズもそれっぽく掛かっている）気がするのですが、PWM出力の方は出ていないようです。
この辺はまた今度にすることにします。

投稿日:

ATmegaとのシリアル通信～AVRLibの導入

ATMEGA88を使うことにしたのですが、シリアル制御を一から作るのも面倒くさい、ということで、ちょっと古いようですが、AVRLibを試してみることにしました。

まず、ZIPファイルをダウンロードしてきて、展開します。
環境変数AVRLIBに avrlib のディレクトリ位置を（avrlibの名前を）設定して、rprintf のサンプルディレクトリに移動。
makeすると、makeはされるのですが、ATmega163用にmakeされてしまいます。
今回のターゲットはATmega88なので修正を試みます。

現状の修正箇所は、

  1. サンプルプログラムの makefile の MCU の定義
    「MCU=atmega88」に書き直します。
  2. サンプルプログラムの makefile の AVRLIB の設定
    環境変数ではなく、ここで記述してみます。（未検証）
    AVRLIB = /（ほげほげ）/AVR-PROJ/avrlib
  3. サンプルプログラムの makefile の SRC の設定
    timer.c を使うとレジスタ定義が異なるので、timerx8.c に変更
  4. サンプルプログラムの makefile の終わりの方の依存関係(dependencies)の修正
    「timer.o ： timer.c timer.h global.h」を「timer.o : timerx8.c timerx8.h global.h」に修正
  5. global.h の F_CPUの値の修正
    現状、7372800 が選択されているが、内蔵８MHzを使用するので、8000000に修正
    サンプルプログラムのプロジェクトディレクトリにも global.h がいるので、そちらも直す。
  6. 最近のGCCならCOFファイルはなくても大丈夫だったような気がするので、avrproj_make の「all :」の依存ファイルから $(TRG).cof を削除
  7. どうせなら書込みまでやってしまいたいので、avrproj_make の最後に

    ###### BLOCK 12) make instruction to delete created files ######prog: all
    avrdude $(WRITER) -p $(WRITER_MCU) -F -U flash:w:$(TRG).hex -U eeprom:w:$(TRG).eep -U efuse:w:$(EFUSE):m -U hfuse:w:$(HFUSE):m -U lfuse:w:$(LFUSE):m

    を追加。（このままだと拡張ヒューズビット無しのCPUに書くとき困るけど、とりあえずそのままで・・・）

  8. 同じくサンプルのmakefileに

    # FUSE BIT for ATMEGA88/168(default is E=0x01/H=0xDF/L=0x62)
    EFUSE = 0x01
    HFUSE = 0xDF
    # LHUSE = 0x62
    LHUSE = 0xe2# WRITER parameter
    WRITER = -c avrispmkII -P usb
    WRITER_MCU = m88

    を追加

とすることで、rprintfのテストを実施が通るようになりました。（サンプルプログラムの方の global.h を修正し忘れていて、通信速度がおかしく、しばらく悩んでしまいました・・・）

無事にシリアル通信が通るようになりました！

 

投稿日:

秋月ZigBeeモジュールの先にAVRをつなぐ

XBeeによって、リモートUARTの環境を構築、ループバック動作を確認できたので、その先のコントローラとして、AVRをつないでみることにしました。AVRにしたのは、Linux環境で閉じた開発ができるからということと、手持ちに ATmega88 が何個か転がっていた（PIC24FJ64も転がっていますが・・・）からです。

Zigbee子機をもう少し大きめのブレッドボードに移植し、ATmega88と同居させました。
・・・といっても、写真では見えないですね。書込みは AVRISPmkII で行っています。
ISP用の端子６本は写真右側に写っているブレッドボード用の自作アダプタを介してその下のATmega88につながっています。

その他、シリアル通信用の端子をXBeeとの間で接続しました。

このATmega88に対してシリアルでコマンド／ステータス通信をさせるようにしていきます。