FC2ブログ

名張市つつじが丘おもちゃ病院

三重県名張市つつじが丘でおもちゃの病院を開院しています。年中無休で修理は無料、部品代のみ実費です。おもちゃの修理依頼は tutuji@cb4.so-net.ne.jp へメールにてご連絡下さい。なお、宅配便での受け付けは行っておりません。このブログにはおもちゃ等の修理事例やツール製作などを載せていきます。故障診断や修理方法の改善等、ご意見をお寄せ下さい。

トイラジ換装用2.4GHz無線アセンブリの頒布(CCPデジプロ用とフルアクション用の統合)

トイラジ換装用2.4GHz無線アセンブリの頒布外観
【前振り】
つつじが丘おもちゃ病院では、上記の「2.4GHzラジコン用無線アセンブリ」を頒布している。2.4GHzトランシーバとエンコーダ/デコーダで構成されていて、トイラジの無線制御部分が故障したときにそれを換装するために開発したものだ。

・CCPデジプロ用

・フルアクション用

の2種類を用意しているのだが、頒布する品物を区別して扱うのがメンドーになった。頒布を受けた方も在庫を別々に持つ無駄が生じる。

そこで、CCPデジプロ用とフルアクション用を統合して、1種類にしてどちらにも使えるようにした。


【設計】
CCPデジプロとフルアクションは別の制御方式なので、相互に使い回しをされたらおもちゃに予期せぬ故障を引き起こすかも知れない。そのため、別物として頒布するのが当初の考えだった。しかし、制御タイプの動的な変更をしないことと異なる制御タイプ間でのペアリングをできなくすれば1種類に纏めても問題は無い。

元々基板は共通で、搭載するファームウェアを別にしていた。別と言っても、ch毎に制御タイプをフルアクション、ESC、プロポの3タイプから#defineで選べるようにしていて、ソースコードは共通化されている。あとは、制御タイプを決定するやり方を検討すればよい。

MCLR機能を使っていないのでMCLRピンが空いている。POR時にMCLRピンのレベルを判定して制御タイプを決定する。

・POR後にMCLRピンがHのときはフルアクション

・POR後にMCLRピンがLのときはCCPデジプロ

MCLRピンは内部プルアップしておき、CCPデジプロ用に使うときはMCLRピンを外部でLにする。但し、MCLRピンを直接GNDに繋ぐとICSPができなくなるので抵抗を挿入しておく。ICSPを行わないのであれば直接GNDに繋いでもよい。

省電力対応のため、動作モードを決定後はMCLRピンがLのときは内部プルアップを停止する。


以下は、元記事「 トイラジ換装用2.4GHz無線アセンブリの頒布 」から今回の変更内容を加筆修正して再掲している。

【頒布する物】
基板の厚さは約6mm。また、トランシーバとPIC基板とはビニール線で繋いでいるので自由に曲げられ、元のおもちゃに収容し易い。2つ折りにもできるが、基板同士が接触して短絡しないように注意すること。

CCP社G-DRIVE及びW-DRIVEのデジプロ対応 と フルアクションタイプ に対応している。

汎用の「無線リモコンモジュール」(JDY-40TY24Dなど)を利用すると 通信阻害やコントローラの操作により誤動作を起こし、Hブリッジに貫通電流が流れて回路が破壊する ことがあるが、本無線アセンブリはトイラジの制御に特化した設計になっているので、そのような誤動作はなく安全に換装することができる。

ノーコン状態になった場合は車体が自動停止するように、フェールセーフの設計になっている。

デジプロ対応の前後進の操作フィーリングはオリジナルに合わせているので、換装後に操作の違和感がない。

トランシーバはnRF24L01の種類及びそのDIPタイプとSMDタイプの組み合わせで各種の商品が流通していて、頒布依頼時にそれらの指定はできない。なお、上記の画像にあるトランシーバは現在確認しているもののなかでサイズが最大のものだ。

コントローラ側と車体側の双方を本アセンブリで換装する。元のトイラジとの互換性は無い。


【頒布の条件】
①おもちゃ病院の活動でおもちゃの修理に使用する、若しくはそのための事前評価に使用することを目的とすること。

②転売等の商用利用をしないこと。また、当方からの頒布代金を超える部品代実費等をおもちゃの修理依頼者から徴収しないこと。

③当方で動作確認済みのものを出荷するが、頒布先での動作保障はしない。当方の責任範囲はジャンク品として現物を提供するのみとする。

④数量に限りがあるので頒布希望に応えられない場合がある。


【依頼方法と頒布代金】
①頒布希望者は下記事項を明示してメールにて当おもちゃ病院へ申し出ること。記事へのコメントで頒布希望を書いても対応しない。

・コントローラ側の台数 と 車体側の台数

・電源電圧の瞬低対応(16LF1503への変更)の要否

②頒布代金は部品の調達実費と郵送料となる。

・部品の調達実費は調達先と時期により変動するが1台当たり150円程度の見込み。16LF1503は数10円アップする。

・郵送料は、少量の場合は定形普通郵便で送付することができる。

③見積りと支払い方法の案内を当方から返信する。


【換装事例】
CCP社W-DRIVEプラスを換装した事例

CCP社G-DRIVEエコプラスを換装した事例


【設計情報】
電源電圧が3.3V標準 であることと、操作ボタンやHブリッジとのインタフェース が修理対象のトイラジに適合することを確認しておくこと。

・本アセンブリの動作電圧は2.3~3.6V

・操作SWからの入力は負論理

・Hブリッジへの出力は正論理

下記回路図の赤枠内が本アセンブリに該当する。

・デジプロ対応の回路
詳細は CCP社G-DRIVE及びW-DRIVEのデジプロ対応 を参照のこと。

前後進操作ボリュームは、元の結線から下記の回路図の結線に変更する必要がある。

コントローラ側(DIPタイプ)
トイラジ換装用2.4GHz無線アセンブリの頒布CCPコントローラ側DIP回路図

コントローラ側(SMDタイプ)
トイラジ換装用2.4GHz無線アセンブリの頒布CCPコントローラ側SMD回路図

車体側(DIPタイプ)
トイラジ換装用2.4GHz無線アセンブリの頒布CCP車体側DIP回路図

車体側(SMDタイプ)
トイラジ換装用2.4GHz無線アセンブリの頒布CCP車体側SMD回路図
 
・フルアクションの回路
詳細は フルアクションタイプ を参照のこと。

操作SWは負論理を想定している。元の回路が正論理の場合はカスタマイズで対応可能。

コントローラ側(DIPタイプ)
トイラジ換装用2.4GHz無線アセンブリの頒布FAコントローラ側DIP回路図

コントローラ側(SMDタイプ)
トイラジ換装用2.4GHz無線アセンブリの頒布FAコントローラ側SMD回路図

車体側(DIPタイプ)
トイラジ換装用2.4GHz無線アセンブリの頒布FA車体側DIP回路図

車体側(SMDタイプ)
トイラジ換装用2.4GHz無線アセンブリの頒布FA車体側SMD回路図

トランシーバのピン接
トイラジ換装用2.4GHz無線アセンブリの頒布ピン接

おもちゃに実装するときにMCLRピンを以下のようにする。

・フルアクションのときはMCLRピンをオープンにする。

・CCPデジプロのときはMCLRピンをGNDに繋ぐ。ICSPを行うときは下記のように3.3kΩを挿入してGNDへ繋ぐ。
トイラジ換装用2.4GHz無線アセンブリの頒布CCPコントローラ側DIP回路図新
トイラジ換装用2.4GHz無線アセンブリの頒布CCPコントローラ側SMD回路図新
トイラジ換装用2.4GHz無線アセンブリの頒布CCP車体側DIP回路図新
トイラジ換装用2.4GHz無線アセンブリの頒布CCP車体側SMD回路図新

【ダウンロード】
上記の換装回路図は ここから ダウンロードできる。

ファームウェアの設計情報とプロジェクト一式は ここから ダウンロードできる。プジェクトは以下の通り。

nRF24L01+のコントローラ側は RC24_nRF24L01_TX_FACCP_1503.X
nRF24L01+の車体側は RC24_nRF24L01_RX_FACCP_1503.X
SE8R01のコントローラ側は RC24_SE8R01_TX_FACCP_1503.X
SE8R01の車体側は RC24_SE8R01_RX_FACCP_1503.X


