FC2ブログ

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

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

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電子オルゴールVer6_2のリリース(音量設定のサポートとタッチセンスの改善)

【前振り】
先般は、「ミミクリ換装基板」と「PICで音声再生」のファームウェアで出力音量の設定を可能とした。

今回は、「PIC電子オルゴール」でも出力音量の設定をサポートした。

その他、orgelエンジン部の割り込み処理とのインタフェースを変更してタッチセンスの機能改善も行い、orgel6_2として公開する。


【設計】
音量設定のやり方は、「ミミクリ換装基板」と「PICで音声再生」の記事を参照。

今回の改変作業に合わせて、タッチセンスの改善も行った。

・長タッチ前に短タッチを検知するのは自然なのだが、長タッチと短タッチをアプリ側で切り分けるのがメンドーだったので、タッチ状態の継続時間を見るだけで判定ができるようにした。

・Sleepを挟んでもタッチセンスの感度や判定状況が不連続とならないようにして、稼働中/非稼働中の遷移時の誤検知を抑止することができた。

・内蔵CPSモジュールを利用した場合にも非稼働中のタッチセンスを可能とした。16F1823での消費電流の実測値は31uAとなった。

従来はデバイスと機能の組み合わせ毎にプロジェクトを作っていたためプロジェクトの数が増大してきて、メンテナンスがやり難くなて来た。今回はデバイスでプロジェクトを絞って、ソースコード内での宣言により実装する機能を取捨選択するやり方に替えた。


【タッチセンスのデモ】

最後の方で、4番を長タッチしたまま4番を更にタッチするとちゃんと4番のタッチを検知している。これはタッチ度合いの変化を捉えているからであり、環境の変化に自動的に追随しているってことだ。


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

プロジェクト名にデバイス名が盛り込まれている。例えば、orgel_18325 のターゲットデバイスは 16F18325 である。

CdSで制御するものにはプロジェクト名に CdS が付加されている。

タッチセンスで制御するものはプロジェクト名に TOUTCH が付加されている。

RFIDで制御するものはプロジェクト名に RFID が付加されている。
  1. 2020/01/31(金) 10:33:32|
  2. 電子オルゴール+音声再生
  3. | コメント:0

PIC電子オルゴールVer6_1のバグ改修(SPIフラッシュの音声切り替えが失敗する)

【バグ事象】
SPIフラッシュから音声再生を実行中にVOICES_SEL()で別の音声を選択すると、指定とは異なる音声に切り替わる。

音声再生が終了しているときにVOICES_SEL()で音声再生を開始する場合にはバグ事象は発生せず、指定した音声が再生される。


【原因】
音声を切り替える際にSPIフラッシュに対して切り替え先の音声のアドレスを設定するが、チップデセレクトが抜けていたためアドレスの更新が行われなかった。そのため、切り替え先の音声指定に関わらず、メモリ配置上の次の音声へ進んでいた。

この事象はSPIをソフト実装する場合に発生し、内蔵SPIモジュールを使用する場合はチップデセレクトが実行されているので正しく動作する。


【ダウンロード】
改修後のorgel6_1最新版は ここから ダウンロードできる。
  1. 2020/01/23(木) 14:38:37|
  2. 電子オルゴール+音声再生
  3. | コメント:0

モータードライバIC(TC118S、MX08)でスピーカ駆動

【前振り】
PIC電子オルゴールやミミクリ換装で、モータードライバICでスピーカのブリッジ/ブレーキ駆動が行えるようにファームウェアを機能改善しているが、モータードライバICによっては音質が悪化することがある。そこで、ポピュラーなICの特性を調査した。

【調査対象】
・モータードライバICは TC118S と MX08 の2品種

・出力ピンに8Ωスピーカを接続した状態で入出力信号を観測

【調査結果】
TC118Sの評価
・ブリッジ出力
モータードライバICでスピーカ駆動TC118Sブリッジ出力
オン遅延は比較的少ないが、オフ遅延が6us以上もある。波形も訛っている。

・ブレーキ出力
モータードライバICでスピーカ駆動TC118Sブレーキ出力
オン遅延、オフ遅延とも4us以上もある。波形も訛っている。

・ブレーキ出力2
モータードライバICでスピーカ駆動TC118Sブレーキ出力2
4usの入力パルスには全く応答していない。

TC118S はPIC電子オルゴールやミミクリ換装のスピーカ駆動としての器ではない。

MX08の評価
・ブリッジ出力
モータードライバICでスピーカ駆動MX08ブリッジ出力
信号遅延は殆ど無い。オフ時に振動が見られるが、ブレーキングが無いので仕方がない。

・ブレーキ出力
モータードライバICでスピーカ駆動MX08ブレーキ出力
信号遅延も振動も殆ど無い。

・ブレーキ出力2
モータードライバICでスピーカ駆動MX08ブレーキ出力2
0.4usのパルスに対しても応答している。

MX08 はPIC電子オルゴールとミミクリ換装に問題なく使える。
  1. 2020/01/08(水) 21:26:00|
  2. 電子オルゴール+音声再生
  3. | コメント:2

WAVファイルからHEXファイルを生成するツールの機能追加(サンプリングレートと量子化ビット数の指定)

【前振り】
PIC電子オルゴールや音声再生のファームウェアで 大容量のフラッシュメモリをサポート したことで、音声データの容量をあまり気にしなくて良くなった。僕のツールを利用していただいている 山口宇部のkohei さんから、音声再生でサンプリングレートを16kspsにすると音質が良くなったとのコメントをいただいて、こちらのツール でもサンプリングレートの指定ができるようにした。ついでに、量子化ビット数も指定できるようにした。

【設計】
サンプリングレートの指定範囲は8000~44100とする。但し、入力のWAVファイルのサンプリングレートと整数比にならない場合は、近しい整数比でサンプルを纏めるので誤差を生じる。

