【前振り】

ＣＨ３２Ｖ事始め（タッチセンスの再挑戦）　で静電容量検知方式でのタッチセンスが上手く動作したので、ＣＨ３２Ｖ電子オルゴールに組み込んだ。


【設計】

①タッチ検知方式

・ＣＨ３２Ｖでは、ハードの構造がＡＤＣのサンプルコンデンサと外部ピンを直接繋いだり切ったりできないので、ＣＶＤ方式によるタッチセンスが作れない。

・そのため、フツウの静電容量検知方式　でタッチセンスを作る。

②Ｒ８ＣでＣＶＤ方式のタッチセンスをサポートしているので、そのソースコードをベースに静電容量検知方式への変更を行う。

③極めて短時間にＡＤＣを実行しなければならないので、ＡＤＣのサンプルタイムは最小の３サイクルに設定する。

④ノイズによるＡＤＣ結果のバラつきを抑えるために複数回のＡＤＣを実行して、それらを合算した結果を評価する。

⑤環境の変化に追随するため、移動平均値を参照値として、それとの乖離を評価する。

⑥ＡＤＣ値が閾値近辺であるときに、判定のバタつきを防止するため、判定処理にヒステリシス特性を与える。


【実装】

①回路図とパッド形状は　ＣＨ３２Ｖ事始め（タッチセンスの再挑戦）　を参照。

②ソースコードはダウンロードファイルの　func_CVD.c　を参照。

③タッチセンス機能を実装するときは下記を宣言する。

#define CVD_EN //CVDを実装するときに宣言する

④タッチセンスのポートとオプションは下記のように宣言する。

//CVDのﾎﾟｰﾄ定義
#define CVD0_PORT GPIOA //CVD0のﾎﾟｰﾄ
#define CVD0_BIT 1 //CVD0のﾋﾞｯﾄ
#define CVD0_An 1 //CVD0のAn
//以下のﾀｲﾏｰﾓｰﾄﾞとﾘｱﾙﾓｰﾄﾞは択一
#define CVD0_TIMER //CVD0はﾀｲﾏｰﾓｰﾄﾞ
//#define CVD0_REAL //CVD0はﾘｱﾙﾓｰﾄﾞ


【評価】

①Ｒ８ＣのＣＶＤ方式と同程度に、感度と安定性が得られた（と感じた）。


【ダウンロード】

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

ＣＨ３２Ｖ００３Ｆ４Ｐ６では
プロジェクトディレクトリは　SW_F4P6
プロジェクトは　SW_F4P6.wvproj
根のソースコードは　SW_F4P6\User\main.c

ＣＨ３２Ｖ００３Ｊ４Ｍ６では
プロジェクトディレクトリは　SW_J4M6
プロジェクトは　SW_J4M6.wvproj
根のソースコードは　SW_J4M6\User\main.c

プロジェクトを利用する際は、目的に合わせてオプションの宣言を変えること。

【前振り】

先日は、ＣＨ３２Ｖ電子オルゴールで内蔵ＳＰＩモジュールを使うことを可能とした。今回は、内蔵Ｉ２Ｃモジュールも使用可能とした。

Ｉ２Ｃの転送速度はＳＰＩに比べてかなり遅いので、内蔵Ｉ２Ｃモジュールを使うことはＣＰＵ負荷を軽減する効果が大きい。

８ｋｓｐｓ８ビットの音声再生を行う場合、Ｉ２Ｃの転送レートをでは４００ｋｂｐｓとすると、ソフト実装では　（概算）９ビット／４００ｋｂｐｓ／１２５ｕｓ＝０．１８　となり、Ｉ２Ｃの転送に約２割のＣＰＵを費やすことになる。


【設計】

①従前はのピン割り当てはＩ２Ｃに関しては内蔵モジュールのピン割り当てに合わせていたため、今回の機能改善でピン割り当ての変更は無い。

Ｆ４Ｐ６のピン割り当てはＶｅｒ１＿１から変更なし。



②Ｊ４Ｍ６は内蔵Ｉ２Ｃモジュールの信号線が外部ピンに出ているので、Ｊ４Ｍ６でも内蔵Ｉ２Ｃモジュールの利用が可能である。ピン割り当てはＶｅｒ１＿１から変更なし。



③ＥＶＴサンプルのＥＥＰＲＯＭアクセスのプロジェクトからコピペするので独自の設計は殆ど無いのだが、サンプルは１バイトのアクセスしかやっていないので、複数バイトの読み込みと非同期な転送の中断のやり方は試行錯誤することになってしまった。

④Ｉ２Ｃをソフト実装する場合は下記を宣言する。宣言しなければ内蔵Ｉ２Ｃモジュールが使われる。

　#define I2C_SOFT //I2Cをｿﾌﾄ実装するときに宣言する


【実測】

①内蔵Ｉ２Ｃ転送時の信号観測

ｃｈ３（青）－デバグ信号でＨ期間が転送待ち時間


・８ｋｓｐｓ（周期は１２５ｕｓ）で転送待ちが発生している。

拡大


・待ち時間は約１．５ｕｓ。実際のＩ２Ｃバス上の転送はバックグラウンドで行われていて、Ｉ２Ｃペリフェラルのデータレジスタから受信データの取り出し時間である。転送待ち時間は発生していないことを示している。


【ダウンロード】

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

ＣＨ３２Ｖ００３Ｆ４Ｐ６では
プロジェクトディレクトリは　SW_F4P6
プロジェクトは　SW_F4P6.wvproj
根のソースコードは　SW_F4P6\User\main.c

ＣＨ３２Ｖ００３Ｊ４Ｍ６では
プロジェクトディレクトリは　SW_J4M6
プロジェクトは　SW_J4M6.wvproj
根のソースコードは　SW_J4M6\User\main.c

【前振り】

ＣＨ３２ＶはＣＰＵ性能が高くて、電子オルゴールの音質がいい。　４パート演奏や１６ｋｓｐｓの音声再生も全くストレスが無い。しかし、天邪鬼なもので、そうなると更に性能改善をしたくなる。それで、今まではＳＰＩをソフト実装していたが、内蔵ＳＰＩモジュールを使うことも可能とした。


【設計】

①従前はＡＤＣ機能を持つポートをアプリでの使用に残すべく、ＳＰＩ信号はＡＤＣ機能のないポートに割り当てていた。しかし、内蔵ＳＰＩモジュールが使うピンは割り当てがほぼ決まっているので、従前のピン割り当てと異なってしまう。そのため、Ｖｅｒ１＿１からＶｅｒ１＿２へリビジョンアップすることにした。

ピン割り当て


②Ｊ４Ｍ６は内蔵ＳＰＩモジュールの信号線が外部ピンに出ていないので、内蔵ＳＰＩモジュールの利用はＭ４Ｐ６のみとなる。Ｊ４Ｍ６のプロジェクトは改変しないで（但し、ソフト実装か否かの宣言は入れているが）Ｖｅｒ１＿２に含める。

ピン割り当て（Ｖｅｒ１＿１から変更なし）


③ＥＶＴサンプルをコピペするので、独自の設計は無い。

④内蔵ＳＰＩにより、高速のの転送速度が得られたので、割り込みやイベントドリブンの仕掛けは講じないこととした。

⑤ＳＰＩをソフト実装する場合は下記を宣言する。宣言しなければ内蔵ＳＰＩモジュールが使われる。

　#define SPI_SOFT //SPIをｿﾌﾄ実装するときに宣言する

【実測】

以下の波形表示は以下となっている。

ｃｈ１（赤）－ＳＣＫ
ｃｈ２（黄）－ＭＯＳＩ
ｃｈ３（青）－ＭＩＳＯ
ｃｈ４（紫）－ＳＳ

①ＳＰＩソフト実装時のＳＰＩ信号観測


・転送時間は約７ｕｓ／バイト

②内蔵ＳＰＩモジュール使用時のＳＰＩ信号観測


拡大


・転送時間は約１．４ｕｓ／バイト

③（参考）１６F1705のＳＰＩ波形

ソフト実装


内蔵ＳＰＩモジュール


④（参考）Ｒ８Ｃ／Ｍ１１のＳＰＩ波形


・比較したマイコンの中で最も性能が悪い。

