« 2013年12月 | トップページ | 2014年2月 »

2014年1月の3件の記事

2014年1月28日 (火)

AquesTalkマルチメーター読み上げ機の実装に向けて

 AquesTalkを使ったマルチメーター(P-10)の読み上げ装置は、ブレッドボード上でほぼ想定どおりの動きをしてくれるようになった。次のステップはこれを適当なケースに入れ、実用品として動かすことだが、その前にやっておきたいことがある。省電力化である。

 電源は今のところ乾電池を考えている。プレーヤーなどのように連続して長時間使うものではないので、消費電流をそう心配することはない。そうは言っても電池は長く持つ方が良いのに決まっている。

 参考にさせてもらったサイトの音声テスターは、クロックを1Mhzまで下げて消費電流を減らしておられるようだ。まあそこまでやることもないだろう。それでも少しは省電力化しておきたい。クロックを下げたり、スリープを入れることを考えてみることにする。

消費電流は意外に少なくならない(1/18/2014)
 まず、とりあえずは現在のブレッドボード上の装置の電流を測る。テスターではなく、オシロに、このあいだのRaspberryPi電源装置開発で味をしめたシャント抵抗を使って電流を測定する。Vccは今5Vなので数十mAあたりを測定するなら10オームで数百mVになりオシロで十分測定可能な範囲だ。

S_p1186348 ミニブレッドボードに10オームを用意して、早速、電流を測る。おやあ、思ったより消費電流が多い。発声時には50mAを軽く超す。あ、そうか、スピーカーを駆動するトランジスターの電流を忘れていた。

 トランジスターの回路を分けて再度テスト。ふーむ、まだ多い。AquesTalkは同じMega328なので、2つのMPUの消費電流はデータシートによれば合わせて14~15mAぐらいのはずなのに、30mA近く流れている。もしかしてISPアダプターがついたままになっている? そうかこれだ。

 ISPアダプターをはずすと、ほぼ想定どおりまで下がった。静止時で14mA、発声時には平均で20mA流れている。さて、省電力化の手順はここからである。

S_p1186347  まず、クロックを8Mhzから、手持ちで一番低いクリスタル4Mhzに換装する。ボーレートや、タイマーの定数を少し変更するだけで正常に動作した。電流を測る。おやあ、あんまり減らないなあ。AquesTalkはCRクロックで恐らく8Mhzで動いているので片側だけでは、2mA下げるのが精一杯だ。全体で消費電流は12mAとなった。

 次に、スリープ機能を入れた。スリープといってもメインループには1msのタイマー割り込みが常に起こっているので余り効果はないと思われるがどうだろう。うーん、やっぱり、たいしたことはない。12mAから9mAまで下がっただけである。それでも率から言えば30%近い削減効果なのだが今ひとつの効果だ。

 こうなるともっとやらないと気がすまなくなった。AquesTalkには本体をスリープにさせるピンが用意されている。データシートによればこれによりマイクロアンペアレベルまで下がると謳っている。これを試してみることにする。

 ブレッドボードなので、ハードの変更はあっと言う間である。ジャンパーでピンをつなぎプルアップ抵抗を追加する。喋ったあとAquesTalkはスリープに入り、喋る前にスリープを解除するロジックを追加する。

 理屈から言えば、現在の9mAから半分に下がるはずである。期待をこめてスタートする。これが意外や意外、殆ど消費電流節減には寄与しないのである。相変わらず消費電流は9mA前後を示すだけである。

 オシロで調べると、スリープピンが動いていることを波形で確認できるのだが、待機時でも電流値は殆ど変わらない。色々考えるが思い当たるところが見つからない。そのうち段々飽きてきた。

 何か原因があるのだろうが、この程度の電流で目くじらたてても余り得るものがない。もともと長時間使う道具でもない。努力の割には報われることが少ないことに意地になるのはもうそろそろ止めよう。省電力化はこの程度にして先に進むことにする。

切り忘れで電池を2度も換える失敗を避けるために脱線(1/20/201)
 ところが、またも脱線である。次に進もうとした矢先、思わぬ事故に遭遇してしまった。マルチメーター(P-10)が電源を入れても動かない。何と言うことだ、電池がすっかりなくなっている。

 P-10の電池は、LR44というボタン電池2つである(常用のP-16と同じ)。P-10のRS232Cを生かす改装をしたとき、RS232CをONにするとAutoPowerOffが効かなくなっていることには気がついていた。

 実験を終わる時は、あらゆる電源断をチェックする癖をつけてはいるのだが、前夜うっかりP-10の電源を切り忘れたようだ。このあいだ入れ替えたばかりの電池がすっかり空になっている。実はこれは2回目の失敗である。

 LR44は、最近は秋月で10個¥100で買えるようになったので経済的にはそう痛手ではないが、何の役にも立てずに消耗していった電池が不憫(ふびん)で申し訳がたたない。気分がすっかり落ち込む。

 現在のP-10は常時RS232CをONにしてあるので、電源の切り忘れは今後も起き得る。このONにしているピンにスイッチを入れれば解除されるが、このスイッチそのものの切り忘れを考えれば解決になっていない。電源スイッチを切ればすむ話である。

 何とかならないか。読み上げ機を動かしているときだけRS232CがONになり、終わるとOFFになってAutoPowerOffが有効になるようなしかけはできないか。USBを通してPCでログをとる時も同じようになって欲しい。あれこれ考えているうち閃いた

 USBのときも、読み上げ機につなぐときも、RS232Cのフォトカプラーの出力用に受け側のVccを使っている。そうだ、これだ。これでRS232CをONするピン(ENTX)を逆にドライブすれば良いのではないか。フォトカプラーをもうひとつ追加して、このVccを入力にし出力をこのピンにすればよい。出力側のVccはP-10からもらえる。良いぞ。

