 |
 |
 |
 |
ブログ - 最新エントリー
遅ればせながらブートローダの操作仕様共通化に従った、AVRマイコンボード向けのブートローダバージョン1.3を公開しました。
AVR Bootloader主な変更点は以下の通りです。
- コマンドモードへの遷移方法をハードリセットに変更
- 最新GCCに対応
開発
先にもお知らせしました仕様共通化に従った、AT91SAM7S/Xマイコンボード向けのブートローダバージョン2.5を先行公開しました。
Atmel社の最近のSAM-BA In-system Programmerはかなり安定して動作する様ですので、フラッシュROMを書き換えるといった場合は利用してみてください。
なお、今後出荷されるマイコンボード製品につきましても、本ブートローダが適用されます。
AT91SAM7S/X Bootloader主な変更点は以下の通りです。
- USB CDC EmulationにおけるPort Open/Closeの判定を中止
- コマンドモードへの遷移方法をハードリセットに変更
- DUMPコマンド追加
Atmel社の最近のSAM-BA In-system Programmerはかなり安定して動作する様ですので、フラッシュROMを書き換えるといった場合は利用してみてください。
なお、今後出荷されるマイコンボード製品につきましても、本ブートローダが適用されます。
開発
SIMPLE TERMは特に高機能という訳でも無くテキトーなリアルターミナルですが、いつもGCC Developer Liteのインストーラと一緒に同梱している都合から、面倒くさがりな作者の都合に合わせて操作を横着するための機能がちまちまと追加され続けています。
今回はフロー制御のお話です。
H8シリーズとのシリアル通信による簡易的なコミュニケーション用として作られたSIMPLE TERMですが、当初からRS232Cを前提とした3線シリアル通信を行う事を念頭に置いていた事もあり、ハードフロー制御は行わないものとしていました。特にDTR/DSRに関してはその当時FLASH WRITERがケーブルの接続チェックに使っていたこともあり、SIMPLE TERMには設定すら無く今でも常時無効にしています。
時代は変遷し、マイコンとPCはUSBで直結して仮想COMポートを介して通信するのが主になってきました。当然マイコンには自分のUSBを制御するコードが入って入るわけでして、弊社でもどこぞやのライブラリを使って実現させています。
ところが、PCがその仮想COMポートを開いている否かをマイコン側で判断しないといけないシチュエーションがありまして、特にマイコン側から一方的に送信する場合は無くてはならない条件だったりします。
ホストがWindowsであるのが前提ですが、今のところSAM3やSAM7Sシリーズ用のUSB CDCエミュレーションライブラリではポートのオープン/クローズを簡易的に判断させていますが、いかんせんOS限定というのはいただけない。
ということで、次期GCC Developer Liteにおいてこのあたりを大幅に仕様変更します。
今回はフロー制御のお話です。
H8シリーズとのシリアル通信による簡易的なコミュニケーション用として作られたSIMPLE TERMですが、当初からRS232Cを前提とした3線シリアル通信を行う事を念頭に置いていた事もあり、ハードフロー制御は行わないものとしていました。特にDTR/DSRに関してはその当時FLASH WRITERがケーブルの接続チェックに使っていたこともあり、SIMPLE TERMには設定すら無く今でも常時無効にしています。
時代は変遷し、マイコンとPCはUSBで直結して仮想COMポートを介して通信するのが主になってきました。当然マイコンには自分のUSBを制御するコードが入って入るわけでして、弊社でもどこぞやのライブラリを使って実現させています。
ところが、PCがその仮想COMポートを開いている否かをマイコン側で判断しないといけないシチュエーションがありまして、特にマイコン側から一方的に送信する場合は無くてはならない条件だったりします。
ホストがWindowsであるのが前提ですが、今のところSAM3やSAM7Sシリーズ用のUSB CDCエミュレーションライブラリではポートのオープン/クローズを簡易的に判断させていますが、いかんせんOS限定というのはいただけない。
ということで、次期GCC Developer Liteにおいてこのあたりを大幅に仕様変更します。
- SIMPLE TERMも他の一般的なターミナルソフトなどと同様に、ポートのオープン/クローズに連動してDTRを自前で制御。
- マイコン向けのUSB CDCエミュレーションライブラリ(SAM7S,SAM3S,STM32F3シリーズのみ)に含まれるWindows限定の判定ルーチンを止め、DTRの状態によってオープン/クローズを判定。
- 旧バージョンのSIMPLE TERMで新しいUSB CDCエミュレーションライブラリを使用したターゲットの仮想COMポートを開くと、見かけ上ターゲットからの応答が得られない。
- 新しいSIMPLE TERMはUSB CDCエミュレーションライブラリの新旧にかかわらず通信が行える。
- 新しいライブラリを使用したターゲットはLinuxやmacOSでもOK。
- つまり、ツールが新しくてターゲットが古い場合はOKで、ツールが古くてターゲットが新しいのがNG。
技術
最近のnote pcを調達したが、何もかもUSBに集約しろといわんばかりにそれ以外の拡張性がない。おまけにUSB3.0というだけあって、下手なUSBデバイスのファームで一度でもしくるとホストコントローラから応答しなくなるまでか、PCのシャットダウンすらできなくなる。
散々四苦八苦し、新しいPCを開発機としてターゲットは古いPC上でという間抜けな環境でしのいでいたが、開発機のUSBポートが足りなくなったので外付けのUSBハブを調達。
ついでなので開発機にお試しデバイスをふと差し込んでしばしそのまま使っていたが、下手打ってもなんだかそのまま使い続けられる事に気づいた。
ということで、新しいPCのUSBにつなく玩具で遊ぶ際は、外付けのUSB2.0ハブをかませると少し安心かもしれないというネタでした。
散々四苦八苦し、新しいPCを開発機としてターゲットは古いPC上でという間抜けな環境でしのいでいたが、開発機のUSBポートが足りなくなったので外付けのUSBハブを調達。
ついでなので開発機にお試しデバイスをふと差し込んでしばしそのまま使っていたが、下手打ってもなんだかそのまま使い続けられる事に気づいた。
ということで、新しいPCのUSBにつなく玩具で遊ぶ際は、外付けのUSB2.0ハブをかませると少し安心かもしれないというネタでした。
技術
扱っているマイコンボードは多岐にわたっているのと、時期によってデザイン思想が変わっている事もあり、ブートローダの挙動がどれもまちまち。とりあえずXMODEMによるバイナリファイル転送という点は共通化されたのだが、ブートローダへ入る方法が気まぐれ過ぎる。
なにか安直な方法はないかとデータシートをまじまじ眺めていると、どのチップも起動直後の条件を取得できる様である。つまり、電源ON一発目なのか、ウォッチドッグでリブートしたのか、ソフトリブートしたのか、外部からのリセット信号でリブートしたのか等々。
そろそろお目見目する予定のDIGITUSシリーズはUSB接続が前提となるので、コンソールから何かしらのシグナルを送ることはちょっと考えにくいし、もともとピン数が少ないところに態々スイッチなんてのも流行りじゃない。
結論から言ってしまうと、「リセットボタンを押したらブートローダに入る」ということ。これが一番確実で、ユーザアプリケーションで想定されるプログラムとの競合も少ないハズ。
ひとまずATmegaが載った輩がコードサイズ的に厳しいので、試しに入れてみた。結果は良好。いままで「!」を連打してた手間も省けていいかんじ
。
ということで、勝手ながら今後のブートローダの仕様を変更させていただきますので、びっくりしないでくださいね。
なにか安直な方法はないかとデータシートをまじまじ眺めていると、どのチップも起動直後の条件を取得できる様である。つまり、電源ON一発目なのか、ウォッチドッグでリブートしたのか、ソフトリブートしたのか、外部からのリセット信号でリブートしたのか等々。
そろそろお目見目する予定のDIGITUSシリーズはUSB接続が前提となるので、コンソールから何かしらのシグナルを送ることはちょっと考えにくいし、もともとピン数が少ないところに態々スイッチなんてのも流行りじゃない。
結論から言ってしまうと、「リセットボタンを押したらブートローダに入る」ということ。これが一番確実で、ユーザアプリケーションで想定されるプログラムとの競合も少ないハズ。
ひとまずATmegaが載った輩がコードサイズ的に厳しいので、試しに入れてみた。結果は良好。いままで「!」を連打してた手間も省けていいかんじ
。ということで、勝手ながら今後のブートローダの仕様を変更させていただきますので、びっくりしないでくださいね。
技術
ここ最近マイコンボードシリーズの終了ばかりで新しいものがないというご意見が。
実際には無いという訳ではなくて、お客様のご要望に合わせたカスタム製品が主になっており、GCC Developer Liteのターゲットにはあるにもかかわらず、実機が存在しないといったケースはそういったものに該当しています。
そういった都合もあり、汎用的に使用できる製品をご用意するところまでに至っていません。
ごめんなさい。
かといって終了品ばかりになってしまいますと次世代の潮流を創出できないといったこともありますので、いくつか準備中です。
実際には無いという訳ではなくて、お客様のご要望に合わせたカスタム製品が主になっており、GCC Developer Liteのターゲットにはあるにもかかわらず、実機が存在しないといったケースはそういったものに該当しています。
そういった都合もあり、汎用的に使用できる製品をご用意するところまでに至っていません。
ごめんなさい。
かといって終了品ばかりになってしまいますと次世代の潮流を創出できないといったこともありますので、いくつか準備中です。
- ATmega32マイコンボード
外部端子に旧来との互換性を持たせ、RS232Cコネクタを廃止。
代わりにUSBシリアルチップを装備、USBバスパワーで駆動可能。
ArduinoでよくやられるRTS/DTRによるリセット発行は、USBの活性時にこきたない挙動を示すのでCBUS経由。
- ATmega128マイコンボード
こちらも外部端子の互換性ありで、RS232Cコネクタを廃止。
USBポートを装備してバスパワー駆動サポート。
使用頻度の少ないと思われる外部SRAMはランドだけ残して未実装。 - SAM3S
AT91SAM7Sシリーズの後継としてcortex-M3を内蔵したSAM3Sを採用。
AT91SAM7Sシリーズとは ハード的に互換性がない小型新シリーズ。
今まで2列だった外部端子を、ブレッドボードなどで試しやすい1列に。
- STM32F3
coretex-M4Fを内蔵。こちらも小型でノリはSAM3Sと一緒。
出すか出さないかは私次第。
その他、
- ユニバーサルドライバ3.5
特に拡張性が向上するといったこともなく、基本的にソフト的・電気的に互換性あり。
取り付けサイズコンパチだが、レイアウトの大幅変更あり。
USBコネクタがminiタイプ。
耐性向上の都合からコストアップ
。 - beaglebone USB cape
任意の外部電源の入力、USBハブ搭載で拡張性アップ。
専用のサーバアプリを使用して、アプリケーション間のデータを共有。
matlab/simulinkのコードをマジ簡単に組み込み可。
といったところです。
詳しくは今後のリリース情報をお待ちください。
技術部
既にイベントは終了しましたが、ROBO-ONE ARCで使用したサーバアプリケーションにて実証実験をかねて標準化APIを使用してマルチプラットホーム化された環境を提供しました。
サーバがサポートしたターゲットは以下の4種類です。
基本的なアクチュエータとホスト間の呼び出し規約をAPIとして共通化した事により、サーバ内のAPIを使用したコーディングはメーカの差異をあまり意識せずに移行する事が確認できました。
今回標準化の成果物として、各社向けAPIのバイナリ(dll)と簡単なサンプルコードを以下に公開いたします。詳細は同梱のpdfをご参照ください。
ROBO-ONE Standard API V1
なお、Dynamixel用のAPIも本標準化に伴い更新版が同梱されているため、こちらのページのドキュメントおよびソースも修正いたしました。合わせてご活用ください。
サーバがサポートしたターゲットは以下の4種類です。
- テクノロード Go Simulation!
- 近藤科学 KRSシリーズ(ICS3.0/3.5)
- 双葉電子 RSシリーズ
- ROBOTIS Dynamixelシリーズ
基本的なアクチュエータとホスト間の呼び出し規約をAPIとして共通化した事により、サーバ内のAPIを使用したコーディングはメーカの差異をあまり意識せずに移行する事が確認できました。
今回標準化の成果物として、各社向けAPIのバイナリ(dll)と簡単なサンプルコードを以下に公開いたします。詳細は同梱のpdfをご参照ください。
ROBO-ONE Standard API V1
なお、Dynamixel用のAPIも本標準化に伴い更新版が同梱されているため、こちらのページのドキュメントおよびソースも修正いたしました。合わせてご活用ください。
技術部
typedef union {
struct {
char a;
uint16_t b;
};
char dat[3];
} __attribute__ ((packed)) stTest;
このstTestは何故か4バイトで扱われる。
内側の構造体をPACKしていないことに気が付くまで、5分程頭を悩まされる。
typedef union {
struct {
char a;
uint16_t b;
} __attribute__ ((packed));
char dat[3];
} __attribute__ ((packed)) stTest;
これで3バイトとして使えるようになった。
struct {
char a;
uint16_t b;
};
char dat[3];
} __attribute__ ((packed)) stTest;
このstTestは何故か4バイトで扱われる。
内側の構造体をPACKしていないことに気が付くまで、5分程頭を悩まされる。
typedef union {
struct {
char a;
uint16_t b;
} __attribute__ ((packed));
char dat[3];
} __attribute__ ((packed)) stTest;
これで3バイトとして使えるようになった。
RX62Nターゲットの検証を行うためInterface誌の2011年5月号の付属RX62Nマイコン基板を使用したが、コンパイルから実行まで問題なく終了したのは以前紹介した通りで、選択したターゲットは「RX62N(512k Flash)」であった。すなわちR5F562N8を対象としている
ところが、Interface誌に付属していたRX62NはR5F562N7となっており、両者の違いは以下に挙げた内蔵メモリのサイズという事になっている。
アドレスも異なるため、この範囲を超えた場合は書き込むこともできないはずだが、どのツールも実機も何の文句も言わずに動いてる。RAMも同様に96kを想定していて、ダンプしてみても確かにそこにRAMはある。
この表の通りであれば、動かないという結果が得られるのがフツーだと思うのだが・・・。謎だ。
ところが、Interface誌に付属していたRX62NはR5F562N7となっており、両者の違いは以下に挙げた内蔵メモリのサイズという事になっている。
| 型名 | ROM容量 | RAM容量 | |
| R5F562N8 |
512K (0xFFF80000 - 0xFFFFFFFF) | 96K | |
| R5F562N7 | 384K (0xFFFA0000 - 0xFFFFFFFF) | 64K |
この表の通りであれば、動かないという結果が得られるのがフツーだと思うのだが・・・。謎だ。
Copyright© 1989,2024 BestTechnology Co.,Ltd.