・ＳＣＫが固まっている１０ｕｓはＰＷＭ（タイマー）割り込み処理を実行している期間だ。割り込み処理はＤＣ値をリングバッファからＰＷＭレジスタへ転送しているだけなのだが、この時間が電子オルゴールでのアンダーラン発生の誘因になっている。これほど、Ｒ８Ｃの割り込みレイテンシーが悪いとは承知していなかったが、コンテキストの保存／回復をすべてソフトで行っていることが致命的だ。

【ダウンロード】

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

ＣＨ３２Ｖ００３Ｆ４Ｐ６では
プロジェクトディレクトリは　SW_F4P6
プロジェクトは　SW_F4P6.wvproj
根のソースコードは　SW_F4P6\User\main.c

ＣＨ３２Ｖ００３Ｊ４Ｍ６では
プロジェクトディレクトリは　SW_J4M6
プロジェクトは　SW_J4M6.wvproj
根のソースコードは　SW_J4M6\User\main.c

【宝石箱】

オルゴール付き宝石箱で、蓋を開けるとオルゴールが鳴り出し、閉じると止まる。必ずしも宝石を入れる必要は無いが、蓋の開け閉めでオルゴールを制御することがこの記事のテーマだ。

先日は　ＰＩＣ電子オルゴールに対して機能追加を行った　のだが、今回はＣＨ３２Ｖ電子オルゴールにも同じ機能追加を行った。


【設計】

①ＣＨ３２Ｖ電子オルゴールで、蓋の開け閉めをＣｄＳで検知し、蓋を開けると鳴り出し、蓋を閉めると鳴り止むようにする。

②今までも、電子オルゴールはＣｄＳで制御ができるようになっているが、それは「手を翳すとオンするスイッチ」として実装している。つまり、暗くなるとオンする。宝石箱では蓋を開けて明るくなるとオンしないといけない。

③明／暗の検知を反転させればよいのだが。。。

・ＰＩＣとＲ８Ｃの電子オルゴールではＣｄＳをローサイドに配置して、暗でポートがＨになるようにしている。その理由は、ポートの内部ブルアップ機能を使ってＣｄＳへの電源供給を制御することで省電力にするためだ。

・ＣｄＳをハイサイドに配置すると、暗でポートはＬになって、明／暗の検知を反転させることができる。ＣＨ３２Ｖにはポートを内部ブルダウンすることができるので、回路を宝石箱用にすれば明／暗の検知を反転させることができる。

・今回は、ＣｄＳをローサイドに配置したままで、プログラムを変更して明／暗の検知を反転させることも可能なようにした。

④タイマーモードでの検知の反転は

・ＣｄＳの評価にタイマーモードとリアルモードがある。タイマーモードでは、短オンで演奏／再生を開始し、長オンで演奏／再生を中断する。この短オンと長オンの区別は宝石箱の操作にはそぐわない。

・そのため、宝石箱の蓋の操作はリアルモードでのみ有効とする。

⑤実装方法

・明／暗の検知を宝石箱の蓋の操作にするには　ＣｄＳ＿ＦＵＴＡ　を宣言する。

・今までのＣｄＳの評価では周囲の明るさの変化に追随するように、ＡＤＣ結果の移動平均を計算して、それを閾値に反映している。宝石箱の蓋では周囲の明るさの変化に追随せずに、絶対的な評価が必要になる。そのため、固定閾値を　ＣｄＳ＿ＴＨＲ　で宣言することとした。

・宝石箱に応用するときの設定例

ＣＨ３２Ｖ００３Ｆ４Ｐ６では
//CdSのﾎﾟｰﾄ定義
#define CdS_GPIO GPIOA //CdSのﾎﾟｰﾄ
#define CdS_BIT 2 //CdSのﾋﾞｯﾄ
#define CdS_An 0 //CdSのAn
//#define CdS_INV //CdS入力は負論理(暗=L)
//以下のﾀｲﾏｰﾓｰﾄﾞとﾘｱﾙﾓｰﾄﾞは択一
#define CdS_TIMER //CdSはﾀｲﾏｰﾓｰﾄﾞ
//#define CdS_REAL //CdSはﾘｱﾙﾓｰﾄﾞ
//#define CdS_THR 100 //CdS評価の固定閾値[1/256]
//#define CdS_FUTA //CdS判定反転(明=ｵﾝ)

ＣＨ３２Ｖ００３Ｊ４Ｍ６では
//CdSのﾎﾟｰﾄ定義
#if BTL==1 //ｺﾝﾌﾟﾘ出力のとき
#define CdS_GPIO GPIOC //CdSのﾎﾟｰﾄ
#define CdS_BIT 4 //CdSのﾋﾞｯﾄ
#define CdS_An 2 //CdSのAn
#else //ｼﾝｸﾞﾙ･ﾌﾞﾘｯｼﾞ･ﾌﾞﾚｰｷ出力のとき
#define CdS_GPIO GPIOA //CdSのﾎﾟｰﾄ
#define CdS_BIT 1 //CdSのﾋﾞｯﾄ
#define CdS_An 1 //CdSのAn
#endif
//#define CdS_INV //CdS入力は負論理(暗=L)
//以下のﾀｲﾏｰﾓｰﾄﾞとﾘｱﾙﾓｰﾄﾞは択一
#define CdS_TIMER //CdSはﾀｲﾏｰﾓｰﾄﾞ
//#define CdS_REAL //CdSはﾘｱﾙﾓｰﾄﾞ
//#define CdS_THR 100 //CdS評価の固定閾値[1/256]
//#define CdS_FUTA //CdSｵﾙｺﾞｰﾙ箱のﾌﾀ判定(明=ｵﾝ)する

・上記のコードは根のソースコードに置く。評価ロジックは、ａｐｌ＿ＳＷ．ｃ　に置く。


【ダウンロード】

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

ＣＨ３２Ｖ００３Ｆ４Ｐ６では
プロジェクトディレクトリは　SW_F4P6
プロジェクトは　SW_F4P6.wvproj
根のソースコードは　SW_F4P6\User\main.c

ＣＨ３２Ｖ００３Ｊ４Ｍ６では
プロジェクトディレクトリは　SW_J4M6
プロジェクトは　SW_J4M6.wvproj
根のソースコードは　SW_J4M6\User\main.c

【宝石箱】

オルゴール付き宝石箱で、蓋を開けるとオルゴールが鳴り出し、閉じると止まる。必ずしも宝石を入れる必要は無いが、蓋の開け閉めでオルゴールを制御することがこの記事のテーマだ。

先日は　ＰＩＣ電子オルゴールに対して機能追加を行った　のだが、今回はＲ８Ｃ電子オルゴールにも同じ機能追加を行った。


【設計】

①Ｒ８Ｃ電子オルゴールで、蓋の開け閉めをＣｄＳで検知し、蓋を開けると鳴り出し、蓋を閉めると鳴り止むようにする。

②今までも、電子オルゴールはＣｄＳで制御ができるようになっているが、それは「手を翳すとオンするスイッチ」として実装している。つまり、暗くなるとオンする。宝石箱では蓋を開けて明るくなるとオンしないといけない。

③明／暗の検知を反転させればよいのだが。。。

・今まではＣｄＳをローサイドに配置して、暗でポートがＨになるようにしている。その理由は、ポートの内部ブルアップ機能を使ってＣｄＳへの電源供給を制御することで省電力にするためだ。

・ＣｄＳをハイサイドに配置すると、暗でポートはＬになって、明／暗の検知を反転させることができる。しかし、プルダウンを制御するためのポートが必要になる。

・やはり、ＣｄＳはローサイドに配置して、プログラムを変更して明／暗の検知を反転させるのが合理的だ。

④タイマーモードでの検知の反転は

・ＣｄＳの評価にタイマーモードとリアルモードがある。タイマーモードでは、短オンで演奏／再生を開始し、長オンで演奏／再生を中断する。この短オンと長オンの区別は宝石箱の操作にはそぐわない。

・そのため、宝石箱の蓋の操作はリアルモードでのみ有効とする。

⑤実装方法

・明／暗の検知を宝石箱の蓋の操作にするには　ＣｄＳ＿ＦＵＴＡ　を宣言する。

・今までのＣｄＳの評価では周囲の明るさの変化に追随するように、ＡＤＣ結果の移動平均を計算して、それを閾値に反映している。宝石箱の蓋では周囲の明るさの変化に追随せずに、絶対的な評価が必要になる。そのため、固定閾値を　ＣｄＳ＿ＴＨＲ　で宣言することとした。