S_p1236352 思いついてからの行動は我ながら早い。早速、P-10につけたフォトカプラー基板をとりはずし、フォトカプラーを2つのせる基板を作り直す。さらにP-10を久しぶりに分解し、RS232Cの送信ピンとグランド(Vss)の2本のピンヘッダーをはずして、Vcc(Vdd)とRS232CをONするピン(ENTX)を追加した4線のピンヘッダーに取り替える。

ダブルフォトカプラーで自動的にAutoPowerOffに戻す(1/22/2014)
細かい作業になるので、新規参入の実体顕微鏡が大活躍である。但し顕微鏡を覗くためにはメガネをはずさなければならない。しかし最近は乱視が進んできてメガネをはずしたままだと、ものが二重に見えて全く仕事にならない。このためにメガネスタンドを買って、メガネの着脱が素早くできるようにしたのだが、とても面倒である。何か対策を考えたいところだ。

S_p1256367 それはともかく、大した配線量ではない。半日ですべて完成した。早速テストする。念のため、元のUSBアダプターにつけて確かめる。おやあ、データは出ているが、正しい値ではない。PCコンソールを16進表示のソフト(アクノリッチ)に換えて見る。うわあ、これは以前、UART-TTLからRS232Cに換えようとして失敗したデータそっくりだ。規則的なもっともらしいデータだが、全くのデタラメである。

 どうしたものか、何か変えたところがあるか。そういえば、P-10のRS232C出力を改装したとき、出力の片側がVdd(プラス側)になっていたので、グランドに戻した(極性は合わせた)ことを思い出した。念のためデータシートを見てみる。

S_p1256361 あっあっあ、データシートもVddにつながっているではないか。そうか、フォトカプラーのLEDをドライブするためにVddをつないでいるのだ。プルアップを省略しているのだろう。わかったぞ。あわててアダプターの配線をやり直した。まずは、USBにつないでPCのソフトで確認する。

 はい、めでたく測定データは正しくRS232Cラインを通して出力された。AquesTalkにつなぐ。当然のように、ここでも正常に読み上げる。読み上げ機の電源を切る。よーし、P-10の表示画面からRS232Cの表示が消えた。P-10のAutoPowerOffは30分がタイムアウトなのでテストはしなかったが大丈夫だろう。これで電池の無駄な損失は避けられる。

S_p1256357

実装仕様をあれこれ考えている(1/23/2014)
 ケースの実装を本格的に始める。ケースは、定番のこれ(秋月のポリカーボネート117、95X65X23 )が良いだろう。リニアPCMプレーヤーの一号機に使ったケースだ。価格もたったの¥100でしかも丈夫だ。ChaNさんは、これと殆ど同じ大きさのアクリルのSK-5を愛用されているようだ。こいつは¥80ともっと安いがアクリルなので傷がつきやすいということである。

S_p1256359 このケースは、秋月のCタイプ基板がぴったり入る、電池ホルダーを入れるために、その部分だけ切り取る。電池は単3ふたつの3Vで良いだろう。ブレッドボードでも3Vで動くことを確認してある。このケースには単3のホルダーがこれも測ったようにきれいに横置き出来る。

 LEDをどうするかが問題だ。当初、LEDの点滅をうまく使って、AquesTalkの動きを表現することを考えた。

点滅......... 初期化中か、音声出力中
点灯......... レディ
激しく点滅.... エラーまたはハングアップ

ここまで考えたのだが、省電力化を考えているときに気がついた。LEDの消費電流も馬鹿にならない(数mA)。それに初期化は一瞬で終わるし、電源が入ったことは最初の音声メッセージでわかる。このLEDで役に立つのは、スピーカーの断線のときくらいである。あまり意味がなくなってきた。

 どうするかは後から考えるとして、レイアウトを先に進める。スピーカーはケース上面の裏につけ、ケースに穴を開ければ音に影響ないだろう。外にはスイッチと、UARTケーブルが出るだけのシンプルな構造だ。

 スピーカーが安物なので、もう少しましなスピーカーを用意することにする。ただし、ケースの高さがないので、本格的なダイナミックスピーカーは無理だ。それより、こういう薄いスピーカーをどうやって固定するかが問題である。

スピーカーを2つ買ってくる(1/24/2014)
 ウェブ情報を参考にして、久しぶりに秋葉原にでかけ、マルツパーツ本店でミニスピーカーを2つ買ってきた。ひとつはブランド品(東京コーン)、もうひとつはノーブランドで値段が5倍も違う(ブランドは¥619、ノーブラは¥126)。

S_p1256365  帰って、スピーカーにリード線をつけて早速聞き比べをする。うーん、確かにブランド品の方が、大きい音(高効率)でめりはりのある声になるが、所詮、5センチ以下のスピーカーだ、値段の差ほどの違いはない。秋月のキットの付属スピーカーは一応ブランド名がついているが、音はノーブランド並みであった。

 こんな小さいスピーカーでも、ちゃんとしたボックスに入れてやれば音が良くなるのだろうか。それにしても、スピーカーのつけかたが悩ましい。3つとも取り付け部がないのだ。どうやって固定するのか。ウェブでみていても参考になる情報は見つからなかった。重いものではないので、ケースの突起などに引っ掛けるなり接着するなりしているのだろうが、どうも良くわからない。

 スピーカーをケースにどうやって簡便に取り付けるかで、また脱線モードに入ってしまった。どうということもないことなのだが、結構、夢中になる。メモ用紙に何枚も略図を描いては、スマートな固定法がないか頭をひねる。こんなことで実装は先に進まない。