【カスタマイズ】
本無線アセンブリの設計条件が修理対象のおもちゃに適合しない場合は以下の方策を検討する。

・おもちゃ側の回路を変更して、本無線アセンブリのインタフェースに合わせる。

・おもちゃ側の回路に合わせて、本無線アセンブリのインタフェースをカスタマイズする。

メールにて要件を提示いただければ検討する。
スポンサーサイト



  1. 2020/07/03(金) 12:28:19|
  2. 2.4GHzラジコン
  3. | コメント:0

2.4GHzラジコン用ファームウェアの改善(ソースファイルの整理)

トイラジ換装用2.4GHz無線アセンブリの頒布外観
【前振り】
2.4GHzラジコン用ファームウェア のプロジェクトは、トランシーバの種類・機能モデル・PICのデバイスの組み合わせの数だけある。それぞれにソースファイルがあり、内容は殆ど同じだが微妙に違っている。これが、改善作業を煩雑にして間違いを生む要因になっている。


【実施内容】
2.4GHzラジコン用ファームウェアのソースコードの整理をした。

ソースコードの同じ部分を切り出して共通ファイルとし、違う部分を個別ファイルとした。#define や #if でコードの共通化も行った。

機能は変わらないので利用者にとってはメリットは無いが、開発側としてはメンテナンス性がかなり向上した。


【ダウンロード】
設計資料とファームウェアの開発プロジェクト一式は ここから ダウンロードできる。

プロジェクト名と根のソースファイル名は同じ。

プロジェクト名にトランシーバの種類・機能モデル・PICのデバイスを織り込んでいる。

CC2500とA7105はデモモデルしかない。このトランシーバは比較的高価なのでおもちゃ修理に使うことは無いと思うが、CCPデジプロ対応やフルアクションタイプの要望があれば対応する。
  1. 2020/06/19(金) 20:54:07|
  2. 2.4GHzラジコン
  3. | コメント:0

2.4GHzラジコン用ファームウェアの改善(ペアリング機能の改善)

トイラジ換装用2.4GHz無線アセンブリの頒布外観
【前振り】
先般は、2.4GHzラジコン用ファームウェアでペアリング機能 を装備した。

コントローラに固有のバンド番号を付与しておき、ペアリングの操作によって車体側へバンド番号を伝えて、以降はそのコントローラからの指令しか受け付けないようにする。

バンド番号は0~7の値であり、同時に8台まで同時に走行させることができる。しかし、このファームウェアの普及が進んで行く(かも知れない)ことを考えると、同じバンド番号を持つコントローラが近辺に存在する危険性が出てくる。マイナンバーのように個々のコントローラに違った番号を付与すればそのような心配は無用になる。


【設計】
早い話がデータペイロードを増やしてバンド番号のビット数を拡大すればいい訳だ。しかし、データペイロードを大きくするとエアー占有時間が長くなり送信が衝突する確率が増える。

今回はデータペイロードの長さは変えずにデータの意味付けと配置を変えることで、固有の番号を14ビットに拡大することができた。固有番号の呼び方も「バンド番号」から「バインド番号」に変えて、情報の意味に合うようにした。

14ビットの数値の範囲は0~16383であり、いくら普及が進んでも十分に賄えると思う。

旧の定義
2.4GHzラジコン用ファームウェアの改善(ペアリング機能の改善)旧仕様

新の定義
2.4GHzラジコン用ファームウェアの改善(ペアリング機能の改善)新仕様

バインド番号のファームウェアへの埋め込みは #define で行う。

設定例
2.4GHzラジコン用ファームウェアの改善(ペアリング機能の改善)BIND宣言


もう一つ見直したことがある。従前は、車体側のファームウェアはコントローラから送られてくる制御タイプを受け入れて、その制御タイプで動作する。この仕組みはデモ運用では都合が良いのだが、実際のおもちゃでは車体側の制御タイプは決まっていて、ファームウェアがそれと違った動作をしてはいけない。

それで、今回は車体側のファームウェアで制御タイプを固定できるようにした。ソースコード上の #define で制御タイプを宣言する。

設定例)
2.4GHzラジコン用ファームウェアの改善(ペアリング機能の改善)CNT_TYPE宣言

宣言されない場合はコントローラから送られた制御タイプで動作するデモ運用となる。


【ダウンロード】
ファームウェアの設計資料と開発プロジェクトは ここから ダウンロードできる。

ホルダ名とプロジェクト名に、トランシーバのデバイス名・送信側/受信側の別・PICのデバイス名を織り込んでいる。「MON」が付いたプロジェクトは、開発時に使う受信モニタで、おもちゃには実装しない。
  1. 2020/06/19(金) 20:04:51|
  2. 2.4GHzラジコン
  3. | コメント:0

2.4GHzラジコン用ファームウェアの改善(ペアリング機能)

トイラジ換装用2.4GHz無線アセンブリの頒布外観
【前振り】
汎用の2.4GHzトランシーバモジュールを使った 2.4GHzラジコン用ファームウェア を開発し、 トイラジコンの修理用に頒布 している。

おもちゃ病院でのトイラジコンの修理に供することを目的としていて、元々のラジコンとは互換が無いため、このファームウェアで複数台を制御することは想定していなかった。そのため、コントローラ側と車体側は括り付けで、不特定多数でのペアリング機能はない。

しかし、 無線アセンブリの頒布 を始めて、今後はこのファームウェアが普及していく(かも知れない)ことを考えると、ペアリング機能は合った方がよいと考えた。


【設計】
操作がし易く、且つ処理が簡易なペアリングの方法を考えた。その手順は

・先に車体側を電源オンする。車体側はコントローラからのペアリング信号を待つ。

・次にコントローラ側を電源オンする。コントローラ側はペアリング信号を2ms周期で10回送る。この周期と回数の設計は後述。

・コントローラ側は通常の運転操作に移る。

・ペアリング信号にはバンド番号(コントローラの識別番号)と制御タイプ(CCPデジプロやフルアクションなど)を含んでいる。

・車体側はペアリング信号を受信して、バンド番号と制御タイプを取り込む。

・以降は、車体側はバンド番号と制御タイプが一致する操作信号のみを受け付ける。

バンド番号は0~7の値で、コントローラ側のファームウェアにハードコードする。従って、8台のコントローラを同時に運用可能とする。

周波数ホッピングはサポートしない。複数台で同一のキャリア周波数を使うので衝突が発生するが、コントローラの送信周期をずらせることで衝突を回避する。コントローラの送信周期はWDT周期にすることで、数%の個体差が生じるのでこれを利用する。

ボーレートが低い方が通信の安定性が良いことを実機で確認しているので、SE8R01では500kbps、nRF24L01では250kbpsとする。キャリア専有時間(送信時間)を短くするためにデータペイロードを必要最小限の4バイトにした。

キャリア専有時間は実測400usであるため、フレーム周期を長めにとる。フレーム周期を32msにしても8台運用時のキャリア輻輳率は10%になり、非同期マルチユーザ通信としてはこれが限度だ。

従来のファームウェアにペアリングのフェーズ付け加えて、ペアリングが完了後に通常の運転操作に進むようにした。

ペアリング信号の送信周期と回数は以下のように考えた。

・衝突を1フレームに抑えるため、全体をフレーム周期(32ms)以下とする。

・送信回数は自分以外のコントローラの数(7)より多くして、衝突せずに伝わることを担保する。

・送信間隔は自分と衝突相手のキャリア専有時間よりも長くする。


【ダウンロード】
ファームウェアの設計資料と開発プロジェクトは ここから ダウンロードできる。

ホルダ名とプロジェクト名に、トランシーバのデバイス名・コントローラ側(TX)/車体側(RX)の別・PICのデバイス名を織り込んでいる。「MON」が付いたプロジェクトは、開発時に使う受信モニタで、おもちゃには実装しない。
  1. 2020/06/09(火) 19:54:23|
  2. 2.4GHzラジコン
  3. | コメント:0

トイラジ換装用2.4GHz無線アセンブリの頒布(16LF1503をサポート)