・宝石箱に応用するときの設定例

//CdSのﾎﾟｰﾄ定義
#define CdS_ADINSEL 0b01000000 //CdSのADINSEL値
#define CdS_ADMOD 0b00000011 //CdSのADMOD値
#define CdS_ADn ad0 //CdSのADﾚｼﾞｽﾀ
#define CdS_PU pu1_2 //CdSのﾌﾟﾙｱｯﾌﾟﾋﾞｯﾄ
//#define CdS_INV //CdS入力は負論理(暗=L)
//以下のﾀｲﾏｰﾓｰﾄﾞとﾘｱﾙﾓｰﾄﾞは択一
#define CdS_TIMER //CdSはﾀｲﾏｰﾓｰﾄﾞ
//#define CdS_REAL //CdSはﾘｱﾙﾓｰﾄﾞ
//#define CdS_THR 100 //CdS評価の固定閾値[1/256]
//#define CdS_FUTA //CdSｵﾙｺﾞｰﾙ箱のﾌﾀ判定(明=ｵﾝ)する

・上記のコードは根のソースコードに置く。評価ロジックは、ａｐｌ＿ＳＷ．ｃ　に置く。


【ダウンロード】

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

ワークスペースは　orgel.hws
プロジェクトは　orgel_SW_M11
根のソースコードは　orgel_SW_M11.c

【宝石箱】

オルゴール付き宝石箱で、蓋を開けるとオルゴールが鳴り出し、閉じると止まる。必ずしも宝石を入れる必要は無いが、蓋の開け閉めでオルゴールを制御することがこの記事のテーマだ。

この宝石箱の蓋の機能は随分昔に作り込んだと思うのだが、いつの間にか揮発してしまっていた。


【設計】

①ＰＩＣ電子オルゴールで、蓋の開け閉めをＣｄＳで検知し、蓋を開けると鳴り出し、蓋を閉めると鳴り止むようにする。

②今までも、電子オルゴールはＣｄＳで制御ができるようになっているが、それは「手を翳すとオンするスイッチ」として実装している。つまり、暗くなるとオンする。宝石箱では蓋を開けて明るくなるとオンしないといけない。

③明／暗の検知を反転させればよいのだが。。。

・今まではＣｄＳをローサイドに配置して、暗でポートがＨになるようにしている。その理由は、ポートの内部ブルアップ機能を使ってＣｄＳへの電源供給を制御することで省電力にするためだ。

・ＣｄＳをハイサイドに配置すると、暗でポートはＬになって、明／暗の検知を反転させることができる。しかし、プルダウンを制御するためのポートが必要になる。

・やはり、ＣｄＳはローサイドに配置して、プログラムを変更して明／暗の検知を反転させるのが合理的だ。

④タイマーモードでの検知の反転は

・ＣｄＳの評価にタイマーモードとリアルモードがある。タイマーモードでは、短オンで演奏／再生を開始し、長オンで演奏／再生を中断する。この短オンと長オンの区別は宝石箱の操作にはそぐわない。

・そのため、宝石箱の蓋の操作はリアルモードでのみ有効とする。

⑤実装方法

・明／暗の検知を宝石箱の蓋の操作にするには　ＣｄＳ＿ＦＵＴＡ　を宣言する。

・今までのＣｄＳの評価では周囲の明るさの変化に追随するように、ＡＤＣ結果の移動平均を計算して、それを閾値に反映している。宝石箱の蓋では周囲の明るさの変化に追随せずに、絶対的な評価が必要になる。そのため、固定閾値を　ＣｄＳ＿ＴＨＲ　で宣言することとした。

・宝石箱に応用するときの設定例

//CdSのﾎﾟｰﾄ定義
#define CdS_TRIS TRISC //CdSのTRISﾚｼﾞｽﾀ
#define CdS_WPU WPUC //CdSのWPUﾚｼﾞｽﾀ
#define CdS_ANSEL ANSELC //CdSのANSELﾚｼﾞｽﾀ
#define CdS_BIT 3 //CdSのﾋﾞｯﾄ番号(RC3)
#define CdS_CHS 7 //CdSのADCﾁｬﾈﾙ番号(RC3)
//#define CdS_INV //CdS入力は負論理(暗=L)
//以下のﾀｲﾏｰﾓｰﾄﾞとﾘｱﾙﾓｰﾄﾞは択一
//#define CdS_TIMER //CdSはﾀｲﾏｰﾓｰﾄﾞ
#define CdS_REAL //CdSはﾘｱﾙﾓｰﾄﾞ
#define CdS_THR 100 //CdS評価の固定閾値[1/256]
#define CdS_FUTA //CdSｵﾙｺﾞｰﾙ箱のﾌﾀ判定(明=ｵﾝ)する

・上記のコードは根のソースコードに置く。評価ロジックは、ａｐｌ＿ＳＷ．ｃ　に置く。


【ダウンロード】
ｏｒｇｅｌ７＿６の設計資料と開発プロジェクト一式は　ここから　ダウンロードできる。

【前振り】
ＣＨ３２Ｖ電子オルゴールはＰＩＣ電子オルゴールから　全曲の移行が終わって　一段落したのだが、サポートデバイスがＦ４Ｐ６だけだった。Ｊ４Ｍ６も比較的廉価に流通していて、これもサポートすることにした。


【設計】

①Ｆ４Ｐ６での複数のピンがＪ４Ｍ６では一つのピンに集約されている。イメージとしては、内部の複数のピンが一つの外部ピンへ繋がれていると見られる。そのため、出力が競合しないように、ピンのポート構成（ＣＦＧＬＲ）を適切に設定しないといけない。

②Ｊ４Ｍ６は、メモリ容量はＦ４Ｐ６と同じだが、８ピンなので機能面で制約が生じる。

・Ｆ４Ｐ６では出力タイプ（ＢＴＬ）を変えてもＰＷＭの正相および逆相の出力ピンが変わらないようにピン割り当てを行うことができたが、Ｊ４Ｍ６ではそれは無理だった。

・ブリッジ・ブレ―キ出力時はＳＷ・ＣｄＳ・ＮＯＩＳＥをフル実装できない。

・ＳＰＩのピン数を節約するため、２線ＳＰＩでの接続とする。

・機能設定に因っては、デバグ情報出力ピンの割り当てを替える必要がある。


【ダウンロード】

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

プロジェクトディレクトリは　SW_J4M6
プロジェクトは　SW_J4M6.wvproj
根のソースコードは　SW_J4M6\User\main.c

ポート割り当てなどのハード情報は根のソースコードに含まれている。

ｓｏｎｇデータとｏｎｐｕデータは　最上位ディレクトリにある。


【カスタマイズ】

①オルゴール演奏と音声再生のカスタマイズ項目（ＢＴＬ、ＰＡＲＴ＿Ｎなど）は　SW_J4M6\User\orgel_cnf.h　にある。

②曲の収容を設定するソングインデックスは　SW_J4M6\User\song_idx.s　にある。

③収容する音声を設定する音声インデックスは　SW_J4M6\User\main.c　にある。

【標準化】

・今までＰＩＣ、ＬＰＣ、ＳＴＭ３２、Ｒ８Ｃ、ＣＨ３２Ｖといろんなマイコンに電子オルゴールを載せて来たが、ｓｏｎｇデータとｏｎｐｕデータがそれぞれのマイコン毎にインプリメントが異なってきている。

・それぞれの時点で最善と思うようにやってきたのだが、結果として、てんでんばらばらな状況になってしまった。

・これまでの経験から各マイコンの事情が判ってきて、直近のＣＨ３２Ｖ００３でのインプリメント　を標準として、他のマイコンへ横展開していく。一言でいえば、各マイコンで同じｓｏｎｇファイルとｏｎｐｕファイルを使う、ってことだ。

・今回は、Ｒ８Ｃ電子オルゴールに適用した。Ｖｅｒ１＿１に対して機能の変更はないが、ｓｏｎｇファイルとｏｎｐｕファイルが全面的に更改となるので、Ｖｅｒ１＿２とした。

【設計】

①変更はｓｏｎｇファイルとｏｎｐｕファイルのみとする。

②標準化されたｓｏｎｇファイルとｏｎｐｕファイルをｐｉｃ－ａｓで期待通りに解釈させるために、下記の宣言を行う。

