NXPのMCUにはROM APIなる機能が備わっている物がある。内蔵ROM上にいろいろなルーチンが予め書き込まれているので、そのルーチンを使えばFLASHメモリ上にそれらの機能を別途作り込む必要が無いという事の様だ。

トラ技の付録だったLPC810の様に、FLASHの容量が少ないデバイスではこのROM APIの恩恵に与る事も多いはず。UART・I2C・SPI・ADCといったペリフェラルは、ROMに用意されたルーチンに任せる事でFLASHの容量を消費せずに利用できるという物。

特にROM APIの中でありがたいのが割り算で、ソースに「/」や「%」を使ったとたんに数キロバイトしかないFLASHの大半をライブラリが占めてしまうのを解消してくれる。
使い方はマニュアルに書いてあるが、何やら特定の環境を前提としている様でよく分からないので、今回はたぶん公知の情報でしょうがLPC82xを前提としてちょっとだけ簡単に使える方法を備忘録として書いておく。
概ねAPIの名称はマニュアルの記述を踏襲しつつ、まずはAPIへの入り口を作る。APIの呼び出しにいちいち変数なんぞ作って初期化して使うのは野暮ったいので直接アドレッシングで。

typedef struct { int quot; int rem; } idiv_return;
typedef struct { unsigned quot; unsigned rem; } uidiv_return;

typedef struct {
  int (*sidiv) (int numerator, int denominator);
  unsigned (*uidiv) (unsigned numerator, unsigned denominator);
  idiv_return (*sidivmod) (int numerator, int denominator);
  uidiv_return (*uidivmod) (unsigned numerator, unsigned denominator);
} TLPC_ROM_DIV_STRUCT;

typedef TLPC_ROM_DIV_STRUCT *pTLPC_ROM_DIV_STRUCT;

typedef struct {
  const uint32_t p_dev1;
  const uint32_t p_dev2;
  const uint32_t p_dev3;
  const uint32_t p_dev4;
  pTLPC_ROM_DIV_STRUCT pROMDiv;
  const uint32_t p_dev6;
  const uint32_t p_dev7;
  const uint32_t p_dev8;
} TROMAPIs;

#define LPCAPI      (*(TROMAPIs **)(0x1FFF1FF8UL))
#define LPC_DIV_API ((LPCAPI)->pROMDiv)

これらの宣言をしておけば後は使うだけ。
割り算をしたければ、

int ans, numerator, denominator;
ans = LPC_DIV_API->sidiv (numerator, denominator);
// ans = numerator / denominator;

余りが欲しければ、

int ans, numerator, denominator;
ans = LPC_DIV_API->sidivmod (numerator, denominator).rem;
// ans = numerator % denominator;

それすらも野暮ったかったら、gccであれば

int __aeabi_idiv (int numerator, int denominator) {
  return LPC_DIV_API->sidiv (numerator, denominator);
}

unsigned __aeabi_uidiv (unsigned numerator, unsigned denominator) {
  return LPC_DIV_API->uidiv (numerator, denominator);
}

idiv_return __aeabi_idivmod (int numerator, int denominator) {
   return LPC_DIV_API->sidivmod (numerator, denominator);
}

uidiv_return __aeabi_uidivmod (unsigned numerator, unsigned denominator) {
  return LPC_DIV_API->uidivmod (numerator, denominator);
}

としておけば、「/」やら「%」を使用するとリンクされる除算のライブラリ自体を置き換える素地となる。

割り算に限らずペリフェラルを扱うAPIもこの様なマクロを介して呼び出せるので、お気楽感が増すでしょう。

NXP LPC824と戯れているウチにボーレートの設定に疑問が出てきてしまった。

LPCXpressoはサンプルやライブラリも一緒に提供してくれるのでお気楽なのだが、いかんせんXpresso MAX用の設定がわんさとあって自前のものに移管させる際に結構ハマる。
普通LPCOpenのライブラリを使ってくれる事を期待しているのだろうと思い、それを無意識に使うと案の定といった感じ。とは言うもののソースがあるので、十分追うことは可能だし複雑怪奇な物は特に無いので素直にデータシートと見比べれば良いまでである。

そいでもってシリアル通信だが、やっぱり半二重や1Mbpsはさくっと出来て欲しいなぁと思って色々試したお話を。

