InfoPath入門

 

何故か、ふと前のブログ消そうと思い立ちました。

どーせ誰も見てないし、結局大したこと書いてないし・・・。
んでもよく見たら１ページだけ異様なアクセス数のページがあったんです。
他のページのなんと80倍ｗ
（まともな記事がそれ一つで終わってたっていう理由もありますが）

ってことで、そのページだけこっちにコピーです。

 

ここから ----------

実は今お仕事で使用している議事録がとーっても見づらくて、
なんとか使いやすくできないものか、できれば他と連携とれないものか、
なんて思ってたんです。

そこで見つけたのがInfoPath。

・・・Word等はよく使うのに、今まで存在すら気付きませんでした。

とりあえずてきとーに触ってみてー・・・
なんて思ってたらちょっとややこしそうだったので、
調べてみたんです。

そしたら、
InfoPath – トレーニング
MicroSoftがトレーニング用のページを用意してたんですね。

これも初めて知りました・・・。

こんな便利そうなツールが存在してたんですね。
私が無知すぎるだけかぁ？？

便利そうといっても、あんましよく分かってないので、
一先ず利点を他人に説明できるくらいまで頑張らないと！

ここまで ----------

 

2009-06-13の記事です。

半年くらい経ちました。
何にも進んでません（汗）

あああああああ orz

Kernelブートイメージファイルの名前と意味 その２

 

その１でブートイメージファイルを沢山書きましたが、
宿題が結構残っていましたので消化しました。

 

まずはxipImage

xipImage
XIP(eXecute in Place)形式というやつで、
RAMへ展開せずに、極力そのまま使えるようにしたものらしいです。
NORフラッシュ等に余裕があるなら使えそうな形ですね。
今度試してみよう。

menuconfigで設定する人は、
”Boot options –> Kernel Execute-In-Place from ROM”にチェックを入れて、
”Boot options –> XIP Kernel Physical Location”にアドレスをいれる。

.config直接いぢる人は、
”CONFIG_XIP_KERNEL”をyにして、
”CONFIG_XIP_PHYS_ADDR”にアドレスを入れる。

んで、お仕事でも使用しているボードでコッソリと試して・・・

試し・・・て・・・・

動かないorz

どうやら、NORがByteアクセス出来ない為に、ちゃんと動かんのです。
まさか実験の為だけにH/W何とかしろなんて言えないので断念です。

 

お次はrImage

rImage
ramcopy形式とMakefileには書いてありました。
無圧縮の形で、とにかく仮想空間への展開だけしてるのでしょうか？
じつはちょっと動きが分からないので、宿題デス。
# 実際ブートローダからjumpしたら動かなかｔｔ

menuconfigで設定する人は、
”Boot options –> Kernel Uncompressed, RAMCOPY”にチェックを入れて、
”Boot options –> RAMCOPY Kernel source address”にアドレスをいれる。

.config直接いぢる人は、
”CONFIG_RAMCOPY_KERNEL”をyにして、
”CONFIG_RAMCOPY_SOURCE_ADDR”にアドレスを入れる。

こっちは動きました。
ほんとにそのまんま、コピーしてジャンプして動くシンプルな形です。

前回は、一先ずDRAMにイメージを展開して、それをLoadしてた為に、
CONFIG_RAMCOPY_SOURCE_ADDRと展開元アドレスが違ってたから、
うまく動かなかったってところですね。

シンプルなので起動速度は結構早いです。
uImageと比べると300msくらいは早くなった気がします。

 

・・・・msかよ！
って思われるかもしれませんが、今時の組み込みLinuxの起動時間は、
ms単位で縮めなきゃいけない状況なのですよ。

uncompressedなんでもちろん容量は大きくなりますが、
所詮はkernelなんで数Mの範囲ですしいいかな。

うん、起動時間とは逆にNORの容量がどんどん増えてきてるので、
kernelを極限まで小さく！なんてことはしなくても大丈夫になりましたねぇ。

 

ってなわけで、宿題消化！

autocmd

 

色々あって、久々の更新。

おかげでOpenSUSE11.2リリースした瞬間にインストールしたのに、
すっかり下記損ねてしまいました。

後で書くつもりです・・・。

 

さて、前回の宿題です。

autocmdは、”ファイルを開いた”とか”バッファから読み込んだ”とか
イベントに応じて自動実行されるコマンドです。

vim usersが好んで好んでやまない機能なようで、
検索すると色々と便利なコマンドが紹介されています。

バイナリデータを16進数表記する方法は、この記事に載っています。
# 使わせてもらいまーす、感謝です。

詳細な使用方法は、このドキュメントに載っています。

 

・・・・けど、個人的にはあまり必要ないなぁと思ってます。
# vim usersには申し訳ないが

私がviを使用する理由は、
・お手軽に使える
・動作が軽い
・Linuxなら必ず使用できる
てな感じなんです。

ちょこっとした用事や、急いでサクっと作業する際に使うので、
自分でカスタム出来るように勉強しても利点が少ないかなぁ・・・。

ここは少し甘えて、先人たちのリソースをありがたく使わせてもらおうと思います。
よさそーなコマンドがあったら紹介しますネ。

CUIのバイナリエディタ

 

Linuxで私の願いを叶えてくれるバイナリエディタを見つけたのでメモです。

 

Linuxにだって沢山のバイナリエディタが存在します。
KDEならKHexEdit、GNOMEならghexなどなど。

でも、私が知っていたのは全部GUIなんですよね。

組み込み開発なんかしてると、Debug用のUARTくらいしか、
Outputできるものが無いことが多いんです。

だから、viのbinary版みたいなものを探していたんですわ。

vimなら”vi –b”で開けばbinaryモードで開ける！！
なんてhelpには書いてありましたが、開いても化け化けで、
16進数表記じゃないんですもの・・・。

とはいえ、odやhexdumpじゃ見てるだけだし、
bviやhiといったフリーソフトはあるようですが、
できれば基本ソフトでなんとかしたい・・・と思ってたんです。

 

で、調べてみたら・・・

「vimならバイナリデータを16進数表記に変換できます」
ΩΩΩ < ナ、ナンダッテー！？

やり方は、”vi -b”(バイナリモード)で開いた後に、
:%!xxd
と打ち込めば変換できます。

元に戻す場合は、
:%!xxd –r
と打ち込めば戻ります。

xxdは16進数変換をしてくれるLinuxのコマンドです。

:%!は、バッファ全体を次に記述されたコマンドに渡し、
結果を反映させて表示しなおす機能のようです。

つまり、バッファ全体をxxdで変換して反映させるという動きなんですね。
表示方法が変わるのではなく、実際に書き換えちゃってます。

ってことでこのまま保存すると困ったことになりそうですから、
必ず元に戻す必要がありますね！

 

色々な方々が記事にしてましたので、ググってみると幸せになれます。

ちなみに、autocmd使えば楽になるよーっていう書き込みを見たのですが、
それほどvimを使いこなしてない私にとってはautocmd自体も？？？です。

ということで、後でautocmdなるものも調べなきゃですね。

 

記事書く度に宿題が増えてる気がするのは気のせいだろうか。