FC2ブログ

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

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

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

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

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

ブリッジ出力のメリット

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


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

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

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

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

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

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

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

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

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

16F1503 CWGにはフルブリッジモードが無く、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の最少構成でも載らないのでサポート対象から落とした。


【評価】
性能改善については、曲演奏と音声再生をコンカレントに走行しても正常な音で鳴っていて、アンダーランは発生していない。

音量と電力効率の評価には 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. | コメント:1

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電子オルゴールで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の制御」のレジューム対応版の改善

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

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

DFPlayerMiniの制御車載外観2

【前振り】
以前に作ったDFプレーヤー は車載で使っているのだが、車のキーONをするたびに再生開始の操作をするのが煩わしくなってきた。それで、キーON時には、キーOFFしたときの曲を自動的に再生開始するようにした。

【設計】
動作状態が変わる都度、管理情報をEEPROMに退避する。
POR時にEEPROMから管理情報を回復して、DFプレーヤを前回動作時の状態に設定する。
PAUSE状態だったときは、再生開始しない。
電源断を挟んで引き継ぐ情報は以下の通り。
・リピートモード(SD内リピート/ホルダ内リピート/1曲リピート)
・音量設定
・イコライザ設定
・PAUSE状態
・ホルダ番号
・トラック番号
ターゲットデバイスはEEPROMを持つものなら何でもよいので、廉価な16F18313を採用した。

EEPROMの書き替え耐力は100k回なので、10年間毎日使うとすると1日当たりの書き替え許容回数は 100k/10年/365日=27回 しかない。そのため、できるだけ永く使えるように、引継情報の書き換えは再生終了時とPAUSE操作時のみとした。ホルダとトラックの選択、音量、イコライザの変更は再生が終了するかPAUSEが操作されるまで引継情報に反映されないことになるが、許容することにする。

【回路図・配線図】
DFPlayerMiniの制御Cタイプ(回路図)
DFPlayerMiniの制御Cタイプ(配線図1)
DFPlayerMiniの制御Cタイプ(配線図2)


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

プロジェクトは DFPlayer_18313.X
  1. 2019/06/05(水) 21:04:18|
  2. 電子オルゴール+音声再生
  3. | コメント:0

PIC電子オルゴールVer5_7でCPSモジュールを使ったタッチセンスで音声再生

【前振り】
CPSを内蔵していないPICで実現したタッチセンスは当ブログで既に公開していて、おもちゃ修理に応用していただいている。簡易版(ローコスト版)なので、それなりの感度と安定性でときには誤動作することもあり、おもちゃとしては愛嬌があるかなと。それで今回は、CPSモジュールを使ってキチンとしたタッチセンスをやってみた。

【結果】
下記の動画のとおり、すこぶる快調に動作する。数10円のコスト差以上の価値がある。

長押しを検知する前には短押しを検知するが、それは自然の道理だ。
デモには含んでいないがマルチタッチも可能で、マトリクスSWとして使うこともできる。

【設計】
・使用部品
ターゲットデバイスはCPSモジュール内蔵では最廉価なPICの16F1823。
音声データを格納するSPIフラッシュはW25Q16。
CR類は電源パスコンの10uFが1個だけ。

・SPIは内蔵のMSSPモジュールを使う。16F1823は内蔵モジュールのピン割り当てがほぼ決められているので不自由だが、逆に悩みは無く、SPIピンを割り当てて残ったピンをタッチセンスに使う。

・「設計」と言って何かウンチクめいたことを書きたいのだけれど、CPSモジュールの使い方はデータシートの通りで工夫も何も無く、書くことが無い。オプションは幾つかあり、例えば「参照電圧」とか「電源モード」とかが選択できるのだが、変えてみての比較評価はしていない。

・タイマーリソースにはTMR1を使った。PIC電子オルゴールではPWM出力にTMR2を使っていて、TMR0とTMR1は空いている。ビット数が多いのと、カウントの開始と停止の制御がやり易いTMR1にした。

・固定タイムベースはPIC電子オルゴールの固有処理のコールバック周期を10msに設定して、それを使った。今回はCPSモジュールの入力チャネル数を5個としたので、特定のチャネルを評価するのは50ms周期となる。電子オルゴールの操作を行うには丁度良い時間だ。

・カウント値は時系列平均をとって、動作環境の揺らぎに追随するようにした。時系列平均値へのサンプル値の反映は1/16ずつにして、800msで半分程度が新陳代謝する。

