ソフトUARTとMMC関数移植完了

やっとAVR GCC用にソフトUARTとMMC関数移植完了しました。

MMCは難航しました。
tiny26でテストしていたのですが、UARTでデバッグ情報を出力してたら、その文字列リテラルでなけなしのRAM(128バイト)が食いつぶされてたり、ループカウンタが最適化の煽りでうまく回ってなかったりで、どうも本質的なことでつまるというより、環境によるものが多かったです。

教訓としては、
・デバッグ用なんかの文字列はめんどくさくてもFLASHのプログラム領域に置くようにする。
・最適化は最初は外してテストすること。容量が許すのであれば最適化は不要。

なんとなくコツも分かってきましたし、とりあえずこれでCでizCOREのメイン部分が組めそうです。

ソフトUARTとMMC周りのコンパイル後のサイズですが、最適化なしで1200バイトくらい食いました。
最適化最大で800バイトくらい。

ちなみにオールアセンブラだと２年前のおよそ同様の実装で600バイト強くらいでした。

こんな感じなのでtiny26はプログラム領域が2Kバイトしかなく、この先苦しそうなので、tiny861買いました。

アセンブラ関数でソフトUART

昨日書いた通り、WinAVR（AVR用GNU Cコンパイラ）やってます。

実はWinAVRには標準でUART関数がありません。多分。

ハードウェアUARTを持っているAVRであればI/Oレジスタ叩くだけでいいのでCでも簡単に実装できそうですが、私が主に使っているTiny系ではハードウェアUARTは無い物がほとんどです。
（AT90S2313やATTiny2313にはハードウェアUARTがありますが、izCORE2.0メインプロセッサとして必須要件として考えているADコンバータがありませんし、UARTも複数系統使いたいですし。）

仕方ないので汎用I/Oポートをソフトウェア制御してシリアル通信をしてやる必要があります。
これまでは主にアセンブラでやっていたので、Atmelが公開しているアプリケーションノート（AVR305: Half Duplex Compact Software UART）を参考にソフトウェアUARTを実装していましたが、高速になればなるほど（115.2kbpsとか）、通信パルス幅が10MHzの1クロック分程度の誤差で通信できなくなってしまいます。

アセンブラであれば、実行命令時間を正確に計算することが出来るので調整がきくのですが、Cだとコンパイラ任せなのでそうもいきません。

数命令程度ならまだしも、全部をインラインアセンブラでやるのはかなり大変そうだと思いましたが、調べてみるとWinAVRにはアセンブラ関数という機能があるようで、アセンブラソースを別に書いといて、それを関数として使用することが出来るようでした。

試してみると、マクロ命令系を除いて、これまで使用していたソースコードをほとんど変えることなく使用することができました。

これでフツーにCの関数としてUART通信を実行出来るようになりました。

確認したところではATTiny26 10MHz駆動時、クロック単位の微調整は要りますが、PCのUSBシリアル変換に対して230.4kbpsまではいけました。
460.8kbpsは駄目でしたが、PC側の規格速度に拘らず、10MHzのAVR同士でこのソフトUART同士なら600kbps～2Mbps位でもいけると思います。

このソフトUARTで出来るのは１バイト送受信ですが、こいつがCの関数と同様に扱えるので、C上で文字列送受信の関数もついでに実装してみました。

なるほど。これはかなり快適です。
アセンブラだとこういうのは苦手だから。

あとはMMCアクセス関連とADC関連を移植すれば要素部品は完了。

でも、やっぱりこうなるとこの構想ではメインプロセッサはATTiny26でしたが、RAM128バイト程度では明らかにメモリが足りなさそうです。

アセンブラだとなんとかやりくりできるかなって感じだったのですが、コンパイラ任せだとスタックや変数領域にどれだけ使うか分からないので、やはりATTiny861（RAM512バイト）かな。
前はどこにも売ってなかった（見つからなかった）けど、最近はこちらで入手可能なようだし。

Mega系を使わない理由は、単に物理的に大きいからです。
DIP品でないと手配線できないし。

ああ、DIPタイプ20ピン以下のMegaがあればいいのに．．．
（ラインナップ的にそれはTinyだろ！ってのはナシのことで。）

WinAVR(AVR-GCC)におけるアセンブラ関数の作り方は、以下ページを参考にしました。

AVR Wikiのavrgccでアセンブラを使う
ChaNさんのアセンブラ関数の書き方(avr-gcc)

感謝。

izCORE V2.0

新しいコントローラ（izCORE V2.0）設計してます。

新しいと言っても技術的にはこれまでの外部プロセッサ追加による拡張を一つにまとめるような形です。

まずは配線図描いてみました。
←クリックで拡大します

