+3.3[V]の電源を供給してRS-232Cコマンドを使ってSDカードにアクセスできる。
現状は企画段階。
2009年9月29日火曜日
2009年9月26日土曜日
B041 : Tiny SD card moduleの発注
久しぶりにOlimexに発注。
Tiny SD card moduleも最初のコンセプトに立ち返り、パソコンに接続してSDカードのI/Oを実験できるというシンプルな目的のみのために設計を修正した。色んな機能を付ければ付けるほど自分の中でこのモジュールが色褪せたためだ。
結果的にはこれで満足。
2009年9月25日金曜日
B041 : Tiny SD card moduleの元々のコンセプト
SDカードのI/Oテストに加えて音をちょっと出せるというのがコンセプト。
SDカードの実験のみにフォーカスした小型基板だったはず。
RTCを付けるのは良いが、最初のコンセプトがかなりボケる。
B041 : Tiny SD card moduleにRTCを付ける
Tinyだったはずなのだが・・・
１．デバッグやテスト用にFT232RLを付ける
２．RTCも付けておこう
と、もはやTinyではないこの基板。
典型的な捨てきれない機能で肥大化の例。
でもここは実験用基板ということでサイズに関しては割り切る。
2009年9月23日水曜日
B041 : Tiny SD card module
SDカードのテストボード。
基板サイズは45[mm]x30[mm]。
マイクロSDカード用コネクタを搭載し、ATmega8Lに接続される。
デバッグ用としてFT232RLを搭載。
最終的には簡単なシリアル通信でSDカードを制御できるようにするという目論見。
電源はUSBコネクタから供給する。
だからこのモジュールさえ持ち出せば色々実験できるという仕組み。
写真は検討中の様子。
最初はFT232RLの搭載を考えていなかったが、あると相当に便利。
マイコンになった気分でSDカードのやり取りを体験できるわけだ。
電源系統もこれによって選択肢が１つ増えた。
その検討の様子が写真。
結果的に基板も一回り大きくなったが、今回はこれで良い。
今後必要に応じて小型化すれば良いだろう。
2009年9月19日土曜日
LEDマトリックス表示装置：通称「100ドット」
デザイン・フェスタ（第30回）に出展します。写真は展示販売するLEDマトリックス表示装置（通称100ドット）のためのポップ。
今回は10月25日（日）のみの出展です。
是非お越し下さい。
Taskの性質
FreeRTOS V4.0.0までのバージョンでは自立したタスク構造によるリアルタイムアプリケーションのみが提供されていた。 これはRTOSスケジューラによる従来のモデルである。
概要：
RTOSを用いたリアルタイムアプリケーションは独立したタスクのセットにより構成することができる。 それぞれのタスクは、システム内部の他のタスクやスケジューラ自身によって使用することのない自身のコンテキストを使って実行される。 どの瞬間でも実行されるアプリケーションは１つで、リアルタイムスケジューラにはその決定をする責任がある。 スケジューラはそれ故にアプリケーション実行に際して各タスクの開始と停止を繰り返し行なう。 各タスクはスケジューラの活動について知らず、リアルタイムスケジューラの責任でプロセッサのコンテキスト(レジスタ値、スタック内容、その他)をスワップイン、スワップアウトする。これら各タスクのための保存は自身のスタックによって提供される。 各タスクのスタックへコンテキストをセーブすることで、後で完全に復帰させることが可能になる。 更なる情報は「FreeRTOSはどのように機能するのか？」を参照のこと。
Task要約
O単純
O使用時の制約なし
O完全なプリエンプション
O完全なプライオリティ付け
X各タスクがスタックを持つ結果RAM使用率が増加
Xプリエンプションを用いる場合再突入に関して十分な考慮が必要
ATmega64採用基板のファームウェア検討（仕様検討）
ファームウェア設計にあたって仕様を練る。
今回の設計は色んなテストを兼ねているので機能仕様と技術仕様の境界は曖昧で良い。
■仕様
・日付と時刻を設定できる。
・日付と時刻を表示できる。
・メッセージを表示できる。
・リモコンの受信ができる。
・メッセージをパソコンに接続して編集できる。
・メッセージをネットワークに接続して編集できる。
・リモコンの送信ができる。
・アラームを鳴らせる。
・メッセージを保存できる。
・日付と時刻を設定できる。
・日付と時刻を表示できる。
・メッセージを表示できる。
・リモコンの受信ができる。
・メッセージをパソコンに接続して編集できる。
・メッセージをネットワークに接続して編集できる。
・リモコンの送信ができる。
・アラームを鳴らせる。
・メッセージを保存できる。
一部の仕様は回路の都合上削ることになるだろう。
内蔵ペリフェラルを使う設計にしていなかったためだ。
RTOSを載せる以上、ペリフェラルの使用は必須だ。
いちいちタイマーでゴリゴリ書かない。
RTCなんかもその一つ。
好きなタイミングで読んでも正しい時刻が得られるのは当たり前だけど当たり前じゃない。
ホビー用途ではタイマーを使って時計を実現したりする。
RTOSを使う場合、通常異なるアプローチとなる。
その１つがRTCだ。
2009年9月17日木曜日
ATmega64採用基板のファームウェア検討（FreeRTOSのポーティング）
ハードウェアについては一通りの確認が終了。
ハードウェア確認用ファームウェアをそのまま使うのは正直あまり面白くない。
そこでちょうど興味のあった小さなOSを載せる事を検討。
今回は内蔵ペリフェラルを使うべきところを通常のポートに接続してしまった所もあった。
OSでタイマーを消費してしまうと力技での対処は難しくなる。
そこでちょうど興味のあった小さなOSを載せる事を検討。
今回は内蔵ペリフェラルを使うべきところを通常のポートに接続してしまった所もあった。
OSでタイマーを消費してしまうと力技での対処は難しくなる。
でもいずれハードウェアは改修するのだから、力技は捨てた。
方針が決まればやるだけ。
以前から目をつけていたFreeRTOSをポーティングすることにした。
ポーティングと言ってもATmega323への移植があるのでそれを流用。
同じATmegaなのでほとんど修正いらずだった。
ディスプレイとシリアルのタスクを立てて並列動作のテスト。
第１段階としては良さそう。
タイミングジッタと精度を測っておきたいなぁ。
2009年9月14日月曜日
ATmega64採用基板のデバッグ（XPort動作確認編）
3.3Vレギュレータを先に取り付け出力電圧を確認。
XPortを取り付け動作確認。
実はこの基板、最終工程で容量の大きなＣを追加する予定がそのまま発注してしまったもの。
案の定XPortが起動するかしないかで電源が発振している様子。
マイコンがリセットを繰り返す。
電源系にＣを後付け。
マイコンが正常に起動することを確認した。
今度はLANTRONIX社のDeviceInstallerでXPortの設定。
MACアドレスを入力するとデバイスの設定ができる。
デバイスの設定をしてWEB設定を開いてみる。
ところどころのページが「ない」と言われる。
先ほどの電源が発振した時にフラッシュの内容が壊れたかもと思う。
LANTRONIX社のホームページからファームウェアのromファイルとWEBセットアップのcobファイルをダウンロード。書き込んで全てのページで正しく表示が行われることを確認した。
2009年9月13日日曜日
ATmega64採用基板のデバッグ（クロック選択編）
ATmega64の場合、周波数別にフューズビットを設定する必要がある。
使用する周波数帯と外部クロックソースによってはCKOPTの選択も必要。
この辺りはややこしいのでこの後の世代のデバイスからは設定項目が変更されているようだ。
AVRの場合、このクロックをISPで使用するので選択を誤ると書けなくなる。
私自身もATmega8で間違ったクロックを選択してしまったことがある。
初めてクロック設定をした時の事で、ちょっと選択してみようなんて軽い気持ちでやってしまった。
ISPできなくなると知って愕然とした。
どんなマイコンでも一癖二癖あるもの。
2009年9月12日土曜日
ATmega64採用基板のデバッグ（どうすんの解決編）
そもそも大量にあるLEDを有効活用しようという策だったのだが以下の点で今回の設計はいまいち。
- 実装が手間。
- LEDとピンヘッダのクリアランスに余裕がない。
優れた設計ならば誰が作っても高品質だし、誰が作っても作りやすい。
これは・・・作りにくい。
今後このモジュールを懲りずに使うなら以下を修正したい。
- LEDピッチを2.54mmに合うようにしたい。
- 通常のピンヘッダを使って実装できるようにしたい。
- クリアランスを再考したい。
本日をもってXPort以外のハードウェアは電気的な確認を終了させた。
2009年9月11日金曜日
ATmega64採用基板のデバッグ（どうすんの編）
設計したＬＥＤモジュールのピンピッチが最低。2.54mmでないから普通のピンヘッダが使えない。
どうやってくっつけるつもりになっていたのだろうか。
バラのピンヘッダを使うつもりだったのだろう。
すごく面倒な実装。設計時にこういうことはきちんと考慮しよう。
2009年9月10日木曜日
ATmega64採用基板のデバッグ（ISP端子とFT232RLのアイソレーション）
10K[ohm]でISPとFT232RLをアイソレーション。
残りの確認事項
- ブザー
- 赤外線出力
- スイッチ
- XPort
- LED Matrix
2009年9月7日月曜日
ATmega64採用基板のデバッグ（赤外線受信動作確認編）
電気的な接続のみ確認。通信フォーマットは数種類あるのでそのあたりは本格的な設計時に考える。
インプットキャプチャで動作しているのだけを確認した。
2009年9月6日日曜日
ATmega64採用基板のデバッグ（FT232RL動作確認編）
昨日発覚したSPI経路のバグ。
ATmega64のTXD/PDO, RXD/PDIには既にFT232RLが直接接続されていた。
MISO, MOSIをそれぞれPDO, PDIに接続し直し、FT232RLはアイソレーションパターンカット。
冷静に考えたらFT232RL側のパターンカットをする前に一度SPIを動作させてしまっていた。
出力段が衝突して回路が死んでいるかもと思う。
幸いエコーバックするプログラムを書き込んで動作しているので問題なさそうだ。
でもこれは運がいいだけ。普通なら壊れているもんだ。
最近のデバイスは耐性を高めるために出力段も色々工夫されている。
もしかしたらそういった恩恵を知らずに受けているのかもしれない。
買ったばかりのAVRISP mkIIも無事のようだ。
まったく何やってんだか。
次はI2C ROMを見ていこうと思う。
2009年9月5日土曜日
ATmega64採用基板のデバッグ（バグ大量編）
- SPIのデータはMOSI, MISOでない。正しくはPDI, PDO。これはATmega8とは異なる。ついついひょいひょいと繋いでしまった。
→２本のジャンパ追加。
- SPIコネクタのVccはターゲットのVccとアイソレーションすることにし「解放」にしていたが、AVRISP mkIIではプログラミングできない。
→１本のジャンパ追加。
- バグ１の関係でTXD/PDO, RXD/PDIに接続しているFT232RLがSPI動作に影響を与えている。
→アイソレーションが必要。FT232RLの~RESETを使えば良いか？
ミスはミス。
起こってしまったことは仕方ない。
こうやってどんどん過ちを繰り返して成長して行くものだ。
でも、データシートは確認しようね。
今日中にISPとUSB-SERIAL周りを確認する予定だった。
FT232RLのISPとのアイソレーションを再考したいので今日はここまでとした。
登録:
投稿 (Atom)