トイラジ換装用2.4GHz無線アセンブリの頒布外観
【背景】
先般 トイラジ換装用2.4GHz無線アセンブリの頒布 を始めたが、制御マイコンに16LF1503を選択することを可能にした。

CCP社G-DRIVE(2.4GHz)、W-DRIVE(2.4GHz)などでは車体側に3.3Vレギュレータを装備しているので、無線アセンブリに安定な電源を確保できる。

しかし、一般のフルアクションラジコンで電池2本(3V)での運用となっているものではモーター起動時に電源電圧が瞬低し、制御マイコンがPORしてしまうことがある。

制御マイコンを16LFタイプにすることで、無線アセンブリの動作電圧範囲を1.9~3.6Vに拡大できる。

【設計】
回路は トイラジ換装用2.4GHz無線アセンブリの頒布 と同じ。マイコンを「16LF1503」に読み替え、電源電圧値を「1.9~3.6V」に読み替える。

【依頼方法と頒布代金】
①部品の調達実費が数10円ほど高くなる。

②頒布依頼時に 「16LF1503」 と明記する。

③その他の事項は トイラジ換装用2.4GHz無線アセンブリの頒布 のとおり。
  1. 2020/06/03(水) 07:51:23|
  2. 2.4GHzラジコン
  3. | コメント:0

トイラジ換装用2.4GHz無線アセンブリの頒布

【前振り】
2.4GHzラジコンの修理で故障した無線モジュールとエンコーダ/デコーダの換装用にnRF24L01(オリジナルのnRF24L01+及びその類似品であるSE8R01を指す、以下同様)を制御するPIC用のファームウェアを当ブログで公開している。しかし、流通しているnRF24L01の全てのバージョンで動作確認している訳ではなく、実際の修理に応用するときに用意したnRF24L01との互換性に不安を持つと思う。

そこで、動作確認済みのnRF24L01と16F1503のアセンブリを有償で頒布することにした。

本記事を公開後に機能改善を行っていて、最新情報は「 トイラジ換装用2.4GHz無線アセンブリの頒布(CCPデジプロ用とフルアクション用の統合) 」を参照。


【頒布する物】
トイラジ換装用2.4GHz無線アセンブリの頒布外観

基板の厚さは約6mm。また、トランシーバとPIC基板とはビニール線で繋いでいるので自由に曲げられ、元のおもちゃに収容し易い。2つ折りにもできるが、基板同士が接触して短絡しないように注意すること。

CCP社G-DRIVE及びW-DRIVEのデジプロ対応 と フルアクションタイプ に対応している。両者は、ハードウェアは全く同じであるが搭載するファームウェアが異なる。ファームウェアを書き替えればどちらにも使える。

汎用の「無線リモコンモジュール」(JDY-40TY24Dなど)を利用すると 通信阻害やコントローラの操作により誤動作を起こし、Hブリッジに貫通電流が流れて回路が破壊する ことがあるが、本無線アセンブリはトイラジの制御に特化した設計になっているので、そのような誤動作はなく安全に換装することができる。

ノーコン状態になった場合は車体が自動停止するように、フェールセーフの設計になっている。

デジプロ対応の前後進の操作フィーリングはオリジナルに合わせているので、換装後に操作の違和感がない。

トランシーバはnRF24L01の種類及びそのDIPタイプとSMDタイプの組み合わせで各種の商品が流通していて、頒布依頼時にそれらの指定はできない。なお、上記の画像にあるトランシーバは現在確認しているもののなかでサイズが最大のものだ。

コントローラ側と車体側の双方を本アセンブリで換装する。元のトイラジとの互換性は無い。


【頒布の条件】
①おもちゃ病院の活動でおもちゃの修理に使用する、若しくはそのための事前評価に使用することを目的とすること。

②転売等の商用利用をしないこと。また、当方からの頒布代金を超える部品代実費等をおもちゃの修理依頼者から徴収しないこと。

③当方で動作確認済みのものを出荷するが、頒布先での動作保障はしない。当方の責任範囲はジャンク品として現物を提供するのみとする。

④数量に限りがあるので頒布希望に応えられない場合がある。


【換装事例】
CCP社W-DRIVEプラスを換装した事例

CCP社G-DRIVEエコプラスを換装した事例


【設計情報】
電源電圧が3.3V標準 であることと、操作ボタンやHブリッジとのインタフェース が修理対象のトイラジに適合することを確認しておくこと。

・本アセンブリの動作電圧は2.3~3.6V

・操作SWからの入力は負論理

・Hブリッジへの出力は正論理

下記回路図の赤枠内が本アセンブリに該当する。

・デジプロ対応の回路
詳細は CCP社G-DRIVE及びW-DRIVEのデジプロ対応 を参照のこと。

前後進操作ボリュームは、元の結線から下記の回路図の結線に変更する必要がある。

コントローラ側(DIPタイプ)
トイラジ換装用2.4GHz無線アセンブリの頒布CCPコントローラ側DIP回路図

コントローラ側(SMDタイプ)
トイラジ換装用2.4GHz無線アセンブリの頒布CCPコントローラ側SMD回路図

車体側(DIPタイプ)
トイラジ換装用2.4GHz無線アセンブリの頒布CCP車体側DIP回路図

車体側(SMDタイプ)
トイラジ換装用2.4GHz無線アセンブリの頒布CCP車体側SMD回路図
 
・フルアクションの回路
詳細は フルアクションタイプ を参照のこと。

操作SWは負論理を想定している。元の回路が正論理の場合はカスタマイズで対応可能。

コントローラ側(DIPタイプ)
トイラジ換装用2.4GHz無線アセンブリの頒布FAコントローラ側DIP回路図

コントローラ側(SMDタイプ)
トイラジ換装用2.4GHz無線アセンブリの頒布FAコントローラ側SMD回路図

車体側(DIPタイプ)
トイラジ換装用2.4GHz無線アセンブリの頒布FA車体側DIP回路図

車体側(SMDタイプ)
トイラジ換装用2.4GHz無線アセンブリの頒布FA車体側SMD回路図

トランシーバのピン接
トイラジ換装用2.4GHz無線アセンブリの頒布ピン接


【カスタマイズ】
本無線アセンブリの設計条件が修理対象のおもちゃに適合しない場合は以下の方策を検討する。

・おもちゃ側の回路を変更して、本無線アセンブリのインタフェースに合わせる。

・おもちゃ側の回路に合わせて、本無線アセンブリのインタフェースをカスタマイズする。

メールにて要件を提示いただければ検討する。


【ダウンロード】
上記の換装回路図は ここから ダウンロードできる。

ファームウェアの設計情報とプロジェクト一式は ここから ダウンロードできる。プジェクトは以下の通り。

nRF24L01+のデジプロ対応コントローラ側は RC24_nRF24L01_TX_CCP_1503.X
nRF24L01+のデジプロ対応車体側は RC24_nRF24L01_RX_CCP_1503.X
nRF24L01+のフルアクションコントローラ側は RC24_nRF24L01_TX_FA_1503.X
nRF24L01+のフルアクション車体側は RC24_nRF24L01_RX_FA_1503.X
SE8R01のデジプロ対応コントローラ側は RC24_SE8R01_TX_CCP_1503.X
SE8R01のデジプロ対応車体側は RC24_SE8R01_RX_CCP_1503.X
SE8R01のフルアクションコントローラ側は RC24_SE8R01_TX_FA_1503.X
SE8R01のフルアクション車体側は RC24_SE8R01_RX_FA_1503.X


【依頼方法と頒布代金】
①頒布希望者は下記事項を明示してメールにて当おもちゃ病院へ申し出ること。記事へのコメントで頒布希望を書いても対応しない。

・CCP社デジプロ対応かフルアクションタイプかの別 (指定されたファームウェアを書き込んで発送する)

・コントローラ側の数量 と 車体側の数量

②頒布代金は部品の調達実費と郵送料となる。

・部品の調達実費は調達先と時期により変動するが150円程度の見込み。

・郵送料は、少量の場合は定形普通郵便で送付することができる。

③見積りと支払い方法の案内を当方から返信する。
  1. 2020/05/13(水) 12:09:12|
  2. 2.4GHzラジコン
  3. | コメント:0

PWMで50Hz正弦波を出力する(その3)