S_p1276371 思いついたスピーカーの固定方法を実装(1/26/2014)
 何枚かスケッチを描いているうちに、決め手となりそうな良さそうな方法を思いついた。パーツは2枚の細い板だけである。このあいだの焦電センサーの基板止めがヒントになった。写真を見てもらえば一目瞭然だが、板の片側にスピーカーの外縁に沿って弧を切り取り、スピーカーが当たる垂直面を斜めに削るところがミソである。

 この板を両側からはさんでスピーカーを固定する。着脱はパネル(ケース面)の剛性を利用して、スピーカーをはめてしまえば、斜めに削ってあるので、はずれない理屈だ。ただし剛性が不足して、入らなかったりパネルを割ってしまうリスクはある。

S_p1276372 まあ、考えていても解決にはならない。実際に確かめてみるまでだ。これまでの工作で残ったアクリル板の端切れを取り出し適当な素材を探す。ライブカメラなどのフレームにした厚さ3ミリのアクリル板が良さそうだ。

 コッピングソーをとりだして、スピーカーの外縁の曲線を切り出す。このあいだは楽に切れたのだが、今度は少し難儀した。素材が違う(紙ベークとアクリル)のと、厚さが違う(1.5ミリと3ミリ)ためだろうと思うが、少し強く切ろうとすると熱で固着が始まる。

S_p1276373 だましだまし切り出し、やすりで切断面に角度をつける。形が少しづつ出来ていくこういう工作は楽しい。不揃いながら2つの固定辺ができた。ためしにはめてみる。うむ、大丈夫だ。しかしパネルの剛性が意外に強く、単なる接着だけでうまくできるか不安は残る。

 コッピングソーの刃を実体顕微鏡で念のため見てみて固着の原因がわかった。刃がもう半分近くなまっていたのだ。これは替え刃を買ってこなくてはいけない。それにしても、コッピングソーの刃は使っているところはごく一部だけなのでもったいない感じである。

 部品は揃った。完成させるにはまだ時間がかかりそうだ。前の記事から2週間がたつので、そろそろこのあたりでブログに報告することにする。省電力化したバージョンのソースコードと回路図も公開しておこう。ただ、LEDをどうするかはまだ決めていない。今のところはLEDなしの版である。

Aquestalk_reader128

 以下にいつものようにAVRStudioのフォルダーを固めたzipファイルを置きます。前のバージョンとファイル名などは変わっていませんのでご注意下さい。

「aques168_1_28_2014.zip」をダウンロード

| | コメント (0) | トラックバック (0)

2014年1月15日 (水)

AquesTalkのマルチメーター(P-10)読み上げ装置が動いた

 久しぶりのソフト開発である。単体でのAquesTalkの発声(ステップ0)と、マルチメーターP-10の測定データ出力の確認(ステップ1)は済んでいる。前回の記事ではステップ2として、P-10の測定データをマイコンでASCII数値にデコードするところまで進んだ。これでPCコンソールにはP-10と同じ測定値表示が出るようになった。

 次はいよいよマイコンによるAquesTalkの初期化と発声シーケンスの制御である。これまでPCのコンソールに使っていたUART(ハードUART 19200bps)をAquesTalk側に回し、P-10のUART(ソフトUART 2400bps)をPCコンソール側に再度接続する。

 このステップ(ステップ3)の目的は、PCコンソールから入れた文字データをAquesTalkに送り、AquesTalkが喋るのを確認することである。ローマ字の発声だけでなく、数字の入力だけでAquesTalkが数字を読み上げるようにする。

 これが出来れば、前のステップで作ったP-10データのデコード(ステップ2)をつないでやればP-10の読み上げソフトは完成となる(ステップ4)。このように、いくつものステップに分けて開発しているのには理由がある。

 複数の通信がからむプログラムは、デバッグのしにくいソフトの代表格である。通信はいわゆるAll or Nothingの世界で、どこかのほんの少しの狂いだけで全体が全く動かない。動き出すまで一苦労するのが常である。

 慎重にステップを踏む方が結局早道であることを、電子工作をやる以前から身にしみて経験している。それでわざわざこんな回りくどい手順をとっているのだ。

ロジックアナライザーさまさま(1/9/2014)
 さらに、UARTなど通信系のソフトはメッセージが出たといっても、それだけで動きを把握するのは難しい。遅いと言っても1秒に何百字が行き来するのである。人間の感覚で判断していると、思い違いをすることが多い。今までに何度も苦い目にあっている(バッファーが一瞬で空になるのを見落とすとか)。

 しかし、こういうときに威力を発揮するのが、オッシロスコープや、ロジックアナライザーなどの測定器である。特に、ロジックアナライザーは強力で、今回も次々に問題を解決してくれていった。プローブ点の設定など、準備に少し手間がかかるが、動き出せば無敵である。

 最初のトラブルである。PCコンソールからの文字入力で無事AquesTalkは喋り始めた。それは良いのだがメッセージ発声の終了マークである'>'を待つ処理が上手く動いていないようだ。どうも、発声がはじまった途端に、'>'が帰ってくる。

 コンソールからの発声なら大した問題ではないが、P-10から立て続けに送られてくるデータを発声させるときに、ここが正常に動かないのはまずい。AquesTalkが誤動作する。しかし、原因が中々つきとめられなかった。

 ロジアナをつなぎ、双方のUART波形を画面にだし、チェックする。愛用しているロジアナ(秋月でもおなじみのLAP-Cシリーズ)には、UARTのデータをデコードしてくれるプロトコルアナライザーがついているので、データの中味を簡単に調べることができる。