従来はメイン、サブともAT90S2313だったのですがこれは旧シリーズであるため、今後の入手性とAD変換の必要性から、メインにATTiny26,サブにATTiny2313としました。
ただ、メインのATTiny26はSRAMが少ないので、場合によってはATTiny861あたりを使うかもしれません。

おおざっぱではありますが想定タイミングチャートです。

←クリックで拡大します

MMCデータの読み出し時間は実際にはもっと短いと思います。実測の必要がありますね。
こうしてみると結構余裕があるので多少の通信遅延や処理時間増は吸収できるでしょう。

上位コントローラは、有線/無線で接続したマンマシンI/Fか、自律動作（というか自動操縦）用の外部プロセッサを想定しています。

外部プロセッサは現在手持ちのだと．．．いろいろありますね。
V850だのSH2だのR8CだのH8だの．．．ええ、みんなInterface誌やトラ技の付録で買ったまま放置してるやつです。　
でも実際使うとしたら多分8ピンAVRのATTiny45くらいだろな。小さいし。

電波は分からん

先日のロボファイトでは全く使えなかったZigBeeですが、実際のところどのくらいの通信エラーがあるのか確認してみました。

PCからの送信データをZigBeeモジュールZIG-100Bを通してPCに折り返して調べてみました。
図にするとこんな感じです。　間にいろいろ入ってますが、送信データをZIG-100B経由でループバックしているだけですね。


確認のためにVB6でこんなツール作ってみました。　→ソース(3KB)（MSCOMMコントロールを使用しています。）

シリアル115,200bpsで約15ミリ秒間隔で1バイト送信し、次の送信までにそれを受信できなければ欠損とします。
受信できても送信したデータと食い違っていれば異常です。
送信データは0～255までインクリメントしていきます。（255の次は0）

もちろん有線でループバックした場合は全く問題が発生しないことを確認しています。

実際の実験装置です。
右側のZIG-100BはABS製のケースに入れています。
写真ではZIG-100Bのチップアンテナが向かい合うように置いています。

結果ですが、一言で言うと「電波は分からん」です。

無線LANのオン・オフ・使用量による影響、ZIG-100Bの向きなど、いろいろ試してみましたが意外なことが影響しているようでした。
今回の検証では一番怪しいと思っていた無線LANはあまり関係ありませんでした。
これは2.4GHz無線LANのチャネルは一つしか占有していないのでZigBeeが空いてるところに自動的によけたためだと思われます。
他の2.4GHz機器（BlueTooth，無線PSコントローラ等）がひしめくロボイベント会場ではまた違った結果になるかもしれませんが。

さて、最も影響したのは「机を触ること」でした．．．
上の写真で机を触っていますが、このようにすると著しく受信データの欠損が発生します。
触れなければほとんど発生しません。

ナゼ？こんなとこ電波の通り道でもないだろに。

また、このように浮かせた状態で間に手を入れてもエラー率は上がりませんが、机に指が触れるとやはりデータの欠損が発生します。

また、左側のZIG-100Bに触れても問題ありませんが、右のABSケースに触れた場合も同様に受信データが欠損します。

完全に絶縁されているのですが．．．ナゼ？

実際に計測した結果は、以下の通りです。
60秒の計測をそれぞれ5回行いました。



机に触れる場合と触れない場合は交互に測定し、特定の時間帯による偏りはないはずです。（近所でバースト的に無線LANを使ってるとか電子レンジとかの影響を考慮。）

うーん、電波は分からんです。
とりあえずABSのケースが癌？

進捗 2006.09.13朝

　昨日の続き。
　
　ブレッドボード上で加速度センサのAD変換の再評価。
　シリアルにノイズデータが混入する原因は判明。
　仕様では下流プロセッサからのデータ要求はあるピンに対する立ち上がりエッジによる割り込みで行っていおり、この割り込みでバイナリデータを送信するようになっています。
　基板のテスト時はこのピンからつながるコネクタは未結線だったため、「不定」の状態で、そのためふらふらしてた模様。たまたま電気的に閾値を超えるとHとみなされ割り込みがかかり．．．といった感じ。下流に繋がないテスト時はプルダウンしておくべきでした。

　この入力ピンの不定状態は、先日、ベーチックの旭さんがボタン押下状態を取得しようとしたときに「押していない場合値が不安定になる」と言っていたのに対して、私がBBSで「内部プルアップ設定にすれば...」と書き込んだのと同じ現象です。
　他人の間違いは気付きやすいのに、自分の間違いは気付きにくいものです。

　あと、破壊につながるものではないと思うのですが、ADCを行う上で足りない結線を発見。
　これで値がかなり安定しました。