・実機動作確認で判ったことは、入力チャネルによってカウント値が大きくバラつくことだ。そのため、カウント値の変化、つまりタッチ感度が違う。そこで、タッチ有り無しの判定の閾値は入力チャネル毎にチューニングができるようにした。おもちゃへの実装では入力チャネル毎に配線ルートやパッド形状が異なると思われるので、実装状態でチューニングを行う必要がありそうだ。

・回路図
PICとメモリを繋ぐだけなので、回路図は書いていない。ソースコードにコメント書きしているピン割り当てを参照のこと。

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

プロジェクトは onsei_PIC1823_SPI_touch.X
親のソースコードは onsei_PIC1823_SPI_touch..asm
音声データは voice_TOUCH
  1. 2019/05/14(火) 20:45:13|
  2. 電子オルゴール+音声再生
  3. | コメント:0

アンパンマンはじめてのおしゃべり48(音源のバックアップ)

PINOCCHIOの「アンパンマンはじめてのおしゃべり48」というぬいぐるみの知育おもちゃ。
アンパンマンはじめてのおしゃべり48外観

基板に電源は来ているが、うんともすんとも言わない。COB不良で音声再生の換装事案かと診察するのを楽しみにしていたのだが、不動作の原因は基板のランド剥がれで、バイパス配線で復旧してしまった。

でも、このような音声再生ものは音源が命だから、元気なうちにバックアップを録っておくことが重要だ。音源さえあればCOB換装はなんとかなる。

アンパンマンはじめてのおしゃべり48(音源ダイジェスト)

仕掛けはタッチセンスだった。両手両足腹鼻頭の7か所にタッチパッドが設置されていて、体中にタッチパッドの配線が走っている。そのため、抱いたまま遊ぶと誤動作が起き易いようだ。基板には傾斜センサーも設置されていた。

しゃべる文言はランダムであったり、「数を数えるよ」では10まで数えないと終らなかったり、動作シナリオがよく判らない。だから、すべての文言と効果音をバックアップできたかどうかは判らない。それと、実際に換装するときはシナリオを創作する必要がありそうだが、今はやらない。
  1. 2019/04/12(金) 20:21:53|
  2. 電子オルゴール+音声再生
  3. | コメント:0

「DFPlayerMiniの制御」で操作性を改善(SDカードの抜き挿し対応)

DFPlayerMiniの制御で操作性を改善(任意のトラックからのリピート再生) をやったばかりだが、今度は SDカードの抜き挿し に対応した。あってしかるべき機能だが、今までは無かった。当初はおもちゃの音声再生機能の換装を目的としたフィージビリティスタディだったので、コマンド1発で操作できる機能しか実現しなかった。その後、フツウのMP3プレーヤーとしての機能改善で、任意のトラックからのリピート再生を行ったのだが、SDカードの抜き差しもフツウに必要と感じてきた。

【要件】
SDカードの抜き挿し対応が無いとどうなるかと言うと、デバイス内のホルダ数の情報が更新されないため、実在しないホルダへ飛んだり、逆に実在するホルダへ進めなかったりする。機能追加と言うよりバグ対応に近いかも。

今回追加した機能は以下の2つのみだ。

・SDカードが抜かれたら、デバイスの管理情報をクリアする。
・SDカードが挿入されたら、デバイスの管理情報を取り込む。

【設計】
今回はファームウェアのみの改善であり、回路図と配線図は DFプレーヤーを制御するファームウェア を参照。 

DFPlayerMiniからの非同期通知で、該当イベントを受信したら、要件の処理を行う。

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

プロジェクトは DFPlayerB_322.X
  1. 2019/04/01(月) 07:46:33|
  2. 電子オルゴール+音声再生
  3. | コメント:0

「DFPlayerMiniの制御」で操作性を改善(任意のトラックからのリピート再生)

先般、DFプレーヤーを制御するファームウェア を作ってフィールドテスト中なのだが、操作性に若干の不満が出てきた。

【改善の要件】
DFプレーヤーでは以下のリピート再生のコマンドが提供されている。

①SDカード全体のリピート
②ホルダ内リピート
③1トラックだけのリピート

上記の①と②は再生開始トラックはそれぞれのリピート範囲での先頭のトラックから再生を開始する。任意のトラックからリピート再生を開始できない。これが「不満」なところ。

【設計】
今回はファームウェアのみの改善であり、回路図と配線図は DFプレーヤーを制御するファームウェア を参照。 

