AVRで秋月のI2C接続小型キャラクターLCDを動かす
ひさしぶりに、電子工作で作りたいものができたので、ちょっとリハビリを兼ねて、AVRの触ったことない機能&触ったことないデバイスを触ってみよう、と思い、秋月でI2C接続小型キャラクターLCDを買ってきて動かしたので、今日はそのメモです。
AVRでI2Cデバイスを動かす場合、内蔵のTWI機能を使うのが基本です。TWIを使うことで、I2Cデバイスのマスターもスレイブも簡単に作れますし、クロックストレッチ(スレーブ側の処理が間に合わないときにスレーブがクロック信号をGNDに押さえつけることで、クロックを一時停止させ、通信を遅らせる仕組み)やマスターが複数いる場合の競合の検出などもハードできちんと対応してくれています。その代わり、TWIはmega系など、8bit AVR の中でもややリッチめなデバイスにしか搭載されていなかったりしますので、それ以外のマイコンではソフトで実装してやる必要があります。競合検出なんかの実装は結構面倒なので、ソフト実装で対応する場合はそのような面倒な仕様は省略してシングルマスターのみ対応とかで妥協しちゃうことが多いんじゃないでしょうか。
ともあれ、今日は素直にTWI使って実装してみました。
続きを読むlocalvimrc: ディレクトリごとに別の .vimrc を適用する
色々なソフトウェアプロジェクトを掛け持ちしていたり、一つのプロジェクトが複数のプロジェクトの寄せ集めだったりすると、プロジェクトごとにコーディングルールなどが異なっていて、エディタの設定を使いわけたくなることがあります。そんな時に便利なのが localvimrc という vim のプラグインです。
インストール方法
まず、vim.org の localvimrc のページに行き、最新バージョンの localvimrc.vba をダウンロードします。
あとは、そのファイルを vim で開いて、以下の vim コマンドを打つだけです。
:so %
これで、 ~/.vim/plugin/localvimrc.vim がインストールされます。
ダウンロードしたファイルは削除してしまってかまいません。
使いかた
特別な設定を加えたいソースコードツリーのトップディレクトリに .lvimrc という名前のファイルを作成すると、それ以下のファイルを開く際は、通常の ~/.vimrc に加えてその .lvimrc も読み込まれるようになります。
ただし、セキュリティ的な観点から、読み込み時に毎回「読み込んで良いか?」と聞いてきて鬱陶しいので、以下のいずれかの設定を ~/.vimrc に追加しておいた方が良いでしょう。
let g:localvimrc_ask=0 " いちいち聞かずに勝手に読み込む let g:localvimrc_persistent=2 " 一度聞いたファイルを記録しておき、次回からは自動で読み込む let g:localvimrc_persistent=1 " 聞いたときに大文字のY/N/Aで答えた場合のみ上記の動作をする
私は一番最後の設定で使っています。なお、選択の記録はファイル ~/.localvimrc_persistent (設定で変更可)に保存されます。
また他にも .lvimrc は(これもセキュリティ的に) sandbox で実行されるのですが、それを避ける設定や、複数の .lvimrc が見つかった場合にどう処理するか(ぜんぶ実行、一番深いところのもののみ実行など)、といったいろいろな設定が可能です。詳しくは下記の公式のドキュメントを参照してください。
https://github.com/embear/vim-localvimrc/blob/master/doc/localvimrc.txt
打ち込めないような名前のファイルでもシェルで操作する方法
今日は小ネタです。
日本語のファイル名だったり、操作ミスなどで制御文字を含んだような名前のファイルができてしまった際に、そのファイルをシェル上で消したりリネームしたりする方法をご紹介。
1. "ls -li" で該当ファイルの inode 番号を取得
まず、対象のinode番号を取得します。たとえばこんな感じです。
$ ls -li 合計 0 2490401 -rw-r--r-- 1 over80 over80 0 4月 17 23:04 binname_???????????????_.txt 2490385 -rw-r--r-- 1 over80 over80 0 4月 17 23:02 日本語ファイル名.txt
一番最初のカラムに表示されている数字が、そのファイルの inode 番号です。この番号はそのファイルシステム下で一意なので、ファイル名の代わりにこの番号でファイルを指定するわけです。
ちなみに、上記の例の1つめのファイルは、16進で "0x01" から "0x0f" の制御文字を含んだ名前のファイルにしてみました。"ls" はその端末の locale で表示できない文字は "?" で置き換えてくれるので、表示は崩れません。この機能はオプションで明示するか、パイプ等でターミナル以外に出力する場合は off になります。
$ ls | hexdump -C 00000000 62 69 6e 6e 61 6d 65 5f 01 02 03 04 05 06 07 08 |binname_........| 00000010 09 0a 0b 0c 0d 0e 0f 5f 2e 74 78 74 0a e6 97 a5 |......._.txt....| 00000020 e6 9c ac e8 aa 9e e3 83 95 e3 82 a1 e3 82 a4 e3 |................| 00000030 83 ab e5 90 8d 2e 74 78 74 0a |......txt.| 0000003a
2. "find -inum (inode番号)" で得たファイル名をコマンドに渡す
たとえば、"日本語ファイル名.txt" (i-node 番号は 2490385) を mv で ascii.txt にリネームする場合、こうします。
$ mv "$(find -inum 2490385)" ascii.txt
シェルで $(コマンド) と書くと、そのコマンドを実行した結果がそこに埋め込まれます(バッククオートで括るのと同じですが、ここでは見やすさ重視でこちらで書いています)。ファイル名に空白文字などが入っていると、そのままではそれが再評価されてしまうので、ダブルクォートで括って再評価を避けています。
なお、わざわざ一旦ファイル名を出力しなくても、find の -exec オプションで同等のことができますので、そちらでやっても良いでしょう。
$ find -inum 2490385 -exec mv "{}" ascii.txt ";"
ただ、find に慣れている人であればこちらが素直だと思いますが、慣れていない人に教えるには find の引数の与え方が特殊なので、前者の方法でやっていただいた方が良いかと思います。
(以下、2014-06-08 追記)
なお、 find は周知の通り、指定したディレクトリ(デフォルトはカレントディレクトリ)から、再帰的にファイルを探しにいきますので、サブディレクトリ等がたくさんある場合は時間がかかります。今回のようにカレントディレクトリに存在すると分かっている場合は、探索の深さを制限してやるとよいでしょう。
$ mv "$(find -inum 2490385 -maxdepth 1)" ascii.txt $ find -inum 2490385 -maxdepth 1 -exec mv "{}" ascii.txt ";"
死にかけのHDDからのデータ吸い出しには GNU ddrescue が良いらしい
今日は超小ネタ。
(というか、言いたいことは記事タイトルで言い切ってしまってます。)
先日、家でサーバーとして使っているPCのHDDの調子がおかしくなっていたので、データの引き上げを行おうとしたのですが、dd でパラメータをいろいろ設定するのは面倒だし、良いツールなりスクリプトなりがないかと探したところ、ddrescue というプログラムがあることを知りました。
2つの ddrescue
ただ、ちょっとした罠なのですが、ddrescure という名前のプログラムは2種類あります。
どちらも ddrescue で、同じ目的・機能のものですが、まったく別のソフトです。
区別して呼ぶ場合、前者は dd_rescue、後者は GNU ddrescue と呼び分けたりしますが、前者の方が古くからあったからか、単に ddrescue と呼んだ場合、暗黙的に前者を指す事が多いようです。両方とも ubuntu のリポジトリに入っているので apt-get でインストールできますが、パッケージ名は、前者が ddrescue で、後者は gddrescue です。
通称 | Ubuntu パッケージ名 | プログラム名 |
---|---|---|
ddrescue, dd_resque | ddrescue | dd_rescue |
GNU ddrescue | gddrescue | ddrescue |
機能に関しては GNU ddrescue が良いようですので、あまり悩まずそちらを使っておけば良いのではないかと思います。
(2014-06-08:追記) なぜ GNU ddrescue が良いと判断したかというと、単純に後発で、 GNU ddrescue の作者が、類似の他のソフトのマズい点を修正するような設計を行っているようだから、といったところです。"GNU ddrescue dd_rescue" でググったり、wikipedia を見たりすると、いろんな意見が見れますので、興味のある方は調べて見てください。
使い方
AtCoder Regular Contest #019 参加記録
最近、ちょくちょく AtCoder の Regular Contest に参加しています。
ここ数回は毎回参加できているのですが、一向に上達する気配が無い……というか、単に当日に漫然と参加している程度では上達するわけもないので、せめて最低限の記録と復習を残してみようと思います。
Summary
AtCoder Regular Contest #019 (公式解説)
問題A | 問題B | 問題C | 問題D | |
---|---|---|---|---|
コンテスト中の最終回答 | AC 8:13(1回目) |
AC 37:33(2回目) |
- | - |
終了後じっくりと回答 | - | - | TLE | AC(30点) |
解説を読んでから回答 | - | - | AC | (未挑戦) |
総合: 200点 42:33 (1ペナルティx5分) 92位
JavaScript 向け vim 設定とか unit test とか
ご無沙汰しております。Over80です。
年単位で放置していた当ブログですが、更新再開してみようと思います。一発目の今日は、JavaScript 関連の雑多ネタです。
JavaScript でブラウザ上で動くゲームを作りたい、というところが発端なんですが、 JavaScript はあまり書いたことが無いので、ある程度以上の規模のコードを書くのであればと、開発環境からきちんと揃えていました。
主な内容は、
- 良い感じのコーディングスタイルを確認しときたい
- それを確認する lint ツールも欲しい
- 快適に書けるエディタとかIDEとかあるの?
- unit test もできるようにしときたい
とかいろいろと調べた内容のまとめです。
続きを読む