« 2009年4月26日 - 2009年5月2日 | トップページ | 2009年5月10日 - 2009年5月16日 »

2009年5月3日 - 2009年5月9日の2件の記事

2009年5月 8日 (金)

STM32のUSB仮想UARTモニター遂に完成

 今年の連休は殆ど外に出かけず、いわゆるCQ-STARMと呼ばれるDWM2008年5月号の付録基板、STM32F103をGNUベースで開発するプロジェクトに没頭していた。こんなに夢中になったのも久しぶりである。やっとのことでUSBの仮想COMポートが実用レベルの域に達した。PCから簡易モニターが開けるのでUARTを通じて開発を進めることが出来る。いやあ今度も大冒険だった。

仮想UARTからの送信データが抜ける(5/4/09)
 STM32のUSB仮想UARTは、とりあえず送受信は出来るようになった。しかし、この雑誌のファーム(蛙がピョン)が使っているUSBへの送信関数は不安定極まりない。特に、連続して送ると前のメッセージを無視して最後の送信メッセージしかPCに届かない。

 受信は出来ているようなので1文字単位のエコーバックは出来るが、ARM側からの連続した送信は全く駄目である。それに受信に関しては不審なことがある。この前、書いたようにデバッグ用に用意されている2文字のコマンドがCD-ROMに入っていたオリジナルのファームに戻してみても、全く機能していないことである。どうもおかしい。

 ソースコードを調べて行ってその原因がわかった。メインループの中で受信バッファーにデータがあるかどうかをバッファーのデータサイズ変数(count_out)で聞いている。受信バッファーは、USBの受信エンドポイントから直接移しているだけでキューイングなどはやっていない。しかもこの変数、count_outは、このループの最後でクリアされている。キーボードの入力はどんなに早くても1/10秒単位である。これでは2文字のデータがUSBのエンドポイントのバッファーに揃うことは絶対にありえない。

 送信がおかしいのは、恐らく送信バッファーで、まだ送っていない前のデータを新しいデータで塗りつぶしているからであろう。USBはホスト(PC側)が完全な主導権を握っており、UARTのときは、ディバイス(ARM)側から送信は、ホストのVCPドライバーからのポーリングで送信するはずで確か、最小でも1ms間隔だったと記憶している。バッファーから正しくデータが送られてバッファーが空にならない限り、次のデータは送れないはずだが、このコードはそういう制御は何もしていない。

 受信の方の不備といい、送信のところといい、どうもこのソースコードの作者は、USBが非同期で沢山のバッファーを通して動いていることを理解しているか疑わしい。困ったことになった。お手本が頼りにならない。加速度センサーのADコンバータが既に動いているし、これをベースにアプリが広げられるという最初の期待はもろくも裏切られた。

 確かにキーボードから「*」の入力で連続した加速度センサーの数値を表示することには成功している。しかし、これは加速度センサーの表示タイミングがUSBの送信間隔よりはるかに遅く、せいぜい10msに一回程度だから、たまたまボロが出なかっただけである。これはオリジナルのSTマイクロのVCPソースからじっくり調べる必要がある。

sprintfは動いたぞ(5/5/09)
 こどもの日の今日は雨。晴れのときは何となく落ち着かないが、雨のときは心置きなくARMマイコンと過ごすことが出来る。このところARMの話題ばかりで、がた老AVR研究所と名前をつけた手前、AVRのことを期待して来られる読者には申し訳ないが、アクセスログを見ていると殆どの読者はキーワード検索で来られるようだ。余り気にすることはないのかもしれない。Sbrk

 それはともかく、何とか動かすためにこのあいだコメントアウトしたsprintfである。書式付の出力関数は、フラッシュが大きくなっているので気楽に使えるし、今後のデバッグの生産性のためにも生き返らせたい。仮想UARTの不具合究明を少しお休みし、こちらの方をやってみることにした。

 まず、この前のウェブの情報には、問題の_sbrkのミニマムコードが掲載されている。真面目にコードを読んでいく。何だ、そんなに難しいことはやっていない。ヒープアドレスのエントリーを要求に応じて上げているだけだ。その間が確保したメモリというわけだ。メモリの解放は考える必要はない。スタックと被るとエラーを出すようになっているが、これも今のところいらないだろう。

 _endという外部変数が気になったが、リンカーが設定するというコメントを信じてソースを追加しコンパイルしてみた。おおー、NO ERRORである。調子に乗って、オリジナルソースのsprintfのコメントの部分をはずしビルドする。これも問題ない。いよいよテストだ。「*」を入れる。やった。やりました。加速度センサーの数字が見事に出力された。オリジナルと全く同じ機能が、GNUベースで実現した。

 STM32で、GNUの標準ライブラリが使えないというのは、このあたりに原因があるのかも知れない。私の場合、リンクエラーが出たので顕在化したが、どこかのライブラリの中でもし何もしない_sbrkのスタブルーチンが用意されてしまっていると動かないことになる。