端子はSWMまかせで好き勝手に割り当てられるのでよしとして、USARTの初期化とボーレートの設定はサンプルのまんまでも何ら問題はない。OETA|OESEL|OEPOLは半二重I/Fのバス制御にRTS端子を使う際に追加している。

#define _BAUDRATE	115200
Chip_UART_Enable (LPC_USART0);
Chip_UART_ConfigData (LPC_USART0,
 UART_CFG_DATALEN_8 | UART_CFG_PARITY_NONE | UART_CFG_STOPLEN_1 | UART_CFG_OETA | UART_CFG_OESEL | UART_CFG_OEPOL);
Chip_Clock_SetUSARTNBaseClockRate (_BAUDRATE * 16, true);
Chip_UART_SetBaud (LPC_USART0, _BAUDRATE);

後はボーレートを好きな値にすれば良い筈だが、ボーレートジェネレータがインテリジェンスなのは分かるが1Mbps以下でしか誤差率を吸収してくれないし、Chip_Clock_SetUSARTNBaseClockRate に指定しているボーレートに対する *16 なんてデータシートまともに読まないと怪しい倍数にしか思えない。

結局の所、昔ながらの明確な指定をしようとするのであれば、ライブラリを使わずに自前でレジスタを叩いた方が素直というのはどこの世界も同じ。今回は1Mbpsにしたいだけだったので、クロックを16MHzの倍数にし、予め div と mul を固定し、BRGに好きな値を入れるという方針にした。
まず sysinitほげほげ.c の中の Chip_SetupIrcClocking でPLL設定しているとこを

Chip_Clock_SetupSystemPLL(7, 0);
Chip_Clock_SetSysClockDiv(3);

てな感じにすればオーバー気味だが fclkout=96MHz, sysclk=32MHz になる。
後はUARTの初期化時に

Chip_Clock_SetUSARTNBaseClockRate ((2000000 * 8), true);
LPC_USART0->OSR = 7;

としておけば良いかな。ボーレートは

uint32_t setbaudrate (uint32_ baudrate) {
  LPC_USART0->BRG = (Chip_Clock_GetUSARTNBaseClockRate () / (8 * baudrate)) - 1;
  return (Chip_Clock_GetUSARTNBaseClockRate () / (_OSR * (LPC_USART0->BRG + 1)));
}

で決めてみてはどうでしょう。今回はOSRをデフォルトの16から8にしたが、この辺は必要に応じて変えればOK。
これで2M,1M,666k,500k[bps]といったどこかで見た様な値が選べる。

カメラをカメラで撮影する事のもの悲しさ。


ハウジングやマウントやらも必要だったのでExtreme Packで。

しかしLiveで見るにはスマホかWifi経由だけなのはこれいかに。
とりあえず今日はここまで。

トラ技の付録だったLPC81xの上位版、LPC82xシリーズ。
ピンコンパチじゃないので注意が必要だけど、 新しくA/Dコンバータが内蔵されたので楽しげな用途が。

TSSOP20なので変換基板つかえば工作も簡単、楽しそうです。

LPCXpressoを使えばエディタ・コンパイラ・デバッガ、それとサンプルも一切合切ついてこれ一つで完結するので楽ちん。


このデバイスはスイッチ・マトリックスで任意の端子にペリフェラルを割り当てられる(一部の機能を除く)ので、PLDやFPGAの様に最短経路で周辺回路とつなげられるのがヨサゲです。
ウェブ上で設定できるので、モノが無くてもどんな感じか垣間見る事ができます。


それと、タイマの機能をステートフローで記述できるのもおもしろい。

巷ではEdisonがちらほらと見受けられるように。


WiFiもBluetoothもメモリも装備されてOS入り。こんなサイズに収まってくれるとやること無いですな。
懐かしいx86互換のV25ボードを引っ張り出して並べてみました。Turbo Cが使えるのかな？んなわきゃないか。



初回ロットはコンソールの取りこぼしやら諸々イラッとするので、さらっとアップデートしましょう。

マルチディスプレイから4Kへ変更。
遅い・・・。ビデオカード買い換え必要。


入れ替えたとたんに勝手にサイズをでかくしてくれるが、100%に戻すと文字サイズがサブノート級。
LabVEIWにはうってつけのでかさだが、テキストエディタは表示方法考えないともったいなくていかん。