量子化ビット数の指定範囲は7~16とする。入力のWAVファイルの量子化ビット数が指定値より小さい場合はLSBに0のビットを補いビット数を拡張する。指定された量子化ビット数が9ビット以上の場合は、HEXファイルの2バイト分に1つのPCMデータを格納する。格納順序は、HEXファイルの若番アドレスにPCMデータの下位8ビットを格納する。所謂、リトルエンディアンで格納するので、HEXファイルを読み込むアプリケーションでは留意されたい。

上記のようにロジックを追加するだけで、特に設計上のウンチクは無い。

【機能追加後の仕様】
・機能
//①リニアPCM形式WAVファイルからインテルHEXファイルを生成する。
//②WAVファイルのヘッダ情報を見て、自動的に指定されたサンプリングレートと量子化ビット数に変換する。
// ch数は1ch(モノラル)となる。
//③サンプリングレートやch数の変換では複数のサンプルの平均値を出力する。
//④最大のダイナミックレンジになる(量子化ビット数での最小値から最大値まで振らせる)ように加工する。
//⑤複数ファイルを入力し、順に1個のインテルHEXファイルに出力する。
//⑥上記⑤の処理で、入力ファイル毎にorgelの音声データ(SPIフラッシュ)のインデックスを設定するvos_macの
// スクリプトを出力する。
// vos_mac 開始アドレス[バイト],サンプル数 ;WAVファイル名
//⑦64Mバイト分までのHEXファイルが生成可能。
//⑧指定されたサンプリングレートで生成する。但し、入力ファイルのサンプリングレートと整数比でない場合は
// 近しい整数個のサンプルを取り纏めるので、誤差が生じる。
//⑨指定された量子化ビットで生成する。8ビットまでは1バイト、9ビット以上は2バイトに変換する。
// HEXファイルには下位8ビットを先に(若番アドレス)に出力する。

・入力パラメータ(起動パラメータ)
//P1:出力ファイル(インテルHEX)のパス名
//P2:出力ファイル(vos_macスクリプト)のパス名
//P3:入力ファイル(WAVファイルパス名リスト)のパス名
//P4:変換後のサンプリングレート[sps](1000~44100)
//P5:変換後の量子化ビット数(7~16)

【使用例】
・起動バッチファイルの例

..\tool\wav2hex\Release\wav2hex.exe W25Q16.hex vos_mac.txt wavlist.txt 8000 8
pause

・WAVファイルパス名リストの例

sharin.wav
kirakiraomeme.wav
aidorumitai.wav
kyounooshare.wav
egaogasuteki.wav
kirarin.wav

・生成されたインテルHEXファイルの例

:020000040000FA
:100000007B906E8D895995816C985A89A25681870B
:10001000748D72807E877C737C828F6B8188847CF8
:100020006E91826D7D93805D94955E7F917B7687E6
:100030007D777F7F895984B44783956C95648196D9
:10004000638395666CAA617D837F885D9E745F9FE4
        ・
        ・
        ・
:1002500083FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF2A
:00000001FF

・生成された vos_macスクリプト の例

vos_mac 0x000000,0x0024de,08000 ;sharin.wav
vos_mac 0x0024de,0x004575,08000 ;kirakiraomeme.wav
vos_mac 0x006a53,0x0019ad,08000 ;aidorumitai.wav
vos_mac 0x008400,0x002cca,08000 ;kyounooshare.wav
vos_mac 0x00b0ca,0x001de2,08000 ;egaogasuteki.wav
vos_mac 0x00ceac,0x0033a5,08000 ;kirarin.wav

vos_macのパラメータは 音声データ開始アドレス、音声データサンプル数、サンプリングレート[sps] となっているので、orgel以外への応用の場合にはこの値を参考にして欲しい。

【使い方のヒント】
①このツールは、入力されたWAVファイルのデータの最大値と最小値を調べて、ダイナミックレンジが最大となるようにデータを加工する。その計算誤差が少なくなるように、入力ファイルの量子化ビット数は落とさないで、このツールに入力するのがよい。

②WAVファイルのサンプリングレートと変換後のサンプリングレートが異なる場合は複数のPCMデータを1つに纏めることにより変換後のサンプリングレートに変換する。そのため、サンプリングレートが整数比でない場合は変換誤差が生じる。これを避けるためには、整数比になるように事前にWAVファイルのサンプリングレートを(出回っているツールを使って)変更しておくとよい。

【開発環境】
VisualuStudio2008Express

【ダウンロード】
設計資料と開発プロジェクトは ここから ダウンロードできるPIC電子オルゴールの公開ファイルに含まれている。

ツールはディレクトリ「tool」に入っている。

プロジェクトのソリューションファイルは下記にある。
tool\wav2hex\wav2hex.sln

使用例は下記にある。
「voice_Mirrorna」と「voice_MICdeWAN」にある。
バッチファイルは wav2hex.bat
WAVファイルパスリストファイルは wavlist.txt
生成されたHEXファイルは W25Q64.hex
生成されたvos_macスクリプトは vos_mac.txt
  1. 2019/11/25(月) 14:17:00|
  2. 電子オルゴール+音声再生
  3. | コメント:4

tiny13Aで音声再生

【前振り】
tiny13Aでの音声再生 は以前にやっているのだが、音声再生処理とアプリケーションロジックが入り混じっていて、カスタマイズがやり難い構造であったので改善したいと思っていた。それと、若干の機能改善も施して、新生「tiny13Aで音声再生」とした。

【改善事項】
音声再生処理とアプリケーションロジックを分離してカスタマイズをやり易い構造にする。

・フラッシュメモリ上の音声データのインデックスをプログラム内にテーブルとして持つ。

・アプリからは音声番号を指定して音声再生の開始を指示できるように、そのようなAPIを設ける。

・操作SWの読み込みのマクロを提供し、ハードを意識しなくて良いようにする。

・Sleep処理を行うAPIを設ける。アプリからはSleepしたい場合に呼び出せばよいようにする。