//==============================================
//songﾃﾞｰﾀとonpuﾃﾞｰﾀの標準化のための設定
//==============================================
#define bgn_mac #pragma asm //ｱｾﾝﾌﾞﾗｺｰﾄﾞの始まり
#define end_mac #pragma endasm //ｱｾﾝﾌﾞﾗｺｰﾄﾞの終わり
#define asb_mac #pragma asm //ｱｾﾝﾌﾞﾗｺｰﾄﾞの始まり(onpuｺｰﾄﾞの途中)
#define ase_mac #pragma endasm //ｱｾﾝﾌﾞﾗｺｰﾄﾞの終わり(onpuｺｰﾄﾞの途中)
#define NULL 0 //NULLを0とする

【ダウンロード】

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

ワークスペースは　orgel.hws
プロジェクトは　orgel_SW_M11
根のソースコードは　orgel_SW_M11.c

【標準化】

・今までＰＩＣ、ＬＰＣ、ＳＴＭ３２、Ｒ８Ｃ、ＣＨ３２Ｖといろんなマイコンに電子オルゴールを載せて来たが、ｓｏｎｇデータとｏｎｐｕデータがそれぞれのマイコン毎にインプリメントが異なってきている。

・それぞれの時点で最善と思うようにやってきたのだが、結果として、てんでんばらばらな状況になってしまった。

・これまでの経験から各マイコンの事情が判ってきて、直近のＣＨ３２Ｖ００３でのインプリメント　を標準として、他のマイコンへ横展開していく。一言でいえば、各マイコンで同じｓｏｎｇファイルとｏｎｐｕファイルを使う、ってことだ。

・今回は、ＰＩＣ電子オルゴールに適用した。Ｖｅｒ７＿５に対して機能の変更はないが、ｓｏｎｇファイルとｏｎｐｕファイルが全面的に更改となるので、Ｖｅｒ７＿６とした。

【設計】

①標準化はｓｏｎｇファイルとｏｎｐｕファイルのみとする。

②標準化されたｓｏｎｇファイルとｏｎｐｕファイルをｐｉｃ－ａｓで期待通りに解釈させるために、下記の宣言を行う。

//==============================================
//songﾃﾞｰﾀとonpuﾃﾞｰﾀの標準化のための設定
//==============================================
#define bgn_mac //bgn_macを殺す
#define end_mac //end_macを殺す
#define asb_mac //asb_macを殺す
#define ase_mac //ase_macを殺す
#define NULL 0 //NULLを0とする

【ダウンロード】
ｏｒｇｅｌ７＿６の設計資料と開発プロジェクト一式は　ここから　ダウンロードできる。

【前振り】
先般は、ＣＨ３２Ｖ００３の電子オルゴールの初版を公開した。但し、実装したのは「ＡＩＡＩ」の１曲だけだった。

その後、ＰＩＣ電子オルゴールの最新版から全曲の移行を実施してきた。それが完了したので、公開する。

移行作業の中でバグ改修とメモリ削減の改善も実施した。


【ダウンロード】

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

プロジェクトディレクトリは　SW_F4P6
プロジェクトは　SW_F4P6.wvproj
根のソースコードは　SW_F4P6\User\main.c

ポート割り当てなどのハード情報は根のソースコードに含まれている。

ｓｏｎｇデータとｏｎｐｕデータは　最上位ディレクトリにある。


【カスタマイズ】

①オルゴール演奏と音声再生のカスタマイズ項目（ＢＴＬ、ＰＡＲＴ＿Ｎなど）は　SW_F4P6\User\orgel_cnf.h　にある。

②曲の収容を設定するソングインデックスは　SW_F4P6\User\song_idx.s　にある。

③収容する音声を設定する音声インデックスは　SW_F4P6\User\main.c　にある。


【今後の課題】

①ｓｏｎｇデータとｏｎｐｕデータの標準化

・今までＰＩＣ、ＬＰＣ、ＳＴＭ３２、Ｒ８Ｃ、ＣＨ３２Ｖといろんなマイコンに電子オルゴールを載せて来たが、ｓｏｎｇデータとｏｎｐｕデータがそれぞれのマイコン毎にインプリメントが異なってきている。

・それぞれの時点で最善と思うようにやってきたのだが、結果として、てんでんばらばらな状況になってしまった。

・それで、マイコンの種類を超えて、ｓｏｎｇデータとｏｎｐｕデータの標準化を行いたい。

・今回のＣＨ３２Ｖ００３でのインプリメントを標準として、他のマイコンへ横展開していく。そうすれば、移行ツールは不要となる。

【前振り】

鳴り物おもちゃのＩＣが壊れたとき、殆どの場合は　ＰＩＣ電子オルゴール　で換装している。しかし、新型コロナ感染拡大の影響で半導体の流通価格が高騰し、秋月のＰＩＣも値上がりが続いていておもちゃ修理には使い辛くなってきた。

ＰＩＣに代わる廉価なマイコンで、秋月からＲ８Ｃ／Ｍ１１Ａが＠５０円で販売開始されたので、先般は、Ｒ８ＣにＰＩＣ電子オルゴールを移植した。

その後、秋月からＣＨ３２Ｖ００３Ｆ４Ｐ６が＠５０円で販売開始された。このマイコンは、ＡｌｉＥｘｐｒｅｓｓでは送料込み＠２８円だった。それで、これにも電子オルゴールを移植した。

これで、電子オルゴールを載せられるマイコンはＰＩＣ、ＬＰＣ、ＳＴＭ３２、Ｒ８Ｃ、ＣＨ３２Ｖになった。いろんなマイコンをサポートしておけば、実際におもちゃの修理を行う時点で廉価なマイコンを選ぶことができる。


【設計】

①機能要件

ＰＩＣ電子オルゴールと同等とする。

・４パートのオルゴール演奏、音符データの演奏とキーボード演奏の動作を可能とする。

・エンベロープ、ベロシティ、ピッチベンド、音源切り替えなどの演奏表現もＰＩＣ電子オルゴールとおなじ。

・８ビット８ｋｓｐｓの音声再生、音声データはプログラムメモリ・Ｉ２Ｃメモリ・ＳＤカード・ＳＰＩメモリに置く。

・オルゴール演奏と音声再生、おもちゃの周辺回路（ＬＥＤ点滅やモーター駆動など）の制御をコンカレントに実行可能とする。

・オーディオ出力はＰＷＭによるＤ／Ａ変換で行う。

・修理対象のおもちゃに合わせたアプリ処理のカスタマイズが簡単にできる。

②開発言語と環境

・ＣＰＵはＰＩＣよりも速いので、Ｃ言語で開発する。

・Ｒ８Ｃ電子オルゴールがＣ言語で書かれているので、それをベースに改変する。Ｒ８Ｃ電子オルゴールはＰＩＣ電子オルゴールの最新機能が含まれている。

・開発環境は本家純正のＭｏｕｎＲｉｖｅｒＳｔｕｄｉｏとする。環境構築は　ここを　参照。

③ソングデータの持ち方

・音符データ中にはリピートを実現するために分岐の記述が必要だが、Ｃ言語ではデータのオフセットを把握することができないので、分岐先を表現できない。そのため、ｏｎｐｕデータはアセンブラで書くしかない。

・ＣＨ３２Ｖのインラインアセンブラの書き方が判らなかったので、純粋にアセンブラで書く。Ｃ言語と共有する宣言値はＣ言語とアセンブラで共有するヘッダファイルに置く。そのため、プリプロセッサ疑似命令（＃ｄｅｆｉｎｅ等）のみで書くこととする。

・ＣＨ３２Ｖのアセンブラマクロの書き方が判らなかったので、プリプロセッサ疑似命令（＃ｄｅｆｉｎｅ等）で書くことにした。

・ＣＨ３２Ｖ００３Ｆ４Ｐ４はプログラムフラッシュが１６ｋバイトあり、１６Ｆ１７０５と同程度の曲数が収容可能。

④音符データの枠組み



Ｒ８Ｃと同じ。

⑤ソースコードの構成

・ＭｏｕｎＲｉｖｅｒＳｔｕｄｉｏではプロジェクトディレクトリ内のすべての　．ｃ　と　．ｓ　がｂｕｉｌｄの対象にされてしまう。電子オルゴールでは個別のアプリによって必要なコードのみをｂｕｉｌｄ対象にしたい。そこで、アプリに固有のコードのみをプロジェクトディレクトリ内に置き、どのアプリにも共通に使うコードはプロジェクトディレクトリの一つ上のディレクトリ階層におき、適宜、＃ｉｎｃｌｕｄｅで呼び込むことにした。但し、ＭｏｕｎＲｉｖｅｒＳｔｕｄｉｏで用意されるコードは元々の配置に従う。