Aques_badcr これを見ると原因がすぐわかった。送出データの最後を示す¥r(キャリッジリターン)がデータ列の中に2つもはいっていたのだ。

 つまり、PCコンソールからの文字入力データの末尾は必ず¥rで終わっているのに気づかず、¥rを追加していたのである。その結果、2番目の¥rの応答プロンプト(これは一瞬で返る)を最初のメッセージの応答と間違えて処理を終えていた。本来の'>'は1秒近くあと(発声が終わったあと)に出ている(AquesTalkは複数の発声申し込みが受け付けるのか、ある種の不具合)。

 次のトラブルは、もっと念が入っていた。1回目はちゃんとタイムアウトや、応答を待っているのだが、2番目以降は発声中に応答が戻ってしまう。せっかく直したところなのにまた同じようなことが起きている。ソースコードを検証するが特におかしなことはない。

 AquesTalkのピンにはbusyのデジタル出力(/PLAY)が出ているので、いざとなればこれを監視していれば確実に発声終了を把握できるのだが、少し意地になっている。この程度で引き下がるわけには行かない。

 これもロジアナの画面を見ているうちに原因が判明した。現在のルーチンの応答待ちタイムアウトは2秒で、発声はそれ以上かかることが多い。すると、タイムアウト後に送られてきた¥rは、読まれずに残ってしまう。受信バッファーに残ったデータが次の発声のときに読まれエラーとなる。

Aquesgood1 原因がわかれば解決はたやすい。発声メッセージを出す前に、念のため必ず受信バッファーをクリアしておけば良い。この問題もロジアナのおかげ一発で解決した。いやあ、ロジアナさまさまである。

 数字の入力で、AquesTalkが数字を読み上げるコマンド(<NUM VAL=XXX>)を新設し、テストする。よーし、順調だ。キーボードから、数字を入れては読み上げさせ、悦に入る。次はいよいよP-10からの出力である。

データの取りこぼしが多い(1/11/2014)
 すんなりAquesTalkの数字読み上げが出来たので、勢いづいて最後のステップ、P-10からのデータの読み上げに進む(ステップ4)。これが出来れば、ブレッドボードでの実験は一段落で、次の実装のステップに入れる。電池仕様を考えているので省電力化を考えねばならない。

 ソフト開発をさらに進める。コンソール入出力に使っていたソフトUARTの部分をP-10につなぎ換え、コマンド応答の部分を削除して、前に作ったP-10データ変換の部分を復活させる。動作確認をLEDにしようと思っていたが、P-10の方のUARTの出力側は使っていないことに気づいた。

Ws000000  そうだ、これをデバッグ用に使えば、動きを完全に把握できる。LEDより遥かに沢山の情報を出せる。AquesTalkに送るデータと同じところに、P-10側の出力を使って前と同じようなメッセージが出るようにする。これはうまくいきそうだ。

 半日でソフトが完成した。意気揚々とコンパイルする。ありゃ、コンパイルエラーがなかなかとれない。ルーチンが複雑になってきて、プログラムの最後の制御ループの整合性がおかしい。どうも}の数が合わない。頭を冷やして最初から見直してやっと原因をつきとめた。

 一番最初のfor(;;)ループの次の{がUARTを切り替えるときにコメントと一緒に消えていた。「デバッグは外へ外へ」の格言どおりである。一生懸命、プログラムの最後の}の数を調べていてもわからないはずである。

 コンパイルエラーがとれた。ほとんどのコードは動作済みなので、一発で動く公算は高い。わくわくしながら電源をONする。よし、初期化が終了したメッセージが出た。P-10の電源を入れる。おおお、読み上げ始めた。良いぞ。しかし読み上げる数値が出鱈目だ。

 ときどき合う時もある。暫く様子を見る。同時に出るPCコンソールのUARTのデータがそもそもおかしい。デコードの部分が悪いのでなく、読み込んだデータが間違っている。気を落ち着けて原因究明を考え始める。

データは出たが古いデータの読み上げばかり(1/12/2014)
 すぐに思い当たったのが、UART読み込みである。AquesTalkの読み上げは平均で2秒近くかかっている。それに対してP-10が出すデータの頻度は、1秒に3回近い。ああ、これはバッファーのオーバーランに違いない。

 現在のルーチンは、バッファーからデータを取り出すときに、P-10のデータフォーマットの特性を生かして(上位4ビットがデータシーケンス番号)、決められた配列にデータを移し、最初のデータを読んだ時、必ずこのデータ配列をクリアして正確な1ブロックのデータを得るようにしている。

 しかし、その前の生データが汚れてしまっていては何にもならない。このデータフォーマットは2バイトでひとつの数字をデコードする構造になっているので、厳密にデータが揃っていないと出鱈目になる。

 ソースを確かめる。なんだ、ここのバッファーサイズは16バイトしかない。これではパンクするはずだ。80バイトに広げて再度テストする。殆どエラーはなくなった。しかし、今度はバッファーが大きすぎて、最新のデータの発声が遅れる。

 AquesTalkが発声している時は、割り込みルーチンが動いてせっせとデータを貯めこみ、制御が戻ってきた時にバッファーの古いデータから読み始めるからだ。まあ、厳密な機械ではないので少々遅れても問題はないのだが、大分前の表示が声になって出てくるのは気分が良くない。

 割り込みルーチンに最新のデータを渡すような仕掛けにしないとまずい。しかし、受信割り込みのところで余り時間をとられると、AquesTalkにデータを送るときのUARTに差しさわりがでる可能性がでてくる。このあたりが難しい。