任意のトラックからリピート再生を行う具体的なやり方は以下のようにする。

①任意のトラックを再生開始する。
②1トラックの再生終了の通知を受信したら、次に再生するトラックを決めて、再生を指示する。
③リピートの範囲は[SDカード全体]、[ホルダ内]、[1トラックだけ]の3つのモードを設けて、次に再生するトラックを決める。

再生を開始するトラックは、ホルダ番号とホルダ内トラック番号で指示する。その操作は以下のようにする。

①リモコンの選局(+/-)ボタンでホルダ番号を+/-する。
②リモコンのチャンネル(0~9)ボタンで直接2桁のホルダ番号を指定することもできる。
③リモコンのビデオ選局(+/-)ボタンでホルダ内トラック番号を+/-する。

【DFプレーヤーの使い方のコツ】
①コマンドを連続送信するとDFプレーヤー側がビジーになることがあるので、30ms程度の時間間隔を空けると良い。
②POR後はDFプレーヤーからの初期化完了の通知が来るのを待つ。
③再生開始後にホルダ内トラック数をクエリすると再生が中断されることがあるので、先にクエリしてから再生開始を指示する。
④上記3..は具体的には、「クエリ」→30ms待ち→「再生開始」 とするのだが、クエリの応答は非同期に返って来るので、「クエリ」の応答からホルダ内トラック数を取込む。
⑤「再生開始」の指示に対しては、正常時は応答が無く、異常時にのみエラーが通知される。通知されるエラーは検知しても対処のしようが無い。「指定されたファイルが無い」もあるが、バグでしか発生しないので対処しない。

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

プロジェクトは DFPlayerB_322.X

僕は、OHM製のテレビ/ビデオ用リモコンに日立のメーカー設定をして使っている。ファームウェア内の赤外線コードの定義は、そのリモコン用になっているので、このファームウェアを応用する場合はお使いのリモコンに合わせた定義に替える必要がある。リモコンのボタンの構成によっては操作方法も替えないといけないかも知れない。
  1. 2019/03/30(土) 21:01:10|
  2. 電子オルゴール+音声再生
  3. | コメント:0

PIC電子オルゴールVer5_7で渡辺Dr(糸魚川)の2019年新曲を追加

糸魚川の渡辺Drから 「日本の歌2019年追加曲目」 をいただいて、PIC電子オルゴールVer5_7に追加した。

【追加曲目】
PIC電子オルゴールVer5_7で渡辺Dr(糸魚川)の2019年新曲を追加

【試聴】
(福岡)飯塚こわれたおもちゃの相談所 で追加曲を含むPIC電子オルゴールの全曲の試聴ができる。試聴は こちら

【ダウンロード】
ここから ダウンロードできる。
  1. 2019/03/07(木) 11:31:23|
  2. 電子オルゴール+音声再生
  3. | コメント:2

PIC電子オルゴールVer5_7でSPIメモリからタッチセンスで音声再生のSleep対応

先般行った 「PIC電子オルゴールVer5_7でSPIメモリからタッチセンスで音声再生」 に対して、Sleep対応を行った。

普通のスイッチでPIC電子オルゴールを操作するのであれば、IOC割り込みを仕掛けてSleepすればよいのだが、タッチセンスで操作する場合は、Sleep中はタイマーが停止するためタッチセンスができないので工夫が必要だ。

ターゲットデバイスは16F1503と16F1705。

【設計】
やり口は、Sleep中にWDTでWakeUpして、短時間のうちにタッチセンスを行うことだ。タッチセンス時間:WDT周期 が小さい程、平均的な消費電流を小さくできる。タッチセンスは1点当たり28us程度を見込むと5点で140usとなる。WDT周期を128msとすると、平均的な消費電流は約1/1000になる。

オルゴール演奏ではFoscは32MHzが必要だが、例えば16F1705でFosc=32MHzではx4PLLを使うことになり、x4PLLは安定するのに2ms程度も掛かる。これでは平均消費電流を抑えることができない。そのため、稼働していないときはFosc=16MHzに落として、定期的にタッチセンスを実行する。稼働中(Fosc=32MHz)はタイマーのプリスケーラを1/2に設定して、タッチセンスでの計時値が変わらないようにする。

