posted by rerofumi

2011/7/31 日曜日 17:32:21

以前から書いている様に CNCフライスを使ったプリント基板作成で一つの目標が 0.5mm ピッチのフラットパッケージ部品を使えることにある。
QFP で言うとだいたい 48Pin から 144Pin あたりがそのあたりのピッチ幅なのだが、この 0.5mm ピッチが自作できると一気に工作の幅が広がる。幅というより夢かもしれない、実際は配線しきれないだろうし。

0.5mm ピッチパッケージの手習いとして安いチップから挑んでいこうと STM32F100 の 48Pin QFP を購入した。1個あたり 310円の Cortex-M3(ARM)マイコン。USBとか気の利いた周辺機器はついていないけれども、ROM64kb/RAM8kb のARMマイコンがこの値段で買えるのは魅力。
ちょっとしたマイコン工作にこれが使えるとおいしいんじゃないかと思っていた次第。
意のままに実装するために、0.5mmピッチ基板の作成は必須なのですよ。

まずはテストボードでも作ってみるべと適当に回路図引き。

基板設計。
前回試しで導入した2枚基板貼り合わせによる簡易二層配線を本格的に実装するため最初から二層で設計していく。さすがに二層でないと配線できないわ。

何度も何度もトライしたり設計を手直ししたりして一組の基板が完成。
流石に 0.5mm ピッチともなると精度が必要で CNCフライスの操作やメンテナンスといったエンジニアリングスキルも必要になってくるあたり。
ずっと基板を作り続けてきたおかげでずいぶんとスキルも上がり精度も向上した。ここに来てようやく 0.5mm ピッチに挑めるようになったという感じ。昔の基板を見返すと精度が違うわというのがわかる。
直角配線もそろそろやめたいのだけれども、CNCフライスで加工する分には斜めを含めない方がやりやすかったりするのよね。

0.5mm ピッチを作るという目標としては大成功。無事 STM32 を実装できた。

スルーピンによる二層配線も特に問題なさそう。
これくらいの規模なら作れるという自信が持てた。

Download: stm32F100_test1.zip
今回の回路図とK2CADファイルとgerverファイルの詰め合わせ。

基板ができたぞバンザーイなのはいいけれども、実はまだ動作確認をしていない。
適当に幅のあるサイズで作ったらブレッドボードにもうまくのらなくてどうしようとかそんなあたりも。ブレッドボード2枚で隙間開けつつテストボードでブリッジさせるしかないかな。
気が向いたらJTAGの動作確認したり、テストコード書いたりしたいのだけれどもなんせ目的が「基板を作る」ことなのでこの時点で満足してしまっていたり。
絶対改修なしでは動きださないよなあと思いつつ。

posted by rerofumi

2011/3/21 月曜日 3:10:38

やっぱりマイコン開発に LCDモジュールはつきもの。
初期化が若干面倒なので制御処理の初歩にちょうど良いし、表示装置というのはなんだかそれだけでカッコイイ。それに色々数値を表示することで、デバッグ作業が楽になるというもの。
一般的な HD44780 コンパチな LCDモジュールは 5V 駆動だったりする。だけれども最近のマイコンは 3.3V 駆動のものが多くなり STM32 も 2～3.6V ラインである。まあ、液晶駆動用に 5V ラインがあれば信号線は 3.3V でも動作するし、STBee は 5V のラインもあるからその組みあわせでなんとか動作させることができちゃったりもする。
しかしまあ、今後の主流が 3.3V だというのならそれに慣れておくのも良かろうと、3.3V 駆動で有名なストロベリーリナックスの I2C LCD 表示モジュールを用意した。3.3V ってだけじゃなくて I2C でもあるので信号線が少なくて済むというメリットもある。
3.3V 液晶モジュールはストロベリーリナックスだけでなく、共立電子からも買える様になっているので徐々に入手しやすくなってきている感がある。

STM32 で I2C を使ってみようというのは peripheral 使用のトレーニングとしては割と面倒な部類に入るかもしれない。
I2C のサンプルコードは見かけるのだが

    while(!I2C_CheckEvent(I2C2, I2C_EVENT_MASTER_MODE_SELECT));

