909クローン製作」カテゴリーアーカイブ

AVR の EEPROM データが壊れるのを防ぐには

909クローンのファームウェアの開発中、eeprom に書き込んだリズムパタンが書き込んだ後に崩れる現象がまあまあ頻繁に発生して、最初はファームウェアのバグのせいかと思っていたのですが、バグにしてはどうにも発生場所がランダムだったり発生の契機が読めなかったりで、これはプロセッサの誤動作なのでは?と考え始め、発生条件をもっとよく調べてみたら、どうも電源を落として立ち上げると何の書き込みをしていなくてもちょいちょい壊れるらしい。そういうわけで何の問題でどう対策すれば良いのか調べました。

続きを読む

怪しい通販サイトからトランジスタを買おうとしたらやっぱり怪しかった話

製作に使う部品にはあまりこだわらない方で普通は手に入るもので済ますので、部品の調達先はだいたい決まっているのですが、909クローンでは、どこを代替品にしてよいかというところまで部品表に指定してあって、そういったことを楽しむために頑張ってできるだけオリジナル部品を調達しました。そのためトランジスタは廃番を中心に集めることになり、トランジスタはほとんどが初めての販売者さんからの調達になりました。こういう時は eBay を利用するのが、詐欺防止の仕組みが充実していて安心なのですが、一点だけ eBay を通さず直接注文を出しました。ところ見事に問題が起きたので顛末を簡単に記録しておきます。

続きを読む

AVR の EEPROM 非同期書き込み関数

TR-909 クローンのシーケンスパタンは eeprom に書き込みますが、avr-libc ライブラリが提供している eeprom 関数には同期書き込みしかありません。

https://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html

しかし、TR-909 クローンのファームウェアでは割り込みをほとんど使わずリアルタイム処理がなされていて、eeprom を同期書き込みすると書き込み中処理が止まってしまいます。これが様々な誤動作の原因になってしまうので、非同期書き込み関数を書きました。

続きを読む

シーケンサの基本構造とリズムパタンの打ち込み

909 の製作はハードウェア部分はほぼ終わり、ファームウェア書きが中心になってきました。ソースコードは GitHub に上げていて文章で書くことがだんだんなくなってきて、ブログ記事の間が広がってまいりました。その中で、シーケンサの基本構造とそこへリズムパタンを打ち込む部分はソースコードを読むだけではわかりにくい、自分でも忘れてしまうかもしれないので大枠を記事にしておきます。

続きを読む

バスドラム・スネアドラム・ハイハットのチューン機能実装

入力

バスドラム・スネアドラム・ハイハットの三つのチューン入力は、ボリューム基板から CV としてマイクロプロセッサへ ADC 入力として入っています。チューン制御をするには、まず ADC を使って CV を読み取る必要があります。

出力

バスドラム・スネアドラムのチューンは CV としてマイクロプロセッサの PWM 出力から回路に入っています。オリジナル回路でも同じなのですが、制御電圧の範囲について注意が必要です。ハイハットのチューンはオリジナルになかった機能ですが、PCM のクロック周波数を変えることで制御します。

続きを読む

バスドラム・部品の差し替え・スネアドラム

TR-909 クローン、製作が進みだんだんコツをつかんできてあまりつっかえるところがなくなってきました。できれば一月中にハードウェアの組み立てを終わってしまいたいのでブログに記録を残すのを端折って製作作業を急いでいました。スネアドラムまで組み終わったので忘れないうちにやったことをざっと記録しておきます。

続きを読む

トランジスタの選別

ファームウェア側の二つの気がかりだった PCM とノイズジェネレータのめどが立ったので、アナログ回路の組み立てをどんどん進めようと思います。組み進める前に、アナログ回路側の気がかり、トランジスタの選別に手を付けました。組み立て後半ではトランジスタの残り数が少なくなって選別の余地がなくなるので早い段階でやっておく必要があります。

TR-909 クローンでは、二種類の選別が必要です。一つは、バスドラムとスネアドラムの VCA 回路に適したトランジスタの選別、もう一つは、ペアトランジスタのマッチングです。

バスドラムとスネアドラムの VCA 回路の可変増幅器を担うトランジスタは、下の図の Q12 のように、トランジスタ一個だけで構成されています。はじめ回路図を見たときに、こんな簡単な回路で CV が漏れたりしないのかな?ドラムだからいいのか?などとぼーっと眺めていたんですが

いざ作る段となると、しょうこりもなく analog さんの回路図をちょっと載せちゃいますけど

トランジスタの選別が必要と回路図に書き込んでありました。どうしてなのか思い出せず。でも analog さんなにか言ってました。このトランジスタの増幅度が低いと音漏れを起こすんじゃなかったかしら?あるいは、増幅度が高くないとどうしても欲しい音が出ないと言っていたのかな?どちらだったかどうも思い出せません。