16F1705ではポートピンの入力容量がピン間でバラつきがあるようだ。特にRA0とRA1はRA2とRA4、RA5と比べて入力容量が倍程度も大きく見える。手持ちの数個の16F1705をチェックしたが同じ傾向が認められた。16F1503はピン間の差は認められなかった。また、16F1705ではFoscが16MHzのときは32MHzのときより入力容量が大きく見える。そのため、事前に実験を行い、16F1705と16F1503ともに1MΩの外部プルアップでソフトの制御の範囲内に収まることを確認した。

【回路図】
PIC電子オルゴールテストベンチ回路図(タッチセンス)

【テストボード】
PIC電子オルゴールテストベンチ(タッチセンス1)
PIC電子オルゴールテストベンチ(タッチセンス2)

【消費電流の実測値】
非稼働時の平均消費電流は、16F1705では2uA、16F1503では8uAとなった。

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

今回追加したプロジェクトは onsei_PIC1705_SPI_touch.X
親のソースコードは onsei_PIC1705_SPI_touch.asm

更新したプロジェクトは onsei_PIC1503_SPI_touch.X
親のソースコードは onsei_PIC1503_SPI_touch.asm

【動作テスト】
単独タッチで音声を再生したあと、最後に複数タッチで音楽を再生している。

  1. 2019/03/06(水) 19:53:17|
  2. 電子オルゴール+音声再生
  3. | コメント:1

PIC電子オルゴールVer5_7でSPIメモリからタッチセンスで音声再生

2月は今日でおしまいだが、今月のブログ記事はまだ4件。そこで、駆け込みでブログへアップ。

ネタは、お馴染みのPIC電子オルゴールで、「SPIメモリからタッチセンスで音声再生」すること。 タッチセンスでPIC電子オルゴールを操作する のは以前にやっていたが、SPIメモリとの組み合わせはやっていなかった。真新しい仕掛けは無く、今までの事例を組み合わせるだけだ。

しかし、ここで言うタッチセンスは、CPSモジュールを内蔵しないPICで「無理矢理タッチセンス」するオタク的なやり方で、今までの事例を組み合わせるだけと言っても、マイコンの仕組みが判っていないとカスタマイズは難しい。そこで、「無理矢理タッチセンス」の応用事例を追加することで、理解の一助になればと思う。

【要件】
タッチSWは5個。それぞれのタッチで、各SWに割り当てられた音声を再生する。これは単独タッチセンスの機能だ。
複数のSWを同時にタッチすると、その組み合わせに割り当てられた音声を再生する。これは複合タッチの機能だ。

【設計】
タッチSWの複数タッチは、一般のキーマトリクスと違ってセレクト線とセンス線の区別が無く、単独タッチがほぼ同時に起きる事象だ。複数のタッチには多少の時間のズレがあるので、必ず単独タッチを検知する。

この単独タッチを排除することを考えないといけない。それには、一定時間は監視を続けて、単独タッチなのか複数タッチなのかを見極めることだ。

もう一つの方策は、単独タッチと複数タッチの誤検知を受容することだ。一瞬、間違った音声を再生し掛けてもすぐに正しい音声が出てくれば問題ないことが多い。但し、タッチを放したときには、複数タッチの音声を再生中は単独タッチに切り替えないように対処することが必要だ。今回の応用事例はこの方策を採っている。

16F1503で実現する場合は、タッチSWは5個まで実現できる。「無理矢理タッチセンス」ではタッチSWを接続するポートの要件として、出力モードに設定できることと、IOC割り込みが可能なことがある。これに該当するポートはRA0~2とRA4、RA5の5本しかない。

ポートの浮遊容量を充電時間で測定し、その変化でタッチを検知するのだが、PWM周期内に測定を終えなければならない。測定中にPWM(TMR2)割り込みが発生すると、IOC割り込みレイテンシが変化して測定に誤差を生じるからだ。ポートの浮遊容量を10pFとすると、1MΩとの時定数は10usになり、PWM周期の32usに比較していい塩梅になる。

【回路図】
PIC電子オルゴールテストベンチ回路図(タッチセンス)

【テストボード】
PIC電子オルゴールテストベンチ(タッチセンス1)
PIC電子オルゴールテストベンチ(タッチセンス2)

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

今回追加したプロジェクトは onsei_PIC1503_SPI_touch.X
親のソースコードは onsei_PIC1503_SPI_touch.asm

【動作テスト】
単独タッチで音声を再生したあと、最後に複数タッチで音楽を再生している。



  1. 2019/02/28(木) 10:15:21|
  2. 電子オルゴール+音声再生
  3. | コメント:0

「DFPlayerMiniの制御」でDFプレーヤーからの応答を受信する(ソフトUARTの割込み受信)