　個別のアプリの根のソースコード　ｍａｉｎ．ｃ

　共通に使うコードは　ｍａｉｎ．ｃ以外のファイル（ｏｒｇｅｌエンジン、ｏｎｐｕファイル、ｓｏｎｇファイル、各種波形ファイル、共通のコードなど）

・ファイルの構成

ｍａｉｎ．ｃ　個別のアプリの根のソースコードで、ファイル名はｍａｉｎ．ｃだがｍａｉｎ（）は含まない。各種設定値の宣言と必要なコードの呼び込みを行う。

ａｓｍ．ｈ　音符データ（アセンブラ）用ヘッダファイル（Ｃ言語側とも共有する）

ｄｅｖ＿ｘｘｘ．ｃ　デバイス依存処理（ＰＷＭ）

ａｐｌ＿ｘｘｘ．ｃ　アプリケーション処理（Ｓｌｅｅｐを含む）

ｆｕｎｃ＿ｘｘｘ．ｃ　基本機能の処理（ＳＷ、ＣｄＳ、ＣＶＤ）

ｓｏｎｇ＿ｘｘｘ．ｃ　ソングデータ

ｏｎｐｕ＿ｘｘｘ．ｃ　音符データ

ｗａｖｅ＿ｘｘｘ．ｃ　音源波形

ｅｎｖｅ＿ｘｘｘ．ｃ　エンベロープ波形

ｐｉｔｃｈ＿ｘｘｘ．ｃ　ピッチベンド波形

ｖｏｉｃｅ＿ｘｘｘ．ｃ　音声データ

ｏｒｇｅｌ．ｃ　エンジン部の処理で、ｍａｉｎ（）はここにある。

ｏｒｇｅｌ．ｈ　Ｃ言語用ヘッダファイル

ｏｒｇｅｌ．ｉｎｃ　インラインアセンブラ用ヘッダファイル

⑤ＰＷＭの設定

・内部オシレータが４８ＭＨｚなので、ＰＷＭの１ステップは１／４８ＭＨｚの２のべき乗倍になる。

・ステップ数を１５００にするとＰＷＭ周期は３１．２５ｕｓになる。

・サンプリングレートを８ｋｓｐｓに合わせるとＤＣ更新周期は１２５ｕｓになり、上記のＰＷＭ周期をソフトで１／４にプリスケールすればよい。

・８ビットＰＣＭ値からＤＣ値への変換で乗算が必要になるが、ＣＨ３２Ｖは乗算命令を持っているのでＣＰＵ負荷を上げずに可能である。

⑥ピン割り当て

・出力タイプを変更してもＰＷＭの出力ピンが変わらないようにする。その結果、正相はＰＣ３、逆相はＰＣ６の組み合わせしか無かった。

・アナログ入力ピンはアプリの個別の応用のためにできるだけ残しておく。

・ＳＷＩＯ機能はＩＳＰのために残しておき、デバグ信号の出力ピンに割り当てる。


【実装】

①実装の結果はダウンロードファイルのソースコードを参照。

・現時点では曲目は「ＡＩＡＩ」の１曲のみ。

・出力タイプはＢＴＬ＝０、１、２、３。

・音声データはＩ２Ｃメモリ、ＳＰＩメモリ、ＳＤカード。

・機械ＳＷを１個（最大４個）、ＣｄＳ入力を１個、ノイズセンスを１個（最大４個）実装。

②非稼働時の消費電流実測値は、機械ＳＷのみの場合は１２ｕＡ、ＣｄＳ・ノイズセンスを実装する場合は３０ｕＡだった。

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

プロジェクトディレクトリは　SW_F4P6
プロジェクトは　SW_F4P6.wvproj
根のソースコードは　SW_F4P6\User\main.c

④デモ演奏

２８円のマイコンから出てくる音がこれ

ＣＨ３２Ｖ００３Ｆ４Ｐ６はコストパフォーマンスが素晴らしい。今すぐＡｌｉＥｘｐｒｅｓｓで注文。


【今後の作業】

①ｓｏｎｇデータ、ｏｎｐｕデータ、波形データをＰＩＣ電子オルゴールＶｅｒ７＿５から移行する。

・今まで各種のマイコンへ移植を行ってきたが、ｏｎｐｕデータの書き方はそれぞれのやり方で、都度移行処理を行ってきた。その経緯から、プリプロセッサで書く方法がポータビリティが良いように思う。

・それで、ＰＩＣ電子オルゴールで、ｏｎｐｕデータをプリプロセッサ式にできるかどうかの評価を行ってから、ＣＨ３２Ｖへの移行を考えることとする。

【前振り】
Ｒ８Ｃ電子オルゴールでのｓｏｎｇインデックスの書き方に問題点を感じていて、改善を行った。


【従前の書き方】

・ｏｎｐｕデータは、その中で流れの分岐（リピート演奏）が必要だが、Ｃ言語でのデータの初期値設定では飛び先のオフセットを式で表せない。オフセット計算を言語処理でやってくれないと実用性が無い。そのため、ｏｎｐｕデータはオフセット計算ができるインラインアセンブラで記述するしかない。

　上記の最下行のｊｐ１＿ｍａｃが分岐のコードで、パラメータで分岐先のオフセットを指定している。

・ｓｏｎｇデータはパート数が不定であり可変長となるため、Ｃ言語の構造体では初期値設定ができず、インラインアセンブラで記述せざるを得ない。

上記はパート数が２のときのｓｏｎｇデータで、パート個別部が２つある。３パートの曲の場合はパート個別部が３つになる。

・ｓｏｎｇインデックスは、その中にソングデータへのポインタを含むため、インラインアセンブラで記述するのが効率的だ。

・ｓｏｎｇデータへのポインタ配列をインラインアセンブラで記述し、それを実体とするＣ言語の関数「ｓｏｎｇ＿ｉｄｘ（）」を作った。


　１曲毎に＃ｄｅｆｉｎｅを挿入しているが、これは後で纏めてｓｏｎｇファイルとｏｎｐｕファイルの実体を＃ｉｎｃｌｕｄｅするための記述だ。

　ｓｏｎ＿ｍａｃの定義は下記の通りで、ｓｏｎｇデータへのポインタを設定している。


・Ｃ言語からは、ｓｏｎｇ＿ｉｄｘ（）をｓｏｎｇインデックスの構造体である「ｓｔｒｕｃｔ　ＳＯＮＧ＿ＩＤＸ」のポインタへキャストしてアクセスする。


・問題はｓｏｎｇ＿ｉｄｘ（）の中にインラインアセンブラで記述したデータが「ｓｔｒｕｃｔ　ＳＯＮＧ＿ＩＤＸ」の定義通りに整然と隙間なく配置されることが保証されるのかどうかと言うことだ。コンパイラによって、関数の先頭部分に予期せぬコードが埋め込まれるようなことは無いのだろうか。


【改善のＡ案】

・その後、コンパイラのマニュアルに「アセンブリとのリンク方法」が説明されているのを見た。アセンブラのラベルをｅｘｔｅｒｎ宣言すればＣ言語から参照できる。


・上記の例に従って、ｓｏｎｇ＿ｉｄｘの書き方を改善しようとしたが、問題点があった。ｅｘｔｅｒｎ宣言は前方参照が許されないため、参照する位置よりも上にｅｘｔｅｒｎ宣言を書かないといけない。電子オルゴールでは、ｓｏｎｇインデックスの記述で収容曲と順番が決まる仕組みになっているので、ｓｏｎｇインデックスが書かれた後でないと必要なｅｘｔｅｒｎ宣言が決まらない。これが矛盾してしまう。

・ｅｘｔｅｒｎ宣言は余分にあっても、極端に言えば実在しないラベルが書かれていてもコンパイルエラーにはならず、メモリリソースも消費しない。そこで、全曲分のｅｘｔｅｒｎを記述したｓｏｎｇ．ｔｘｔファイルを作って、ｓｏｎｇインデックスの上で＃ｉｎｃｌｕｄｅするようにした。