などとポーリングで完了待ちをしていたりしていささかよろしくない。
外部通信は存分に遅い処理なのでその間ループでブロックして待つというのは無駄な処理と時間を費やす事になる。
そこで、割り込みと FreeRTOS のタスクを利用してできるだけ無駄な負荷がかからない I2C LCD 表示ルーチンを目指してみた。

少々複雑なれどタスクとキューと割り込みの関係図。

ソースコード
Download: fumi2_stbee_project-0.3.0.zip

Read the rest of this entry »

posted by rerofumi

2011/3/13 日曜日 17:29:11

STBee でLEDチカチカやってみました、第二弾。いつまでＬチカやってんじゃいと思わずお付き合いくださいまし。
上の動画を見て貰った方が早いのだけれども、今回は 2つのLEDがそれぞれ異なる周期で非同期にチカチカしている。これは FreeRTOS によってそれぞれ別のタスクとして動作しているという成果によるもの。

今回は開発ソースツリーに FreeRTOS を含めたというお話。
STBee を使った電子工作プロジェクトの開発環境を整備するというシリーズも目標としていたところを一通り準備し終えたということで、これで一応の完結となる。

ソースコード。
Download: fumi2_stbee_project-0.2.0.zip

Read the rest of this entry »

posted by rerofumi

2011/3/9 水曜日 1:22:34

toolchain スクリプトの更新。 Ver.0.0.3

binutil-2.21 の gas で、SVC ニーモニックが使えないというバグがあるようなので、binutil の version を 2.20.1 に引き下げたもの。

Download: fumi2_cortexM3_toolchain-0.0.3.tar.gz (4KB)

おまけの cygwin binary
Download: cortexM3_gcc_toolchain.tgz (77MB)

posted by rerofumi

2011/2/27 日曜日 17:59:48

LEDチカチカはいいね、リリンの生んだ電子工作の極みだよ。

STBee でLEDチカチカやってみました。というんじゃなくて最低限のビルドプロジェクトを構成するお話。

ARM系のクロスコンパイラがあればそれだけで開発ができるという話ではなく、割り込みベクタにスタートアップ、周辺回路のライブラリなどを用意する必要がある。
ストロベリーリナックスで配布している STBee 用のサンプルプロジェクトが一通りそろっていて参考になる。make 一発で STBee 上の LEDチカチカがビルドできるので、これをベースに自分用のプロジェクトを作るのが手軽ではある。しかし、Makefile がお世辞にも綺麗と言えないのと AVR 用の使い回しなので不満も残るところがあったりする。
今回の目的は、自分の手で同等品を全てそろえることでスタートアップ構成を理解したいというのと、自分にとって使いやすい Rakefile を構築しようというところにある。

今回の成果、ビルド用ソースコードツリー。
Download: fumi2_stbee_project-0.1.0.zip
main.c のLEDチカチカ部分はストロベリーリナックスのモノをほぼそのままです。

Read the rest of this entry »

posted by rerofumi

15:34:59

OpenOCD で JTAG ダウンロードができるようになったといっても毎回 gdb サーバーを起動して gdb からバイナリを流し込むのも面倒くさいもの。
Makefile(Rakefile) やコマンドラインから一発でフラッシュを書き込めないものか。

OpenOCD にはフラッシュを読み書き消去する基本的な機能が備わっている。
単純な機能のダウンロードケーブルとして使うにはこれで十分だったりする。
このコマンドは OpenOCD が起動している時に port 4444 (標準時)に telnet アクセスして打ち込めば使えるが、起動時にコマンドラインとして与えることもできる。

毎回コマンドを入力するのも大変なのでコンフィグファイルに書いておくのが便利。
このへん参考記事がいくつか見つかるので、そのうちの一つのものを参考にコピペする。
—–

proc flash_program {ELF_FILENAME} {
halt
flash probe 0
flash write_image erase $ELF_FILENAME
echo "flash program complete. reset and run"
resume
reset run
exit
}

—–
これをコンフィグファイルに書いておく。

それを使いやすくシェルスクリプトにまとめて、書き込みコマンドを作成する。
—–

