CuBeatSystems

Today, I wanna talk about handling a gamepad on a linux environment.
We can get the device information using cat a device file.

cat /proc/bus/input/devices

I: Bus=0003 Vendor=0079 Product=0011 Version=0110
N: Name="USB Gamepad "
P: Phys=usb-.&checktime(0000,00,1,':')d.0-1/input0
S: Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input4
U: Uniq=
H: Handlers=event4 js0
B: EV=1b
B: KEY=3ff 0 0 0 0 0 0 0 0 0
B: ABS=100 1f
B: MSC=10

And now, the device has a file for the event.
In this case event4 for js0.
(See /proc/bus/input/event?, /proc/bus/input/js0)

So we can read the action using a codes.

#include
#include

int main(int argc, char **argv);

int main(int argc, char **argv)
{
FILE *dev = fopen("/dev/input/event4", "r+");
if (NULL == dev) {
perror("fopen");
return 1;
}
for (int i = 0; ; i++) {
uint8_t c = fgetc(dev);
fprintf(stderr, "%c0x%02x", ((i % 16) == 0) ? '\n':' ', c);
}
return 0;
}

That's great.

考え直してプロセッサを変更。
I/Oポートを数ポート増やすことで気持ち悪いスイッチの接続(A/D変換でスイッチを読む)とか気持ち悪いバックライト制御(SPIでD/Aを制御してバックライトをON、OFF)を解消できる。
誰が見ても気持ち悪くない構成にしたかった。
小さいプロセッサで制御は魅力的だったが、どうしても納得できなくなっていた。
自分が納得できない設計は後で必ず後悔する。

一回り大きなプロセッサになったので、今回の小さい基板では配置配線に困るかもしれないが、現状はこれで満足。
SDカードの挿入も検出できるようにしたし、ブートスイッチも付けた。
テスト用LEDとアンプのシャットダウン制御も追加。

あとは2、3日寝かせてから再度見直していくことにしよう。

電気図面は一応終了。

LCDのバックライト輝度調整やコントラスト調整もMPUからやりたくて迷いに迷って2時間。
結局何も制御しないことにして電気図面終了となった。



仮配線を開始。
残り240本の配線。

B046 : uMP3 PLAYERはそれこそ、カラーLCDもついてSDカードも搭載しているし、フラッシュROMなんかもあって、MP3が再生できる素敵なプロジェクトなんだけど、カラーLCDもいつまで入手できるかわからないし、先日上げたとおり色々な種類のものが手元に来てしまっていて扱いづらい。



B049 : Alarm Clockでは以下にフォーカスしてお手軽プロジェクトとしてまとめたい。

• RTCを搭載して時計にしよう。
• 入手性の良い汎用キャラクタモジュールを採用してお手軽にしよう。
• イヤホンから音楽が流れるのではなくて、スピーカで直接鳴らそう。
• 上記の特徴を活かして目覚まし時計に仕立てよう。

検討中のブロック図はこんな感じ。



だいたいの外観も検討。



一応検討のみという段階。

AVRISP mkIIは便利なのですがオンフィールドで書き換えるには不便ですし、ユーザに書き変えを頼むわけにもいきません。

Atmelが公開しているアプリケーションノートAVR109に自己プログラミングがありましたので試してみました。ターゲットMPUはATmega8とATmega328Pです。

preprocessor.shを使うとdefines.hに記述する内容を吐き出してくれるようになっています。

usage: preprocessor.sh device bootsize progport prog_no cpu_freq baud_rate

デバイス名とブートコードサイズ、プログラミングモードに入るポート名とポート番号、CPU周波数とUSARTのボーレートを指定します。

ATmega8の例では

preprocessor.sh atmega8 1024 PORTB 0 8000000 9600> defines.h

と言った感じです。
このケースの場合、PORTBのビット0がLOWレベルになっていたらプログラミングモードに入ります。ブートローダ内部では対象ポートのプルアップレジスタを有効にしますので、外付け抵抗は必要ありません。ピンにスイッチを付けておくだけでこの機能をサポートするボードが完成します。
（ブートローダはこれ以外のI/O設定は一切行いません。要するにすべてのピンが入力のままです。）

ターゲットにブートローダを書き込んで一度電源を切り、PORTBのビット0をLOWにして電源を入れます。ブートローダが起動したはずですのでminicomを使って接続してみましょう。

コンソールに大文字Sを入力した時にAVRBOOTという文字列が帰ってくればブートローダが期待通りに動作しています。ホストは特定のプロトコルに従って書き換え対象プログラムをブートローダに渡すことで、ブートローダが自身のフラッシュを書き換えてくれるというわけです。

ここで疑問が湧いてきます。

• ユーザプログラムはどこに配置するのでしょう？
• 何か特別な配慮が必要になるのでしょうか？
• ブートローダは上書きできないようにできるのでしょうか？
  

さて、疑問を一つずつみていきましょう。