PIC電子オルゴールではブリッジ出力をサポートしたので、今回はtiny13Aの音声再生でもブリッジ出力をサポートする。

【設計】
①ブリッジ出力

下記の4種類の出力タイプから選択できる。

・BTL=0(シングル出力)
Tr1石のバッファアンプでスピーカを駆動する。
スピーカには直流成分が流れる。
電力効率は悪い。

・BTL=1(コンプリ出力)
正相出力と、そのコンプリ波形を出力する。音声レベルが0のときでも、50%デューティのPWMでスピーカが駆動される。電力効率はやや悪い。
ハイサイドにバッファを置く場合にはコンプリ出力を使うと都合が良い。
このタイプではデッドバンドの設定ができない。

・BTL=2(ブリッジ出力)
正相と逆相のブリッジ回路を駆動する信号を出力する。
音声レベルが0のときは、スピーカは駆動されず、電力効率が良い。
高インピーダンススピーカや圧電スピーカをPICのポートで直接鳴らす場合には外付けアンプが要らず都合が良い。
ベアなHブリッジを繋ぐと音質が悪い。
このタイプではデッドバンドの設定ができる。

・BTL=3(ブレーキ出力)
正相と逆相のブレーキング機能付きのブリッジ回路を駆動する信号を出力する。
音声レベルが0のときはスピーカは駆動されず電力効率が良い上に、制動によって音質が良い。
このタイプではデッドバンドの設定ができる。

tiny13AのPWMにはデッドバンド機能が無いので、ソフトでデッドバンドを設ける。但し、コンプリ出力タイプではソフトでの実現は不可能である。

②ポートの割り当て

・I2Cの場合

PB0:PWM出力(正相)
PB1:SW2入力(負論理、内部プルアップ)、PWM出力(逆相)
PB2:SCL入出力
PB3:SDA入出力
PB4:SW1入力(負論理、内部プルアップ)、デバグ用TX
PB5:SW0入力(負論理、内部プルアップ)

回路図

tiny13Aで音声再生I2C回路図

I2CバスはSWと共用できないので、専用のポートを割り当てるしかない。そのため、ブリッジ出力ではSWは2個しか実装できない。

・SPIの場合

PB0:PWM出力(正相)
PB1:PWM出力(逆相)、SW3入力(負論理、内部プルアップ)、デバグ用TX
PB2:SS(CSに繋ぐ)
PB3:SCK(CLKに繋ぐ)、SW0入力(負論理、内部プルアップ)
PB4:M0SI(DIに繋ぐ)、SW1入力(負論理、内部プルアップ)
PB5:MISO(DOに繋ぐ)、SW2入力(負論理、内部プルアップ)

回路図

tiny13Aで音声再生SPI回路図

SPIバスはSSをネゲートすれば、ポートを他の用途に使うことができる。時分割多重の考えで、SW回路と共用している。SWは3個を実装でき、シングル出力タイプでは4個が実装できる。なんと、I2CよりSPIの方が多くのSWを実装できるのだ。

【ダウンロード】
設計資料と開発プロジェクトは ここから ダウンロードできる。
  1. 2019/11/22(金) 18:50:36|
  2. 電子オルゴール+音声再生
  3. | コメント:2

PIC電子オルゴールVer6_1の改善(タッチセンスの動作安定)

【前振り】
PIC電子オルゴールVer6_1でタッチセンスが誤検知するとの申告を受けて調査していた。原因が判明して対処したので報告する。


【原因】
PIC電子オルゴールVer6_1の目玉はブリッジ出力のサポートなのだが、そのためには内部で持つ音声データをWAV形式PCMデータ(0x80が音声レベル0)とする必要があった。その対応でCPU負荷が増えたことが要因だった。

オルゴール演奏や音声再生の開始時には初期設定のためCPU負荷が集中する。それでもPWM出力が途切れないようにリングバッファを持って対応しているが、固有処理のコールバックが遅れることがある。CPSモジュールが要求する「固定タイムベース」をコールバック周期にしていたため、「固定タイムベース」が揺らいで、CPSカウント値が揺らぎ、その結果、タッチ有無を誤判定することになってしまった。


【対策】
PWM周期割り込みをプリスケールして「固定タイムベース」とすることで、揺らぎを無くす。従って、CPSカウンタの操作とカウント値の評価をすべてPWM周期割込み処理内で行うこととした。この処理は200ステップ程度のCPUを消費するのだが、元々のPWMデューティの設定処理と合わせて32us以内には実行完了する。

「固定タイムベース」は10ms程度が適切なので、PWM周期の32usを8ビットのソフトカウンタでプリスケールして8msとした。

短押し/長押し、マルチタッチなどのタッチSWの評価はアプリケーションで行うように、機能分担を整理した。

ついでに、タッチSWのスキャン周期を一定にして、チューニングを容易にした。タッチSWの最大数を12個とし、1個当たり8msで全体のスキャン周期を96msで一定にした。0.1秒であればレスポンスと短押し/長押しの識別の操作性には影響ない。


【デモ】
ターゲットは16F1823で4個のタッチSWを実装して、短押し/長押しの識別と2個のマルチタッチを実現している。
CPSチャネル毎にチューニングをしていないが、それでも安定に動作している。

長タッチ検知の前に短タッチを検知する。また、マルチタッチの検知の前にも短タッチを検知するのは自然のどおりだ。Windowsでもダブルクリックイベントの前にはクリックイベントが発生する。これらのイベントのハンドリングはアプリケーションの仕事だ。

マルチタッチの機能を利用してタッチSWをマトリクス構成に見立てることができる。


このデモを行うのに要したコストは
16F1823 53円(2019年AliExpress)
W25Q16 18円(2018年AliExpress)
SOP14-DIP変換基板 7円(2019年AliExpress)
SOP8-DIP変換基板 3円(2018年AliExpress)
合計 81円

