BluetoothGattCallback STATE_DISCONNECTEDでstatus=14が発生する

AndroidのBLE通信にて、BluetoothGattCallbackのonConnectionStateChange(STATE_DISCONNECTED)にて、status=14で切断される事象が発生しました。発生頻度は低く、発生後BLE通信の調子が悪化し、14が連発します。

弊方のトレースログでは、

発生頻度は低いですが、発生後BLE通信の調子が悪化し、14が連発します。 アプリを再起動すると復活します。

海外のサイトを調べると「14」は、GATT_ERR_UNLIKELY、直訳すると「ありえないエラー」です。

それ以外、WEB上には詳しい情報や事例はありません。弊方は、複数のBLE計測器機器を、シーケンシャルに読みだししています。その影響でありましょうか?

再現性も不明。エラーメッセージを表示して、ユーザに計測を中止してもらうしかありませんでした。

SERROW225 エクステンションキャリア

趣味を事業化できれば効率的です。簡単な自動車用品を開発販売できないか模索しています。

SERROW225 エクステンションキャリアの試作を紹介します。

SERROW225は足&旅パイクとしても多く利用されるようですが、Y’s Gear純正のアルミキャリアは、ちょっと小さいです。アルミ角材で拡張している方もますが、美しくない。大きすぎるのも美しくない。そこでアルミ縞板で、コンパクトな追加荷台を作成しみました。

ご興味のある方で自作は面倒な方はこちらまで。 知り合いのレース屋さんに量産を相談してみます。

HP G800に、CONTEC「DA12-8」「PIO-16」 をSD-PECPCiRi2で接続する

組込みソフトのデバック用に、任意波形発生器の必要になり、CONTECのDA/DIOボードのPCIボードを用意しました。PCI用だと種類が豊富でUSEDなら格安です。しかし今時のディスクトップではPCIバスがありません。そこで、AREA社のPCIe→PCI変換ボード「SD-PECPCiRi2」を試しました。この製品は、PC内部用とPC外部用の2つの基板に分かれています。

PCは「HP G800 SFF」、Win10。ドライバーをインストールし、DA12-8は通電し繋がりはしますが、デバイスマネージャで変換ボード「PCI to PCIブリッジ」は現れますが、「CONTEC Devices」が現れません。

DA12-8は5V駆動ですが、変換ボードの出荷値が3.3Vだったのでこれが原因かと思い、変換ボード側を5Vに切替えるとBIOSが起動しなくなりました。

「PIO-16」では、BIOSは起動するものの、変換ボード自体も認識しなくなりました。

AREA社に色々と問合せたところ、変換ボードの内部用に、PCIeバスとは別に電源供給が必要なようです。取説には接続必須とも記載されていなかったため、大電流必要時のオプションかと解釈していましたが違うようです。HP G800では、追加電源の配線が無いため接続しないままであった事情もあります。

SATA電源ケーブルの途中に、コネクタだけ追加して、変換ボードに接続しました。

外部ボード用の電源ケーブルも接続します。

これでBIOSも起動し、OSもCONTECを認識しました。

おそらくPCIeには、5Vが無いようなので、PC本体から供給が必要だったのではないかと思います。

RL78で16bit × 16bit = 32bit演算が狂う

CA78K0コンパイラで、16bit × 16bit = 32bit演算が狂う事象が発生しました。コード概略は、

U16 a=125; 
U16 b=430; 
U32 c;
 c = a * b;     // c=10になる

WindowsやAndroidアプリでは考えられない事象ですが、OS無しの16bitマイコンありがちな事象です。しかし、乗算結果の上位16bitが捨てられるありえそうですが、意味不明な演算結果です。試しにキャストを明示してもNGでした。

 c = (U32) ( a * b );     // これもNG

仕方がないので、アセンブラのコード展開をみてみました。

movw    ax,[hl+4]
movw    _@RTARG0,ax
movw    ax,[hl+8]
call    !@@iumul
clrw    bc
movw    [hl],ax
xchw    ax,bc
movw    [hl+2],ax

乗除算は、マイコンライブラリにまとめられているようです。16bit × 16bit = 32bitのmulhu命令が、なぜダイレクトに展開されないのでしょう? マイコンライブラリはあまり使わないようにしますが、元々使われていたら仕方ありません。でも怪しいのは、「clrw bc」のところです。明らかに16bit捨てられています。

キャストを明示した場合では、axレジスタの方がクリアされます。

movw    ax,[hl+4]
movw    _@RTARG0,ax
movw    ax,[hl+8]
call    !@@iumul
movw    _@RTARG0,ax
clrw    ax
movw    _@RTARG2,ax
movw    [hl+2],ax
movw    ax,_@RTARG0
movw    [hl],ax

マイコンライブラリを使用しないようにすると解消する気もしますが、全体的に、ロードモジュールに影響が生じます。正しい結果が得られるC言語の書き方を、TRY&ERRで探すしかいりません。

今回は、以下の書き方で直りました。

U16 a=125; 
U16 b=430; 
U32 c;
 c = a;      // 一旦32bit変数に入れる
 c *= b;     // c=53750になる

アセンブラ展開コードは、、、

movw    ax,[hl+4]
clrw    bc
xchw    ax,bc
movw    [hl+2],ax
movw    ax,[hl+8]
movw    _@RTARG4,ax
movw    _@RTARG6,#00H
movw    ax,[hl] 
movw    _@RTARG0,ax
movw    ax,[hl+2]
movw    _@RTARG2,ax
movw    ax,_@RTARG6
call    !@@lumul
movw    ax,_@RTARG2
movw    [hl+2],ax
movw    ax,_@RTARG0
movw    [hl],ax

clrw命令がなくなり、上下16bitがスタックに格納されていることが確認できました。だいぶコードが増えたのが気がかりです。

CS+でROMサイズ違いのマイコンに切替える

今回、製品ボートの数が少なくて、開発用に同じシーリーズでピン数のマイコンの評価ボートを購入したのですが、ROM/RAM容量が違いました。ルネサスCS+では、既存のプロジェクトから、ピン数同じでもマイコン型番変更ができないようです。

一からプロジェクト生成すると、自動コード生成やビルド設定等々を入力しなおさないといけません。ミスがあると組込みソフトでは致命的です。最初から関わっていない製品ではなおさら。

幸いプロジェクトファイルはxml形式なので、エディタで直接変更してみました。

以下の部分は、複雑なので、開発用マイコンで空プロジェクトを作成してコピーしました。

CS+を再起動して、ビルド、実行し、これで問題なさそうでした。

※くれぐれね良い子はまねしないでください。