ここのところopenocdに手を染めていない事に気づく。久々にgitしてみると結構いい感じに修正されている様だ。

従来の設定ではlinux上でwin32ターゲットのクロスコンパイルがうまくいかない様なので、ついでということで長らくやってないMinGWでビルドしてみる。それもつまらないので、まっさらから新しくなったMinGWのインストーラで環境を再構築。後から手動でツール群を入れてたものが標準でお膳立てができてて楽ちん。

libusbxとlibftdiを適当なトコにおいて、 LIBUSB1_CFLAGSへ適当に指示してあげればよさげ。今更ながらisasciiで止まるとは...。usbprogはもう除外。
種々のプラットフォーム対応はもうちょっとといった所だが、概ね意図している事はわかった。
多少小細工は施したが、たいした問題もなく再構築完了。


ということで新しいバイナリを置いときました。

そうそう、Windows8からとっても野暮ったくなった署名なしのデバイスドライバですが、こちらの手順を踏んでからインストールして下さいね。

Dynamixel Library Version 2.9を公開しました。

今回の主な変更はタイムアウトの指定を無くしたことにあります。従来タイムアウトは受信をあきらめるまでの時間を意味し、基本的にボーレートと受信バイト数に依存するものでした。しかし受信パケットのバイト数が判然としていない限り計算が困難であった事が「パケットを意識せず」という意図からずれていると判断し、ライブラリ内で処置する事としました。
その代わりという訳ではありませんが、OSやI/Fに依存する応答性を考慮したタイムアウト値を別途設定出来るようにしました。

また先にお知らせした新しいCDCエミュレーションを使用したファームウェアを内蔵したマイコンを仲介した際に、Windowsによるポートのオープン・クローズの判定用としてDTRの制御をONにしました。

最後にLinuxで使用される際の問い合わせが大半を占める様になってきたこともあり、コンフィギュレータ以外のマイコンを仲介した場合でも使用できる様にボーレートの設定方法を見直しました。

なお、ROBO-ONE標準APIも本仕様に合わせて修正しましたので、その仕様に合わせた各社向けdllが近々公開のサーバに適用されます。

たいそうな代物ではありませんので、活用の一助になればといったところ。

1件だけならまだしも、数件のお問い合わせがあったので備忘録として。

今年の春頃から出始めた弊社のボード類の殆どには、USB-microBコネクタが装備されている。UD3.5も然り。
このコネクタは薄くて丈夫で挿抜の回数がminiよりも向上しているのが謳い文句。それと、最近のAndroidケータイにも装備されているので、ケーブルの調達がしやすい事もあって、製品に同梱する事を止めている。

ところが、量販店のケータイコーナーで不用意に調達すると痛い目に遭う。PCとケータイをUSBでつなぐ目的が「バッテリの充電」というのが大半らしく、USBケーブルのフリをした「充電専用」ケーブルが存在する。充電専用しか取り扱いが無いという店舗もあるし。
この充電専用のケーブルの殆どはUSBのバスパワーラインだけが接続されており、データラインが未結線であった。これではいくらPCを換えてもパイロットランプだけが点灯するだけで、PCからは一切認識されない訳である。

今後USBケーブルを調達する際は、説明書きを良く読んでから購入してくださいね。

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においてこのあたりを大幅に仕様変更します。

• SIMPLE TERMも他の一般的なターミナルソフトなどと同様に、ポートのオープン/クローズに連動してDTRを自前で制御。
• マイコン向けのUSB CDCエミュレーションライブラリ(SAM7S,SAM3S,STM32F3シリーズのみ)に含まれるWindows限定の判定ルーチンを止め、DTRの状態によってオープン/クローズを判定。

この仕様変更に伴う功罪は以下の通りです。

• 旧バージョンのSIMPLE TERMで新しいUSB CDCエミュレーションライブラリを使用したターゲットの仮想COMポートを開くと、見かけ上ターゲットからの応答が得られない。
• 新しいSIMPLE TERMはUSB CDCエミュレーションライブラリの新旧にかかわらず通信が行える。
• 新しいライブラリを使用したターゲットはLinuxやmacOSでもOK。
• つまり、ツールが新しくてターゲットが古い場合はOKで、ツールが古くてターゲットが新しいのがNG。

今後のGCC Developer Liteのリリースの際はこの点に留意ください。