ずーっと使いながら時々気になっていたことって良くあるものです。別のせいにしてお茶を濁してることもしばしば。at91sam7s/xでも似たようなことがって、あまり手を入れていなかった所に地雷が仕掛けられていました。それがPLLの初期化。
とりあえず現状でも動くのですが、起動させる条件(たとえばデバッガを使っていたりRAMでブートさせるといったと時)によって時折動かない事が起こり得えます。これはCPUの動作クロックを設定する部分に起因していて、フラグが意図通り変化しない場合に陥ります。openocdがガンガンバージョンアップしていく過程で明らかになった部分で、アセンブラであったこともあり気付くのに時間を要してしまいました。
GCC Developer Lite本体のWindows Vista/7対応レベルの向上、sam7s/xのx64環境でのUSBシリアルエミュレーションドライバ対応、sam7s/xのRAMデバッグ環境の見直し、FDIIIライブラリのバグフィクスと合わせて近々更新する予定です。

現在AT91SAM7S/Xシリーズ向けのシリアル通信ライブラリにおいて、USARTのボーレートは粗めの分解能でしか設定出来ません。特段理屈は無かったのですが、確かに高いボーレートになると合わせにくい所でもあります。
次のGCC Developer Liteのアップデート時にUSARTのSampling Divider関連は全て16から8に変更されますので、従来よりも倍の精度でボーレートが設定できるようになります。
なお、FDIII-HCにおいてもボーレートが全域においてDynamixelと一致しますので、666k,500kbpsといった最大速度に対して若干遅めのボーレートにも対応できるようになります。

それと、ボーレートついでに。
しばしば問い合わせのあるPCとDynamixel間の無線化は、特に特殊な事をせずともFDIII-HCを使用する事で実現できます。USB接続のみのDnamixelコンフィギュレータをFDIII-HCに置き換えるだけで、Bluetoothによる無線化が簡単に行えます。その場合FDIII-HC用に専用のプログラムを作る必要はありませんし、USBケーブルで有線、Bluetoothで無線といった具合に必要に応じて自由に使い分ける事もできます。もちろんPC上のソフトウェアの資産はそのままで、接続先に応じたCOMポート番号を変えれば良いだけ。
ちなみに、FDIII-HCではBluetoothのDTE速度を460.8kbpsとしていますので、無線化したとしてもリアルタイム性は別としてそこそこのスループットは得られるかと思います。

とは言っても人造人間の方じゃありません。Googleの携帯向けOSです。
Linuxじゃんといえばそれまでですが、カーネル以外はどこがLinuxかワカラン程度で別個のプラットホームと考えた方が良い感じです。

なぜに今になってそんなネタを？
何となく黎明期のPocketPCの様に無い機能は自分で作る以外に無いといった雰囲気がおもしろいなぁと思いまして。コーディングするという点においてはiPhoneと違って縛りも無いし。
beagleboardやPC、その他のARMが載ったボードでも実際に動いていますし、もちろん携帯電話としてもdocomoからも端末が出てきた事もあり、そこら辺の環境を利用しつつ何かに応用出来ないかなと画策中。

最近Windows Vistaを使っている方が増えているためか、GCC Developer Liteのメッセージダイアログボックスに何にも表示されないという問い合わせがちらほらと。
ネタはGCC Developer Liteの従来からの互換性の都合から、Vistaでは標準でONになっているUAC(ユーザーアカウント制御)による制限を受ける事に起因し、とりあえず何か文句を言われたら「キャンセル」ではなく「許可」をクリックしましょう。「キャンセル」を押した後で難なく動く理屈は全くありませんので。
メッセージがあまりにもウザい時はここやここの情報を参考に設定を変える以外に、今のところは手はありません

USS3のアナログ信号をATmega32 EVBに取り込んでみました。
壁との距離がある値を下回るとブザーがなり始め、距離によってブザーの音が変わるようなプログラムにしました。
詳しくはチュートリアルをご覧下さい。

Atmel社のAT91SAMシリーズがほぼ標準で持っているSAM-BAという機能。
FLASH WRITERでも対応しており、USB経由であれば特に支障はないのですが、外部クロックの都合などでCOMポート経由で使おうとすると処理時間が劇的に遅くて全く使い物になりません。DBGUしか持っていないAT91SAM7S32では致命傷。
原因はAT91Boot_DLL.dllを使っているからなのですが、Atmel社のアップデートを待っているだけでは延々と解消しそうにないので、何が起こっているのか調べてみました。
結論から言うと送信するファイルを分割してパケット通信している所で、毎回3秒程度の時間待ち(タイムアウト？)が発生しているのが原因でした。
その後詳細に見ていくと、チップ内に予め備わったブートプログラムでそれにかかるコードが見つかりました。FLASH WRITEから呼んでいるAT91Boot_DLL.dllを経由して無理やりパッチをあてる事で訳の分からない時間待ちが無くなり、すっきり解消。

次期GCC Developer Liteにおいては、この辺りの対応がなされたFLASH WRITERを同梱する予定です。

ZEALコードレスアダプタはZEAL-C01という無線モジュールをCOMポートにつなぐ用途で用意していますが、今更COMポートなのかな？というのと、ZEAL-C01を単体で利用したいというご要望もありまして、簡単なピッチ変換基板モドキを試しにこさえてみました。
細かいピッチで並んだ何十ピンもあるコネクタも、最低限必要な端子数は知れています。その中から割り切って8ピン分のヘッダに配線してみました。

こんな感じに亀の子状態に合体すれば完成です。これならばちょっと試しにブレッドボードに挿してみようかなという気にはなるかなと。

最近かなりバリバリと細かいパッチが当たってるので放置してたが、ちょっとばかりアップデートして試してみた。が、どのようにしてもマトモに動かない。
J-LINKではサラッと動くトコを見るとft2232依存っぽい。どうもjtag_kHzの挙動が予想と違う感じと思ってデバッグしてみると、FT2232Hのサポートが影響してた。
configure時に無指定だと--enalbe-ftd2xx-highspeedになるので、--disable-ftd2xx-highspeedを追記してみると解決するでしょう。

6/21追記:
svn 2295からデフォルトでwant_ftd2xx_highspeedがnoになったので、追加しないでも支障は無くなりました。