仮想UARTは本家のSTマイクロのサイトでも紛糾(5/6/09)
 お手本にしようとした雑誌の内蔵ファーム(蛙がピョン)の応用をあきらめて、もとのSTマイクロのVirtualComPort(以後VCP)のデモプログラムで仮想UARTの実装を始めた。内蔵ファームの仮想UARTの部分は、このVCPのソースを殆どそっくり利用していたので、理解が早い。送信バッファーの取り扱いがわかった。最初から書き込まず、足しこんでいる。そうか、これなら内蔵ファームのようにデータは失われない。

 その内蔵ファームについて前回の記事では、その後の情報収集で少し誤解があったようなので訂正しておきたい。2文字コマンドは絶対動かないと書いたのだが、これはGainerプロジェクトの仕様なのだそうだ。キーボードでなく、別のマシンからの入力を想定しているのでバグではない。キーボードから入れるときは、端末プログラムで入力コマンドをカット&ペーストすると動くと言う。

 実際に試してみて動くことを確認した。情報源のサイトでは「変な仕様だなあ」などのコメントがついていたが、同誌の次号6月号3章の記事を読み直して少し謎がとけた。この記事の中で、コマンドがすべてASCIIなのに端末側にわざわざフリーウエアのAcknowrich(アクノリッチ)を要求している理由が全くわからなかったのだが、こういうことだったのである。それなら最初から、そう書いてくれれば混乱することはなかったし、アクノリッチを使うこともなかったように思うのだが。

 それはさておき、STマイクロのVCPデモソースの解析の方である。ここではmain.cとhwconfig.cで、USBの受信バッファーのデータサイズ(count_out)分をUARTへ送り、UARTからのデータは、UARTの受信割込みの度に、USBの送信バッファーに書き足している。USBの送信バッファーはエンドポイントの割込みを処理するusb_endp.cで定期的にハードのパケットレジスターに送信バッファーサイズ(count_in)だけ書き込まれる。いずれも処理のあとにバッファーサイズの値は0にリセットされる。

 問題なさそうである。これを元に鼻歌まじりで、1文字送受信関数、USB_putc、USB_getcを作り、USB_putcを使って、文字列用のUSB_putlineまで用意して、仮想UART超簡易モニターを実装した。STM32の開発ベースになるものである。とりあえずは、入力をエコーバックし、リターンキーでこれまでのデータを送出、0、1、でLEDのOFF/ONという仕様だ。ファームを書き換え、意気揚々とテストに入る。

 と、これが言うことをきかないのである。受信は問題ないが、ホストへの送信が前と同じようにうまくいかない。一文字なら良いが(エコーバックは完全だ)、一気に送るとデータ落ちが激しい。それにおかしなことにデバッグ用のLEDをONするステートメントをメインループからはずすとハングする。???である。

 おかしいな。送信バッファーは64バイトもある。いくら実際のUARTよりはるかに早いタイミングでプログラムからバッファーを書き換えても、USBの割込みが入ってハードのエンドポイントレジスターに書き込むときは、正しいバッファーの内容と、そのサイズを示しているはずだ。現象はあきらかに書き足す処理の時に割込みが入って、サイズとバッファーの内容との不整合が起きているとしか考えられない。バッファー転送とサイズ変更の間で割り込まれないようにしておく必要がある。

 しかし、STM32で割込み禁止をかける方法がわからない。8ビットのAVRと違ってSTM32 の割込み環境は目茶目茶複雑だ。下手にかけると他がおかしくなる。それにLEDのステートメントがないとハングアップするというのも奇怪な話である。

 USBの知識も生半可なので少し勉強し直し、色々いじってみたが改善しない。うーむ、よくわからない。思い余って、このあいだ試して味をしめた生のステートメントをGoogleに投げる方法をやってみた。キーワードは、ユーザーバッファーから実際のエンドポイントにデータを移すSTマイクロ提供のライブラリ関数、UserToPMABufferCopy(...)である。Pmabuf

 すると、また当たったのである。こんどもSTマイクロのフォーラムだ。それも私と全く同じ仮想UARTのデータ抜けで困っている人たちの議論である。3ページ分ある。英語の斜め読みなので、完全に理解したとは言い難いが、UARTが低速のときはUSBがパケットを送るタイミングとぶつからないが、高速になると取りこぼすバグの対処の議論である。

 色々な改善案の出し合いがあって、最終的には、一方がsystickを使った新しいコードを提案してスレッドは終わっている。しかし、このコードはのちほど本人が否定して、問題は解決されていない。STマイクロの対応(発言)はない。去年(2008年4月)の話なのでソースはV1.0ベースだ。これを受けて次のバージョン(V2)でどうなったか、USBライブラリをダウンロードしてみたが、何も変わっていなかった。ただこれはこの関数UserToPMABufferCopyだけの問題ではない。V3のVCPのデモソースは見つけられなかった。

 さて、どうするか、である。割込みを止めようとウェブを探し回ったら、何とユーザーモードでは割込みをペンディングできないことがわかった。うーむ、やっぱり32ビットプロセッサーは難しい。LEDを動かさないと何も動かずハングするとか、count_outなどの外部変数を監視していても変化しないとか、まだわからないことだらけだ。