ブログの読者から、 「PICでPWMを使用でマシン語を使って50Hzのサイン波を正相と逆相を二つ作りたい」 との依頼を請けてファームウェアを開発した。本記事はその続編である。依頼者から未だに評価をいただけず、更に改善を施した。


【設計】
PWMで50Hz正弦波を出力する(その2)」 に対して以下の改善を施す。

・PWMをCenterAlignedモードで出力することで位相歪みを低減する。

但し、PWM分解能は1/2になって量子化ビット数が1ビット分減ることになるので、総体的に改善になるのかどうかは依頼者の評価次第だ。


【評価】
PWM出力波形
出力波形ブリッジ

上図ではCenterAlignedモードになっていることが確認できないので、逆相に極小のデューティサイクルを出力させて、正相がCenterAlignedモードになっていることを検証した。
出力波形センターアライングモード検証

僕の耳で聴いた感じでは、音質の変化は全く感じられない。。。


【ダウンロード】
開発したファームウェアと波形サンプルデータは ここから ダウンロードできる。

プロジェクトは URUTA20200416_1572_CMP_CTR.X と URUTA20200416_1572_BTL_CTR.X

波形サンプルデータは wave.xls
  1. 2020/04/19(日) 09:36:13|
  2. 電子オルゴール+音声再生
  3. | コメント:0

PWMで50Hz正弦波を出力する(その2)

ブログの読者から、 「PICでPWMを使用でマシン語を使って50Hzのサイン波を正相と逆相を二つ作りたい」 との依頼を請けてファームウェアを開発した。本記事はその続編である。


【設計】
PWMで正弦波を生成する事例はネット上に沢山ある。なのに、当方へ依頼されたと言うことは、あまり一般的ではない要件なのではないかと思った。

「正相と逆相を二つ作りたい」 とはコンプリ出力のことではなく、ブリッジ出力で後段をBTL駆動したいのではないかと考えた。そのような事例は見かけない。それで、設計を変更したプロジェクトを追加した。

・ターゲットデバイスは12F1572で変えない。


・正相と逆相の出力

PWM1で正相分を出力し、PWM2で逆相分を出力する。PWM1とPWM2は交互に稼働する。


・PWM設定

PWMクロックはFoscの32MHzとする。

50Hzの半サイクル時間の延べPWMステップ数は

 32MHz/50Hz/2=320k

となる。

PWMステップ数×波形サンプル数=320k になり、PWMステップ数と波形サンプル数のバランスが良い組み合わせとして

 PWMステップ数(正相分)=500
 波形サンプル数(半周期分)=640

を選定した。

ブリッジ出力であるので、正相と逆相を合わせた実効的なPWMステップ数は1000になる。
また、1周期分の波形サンプル数は1280になる。


【評価】
PWM出力波形
出力波形ブリッジ

【ダウンロード】
開発したファームウェアと波形サンプルデータは ここから ダウンロードできる。

プロジェクトは URUTA20200416_1572_BTL.X

波形サンプルデータは wave.xls
  1. 2020/04/18(土) 15:52:45|
  2. 電子オルゴール+音声再生
  3. | コメント:0

PWMで50Hz正弦波を出力する

ブログの読者から、「PICでPWMを使用でマシン語を使って50Hzのサイン波を正相と逆相を二つ作りたい」との依頼を請けてファームウェアを開発した。


【設計】
要件は上記の一言で、ターゲットデバイスや詳細な要件は当方でテキトーに決めた。

・ターゲットデバイス

PWM性能が良くて廉価な12F1572を選定した。


・正相と逆相の出力

CWGでコンプリ波形を作る。


・PWM設定

PWMクロックはFoscの32MHzとする。

50Hzの1サイクル時間の延べPWMステップ数は

 32MHz/50Hz=640k

となる。

PWMステップ数×波形サンプル数=640k になり、PWMステップ数と波形サンプル数のバランスが良い組み合わせとして

 PWMステップ数=800
 波形サンプル数=800

を選定した。


【評価】
PWM出力波形
出力波形コンプリ
出力波形コンプリ2

LPF後の波形
出力波形LPF後
見た目には綺麗な波形が生成できている。


【ダウンロード】
開発したファームウェアと波形サンプルデータは ここから ダウンロードできる。

プロジェクトは URUTA20200416_1572_CMP.X

波形サンプルデータは wave.xls
  1. 2020/04/17(金) 15:17:39|
  2. 電子オルゴール+音声再生
  3. | コメント:0

PIC電子オルゴールVer6_2の改善(タッチセンスのAPI提供の続き)

【前振り】
先般、 PIC電子オルゴールでタッチSWの操作状態を取得するAPI を提供したのだが、そのオマケとして、タッチSWが1個のみ実装しているケースでのAPIも提供した。

タッチSWが1個実装時にも先般提供したAPIを使うことは可能だが、複数個を前提としたコードは嵩張るので、1個のみの実装を前提としてコードの縮小を図る。


【設計】
①複数個のタッチSWに対する繰り返しロジックを削除する。

②その他の要件は先般のAPIを踏襲する。

③API関数

・エントリ名 tsw_sts

・パラメータ無し。

・戻り値はWレジスタにタッチSW操作状況を返す。

Wレジスタの値
     0=操作無し(タッチ開始から短タッチに至る前を含む)
     1=短タッチ(短タッチ以上タッチ後に離された)
     2=長タッチ(長タッチ以上タッチされた)

・短タッチ/長タッチを返した場合、タッチ状況がクリアされる。

④提供形態

・タッチセンスはCdSやRFIDと同様にPIC電子オルゴールのエンジン機能としては位置付けられない。このため、固有部のコードとして提供する。


【使用例】
PIC電子オルゴールVer6_2の改善(タッチセンスのAPI提供の続き)使用例

【ダウンロード】
orgel6_2は ここから ダウンロードできる。

本記事の対象プロジェクトは orgel_1840.X
  1. 2020/04/11(土) 17:49:32|
  2. 電子オルゴール+音声再生
  3. | コメント:3

PIC電子オルゴールVer6_2の改善(タッチセンスのAPI提供)

【前振り】
PIC電子オルゴールでは、タッチSWの評価はCPSカウントの固定タイムベースの精度を確保するためPWM周期割り込み処理で実行している。アプリ処理とは非同期に行っていて、処理ロジックもアプリとは関連させないようにしている。

今まではタッチセンス処理の管理情報をアプリに見せることで、タッチSWの操作状況をアプリ側で判断するようにしてきた。そのため、アプリから見てタッチセンス処理をブラックボックスにはしていなかった。これはタッチセンス処理もアプリ処理も僕が設計しているのでそれでよかったのだが、誰にでもアプリを設計して貰うためにはタッチセンス処理をブラックボックス化して、タッチSWの評価結果を取得するAPI関数を提供する必要がある。


【設計】
①マルチタッチは非サポート

・最初からネガティブな言い方だが、マルチタッチは技巧的には面白いのだがおもちゃ修理としては応用シーンが少ないと思う。僕の修理実績では無かった。それでマルチタッチはサポートしないこととする。

②短タッチと長タッチの識別はサポートする。

・長タッチの評価途中での短タッチは検知させないようにする。つまり、タッチが離されたときに短タッチの評価を行う。

・長タッチはタッチ継続時間が一定に達すれば検知する。

③API関数

・エントリ名 tsw_sts

・パラメータ無し。

・戻り値はWレジスタにタッチSW操作状況を返す。

Wレジスタ
b7-4:操作状況
     0=操作無し(タッチ開始から短タッチに至る前を含む)
     1=短タッチ(短タッチ以上タッチ後に離された)
     2=長タッチ(長タッチ以上タッチされた)
b3-0:タッチSW番号(0起算)

・短タッチ/長タッチを返した場合、全タッチSWのタッチ状況がクリアされる。

④提供形態

・タッチセンスはCdSやRFIDと同様にPIC電子オルゴールのエンジン機能としては位置付けられない。このため、固有部のコードとして提供する。


【使用例】
PIC電子オルゴールVer6_2の改善(タッチセンスのAPI提供)使用例

【ダウンロード】
orgel6_2は ここから ダウンロードできる。