　さて、これからまた基板実装。

　去年のXDAY-3の朝の状況は．．．　モーションの準備してる。
　（ここではあと4日と書いてますが、朝なので2005.9.14も含めての日数です。）

　ONOさん情報によると、SISOさんちにご子息が生まれた模様。

　おめでとうございます。

（6:30現在でplalaのブログがメンテナンス中のため詳細は不明。）

※7:20追記
　自動起き上がり用の加速度センサユニット完了....長かった。破壊の根本原因は結局不明だがとりあえずよしとします。
　tiny26の在庫が潤沢でよかった…グッジョブ！過去の俺。

■完了分
・制御系改修H/W作成（加速度センサユニット）

■未完
・新機体基本モーション動作確認
・資格審査モーション作成
・うさぎ跳びモーション
・予選デモ構成検討＆作成
・バトル系モーション作成
・PC用ZigBee基板（忘れてた）

進捗 2006.09.11

うまくいかない。
日曜日、ブレッドボードでテストを終えた３つのアドオンプロセッサ基板を作成したが、そのうち、加速度センサ取り込みようのものがうまくいかない。

日曜の段階ではうまくいっているように見えたが、電圧が小さい方に振れたあと、加速度センサを水平にしても中立まで戻ってこない。というより、低いまま固定化されているような感じ。
さらに傾けてやると大きな値が取れるようになり、水平にしてやると中立値に戻る。
このままでは、転倒状態を検出して自動起き上がりがうまくいったとしてもまだ転倒状態であると誤認識する。

それから、シリアル送信におかしなノイズデータが乗るようになった。線を圧迫したりするとひどくなったり改善されたりするので断線かと思いいろいろ試してるうちに、tiny26がおかしくなった。電源逆挿しとかしちゃったからかな？

仕方ないので、もう一つ作ってみたが、こちらも同様。
そのうち、またtiny26が動かなくなってしまった。　ナゼ？　こんなことは初めて。

半田付けによる熱破壊？　２つ連続はちょっと考えにくいし。
昔、AVR AT90S2313で実験してたとき、電源逆挿し状態でしばらく悩んでたら、チップ上面に貼ってあったシールは焦げるわ、ブレッドボードは融けるわといった発熱が生じたけど、冷ましたらフツーに使えた。　丈夫だな～とか思ってたが．．．

ユニバーサル基板の在庫も底をついた。

■完了分
・制御系改修H/W作成（miniSDユニット、無線補助ユニット）

■未完
・制御系改修H/W作成（加速度センサユニット）
・新機体基本モーション動作確認
・資格審査モーション作成
・うさぎ跳びモーション
・予選デモ構成検討＆作成
・バトル系モーション作成

いかん、めちゃめちゃ遅れてる。　ヤバイ。

ちなみに去年のROBO-ONEウィークの火曜日朝は．．．
イカン、去年の自分に追い越された。

こんなことしてます

うう、みんな結構進んでるな。

私は長井用に制御系の改修中。

従来はこんな感じでした。（クリックで拡大）
操縦時の仕様は去年7月くらいから変わっていません。
通信は有線シリアルかWiportを使用した無線LANによるものとなっています。

自律デモ用は昨年秋の飛騨高山用に急遽こしらえたものです。　
miniSDに2分間の20ms毎の補間後モーションデータを格納しておき、PCからの通信と同じフォーマットで流すことでizCOREを騙します。

で、今作ってるのがこれ（クリックで拡大）。
izCORE部分は変わっていません。
従来の自律モードと同じように、miniSDを繋いだアドオンプロセッサを置き、補間後の各モーションデータをここに保管しておきます。こいつに外からコマンド（実際にはminiSDのアドレス（64KB単位））を送ってやればそのアドレスのモーションをizCOREに送ってやる手はずです。

これでかなり必要な通信が削減される（モーション再生中は通信が落ちていても再生し続ける）ので信頼性向上が図れるかと思いますが、その前段にさらに全力で通信をサポートするバッファ的プロセッサを置きました。

このプロセッサは基本的にはPCから受信した内容を下流にスルーするだけですが、通信が途絶えても2秒間は最後に正常受信したコマンドを下流に対して送ることを保証します。
通信断が２秒以上続くようなら下流には脱力コマンドを発行し、安全な形で待機させます。
もちろんその後通信が回復すればそのモーションを送ります。

これは今回、無線はZigBeeを使うつもりなのでその障害対策のためです。
（ヒロムロボにはWiportを置くスペースが無いのです．．．ま、Wiportも時々パケットが遅延したりするのでいずれはこんな感じにするつもりでしたが。）

これで、５個のAVRによるマルチプロセッサシステムとなります。　
なんかカッコいいぞ！