思い切ってデータを捨てる(1/13/2014)
 AquesTalkが喋っている間は、マルチメーターP-10のデータ送信は止めておきたい。しかしP-10のUART送信を制御することは出来ない。しかもP-10側のUARTはソフトUARTなので簡単にUARTをdisableには出来ない。

UARTは非同期通信なので最初のスタートビットの把握が命である。ここからボーレートに応じた時間を8ビットとってデータを取り込む。受信割り込みは常にスタートビットで起きないといけない。下手に途中で止めたり、スタートさせると目茶目茶なデータになる。

 最新のデータだけをワンセット(14バイトが1ブロック)残しておくという手順はそう簡単には思いつかなかった。寝床に入ってからも、あれこれ考えていた。こういうことは下手をすると不眠の原因になるが、久しぶりのソフト開発が面白くてつい寝ながら考えてしまう。

 現役の頃なら、明日のことを考えて余計眠れなくなるところだが、気楽な年金生活者にとっては、そんな心配も無用である。逆にかえって早く寝付けてしまう。面白いものだ。現在の境遇の有難さをかみしめる。

 こういう問題解決のノウハウも、デバッグと同じで「外へ、外へ」である。問題そのものを突き詰めるのでなく、その環境の前提をもういちど基本から考え直す。そういうことから言えば、データが直前の情報でないと絶対まずいわけではない....そうか、何も難しく考える必要はなかった。

 UARTのバッファーにデータを貯めるのを止めようと思っていたが、何もとめる必要はない。喋った直後にデータをとりなおせば良い。1秒に3回はデータが来る。喋った後、一旦バッファーをクリアし、新たに最新のデータを読んでそれをP-10のデータにすればよい。そうか、これは素晴らしい解決だ。

 早速、ソフトを修正する。仕掛けはとても簡単で、受信データをフラッシュ(クリア)する関数(データポインターを等しくするだけ)を追加し、これをAquesTalkの発声終了を待って発行するだけである。

 試してみる。見事に最新のデータをAquesTalkが喋るようになった。嬉しくて動画(音付き)を撮る。ちょっと音が悪いが読み上げている様子が何とかわかると思う(冒頭に表示)。

回路図とソースコードの公開(1/14/2014)
 本体はまだブレッドボードにあるだけだが、開発が一段落したので、このあたりで回路図とソースコードをウェブに公開することにする。実装版には、AquesTalkの動作状態を示すLEDなどを付けたいのだが、AquesTalkをすぐにでも動かしたいという方のためにとりあえずご紹介することにした。

Aquestalk_reader ソースコードには多量のデバッグ用のUART出力メッセージを出すコードが残っている。これは入れておいても実害はない(ハングしない)ので、残すことにした。またPCコンソール入力からP-10のデータに変換する部分(ステップ3)も参考になるかと思い、あえてコメントとして残した。

マイコンは、Mega328Pを使っているが、現在のフラッシュサイズは4KB以下なので、Mega88程度で十分である(もっとも価格は殆ど変わらないが)。スピーカーは、秋月の録音再生キットに付属していた小さなダイナミックスピーカーで、このあたりはもう少し考えたいところだ。

 使い方は簡単で、電源を入れると、「準備が出来ました」というメッセージが出る。P-10の測定レンジを所定のところへ回せば、勝手に読み上げてくれる。読み上げる数値は、AquesTalkが喋り終わった直後のメーターの表示である。電源を入れた当初は、どのデータが読み上げられるかは不定である。

 現在は、同じ数値のときも発声する。長期間データをログするときは止めた方が良いかもしれない。省電力化のためにクロックを下げ、スリープを使うことも必要か。

 例によって、AVRStudioのフォルダーの形でソース一式をzipで固めたものを以下に置きます。回路図のce3ファイルも中に入っています。

「aques168.zip」をダウンロード

| | コメント (4) | トラックバック (0)

2014年1月 6日 (月)

AquesTalkでマルチメーター読み上げ装置を作る

みなさま新年おめでとうございます。

  このブログも発足以来6年目となりました。昨年のアクセス件数はおかげさまで18万件と前年と同程度でしたが、記事の新規掲載数は下がる一方で、昨年はひところの半分以下の22本、特に先月の12月は遂に一本だけで、一ヶ月も間が空いてしまいました。

 当研究所のドジ話を楽しみにいらっしゃる方には申し訳ないことですが、なにしろ工作にかける時間が激減しましたので書くことがありません。前にも書きましたように電子工作への熱意がさめたわけではありません。むしろ何か創りたいという気持ちは前と変わりがないのですが、作る種(たね)がつきてきたというのが正直なところです。

  とはいえ、暮れには念願の実体顕微鏡を入手するなど意欲だけはまだ十分に旺(さかん)なので、細々でも電子工作は続けていくつもりです。これからも暖かく見守っていただけるようお願い申し上げます。以下は昨年からの工作記録です。