本記事の対象プロジェクトは orgel_1825.X
  1. 2020/04/10(金) 12:22:05|
  2. 電子オルゴール+音声再生
  3. | コメント:2

PICで音声再生の音質向上(W25QのQPI・マトリクスSW接続)

【前振り】
先日からPICで音声再生の音質向上で以下の記事を掲載した。

PICで音声再生の音声データ12ビットパッキング

PICで音声再生の音質向上(W25QのQUAD出力)

PICで音声再生の音質向上(W25QのQPI接続)

PICで音声再生の音質向上(16F1823)

PICで音声再生の音質向上(16F18313)

音声品質の改善の目標は達成したのだが、操作SWが4個しか無く、おもちゃ修理等へ応用し辛い状況であった。それで今回は操作SWの増設を行った。


【設計】
QPI(IO0~3)のポートをSW制御と共用することで、SWを増設する。

共用したポートにベアにSWを繋ぐのでは4個しか増設できない。また、16F1823はポートCにIOC割り込みの機能が無いので、増設したSWはSleepからのWakeupに使えない。

そこで、SWをマトリクス構成にする。QPI(IO0~3)の4本をセレクト線に充てる。従来のSWポートの4本にSPI(QPI)のCLKを加えて計5本をセンス線に充てる。そうすると4×5=20個のSWを繋ぐことができる。また、どのSWでもIOCでWakeupできる。

回路図
PICで音声再生の音質向上(W25QのQPI接続・マトリクスSW)I回路図
QPI(IO0~3)のポートをQPIから解放させるにはW25Qをデセレクトしなければならない。そうすると、SWをセンスした後でW25Qに対して読み込み設定(QPI読み込みコマンドとアドレスの送信)を再度行わなければならない。この処理の所要時間を短縮するため、W25Qへの送信もQPIで行う方が良い。そのため、今回の改善はW25QをQPIでアクセスするプロジェクトのみに実施する。


【開発】
マトリクスSWのスキャンには比較的多くのダイナミックステップ数を喰うことになり、当初はアンダーランが多発した。それで、コンパイラのコード展開を見て、効率が悪くて走行頻度が高い部分をインラインアセンブラに書き替えた。対処した箇所はソースコードを参照。その結果、アンダーランは抑えられ、アプリ実行用のCPUを確保できた。


【評価】
CPU消費時間の実測結果を以下に示す。観測用の信号は、リングバッファの空きチェック開始でL、空き検知でHにしている。つまり、L期間はリングバッファの空き待ちを示し、この期間がアプリの実行に充てることができる時間になる。
PICで音声再生の音質向上(W25QのQPI・マトリクスSW接続)QPI時間観測
H期間は20usと14usが交互に現れていて、40usが2サンプル(3バイト)の読み込み時の処理、14usが保留していた後行サンプルの処理である。CPU使用率は約55%であり、アプリ実行に充てられる時間は十分確保されている。

アプリが長時間CPUを占有したときの動作検証も行った。メインループ中に100usのダミーループを挿入して、CPU消費時間を観測した。
PICで音声再生の音質向上(W25QのQPI・マトリクスSW接続)QPI時間観測2
ダミーループ時間中はPWMデューティ値データを計算することができないが、リングバッファ上のデータでPWMデューティ値の更新は続けられてアンダーランが抑止されている。約400us後にリングバッファがフルに追い付いている。


【再生音】(16F1313版と同じ)
オリジナルの音源はステレオ16ビット44.1kspsで、 「SoundEngineFree」 でモノラル16ビット32kspsに変換し、その後 「wav2hex」 のツールで16ビット32kspsのHEXファイルを作成した。

それを今回のファームウェアで再生させ、SoundEngineFreeで録音した。

10ビット32kspsでの再生音はこれ↓
onsei_18313_10bit32ksps.mp3


【ダウンロード】
設計資料と開発プロジェクトは ここから ダウンロードできる。

プロジェクトは onsei_1823_QPI_10bit32ksps.X

音源は voice_TRUTH にある。

過去の記事で説明されたプロジェクトは今回の改善版で上書きされている。機能上は包含されている。
  1. 2020/03/24(火) 19:28:34|
  2. 電子オルゴール+音声再生
  3. | コメント:0

PICで音声再生の音声データ12ビットパッキング

【前振り】
過日、PICで音声再生の音質向上の続編で W25QのQUAD出力 を行い、音質向上の目標は達成できた(と思う)。ただ、11ビットの音声データを2バイトに格納しているのでメモリの利用効率が悪い。その点を改善したい。


【設計】
11ビットは中途半端なので12ビット形式にして、3バイト/2サンプルの形でパッキングを行ってフラッシュメモリに格納し、再生時にアンパックを行う。必要なメモリ量を75%に削減できる。

128Mビットのデバイスでは、16ビット形式では4.3分間の音声が格納できるが、12ビットパッキング形式では5.8分間になる。

・パッキング

パッキングは 「wav2hex」 のツールで行う。

「wav2hex」の従来版は変換後の量子化ビット数として7~16が指定でき、9ビット以上の場合は2バイト/1サンプルに変換していた。これを、変換後の量子化ビット数として8・12.16のうち何れかを指定可能とし、8ビットの場合は1バイト/1サンプル、16ビットの場合は2バイト/1サンプルに変換する。12の場合に新規の仕様でパッキングを行う。

12ビットのパッキングは以下の形式でHEXファイルを生成する。そのように「wav2hex」を改造した。改造後の「wav2hex」はダウンロードファイルに含まれている。
PICで音声再生の音声データ12ビットパッキング格納形式

なお、変換後の量子化ビット数が8と16の場合の変換結果は従前どおりとなる。今まで8と16でしか使っていなかったので、(僕としては)問題は無い。

・アンパック

アンパックは 「PICで音声再生」 のファームウェアで行う。

フラッシュメモリからは3バイト単位で読み込み、アンパックして2サンプルを得る。

メインループの1回目で読み込みとアンパックを行い、先行サンプルを処理する。2回目は1回目で得た後行サンプルを処理する。


【評価】
動作時間の実測結果を以下に示す。W25Qからの読み込みを含むアンパック処理の入口/出口、およびPWM周期割り込み処理の入口/出口でデバグ信号を出して観測した。
PICで音声再生の音声データ12ビットパッキング時間観測
16ビット形式のQPI接続とQUAD出力ではPWM周期の32us当たり約7usを占有していたが、12ビット形式ではPWM2周期の64us当たり約8usの占有となり、性能の改善にもなった。

アプリの実行可能時間(割り込み処理中を除く)は十分確保されている。


【ダウンロード】
設計資料と開発プロジェクトは ここから ダウンロードできる。

プロジェクトは onsei_1823_QUAD_10bit32ksps.X

音源は voice_TRUTH にある。
  1. 2020/03/17(火) 09:49:36|
  2. 音声再生・録音再生
  3. | コメント:0

PICで音声再生の音質向上(W25QのQUAD出力)

【前振り】
過日、PICで音声再生の音質向上の続編で W25QのQPI接続 を行い、性能が改善されることを確認した。しかし、QPI接続するためにはステータスレジスタ2のQEビットがセット(1)されている必要があり、出荷時にセットされていないデバイスではQEビットをセットする余計な操作が必要になる。

音声再生処理では読み込み処理が高速化できればよいので、無理にQPI接続しなくても、W25Qからの読み込み時にQUAD出力させればそれだけで済む。


【設計】
廉価PICに内蔵されたSPIモジュールはQUADをサポートしていないので、QUADはQPIと同様にソフト実装することになる。QUADの転送処理はQPIと同じなので、転送性能も同じになるはずだ。

QUAD出力させること以外は従前の設計を踏襲する。


回路図(QPIと同じ)
PICで音声再生の音質向上(W25QのQPI接続)I回路図


【評価】
動作時間の実測結果を以下に示す。W25Qからの読み込み開始/終了の箇所でデバグ信号を出して観測した。

ソフト実装QPI
PICで音声再生の音質向上(W25QのQPI接続)QPI時間観測
転送処理中はCPUを占有する(同期処理)。その経過時間は約7usであった。転送後PWM周期の終了までアプリの実行が可能である。

ソフト実装QUAD
PICで音声再生の音質向上(W25QのQPI接続)QUAD時間観測
ソフト実装QPIと全く同じである。