ここまで安くなったので、おもちゃ修理の素材として十分使える。

【ダウンロード】
orgel6_1の最新版は ここから ダウンロードできる。

16F1823のタッチセンスのサンプルプロジェクトは onsei_PIC1823_SPI_touch.X
親のソースコードは onsei_PIC1823_SPI_touch.asm
  1. 2019/11/10(日) 08:06:40|
  2. 電子オルゴール+音声再生
  3. | コメント:1

PIC電子オルゴールVer6_1の改善(ブレーキ出力のサポート)

【前振り】
PIC電子オルゴールVer6_1は日々改善されていて、今回は「ブレーキ出力」をサポートした。

「ブレーキ出力」とは
PIC電子オルゴールのブリッジ出力信号をベアなHブリッジに繋いでスピーカを鳴らすと、ガサガサしたノイジーな音になってしまう。それは、オンデューティ期間はスピーカが駆動されるが、オフデューティ期間はHighZとなり、オンデューティからオフデューティに切り替わったときにスピーカが自由振動してしまうからだ。オーディオ分野で言う「ダンピングが悪い」状態なのだ。スピーカの端子間電圧を観測すると大きな逆起電力が現れ、振動している様子が見える。

改善前の入出力信号波形
PIC電子オルゴールVer6_1の改善(ブレーキ出力のサポート)ブレーキ無し波形

これを解決するには、オフデューティ期間はHブリッジへ制動の信号を出して、スピーカを制動すればよい。具体的にはローサイドまたはハイサイドの正相と逆相をともにオンにする。しかしながら、PICのCWGモジュールには制動の機能が無い。

そこで、モータードライバーICに備わっているブレーキング機能を使って、PIC電子オルゴールの出力信号でスピーカを制動できるようにする。


【構成】
PIC電子オルゴールにモータードライバーを繋ぎ、スピーカを駆動する。
PIC電子オルゴールVer6_1の改善(ブレーキ出力のサポート)動作確認構成

【設計】
モータードライバーICは正転入力と逆転入力を同時にHにすればブレーキが掛かる仕組みになっているので、そのような信号をPICから出す。それには、PICのCWGモジュールの出力をアクティブLで出せばよい。たったそれだけのことでしかなく、それで話が終わってしまっては面白くないので、ファームウェアへの実装関連で多少のウンチクを書くことにする。

PIC電子オルゴールの出力形態は

・BTL=0(シングル出力)
Tr1石のバッファアンプでスピーカを駆動する。
スピーカには直流成分が流れる。
電力効率は悪い。

・BTL=1(コンプリ出力)
正相出力と、そのコンプリ波形を出力する。音声レベルが0のときでも、50%デューティのPWMでスピーカが駆動される。電力効率はやや悪い。
ハイサイドにバッファを置く場合にはコンプリ出力を使うと都合が良い。

・BTL=2(ブリッジ出力)
正相と逆相のブリッジ回路を駆動する信号を出力する。
音声レベルが0のときは、スピーカは駆動されず、電力効率が良い。
高インピーダンススピーカや圧電スピーカをPICのポートで直接鳴らす場合には外付けアンプが要らず都合が良い。
ベアなHブリッジを繋ぐと音質が悪い。

の3種類があったが、今回はこれらに加えて

・BTL=3(ブレーキ出力)
正相と逆相のブレーキング機能付きのブリッジ回路を駆動する信号を出力する。
音声レベルが0のときはスピーカは駆動されず電力効率が良い上に、制動によって音質が良い。

を追加した。

モータードライバーICは、入力信号がLであれば消費電流は数uA以下だが、Hのときは数100uA以上も消費する。殆どのモータードライバーICはこのような仕様である。そのため、SlepするときはCWGモジュールの出力をアクティブHに切り替える必要がある。そのときに、正相と逆相の信号を同時に切り替えないと大きなポップノイズが発生することになる。要はコードの書き方で、CWGの出力極性制御ビットの操作を1命令でやれ、と言うことだ。

初期設定時にもポップノイズが出ないようにコードを書かないといけない。最初はCWGをアクティブHで初期化して、ピン出力するまで進めておく。その後、出力をアクティブLに1命令で切り替える。

実際のコーディングはダウンロードファイル中のソースコードを参照。


【動作確認】
初期設定時の波形
PIC電子オルゴールVer6_1の改善(ブレーキ出力のサポート)負論理への切り替え時波形
モータードライバーICの正相と逆相の入力が同時にHになっていて、出力には少しのヒゲも出ていない。

演奏中の波形
PIC電子オルゴールVer6_1の改善(ブレーキ出力のサポート)ブレーキ有り波形
スピーカの逆起電力が殺されて綺麗なパルス波形になっている。 実際の音を聴くとフツウの綺麗な音が出ている。

Sleep時の消費電流は、16F15325が0.7uA MX08が0.1uAだった。

ポップノイズは、電源オン時、演奏開始/終了時、Sleep/Wakeup時ともに全く発生しなかった。

電源電圧3Vで8Ωスピーカを鳴らしたが、耳が痛くなるほど大きな音量でも消費電流は平均数10mAと、電力効率が格段に向上した。これで、PIC電子オルゴールは音が小さいと言うクレームは無くなるだろう。


【各デバイスへの横展開】
CWGのフルブリッジ機能が利用できるデバイスは一律の対応で済ませられるが、以下のデバイスへの横展開に於いては特別な扱いをしている。

・16F1503

CWGにフルブリッジ機能が無いため、正相と逆相に別のPWMを割当てて、音声レベルの正負によりどちらか一方のみを出力させるようにソフトで制御している。

・12F1612

CWGにフルブリッジ機能が無いため同期ステアリングモードでソフトにより正相/逆相のオン/オフを行っているが、出力極性を切り替えるとオンになっている相のみが切り替わる。そのため、極性はアクティブLのままにして、ピン出力する/しないを切り替えている。