実用にこだわってマルチメーター数値読み上げシステムをつくることにする
 ご存知のように当研究所は「実用品」を作ることにこだわっている。工作への熱意が下がったというより、作れるものをあらかた作ってしまって作るものがなくなったというのが近いだろう。もう少し正確に言うと、「現在の自分の技術レベル」で作れるタネがつきたのだ。

 実用品を作ってきたので、身のまわりには自作品が溢れている。髭剃り用のLEDペンライトから、階段照明の人感センサー、プリンター電源の遠隔制御アダプター、PC用のデジタルアンプ、グラフィック気圧計などは常時電源が入っており、時計のぜんまい巻上げ機も毎日動いている。

 周りの棚やケースにはFPGAを使ったフォトフレーム、温度ロガー、ガイガーカウンター、Xbee電力ロガー、Xbeeラジコンカー、2台のリニアPCMプレーヤーなど自作品が満載である。

 FPGAの基板(DE0)や32ビットCPU(mbedなど)は数多い積み基板のひとつで、このあたりはフォトフレーム以降、タネが見つからない。タッチパネルで液晶を動かすAndroidなどのスマホ系は、既製品のレベルに到達するのはとてもじゃないが無理なのでそう簡単には手が出せない。Xbeeなどの無線系もこれといったアプリがない。

 オーディオ方面も、24bit 192kbpsのスーパーオーディオの世界には飛び込みにくい。これを導入するとなると、今常用している古いオーディオシステムの聡取替えにつながる。というより、今の音以上の忠実度を欲しいとは思わない(クラシックの場合、音の心地良さと忠実度は比例しない)。

51uzz1agal_sl500_aa300_ この間、書店でFPGAでギガビットイーサネットのインターフェースをつくるというFPGAマガジンを見つけ、勢い込んで買ってはみた。しかし、「で、何が出来るの?」と聞かれたとき胸を張って答えられるアプリケーションはこのなかから見つからなかった。

 RaspberryPiのライブカメラも猫への防御を考えている間に、すっかり熱がさめてしまった。やっぱり作ることが楽しいので、応用となると途端に意欲が薄れる。困ったものだ。

音声合成チップAquesTalkを試す(12/8/2013)
 そうこうするうち、ウェブを見るともなく見ていて音声合成チップ、AquesTalkを実験しているサイト(すみませんURLが行方不明になりました)を見つけた。ここの回路は、トランジスタひとつでスピーカーを鳴らしている(単にオープンコレクターの負荷にスピーカーを接続しただけ)。他にも色々な実験サイトがある(ここやここ)。

 これまでスピーカーを鳴らすのには別のアンプが要ると思っていたが、これなら小さなブレッドボードだけで実験できる。この音声合成チップ(AquesTalk pico ATP3011F4-PU) は1年以上前に面白がって買ってあったが、まだ動かしたことはない。

 どんな声かはウェブで聞いているが、実際に鳴らしたことはない。ちょっと聞いてみたくなった。合成音声は何かと応用範囲が広い。当研究所の「実用性」ということでは研究対象として申し分がない。

S_p1066341 マイコンも何も要らない、UART入出力をPCへつなぐだけである。簡単に結線が終了した。動かしてみる。しかし、最初は動かなかった。配線間違いなどしたくてもできない簡単な回路だ。定石どおり、各部の電圧をチェックしていく。所定どおり出ている。

 おやあ、電源を切ってもVccが2V以上を指しているではないか。USB-UARTアダプター(Aitendo製)を切ると、Vccは0Vに戻る。プルアップされたUARTピンから電流が流れチップのパワーオンリセットがうまく動いていない可能性が高い。

 UARTをCOM1で受ける別のRS232Cインターフェースに切り替える。0Vに戻った。PCコンソールから?を送ると、>が返ってきた。よしチップが正常に動いた。試しに>aioeoといれると、ちゃんと「あいうえお」と女性の声が出た。いやあ感激である。ウェブで音声を聞いていたけれど、実際に自分のブレッドボードのチップから声が出てくると、とても不思議な気分である。

 '(コーテーション)などで適当に音節を切ると、さらにもっともらしい音声になる。実用性は十分だ。このチップのすごいところは数字をそれらしく読み上げてくれるところで、しかも2種類(百千などの位取りをする読み方と、一桁づつ棒読みする方法)で発声する。どちらも試してみる。

  2つとも非常に明快に数値を読み上げた。見事なものである。これは完全な実用レベルだ。すぐにでも何かに応用したくなった。そこで思いついたのがマルチメーターの計測値を読み上げる装置である。

マルチメーターのデータ読み上げ装置を調べる(12/10/2013)
 マルチメーターの測定で、プローブを基板に当てたあと値を読み取るために視線を表示装置に移さなければならない。その隙にプローブが測定点をはずれてしまったり、下手をするとプローブが別のパッドに当たって機器を壊すような悲劇も起きる。

 このとき、音声で数値を読み上げてくれれば、視線を換えずに対象物に確実にプローブを当てていることが出来る。極めて実用的な応用だ。これは単にマルチメーターからの測定値をUARTなどで引き出し、それを音声合成装置に入れてやれば良いだけだ。

 こちらは以前、秋月で¥1000の激安マルチメーターP-10を改造し、USB-UARTでデータを引き出している。改めてUART付きのマルチメーターを用意する必要はない。しかし、簡単なしかけなので、もう色々な人が作っているだろう。今さら作って面白がられるのか。

 しかし、調べてみるとウェブには意外に応用例が少ない。みんなAquesTalkで声が出たことで満足し、実際のメーター値の読み上げまで作った人がいないのだ。音声テスターとして完成させているのは調べた限り、ここのサイトだけだ。

 ふーむ、Arduinoで作っているのか、いや、省電力のためにクロックを下げて、スクラッチからの開発だ(Arduinoは固定クロック)。ソースコードまで公開されている。なんだ、ここまで出来ているのなら、今さら、こちらで作っても2番煎じになるだけかなと、ちょっとやる気をそがれた。

 いやまて、このサイトのAquesTalkはI2Cだが、こちらの石はUARTだ。しかも対象のマルチメーターの機種が違う(MAS345とP-10)。ソースコードを公開する意味はありそうだ。はじめは思い付きレベルだったが、制作熱が次第に高まってきた。

 久しぶりのまともなソフトの開発に心がはやる。おおまかな仕様の検討を始めた。しかけは、マイコンでUARTを通してマルチメーターから送られてくる数値データを受け取り、それをAquesTalkの発声データに変換して、別のUARTを通してAquesTalkに送り込むだけである。

 ソフトとして難しいところは、2つのUARTをデータ落ちしないように(誤りは許されない)正しく動かすことだけで、制御上の問題はほとんどない。連続的に変換してやれば良い。マルチメーター(P-10)のUARTは2400bpsと遅く、AquesTalkのほうは38400bpsくらいまでサポートしているので、フロー制御も考えないでよいだろう。

 CPUはUARTが2つとれる石が良いが、先のブログと同じ、AVRのMega168で十分だろう、UARTはひとつしかないが2つめはソフトUARTで実現できる。Mega88でも全く問題なさそうだが、手持ちのMega328を選ぶ。