試しに、ブートローダのことを意識せず従来のユーザプログラムを書き込んでみましょう。
avrdude -c ?とすると対応しているプログラマを表示できます。
この中に「avr109 = Atmel AppNote AVR109 Boot Loader」というのがあります。

sudo avrdude -c avr109 -b 9600 -P /dev/ttyUSB0 -p m8 -U flash:w:sdcmod.hex

書き込んでみました。

Connecting to programmer: .
Found programmer: Id = "AVRBOOT"; type = S
Software Version = 1.5; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=64 bytes.

Programmer supports the following devices:
Device code: 0x77

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9307
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: butterfly_recv(): programmer is not responding

あれれ。
プログラマIDやソフトウェアバージョンは取得できているようです。
でも書き込めませんでしたね。
プログラマからの応答がないようです。

ここで言うプログラマとはまさにブートローダの事です。
おかしいですね。
プロトコルの仕様では0x13を返すようになっています。
ブートローダのソースを見るとまさにそういう実装になっています。

あれれ？
ちょっと何か思い違いがありそうですね。

ここからは次回のデバッグ編に続くことになりそうです。

ソースファイルの管理はSubversionを使っています。
あわせてRedmineも使用していたのですが、先日再インストールする機会があったのでBitNami :: Redmineを試してみました。以前はそれこそ半日かけてインストールという感じでしたが、何の苦労もなく完了。

気になる点は一点だけ。
Ubuntuは最近まれに固まるのですが、再起動後ctlscript.sh startした時に何やら怒られます。

** !!! PID file tmp/pids/mongrel.3001.pid already exists. Mongrel could be running already. Check your log/mongrel.3001.log for errors.
** !!! Exiting with error. You must stop mongrel and clear the .pid before I'll attempt a start.

starting port 3002
** !!! PID file tmp/pids/mongrel.3002.pid already exists. Mongrel could be running already. Check your log/mongrel.3002.log for errors.
** !!! Exiting with error. You must stop mongrel and clear the .pid before I'll attempt a start.

これはメッセージどおりにこれらを削除してやれば良さそうです。

sudo find . -name "mongrel.3002.pid" -print
./opt/redmine-0.8.7-0/apps/redmine/tmp/pids/mongrel.3002.pid

sudo rm /opt/redmine-0.8.7-0/apps/redmine/tmp/pids/mongrel.300*

これで無事にsudo /opt/redmine-0.8.7-0/ctlscript.sh startで再起動できます。
こういった事が起こることを想定してctlscript.shに同様の処理があると良いかもしれません。

2つの商社から2回のオーダで入手した液晶の外見の違いから見る種類は、なんと5種類。
2回のオーダだから当然集めたくてこうなったわけではない。

ここではこれらの違いについて「基板」と「LCDとFPCの接続押さえ金具の外形」から整理してみたい。国内外のサイトでは単に「緑色のPCB」とかで区別しているところが多い。
実際に手元にある5種類を見る限り、PCBの色で適切に分類できるわけではなさそうだ。
更にデバッグの過程で判明したコントローラに関しては型名を明らかにするつもり。

■1つ目
基板：薄緑
金具：中央に対照的に配置され比較的小型。白色のジェルで埋まっている。

裏面：


■2つ目
基板：深緑
金具：

裏面：


■3つ目
基板：オレンジ色
金具：

裏面：


■4つ目
基板：オレンジ。
金具：左右非対称。

裏面：

コントローラ：PCF8833(Philips)

■5つ目
基板：
金具：

裏面：

FreeRTOSでリンクされているMicorochipTechnology社のアプリケーションノートAN1264はPICを使用しない人にとってもわかりやすく整理された文書。

B046 : uMP3 PLAYERはAtmelのATmega328Pを使っている。
FreeRTOSにはATmega323への対応がある。

基本的にはカーネルティックタイマ周辺のレジスタ設定を変更するだけで使用できる。

• TIMSKをTIMSK1に変更する。ATmega328PにはTIMSKというレジスタは存在しない。
• portCOMPARE_MATCH_A_INTERRUPT_ENABLEのビット定義を修正する。_BV(OCIE1A)
• 割り込みハンドラ名を修正する。TIMER1_COMPA_vect
  

portCOMPARE_MATCH_A_INTERRUPT_ENABLEは値でハードコーディングされていて気づくまでに無駄な時間を費やしてしまった。
基本に戻ってシミュレータでハードウェアタイマがきちんと動作しているのか確認すると、タイマオーバーフロー時の割り込み有効フラグが設定されていないことに気づく。
修正した結果が_BV(OCIE1A)というわけ。
ハードウェア依存箇所の値によるハードコーディングはできれば避けてほしいなぁと思う。

使用したFreeRTOSのバージョンは6.0.1。
バージョンが上がっても幅広いデバイスをきちんとサポートし続けている。
今のところすごく信用のできるオープンソースプロジェクトだ。