フォーラムへの返信
-
投稿
-
doublesh6198さん
VREFHI-VREFLO間のコンデンサ容量につきましては、ADC変換のサンプリングーホールド時間（S/H時間）に影響を与えるものではございません。
S/H時間の求め方として、TMS320F2837xS Technical Reference Manual（SPRUHX5）の”10.3.2 Choosing an Acquisition Window Duration”に計算方法が記載されております。
こちらをご参照のうえ、S/H時間を算出、ご確認頂けますでしょうか。
よろしくお願いいたします。
amatsu1さん
(IoutCommand_Ch1 – IoutDetect_Ch1) < 0になった時に (IoutCommand_Ch1 – IoutDetect_Ch1)が
マイナスになることを想定しているのですが、そうなっておらず、
0になると仮定すると辻褄が合う気がします。ご指摘頂いた点ですが、_iq宣言は実際はsigned longですので、減算で負になる場合でも0になることはありません。
制御ループ内の次回に使用する演算結果（CtrlVal1_Ch1）をCMPAレジスタへの設定値から保存されていますが、CMPAの小数部は8ビットになり、CtrlVal1_Ch1=EPwm3Regs.CMPA.all;により演算結果の下位8ビットは切り捨てられます。
例として、エラー（IoutCommand_Ch1 – IoutDetect_Ch1）が1000 だった時を考えてみたいと思います。
エラーが1000の場合、左14ビットシフトしているので Ierror0_CH1は1000 << 14= 0x3E8 * 16384 = 0xFA0000になります。
K0=0.00002(=0x0000_0001)で、__IQmpy(K0,Ierror0_Ch1,16)を計算しても、0x0000_00FAとなり前回の反映値に対し加算したとしても、CMPA/CMPAHRレジスタの設定値に変化はありません。
これが、原因であると考えます。次回に使用する演算結果（CtrlVal1_Ch1）は、CMPAレジスタ設定値ではなく、以下のように、演算結果を使用してご確認頂けますでしょうか。
NxtCntVal_Ch1 = __IQmpy(K0,Ierror0_Ch1,16)+__IQmpy(K2,CtrlVal1_Ch1,16);
EPwm3Regs.CMPA.all=__IQsat(NxtCntVal_Ch1, MAX_CNTVAL, MIN_CNTVAL);
CtrlVal1_Ch1=EPwm3Regs.CMPA.all;↓
NxtCntVal_Ch1 = __IQmpy(K0,Ierror0_Ch1,16)+__IQmpy(K2,CtrlVal1_Ch1,16);
CtrlVal1_Ch1 =__IQsat(NxtCntVal_Ch1, MAX_CNTVAL, MIN_CNTVAL);
EPwm3Regs.CMPA.all = CtrlVal1_Ch1;ご確認のほど、よろしくお願いいたします。
amatsu1さん
GLOBAL_Qは16でしょうか。
小数部のビット数が16ビットの場合、小数部1ビットあたり 0.0000152587890625 となります。
そのため、GLOBAL_Q = 16において、K0= _IQ(0.00002); とすると、K0は0x0000_0001(0.0000152…)となり、約23%の誤差が発生します。K0=_IQ(0.0005)では0x0000_0020(0.00048828125)になり、約2.3%の誤差になります。小数部のビット数に対し、設定されている係数が小さすぎるために不具合が発生しているものと考えます。
つきましては、小数部ビット数に応じた有効桁数内での係数設定、あるいは小数部ビット数を大きくして計算してからCMPA設定時に16ビットに合わせていただく方法のどちらかをご検討頂く必要がございます。
小数部のビット数を大きくすると、整数部の範囲が小さくなりますので、ご注意ください。
ご確認のほど、よろしくお願いいたします。
mickey.mouseさん
申し訳ありません。
再現検証いたしましたが、一つのプロジェクトに複数のBuild Configurationを作成し、以下の操作を実行しましたが、ご指摘のリンカコマンドファイルの設定がクリアされるという現象は再現することができませんでした。
controlSUITEにあるサンプルプロジェクト、新規に作成したプロジェクトでも、再現せず複数のConfigurationで設定したリンカコマンドファイルは、設定がクリアされることはありませんでした。ローカルディレクトリを指定されると、プロジェクト内にファイルがインポートされますが、その後でプロジェクトビューの操作で対象のリンカコマンドファイルに対し”Exclude from Build”を実施されますと、設定はクリアされます。
また、ActiveでないBuild Configurationを修正される際は、修正後にOKボタンによる確定を行わずにConfigurationを変更されると、修正が反映されません。
今一度、操作手順をご確認頂けないでしょうか。
よろしくお願いいたします。
__IQmpyの第三引数は、小数部のビット数を表します。先程の回答に計算結果を記載しておりますが、第三引数を16とした場合、1.5 (0x00018000) * 1.5 (0x00018000) = 0x00024000と 整数部0x0002, 小数部0x4000となり、2.25という小数部を含む結果が得られます。整数部のみとなることはございません。
GLOBAL_Qを16として、__IQmpyのみ24とすると、ACC:Pが 0x00000002_40000000に対して8ビット左シフトとなりますので、resultは 0x0000_0240 と整数部が0、つまりCMPA=0, CMPAHR=0x02という値となります。
ご確認のほど、よろしくお願いいたします。
amatsu1さん
お問い合わせ①
GLOBAL_Qの値は16で問題ないものと考えます。
__IQmpy関数（アンダースコアが2つ）の場合には、IQmathライブラリではなく、組み込み関数（Intrinsics関数）が使用されます。この詳細動作につきましては、Compiler User’s Guideによると、以下の命令で構成されます。
long dst = __IQmpy( long A, long B, int N )
15 < N < 32 : ( 以下、XT = A が行われたあとの命令です)
IMPYL P, XT, B ; A * B の下位32bitの計算（結果はPレジスタへ）
QMPYL ACC, XT, B ; A * B の上位32bitの計算（結果はACCレジスタへ）
LSL64 ACC:P, #(32 – N) ; ACC:Pから（32-N）ビットを左シフトわかりやすく、1.5 * 1.5の計算を例に、どのような計算が行われているか考えてみます。
#define GLOBAL_Q 16
_iq A = _IQ(1.5);
_iq B = _IQ(1.5);
_iq result;result = __IQmpy( A, B, 16 );
1.5を固定小数点で表すと、0x00018000になります。
__IQmpy( A, B, GLOBAL_Q )を細かく見ていくと、IMPYL P, 0x00018000, 0x00018000 → P = 0x40000000
QMPYL ACC, 0x00018000, 0x00018000 → ACC = 0x00000002
LSL64 ACC:P, #(32-16) → ACC😛 << 16 = (0x0000000240000000 << 16) = 0x0002400000000000
ACC = 0x00024000となります。CMPA.all（CMPA(16bit):CMPAHR(8bit)）と同じフォーマットで小数点以下（CMPAHR）も設定できる構成になっています。
GLOBAL_Qは、少数ビットに何ビット使用するかを表すものですから、24を設定すると、32ビット中下位24ビットが小数部として使用されます。このとき、上記と同様に計算してみます。
#define GLOBAL_Q 24
_iq result;
result = __IQmpy( _iq(1.5), _iq(1.5), 24)結果は、result = 0x02400000となります。
この値をそのまま、CMPA.allに設定すると、整数部が期待値と異なってしまい、飽和処理でも正しい結果が出ないものと考えます。
お問い合わせ②
上記にも記載しましたが、__IQmpy関数では、3つの命令で構成されております。整数部しか使用されないのであれば、Bのシフト命令により1/4される方が、1命令少なくなりますので、その分高速になるものと考えます。
以上、ご確認のほど、よろしくお願いいたします。
-
この返信は5 年、 1 ヶ月前に Yojiro さんが編集しました。理由: Underline（Ctrl-u）が正しく反映されないため
kogaさん
申し訳ありませんが、BTLEDisconnectErrorの原因が不明の状況では、対策についてもコメントすることができません。
記載いただいた内容では、環境Aにおいては48時間エラーなしでデータ取得できていることから、CC2650STKに問題はないように見受けられます。
環境Bに問題が発生しているものと推察いたしますが、弊社ではRaspberry PiおよびBlueZスタック/bluepyに関してお答えすることができません。
切断の原因を特定には、BLEのパケットスニファなどにより、無線フローをご確認いただくことをお薦めいたします。
CC2540 USB 評価モジュール・キット または CC26x2R ワイヤレス・マイコン向け LaunchPad™ 開発キットがございましたら、こちらよりBLEのパケットスニファをご利用いただくことができます。
パケットスニファをご利用いただくことで、Raspberry Piからデータ要求のパケットが送信されているか、またCC2650STKが応答しているかなど、詳しく確認することが可能となります。また、bluepyやBlue-Zに関するご質問であれば、githubにお問い合わせいただけますでしょうか。
以上、ご確認のほど、よろしくお願いいたします。
satoshiさん
DSSにつきましては、以下のサイトに概要および使い方について記載さておりますので、こちらをご参照頂けますでしょうか。
http://downloads.ti.com/ccs/esd/documents/users_guide/sdto_dss_handbook.html
C2000向けのサンプルスクリプトファイルにつきましては、テスト向けでの用意はございません。
以下のフォルダにF28335用のFlash書き込みスクリプトが用意されております。<CCSインストールフォルダ>\ccs\ccs_base\scripting\examples\DebugServerExamples
同フォルダには、C2000向けのほか、MSP430用ですがRAMメモリ操作やブレークポイント設定などが用意されておりますので、参考にしていただけるものと思います。
DSSのAPIリファレンスにつきましては、
<CCSインストールフォルダ>\ccs\ccs_base\scripting\docs\GettingStarted.htm
から参照いただけますので、ご確認ください。
以上、ご確認のほど、よろしくお願いいたします。
mickey.mouseさん
特定ファイルのebssを対象セクションの先頭に配置するには、以下のように記述してみて頂けますでしょうか。
SECTIONS {
：
.ebss : { Filename.obj(.ebss) *(.ebss) } RUN = RAMGS3 | RAMGS4 , PAGE = 1,
RUN_START(_RamEBssStart), RUN_SIZE(_RamEBssSize)Filename.objは、変数f_lpfを定義しているオブジェクトファイルを指定してください
ワーニングの内容では、CLAオブジェクトに対するワーニングが表示されているようです。CLAではアクセス可能なメモリは、LSx（0x8000 – 0xAFFF）に限定されており、GSxメモリにはアクセスすることができません。
そのため、変数f_lpfをCPUとCLA双方でアクセスする場合は、RAMLS0～RAMLS5のいずれかに配置する必要があります。（下記例では、LS3に配置しています）
cla_ebss : { Filename.obj(.ebss) } > RAMLS3
などのように、特定ファイルのみのセクション指定が必要となります。
以上、ご確認のほど、よろしくお願いします。
doublesh6198さん
リセット解除時のGPIOは、全て入力・プルアップなしの状態となります。
ブートモードにFLASH, RAM, Waitが設定されている場合は、リセット解除時の設定がそのまま継続されます。
FLASH, RAM, Wait以外が設定された場合のGPIO設定につきましては、Technical Reference Manualの4.9.6 GPIO Assignmentsにモード毎の設定が記載されていますので、こちらをご確認ください。
ご確認のほど、よろしくお願いいたします。
amatsuさん
ご確認いただいている現象ですが、他のチャネルでもAD変換を実施されておりますでしょうか。
変換されている場合、第一に考えられるのが、対象ピンに対する変換時のADC内部のサンプリングコンデンサが完全に充電されるためのS/H時間が取られていないために、ADC SoC間でクロストークが発生しているものになります。
ADC機能モジュールでは、ADC端子に対し電圧を印加することはありませんので、ADC変換をこの1chしか実行されていない場合は、配線間のクロストークも原因の一つとなります。
以上、ご確認のほど、よろしくお願いいたします。
amatsu1さん
①サンプリング時間を長くすると添付のSwitchのON時間が長くなる為、Rsが大きくとも正しいAD検出電圧になるという理解で宜しいでしょうか
はい、ご認識のとおりです。
②以下につきまして、理解することができませんでした。大変恐縮ですが、より簡易的にご説明願います。
>ご所望のサンプリング周期に合わせる場合は、周期に対し十分なAcquisition windowとなるようにRsを変更いただく必要がございます。
一般的なサンプリング周期は、AD変換用のコンデンサにチャージする時間（Acquisition window duration）とデジタルへ変換する時間（Conversion）の2つの時間が必要となります。上記の計算式では、Acquisition window durationの時間を算出するもので、計算結果 = サンプリング時間ではありません。TMS320F28027ではConversionに13 ADC Clock必要ですので、これを加味してサンプリング周期を算出する必要があります。
つまり、ADC Clock = 60MHz（16.66ns）を設定されている環境において、計算結果が880nsとなった場合、880ns + 13 cycle * 16.66 ns = 1049ns ≒ 952KSPS となります。もし、１MSPSでサンプリングする必要がある場合、このRsでは実現することができませんので、Rsを小さくしてAcquisition window durationも小さくする必要があります。
なお、TMS320F28027では、Acquisition duration windowの設定には、7 ADC clock ～ 64 ADC clockまでの制限があり、かつその中でも設定できない値がございますのでご注意ください。設定できない値につきましては、Technical Reference ManualのADCSOCxCTLレジスタのACQPS詳細説明をご確認ください。
以上、ご確認のほど、よろしくお願いいたします。
amatsu1さん
外部に配置する抵抗・コンデンサの値とサンプリング時間は大きく関連しており、現在ご提示いただいている情報だけでは、具体的な数値をお答えすることが難しいです。
サンプリング時間（Acquisition window duration）の計算式につきましては、異なるシリーズとなりますが、TMS320F280049のリファレンスマニュアルに記載されております。
○TMS320F28004x Technical Reference Manual
http://www.tij.co.jp/jp/lit/ug/sprui33b/sprui33b.pdf
13.3.2 Choosing an Acquisition Window Durationこちらの計算式のパラメータについて、TMS320F28027のデータシートのFigure 6-20. ADC Input Impedance Modelに記載される値にて、サンプリング時間（Acquisition window duration）を計算していただけますでしょうか。
ご所望のサンプリング周期に合わせる場合は、周期に対し十分なAcquisition windowとなるようにRsを変更いただく必要がございます。
以上、ご確認のほど、よろしくお願いします。
amatsu1さん
ご指摘の現象につきましては、インピーダンスの不整合やサンプリング時間が短い場合に発生する可能性がございます。ADC内部のサンプリングバッファからのクロストークなど、さまざまな要因がありますので、一意に特定することはできません。
メーカーからは同様の問題に対し、以下の対応策が提案されております。
・抵抗サイズを小さくする
・コンデンササイズを小さくする
・サンプリング時間を大きく取る本件に関しまして、以下のTI社フォーラムが参考になるかと思いますので、ご確認いただけますでしょうか。
http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/542665
http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/697116/2570286また、ADC入力回路に関するTI社のセミナー資料もございますので、こちらもご確認いただけるとより一層ご理解いただけるものと思います。
http://www.ti.com/lit/ml/slyp166/slyp166.pdf
以上、ご確認のほど、よろしくお願いいたします。
kitadeさん
お問い合わせいただき、ありがとうございます。
Tiva製品につきましては、現在TI社HPより、「製品」→「マイコン」の製品ツリーリストから「その他のマイコン」カテゴリーにてご確認いただくことが可能となっております。
クイック・サーチにて、CPU欄に”ARM Cortex-M4F”を選択していただきますと、Tiva製品がリストアップされますので、こちらをご参照いただけますでしょうか。
http://www.tij.co.jp/ja-jp/microcontrollers/other-mcus/products.html#p887=ARM%20Cortex-M4F１．Tivaシリーズは、新規採用をやめた方が良いのでしょうか？
・もし、そうであれば、代替のマイコンがあるのでしょうか？Tivaシリーズですが、Tiva製品対応SDKであるTivaWareについて、今後更新される見込みはございません。
Tivaシリーズの後継製品としまして、MSP432E4シリーズを用意しております。
ソフトウェア（SDK）はSimplelink MSP432E4 SDKをご利用いただくものになります。
Simplelink MSP432E4 SDKのドキュメントにつきましては、こちらから参照していただくことができますので、ご確認いただけますでしょうか。LCD＋USB機能でしたら、MSP432E411Yにて対応いただけるものと考えております。
２．Tiは、Cortex M7系は対応しないのでしょうか？
大変申し訳ございませんが、現時点でCortex-M7対応製品のリリース情報は入手しておりません。
以上、ご確認のほど、よろしくお願いいたします。
-
この返信は5 年、 1 ヶ月前に