・12F1572 と 16F1579

CWGにフルブリッジ機能がないため、2つのPWMをマスター/スレーブの構成にして、それぞれ正相/逆相の信号生成を分担させている。出力極性の切り替えはそれぞれのPWMに対して行うことになるので時間差が生じてしまう。そのため、極性切り替えの前後でTRISにてPWMのピン出力を無効/有効に設定するという姑息なやり方でしかできなかった。この方法を採ったために、16F1579では正相出力ピンと逆相出力ピンは同じポートレジスタに配置する制約となってしまった。

他にスマートな方法が判らず上記のやり方を採っているが、有識者の方のアドバイスを乞う。


【重要な注意事項】
BTL=3の指定で出力された信号をブレーキ機能の無いベアなHブリッジに繋ぐと燃える、ので注意されたし。


【ダウンロード】
orgel6_1の最新版は ここから ダウンロードできる。


【感想】
MX08は約11円(2019年AliExpress配送無料)で出回っている。この価格なら、ブレーキ機能付きフルブリッジ回路をディスクリートで組むより安い。
  1. 2019/09/01(日) 08:25:34|
  2. 電子オルゴール+音声再生
  3. | コメント:1

PIC電子オルゴールVer6_1の改善(ブリッジ出力)再挑戦

【前振り】
PIC電子オルゴールVer6_1の改善(ブリッジ出力) は以前にやってみたのだが、性能面の理由から失敗 していた。

しかし、ブリッジ出力にするメリットは大きいので、再挑戦することにした。

ブリッジ出力のメリット

・低電圧でも大きな音で鳴る。シングル出力に比べて4倍の出力になる。
・音の内容やブリッジ回路以降の特性などによるが、消費電流は1/2以下になる。
・上記の2つを合わせて、電力効率は8倍以上になる。


【設計】
内部のPCMデータの取り扱いをWAV形式にすることは前回と同じで、そのため、演算処理を全般的に変更する。これは前回の試行で実施済みだ。

今回は性能改善が取り組みの課題になる。

PIC電子オルゴールの内部の処理は以下の3つの部分から成る。

・曲演奏/音声再生処理(それぞれのサンプリング周期で実行)

・出力合算処理(PWM周期で実行)

・メイン制御(メインループ)

ミュート処理は、従来は出力合算時に演算していたが、これを実行頻度が少ない曲演奏/音声再生処理に持ってくることで全体のDSを削減する。

聴感上問題にならない程度に、エンベロープ処理における乗算処理のビット数を少なくする。従来は7ビット演算していたが、5ビットに縮小する。約3%の分解能になる。

前の記事 で、「PIC電子オルゴールでサポートしてきたデバイスで、ブリッジ出力ができるかどうか調べた」のだが、その結果に間違いがあったので、今回の開発での結果を掲示しておく。

16F1503 CWGにはフルブリッジモードが無いが、2個のPWMの有効/無効をソフトで制御してブリッジ出力が可能
12F1572 CWGにはフルブリッジモードが無いが、PWMをマスター/スレーブ構成にしてブリッジ出力が可能
16F1579 CWGにはフルブリッジモードが無いが、PWMをマスター/スレーブ構成にしてブリッジ出力が可能
12F1612 CWGにはフルブリッジモードが無いが、同期ステアリングモードでブリッジ出力が可能
16F1705 COGのフルブリッジモードで、ブリッジ出力が可能
12F1822 CCPのシングル出力同期ステアリングモードで、ブリッジ出力が可能
12F1840 CCPのシングル出力同期ステアリングモードで、ブリッジ出力が可能
16F15325 CWGのフルブリッジモードで、ブリッジ出力が可能
16F18313 CWGのフルブリッジモードで、ブリッジ出力が可能
16F18325 CWGのフルブリッジモードで、ブリッジ出力が可能
16F18326 CWGのフルブリッジモードで、ブリッジ出力が可能
16F18857 CWGのフルブリッジモードで、ブリッジ出力が可能

なお、12F1501は1kワードしかなく、orgel6_1の最少構成でも載らないのでサポート対象から落とした。


【評価】
性能改善については、曲演奏と音声再生をコンカレントに走行しても正常な音で鳴っていて、アンダーランは発生していない。但し、内部クロックが16MHzのデバイスではコンカレント走行は不可。

音量と電力効率の評価には 16F1705 を使った。正相出力ピンと逆相出力ピン(シングル出力時はGNDピン)に290Ωスピーカを繋いで、スピーカの両端子間の電圧を観測した。PICの電源電圧は4.5Vで、全体の消費電流も測定した。

シングル出力時
PIC電子オルゴールVer6_1の改善(ブリッジ出力)再挑戦シングル出力波形
出力電圧はほぼ電源電圧、消費電流は7.6mA

コンプリ出力時
PIC電子オルゴールVer6_1の改善(ブリッジ出力)再挑戦コンプリ出力波形
出力電圧は電源電圧のほぼ2倍、消費電流は9.1mA


ブリッジ出力時
PIC電子オルゴールVer6_1の改善(ブリッジ出力)再挑戦ブリッジ出力波形
出力電圧は電源電圧のほぼ2倍、消費電流は3.5mA

PIC自体の消費電流が2mA強あることから、ブリッジ出力での電力効率は非常に高いことが判る。音の大きさはコンプリ出力時と全く変わらない。但し、信号レベルや出力段(実際に繋ぐHブリッジ以降)の特性によるが、かなりの改善が期待できる。


【ダウンロード】

orgel6_1の最新版は ここから ダウンロードできる。

当面旧版のVer5_7も残しておくが、バグがあってもメンテしない。
  1. 2019/08/21(水) 13:54:34|
  2. 電子オルゴール+音声再生
  3. | コメント:3

PIC電子オルゴールVer6_1の改善(フルブリッジ出力)は失敗

ホントに参りました。

