PSoC1 を仲介にして、3.3V駆動、I2C通信で表示ができるキャラクターLCDモジュールのユニットを作成してみた。

ストロベリーリナックスの 3.3V キャラクターLCDモジュールはお安くて入手性も良いのだけれども、いかんせんちょっと小さいのとバックライトがないのとで見づらいところがある。
バックライト付きの 5V LCDモジュールを 3.3V と I2C で使いたいなあと、制御マイコン付きの基板を作ってみることにした。

回路図、K2CADのパターンファイル、基板のガーバーデータ、PSoCプロジェクトの詰め合わせ。
Download: i2c_lcd_psoc1.zip

Read the rest of this entry »

やっぱりマイコン開発に 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 »

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

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

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

Read the rest of this entry »

以前からちょくちょく出てきている、iruka さん製作の STBEE MINI を使った JTAGアダプター。名称 arm_blaster。

ごらんの通り CNCフライスでプリント基板を作って使っている。
回路図は元のページを見て欲しいのだけれども、単に 4本の GPIO に抵抗を挟んでコネクタにつなぐだけの代物。どう見てもユニバーサル基板で作った方が早いよ！という風情なのだけれども、敢えてこういう小物も CNCフライスで作っていきたい。

できあがったモノの仕上がりが綺麗ってのもあるけれども、今は CAD で書いて CNC で出力というフローに慣れたいからというのが主な理由。
あと、こんなものでも部品代としてみれば安いので数こなしていけばユニバーサル基板を買うよりコストメリットも出てくるはず。それとこれは次回になるだろうけれども、コネクターでユニバーサル基板にそのまま刺さらないような奴を使いたいときにぐぐっと優位性がでてくる。

とかそれらしいこと書いているけれども、実際の所、ワイヤーの皮膜を向いたり溶かしたりして配線する作業が面倒で嫌なんだよ！ヽ(`Д´)ﾉｳﾜｧｧｧﾝ
あとユニバーサル基板を適度なサイズに割るのもめんどい。

ユニバーサル基板だととりあえずで作り始めて作りながらあーでもないこーでもないと設計を変えたりテストしたりするものだけど、CNCだと最初にCADできっちり設計しなければならないのが難点。
いや、それは製作手順としてやった方がいいことなんだけれども。

この程度のもの欲しい人がいるとも思えないけど、K2CADのデータやガーバーやGCODEの詰め合わせ。
Download: armblaster_pcb.zip

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)

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 »

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 にしておく必要がありまする。

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 だけという結果に落ち着いたり。

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 も載っていてまさにそういった用途にお使いくださいといった感じだしなー。

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 だけなのだけれども、それだけのために個人情報を入力してダウンロードするかというのは考えどころ。