上記の観測結果から、QUADはQPIと全く同じ性能であることが判る。

PICで音声再生の音質向上を目指してW25Qの転送方法を試行してきたが、今回のQUAD出力がゴールだと思う。


【再生音】(16F1313版と同じ)
オリジナルの音源はステレオ16ビット44.1kspsで、 「SoundEngineFree」 でモノラル16ビット32kspsに変換し、その後 「wav2hex」 のツールで16ビット32kspsのHEXファイルを作成した。

それを今回のファームウェアで再生させ、SoundEngineFreeで録音した。

16ビット32kspsでの再生音はこれ↓
onsei_18313_10bit32ksps.mp3


【ダウンロード】
設計資料と開発プロジェクトは ここから ダウンロードできる。

プロジェクトは onsei_1823_QUAD_10bit32ksps.X

音源は voice_TRUTH にある。

なお、このプロジェクトは 「PICで音声再生の音声データ12ビットパッキング」 に対応して仕様変更されている。
  1. 2020/03/16(月) 09:07:40|
  2. 音声再生・録音再生
  3. | コメント:0

PICで音声再生の音質向上(W25QのQPI接続)

【前振り】
過日、PICで音声再生の音質向上で 16F18313版16F1823版 を公開したが、当初はSPIの転送レートを1Mbpsにしたところアンダーランが発生して、4Mbpsにすると回避できた。

今回はSPIフラッシュメモリのW25QをQPI接続することで更なる性能改善を試みた。

SPIモジュールを内蔵していないマイコンで高速転送レートを稼ぐ手法としても有用だ。


【設計】
廉価PICに内蔵されたSPIモジュールはQPIをサポートしていないので、QPIはソフト実装することになる。ソフト実装することにより非同期処理が不可となり性能は低下するが、一方、4ビットパラレル転送による性能向上が期待できる。どちらの効果が大きいかと言うことだ。

QPI接続すること以外は従前の設計を踏襲する。

CLKのビット操作を連続したbcf/bsf命令で行うと、Fosc=32MHzではクロック周波数が4MHzに相当するが、W25Qの最大クロック周波数は33MHzなので全く問題ない。

W25QをQPIで接続するためにはステータスレジスタ2のQEビットがセット(1)されている必要がある。データシートによると、注文時にQEビットが1か0かが指定できるようだが、Aliの販社の商品ページでそのようなオプションは見付からない。Aliから調達したW25Qを調べたらセットされていた。念のため、クリア(0)であった場合はこのファームウェアでセットするようにした。なお
QEビットの設定の過程で接触不良などの誤動作が発生するとOTP設定になってしまう可能性があるので、QEビットの設定機能はオプション実装とした。

回路図
PICで音声再生の音質向上(W25QのQPI接続)I回路図


【開発】
ソフト実装QPIでの8ビット受信のソースコード
PICで音声再生の音質向上(W25QのQPI接続)ソースコード

コード展開の結果
PICで音声再生の音質向上(W25QのQPI接続)コード展開
8ビット分の転送の命令サイクル数は20となった。Fosc=32MHzで

  実行時間=1/32MHz*4*20=2.5us

  転送レート=8/2.5us=3.2Mbps


【評価】
動作時間の実測結果を以下に示す。W25Qからの読み込み開始/終了の箇所でデバグ信号を出して観測した。

ソフト実装QPI
PICで音声再生の音質向上(W25QのQPI接続)QPI時間観測
転送処理中はCPUを占有する(同期処理)。その経過時間は約7usであった。転送後PWM周期の終了までアプリの実行が可能である。

内蔵SPIモジュール(4Mbps)
PICで音声再生の音質向上(W25QのQPI接続)SPI時間観測
先行バイト取込み~後行バイト転送~次の先行バイト転送開始の期間はCPUを占有する(同期処理)。その経過時間は約14usであった。次の先行バイト転送開始後は非同期処理となり、PWM周期の終了までアプリの実行が可能である。

上記の測定結果から、ソフト実装QPIの方が性能が優れていることが判る。そのトレードとして必要なポート数が2本増えてしまう。ファームウェアの書き方としては転送の全てが同期処理であるソフト実装QPIの方が易しい。

SPI転送レートが1Mbpsのときは性能クリチカルな部分をインラインアセンブラで書き替えて対応したが、今回の評価でSPI(4Mbps)とソフト実装QPIの両者とも十分なアプリ実行時間が確保できることが判ったので、以前にインラインアセンブラ記述に書き替えた部分をC記述に戻した。メンテ性を考えるとC記述の方が良いからだ。但し、上下ニブルの交換は swapf のままにしている。これは合理的なやり方が見付からないからだ。なお、上記の評価結果はC記述に戻したファームウェアでの実測である。


【再生音】(16F1313版と同じ)
オリジナルの音源はステレオ16ビット44.1kspsで、 「SoundEngineFree」 でモノラル16ビット32kspsに変換し、その後 「wav2hex」 のツールで16ビット32kspsのHEXファイルを作成した。

それを今回のファームウェアで再生させ、SoundEngineFreeで録音した。

10ビット32kspsでの再生音はこれ↓
onsei_18313_10bit32ksps.mp3


【その後】
QUAD出力版で音声データの12ビットパッキング形式に対応したことにより、QPI版でも12ビットパッキング形式に対応した。


【ダウンロード】
設計資料と開発プロジェクトは ここから ダウンロードできる。

プロジェクトは onsei_1823_QPI_10bit32ksps.X

音源は voice_TRUTH にある。
  1. 2020/03/14(土) 20:54:41|
  2. 音声再生・録音再生
  3. | コメント:0

PICで音声再生の音質向上(16F1823)

【前振り】
過日、PICで音声再生の音質向上(16F18313) を公開したが、その続編として16F1823版を公開する。

【設計】
量子化ビット数やSPI転送レートについては、16F18313での設計を踏襲する。

SPIメモリからの読み込みとPWMデューティ計算を非同期に実行することも同じだ。

16F18313は8ピンなので、SPIとSWでポートの共用が必須であったが、16F1823はポート数に比較的余裕があるので、SWを専用のポートに繋ぐことにする。16F18313ではSWの読み込みでメンドイことをやっていたが、それが要らなくなる。

回路図
PICで音声再生16F1823_SPI回路図

【開発】
問題があったところは、16F1823のPWMデューティの下位2ビットの設定場所がPWM制御レジスタの一部分になっていて、その設定の実行コードが嵩張って、結果としてアンダーランが発生してしまった。

そこで、Cコンパイラの展開結果を確認した。

例1 data<<=1 の展開
「PICで音声再生」の音質向上(16F1823)展開例1
シフト数は1ビット固定なのに何故かループさせている。

これをインラインアセンブラで記述した。
「PICで音声再生」の音質向上(16F1823)展開例1のアセンブラ

例2 data=~(data<<1) の展開
「PICで音声再生」の音質向上(16F1823)展開例2
一々作業域へコピーしてから処理している。

これをインラインアセンブラで記述した。
「PICで音声再生」の音質向上(16F1823)展開例2アセンブラ

例3 CCP1CON=((((unsigned char)data)>>2)&0b00110000)|0b00001100 の展開
「PICで音声再生」の音質向上(16F1823)展開例3
これも作業域へコピーしているし、2ビットのシフトをカウント繰り返しに展開している。

これをインラインアセンブラで記述した。
「PICで音声再生」の音質向上(16F1823)展開例3のアセンブラ

上記のようにインラインアセンブラで書くことで、ダイナミックステップ数は半減した。その結果、アンダーランは発生しなくなった。

32usの間に、SPIフラッシュメモリから2バイトを読み込み、デューティ値に変換して、PWMに設定する処理を絶え間まなく実行するのでかなり忙しい。それをCで書くのは初めから無理だった、ってことだ。なお、これはフリーのXC8コンパイラでの話で、有償版ではもっと気の利いたコードが出るのかも知れない。

【再生音】(16F1313版と同じ)
オリジナルの音源はステレオ16ビット44.1kspsで、 「SoundEngineFree」 でモノラル16ビット32kspsに変換し、その後 「wav2hex」 のツールで16ビット32kspsのHEXファイルを作成した。

