2009年6月1日月曜日
STM32使用開始
2009年5月13日水曜日
RTOS
就活がやっと終わったので再開。だけど...CANSATのスケジュールはかなり厳しい模様。学会が終わったら集中しないといけない。CANSATではCANを使って各部を繋ぐ構成にしようと発案したためか、マイコン周りを全部担当することに。どうにかしてソフトウェアの作りやすさも考えないといけない。
最近は携帯機器向けの高性能なマイコンが出回っているおかげで、海外ではGumsticのようなボードが手に入るようになった。 このクラスにもなれば、Linuxを動かしてソフトをつめば、ネットワークに繋いで遊べるのだろうけど...常にこんなハイスペックが欲しいわけではない。
とはいえOSは使いたい。そこでeCosのようなRTOSに目がいくのだが...一体どう開発したらよいのか分からない。自作ボードでOSを動かすとき、一体何を書けばよいのだろうか? 一応知識として「OSはハードウェアの差異を意識することなくソフトウェアを持ってこれる」ということは知っているので、それを基に考察し裏づけをしていきたい。
- eCosの提供してくれるもの
- eCosは、OSとしての機能(タスクの管理やコンテキストスイッチン グ等?)を提供してくれる。その一部はCPUに依存するので、アセンブリで書かれているものもある。eCosではこれをHAL(Hardware Abstraction Layer)と呼んでいる。疑問:OSが動くには最低でもタイマーの設定がいるはず。Redbootではシリアル通信も必要だったはず。ハードウェアの構成如何によって異なるので、移植に際してはいくつかコードを書かなくてはならないのだろうか?手を加えるべきコードに関する情報はどこにあるのだろうか?
- ファイルシステム?
- 最新のeCosでは、FATファイルシステムをサポートするようになった。 この場合も移植に際しては手を加える必要があるのだろう。 Flash、SDカード、RAMなど、ファイルシステムで使う記憶装置はハードウェアの構成に依存する。目的に応じて変えたいこともある。ファイルシステムのような「ミドルウェア」は、OSのハードウェアを抽象化する機能を使って記述され、足りない部分はユーザに記述させるのだろうか?
- アプリケーション開発
- 直接ハードウェアをいじらず、予め用意したOSやミドルウェアで機能を実現することになるはず。割り込みなども、直接触らないでOS経由で操作するはず。
- ミドルウェア開発
- プロトコルスタックやファイルシステムなど、アプリケーション開発で部品となる機能を提供するのがミドルウェアだったはず...これはハードウェアまたはOSの機能を使って記述することになるはず。ハードウェアの機能は抽象化されないといけないので、いくつかのハードウェア依存箇所を空白にして作るのだと思う。このハードウェア依存箇所もまた、OSの機能を使って記述されるべき?
- 移植
- OSもミドルウェアも、ハードウェアによって異なる部分と、共通の部分がある。ハードウェアによって異なる部分は最小化され、必要な機能をハードにあわせて書くだけで良いよう工夫されている?移植とは、この部分を記述することだと思う。
2009年3月22日日曜日
今後
VSLAMの実装を行う。練習としてEKF SLAMに取り組む。GSLの行列や乱数などを利用してシミュレータを作る。VTKで結果を表示する。
SLAMの前にやったEKF位置推定からわかったこと: 信念から予測を行ったら、得られた観測すべてについて更新ステップを行う。一度に反映するのは1つだけでも、次の予測の前に更新し続けることですべての観測を反映できる。
相関のあるノイズの作り方について: 確率変数Xの分散共分散行列Var(X)が対角成分しか含まないとき、行列AをかけたAXの分散共分散行列は、A Var(X) A' となる。相関のない乱数からなるベクトルに対し、適当な行列をかけてやれば、成分間に相関ができる。手間はかかるけど一応相関のあるノイズは作れる。
2009年2月21日土曜日
マイコンで復調
FSKの場合、周波数が高いか低いかが分かれば良いので、FFTを使うのも方法の1つだが、演算量が多い。受信は送信と異なり、常に動作していなくてはならないため、あまり複雑だと消費電力が多くなってしまう。そこで、外部に簡単な回路を設け、そこで電気的に相関の演算を行ってもらうことにする。
PSoCのアプリケーションノートAN2336「Simplified FSK Detector」では、FSK変調のかけられた信号をデジタル信号にした後、基準となるクロックとのXORをとり、これをLPFで平滑化することで相関を得る「correlator」の回路について書かれている。
マイコン外部にXORを用意し、マイコンからはクロックを、音声入力からは変調波を入力することで同じことが行える。あとはcorrelatorの出力を定期的にA/D変換し、その値を閾値と比較して'0'と'1'を判断する。
LPFはビットレートで定数が決まるはずなので、correlatorはキャリア検出のみに使用し、実際の処理は全てデジタルで行うべきかもしれない。
2009年2月19日木曜日
OlimexとP板での基板外形の取り扱い
OlimexとP板では基板外形の取り扱いについて異なることが分かった。基板発注で面付け(panelize)を頼む際に問題となりそうなので気をつける。
Olimexの場合
OlimexのFAQでは、Panelizationに関して「Please panelize your boards with 0.254 mm (10 mils) gap between outer outside of their borders (NOT between the centers of your board borders i.e. take into account the border line width too!) 」と書いてある。基板の境界線間に10milの余白をあけて並べることが必要で、境界とは外形線の中心ではなく太さを加えた外側とのこと。確か基板外形もシルク印刷されるため、必然的に外形線も10milにしなくてはならない。切り取り方は裁断とカッターによるものがあり、必要な余白も異なる。
P板の場合
P板の規格の中の基板製造用データ説明書によれば、外形線は線幅0.2mmと指定されている(10milではダメ?)。外形線の中心を基板外形とする。基板間の余白は3mmとなる(ルータ切り出し)。3mm以上ではない。
OlimexとP板で使えるようにするには
基板外形レイヤを2通り用意しておき、出力時に切り替えることにする。CAD上でのサイズは共に外形と一致させるが、Olimex用はは外形に接する外形線を、P板用は外形と一致する外形線を描くことにする。
2009年2月18日水曜日
Alternate Functionとピンの重複
複数の周辺回路が同一のI/Oに割り当てられている場合の問題と対策について調べた。STM32シリーズのエラッタシート内の「STM32F10xx Silicon Limitations」において、 Alternate Function で生じる問題について書かれていた。
CAN と USART1 間の問題
リマップをしない状態では、CANで使われるRX/TXはそれぞれ、USART1のCTS/RTSとPA11/12ピンを共有する。RXとCTS、TXとRTSはそれぞれ入力と出力なので、PA11/12ピンはそれぞれAlternate In と Alternate Out と設定して使用する。
このとき、CANが割り当てられてはいるが使わない(not clocked)場合においても、PA12ピンでは'1'が出力されてしまうという不具合があるらしい(エラッタシートP.7)。そのため、CTS/RTSを使ったハードウェアフロー制御が行えなくなる。フロー制御を行いたい場合、CANの使用にかかわらず、CANをPA11/12以外にリマップしなくてはならない。(CAN_REMAPを"00"以外にすればよい)
SPI1とUSART2間の問題(エラッタ2.4.2 - 2.4.3)
USART2はPA0からPA4をCTS, RTS, TX, RX, CKとして使い、同期通信が可能となっている。一方SPI1は、PA4からPA7を nSS, SCK, MISO, MOSIとして使っている。 (どちらもリマップを行わない状態において)
USART2のCKは、同期通信モードを有効にすると出力になり、それ以外は使用されない。 SPIはマスター/スレーブを切り替えることができ、スレーブセレクト(nSS)はマスターで出力、スレーブで入力となる。
エラッタシートの2.4.2によればSPIスレーブ時はUSART2は同期通信モードを使用できない(対策はない)という。これは、USARTの出力するクロックがスレーブセレクトへ入力されてしまうためと考えられる。また2.4.3によれば、SPIマスター時にSPIのスレーブセレクトを出力しないよう設定すれば、USART同期通信モードを使用することは可能という。このためにはSPI_CR2のSSOE(Slave Select Output Enable)ビットをクリアすればよい。
これらの記述から分かったこと
周辺回路のピンが重複している場合においても、どちらかが重複箇所を使用しないよう設定することができれば、機能は限定されるものの共存は可能であることが伺える。(ピンが重複していて、どちらもそのピンを使用しないように設定できないなら共存はできない)。 大抵は何らかのイネーブルレジスタが用意されているようだ。 リマップ後に重複するような場合についても、同様だと思われる。
ピンが重複している場合でも、CANとUSART1のような例外を除き、基本的には片方が停止していれば問題ないと思われる。
マイコンの中は設定可能だが、基板の配線は決まっている。リセット直後は基板にあわせたコンフィギュレーションを行う必要があるため、コンフィギュレーションとその後のGPIOロック(リファレンスマニュアル参照)を行うルーチンを用意しておく必要がありそうだ。 設定を正しく行えないと、最悪の場合は外部のICとI/Oを破壊する可能性もあるため、コンフィギュレーションについては慎重に行う必要がありそうだ。
重複ピンの内部で出力同士が衝突するかについては記述されていないが、破壊されるようなことはないと信じたい(ORバスのような何かで直接は衝突しないはず...)。
STM32のAlternate Functionが分からない
STM32ファミリのマイコンは周辺回路を多く持っている。一般的なマイコン同様、1つのI/OピンにGPIOと複数の周辺回路が割り当てられている。I/Oピンの入出力設定を行うレジスタでは、I/Oピンを入力・出力・Alternate Functionという3つのモードに切り替えられるらしい。更にプルアップやプルダウンの設定、動作速度の設定もできるらしい。(RM0008 Alternate Functionについての解説より)
GPIOの出力レジスタODR(Output Data Register)は出力バッファに接続されており、出力モードが設定されたビットにはODRの値に対応する電圧が出力される。Alternate Functionモード(これにも入出力はある)にすると、ODRのは出力バッファから切り離され、代わりに周辺回路が接続される。
この考え方は他のマイコンと同じだが、STM32では複数の周辺回路で一部のピンが重複して割り当てられていることがある。この場合周辺回路を同時に使えないはずだが、どちらの機能がピンを使えるの設定を行う方法が不明。重複した周辺回路の片方が、そのピンを使わないよう設定できたりしたら、同時に使うことができるのだろうか?
また、周辺回路は接続先のI/Oピンを切り替えられることがあるのだが(これをリマップと言い、ソフトウェアからリマップレジスタの値を書き換えることで2~4通りの接続が選択できる)、リマップ先が重複していることがある。リマップしても重複していれば当然使えないはずだが...どちらを使うかの設定はどこでするのだろう?
同じピンに複数の周辺回路が割り当てられた場合、やはり2つの回路を同時に有効にしてはいけないのだろうか(出力バッファへの入力が2つの回路から駆動されるため)。明示的に周辺回路を切り替えられる仕組みがあったりするのだろうか。何らかの注意が書かれていて欲しいが、マニュアルから見つけられずにいる。