・ｓｏｎｇ．ｔｘｔの内容は下記の通り。


・その下にｓｏｎｇインデックスを書く。


・ｓｏｎｇデータのラベルの先頭には’＿’を付けておく。



【改善のＢ案】

・改善のＡ案では、新曲をサポートする都度、ｓｏｎｇ．ｔｘｔファイルにも追加することが必要になる。これまでも、ｓｏｎｇ．ｈファイルとｓｏｎｇ．ｃファイルを作り直す必要があったので五十歩百歩なのだが、できれば手入れは少なくできた方が良い。

・もう一つの事情があって、そもそもｓｏｎｇインデックスをＣ言語で書きたいのは実装曲数をｓｉｚｅｏｆ（）で表しかったからだ。先般、ランダム演奏・再生をサポートしたときに曲番号・音声番号を乱数で加算するようにした。加算後の曲番号・音声番号が実装数に収まるようにしなければならないが、その計算を早くするために乱数を予め実装数に応じたビット数でマスクしておくことを考えていた。このマスクパターンは実装数を＃ｉｆで切り分けて、＃ｄｅｆｉｎｅで静的に定義しようとしていたが、Ｃ言語仕様ではｓｉｚｅｏｆ（）は＃ｉｆの中で使えないことが判った。そのため、マスクパターンは実装数から動的な計算により定めるしかなく、期待した改善は見込めなくなった。

　下記コードの＃ｉｆはコンパイルエラーになる。


・それで、ｓｏｎｇインデックスの実体はインラインアセンブラで書くのだが、それをＣ言語の関数で包むのではなく、ｓｏｎｇインデックスの先頭をｅｘｔｅｒｎ宣言でＣ言語からリンクする書き方にした。曲毎にｅｘｔｅｒｎを宣言する必要は無い。

　上記コードの最後の行が、C言語からｓｏｎｇインデックスをアクセスする入り口になる。

・具体的には下記のコードでアクセスする。


・「改善」とは言え、初めからそうして置けばよかっただけのことだが。。。


【ダウンロード】

Ｒ８Ｃd遠視オルゴールの設計資料と開発プロジェクト一式は　ここから　ダウンロードできる。

ワークスペースは　orgel.hws
プロジェクトは　orgel_SW_M11
根のソースコードは　orgel_SW_M11.c

【前振り】

電子オルゴールや音声再生などでの音声出力では、非稼働時の消費電流を抑えるため、非稼働時はＬレベルを出力している。稼働時のレベル（平均）は出力タイプによって異なり、例えばＢＴＬ＝０（シングル出力）の場合はＶｄｄ／２になる。そのため、非稼働から稼働に移るとき、また、稼働から非稼働に移るときにポップノイズが発生する。そのポップノイズを抑えるやり方について整理した。

【出力タイプについて】

①音声出力の出力タイプは、機能改善により変わってきているが、現在は次のようになっている。

・ＢＴＬ＝０（シングル出力）
　Ｔｒ１石のバッファアンプでスピーカを駆動する。
　スピーカには直流成分が流れる。
　電力効率は悪い。

・ＢＴＬ＝１（コンプリ出力）
　正相出力と、そのコンプリ波形を出力する。音声レベルが０のときでも、５０％デューティのＰＷＭでスピーカが駆動される。電力効率はやや悪い。
　ハイサイドにバッファを置く場合にはコンプリ出力を使うと都合が良い。

・ＢＴＬ＝２（ブリッジ出力）
　正相と逆相のブリッジ回路を駆動する信号を出力する。
　音声レベルが０のときは、スピーカは駆動されず、電力効率が良い。
　高インピーダンススピーカや圧電スピーカをＰＩＣのポートで直接鳴らす場合には外付けアンプが要らず都合が良い。
　ベアなＨブリッジを繋ぐと音質が悪い。

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

②それぞれの出力タイプ毎にポップノイズ対策を行っている。

【当初のポップノイズ対策】



①ＢＴＬ＝０（シングル出力）

・非稼働時はＬレベル（ＤＣ＝０％）を出力している。稼働時の音声レベルが０ではＶｄｄ／２（ＤＣ＝５０％）となる。

・音声出力の開始時にＬレベルからＶｄｄ／２へ急激にレベルが変わることによってポップノイズが出る。

・そこで、ＤＣを０％から５０％まで徐々に変化させる、つまりランプ出力をさせることでレベルの変化が音として聴こえないようにするのがポップノイズ対策の考え方だ。

・音声出力の終了時はＤＣ＝５０％から０％まで、徐々に変化させる。

②ＢＴＬ＝１（コンプリ出力）

・非稼働時は正転と逆転ともＬレベルを出力している。稼働時は音声レベルが０では正転はＶｄｄ／２（ＤＣ＝５０％）、逆転は正転の相補波形となる。

・そこで、ＢＴＬ＝０と同様に、ＤＣを０％から５０％まで徐々に変化させる。

・音声出力の終了時はＤＣ＝５０％から０％まで、徐々に変化させる。

③ＢＴＬ＝２（ブリッジ出力）

・非稼働時は正転と逆転ともＬレベルを出力している。稼働時は音声レベルが０では非稼働時と同じに正転と逆転ともＬレベルを出力する。

・つまり、ポップノイズ対策は不要である。

④ＢＴＬ＝３（ブレーキ出力）

・非稼働時は正転と逆転ともＬレベルを出力している。稼働時は音声レベルが０では正転と逆転ともＨレベルを出力する。

・そこで、ＢＴＬ＝０と同様に、ＤＣを０％から１００％まで徐々に変化させる。

・音声出力の終了時はＤＣ＝１００％から０％まで、徐々に変化させる。

【現在のポップノイズ対策】



①実は、ＢＴＬ＝１とＢＴＬ＝３ではポップノイズ対策は不要だ。

・非稼働時と稼働時でレベルが大きく変化するのだが、正転と逆転が同じ変化となるので信号間には相対的な変化が現れない。

・つまり、非稼働から稼働に、また、稼働から非稼働に移るときに正転と逆転のレベルを階段状に変えてもポップノイズは発生しない。

②ＢＴＬ＝２では非稼働時と稼働時のレベルがともに０であるので、元々ポップノイズ対策は不要だ。

③纏めると、ＢＴＬ＝０（シングル出力）の場合だけポップノイズ対策が必要であり、そのやり方は従前どおりランプ出力によって行う。

④ＰＩＣやＲ８Ｃなどデバイスの種類に関わらず、音声を出力するプロジェクトでは全般的にこのやり方を採っている。

⑤現在はこのやり方で開発しているが、古いプロジェクトでは「無用なランプ出力」が残っているものがあるかも知れない。

【前振り】

ＰＩＣ電子オルゴール　や　Ｒ８Ｃ音声再生　でランダム演奏・再生をサポートしたので、Ｒ８Ｃ電子オルゴールでもランダム演奏・再生をサポートした。


【設計と実装】

①ランダマイズの種は、Ｒ８Ｃ音声再生と同じやり方で、ダミーのＡＤＣを実行した結果を使う。

②電源オンで自動開始する場合とＳＷ等の操作で開始する場合の両方でランダマイズが可能とした。

③ランダマイズの要否は下記の宣言で指定する。

#define KYOKU_RAND //曲番号をﾗﾝﾀﾞﾏｲｽﾞするときに宣言する
#define ONSEIN_RAND //音声N番号をﾗﾝﾀﾞﾏｲｽﾞするときに宣言する
#define ONSEII_RAND //音声I番号をﾗﾝﾀﾞﾏｲｽﾞするときに宣言する
#define ONSEIC_RAND //音声C番号をﾗﾝﾀﾞﾏｲｽﾞするときに宣言する
#define ONSEIS_RAND //音声S番号をﾗﾝﾀﾞﾏｲｽﾞするときに宣言する


【ダウンロード】

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

ワークスペースは　orgel.hws
プロジェクトは　orgel_SW_M11
根のソースコードは　orgel_SW_M11.c


【使い方のコツ】
①ランダマイズの種を取得するためのダミーのＡＤＣはポートを内部プルアップ・開放状態で実行している。適切なＡＤＣを得るためにはポートに若干の容量負荷があるとよい。また、抵抗負荷は避ける必要がある。

②ＳＷなどを繋いでいる場合はその配線が容量負荷となる。真に開放状態である場合には１０ｐＦ程度のコンデンサを付けるとよい。