こういうアドバイスにしっかり従って忠実に作りたいというのが今回の製作ですから、少し時間はかかりますが選別してゆこうと思います。hFE が高いものを選ぶ必要があるのは、一番多く使われている 2SC2603 です。もともとは三菱のトランジスタのようです。hFE の測定は、特に難しいことを考えずにテスタの hFE メータを使いました。hFE が高めのランクが指定だっただけあって、低いものでも 400 以上、高いものは 530 を超えていました。ばらつきがかなり大きいのが意外でした。530 超えが三個見つかり、必要な高増幅度トランジスタも 3 個なのでそれを取り分けて、念のため 500 を超えたものも別袋に入れて選別完了です。

もう一つの選別は、ペアトランジスタのマッチング、実はこれは部品リストに指定があったのをすっかり忘れていました

Q84 と Q184 てどこでしょう?

ハイハットの、これまた VCA 回路です。てかこれ、アンチログ回路ですね。オリジナルではペアトランジスタです。それでマッチング指定なんですね。なんと。ここもう組んでしまいました。とりあえず音に問題はないような気はしますが、やっぱり analog さんの指示には従いたいところです。ということで、PNP トランジスタ 2SA1115 のマッチングをとることにします。ペアの精度の問題になりそうな箇所が実はもう一つあって、ハンドクラップの VCA (OTA) に入れる制御電流を発生する回路、これもアンチログなようです。この回路を見たところで、analog さんが「マッチングする場所は二か所あって、どっちもやらなくても大丈夫かもしれないけど念のためですね」と言っていた、ような気がしてきました。ハンドクラップのほうは調整できるのでマッチングは面倒だったらやらなくていいですよ。と言っていた、ような気がします。うーんどうも覚えてないなあ

さて、トランジスタのマッチングを取る方法ですが、恐縮ですが幣著の付録に載せたこの方法が伝統的です。

でも自分で書いたものにケチをつけるのも間抜けですが、ちょっとこの方法めんどくさいなあと感じてしまいます。もうちょっと簡単な方法はないかと、自分で考えることをせずにすぐ検索に頼るのは本当は良くないのですが、こんな方法がありました

http://www.bestsoldering.com/transistor-matching/

さらにその元記事

https://dragonflyalley.com/synth/images/TransistorMatching/ianFritz-transmat0011_144.pdf

元記事のスクリーンショットははばかられるので汚い手書きですけどこんな方法です。これで 1mV ぐらいの差なら概ねよろしいとのこと。これは簡単だし理にかなっているし同時に測れるから温度変化の影響も少なさそうだし、なによりやったことがないので面白そうです。この方法でマッチングを取って2ペア作りました。

ちなみに、マッチング方法を検索しただけなんですが、元記事を書いた人もさらにその元記事を書いた人もシンセ作る人です。おおもと記事を書いた Ian Fritz という人はその道でとっても有名な人です。21 世紀にどっぷり深く入ってもいまだにトランジスタのマッチングを取っているような人はだいたいそういう人なんですね笑ってしまいました

ところで全然関係ありませんがブレッドボード左側の回路は以前実験した電圧制御 EG の残骸です。ソースコードは

https://github.com/naokiiwakami/vceg

AVR のファームウェアを C++ で書くのはどう?

TR-909 クローンのファームウェア、あまり深く考えずに C で書き始めましたけど、どうもちょいちょい「これは、C++ のほうがよくない?」という場面にあたります。

例えばこんなところ

void TriggerRimShot(int8_t velocity) {
  SET_BIT(PORT_TRIG_RIM_SHOT, BIT_TRIG_RIM_SHOT);
  SET_BIT(PORT_LED_RIM_SHOT, BIT_LED_RIM_SHOT);
  g_rim_shot.status = 255;
}

この関数にはこんなマクロが参照されています

#define SET_BIT(port, bit) (port) |= _BV(bit)
#define PORT_TRIG_RIM_SHOT PORTD
#define BIT_TRIG_RIM_SHOT  PD0

なんというか。マクロだらけです。けっこう危ないコードだしメンテも大変そうです。他にもこんなところ

void CheckSwitches(uint8_t prev_switches, uint8_t new_switches) {
  if ((prev_switches ^ new_switches) == 0) {
    return;
  }
  if (IS_RIM_SHOT_ON(new_switches)) {
    TriggerRimShort(127);
  }
  if (IS_OPEN_HI_HAT_ON(new_switches)) {
    TriggerOpenHiHat(127);
  }
  if (IS_CLOSED_HI_HAT_ON(new_switches)) {
    TriggerClosedHiHat(127);
  }
}

スイッチが押されるのを検知する関数ですが、マクロを使うわ微妙に違う似たようなパタンの繰り返しになるわ。実行速度を考えるとループを回したり関数ポインタを使った汎用ルーチンを使ったりは避けたいですけど、すぐにメンテが大変なことになりそうです。これ、テンプレートが使えないかな?

てな風に、C++ で書いた方がいいんじゃね?感がどんどん増してきました。8bit プロセッサのコードを C++ で書くのはあまりやったことがありませんがどんな感じなりそうか見てみました。

続きを読む