【前振り】
先般製作した 「DFPlayerMiniの制御」 ではPICからDFプレーヤーへ一方的に制御コマンドを送って、DFプレーヤーからの応答は見ないでいた。トラック番号やホルダ番号を指定して再生させるにはそれで十分なのだが、指定したトラックやホルダが存在しないとかのエラーの検知や、予めメディア内のトラック数やホルダ数を把握して気の利いた制御を行うにはDFプレーヤーからの応答を受信する必要がある。

そのためには、赤外線リモコンからの受信とDFプレーヤーからの応答受信をコンカレントに実行する必要があり、UARTモジュールを内蔵していないデバイスでは実現が難しい。UARTモジュールを内蔵したマイコンで最廉価なのは以下があるが、10F322の価格の倍近くしている。ファームウェアを工夫することで 10F322 で何とかしたい。
12F1572 @80円(2019年秋月)
16F18313 @80円(2019年秋月)

そこで、UARTモジュールを内蔵していないデバイスで割込み受信のフィージビリティスタディをやってみることにした。

結果は、赤外線リモコンからの受信とDFプレーヤーからの応答受信とがコンカレントに実行でき、実用生が実証できた。
この方法はDFプレーヤーに限らず ソフトUARTでの割り込み受信 として一般的に利用できる。

【設計】
赤外線受信機能とUART受信機能をコンカレントに実行するにはどちらかを割り込みで対応する必要がある。どちらの機能が汎用性があるかと言えばUARTだ。いろんなファームウェアでの使用頻度が高いし、調歩同期の仕様は普遍的であるからだ。それに比べて赤外線はエンコードの種類が多くて、特におもちゃ修理では都度カスタマイズが必要なことが多い。それを割り込み処理でやるとすれば無用の労力を喰うことになる。それで、UART受信を割り込み処理で実現することとする。

UARTモジュールを内蔵したデバイスでは1バイトを受信する毎に割り込みさせて受信データを取得するのだが、シリアル通信をI/Oポートの入力信号として割り込みで取り扱うには、以下のようにする。

・スタートビットのエッジをIOC割り込みで拾う。
・1/2ビット巾後にタイマー割り込みで、スタートビットの中央で信号レベルをチェックする。
・以降は1ビット巾間隔のタイマー割り込みで、データビットとストップビットをサンプルする。

つまり、ビット単位で割り込み処理をさせる訳だ。

UARTの受信中は頻繁に割り込み処理が走るので、タスク処理で実行している赤外線受信処理にも工夫が必要だ。
赤外線信号のパルス幅の計測を簡易なポーリングループ回数のカウントで行うと、割り込み処理でのCPU時間の誤差が積もって行くので、デコードを誤ることになる。そのため、タイマーを用いた時間計測を行って、割り込み処理での誤差が積もらないようにする。今回の10F322では、TMR0を赤外線受信に、TMR2をUART受信に充てている。

【回路図と配線図】
DFPlayerMiniの制御Bタイプ(回路図)
DFPlayerMiniの制御Bタイプ(配線図1)
DFPlayerMiniの制御Bタイプ(配線図2)

【UART割込み受信の検証】
割込みタイミングの検証
DFPlayerMiniソフトUART割込み受信タイミング検証波形
ch1(赤)が非同期シリアル受信データで 0x55 (1と0が交互に並ぶ)。
ch2(黄)が割り込み処理ルーチンでポートにパルスを出力させたタイミング検証用の信号。
各ビットの中央でサンプルできていることを示している。

赤外線受信とのコンカレント実行の検証
DFプレーヤーからの非同期シリアルデータ
DFPlayerMini応答取得(受信データ)

ファームウェアで割り込み受信した結果の表示
DFPlayerMini応答取得(表示)
<>内に、受信した応答の0起算で3バイト目と6バイト目のデータを表示している。

リモコンの選局ボタンを素早く押して、DFプレーヤーからの応答を受信完了する前に次の操作を矢継ぎ早に指示し、そのときの動作ログを以下に示す。赤外線受信とDFプレーヤーとの送受信の処理、更にログ取得の処理が同時期に重なっても、それぞれの処理は正常に動作している。
DFPlayerMiniソフトUART割込み受信検証ログ

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

ソフトUARTの割込み受信を行うプロジェクトは DFPlayerB_322.X
  1. 2019/02/06(水) 15:49:56|
  2. 電子オルゴール+音声再生
  3. | コメント:0

