ATmega128とSTM32の速度比較
テストテクノロジーのBTC068基盤から、DWM５月号付録のCQ-STARM基盤への移植作業がだいぶ出来上がってきました。とりあえず２足で歩く程度の機能は動作しています。
移植作業を開始する前にBTC068基盤で各処理にどれだけ時間を要しているのかの計測を行いました。2008/05/20の日記参照
そして３ヵ月後の今日（長かった・・・）、CQ-STARM基盤でも同じ処理部の計測を行いましたので、報告します。
処理１：センサ読み込み＋次ポーズ選択＋逆運動学制御
BTC068・・・・・・・３．０ｍｓ
CQ-STARM・・・・０．８ｍｓ
処理２：サーボ制御（８個のI/Oポートを制御）
BTC068・・・・・・・２５μs
CQ-STARM・・・・１０μs
劇的なスピードアップです。
処理１はもともと標準の三角関数などを使わないで高速化していた処理なので、あまり期待していなかったのですが、３倍以上のスピードアップでした。精度優先ってことで標準の三角関数に戻そうと考えていますが、どの程度時間がかかるのかが興味深いところです。
処理2はI/Oポートの制御ですが、こちらも良い結果でした。サーボを増やす予定ですが、余裕そうです。
ATmega128とARMCortexM3（STM32）では比較対象が悪いのかもしれませんが、苦労して移植した甲斐がありました。
移植作業を開始する前にBTC068基盤で各処理にどれだけ時間を要しているのかの計測を行いました。2008/05/20の日記参照
そして３ヵ月後の今日（長かった・・・）、CQ-STARM基盤でも同じ処理部の計測を行いましたので、報告します。
処理１：センサ読み込み＋次ポーズ選択＋逆運動学制御
BTC068・・・・・・・３．０ｍｓ
CQ-STARM・・・・０．８ｍｓ
処理２：サーボ制御（８個のI/Oポートを制御）
BTC068・・・・・・・２５μs
CQ-STARM・・・・１０μs
劇的なスピードアップです。
処理１はもともと標準の三角関数などを使わないで高速化していた処理なので、あまり期待していなかったのですが、３倍以上のスピードアップでした。精度優先ってことで標準の三角関数に戻そうと考えていますが、どの程度時間がかかるのかが興味深いところです。
処理2はI/Oポートの制御ですが、こちらも良い結果でした。サーボを増やす予定ですが、余裕そうです。
ATmega128とARMCortexM3（STM32）では比較対象が悪いのかもしれませんが、苦労して移植した甲斐がありました。
CQ-STARMへの移植作業 進捗状況
CQ-STARM基盤へのプログラム移植作業を行っています。
最初はCYGWINで開発環境を構築しようとしていたのですが、やっぱりCodeSourceryという環境で開発を行うことにしました。
理由は、CYGWINでSTのライブラリを使う方法が分からなかったからです。私自身がmakeファイルとかに弱いので、自力でSTのライブラリを使えるように出来ませんでした・・・なさけない。
ライブラリを使うと、サンプルをまねるだけで意外と動いたりするので、細かいところまで調べなくても動いてしまうと言うメリットと、ちょっと動かないと調査に時間がかかってしまうと言うデメリットがあります。
とりあえずは、サーボを動かすところまで動作確認が終わっていますが、なんでそのAPIを呼ぶ必要があるのか理解できていない部分も沢山あります。かっこよく言えばブラックボックスとして扱っているわけで作業効率が上がっているのですが、結果オーライ的な作業ともいえます。
HITECサーボのHMIプロトコルはCQ-STARMだとレベル変換等なしで通信できることが確認できたのでちょっとうれしかったです。
あとは、AD変換とかPWM出力とかSPIとかをクリアできたら、ほぼ移植完成かな？？？
あと少しだ。がんばれ、自分。
つまらない移植作業はとっても作業効率が悪いです。集中力が続きません・・・
最初はCYGWINで開発環境を構築しようとしていたのですが、やっぱりCodeSourceryという環境で開発を行うことにしました。
理由は、CYGWINでSTのライブラリを使う方法が分からなかったからです。私自身がmakeファイルとかに弱いので、自力でSTのライブラリを使えるように出来ませんでした・・・なさけない。
ライブラリを使うと、サンプルをまねるだけで意外と動いたりするので、細かいところまで調べなくても動いてしまうと言うメリットと、ちょっと動かないと調査に時間がかかってしまうと言うデメリットがあります。
とりあえずは、サーボを動かすところまで動作確認が終わっていますが、なんでそのAPIを呼ぶ必要があるのか理解できていない部分も沢山あります。かっこよく言えばブラックボックスとして扱っているわけで作業効率が上がっているのですが、結果オーライ的な作業ともいえます。
HITECサーボのHMIプロトコルはCQ-STARMだとレベル変換等なしで通信できることが確認できたのでちょっとうれしかったです。
あとは、AD変換とかPWM出力とかSPIとかをクリアできたら、ほぼ移植完成かな？？？
あと少しだ。がんばれ、自分。
つまらない移植作業はとっても作業効率が悪いです。集中力が続きません・・・
CQ-STARMに２３２Cからプログラムを書き込む
DWM５月号付録の基盤はCQ-STARMと言うらしいです。
CQ-STARMを勉強中です。
今日は、CQ-STARMで６月号第４章のサンプルプログラムを入れて動作確認をしました。
このサンプルプログラムはUSART１を使ってPCと通信をするプログラムなのですが、CQ-STARMにはRS232CインタフェースICが付いておりません。そのままではPCと２３２Cで通信できないのです。仕方が無いのでADM3202と言うICをお昼ごろ購入してきました。それをDWMに載っている拡張ベースボードの回路図を参考にして結線し、ついでにCQ-STARMの電源も電源端子から取るように結線しました。CQ-STARMはUSBから電源を取ることも出来るのですが、ROBOTに乗せることを考えると電源端子から電源を供給する必要があります。電源端子から電源を供給する場合はUSBからの電源を遮断する必要があります。R7の０Ω抵抗を取り除くのを忘れないように。
とりあえず、サンプルプログラムは動きました。
しかし、CQ-STARMにプログラムを書き込むのはUSBで、デバックやモーションプロセッサとのやり取りはRS232Cでは、２本も線をつなぐ必要があり使いにくいのです。デバックやモープロとのやり取りをUSBでやればよいのですが、いまいちプログラムの作り方がわかりませんでした。となると、プログラムの書き込みを２３２Cでやる方向で解決しようと思います。
私はマイコンはど素人なので、自己責任でお願いします。
まずはUSBダウンローダの仕組みですが、
CQ-STARMは０ｘ８００００００番地から０ｘ８００３０００番地にUSB用のUSBダウンローダプログラムが入っています。そしてUSBダウンローダプログラムを使って０ｘ８００３０００番地からユーザープログラムを書き込んでいます。CQ-STARMのジャンパJ６（実際はPB9）をショートさせると、マイコンは０ｘ８００００００番地から動作するのでUSBダウンローダが起動し、ショートさせないとマイコンは０ｘ８００３０００番地から動作するのでユーザプログラムが起動します。（推測ですが、USBダウンローダがPB9がLOWかHIGHかで、USBダウンローダを起動するかユーザプログラムを起動するかを切り分けているのだと思われます。）
ですから、間違って０ｘ８００００００番地にユーザプログラムを書き込んでしまうとUSBダウンローダが消えてしまうのでUSBでのプログラム書き込みは出来なくなってしまうのです。怖い怖い・・・
次に２３２Cダウンローダの仕組みですが、
CQ-STARMは０ｘ１FFFF000番地から２３２C用の２３２Cダウンローダプログラムが入っています。２３２Cダウンローダプログラムは０ｘ８００００００番地からユーザプログラムを書き込んでいます。（正確には書き込む開始番地はmemory_thumb.defで指定します）CQ-STARMのBOOT０（１１番ピン）をHIGHに短絡させるとマイコンは０ｘ１FFF000番地から動作するので２３２Cダウンローダプログラムが起動し、短絡させないとマイコンは０ｘ８００００００番地から動作するのでユーザプログラムが起動します。
これで、USB経由でのプログラム書き込みはできなくなりますが、２３２C経由で書き込めますので、CQ-STARMとPC間の線は一本ですみます。すっきり。
さらにUSBダウンローダプログラム分の１２KBをユーザプログラム領域として使用できるのでちょっと嬉しいです。さらに、２３２Cダウンローダではs19形式のファイルを扱えるのでわざわざDFU形式に変換する手間が省けてかなり嬉しいです。
２３２Cダウンローダプログラムでプログラムを書き込むときにPC側で使用するプログラムはFlash loader demonstratorと言います。
通信速度は57600BPS EvenParityでやってみたら問題なく動作しました。
サンプルプログラムは０ｘ８００３０００番地から書き込む記述になっているので、memory_thumb.defファイルを修正して０ｘ８００００００番地から書き込むように変更しました。（４行目）
2008/07/20 追加
割り込みアドレスのＢＡＳＥも変更の必要がありました。
gcc_sample.cの以下の行を修正してください。
#define __NVIC_VTOR_VAL 0x00003000
を
#define __NVIC_VTOR_VAL 0x00000000
に変更。
CQ-STARMを勉強中です。
今日は、CQ-STARMで６月号第４章のサンプルプログラムを入れて動作確認をしました。
このサンプルプログラムはUSART１を使ってPCと通信をするプログラムなのですが、CQ-STARMにはRS232CインタフェースICが付いておりません。そのままではPCと２３２Cで通信できないのです。仕方が無いのでADM3202と言うICをお昼ごろ購入してきました。それをDWMに載っている拡張ベースボードの回路図を参考にして結線し、ついでにCQ-STARMの電源も電源端子から取るように結線しました。CQ-STARMはUSBから電源を取ることも出来るのですが、ROBOTに乗せることを考えると電源端子から電源を供給する必要があります。電源端子から電源を供給する場合はUSBからの電源を遮断する必要があります。R7の０Ω抵抗を取り除くのを忘れないように。
とりあえず、サンプルプログラムは動きました。
しかし、CQ-STARMにプログラムを書き込むのはUSBで、デバックやモーションプロセッサとのやり取りはRS232Cでは、２本も線をつなぐ必要があり使いにくいのです。デバックやモープロとのやり取りをUSBでやればよいのですが、いまいちプログラムの作り方がわかりませんでした。となると、プログラムの書き込みを２３２Cでやる方向で解決しようと思います。
私はマイコンはど素人なので、自己責任でお願いします。
まずはUSBダウンローダの仕組みですが、
CQ-STARMは０ｘ８００００００番地から０ｘ８００３０００番地にUSB用のUSBダウンローダプログラムが入っています。そしてUSBダウンローダプログラムを使って０ｘ８００３０００番地からユーザープログラムを書き込んでいます。CQ-STARMのジャンパJ６（実際はPB9）をショートさせると、マイコンは０ｘ８００００００番地から動作するのでUSBダウンローダが起動し、ショートさせないとマイコンは０ｘ８００３０００番地から動作するのでユーザプログラムが起動します。（推測ですが、USBダウンローダがPB9がLOWかHIGHかで、USBダウンローダを起動するかユーザプログラムを起動するかを切り分けているのだと思われます。）
ですから、間違って０ｘ８００００００番地にユーザプログラムを書き込んでしまうとUSBダウンローダが消えてしまうのでUSBでのプログラム書き込みは出来なくなってしまうのです。怖い怖い・・・
次に２３２Cダウンローダの仕組みですが、
CQ-STARMは０ｘ１FFFF000番地から２３２C用の２３２Cダウンローダプログラムが入っています。２３２Cダウンローダプログラムは０ｘ８００００００番地からユーザプログラムを書き込んでいます。（正確には書き込む開始番地はmemory_thumb.defで指定します）CQ-STARMのBOOT０（１１番ピン）をHIGHに短絡させるとマイコンは０ｘ１FFF000番地から動作するので２３２Cダウンローダプログラムが起動し、短絡させないとマイコンは０ｘ８００００００番地から動作するのでユーザプログラムが起動します。
これで、USB経由でのプログラム書き込みはできなくなりますが、２３２C経由で書き込めますので、CQ-STARMとPC間の線は一本ですみます。すっきり。
さらにUSBダウンローダプログラム分の１２KBをユーザプログラム領域として使用できるのでちょっと嬉しいです。さらに、２３２Cダウンローダではs19形式のファイルを扱えるのでわざわざDFU形式に変換する手間が省けてかなり嬉しいです。
２３２Cダウンローダプログラムでプログラムを書き込むときにPC側で使用するプログラムはFlash loader demonstratorと言います。
通信速度は57600BPS EvenParityでやってみたら問題なく動作しました。
サンプルプログラムは０ｘ８００３０００番地から書き込む記述になっているので、memory_thumb.defファイルを修正して０ｘ８００００００番地から書き込むように変更しました。（４行目）
2008/07/20 追加
割り込みアドレスのＢＡＳＥも変更の必要がありました。
gcc_sample.cの以下の行を修正してください。
#define __NVIC_VTOR_VAL 0x00003000
を
#define __NVIC_VTOR_VAL 0x00000000
に変更。
６月２９日は中部練習会
ROBO-ONEサッカーの一週間前の6/29は大同工業大学にて臨時練習会があります。
RFC愛知練習会でもあります。
やっぱり、チームメイトで練習してみないと感覚がつかめないでしょうから、練習会は重要です。
私は最近、練習会には長いこと参加していませんでしたので、とても久しぶりです。たのしみ〜。
大同工業大学なので地理的には
アー○ブルーの方とか○ジンガーの方とか来てくれると
RFC愛知3/4 VS 四○会2/4
が出来るのにな〜。
キング○イザーの方とか来てくれると
グループB第一試合の予行練習が出来るのにな〜。
そんな豪華な練習会だったいいのにな〜。（笑）
RFC愛知練習会でもあります。
やっぱり、チームメイトで練習してみないと感覚がつかめないでしょうから、練習会は重要です。
私は最近、練習会には長いこと参加していませんでしたので、とても久しぶりです。たのしみ〜。
大同工業大学なので地理的には
アー○ブルーの方とか○ジンガーの方とか来てくれると
RFC愛知3/4 VS 四○会2/4
が出来るのにな〜。
キング○イザーの方とか来てくれると
グループB第一試合の予行練習が出来るのにな〜。
そんな豪華な練習会だったいいのにな〜。（笑）
ROBO-ONEサッカーまでの残作業
ROBO-ONEサッカー大会まであと２週間になりました。
現在、やっとパンチカーペット上でそれなりに移動ができるようになりました。
まだまだやらなきゃいけないことがてんこ盛り。
残作業項目をまとめてみました。
１、旋回モーションの調整
２、起き上がりモーションの調整
３、スローインモーションの調整
４、パスモーションの作成
５、シュートモーションの作成
６、立ち位置の微調整用移動モーションの作成
７、ジャイロセンサの調整
それぞれのモーションをどうやってPS2PADのボタンに割り当てるかが悩みどころ。
覚えられなさそう・・・
予定は
6/29 大同工業大学で練習会
7/5-6 ROBO-ONEサッカー大会
練習会までに項目４までは完成させたいな・・・
現在、やっとパンチカーペット上でそれなりに移動ができるようになりました。
まだまだやらなきゃいけないことがてんこ盛り。
残作業項目をまとめてみました。
１、旋回モーションの調整
２、起き上がりモーションの調整
３、スローインモーションの調整
４、パスモーションの作成
５、シュートモーションの作成
６、立ち位置の微調整用移動モーションの作成
７、ジャイロセンサの調整
それぞれのモーションをどうやってPS2PADのボタンに割り当てるかが悩みどころ。
覚えられなさそう・・・
予定は
6/29 大同工業大学で練習会
7/5-6 ROBO-ONEサッカー大会
練習会までに項目４までは完成させたいな・・・