擬似コーディングの前に仕様を固める(12/12/2013)
 そろそろ忘年会のシーズンが始まって忙しくなった。先月長女が家を出て家族が減り、一人だけ工作室にこもるのが少し気が引けるようになった。家族となるべく一緒にいるようにしたら、結果として工作に専念できる時間が減った。こういうことも電子工作に時間をかけられなくなった理由かもしれない。

 それはともかく、読み上げシステムの仕様を詰めていく。こうした作業は居間のTVを見ながらでも出来る。読み上げは、数値だけでよいか。同一データの時の繰り返し発声はないほうが良いのか。オームやボルトなどの単位の読み上げは必須だが、AC、DCといった付属データの読み上げをどうするか。エラーのときはどうするかなど、開発の前に決めておくことは多い。メモ用紙に何枚も気のついたことを書き留める。

 対象のマルチメーターはとりあえずP-10で決まりだ。こいつは、USB-UARTでデータが出力できるように改装したが、出力データのデコードは既存のPCのフリーソフトDMMViewer(沢山のマルチメーターをサポート、P-10はWens20-Tと完全互換)に頼っているので、この部分は一から作り直す必要がある。

 P-10のデータフォーマットを本格的に調べ始める。スペックによると、データは定期的に固定長の14バイトのレコードをUARTに送り出す。この中にP-10のLCD表示面のデータがすべて入っているので、ここから必要なデータだけを選んでAquesTalkのフォーマットに変換する。

 例えば、読み上げる数値は、< NUMK VAL=NNN.NNN > という書式のASCIIデータを送れば、「N百N十NてんNNN」と発声してくれる。単位は、megu'o-muとかmiri'anpeaなどのローマ字表示だ。

 発声のトリガーは、音声データが送出されたあとAquesTalkから戻ってくるUARTのプロンプト'>'である。マルチメーター側のマイコンUARTは、同一バッファーに常に数値データを送り込み、一つのデータが完結するまでフラグを立て、途中のデータが持っていかれないようにする。

P-10からは別のUARTラインを取り出す(12/14/2013)
 手持ちのP-10のUART出力は、マルチメーターのケーブル収容スペースに設置したUART-USBアダプターを通してPCに行く(記事参照)。フォトカプラーで絶縁され、電源はUSBの5Vである。これまでに何度か使いロガーとして重宝している。

 最初は、このUART-USBアダプターを生かして、STM32とか、FM3などでUSBホストを実装してシリアルをつなぐ野望を抱いていた(単なるUART2つでは面白くない)。USBがつなげればソケットを通して読み上げシステムにつなぐことができる。とてもスマートだ。

 しかし、少し調べてみたが、マイコンでUSBホストを実装するのはとんでもなく難しいことがわかった。STM32も手持ちのF103ではだめで、F105以上が必要だ。F107基板は、グラフィック気圧計に使ってしまったのでmbedあたりの出馬が必要だが、ちょっと大げさすぎる。

 なひたふさんが、RX61でオープンソースの手作りUSBホストライブラリを提供しておられるのを見つけたが、こちらはRX61基板は持っているものの開発環境がない。簡単には手が出しにくい。それにこれができてもRX61をこれだけに使うのも勿体ない。

 あれこれ迷ったが、今回はUSBホストは諦め、通常のUART-TTL(元々はこれが出力)を途中から引き出すことにした。まあ、本筋でないところであまり力を懸けて何のプロジェクトかわからなくなることは避けよう。

 P-10のUSB-UARTアダプターとフォトカプラー基板の間のハンダ付け接続をとりはずし、ピンソケットを増設する。通常のmilピッチなので実体顕微鏡を持ち出すこともないが、嬉しくて顕微鏡を通して作業する。

 最初はハンダごてをレンズにあてないか冷や冷やするが、徐々に慣れてきた。ハンダ吸い取り線でハンダを除去する作業がとても楽である。吸い取り線を正確にとりたい部分にあてられるので、熱をかけすぎて部品を痛めることがない。P-10のハードの準備はあっというまに完了した。