NOP_PROCESS()ですべてが解決した(5/8/09)
 AVRだと気楽に割込みを止めてアトミックオペレーションに備えることが出来るが、ARMあたりはRTOS(リアルタイムOS)を意識しているので、そう簡単にユーザーレベルで割込みを止められたら確かにおかしくなることはわかる。ただ、今の現象はあきらかに、USBのエンドポイントの送出割込みがバッファー転送中に起きていると思われる現象だ。

  向こうが待ってくれないなら、こちらで待つ(バッファーが0になるのを待つ)ようにしようとしたが、これも出来ない。モニターに使うUARTだから早さは求めない。バッファーサイズが0になるのを待って、1バイトづつ送っても問題ないのだが、whileループで、これを調べても変化しない。ここでループしたままになる。ユーザープログラムからこのバッファーサイズ(正確には変化)が見えないのである。

 別のお手本を探すしかないかと、あきらめ気分になっていたとき、STマイクロのソースを見ていてふと目に留まったものがある。何かのフラグを調べているプロセスでwhileのあとの処理クローズにNOP_Process()という関数が入っている。これは何だろう。コンパイラーの最適オプションでおかしくなるのをさけるためなら、インラインアセンブラのasm("nop")で良いのに何故わざわざ別の関数を呼んでいるのだろう。

 頭の中に何か灯りがともった。何かにおう。これが長年この世界にいた勘かもしれない。もしかしたらもしかするかもしれない。エンドポイントにデータを送る関数USB_Putc()でbuffer_outが0になるまで、このNOP_Process()で待ってみることにしてみた。バッファーを送った直後なら、次のデータ転送の時に割り込まれる可能性は殆どない。ついでにはずすとハングするLEDのステートメントもこの関数にしてみる。だめもとである。あまり期待もせずテストしてみた。

 何と、何と、これが見事に機能したのである。長いメッセージも全くデータ落ちなく出力される。LEDプロセスがなくても問題なく動く。なぜ動くのか理由はわからない。ただ山勘でやってみたのがあたった。一回の転送タイミングで1バイトしか送れない(1msのタイミングで8kbps)が、今はこれで十分である。調整していけばもう少し早くなるだろう。Stm32monitor

 いやあ、嬉しい。世の中がばら色に見える。寝ている女房を起こして喜びを分かち合いたい気分である。STマイクロのフォーラムであれほど紛糾していたのだから、殆どあきらめていた。それが低速とは言え、モニタープログラムが問題なく動いた。鼻が高い。リターンキーで、貯めこんだメッセージを1字も抜けずに表示するし、LEDも0、1のキーで点滅する。満足、満足である。

 今のところ高速化は必要ないが、バッファーをリングバッファーにするか、バッファーを書き換えるのときにUSBの割込みをペンディングする方法が見つかれば、もっと高速に送れる。まあ、これは先の話である。それよりも次はJTAG環境を整備したい。Dfu経由だと一回の書き換えに25クリックもかかる。

| | コメント (2) | トラックバック (0)

2009年5月 4日 (月)

STM32基板のUSB仮想COMポートがGNUで動いた