DFPlayerMiniの制御

DFPlayerMiniというMP3プレーヤーが廉価に出回っていて、おもちゃの音楽演奏や音声再生に使えそうなので、AliExpressで買ってみた。
DFPlayerMiniAli
送料込みで@130円くらい。制御用のマイコンを付けて、200円くらいで作れる。但し、SDカードは別途必要だ。
一般のMP3プレーヤーと同じ音質で、従来の(PIC電子オルゴールのような)8ビットPCMとは雲泥の差だ。
モノラル3Wのパワーアンプも付いていて、故障COBの換装に都合が良い。

もう一つの大きなメリットは、音源データはMP3またはWAV形式のファイルで、SDカードにはFATファイルシステムで格納することだ。つまり、おもちゃの音声再生機能をこれで換装すると、修理後にも音源データをユーザが自由に入れ替えることができるということだ。例えば、先般修理した 「マイクでワンちゃんトイプードル」 をこれで換装していたとすると、お子さんやお友達のお喋りに替えたり、犬の鳴き声を飼い犬のものにすることができる。

DFPlayerMiniの制御は、DFPlayerMiniへ非同期シリアルでコマンドを送ることで行う。
コマンドを1つ送るだけで、トラック番号を指定して再生を開始できる。途中停止もできる。この操作だけで電子オルゴールやおしゃべりおもちゃとして応用できる。

DFPlayerMiniから応答が返されるが、トラック番号を指定して再生するような単純な操作だけなら応答を受信する必要は無い。そのためUARTモジュールを内蔵していないマイコンでもよく、今回は10F322(@45円2019年秋月)を使った。

本記事は実際のおもちゃの換装事例ではなく、DFPlayerMiniを制御するファームウェアのフィージビリティスタディとして、赤外線リモコンで操作するMP3プレーヤーを製作した内容になっている。

【外観】
DFPlayerMini1
DFPlayerMini5
DFPlayerMini4


【要件】
・操作パネルを作るのはメンドーなので、操作にはテレビの赤外線リモコンを流用

・メディア内全トラックの繰返し再生、フォルダ内の繰返し再生、1トラックの繰返し再生

・一時停止/再開

・音量の増減

・イコライザの切り替え


【設計】
できるだけ簡易にするために、コマンド1発で実現できる機能に絞った結果が上記の要件となった。

例えば、メディア内全トラックの繰返し再生は 0x7e ff 06 11 00 00 01 ef の8バイトを9600bpsでDFPlayerMiniへ送ればよい。

データシートに規定されたコマンドを送るだけなので特に設計というものは無い。

今回のファームウェアはDFPlayerMiniの制御よりも赤外線信号のデコードの方が重くなっている。
赤外線リモコンは日立のテレビ/ビデオのものを使った。


【回路図と配線図】
DFPlayerMiniの制御(回路図)
DFPlayerMiniのVccに4Vを供給するために、レギュレータに下駄を履かせている。レギュレータに S-812C33AY-B-G を使ったら、消費電流が極めて小さくてダイオードのVfが十分に上がらなかったので、抵抗を付けた。


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

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

プロジェクトは DFPlayerA_322.X

ソフトUARTの割込み受信を行うプロジェクト は DFPlayerB_322.X
  1. 2019/01/17(木) 10:22:21|
  2. 電子オルゴール+音声再生
  3. | コメント:0

PIC電子オルゴールVer5_7で収容可能な音声数を255に拡大

【前振り】
PIC電子オルゴールで大容量SPIフラッシュをサポート して、それを使って先日は マイクでワンちゃんトイプードルのCOB不良 を修理したが、その際に収容音声数が制限の63に達してしまった。それで、収容可能な音声数を255に拡大することにした。

PICのプログラムメモリとI2Cフラッシュは元々容量が少ないので拡大しても意味が無い。SDカードとSPIフラッシュを255まで拡大した。

【設計】
音声再生処理では、ステータスの2ビットと音声番号の6ビットを合わせて1バイトで処理状態を管理している。このうちステータスの2ビットを別のメモリに移して、音声番号を8ビットで表すようにする。
SDカードとSPIフラッシュは同時使用できないので、全体として1バイトのメモリ増になる。
たった1バイトのメモリ増を気にするなんて、貧乏性だね~。いや、PICが貧乏性にさせるってことだな。

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

マイクでワンちゃんトイプードルの修理(音声再生換装)