【前振り】
以前に、モータードライバＩＣのＴＣ１１８ＳとＭＸ０８でスピーカを駆動する　ことの可否を評価した。

今回は、Ｌ９１１０Ｓを評価した。

【Ｌ９１１０Ｓについて】

・Ｌ９１１０の名前を冠したデバイスが各社から提供されていて、どれがオリジナルなのかも判らない。

・各社のデータシートを見ると、真理値表が、入力が共にLの状態で出力が共にＬになったり、入力が共にHの状態で出力がともにＨｉｇｈＺになったり、（僕の）常識から外れた仕様になっているものがある。







・この記事では　「入力が共にＬとなる動作形態をブリッジ出力」　「共にＨとなる動作形態をブレーキ出力」　と区別している。Ｌ９１１０Ｓでは「ブレーキ出力」の入力状況でも出力の実態はブレーキにはならない。


【評価内容】
・出力ピンを1００Ωの抵抗でＧＮＤへ落とした回路で信号遅延を測定する。

・ブリッジ出力とブレーキ出力について測定する。

・貫通電流の発生の有無も確認する。

【評価結果】

①信号観測結果

・ブリッジ出力オン遅延

信号遅延は殆どない。

・ブリッジ出力オフ遅延

信号遅延が４ｕｓもある。

・ブレーキ出力オン遅延

信号遅延は殆どない。

・ブレーキ出力オフ遅延

信号遅延が４ｕｓもある。

②電源電流の観測結果

・ローサイドに電流センス用の抵抗として５０Ωを挿入して、その両端の電圧を観測した。

・ブリッジ出力

貫通電流は発生していない。

・ブレーキ出力

貫通電流は発生していない。

③評価

・ブリッジ出力とブレーキ出力でオフ遅延が同じ程度になっていて、ドライバ段でオフ遅延が発生していると思われる。

・Ｔｒ（ＳＳ８０５０等）エミッタ接地のバッファ回路での遅延は２ｕｓ以下である。

（参考）ＳＳ８０５０での遅延


Ｌ９１１０Ｓのオフ遅延の４ｕｓはＳＳ８０５０よりも悪い。ＰＷＭ周期（ＰＩＣ電子オルゴールでは３２ｕｓ）に対して無視できるレベルではなく、音質に影響すると思われる。

・貫通電流は発生しないので、マイコン側でデッドバンドを設けなくても安全に使用できる。

・Ｌ９１１０Ｓはスピーカ駆動に使えなくはないが、ＭＸ０８の方を推奨する。

【前振り】

電子オルゴールや音声再生で、ランダムに演奏・再生する機能を要望されることがある。先日は　「Ｒ８Ｃで音声再生」　でランダマイズ機能を実装した。

今回は「ＰＩＣ電子オルゴール」に実装した。

ＳＷの場合はオンされている時間、タッチセンスや音声ＳＷの場合はＡＤＣ結果、などが都度変化するのでそれらをランダマイズの種として利用できるのだが、自動演奏・再生の場合には操作が無いので、そのような場合にランダム演奏・再生を実装する方法を検討した。


【設計】

①ランダムになり得るデータ

・「Ｒ８Ｃで音声再生」ではＡＤＣ結果が揺らぐことを利用して、ランダマイズの種とした。

・「ＰＩＣ電子オルゴール」のＳＷモデルでは、操作入力に使うポートはＳＷ・ＣｄＳ・ＣＶＤがそれぞれ１本ずつ割り当てられている。ＳＷにはＲＡ３が充てられていて、これはＡＤＣが使えない。ＣｄＳポートは外部に回路が繋がっているのでＡＤＣ結果の揺らぎは期待できない。ＣＶＤポートはＳＰＩのＳＳと共用していて、このポートをランダマイズの種として利用するには２線ＳＰＩにするしかない。

・ポートの割り当てを替えるとテストボードの変更が必要になるので避けたい。

・そこで、３１ｋＨｚ内部オシレータを使うことにする。ポート割り当てへの影響が無くなる。

②３１ｋＨｚ内部オシレータをＴＭＲ１の入力クロックにして、ＴＭＲ１のカウント値をランダマイズの種とする。


【実装】

①ＰＩＣ電子オルゴールＶｅｒ７＿５のＳＷモデルのプロジェクトに「ランダム再生」の機能を実装した。


【ダウンロード】

ｏｒｇｅｌ７＿５の設計資料と開発プロジェクト一式は　ここから　ダウンロードできる。

長年に渡りＰＩＣ電子オルゴールを開発してきているが、その取り組みでの所感を表しておきたい。

①ＰＩＣ電子オルゴールの開発経緯

・鳴り物おもちゃの修理にＰＩＣ電子オルゴールを初めて適用したのは２００６年だった。当時は廉価なＰＩＣ（１６Ｆ６４８）にはＰＷＭが内臓されていなかったので、ビープ音をそれぞれのポートに出力する２パート演奏だった。（ｏｒｇｅｌ）

・２０１２年にＰＩＣエンハンスドコアが廉価に出回り始めたので、ＰＷＭ出力に替えて音質が改善された。（ｏｒｇｅｌ２）

・２０１５年には音源とエンベロープを波形ファイルで設定できるように改善し、演奏表現が強化された。（ｏｒｇｅｌ５）

・その後、音源波形やエンベロープ波形の動的変更、転調機能などをサポートしてきている。（ｏｒｇｅｌ７＿５）

②演奏パート数

・ＰＩＣ電子オルゴールの最大パート数は、設計上は４パートであるが、音声再生とコンカレント実行するとアンダーランが発生し、実質的に３パート演奏が上限になっている。

・おもちゃ修理への適用実績から必要なパート数は標準で２パート、多くしても３パートで十分と感じている。

・ネット上には無闇にパート数を多くしている電子オルゴールが発表されているが、サンプル音を聴くと雑音が重なり合っているようにしか聴こえない。

・パート数を増やすよりも、豊かな音色の音源と多彩な演奏表現が電子オルゴールには重要だと思う。

③ＰＩＣ電子オルゴールのサンプル音

・糸魚川のＤｒ．渡辺氏が作った「ＲＡＩＬＷＡＹ」を演奏したものだが、これは２パート演奏ながら素晴らしい演奏表現をしている。
RAILWAY
電子オルゴールはマイコンという器ではなく、それに入れるコンテンツが重要だということだ。この作品は鳴り物おもちゃの代替部品としてではなく、芸術作品としてのオルゴールと言ってよい。

・Ｄｒ．渡辺氏のその他の演奏曲は　ここから　聴くことができる。

Ｒ８Ｃ電子オルゴール　はＰＩＣ電子オルゴールからのデータ移行が完了して、一応完成と言うことにしたのだが、その出来栄えはＰＩＣ電子オルゴールと比較してどうだったのか、僕の評価を記しておきたい。下記でＰＩＣはＰＩＣ１６エンハンスドコア、Ｒ８ＣはＭ１１を指す。


①実行速度

・ＰＩＣはＣＰＵクロックが３２ＭＨｚで、１命令は４サイクルで実行される。一方、Ｒ８ＣはＣＰＵクロックが２０ＭＨｚで、１命令は３～５サイクルで実行される。つまり、命令実行速度はＲ８Ｃが遅い。

・ＰＩＣはメモリとＷレジスタ間の演算に限られるが、Ｒ８Ｃではレジスタ・メモリ・リテラル間での演算が可能であり、処理の内容で評価するとＲ８Ｃの方が処理が速いと考えられる。

・ＰＩＣはインデックスレジスタが無いので配列処理やポインタ変数の処理では一々ＦＳＲへの設定を伴うことになり、メモリが嵩張り処理時間も増大する。Ｒ８Ｃでは各パートの処理を配列やポインタ変数を使うことでスマートに記述でき、処理も軽い。これは電子オルゴールにとって優位である。

・乗算命令があり、波形演算が速く実行できる。

・Ｒ８ＣはＳＦＲを含むメモリ全体がリニアな（バンク分けされていない）ので、ＳＦＲアクセスの効率が良い。

・総じてＲ８Ｃの方が処理速度は速いと評価できる。４パート演奏ではアンダーランが発生したが、Ｃ言語で書けることの方がメリットだと思う。

②メモリ

・ＰＩＣでは１ワード（１４ビット）に２つの波形データを詰め込んでいるので、１データは７ビットになってしまう。Ｒ８Ｃでは１データを８ビットで収容するので量子化ノイズが半分のレベルになっている。