#/bin/sh
openocd.exe -f (コンフィグを置いたパス)/armblaster_stm32.cfg -c "flash_program $1"

—–
これに armblaster_flash などと名前をつけておくと使いやすい。

これで書き込み＆実行確認がやりやすくなった。

※注意？
そういえばこの方法だとフラッシュイレースの範囲をちゃんと指定していないから DSU が書き込まれている 0x08000000 – 0x08002fff の範囲も書きつぶしてしまうのでした。
DSU を消したくない人やバックアップをまだ取っていない人はご注意を。
それ故にダウンロードするプログラムの先頭アドレスを 0x08000000 にしておく必要がありまする。

posted by rerofumi

2011/2/26 土曜日 20:12:13

STBee とその開発に使えるJTAGケーブルの実際。
iruka さん製作の STBEE MINI を使った JTAGアダプター。

STBee Mini もお安いしあっという間に作れるし、ファームも DSUe で書き込めるのでもうこれでいいんじゃね的なソリューション。
コマンドラインベースだけれども、シリアルライト機能の応用として AVRライターや PIC18Fライターも用意されているのでパワーユーザーにはおいしい感じである。

若干遅めではあるものの、OpenOCD 経由の利用も、gdb でのデバッグもできた。
個人的にはこれで十分かな。

OpenOCD とそれ用の HID コントローラーは用意されているバイナリを使うことになるんだけれども、それが今のところ Windows のみというのがたぶん最大の条件。
HID 部分は libusb じゃなくて Windows のデバイスを直接 Open しているので、他の OS に持って行くには libusb への移植作業が必要そう。

MaxOSX でも使えたらうれしいかもと思って調べ始めた JTAG ケーブルだったが、結局安定して使える環境が Windows だけという結果に落ち着いたり。

posted by rerofumi

19:52:09

STBee とその開発に使えるJTAGケーブルの実際。
USB Blaster もどきで OpenOCD がどれくらい使えるか。

OpenOCD には ALTERA のダウンロードケーブルである USB Blaster やその互換品を JTAG ケーブルとして使うというオプションがある。
OpenOCD はパラレルポート(が使えた過去の時代)や FT2232ベースのJTAGケーブルを使うことを想定されている。だが MacOSX では FT2232 のドライバーだといまいちな場面があるらしく使いづらいとの声を聞く。
そこで浮上してくるのが USB Blaster 互換ケーブルの使用である。

そもそも、OpenOCD が難しいのはなぜかというと USB 接続デバイスを扱うからということに他ならない。デバイスの問題は結構大きいのだけれども、それは Windows, MacOSX、Linux のそれぞれでデバイスモデルが異なるところにある。なのでオープンソースで開発を固めようとしても、どうしてもこのターゲットとの接続部分がいまくいかないものなのである。
libusb はそういった機種間の proxy となり一つの stub を提供してくれるのだが、Windows では専用の USB ドライバをインストールする必要があるとか inf を作成しないとインストールできないとか色々とあったり、すんなりとは行かなかったりする。MacOSXと Linux は libusb で割と問題無くいけそうに見えるなあ。
そういう意味でダウンロードポートを USART(シリアル接続)のみに絞った Arduino の設計は正解なのだよね。

