ブログ トピックス


ニュース

    年末年始休業のお知らせ (2014/12/25)

    2014年12月27日(土)~2015年1月4日(日)の間は、年末年始休業とさせていただきます。
    • 電話・FAXによるお問い合わせはお休みいたします。
    • 電子メールによるお問い合わせ及び、オンラインショップからのご注文は、2015年1月5日以降から順次対応させていただきます。
    • 緊急の際はご案内いたしております担当の直通電話にてお受けいたします。
    何卒ご了承くださいますようお願い申し上げます。

    管理部

    BTE023B 800mm IRリフレクタ リリースのお知らせ (2014/12/12)

    「BTE023 800mm光センサ」の後継として「BTE023B 800mm IR リフレクタ」の販売を開始いたしました。
    旧来との差異として、外形互換なし・感度調整廃止・コネクタからケーブルに変更といった点がありますが、検出距離の特性はほぼ同等となっております。

    なお、本リリース以前に製品情報を掲示しておりましたため、その間にご予約頂いたお客様には本日出荷させていただいております。


    ショップページへ
    商品名:800mm IRリフレクタ
    商品番号:BTE023B
    価格:¥2,700. (税別)
    付属品:センサ本体

    詳細はこちらをご覧ください。

    TINY JTAG-ICE2入荷のお知らせ (2014/12/05)

    TINY JTAG-ICE2が1年ぶりに入荷致しました。
    一部パーツを代替した上で互換性を有しております。



    なお、この間にopenocdのバージョンアップが頻繁に行われている都合、最新版を使用しますと従来の設定では利用できないケースが必ず発生すると思われます。
    各デバイスに応じた設定等はドキュメントホームページを参照ください。

    管理部

ニュースのトップへ

ブログ

    GCC Developer Liteの更新は? (2015/01/13)

    新しもの好きの作者の割には、パブリック向けの更新が滞っている様です。
    カスタムターゲット向けのパッケージはそこそこ更新されていますが、ツール類は特段変わった様子も無く枯れたままだったり。

    そんな中、作者より更新の案内がありました。
    ソースの編集は1ファイルに限定している事もあって有用性は無いと判断し、公には活性化されていないタグジャンプ機能を、今後のリリースでは使えるようにするらしく。

    既にターゲットによってはサポートファイル類が肥大化しており、それらを使用する場合はソースやヘッダファイルを参照せざるを得ない状況です。
    また、シングルソースであっても、長大であれば短期記憶をアテに自分のソースを移動するのは骨が折れますし、数日もすればおぼろげな記憶のレイアウトはアテにならなくなってくるでしょう。

    Eclipseをはじめ、最近のIDEの類はプロジェクト中のファイルを解析して、編集作業をしやすくする機能が当然の様に備わっています。
    GCC Developer Liteは単なるテキストエディタと称している割に、そこそこ中途半端に変な機能が備わってはいますが、広大なソースファイル類を手に取る様に見渡す事はできません。

    これらから、タグジャンプ機能の公開が迫られていたという背景がありました。

    今回の機能解放では、外部のコマンドを併用してソースファイル中の単語の関連性を簡易的に調べて、宣言されている場所を渡り歩く事ができる様になります。

    タグファイルが生成されてさえいれば、カーソル位置の単語をタグファイルから検索させ、その単語を含むソースファイルの該当位置へジャンプ(タグジャンプ)させる事ができますし、ジャンプした履歴を逆に辿る事もできます。

    背反事項として、設定によってはタグファイルのサイズがソースファイルのサイズとは関係なく大きくなる事がありますが、ハードディスクもSSD化が進み速度的に有利な環境が整いつつあるので、本ツールを活用されている方向けに活性化する事としました。

    ちなみに、ゼロからプログラムを書き進める時よりも既存のソースファイルを読み進めるための機能なため、とりあえずは大きめのサイズになりがちのFDIII-HCやUD3のサンプルプログラムを読むには良いでしょう。

    近々公開されるであろう更新版では、この機能が活性化していると思います。

    技術

    ROM API (2014/12/26)

    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もこの様なマクロを介して呼び出せるので、お気楽感が増すでしょう。

    LPC8xxのボーレート (2014/12/11)

    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]といったどこかで見た様な値が選べる。

    技術

    DYNAMIXE PROシリーズの通信プロトコルについて (2014/11/19)

    PROシリーズはMXシリーズやAXシリーズとは異なる通信プロトコル(V2.0)で運用され、従来(V1.0)との相互互換性は無い。また、XL-320もPROシリーズと同類だが、完全互換でもない。
    V1.0 Status Packet

    V2.0 Status Packet


    PROシリーズは扱うアドレスやデータのサイズが大きくなっている都合、自ずとパケットの構成要素のサイズが大きい。
    そういった面からV2.0ではチェックサムはCRCになり、最大通信速度が10Mbpsに上がっているので、ハード同様に多少なりとも堅牢で応答性の良い環境にはなっている。

    それとは別に、V2.0の通信プロトコルにおいて今まで指摘されなかった事を良い事に、仕様と実態が異なる事をライブラリ内でクローズしていた。
    実際にはステータスパケット中のErrorはV1.0と同じ挙動をしているが、本来はそれとは異なるものとしている。

    プロトコルの処理を独自に組み込んで使用する際は、現時点では「とりあえず」ErrorはV1.0と同様に各要因がビットアサインされているものとして処理してもらう他ない。
    最終的にどのように修正されるかは流動的だが、V2.0の仕様に合わせたファームウェアの改修で対処する方針の様なので、いずれ変更せざるを得ない事をお忘れ無きよう。

    技術

ブログのトップへ