1.患者
マイクでワンちゃんトイプードル(イワヤ)
マイクでワンちゃんトイプードル外観

歌ったりお喋りしたり、クチパクと体も動かすそうだ。
取説はこれ。
マイクでワンちゃんトイプードル説明書1
マイクでワンちゃんトイプードル説明書2
マイクでワンちゃんトイプードル説明書3
マイクでワンちゃんトイプードル説明書4


2.症状
①全く動かない。

3.診察
①電池はOK。電池受け金具もOK。

②内部の基板をチェックすると、電源供給は正常で、左手ボタンと口元のリードSWの動作も正常。

③モーターは2個あり、一つはTr1個でシングル駆動されていて、駆動信号を与えると正常に動作する。もう一つはHスイッチ「MX-08」でフルブリッジ駆動されていて、駆動信号を与えると正常に正逆転する。

④スピーカはCOBから直接ドライブされていて、スピーカ自体は正常だ。

⑤モーターやスピーカーへの出力ポートのインピーダンスを測るとHighZになっていて、マイコンの初期化ができていないようだ。

⑥COB故障と判断した。改めてCOBを見ると、モールドの一部が剥がれていた。ここまで割れていると故障していてもおかしくはない。
マイクでワンちゃんトイプードルCOB割れ

4.治療
①故障したCOBをPIC電子オルゴールで換装する。歌を歌うのでオルゴール演奏では無く、すべて音声再生で実行する。先般、 PIC電子オルゴールで大容量メモリをサポート して、 「今後はオルゴール演奏しないPIC電子オルゴールの応用が進む」 と予想したが、その初めての事例になる。

【要件】
②歌とお喋りの内容や仕草は元々の動きが判らないので独自に創作することになる。

③取説では12曲を収容しているが、1曲2分とすると24分になる。8ビット8kspsでは12MバイトになりW25Q128が必要になる。しかし、W25Q128は@71円もするので、@42円で調達できるW25Q64にして、収容曲数を若干少なくする。W25Q64は約17分間の音声が記録でき、8曲程度を収容可能である。

④お喋りの文言も取説には50個とあるが、なかなか50個も思い浮かばないので、できるだけ多くということにしておく。

⑤仕草は、お喋りや鳴き声、それと歌っているときはクチパクさせる。音声データのPCM値を評価して、音声に合わせて動作させる。

⑥体の動きは、曲の演奏中は横振りを主に、音声レベルが高まると縦振りさせる。体は1個のモーターで駆動されていて、回転方向によって横振りと縦振りを変えている。つまり、縦振りと横振りは同時には実行できないメカになっている。

【設計】
⑦PCM値を一定の閾値と比較したのでは曲によっては動き過ぎたり動かなかったりするので、一定期間での最大値をサンプルして、その最大値の変化の大きさを評価することにした。

⑧その変化が大きいときは体を縦振りし、小さいときは横振りさせると曲の進行に合ったいい振り付けになった。閾値の設定と評価ロジックはソースコードを参照。

⑨鳴き声を出すトリガになる背中のセンサー(Piez素子)にはTr1段のアンプが付いていたが、信号観測するとポート入力に十分な信号が確認されたので、換装後はアンプを割愛した。

1MΩでプルダウンしたときの出力信号
マイクでワンちゃんトイプードル圧電波形

⑩寝かしつけの動作のトリガになる傾斜センサーの出力が極めてノイジーだったので、コンデンサを抱かせた。

対策前(内部プルアップのみ)
マイクでワンちゃんトイプードル傾斜センサー対策前

対策後(3.3uFを抱かせたとき)
マイクでワンちゃんトイプードル傾斜センサー対策後

⑩センサーとモーター制御の点数からポート数が1個足りなくなったので、左手SWと口元リードリレーを合わせて1個のADC入力にしてポート数を節約した。詳細は回路図を参照。

⑪W25Q64の動作電圧が3.6Vまでであるで、3.3Vのレギュレータを設置する。消費電流が1uAのSIIのS-812を採用した。動作時の負荷電流により電池電圧が瞬低しBORすることがあったので、Vddに大き目の電解コンを設置した。

対策前
マイクでワンちゃんトイプードルBOR対策前

対策後(Vddラインに2200uFを設置)
マイクでワンちゃんトイプードルBOR対策後

⑫それでも、電池が消耗してくるとBORするので、BORを無効にした。そうするとハングアップする可能性が出てくるので、WDTを有効にしてハングアップ時はリセットさせることにした。Sleep中はWDTを無効にする。

