念のため、その通り入れてみる。シンタックスエラーではねられる。-yをとりのぞいて入力。順調にパッケージがインストールされた。Debianは初めてだが、このapt-getは実に便利である。Linuxを入れて、rpmに感激したことを思い出す。ウェブブラウザーを探す。おや、Conkerorという簡易なブラウザーしかない。こいつキーボードからURLを入れさせる。コマンドガイドを頼りに日本語サイトを入れる。おおう、きれいな日本語フォントだ。いやあたいしたものだ。8センチ四方のボードでここまで動くのである。ボードのCPUチップに触ってみる。熱くなっているが、やけどしそうなほどの熱さではない。数ワットというところだ。PC、そうちょうど今ターミナルに使おうとしているPentium133Mhz時代のLet'sNoteの画面の動きをもう少し遅くした感じだ。ウインドウを激しく動かすと軌跡が残る。これだけ動けば十分だ。こちらは今のところNASあたりを予定している。それにしても、今度の雑誌の誤植には驚いた。信頼性について活字メディアを一段高い位置に置いて考えていた自分がもう古いのかもしれない。Web情報ならいくらでも訂正が効くが、活字はそういうわけにはいかない。校正には念には念を入れ、読者もそれを信じていた。いう自覚が今は薄れているのだろうな。(火)レガシーなRS232CインタフェースにはまるSTM32のRTC(リアルタイマークロック)が動き始めた。次のプロジェクトの目標はSDカードアクセスで、行く行くはこのSTM32で、液晶フォトフレームのようなものを作ってみようと考えている。その前に環境を整備しておこうとして思わぬところで時間を費ってしまった。一週間たっぷりはまりこんで一喜一憂していた。これが趣味の醍醐味だと負け惜しみを言っている(単に耄碌(もうろく)しただけかも)。printfがやっと動いた(6/08/09)当面の懸案は片付いたのだが、具体的な次の作業が見つけられない。そんなこともあって細々とした手直しや、周辺の環境整備をして気分が乗るのを待っている。1年以上前にAVRの実装処女作として作った温度ロガーを久しぶりに動かしてみた。電池はまだ十分あって温度が表示されたが、コマンドを殆ど忘れていることがわかる。あわててコマンドの案内メッセージを出すためにAVRStudioを立ち上げてAVRプログラムの修正。やり方を忘れていなかった。思えばBeagleBoardのために買ったワイヤレスのキーボードを試してみたりする。当研究所のキーボードは15年以上前に買ったDECのPCについていたものである。中古でも当時30万近くしたPCだったのでキーボードのつくりが良い。こいつの使い勝手、キータッチを上回るキーボードにそれ以来お目にかかったことがない(安物ばかり使っていたこともあるが)。ブラウン管モニター同様愛用していて今も何の不具合もないが、さすがに古くなってきた。今度のワイヤレスはその代替としても考えており、少し高めの製品を選んだためか打ちやすい。ところでBeagleBoardのブートローダーや、STM32のファームライターはシリアルを要求する。PC一台では開発の効率が悪いので、戸棚の奥に眠っていた大昔のLet'sNoteを引っ張り出した。Pentium133MhzのWindows95時代のものである。ターミナルだけなら十分だ。立ち上げてみて、色々思い出した。こいつはLinuxと、DOS(V7)まで3つのOSが動くようにしてあった。海外のサイトの情報をもとに、liloを細工してPartitionTableを書き換えるという荒技をやって、DOSとWindowsを両立させている。情けないことにLinuxのコマンドを殆ど忘れているのでWindowsのハイパーターミナルでシリアルをテストする。これでPCの画面を切り替えなくてもBeagleBoardを動かすことが出来る。STM32の方は、ファームライブラリをV1(V2は殆ど同じ)からV3に上げないといけない。guideを少しまともに読んでお勉強する。Standardの略で、ARMのCortex-Mファミリーの中だけの話だ。構造的に大きく変わったわけではなさそうだ。直接レジスターを叩くときのライブラリ(core_cm3.h関連)と、構造体を介して動かすソフトのためのライブラリを別に用意したのと、表記上の変更・統一(Atmelと同じようなuint32_tとか、volatileでなく__IO__とか)などが主な変更だ。要するにCortex-Mシリーズの統一したライブラリを目指したもので(ベンダー側のメンテナンスコスト削減)、ユーザーにはたいしたメリットはない。GNU用のスタートアップルーチンが用意されたのが安心と言えば安心である。一気にV3の新しいプロジェクトを立ち上げる気力がなかったので、前からやろうと思っていたprintfの実装をすることにした。<stdio.h>が未定義エラーになっているのも以前から気になっている。それでいて標準ライブラリは、sprintfが問題なく使えている。オリジナルのデモソースは、printfだったが、動かなかったので、sprintfに替えた経緯がある。)にUARTの出力関数を実装すれば動くはずだ。「ねむい」さんのsyscallsのソースもそうなっていた。このソースを参考にコーディングしてみる。こいつがまた思い通り動かない。出力はされるのだがタイミングがおかしい。調べているうち、昔のことを思い出した。昔、UNIXを少しいじっていた頃、標準ストリーム出力が言うことをきかなかったことを思い出す。ストリームは、バッファーリングしているのでデータを残さないで全部を吐き出させるためには何かテクニックがあったはずだ。ウェブに慌てて教えを請う。えー、¥n(ニューライン)がバッファーの区切りなの?それじゃあ、デモソースにある時刻を表示するステートメントの最後が¥r(リターン)では、いつまでたっても表示されない。デモソースのオリジナルは、printfの文法を無視した実装になっている。オリジナルのデモソースのprintfは標準のpirntfで動いていない。その証拠に\n\rが行頭にあり、これでは全部のステートメントが一回づつ遅れる。それに時刻表示が\rで終わっている。これでは1秒毎に表示されず、バッファーが満杯になって始めて全部の秒表示が行われ、最終的に最後の秒表示が出るだけだ。今のソフトがまさしくこうして動いており、何分かに一回、時刻が更新されている。UARTに出すメッセージの行換え文字\rをすべて\nにして行末に移しコンパイルし直す。これで正しくメッセージが表示された。おや、時刻表示が\nによって行を換えて斜めに表示されてしまう。)で、\nがあると\rを追加している。これがそれを防ぐ仕掛けか。時間表示が延々と行を換えて出てくるのは時刻表示らしくない。そこで考え付いたのが、\nを\rに、\rを\nにひっくり返す方法だ。これで、\n\rとやれば、従来どおり行を換えて行頭から出力され、\nだけだと、行頭に来るが、行換えをせず重ね書きをして時刻表示らしくなる。標準ライブラリには、これらを定義する関数か、環境変数があるのだろうが、とりあえずの対策である。簡易RS232Cの制作ではまる(6/13/09)今さらレガシーなRS232Cでもないのだが、COMポートの使用頻度が高くなったきたので、chaNさんの簡易RS232Cインターフェースを作ることにした。USB-UARTがあるから必要ないように思えるが、USBの仮想COMポートは、頻繁にファームを書き直し、リセットしては動かすマイコン相手には、極めて使い勝手が悪い。USBの仮想UARTは、セッションのときだけ存在するまさしく仮想的なもので、どちらかのアプリケーションが終われば無効になる。マイコンのように常にリセットするような相手では、PC側の端末ソフトはその都度、立ち上げなおさなければいけないし、フラッシュローダーも仮想COMポートが生きているように見えても実際にはマイコンだけでなく仮想COMポートもリセットしてから(コネクタの抜き差し)でないとつながらない。ARMのフラッシュローダーを使うようになってUARTを使う機会が増えた。BeagleBoardもブートローダーはシリアル経由だ。ChaNさんのAVRspもシリアルであり、シリアル、UARTの使用頻度は高い。我が家の自作PCはレガシーなCOMポートがついている。いざとなったら16550を使った拡張COMポートインターフェースだってある(古いものなら何でもある。あ、あれはISAバスだったか)。ハードのCOMポートなら端末プログラムを立ち上げておきさえすれば、マイコン側がどういう状態であろうと常に動き出す。フラッシュローダーも端末プログラムを止めればそのまま動く。手始めにSTM32のTTL-UARTをRS232CインターフェースにするChaNさんの簡易RS232CをDSUBソケットに作ることにした。これはインバータICを使った至極簡単な回路である。これで+9V,-9VのRS232CラインがTTLになってしまう魔法のような回路だ。規格に合っていない邪悪な方法だそうだが、他のいくつかのサイトでも動作が確認されておりアマチュアが使う分には折り紙つきだ。ブレッドボードに組み、動きを確認する。作るのに1分もかからない。最初はPCからの送信がうまくいかなかったが、端末のフロー制御をしていないという例のオチに気が付いてジャンパーを飛ばして解決し、ブレッドボードでは何の問題なく稼動した。3.3VのVccなのに5Vの入力パルスが来るのが少し気になるが、これは実装のときに100KΩの抵抗を増やせば良いだろう。今度は基板を小さく切り取ってDSUBの変換基板に実装する。ところがブレッドボードでは苦もなく動いたのに、こいつが言うことを聞かないのである。TTLからの送信はできるのだが、PCからの送信が出来ない。フロー制御はコネクタで処置済みである。オシロまで持ち出した。結果、PCからの送信、マイコンにとって受信側が、送信データを拾って発振を起こしている。配線が近くなったから?まさか。それともインバータの手持ちがなかったので74HCU04というアンバッファータイプを使ったのが原因なのだろうか。Vccを3.3Vにしたので、RS232Cの電圧が高すぎ、ICをこわしてしまったのだろうか(100KΩを200KΩにして3Vまで下げた)。ICを取り替えてみたいが、こういうときに限ってICを半田付けしてしまっている。¥300)を用心のため買う。例の表面実装部品とりはずしの低温半田でインバーターICを取替え(これは確かに楽だ)、組み込みなおす。HC04でも動かない。ブレッドボードでは問題ないのに。思い込みとは恐ろしい。結局、RS232Cを動かすのに3日もかかってしまった。オチは、ここに書くのも恥ずかしい、インバーターの入力ピンと出力ピンの取り違いである。ブレッドボードでは横並びにインバータを使い、実装では配線を短くするため、反対側の回路を使った。ピンナンバー順に入出力が並んでいると頭から思い込んで、片側の回路に入出力を逆につけて動かない、動かない、発振していると悩んでいたのである。データシートは見たが、思い込んでいるときは、こういうものである。はなから自分で納得し図をろくに見ていない。昔、鉄道の単線で、全速力の列車の正面衝突という大事故の原因が、区間にひとつしかないタブレットという交換器の機械が空かない(実際にもう汽車が走っている)のは故障と頭から決め付けて、鍵をはずしてもう一方の列車に渡してしまった駅長さんの話を思い出した。動いたときは、本当に安心した。情けないという自責の気持ちより、これが動かずに終わったらこの先の気持ちの整理をどうしようかと恐れていたのだが、それをしないですんだという安堵感の方が強かった。くだらないことにくよくよする自分が情けなくてまたさらに落ち込むという鬱のスパイラルに陥るときがある。こんなことで一喜一憂しているのだから本当に安い娯楽だ。本式のラインドライバーは違う。フラッシュローダーが動く(6/14/09)手を動かしていると、こういう気持ちの納まらない時の気分転換になる。安全のために買ってあったRS232Cのラインドライバーを実験してみた。DIPではなくあえてSOICのADM3202ARNにしたのは、変換基板に必要部品も乗せてしまおうと言う魂胆である。ICのおまけに、チップコンデンサーが付いている(0.1μF、5×2)。これが、今まで実装したことのある20x12ではなく、もう一段小さい16x08(横1.6ミリ、縦0.8ミリ)だ。これをつけろというらしい。うーむ、変換基板の端子に普通のリード線のコンデンサーをつけるつもりをしていたが、挑戦状を突きつけられた感じだ。これは受けるしかないだろう。写真を見ていただければ良いが、これは面白かった。良い勉強になった、半田ごてをもう少し細いこて先にすればもっと楽だったかもしれない。被害はチップコン1個(ピンセットで強く挟んだ弾みに机から飛びはね行方不明になった)。このへんが手配線の限界だろう。ブレッドボードにDSUBコネクタと一緒に配線してテストする。うむ、配線違いもなく問題なく動く。きれいに+6V,-6VにわかれたRS232Cの信号が出ている。STマイクロのフラッシュローダーはどうだ。こいつは気難しくて簡易RS232Cでは動かなかったのだ。おおお、何の問題もなく認識した。買っておいて良かった。(月)STM32基板のRTCを動かすそれにしてもデバッグは難しい。わかってしまえば、何でこんなことに今まで気づかなかったのだろうというお馬鹿な間違いなのだが、気がつくまでの道のりは決して短くない。この謎解きが面白くて電子工作をやっているようなものだが、今度のSTM32のRTC(リアルタイマークロック)プログラムも結構手こずった。「デバッグは外へ、外へ」などと偉そうなことを常日頃言っているくせに、頭に血が昇るとつい我を忘れてしまう。開発に熱中し、先週、高速化したUSB仮想UARTのモニタープログラムを完成させて意気が上がっている。ウェブでもこの石を使ったCPUボードを時々見かけるようになった。価格もそう高くない(2インチ160x128のカラー液晶付きの評価ボードが¥9000で手に入る)。クロック72Mhzの32ビットプロセッサーだ。ARMコアの中では普及版だそうだが、アマチュアが遊ぶには十分すぎるスペックである。RTCはUARTモニターの開発のときから次の目標に決めてある。バッテリーバックアップ回路を追加したのだ。電池と32.767khzのクリスタルの顔を立ててやらねばならない。RTCはファイルシステムには欲しい機能だし(書き込みの記録)、これが動くと俄然マイコンがプロっぽくなる。STマイクロの提供するライブラリには、RTCのライブラリを使ったデモソースが収録されている。これを使えば簡単に出来るはずだ。Eclipseの新規プロジェクトを作り、そこへソースコード一式を放り込む。このソースはIARなどの開発環境用なので、仮想UARTモニター同様、GNUで必要な、Makefileや、リンカースクリプト、スタートアップルーチンを入れて調整する。Makfileを換えるだけでうまく行くはずだ。必要なライブラリを取捨選択し、ビルドする。殆ど問題なくバイナリーが出来た。しながら、フラッシュローダーにかける。おやあ、赤ランプがついて送れない。ファイルはあるけれど中身は0バイト。これは一体どうしたことだ。elfファイルは60KB以上あるのに。コンパイラーもリンカーもエラーは出ていない。なると何が悪いのか見当がつかない。マップファイルは出来ていたので、良くわからないままこれを調べる。あれ、関数のエントリーがみな同じ値だ。エラーは起きていない。念のため、必要なライブラリの数をMakefileで確かめる。あれえ、stm32f10x_vecter.cが抜けている。デモソースのreadmeには、これを入れろとは書いていない。こいつがないからに違いない。おお、ちゃんとしたhexファイルが出来た。readmeを信じてえらい目にあった(このあと各開発環境のプロジェクトフォルダーにはこのモジュールが入っているのを発見した。GNUのときは注意しないといけない)。ERRORは安心できないことを学ぶ。お膝元のメーカーのデモソースである。バイナリーが出来たので簡単に動くかと思ったが、これが全く動かない。おかしい原因はおおよそ見当がついている。UARTへの出力関数printfが恐らく暴走の原因だ。これを、これまで使っていたsprintfに置き換え、受信関数も自前のものにして再度、実行。おお、やっとメッセージが出た。configured...のメッセージを出したまま、それっきりになる。ロジックを追うと、RTCのセットアップが終わるのをループで待っていて、ここがreadyになっていないようだ。