自律モードは基本的には飛騨高山とほとんど変わりませんが、前段に加速度センサをA/D変換で取り込んで転倒検知とそれに対する起き上がりモーションを発行するプロセッサを置いています。

飛騨高山でのAsso Di Fioriは実は自動起き上がりは出来ませんでした。
それでもなんとなく自動起き上がりっぽく見えていたのは、「走る」モーションの後は高確率で転ぶため、デモのシナリオとして「仕組まれた」ものでした。
走った後、逆にコケなければ突然のたうちまわります。

あと1週間ちょっとしかないや。
去年に比べて危機感が薄いような気がする。　

■宣伝協力■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
イコーぜ！長井！
いくぞタイガース　＆　走れ！ＲＯＢＯ－ＯＮＥ弾丸吉日号 ！
ROBO-ONE参加者じゃなくても観戦だけでもＯＫ。
オジさんだって「青春」しようぜ！　合宿であの日の気分が満喫できます。　ゼヒ。
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

ROBO-ONE対応改修

■宣伝協力■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
イコーぜ！長井！
いくぞタイガース　＆　走れ！ＲＯＢＯ－ＯＮＥ弾丸吉日号 ！
ROBO-ONE参加者じゃなくても観戦だけでもＯＫ。
「私、19歳の女子短大生。実は誰にも言ってないけどロボマニアなんです。
こないだKHR-2HVを買ったけど話を分かってくれる人が周りにいなくて．．．」
という貴女！
女子でも安心の個室ありだそうですのでノープロブレム。
決勝トーナメント前夜のROBO-ONE参加機とのスパーリングで、マックスとミリアのような
恋も芽生えるかもしれません。
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

　ROBO-ONEレギュレーションを満たすため、昨年の飛騨高山大会に投入したminiSDユニットを改修。
　他にもizCOREの前段にPCとの通信を受け持つサブプロセッサも追加。
　元々はizCOREと直接PCが通信する仕様なのだが、このサブプロセッサがPCからのコマンドを受け取り、miniSDユニットに通知，miniSDユニットから必要なモーションデータを読み出して、izCOREに伝えることとする。

　これにより自律動作だけでなく、通信頻度を減らすことができるので、無線障害を軽減することが可能である。
　現在、昨年のアセンブラソースを通勤中に解読＆改修中。

　こういうときはVAIO-U50が役に立つ。　立ちながらでもプログラミング可である。
　最近は公私共にプログラミングから遠ざかっていたのでリハビリ中といったところ。

　さて、これでizCOREの3つを含めると、5つのマイクロプロセッサが動作することとなる。
　非同期タスクが増えるたびにプロセッサが増えていく．．．

　もしかすると大会参加機中、最多マイコン搭載機かもしれん。
　（もちろん、デジタルサーボ中のマイコン除く）

ZigBeeテスト@ヒロムロボ

　ヒロムロボにZigBee付けてみました。

　動くには動くのですが、結構エラーがあるようです。
　アンテナの方向やモータノイズの影響を受けてる感じがします。
　（動かすとエラーが起こりやすい。）

　izCOREは、115200bpｓで毎秒50回の双方向通信をしているのですが、動かしてると1分間に１，２度、データ授受ができないようです。
　
　今のところの印象では、ZigBee、時間的に離散的なコマンド投入（＋多少のデータ収集）にはいいかもしれませんが、ウチのようなリアルタイム"データ通信"にはちときついかもしれません。

　通信速度落とせばいいかもしれませんが、まだ試してないです。
　昔計算したところでは、izCORE、最低でも57600bpsは必要だったような気がします。

　でも、機器-ZIG100B間の通信速度がお互い違っていてもいいということは、ZIG100B同士の通信はもっと速い速度で一定？
　機器-ZIG100B間の通信（有線）でエラーが出てるとは考えにくいので、ZIG100B間の無線通信でエラーが出てるのなら、シリアルの速度落としても解決しないのかな？

　DELLノート、";"のキーがおかしい。
　やたらと入りにくいし、そもそもこのキーだけなんかタッチ（タイプ時の音も）が違う。そんなもん？

ZigBeeテスト

　ブレッドボード上にてZigBeeテスト。

　接続は左図の通り。
　PC<->ZIG-100B間は、USB-RS232C変換とMAX232互換のレベル変換を介して接続。

　以前、Wiportのテストで使用したAVR AT Tiny26Lのプログラムでテストを行いました。
　通信速度は9600bps,57600bps,115200bpsで確認。

　いずれの速度も特に問題なく接続することに成功しました。

　Tiny26Lを115200bps，ＰＣ側を9600bpsとするなど、双方の速度が違っていても通信できます。