・プログラムメモリが３２ｋバイトで１６Ｆ１７０５の倍以上あるので、曲と音声を多く収容できる。これだけでもＲ８Ｃを採用する価値がある。

③ＰＷＭ機能

・Ｒ８Ｃにはデューティサイクルのバッファレジスタが１組しかなくステアリング制御機能もなく、相補波形出力機能もないので、コンプリ出力・ブリッジ出力・ブレーキ出力ではフルデューティの出力ができない。

・デューティサイクルの更新がＰＷＭ周期の終了時ではなく、一致ＢのタイミングであることがＰＷＭによる音声出力では致命的な欠点で、デバイスの設計ミスだと思う。

・ＰＷＭクロック周波数・ＰＷＭステップ数・サンプリング周期の組み合わせがスンナリ行かない。結果としてサンプリング周期が長めの設定になってしまう。

④ＳＰＩ・Ｉ２Ｃ通信機能

・Ｒ８ＣにはＳＰＩ・Ｉ２Ｃ通信機能がないので、ソフト実装することになる。内臓モジュールがあったとしても２線ＳＰＩ、３線ＳＰＩでは内臓モジュールは使えないので、あまりハンデにはならないと思う。

⑤ピン割り当て

・機能モジュールで使えるピンが固定されていて代替ピンが少なく、ピン割り当ての自由度が極めて低い。ＰＩＣのＰＰＳに慣れているとＲ８Ｃは使い辛いと感じる。

・ＭＯＤＥピンはＩ／Ｏピンとして使えないので、同じピン数のＰＩＣと比べて１ピン損した気持ちになる。

・ＲＥＳＥＴピンは出力モードで使えるので、その点はＲ８Ｃに優位性がある。

⑥コスト

・流通価格は変動するので固定的な評価はし辛いが、現時点で＠５０円（２０２３年秋月）はＰＩＣを圧倒している。秋月の在庫状況は未だ「ＡＡＡ」の表示になっていて、当面は入手可能と思われる。

⑦音質

・実際に演奏音を聴いた感じではＲ８ＣとＰＩＣでは音質の差は感じられない。

「ＲＡＩＬＷＡＹ（Ｄｒ．渡辺氏）」のＲ８Ｃ／Ｍ１１での演奏
RAILWAY_R8C.mp3
この音が＠５０円のＲ８Ｃから出ていることに驚かれるだろう。

【前振り】

先日は、Ｒ８Ｃ電子オルゴールで　「複数ｓｏｎｇの連続演奏」の機能をサポート　した。それが必要となったのは、ｏｎｐｕデータの規模が大きくなるとｂｕｉｌｄで「input buffer overflow, can't enlarge buffer because scanner uses reject」のエラーが発生するので、１個のｏｎｐｕファイルを小さくするため複数個のｏｎｐｕファイルに分割して、それらを自動的に連続演奏するためだった。


【その後の検討】

①ｏｎｐｕファイルを分割していても、それらをすべて＃ｉｎｃｌｕｄｅしてコンパイルする訳で、その方法でエラーが回避できるのが不可思議だった。

・もしかして、＃ｐｒａｇｍａ　ａｓｍ　～　＃ｐｒａｇｍａ　ｅｎｄａｓｍ　の間の行数がトラブルの要因なのだろうか。

・そうであれば、ｏｎｐｕファイルの途中で＃ｐｒａｇｍａ　ｅｎｄａｓｍ／＃ｐｒａｇｍａ　ａｓｍを挿入して、連続するインラインアセンブラの行数を少なくすればよいのではないだろうか。

②それを実際にやってみたら、的中した。インラインアセンブラを分断するところは以下のとおり。



・インラインアセンブラの５００行程度毎に入れるとよさそうだ。

・結果はメデタシメデタシだが、マニュアルにはインラインアセンブラの制約についての記載が見当たらず、この対策の真偽は確認できない。

③連続演奏の仕掛けは作ってしまったので、機能の削除はしないでおく。今後のおもちゃ修理で使い道はあると思う。

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

ワークスペースは　orgel.hws
プロジェクトは　orgel_SW_M11
根のソースコードは　orgel_SW_M11.c

【前振り】

Ｒ８Ｃ電子オルゴールは　ＰＩＣ電子オルゴールから全曲の移行が完了した　のだが、「ＲＡＩＬＷＡＹ」の曲がｂｕｉｌｄできないことが判った。

その対応のため、「複数ｓｏｎｇの連続演奏」の機能をサポートした。


【不具合の発生状況】

①ｓｏｎｇインデックスに「ＲＡＩＬＷＡＹ（作　Ｄｒ．渡辺氏）」を含めてｂｕｉｌｄすると、訳の判らないエラーが表示されて異常終了する。


「input buffer overflow, can't enlarge buffer because scanner uses reject」

②このエラーメッセージをＨＥＷのＣコンパイラユーザーマニュアルで探したが、見付からなかった。エラー番号が表示されていないので、文法エラーのような想定されたエラーではないようだ。

③ネット検索するとＨＥＷのＣコンパイラに限らず、いろんなプログラムで表示されるもののようだ。勿論、プログラムによって指し示す意味は違うのだろうが、何らかの処理をするのにバッファが足りないことを主張している。

④Ｃコンパイラの動作環境の設定で回避できないかマニュアルを見たが、コンパイラの起動オプションには関連しそうなものが無かった。

⑤「付録C　翻訳限界」に「ソースファイルでの行数は最大６５５３５行」との記載があるのだが、それには至っていない。


【対応】

①「ＲＡＩＬＷＡＹ」の特徴は他のｓｏｎｇと比較してｏｎｐｕデータが極めて長いことだ。それでバッファが足りなくなったと思われる。しかし、Ｄｒ．渡辺氏はよくこんな大作を作ったもんだ。

②試しにｏｎｐｕデータを半分にしてみたらｂｕｉｌｄできた。しかし、残りの半分はエラーとなってしまった。

③試行錯誤して、ｏｎｐｕデータを３分割にしたところ、３つともｂｕｉｌｄできた。

④３分割したｓｏｎｇを同時にｓｏｎｇインデックスに含めてもｂｕｉｌｄできた。

・３分割したとは言え結局は全部を＃ｉｎｃｌｕｄｅするのでコンパイラが扱うソースコードの長さは同じになるが、それで、エラーが回避できるのが不可思議だ。コンパイラの気持ちが推し量れない。


【機能改善】

①従来の機能でも、演奏終了のコールバック関数で次のｓｏｎｇを演奏開始させれば複数のｓｏｎｇを連続再生することができる。しかし、コールバック関数側で連続演奏の要否と曲番号の指定が必要になるので、アプリが組み難い。

②連続演奏させるｓｏｎｇの組みは決まっていて、その情報をｓｏｎｇデータに含めておくことでエンジン側で自動的に連続演奏させるようにした。

・ｓｏｎｇデータに次のｓｏｎｇへのリンクを張っておく。連続演奏しないフツウの曲ではリンク情報にＮＵＬＬを設定しておく。

・ｓｏｎｇの演奏終了時に次のｓｏｎｇへのリンク情報があれば、ＳＯＮＧ＿ＳＥＬ（）と同等の演奏制御データの設定を行う。これで次のｓｏｎｇが演奏開始される。

・但し、分割したｏｎｐｕデータに跨る分岐は行えない。

・もしかして、＃ｐｒａｇｍａ　ａｓｍ　～　＃ｐｒａｇｍａ　ｅｎｄａｓｍ　の間の行数がトラブルの要因なのだろうか。

③既存ｓｏｎｇファイルの移行をやり直した。分割した「ＲＡＩＬＷＡＹ」のｓｏｎｇファイルには次のｓｏｎｇへのリンク情報を設定した。

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

ワークスペースは　orgel.hws
プロジェクトは　orgel_SW_M11
根のソースコードは　orgel_SW_M11.c

但し、下記後日談にあるとおり対応方法を替えたので、ダウンロードファイルには今回の対応の結果は残っていない。


【後日談】

その後、ｂｕｉｌｄエラーの回避策を再考した結果、ｏｎｐｕファイルを分割せずとも　＃ｐｒａｇｍａ　ａｓｍ／＃ｐｒａｇｍａ　ｅｎｄａｓｍ　で区切ればよい　ことが判った。