それを今回のファームウェアで再生させ、SoundEngineFreeで録音した。

16ビット32kspsでの再生音はこれ↓
onsei_18313_10bit32ksps.mp3

【ダウンロード】
設計資料と開発プロジェクトは ここから ダウンロードできる。

プロジェクトは onsei_1823_SPI_10bit32ksps.X

音源は voice_TRUTH にある。
  1. 2020/03/10(火) 15:09:18|
  2. 音声再生・録音再生
  3. | コメント:2

PICで音声再生の音質向上(16F18313)

【前振り】
このブログの 「PICで音声再生」「PIC電子オルゴール」 では音声再生を8ビット8kspsの分解能でやっていた。おもちゃの修理用ということで、それなりの音質に甘んじてきた。しかし、最近のおもちゃはHiFiなものがあり、廉価PICでどこまで音質をよくできるのか実験してみた。


【設計】
・量子化ビット数

廉価PICでも16ビットPWMを搭載したものがあり、量子化ビット数を16ビットにすることができる。PWMクロックが最大32MHzなので、16ビット分解能にすると

PWM周期=(1/32MHz)×(2^16)=2ms

となり、話にならない。

廉価PICで標準的な10ビット分解能では

PWM周期=(1/32MHz)×(2^10)=32us

となり、Fosc=32MHzではこれが限界だ。

ブリッジ出力とブレーキ出力ではPCMデータのMSBの1ビットは正相と逆相の区分に充てられ、2ビット目から10ビットがデューティ値に反映されるので、実質的に11ビットの分解能となる。


・SPI転送レート

量子化ビット数が8ビットを超えると1サンプルを2バイトに格納することになる。必要な転送レートは

転送レート=16ビット/32us=500kbps

になる。これはSPIのソフト実装では賄えない速さだ。オーバーヘッド分をみて、内蔵SPIモジュールを1Mbps以上で動かすしかない。


・デバイス選定

ブリッジ出力をサポートするにはフルブリッジ出力機能かステアリング出力機能、若しくはPWMが2個搭載されている必要がある。

SPI(SS、SCK、MOSI、MISO)に4本、音声出力(PWM)に正相と逆相の2本が必要で、8ピンPICで構成できそうだ。SWはSPI信号とポートを共有することで、SW専用のポートを取らなくて良いようにする。

RA3は入力専用ポートなので、上記のポートのうち唯一の入力信号であるMISOをRA3に割り当てる必要がある。そうするためにはPPS機能を搭載したデバイスである必要がある。

この条件で最廉価なのが16F18313で、秋月で@80円。Aliには該当条件の廉価ものは無かった。

14ピンPICではポート数に余裕があるのでPPS機能は無くてもよい。16F1823がAliで@53円だ。


・SPIメモリ容量

16ビット32kspsでは

16ビット×32ksps=512kビット/s

の容量が必要になる。128MビットのW25Q128でも250秒しか持たない。長目の曲だと1曲しか入らない。

回路図(16F18313)

PICで音声再生16F18313_SPI回路図


【開発】
今回は、16F18313で作った。

問題があったところは、処理速度だった。SPIメモリからの読み込みとPWMデューティ計算をシリアルに実行するとアンダーランが発生して、演奏のテンポが微妙に遅くなった。PCMデータ2バイトのうち1バイトの転送とPWMデューティ設定を並行処理するようにするとテンポが乱れることが無くなった。このときのSPIクロックは1MHzで実行している。

面倒だったところはSPIとSWのポート共有させることで、SPI転送が完了したタイミングでSPIバスを解放してSWを読込まないといけない。W25QはCE(SS)をネゲートすればMISOは解放される。MOSIとSCKを解放させるには、内蔵SPIモジュールを無効にするか、PPSでSPIモジュールからポートピンを切り離す。今回は前者を採った。SWを読み込み後に、SPIモジュールを有効に戻して、SPIメモリへREADコマンドを発行して読み込みを再開始する。

W25QのSPIクロックの最大値は33MHzなのだが、PIC内蔵SPIモジュールの最大値が4MHzなので、4MHzとした。これで、アプリ実行のCPUが稼げる。

16F18313は省電力性能が優れていて、Sleep時の消費電流は0.4uAだった。


【再生音】
オリジナルの音源はステレオ16ビット44.1kspsで、 「SoundEngineFree」 でモノラル16ビット32kspsに変換し、その後 「wav2hex」 のツールで16ビット32kspsのHEXファイルを作成した。

それを今回のファームウェアで再生させ、SoundEngineFreeで録音した。

16ビット32kspsでの再生音はこれ↓
onsei_18313_10bit32ksps.mp3
ラジカセ(表現が古い)レベルにはなった。


【ダウンロード】
設計資料と開発プロジェクトは ここから ダウンロードできる。

プロジェクトは onsei_18313_SPI_10bit32ksps.X

音源は voice_TRUTH にある。
  1. 2020/03/08(日) 20:21:17|
  2. 音声再生・録音再生
  3. | コメント:0

8ピンPICで2.4GHzラジコンコントローラ

【前振り】
「tiny13Aで音声再生」「8ピンPICで音声再生」 で、SPIバスとSWのポートを共用することで8ピンデバイスでの操作性を確保した。この考えを2.4GHzラジコンファームウェアに応用すれば8ピンPICでコントローラが実現できるのではないか、と今更ながら思い付いた。

【設計】
考え方は今までと同じで、SPIのSSをネゲートしてSCK・MOSI・MISOの3本の信号線を解放し、その信号線に繋いだ操作SWを読み込む。SPIが使われているときにSWを操作してもSPIに影響が出ないように、ポートとSW間には1.5kΩの抵抗を入れておく。

ピン割り当て
8ピンPICで2.4GHzラジコンコントローラピン割り当て

回路(配線パターン)
8ピンPICで2.4GHzラジコンコントローラ回路図
上記の①と②の違いは、トランシーバを表向きに付けるか、裏向きに付けるかの違いだ。

IMG_9035.jpg

【評価】
データシートによると
8ピンPICで2.4GHzラジコンコントローラSE8R01-SPI
CSNがHの期間は、MISOは駆動されないように表現されているのだが、実機で動かしてみると、SE8R01ではCSNをHにしてもMISOはLに張り付いたままだ。DIPタイプとSMDタイプの両方でやってみたが、MISOは解放されない。

と言うことで、目論見は失敗だった。

しかし、nRF24L01でやってみたら、こちらは正常動作する。つまり、nRF24L01ではCSNをHにするとMISOは解放された。

SE8R01でMISOを解放させるやり方の知見をお持ちの方は、是非ご教示いただきたい。

【ダウンロード】
ファームウェアの設計資料と開発プロジェクトは ここから ダウンロードできる。

プロジェクトは ディレクトリRC24_SE8R01 の RC24_SE8R01_TX_1572.X

8ピンPICではデバグ情報を出力するポートが確保できないので、デバグは1503で行っている。このプロジェクトは RC24_SE8R01_TX_1572_DBG1503.X

どちらもSE8R01用に書いているが、このHEXファイルはnRF24L01でも動作している。但し、バージョンによっては互換が無いかも知れない。
  1. 2020/03/02(月) 11:41:19|
  2. 2.4GHzラジコン
  3. | コメント:0

2.4GHzラジコン用ファームウェアの改善(タッチSW)

【前振り】
2.4GHzラジコン用ファームウェアで コントローラ側に16F1823を採用 したのだが、この石はCPSを内蔵している。また、電動乗用ラジコンの 27MHzのTX2コントローラ を製作したときに、操作ボタンにタッチSWを使ったところ良好な結果を得たので、2.4GHzラジコン用ファームウェアでもタッチSWをサポートした。

【設計】

・固定タイムベース

コントローラ側の処理の流れは、操作状態を確認して制御データを送信する処理をシーケンシャルに繰り返せばよいので、非同期処理の必要が無い。そのため、CPSをカウントするための固定タイムベースは、通常動作中でもSleep中でも同じWDT周期にすることで、カウント値の段差の発生を防止する。

固定タイムベースの時間設定は動作時間と分解能の観点で、今までの経験値から1msとした。

・CPSカウント値の評価

ラジコン操作の特性上、タッチまたは非タッチの状態が長時間継続するため、タッチの評価はCPSカウント値の変化ではなく、絶対評価で行う。