LPC2388は少し休んでSTM32の方に専念する(4/27/09)
 LPC2388基板を付録にしたインターフェース誌の次号(6月号)が出たので買ってきた。chaNさんが本名で2章にわたって執筆されている。UARTやUSBホストの解説もある。うーむ、みんなやろうとしていたことばかりだ。何か急に道が広くなって歩きやすくなると同時に、生来のへそ曲がりが出て逆に何となく意欲が失せてしまった。

 昔からこうだ。みんなが進んでいく方向についていくのが嫌いで、違う方、変わった方に行きたがる。今度の号でも一番の情報は、LAN&SDカードソケット拡張基板のイーサネット物理層のトランシーバーICの型番がわかったことである。 LAN8187とある。Ws000000

 実は、今度のLPC2388はイーサネットの論理層(MAC層を含む)をサポートしていると知り、ネットでこの物理層のICを探していた。しかし目に付くのは殆どがギガビットイーサのICばかりで、10/100MあたりのICはDigiKeyで見ると流通在庫のない旧製品が多く1個からは売ってくれない。残念ながらLAN8187もDigiKeyでヒットしたが、販売最低個数は800ヶで手が出ない。

 そう、この別売りのLAN&SDカード拡張基板の自作を企んでいる。買えば¥6800だそうだが、今度も、いくら何でも「ぼったくり」だ。SDカードソケット、モジュラージャック(パルストランス付き)、AタイプUSBソケット(これは余計)を合わせても小売価格で\1000しない。それに物理層ICが\500前後としても部品代は¥2000以下、基板を起こす費用が1枚あたりそれくらいかかったとしても、売価がその倍というのはないだろう。秋月なら半分で売る。

 この前の雑誌付録のフリースケールのイーサネットマイコンのときもそうだった。別売りの部品セットの法外な価格に反発して、秋月のモジュラーを無理につけてピンを折り、パルストランスを外付けして動かした(2008/9/9の記事)。今度も恐らく誰かが私と同じようなことをしようとしているに違いない。データシートさえあればやっていることはそう難しくない。外付け部品は発振子だけで、あとは結線するだけだ。いずれ物理(PHY)層ICを手に入れて作ってやる。

 それはともかく、新しい号の雑誌で逆に関心の方向がLPC2388より、去年の雑誌付録STM32基板(Cortex-M3 STM32F103)の方に移ってしまった。32ビットプロセッサーと言ってもこの石は、Thumb2という16ビット命令でしか動かない廉価版だが、せっかくSDカードソケットをつけたのに活用していない。 それにこちらの方が情報が少なく難しそうである。へそ曲がりに加えて、例の中毒だ。出来ないこと、難しいことを克服したときの充実感がたまらない。いつのまにか険しい先の見えない脇道にそれてしまう。

STM32をGNU環境で開発する(4/29/09)
 STM32はこのあいだUARTが動いたが、これは普通のTTL-UARTで、USBを経由していない。このSTM32はUSBがついているのが特長だ。USBインターフェースの勉強のためにもUSBを通してPCとお話がしたい。

 しかしUSBを動かすには、複雑で面倒な設定が必要で自前で作るのは大変だ。ライブラリに頼って開発しないと効率が悪い。このライブラリ(USBLib)やデモプログラムは、雑誌のCD-ROMに他のペリフェラルのライブラリ(FWLib)とともに入っているが、これらのソースはIARやKeilの商用コンパイラーをプラットホームにしていて、GNU向けのソースではない。 仕様は殆ど変わらないはずだが、肝心のMakefileとリンカースクリプトがない。

 それでも、「STM32 gnu」で検索したら結構沢山のサイトが見つかった。探した中で一番簡単そうな、ここのサイトのMakefileとリンカースクリプトを拝借してコンパイルしてみることにした。お手本のソースは雑誌のデモ(蛙が跳ぶやつ)のファームウエアだ。知らなかったが、雑誌付録のCD-ROMにちゃんとソース一式が入っていた。

 しかし、このMakefileはこの前と比較にならないほど複雑でちょっと見ただけでは何をやっているのかよく分からない。ウェブ上のマニュアルと首っ引きで、やっとのことでWINARMからCodeSourcery G++の環境に移し、ソースのコンパイルまではうまくいくようになった。

 はじめはライブラリの構築がうまくいかず途方に暮れた。一部の$で囲まれる変数、$(CFILES)などが置き換わらず、Nullデータになってライブラリが作れない。お手本にしたMakefileはCygwinのUNIXベースのもので、こちらの環境はDOS窓だ。/ではなくて¥(バックスラッシュ)などのセバレータが入るとおかしくなるのかと思ったが、それが原因ではなかった。

 変数に入れるファイル名をひとつだけにするとうまくいったので、DOS窓の環境変数などのバッファーのオーバーフローかと、少しづつ増やしていった。ところが、いくら増やしてもエラーにならない。結局、元の全部を入れても相変わらず正常にライブラリが構築される。直ってしまったのである。???であるが、余り深く詮索するのはやめる。とにかくすべてのソースのコンパイルは、いくつかの警告メッセージがでるもののOKとなった。

 しかし喜んだのも束の間、リンカーで以下のようなメッセージをだして失敗する。f:/gcc/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/lib\
libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text+0x18): undefined reference to `_sbrk'
f:/gcc/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/lib\
libc.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text+0x20): undefined reference to `_write'
f:/gcc/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/lib\
libc.a(lib_a-closer.o): In function `_close_r':
closer.c:(.text+0x18): undefined reference to `_close'

 これは標準Cライブラリの中のエラーだ。ヘッダーファイルと実際のシステムライブラリとがどうも不整合を起こしているようだ。うーむ、やっぱり駄目か。しかし、せっかくここまできてあと少しなのに残念だ。このあたりはビルドのなかでも一番難しいところでこれ以上は手が出ない。ライブラリのリンクではLinuxで散々苦労した。やっぱりウェブと同じWINARMに替えるしかないか。

 殆ど諦めたが、寝る前の最後に頼みのGoogleに、だめもとで上記のメッセージのうち環境に依存しない部分の
libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text+0x18): undefined reference to `_sbrk'
をぶちこんで検索してみた。すると何と該当するサイトが見つかったのである。

 STマイクロのサポートのページで全く同じメッセージを出して立ち往生している人の質問であった。幸いなことに回答が出ている。英語なので今ひとつはっきりしないが、要はsyscalls.cなどのOS用のルーチンを組み込まないでコンパイルすると、それ向けの関数がないのでエラーになる。 syscallを使っていないのならこのエントリのダミールーチン(stub)を作れば良いということである。

   言われるまま、ユーザー関数を入れている適当なファイルhw_config.cに、_sbrk _writeなどの関数を追加する(中ではなにもしない)。祈る気持ちでmakeする。おおお、NO ERRORだ。Makefileどおりelfファイルとhexファイルができた。勢い込んでDfuでファームを書き込む。動かしてみた。順調にVirtualComPortが認識され、LEDが点いた。よーし、動いたぞと、キーボードから入力する。残念。キーボードの反応はない。やれやれやっぱりまだ駄目か。まあ、ゆっくりデバッグしていこう。

遂にBeagle Board RevCを発注してしまった(4/30/09)Ws000001
 前から、目の前のプロジェクトが上手く行かないと新しいリソースに手を出す癖がある。素直に雑誌の環境でコンパイルすれば良いものを、わざわざ茨(いばら)の道を選んでGNUで苦闘している。こういうときが危ない。このあいだのイーサの物理層ICを探したときにDigiKeyに寄って、見るともなくBeagleBoardのページに行ったら、何と在庫が25に減っている。しかも価格は円高でこの前見た価格より\1000以上安い¥16,062だ。

 確かこの前は3桁の在庫があったはずだ。うむむ、こういうものは次のロットは遅れることが多い。よし買ってしまおう。7,500円以上なので2000円もする送料が無料だ。この際、色々な手に入りにくい小物を手に入れるチャンスでもある。フリースケールのイーサネットマイコンのモジュラーはすぐ思いついた。今度のイーサ物理層のICも買っておきたい。しかし、ひとつから買える適当なICがなかなか見つからない。

 買うとなると気がせいてきて、とうとうICが見つからぬまま29日の深夜、モジュラージャック2ヶと合わせて発注のクリックを押してしまった。代金は消費税を入れて¥17,700。いやあ、これで、がた老AVR研究所に遂にハイエンドの組み込みボードが来ることになった。暫くは気分が高揚して何も手がつかない。このあいだ6年乗った車を乗り換えたが、これほどの感動はなかった。

 恐らく品物が届いても、簡単にはすぐ手が出せないだろうが、可能性だけはやたらに広がった。FPGAと云い、趣味の世界でこれだけ興奮できるというのも幸せなことである。モニターをこいつのために新調する必要がある。ビデオ出力がデジタルだからだ。現在のメインモニターは、もう10年以上使っている古い17インチブラウン管モニターでディジタル端子などついていない。そのかわり今や珍しいケーブル5本のRGBコンポーネント端子がついている(接続はもうひとつのアナログ15ピンの方だが)。しかし目に優しく長く使っても疲れない。とても愛用している。このあと30万近く出して買ったナナオの液晶モニターにはDVI端子がついているが、これは娘にやってしまった。

 発注してしまってから、イーサ物理層ICのMicrel社のKSZ8721BLがDigiKeyで1個売りしているのが見つかった。0.5ミリピッチのLQFPで48ピン。変換基板で対応可能である。データシートも完全にある。価格は¥497。しかし、後の祭りである。

GNU環境でやっと仮想COMポートが動いた(5/3/09)
 STM32開発のその後の進展は、はかばかしくない。LEDの点灯までは動いたが、USBからのレスポンスは全くないままだ。PC側からはVirtualComPortとしてポートが見えるのでUSBの初期化はうまくいっていると思われるが、その後が進まない。

 ソースは「蛙がピョン」のオリジナルのままである。「*」を入れると3軸の加速度を表示するはずだが、全く表示しない。ソースの中にデバッグ用と見られるいくつかのコマンドがあるので(「?*」でバージョン表示、「Q*」でリセットなど)入れてみるが、それにも反応がない。main.cに手を入れて無条件でメッセージをUSBに出力するステートメントを加えたが、反応なし。どうもLEDを点灯したあと暴走している感じだ。

 ここでJTAGインターフェースが使えれば、もう言うことなしなのだが、デバッガーの設定はプロジェクト単位にする必要があり、今のところは全く手が出ない。たとえ入れても何をデバッグしているのかわからないだろう。頼みはやっぱりウェブによる先人たちの経験報告である。

 Makefileを貰ったサイトでは、動いているように書かれているが、同じWINARMを使って仮想UARTを動かそうとしているサイトではGNUでは動かないというレポートが多い。あるサイトで「STM32はThumb2命令で動くので、ARM命令で作った標準ライブラリは駄目」とあるのを見て、慌ててCodeSourceryのディレクトリチェーンから、それらしいライブラリパスを指定して(gcc/arm-none-eabi/libからgcc/arm-none-eabi/lib/thumb2)みるが、前と同じ。

 やっぱり、リンクエラーをなくすためにライブラリのスタブルーチンを入れたことが原因だろうか。それに関連して、断片的な記述で良くわからないが、sprintfを入れようとしてsyscalls.cを要求され開発をあきらめたというこの記事がどうも気にかかる。そういえばこのあいだのスタブルーチンの説明にも、syscallsを作るとか何かという話があったことを思い出した。

 念のため、ターゲットのコードを見てみる。何と、sprintfが加速度を表示するために使われているではないか。もしかしたらこれが原因かもしれない。もう一度、スタブルーチンを入れろと言った記事を詳しく読み直す。「sprintfは、一時メモリをmallocで取るので、これを使うときは、_sbrkだけはまともに書け」とあるではないか。これだ。_sbrkのエントリーは今度のダミールーチンに入っていて何もしていない。これに違いない。

 正しい作り方が良くわからないので、とりあえずこのsprintfの部分をコメントアウトしてmain.cを適当に作り替え(キー入力をループバック)、ビルドし直す。今度は少し動くような予感がする。hexファイルをdfuファイルに変換し(結構面倒だ)、Dfuローダーで書き込む。ピンを差し替え(早くJTAGにしよう)、USBソケットを抜き差しし(うーむ気があせる)、PCのTeraTermを起動させ、仮想COMポートを選ぶ。

 勘が見事に当たった。TeraTermからは文字化けしているが連続して文字が出てくる。思ったようには出力されていないが、始めて仮想COMポートが動いた瞬間だ。いやあ嬉しい。何度も書いているが、この快感がたまらない。いや、やっぱり相当中毒が進んでいるか。

 行末のNULLキャラクターを調整して、とりあえずキーボードからの入力を忠実にエコーバックする仮想端末が完成した。まだ、USBソケットを抜き差しすると端末がCOMポートを認めなくなったり、最初のウェルカムメッセージが想定どおり出ないなどの不具合は残っているが、これでSTM32の開発環境は大きく前進した。端末からターゲットの状況が手に取るようにわかるモニター機能は、これからの機能の開発には欠かせないからだ。

| | コメント (5) | トラックバック (0)

« 2009年4月26日 - 2009年5月2日 | トップページ | 2009年5月10日 - 2009年5月16日 »