さて、USB Blaster もどきを使って OpenOCD を使う実験だけれども、Windows 上では早々に諦めた(w。
Windows だと 32bit と 64bit のドライバーって異なっているので、libusb-win のドライバーも二種類存在している。我が家は Win7 64bit を使っているので、64bit の方をインストールすることになる。かたや Cygwin は 32bitなので libusb はバイナリも付いてくるものの 32bit 版しかない。
このへんに食い違いがあるのかどうかよく分からないのだけれども、うまいこと使えなかった。原因究明するにも、準備が面倒な段階でもういいやと投げてしまった次第。

MacOSX と Linux での OpenOCD ビルドはそんなに難しくはない。
libusb, libusb-compat, libftdi, openocd といった順番でビルドしていけば良い。
libusb は Linux ディストリビューションに入ってることが多いので、devパッケージだけ用意すれば後は libftdi, openocd のインストールで良い。

そんなこんなで OpenOCD が用意できて MacOSX と Linux はこれでばっちりだぜと思っていたのだけれどもそうはうまくはいかないのでした。

ターゲットと接続して scan_chain とか難なくできるから大丈夫かと思っていたのだけれども、gdb から操作しているとやたら遅かったり失敗したりする。どうも通信がうまくできていないような印象。
先達の記事にも OpenOCD で USB-Blaster はイマイチと書いてあったりするので深追いしないことにした。

OpenOCD を使うのであれば素直に FT2232 系の JTAG ケーブルを購入するのが良さそうである。
ストロベリーリナックスの FT2232H モジュールとか EEPROM も載っていてまさにそういった用途にお使いくださいといった感じだしなー。

posted by rerofumi

2011/2/22 火曜日 1:47:29

STBee とその開発に使えるJTAGケーブルの実際。
まずは STM 純正の ST-Link のお話。

これ自体 2500円ちょいで買えるので、開発ツールはこれ一本で完璧なんじゃね？と思われるのだけれども、本当にオープンソース周りで開発を固めようとすると「ドライバー等がオープンじゃない」という問題がある。一番大きな影響は MacOSX や Linux で利用するすべがなさそうだ、という所に尽きるだろう。
Windows だけで良いよといった場合は無償環境でそこそこはいけるので、なにができるのかを記しておく。

■ ファームのアップデート
ST-Link を入手したらまずはファームウェアのアップデートを行う。
STMicro のサイトに行って ST-Link Upgrade をダウンロードする。

すると案の定古いバージョンだからアップデートするように催促されるのでアップデートしておこう。
ここで、最新のファームウェアにしておかないと後述する Atollic のデバッグプロキシが動作しないことがある。地味にひっかかるポイント。

■ AT-Link Utility
STMicro のサイトに AT-Link 用のアプリケーションとして AT-Link Utility が提供されている。もちろん無償。

これを使うと ST-Link を JTAGケーブルとして STM32 のメモリ空間がダンプできる。
このダンプされているメモリ空間に対し、バイナリデータのアップロードや、ダウンロード、およびフラッシュメモリのイレースを行うこともできる。つまり基本的なダウンロード作業は ST-Link と ST-Link Utility で一通りできるのだ。
フラッシュメモリの吸い上げもできるのが嬉しいところ。STBeeユーザーは、これを使って DFUe ファームウェアをバックアップしておくと、書きつぶしちゃった後にいつでも復活できるようになるよ。

Reset/Run/Halt といった実行だけでなく、レジスタも見れてプログラムカウンタ単位のステップ実行もできるので、バイナリダンプを見て命令を脳内デコードできる人ならこれだけでデバッグできるかもしれない。

とまあ、ソースコードデバッグを考えなければ ST-Link と無償提供の ST-Link Utility でダウンロード＆実行はできてしまう。
Windows ユーザーであれば持っていても良いケーブルかもしれない。

■ デバッグ環境
ARM系列を JTAG ケーブルでソースコードデバッグするとき、hobbyユーザーとしては GDB+OpenOCDが鉄板というか他があまりないわけなのだが、ST-Link がオープンじゃないっぽいので OpenOCD が使えないらしい。
デバッグをするには IAR, KEIL, Atollic といったプロユースの有料開発環境には ST-Link 用のドライバーとそれを利用する GDB Server が付いてくる。
しかしそれらはプロ用と称すだけあってお値段数十万円だったり、hobby用の廉価版がなかったりといった問題がある。一応、無料利用できる制限版があるのだけれども、IARとKEILは出力バイナリにサイズ制限があったりする。
Atollic TrueSTUDIO は無料体験できる Lite版でもサイズ制限がなく、デバッグもできるので多くの人が使っているようだ。

Eclips ベースの IDE 製品なのでこういった環境が欲しい人は ST-Link とセットで使えば、完全なゴールとなろう。
ただし Lite版には以下の制限がある。
・事ある毎に「Pro版にアップグレードしましょう」というダイアログが出てきて 3秒待たされる
・ダウンロードする際登録したメールアドレスに「あなたの業種はなんですか？Pro版を購入しませんか？」といった旨のアンケートメールが届く
それが気にならないなら悪くない選択だろう。

さて、Atollic TrueSTUDIO をインストールすると、ST-Link GDB server というコマンドラインプログラムが存在している事に気がつく。

これがまさに GDB Server そのもので、True STUDIO は裏でこれを起動してデバッグを行っている。ST-Link へ続く GDB server なのでこれさえあれば、別個に用意した ARMクロス開発用の GDB でデバッグをすることができる。

実際にコマンドライン上での GDB でデバッグできることはもちろん、Meadow などの Emacs をつかって GUD ソースコードデバッグを行うことができる。
先にビルドしておいた Tool chain で、コンパイルからデバッグまで一通りできることが確認された。

なので個人的に欲しいのは Atollic TrueSTUDIO の ST-Link GDB server だけなのだけれども、それだけのために個人情報を入力してダウンロードするかというのは考えどころ。

posted by rerofumi

2011/2/13 日曜日 21:44:16

STBee には DFU (USB Device Firmware Upgrade) という USB 標準規格なファームウェア書き換えのブートローダが乗っており、Windows PC と USB 接続するだけでユーザーが作成したプログラムのダウンロードと実行ができるようになっている。
このマイコンボードを買うだけでマイコン開発ができるということでもあり、とてもお手軽なマイコン工作環境を提供してくれている。

通常ならばその恩恵に預かっていれば良いのだけれども、ちと深いことをやろうとするとやっぱり JTAG ケーブルが欲しくなってくるところ。
DFU だけだと不満な点というのはだいたい次の様なところ。

• USB DFU のドライバーインストールが必要になる (ST社製)
• ドライバーと転送ソフトが Windows でしかない
• ダウンロードのみでデバッグまではできない(スタブを乗せれば手はあるけど)
• ブートローダをつぶしちゃうと利用できなくなる
• 自分でチップ買って作成した時はJTAGでなんとかしないとならない

そういった将来的な所も考えて JTAG ケーブルによる開発環境も用意しておいた方がよさそう、と思った。

ARM 開発での安価な JTAG ケーブルというと、OLIMEX の ARM-USB-OCD が鉄板な感じ。
中身は FT2232 なので互換機の製作もできなくないし、OpenOCD を使うなら JTAG ケーブルはシンプルにできるというもの。
7000円とか 9800円とか開発機材としては安いんだけれども、今回はなんとなく OLIMEX のこいつを使わないでできる方法を探してみた。ARM-USB-OCD を回避しているのには特に深い意味は無いですが。

■ ST-LINK

ST純正のデバッガ＆プログラムケーブル。
2700円ほどと大変お安い。STBee を買った時に、ブートローダの保存＆復活のために買っておいたもの。
これがあれば十分じゃんという意見もあるけれどもね。
基本的にデバッグには IAR, Keil, Atollic といった商用開発環境(hobby用は存在しない)が必要でドライバーもオープンじゃないので OpenOCD が使えない。Atollic lite が無料で使えるのでその上で開発を完結させるつもりならばそんなに問題は無い。
詳細についてはあとで書く。

■ arm_blaster

iruka さん製作の STBEE MINI を使った JTAGアダプター。
HID なのでドライバ要らずなのがステキ。
OpenOCD は独自のパッチをあてて利用する形だけれども、Windows版のソース＆バイナリもあるのでそれを利用すれば容易。

■ USB-Blaster もどき

以前作ってあった PIC18F2550 使用の USB-Blaster もどき。ALTERA のダウンロードケーブルとして使えている。
OpenOCD 0.4.0 では多少微妙なれど USB-Blaster をサポートするオプションが付いている。これを利用すると、この USB-Blaster もどきも OK なはず。

■ つづく
取り急ぎで上にある 3種類の JTAGケーブルを使ってのフラッシュ書き込みと GDB からの接続を確認済み。
もうちょっと環境の広がりを検討するので、ちょびちょびと報告していく予定。

基本的にコマンドラインと手書き Makefile で扱えるように検討していくのが目的。
必要なときに gdb をコマンドラインから叩いて扱ったりするような人向け。