PIC電子オルゴールVer6_1の改善(ブリッジ出力)」 は、タッチセンスのモデルで不具合が出て改善の見通しが立たないため、WAV形式PCM値で処理するという目論見は失敗と判断した。

今後も悪あがきはすると思うが、解決できるかどうかは判らない。
  1. 2019/08/02(金) 14:11:50|
  2. 電子オルゴール+音声再生
  3. | コメント:0

PIC電子オルゴールVer6_1の改善(ブリッジ出力)

【前振り】
PIC電子オルゴールVer5_7では、PWMの出力タイプが、シングル出力と相補出力しかなかった。相補出力ではスピーカーをBTL駆動できるが、音声レベルが0のときにも50%デューティのPWMが出てしまう。これを、音声レベルが0のときは、ブリッジの正相と逆相ともにデューティが0となるように改善を施した。今回の改善は、内部のPCMデータの扱いをunsignedからWAV形式に変える大きな変更であるため、バージョン番号を 6_1 に革めた。


【設計の経緯】
PIC電子オルゴール開発の当初はシングル出力のみを想定していて、演奏出力が無いときはPWMデューティを0としていた。オルゴールの音源データをunsignedの0から始まるように作っておくことで、演奏の始まりではPCM値が自然に0となり、PCM値をそのままデューティに設定するだけでポップノイズ対策は不要だった。演奏の終わりではエンベロープレベルが小さくなっていくので、これまた自然に0となる。つまり、内部の演算処理をunsignedでやることが都合がよく、簡単であった。WAV形式での扱いは考えに無かった。

その後、音声再生をサポートしたときに、音声データはWAV形式(音声レベル0のPCM値は0x80)であり、いきなり音声データのPCM値をデューティに設定すると大きなポップノイズが発生する問題が生じた。この対策として、音声再生開始前にデューティが最初の音声データ値になるまでランプ出力し、音声再生終了後は逆にデューティが0になるまでランプ出力するようにした。

効率的なブリッジ駆動のためには、音声レベルが0のときは正相と逆相ともデューティ0にするのが良いのだが、従前のunsignedのPCM値をPWM出力時点で正相分と逆相に分けるのが難しい。その点、WAV形式のPCM値はレベル0を中心に正負に振れているので、ブリッジ出力にマッチしている。

音声再生をサポート後も内部の演算処理はunsignedのままにして、ポップノイズの抑止だけを刹那的に対応してきた訳で、スマートな設計ではないのが気になっていた。そこで、今回は音源データからWAV形式に統一して、まともなブリッジ出力を行うように改変した。


【設計】
・今までPIC電子オルゴールでサポートしてきたデバイスで、ブリッジ出力ができるかどうか調べた。

1501 CWGにはフルブリッジモードが無いが、CCPを2個使ってブリッジ出力が可能と思われる
1503 CWGにはフルブリッジモードが無いが、CCPを2個使ってブリッジ出力が可能と思われる
1572 CWGにはフルブリッジモードが無いが、CCPを2個使ってブリッジ出力が可能と思われる
1579 CWGにはフルブリッジモードが無いが、CCPを2個使ってブリッジ出力が可能と思われる
1612 CWGにはフルブリッジモードが無いが、CCPを2個使ってブリッジ出力が可能と思われる
1705 COGのフルブリッジモードで、ブリッジ出力が可能
1822 CCPが1個で、フルブリッジモードも無いため、ブリッジ出力は不可能
1840 CCPのステアリングモード(同期)で、ブリッジ出力が可能
15325 CWGのフルブリッジモードで、ブリッジ出力が可能
18313 CWGのフルブリッジモードで、ブリッジ出力が可能
18325 CWGのフルブリッジモードで、ブリッジ出力が可能
18326 CWGのフルブリッジモードで、ブリッジ出力が可能
18857 CWGのフルブリッジモードで、ブリッジ出力が可能

 1822 はブリッジ出力は不可能で、これは諦める。

 1840 は特殊なやり方になるが、個別対応でできそうだ。

 15xx はソフトの工夫でブリッジ出力ができそうだ。

・15xx で、PWMモジュールの出力ピンを切り替えることで1個のPWMモジュールを正相と逆相に共用させようとすると、デューティレジスタがバッファリングされているのに対してピン切り替えはリアルタイムで効いてしまうので、同期することができず上手く行かない。今回は、正相出力用と逆相出力用に別のPWMモジュールを対応付けて、それぞれにデューティ設定するやり方のフィージビリティスタディとしてやってみる。

・従来から BTL=x で指定している出力タイプは シングル出力・コンプリ出力・ブリッジ出力 の3種類に替える。

 シングル出力(BTL=0)は、正相のみを正論理で出力し、出力が無いときはデューティ0とする。旧版(Ver5_7)の BTL=0 と同じ動作をする。

 コンプリ出力(BTL=1)は、正相の正論理出力に加えて、逆相に正相のコンプリ波形を出力する。出力が無いときはデューティ0とする。旧版(Ver5_7)の BTL=1 と同じ動作をする。

 ブリッジ出力(BTL=2)は、正相と逆相とも正論理で出力し、出力レベルが0のときは正相と逆相ともデューティ0とする。出力レベルが正のときは正相のみに出力レベルに応じたデューティで出力する。出力レベルが負のときは逆相のみに出力レベルに応じたデューティで出力する。旧版(Ver5_7)の BTL=2 とは異なる動作をする。

 旧版(Ver5_7)の BTL=2(BTL出力でSleep時は同相出力する) は廃止する。

BTL=2 のときの出力波形
PIC電子オルゴールVer6_1BTL=2出力波形

・音源データをWAV形式に作り替える。

 オルゴールの音源でExcelの計算で作ったものはレベル0から始まるように作り替える。エンベロープ波形データとピッチベンド波形データはunsignedのままで処理するので変更不要。

 ピアノなどのサンプリング音源波形はレベル0の部分が先頭に来るようにデータを移動する。

 音声データはWAVファイルから変換したときにWAV形式PCM値になっているので対応不要。