擬似コーディングに入る。デコードが結構大変だ(12/18/2013)
  いよいよ実装に入る。今回のソフトの制御ループは単純だが、各段階のテストをどうするかが悩ましい。例の逐次開発法で行くには、少なくとも4段階のテストステップが必要で、最後は手探り(動きを確認する手段がない)になる。

 まず、AquesTalkのUART入力で音声がでることの確認(ステップ0でこれは済んでいる)、次は、P-10からのUART出力がマイコン側で受け取れているかの確認(Aques側のUARTをPCコンソールにつける。ステップ1)。

 次に、P-10のデータをデコードして、Aques側に渡せるだけのデータに揃え、これをPCコンソールに出力する(ステップ2)。さらに、Aques側のUARTを動かして、Aquesが音声を出せるかどうかの確認(今度は、P-10側をPCにつなぐ。ステップ3)を終えて、始めて、最終工程、P-10からの出力をAques側に送る(ステップ4)。

 最後のステップ4では、動いていることの確認は、Aquesの音声以外では出来ないのがちょっと不安だ。まあ、これは最後の方なので、とりあえずはP-10のデータのデコードロジックの開発に専念する。

 参考情報は、すんさんが紹介してくれたWens-20Tのサイトや、P10のコントローラーFS9721のデータシートである。データフォーマットは、上位4ビットがデータのシーケンス番号になって下位4ビットがデータという変則的な仕様である。

 これが結構手ごわい。数値の表現がややこしいのだ。1桁の数値が2バイトにわかれ、しかも出来上がったデータを別のテーブルで翻訳している。しかし良く調べてみると、これは7セグLEDの数字のエレメントを単にデータビットに出しているだけであることに気づいて理解は急速に進んだ。

 これに気づく前は、参考にしたサイトに、いくつか誤りがあったこともあって(マイナスや小数点表示のビット値"0"は誤りで"1"、4のときのAb、ghの値、2Eは誤りで27、表示のKとMがないなど)、頭をかかえていた。

忘年会ラッシュと年賀状印刷の合間を縫って作業する(12/26/2013)
 今年は忘年会は少なめだ。それでも人間ドックをはさんで3連荘で少々ばて気味である。このところ電子工作は掛け声だけで先に進まない。擬似コーディングは済んでいるのだが、実際のコーディングになかなか手がつかない。

S_p1066346 そのうち年賀状を作る時期になって工作には手が回らなくなる。こういうときに限ってレーザープリンターのトナー交換の時期が来る。購入後7年を経過し2回目の交換である。3色全部をとりかえねばならないので経費は3万円以上かかるし、時間もとられる。

 それでも年賀状作成の間を縫って作業を進めた。ブレッドボードにAquesTalkと、Mega328を並べる。Mega328のUARTをどう割り当てるかで迷う。P-10側のUARTはマイコン側から送信する必要がないので、バッファー出力のないソフトUARTを使い、Aques側には送信割り込みの入った本格的なハードUARTを使うことにする。

 XbeeのAPIモニターに使ったソースコードを丸々流用する。ここのソフトUARTはChaNさんのASMプログラムを使わず全部をCで書き直したやつだ。最初のステップ、P-10 のデータ受信で少しはまる。

 ボーレートの計算がおかしい。文字の字化けが直らない。クリスタルを4Mhzから8Mhzに上げたのでループカウントを倍にしたのだが、どうもこれが間違っているようだ。最初オッシロで立ち上がりの時間が所定の時間でないことを確認した。

Aquesuart そのあと、プローブステートメントをコードの中に入れてコンパイルし直し、今度はロジアナを入れて正確な時間を測り直す。4MHzのときは、受信割り込みのあと14μsで割り込みルーチンに来るのだが、8MHzでは、半分の7μsではなく、8.7μsになっていた。

 待ち時間を単純なCPUループで作っているが、どうもループカウントの換算数とクロックが比例していない。原因を究明するよりも対症療法で解決する(先を急ぐ)。ロジアナで出たパルスの時間を2400bpsの長さになるようループカウントを補正する。

 コンパイルし直して、様子を見る。よーし、完全にデータが出たようだ。14バイトのP-10の測定データの16進表示だ。上位4ビットば番号、下位4ビットが数値というデータ列がUART画面を埋めていく。これで一歩前進した。次はこのデータのデコードだ。

やっとUARTにP-10の測定数値が出た(1/4/2014)
 家族が増えて暮や正月は忙しかった。所長を除いてこれまでは女ばかり(猫一匹がオス)の家族だったが、婿殿が2人増えてようやく男女同数になった。

 正月は酒を飲む機会が多い。飲んでしまえば、まず電子工作のような細かい作業は全くやる気がなくなる。来客のある2日間は全く手がつかなかった。3日から再開する。

 16進表示のデータが出たのであとは力仕事である。UART上で完全なマルチメーターの数値データが表示されるようにする。ここまで来ればAquesTalkの発声データにするのはあと一息である。データシートの資料を元に単位(VやA)の表示のコードを加える。

 参考にさせてもらって文句を言うのも気が引けるが、Wens-20Tの資料は、どうもわかりにくい。難しく考えすぎだ。それに抜けがある。単に表示面のセグメントが各データのビットに対応しているのだから、そのまま書けば良いところを、組み合わせて表示しているので、かえってわかりにくくなっている。

Aquescosole 奮闘数時間で、UARTにP-10の表示のままの数値と単位が順調に表示されるようになった。やれやれ一段落だ。これでステップ2が終了した。数値と単位以外にも表示面には、色々な情報(DC、AC、HOLD、AUTOなど)が出ているが、これは音声で出す必要はないだろう。音声は短い方が良い。

 このあたりでブログに報告することにしよう。残っているステップは、AquesTalkの制御(初期化、プロンプト待ち)と、実際の音声出力の確認である。

| | コメント (7) | トラックバック (0)

« 2013年12月 | トップページ | 2014年2月 »