・Sleep時間

固定タイムベースに対してSleep時間を長くすることが省電力になるが、操作のレスポンスに影響しない範囲で16msとした。5個のタッチSWの評価の所要時間は80ms強となる。

・機械SWとの共用

CPSポートをGNDにするとCPSカウント値は0となるので、機械SWを接続していてもCPSによるSWの評価が行える。唯一の特異点は、RA3はCPSポートにならないことだ。

タッチSWの場合は、タッチパッドへの信号経路に10kΩ程度の保護抵抗を入れておくと安心だ。

・SWの構成情報の定義

タッチSWと機械SWの構成情報は下記のように定義する。

2.4GHzラジコン用ファームウェアの改善(タッチSW)SW構成定義2
2.4GHzラジコン用ファームウェアの改善(タッチSW)SW構成定義

【実装】
2.4GHzラジコン用ファームウェアの改善(タッチSW)配線図

2.4GHzラジコン用ファームウェアの改善(タッチSW)基板1
2.4GHzラジコン用ファームウェアの改善(タッチSW)基板2


【ダウンロード】
ファームウェアの設計資料と開発プロジェクトは ここから ダウンロードできる。

プロジェクトは RC24_SE8R01_TX_1823_T.X

なお、ファームウェアを利用する際は、応用先の回路に合せて定義を変更すること。または、当おもちゃ病院が提供する ファームウェア開発サービス を利用することも可能だ。
  1. 2020/02/24(月) 11:40:38|
  2. 2.4GHzラジコン
  3. | コメント:0

2.4GHzラジコン用ファームウェアの改善(基板パターン検討)

2.4GHzラジコン用ファームウェアのターゲットデバイスは以下をサポートしてきた。

・16F1503
・16F1705
・16F18325
・16F15325

このうち、現時点でおもちゃ修理に使える廉価なものは

・16F1503-I/SL @52円(2020年AliExpress)

だけだ。

しかし、16F1503はポートCを内部プルアップできないので、SWを繋ぐ場合には不便だ。そのため、コントローラ側には16F1823を採用することで、部品点数を削除でき作り易くなる。

・16F1823-I/SL @53円(2020年AliExopress)

それでも、PPS機能が無いのでピン割り当てには制約が残る。空中配線する場合はピン割り当ての制約は問題にならないが、きちんと基板を製作する場合は最適なピン割り当てを考える必要がある。

それで、2.4GHzラジコンの基板パターンを観点にして、ファームウェアのカスタマイズを検討してみた。

なお、トランシーバは SE8R01 のみだ。

基板上のPICとトランシーバの配置によって基板パターンのバリエーションが沢山考えられる。

・SPIをPICのポートCに割り当てる場合と若番ピン(ピン2~7)に割り当てる場合

・トランシーバがDIPの場合とSMDの場合

・トランシーバを基板の表側に付ける場合と裏側に付ける場合

・トランシーバを表向きに付ける場合と裏向きに付ける場合

コントローラ側の配線パターン

【16F1823・ポートC・DIP①】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1823・ポートC・DIP①

【16F1823・ポートC・DIP②】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1823・ポートC・DIP②

【16F1823・ポートC・DIP③】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1823・ポートC・DIP③

【16F1823・ポートC・DIP④】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1823・ポートC・DIP④

【16F1823・ポートC・SMD①】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1823・ポートC・SMD①

【16F1823・ポートC・SMD②】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1823・ポートC・SMD②

【16F1823・若番ピン・DIP①】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1823・若番ピン・DIP①

【16F1823・若番ピン・DIP②】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1823・若番ピン・DIP②

【16F1823・若番ピン・DIP③】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1823・若番ピン・DIP③

【16F1823・若番ピン・DIP④】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1823・若番ピン・DIP④

【16F1823・若番ピン・SMD①】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1823・若番ピン・SMD①

【16F1823・若番ピン・SMD②】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1823・若番ピン・SMD②


車体側はPWM出力が必要なので、PWMを4個内蔵した16F1503を採用する。PPS機能がなくPWM出力ピンが固定されていて、SPI信号線にも若干のジャンパー配線が避けられない。

図中の「ch1」は前後進モーターの負荷電流測定端子、「ch2」はステアリングモーターの負荷電流測定端子である。

【16F1503・ポートC・DIP①】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1503・ポートC・DIP①

【16F1503・ポートC・DIP②】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1503・ポートC・DIP②

【16F1503・ポートC・DIP③】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1503・ポートC・DIP③

【16F1503・ポートC・DIP④】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1503・ポートC・DIP④

【16F1503・ポートC・SMD①】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1503・ポートC・SMD①

【16F1503・ポートC・SMD②】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1503・ポートC・SMD②


CCP社デジプロのようにPWM出力が前後進だけでよい場合はSPI信号線のジャンパー配線を無くすことができた。

【16F1503・CCP・DIP①】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1503・CCP・DIP①

【16F1503・CCP・DIP②】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1503・CCP・DIP②

【16F1503・CCP・DIP③】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1503・CCP・DIP③

【16F1503・CCP・DIP④】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1503・CCP・DIP④

【16F1503・CCP・SMD①】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1503・CCP・SMD①

【16F1503・CCP・SMD②】
2.4GHzラジコン用ファームウェアの改善(基板パターン検討)16F1503・CCP・SMD②


【ダウンロード】
ファームウェアの設計資料と開発プロジェクトは ここから ダウンロードできる。

追加したプロジェクトは、コントローラ側は RC24_SE8R01_RX_1503_T.X、車体側は RC24_SE8R01_TX_1823_T.X

ソースコード中の #define でポートの割り当てを定義する。

2.4GHzラジコン用ファームウェアの改善(基板パターン検討)SPIポートの宣言

2.4GHzラジコン用ファームウェアの改善(基板パターン検討)SWポートの宣言

なお、ファームウェアを利用する際は、応用先の回路に合せて定義を変更すること。または、当おもちゃ病院が提供する ファームウェア開発サービス を利用することも可能だ。
  1. 2020/02/23(日) 21:55:54|
  2. 2.4GHzラジコン
  3. | コメント:0
次のページ

プロフィール

大泉茂幸

Author:大泉茂幸
名張市つつじが丘おもちゃ病院
名張市つつじが丘南3番町129
tutuji@cb4.so-net.ne.jp
090-5534-6494
連絡は上記のメール、またはSMSでお願いします。

子どもの頃から趣味は電子工作一筋でやってきました。理科離れが進む中で科学技術に興味を持つ子どもが少しでも増えて行くことを願って、子ども達に電子工作の活動の場を提供しています。

1981年からおもちゃ病院の活動を始め、2014年に三重県名張市への移住を機に「つつじが丘おもちゃ病院」を開院しました。自分でおもちゃを設計し製作する【おもちゃ工房】と、マイコンを応用した電子工作を楽しむ【マイコンクラブ】も併設しています。新規参加メンバーを募集しています。

当ブログで公開している技術情報や成果物の複製、改変および再配布はフリーです。読者様のおもちゃ病院活動のお役に立てば幸いです。ご利用いただいた結果や感想等を記事へのコメントやメールでフィードバックしていただけると有難いです。なお、公開ファイルは最新版を載せているので、古い記事の内容から変わっている場合があります。

カテゴリ

おもちゃ修理技術 (172)
¦ ・電子オルゴール+音声再生 (65)
¦ ・音声再生・録音再生 (26)
¦ ・2.4GHzラジコン (57)
¦ ・レガシーラジコン (13)
¦ ・赤外線リモコン (4)
¦ ・RFID (3)
¦ ・タッチセンス (4)
ツール製作 (36)
¦ ・プログラマー (28)
¦ ・USB-シリアル変換 (3)
¦ ・その他のツール (5)
修理事例 (172)
¦ ・マイコン換装 (86)
¦ ・電子・電気修理 (63)
¦ ・メカ修理 (23)
製作記事 (15)
PIC開発 (4)
おもちゃ病院 (9)
ドクター研修会 (3)
未分類 (1)

最新記事

最新コメント

月別アーカイブ

訪問者数

検索フォーム

RSSリンクの表示

リンク

このブログをリンクに追加する

QRコード

QR