・内部の演算処理をWAV形式対応に替える。

 PIC16は乗算命令がないのでソフト実装している。従来は unsigned×unsigned の処理しか用意していなかったが、WAV形式×unsigned の処理も用意する。

 加減算もWAV形式で行うように替える。

・正相と逆相間で出力が切り替わるときはデッドバンドを確保する。

 デューティが100%、およびそれに近い状態で正相と逆相が切り替わるときは貫通電量が発生する可能性がある。そのため、最低限確保するデッドバンド(正相と逆相がともにオフになる時間)を設定可能とする。具体的には、オフとなるPWMステップ数が指定されたステップ数よりも小さい場合は、切り替わった最初のデューティを0とする。極めて乱暴な処置だが、100%デューティに近い状態から正逆が反転することは音声データの場合には殆ど無いと考える。


【ダウンロード】
PIC電子オルゴールVer6_1の設計資料と開発プロジェクトは ここから ダウンロードできる。

現在は16F1705のプロジェクトのみ旧版(Ver5_7)から移行している。その他のデバイスについては今後拡充していく。


(重要)後日談】
16F1705のタッチセンスのプロジェクトの動作がおかしいので、原因を調べたところ、演奏/音声再生のデータ準備でアンダーランが発生していることが判った。WAV形式PCM値の演算が各所にあり、それぞれは若干のダイナミックステップ増なのだが、チリツモで全体ではCPU消費が増大している。それと、タッチセンスの処理は固有処理と割り込み処理でCPUを喰うので、問題が顕在化した。

数日間改善を試みたが、アンダーランの解消には至らず。

PIC電子オルゴールVer6_1は残念ながら、開発を中断したことをここに告知する。
  1. 2019/07/31(水) 15:27:43|
  2. 電子オルゴール+音声再生
  3. | コメント:0

PIC電子オルゴールVer5_7で12F1572と16F1579のサンプルプロジェクトを追加

【前振り】
昨年から公開ファイルには追加されていたのだが、公式のアナウンスはこれが初めてだ(と思う)。

157xはPWM機能が強化されたデバイスで、分解能はなんと16ビットだ。

でも 「そんなの関係ねぇ!」。 PIC電子オルゴールは音源が8ビットしかない。だから、16ピットPWMのメリットは無く、8ビット分解能でいいから半額にして欲しい。

それでも、PIC電子オルゴールでサポートしたのは、それなりに廉価だから。PIC電子オルゴールでは動作スピードとメモリ容量が重要だ。8ピン2kワードでは12F1572が最安(2019年秋月価格@80円)、8kワード20ピンでは16F1579が最安(2019年秋月価格@140円)。AliExpressには12F1572(SOP)が@30円台で出ている。

PIC電子オルゴールの開発当初は、当時最廉価だった12F1822(秋月@80円)を使っていたが、現在は(PIC電子オルゴールとしては)12F1572が代替品となる。


【設計】
PIC電子オルゴールのエンジン部は記述が汎用化されていて、デバイスの差異の影響を受けない(ように設計している)ので、PIC電子オルゴールでのサポートとは、固有処理部にデバイス固有の定義と初期化、それと必要なら割り込み処理のオンコーディング部を書くことだ。

今回のデバイスはPWM機能が強化されていて、PWM関連のレジスタの種類と設定内容が従来のデバイスと全く異なる。そのため、PWMモジュールの初期設定とPWM周期割り込み処理でのデューティ設定トリガの設定を新規に書いた。詳細はソースコードの該当部分を従来のデバイスと比較すれば理解し易い。


【ダウンロード】
PIC電子オルゴールのファームウェアは ここから ダウンロードできる。

追加したプロジェクトは
 demo_PIC1572.X onsei_PIC1572.X onsei_PIC1572_I2C.X onsei_PIC1572_SD.X onsei_PIC1572_SPI.X
 demo_PIC1579.X onsei_PIC1579.X onsei_PIC1579_I2C.X onsei_PIC1579_SD.X onsei_PIC1579_SPI.X
  1. 2019/06/24(月) 18:50:35|
  2. 電子オルゴール+音声再生
  3. | コメント:0

「DFPlayerMiniの制御」のレジューム対応版の改善(ソフトUART送信のビットタイミング)

DFPlayerMiniの制御車載外観2

【前振り】
「DFPlayerMiniの制御」の記事はしつこいくらいに出てくる。申し訳ないが、今回も。

おもちゃの修理も含めて人からの頼まれ物は納期があり、それなりに完成するのだが、自分の製作物はいつまでも工事中であり、完成することが無い。

【改善点】
「DFPlayerMiniの制御用ファームウェア」も少しずつ改善されてきていて、今回の改善点は、「ソフトUART送信のビットのタイミングをタイマーで計時するようにした」ことだ。

以前は、ビット巾をスピンループで待っていたため、割り込み処理が走行するとビット巾が延びて、通信エラーになる恐れがあった。そのため、アプリ処理の流れで、送信と割り込み処理が同時に起きないようにしていた。本末転倒の対処だった。

【設計】
正確に言うと改善後もスピンループであるのだが、ループの中でタイマーを見ることで、割り込み処理が走っても正確に計時する。

計時にはTMR0を使う。TMR0は赤外線受信にも使っているが、赤外線受信とDFプレーヤーへの送信は同時並行処理をしないので、TMR0を共用することができる。TMR2はDFプレーヤーからの割り込み受信に使用していて、これは非同期処理なのでTMR2の共用はできない。TMR1は、それを内蔵していないデバイスもあって、ファームウェアのポータビリティを確保するため敬遠した。

計時の方法はオーソドックスに、TMR0に (-経時時間) を設定し、TMR0のオーバフローを待つ。実際には、TMR0の更新時のインクリ抑止期間と関数呼び出しを含めたオーバヘッド分を加味してTMR0を設定する。