マイクでワンちゃんトイプードル瞬低対策後

【回路図と配線図】
マイクでワンちゃん回路図
RA1の2.2KΩとRA3の1.5KΩの直列抵抗は周辺回路がICSPに影響を来たさないように入れている。
Sleep中はRA3の内部プルアップを無効にするので、1MΩでプルダウンンしてポート電位をLに固定する。
RA4は、Sleep中はL出力する。
RA0は、Sleep中はデジタル入力設定に変えて内部プルアップを有効にして、IOCNでWakeUpする。ポート数を節約するため、若干の電流消費は受容する。

マイクでワンちゃん配線図部品面

マイクでワンちゃん配線図半田面

【部品代実費】
16F1503 85円(秋月)
W25Q64 42円(AliExpress)
S-812C3A-B-G(3.3レギュレータ) 13円(秋月)
IRLM6344 5円(AliExpress)
ICソケットDIP8 5円(AliExpress)
ICソケットDIP14 7円(AliExpress)
SOP8ピッチ変換基板 6円(AliExpress)
蛇の目基板 5円(AliExpress)
CR類 50円
合計 218円

目標コストの200円を超えていて、修理すべきだったかどうか微妙なところだ。

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

【開発と動作確認】
最初はシミュレーションデバグで個別処理の処理ルートとロジックの確認を行う。

次にPIC電子オルゴールのテストベンチで、デバグログの採取を行って走行ルートをトレースする。
走行ルートがOKになったら、デバグログをオフにして、実時間で動かして出力信号を確認する。
マイクでワンちゃんトイプードルデバグ1

ファームウエアの目途が付いたら、換装用の基板を作る。 (下の画像では最終版と異なる部分がある)
マイクでワンちゃんトイプードル換装基板1
マイクでワンちゃんトイプードル換装基板3


音楽に合わせた仕草は実際に動かせてみないと評価できないので、テスト動作とICSPを繰返して実行できるようにしておく。
換装基板をぬいぐるみの外に出して、PICをICテストクリップでPICプログラマーに繋いでおく。PICへのVdd供給はターゲットの電源から行う。
マイクでワンちゃんトイプードルデバグ2


動作確認の動画はこれ



【後日談】
このワンちゃんを修理した後で、別の個体を診る機会を得た。その個体は手のSW配線の断線で、制御の仕掛けは健全だったので、本来の動作を調べた。

電源SWのポジションは 「PLAY」-「OFF」-「SOUND」 となっていて、その使い分けは以下のとおりであることが判った。

「PLAY」 は音声出力し、モーターも稼働する。
「SOUND」 は音声出力のみで、モーターは稼働しない。

次回、修理の機会があったら、そのように設計変更する。

また、歌・おしゃべり・鳴き声・寝かしつけの動作の元々の音声をバックアップした。放置したときの音声は2言だけ録れたが、なかなか音を出さないのでやめた。
  1. 2018/12/31(月) 13:08:00|
  2. 電子オルゴール+音声再生
  3. | コメント:0

PIC電子オルゴールVer5_7で渡辺Dr(糸魚川)のCdSモデルを追加

PIC電子オルゴールVer5_7で渡辺Dr(糸魚川)のCdSモデルを追加

糸魚川の渡辺Drが PIC電子オルゴールのCdSをSWに使ったサンプル を使って、「100円均一商品のLEDタッチライトを、電子オルゴールに改造してみました。」 とのことで、渡辺Drのプロジェクトをorgel5_7に追加した。 ここから ダウンロードできる。 渡辺Drのデモ動画や回路図などの製作記事はここ

【追加(改善)したプロジェクト】
yurikago_LF1705.x
yurikago_LF1822.x
yurikago_LF1840.x
yurikago_LF18326.x
yurikago_PIC1572.x
yurikago_PIC1705.x
yurikago_PIC1822.x
yurikago_PIC1825.x
yurikago_PIC1840.x
yurikago_PIC18313.x
yurikago_PIC18325.x
yurikago_PIC18326.x

なお、yurikagoLED_**** のプロジェクトは割愛した。
  1. 2018/12/19(水) 07:43:48|
  2. 電子オルゴール+音声再生
  3. | コメント:1
次のページ

プロフィール

大泉茂幸

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

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

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

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

カテゴリ

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

最新記事

最新コメント

月別アーカイブ

訪問者数

検索フォーム

RSSリンクの表示

リンク

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

QRコード

QR