この処理は、DFプレーヤーへの送信処理とデバグ情報出力のソフトUARTに適用した。対象のターゲットデバイスは 12F1501 と 16F18313。10F322 はメモリが満杯で手入れができない状況である。

【改善結果】
ホルダ内トラック数のクエリと再生開始コマンド間を130ms空けていたが、30msの待ちに短縮できた。使用感としては変化には気付かない程度だが。

デバグ情報の採取の制約が少なくなったので、デバグはやり易くなった。こちらの方が僕としてはメリットがある。他の開発プロジェクトにも展開して行きたい。

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

プロジェクトは DFPlayer_1501.X と DFPlayer_18313.X
  1. 2019/06/16(日) 21:48:24|
  2. 電子オルゴール+音声再生
  3. | コメント:0

「DFPlayerMiniの制御」のレジューム対応版で12F1501をサポート

DFPlayerMiniの制御車載外観2

【前振り】
電源オフ/オンで動作状態を引き継ぐ「レジューム機能」をサポート したのだが、16F18313のEEPROMに引継情報を退避するのに43msも掛かるので、その間のVddを保持するのに1000uFもの大きな電解コンが必要だった。EEPROMの書き換えがバイト単位であることが書き換えに時間が掛かる原因になっている。それに対して、HEFはROW単位での書き換えなので、書き換え時間が短くて済む。それで、ターゲットデバイスを12F1501に替えて、引継情報の退避先をHEFにしてみた。

【設計】
12F1501のHEFの書き換え(消去+書き込み)に必要な時間はデータシートでは約4ms、実測では3.3msであった。16F18313のEEPROMの書き換え時間の1/10以下だ。書き換え時間にVddを保持するためのパスコンを小さくできる。実測による評価を行った結果、22uFとした。

Vddのパスコンを22uFとしたときの引継情報書き替えタイミングの実測結果
DFPlayerMiniの制御1501(HEF書替えタイミング検証)

引継情報の1バイトはHEF上では1ワードに対応する。また、HEFの書き換えはROW単位なので、12F1501のROWサイズの16ワードになるよう引継情報の構造体にはダミーエリアを設けておく。

//----------------------------------------------
//作業領域
//----------------------------------------------
static struct DF_CNT //DFプレーヤーの引継情報
{
unsigned char val1; //有効性検証バイト1
unsigned char df_mode; //DFプレーヤーの動作モード
// (0=SD内リピート、1=ホルダ内リピート、2=1トラックリピート)
unsigned char df_volume; //DFプレーヤーの音量設定値
unsigned char df_eq; //DFプレーヤーのイコライザ設定値
unsigned char df_pause; //DFプレーヤーのpause設定値(0=停止中、1=再生中)
unsigned char df_hld_no; //DFプレーヤーのホルダ番号
unsigned char df_trk_no; //DFプレーヤーのホルダ内トラック番号
unsigned char dummy[8]; //ROWを埋めるためのダミー
unsigned char val2; //有効性検証バイト2
} df_cnt;

#define HEF_ADR 0x3f0 //HEFのワードアドレス

//----------------------------------------------
//HEF領域
//----------------------------------------------
const struct DF_CNT HEF@HEF_ADR={0xff,0xff}; //DFプレーヤーの引継情報の初期値

上記のようにHEF領域を確保しておけば、該当するHEFの領域にプログラムコードが配置されることを防止できる。リンカーコマンドやスクリプトで領域を確保するより、簡便でプログラムの見通しが良い。

12F1501はUARTモジュールを内蔵していないので、DFプレーヤーからの受信は、ソフトUARTの割込み処理で実装する。

【回路図と配線図】

DFPlayerMiniの制御1501(回路図)

DFPlayerMiniの制御1501(配線図1)
DFPlayerMiniの制御1501(配線図2)


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

プロジェクトは DFPlayer_1501.X

【感想】
これからは、EEPROMよりも書き換え時間が短かいHEFを利用するのがよさそうだ。
  1. 2019/06/08(土) 21:18:23|
  2. 電子オルゴール+音声再生
  3. | コメント:0

「DFPlayerMiniの制御」で操作性を改善(レジューム機能の改善)

DFPlayerMiniの制御車載外観2

【前振り】
一昨日行った 「DFPlayerMiniの制御」で操作性を改善(レジューム機能)」 は、EEPROMへの引継情報の退避が頻繁に発生して宜しくない。書き込み許容回数が1日27回じゃ少な過ぎる。そう思いながら作ったのだが、やはり宜しくない。そこで、電源オフのときにだけ退避するように、今になって真面目に取り組むことにした。

【設計】
電源がオフされても、引継情報を退避する時間はVddが保持されるように、電源からショットキーを介してVddを供給し、Vddには大きな電解コンを設置しておく。

Vddを抵抗分圧してコンパレータに入れて、FVRの1.024Vと比較することで、Vddが低下したことを検知する。

EEPROMへの書込み時間は5ms掛かるので8バイトの書き込みには40ms掛かる。実測による評価を行った結果、330uFとした。

Vddのパスコンを330uFとしたときの引継情報書き替えタイミングの実測結果
DFPlayerMiniの制御18313(EEP書替えタイミング検証)

【回路図と配線図】

DFPlayerMiniの制御18313(回路図)

DFPlayerMiniの制御18313(配線図1)
DFPlayerMiniの制御18313(配線図2)
Vddのパスコン330uFは基板には載せていない。


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

プロジェクトは DFPlayer_18313.X

【課題】
EEPROMへの書込みはバイト単位なので、引継情報のバイト数だけ時間が掛かる。そのため、Vddを保持する電解コンに大きなものが必要になる。そこで、退避先をHEFにすれば、ROW単位の消去書込みになるので、退避時間を短くできると思う。
  1. 2019/06/07(金) 19:16:21|
  2. 電子オルゴール+音声再生
  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