PSoC CY8CKIT-049-42xx キットの USB-UART ブリッジを使う

これをプログラムするには miniprog3 が必要です。

1. SCB UART コンポーネントを置く。ボーレートを 9600 に変更する。
uart_config

2. ピンの割り当ては以下の通り

UART RX : P4[0]
UART TX : P4[1]

pin_connection

3. これがソースコード

4. ビルドしてプログラムして CY8CKIT-049-42xx キットを PC につなぎます
terminal_screenshot

はいこれだけ

PSoC 42xx を使って MCP2515 の命令フレームを生成する

PSoC 42xx は SPI コンポーネントが提供されていて、クロックは 4MHz まで設定できます。しかしながら、これを使って可能な限り速く MCP2515 と通信することはそれほど単純ではありません。

問題は、MCP2515 の命令は複数のバイトでできていることです。一つの命令は CS 信号で束ねられていて、命令を送っている最中はずっと L (イネーブル)にしておかないといけません。しかしながら、PSoC の SPI は CS 信号を直接制御できません。コンポーネントとの通信は FIFO を通じて行われており、FIFO がデータを受け取ると、内部で自動的に CS をイネーブルに変え、データの送信が終わって FIFO が空になると自動的に CS をディスエイブルに戻します。自動生成される API 関数はあまり効率が良くなくて、SPI のクロック周波数が高いとスピードに追い付けず、送信の間が空いてしまいます。そのためクロック周波数が高いと API 関数を使って MCP2515 の命令フレームを作ることができません。

datasheet_read_instruction

この問題を解決するために、API 関数を使わずに SPI を制御する関数を書きました。方針は

  • より低レベルのインタフェースを使って SPI とやり取りを行う
  • いったん送信が始まったら可能な限り速く Tx FIFO にデータを送り込み、送信が途絶えないようにする
  • データを送るのと並行して可能な限り早く Rx FIFO からデータを取り出す

いくつか制限事項があります

  • SPI 設定の Rx および Tx バッファサイズは 4 でないといけない。これより大きいと、PSoC Creator がソフトウェアバッファを生成してしまいソースコードの管理が難しくなる
  • 取り出したデータの最初の2バイトはダミーで意味をなさない。実際のデータは3バイト目から始まる。
  • まだ実装していないがたぶんこの関数を実行中は割り込みを停止しておかないといけない

以下がソースコードです。SPI コンポーネント名は SPIM_CAN で種類は SPI マスタ (SCB を使わない) です。

MCP2515 から 16 バイト取り出してみました。4MHz のクロックで想定通りに動いています。

read_instruction

read_instruction2

Analog3: 最初の設計例

DSC02688

Analog 3 の開発を休止してから1年が経ってしまいました。そろそろ再開しようと考えて、最初の設計例として作りたいシンセのパネルの粗案をかいてみました。パラメータ数は多いし、VCF のパラメータの例のように、伝統的なパラメータと考え方の違うものも多々あります。作って行くうちに更新や調整が必要になってくる可能性があります。ハードウェアの作り直しを避けるために、以下のような道筋で開発を進めようと考えています。

  • 最初に動くことがわかっているシンセから出発する。
  • このシンセを改造してゆくことで開発を進める。
  • 改造は、モジュールを1個ずつ Analog 3 のものに置き換えることで行う。
  • 新しいモジュールはソフトウェアパネルを使う。
  • 古いモジュールはハードウェアパネルを使い続ける

このようにして、常に完全なセットで音が出る状態で開発を進めようと考えています。

ということで、最初にする作業は、Analog2.0 の基本セットを組み立てることです。

 

今何を作っているのか

analog3もうここ数年ろくに新しい製作の記事を書いてないのですが、作るのをやめてしまったわけではなく、単に手こずっているのであります。あと、自分でも何を作っているのかよくわかっていなかったためなんとなく記事にしづらかったのであります。

作っては失敗し、やり方を変えてまた作り、を繰り返しはや数年、ここ一ヶ月ぐらいでやっと動く様が見られるようになってきました。動くものを見たら自分が何を作っているのかやっと少しずつわかるようになってきました。

今やっているのは、Analog3 というアナログシンセサイザー作りの新しいプロジェクトです。でも今の所アナログ回路はほとんど組んでいません。大半がソフトウェアです。まだもうしばらくソフトウェアばかり組むことになりそうです。

ソフトウェアの進捗はブログにまとめづらいのですがソースコードは GitHub で管理していてそちらから見られます。

https://github.com/naokiiwakami/analog3

何でアナログシンセなのにソフトウェアばっかりになっているかというと、以前していた Analog2.0 プロジェクトは一旦開発終了として(サポートは現在も続けてます!)、次のシンセを作ろうと思った時にこんな葛藤があったからです。

  • アナログシンセ、細かい所に不満が多すぎる。もっと細かいところをしっかりたくさん作り込みたい。
  • でも、こまこまと作り込むと、設定パラメータが増えてしまう。
  • アナログシンセには操作パネルが付いていて、パラメータ一個につきツマミが一個必要。
  • パラメータが増えたら、ツマミの数が大変なことになるよ。ツマミ100個とかになったら作るのは大変な手間だし、作ったとしてもごちゃごちゃしてて操作できないよ。
  • しかも、回路をちょっと変えただけでパネルの作り直しが必要になったらいつまでたっても完成しないよ。
  • こまった…

しばらく色々考えて、こんな風に考えるようになってきました。

  • パネルがなければ回路を変えてもあんまり困らないんじゃね?
  • パネルはソフトウェアで作っちゃう?
  • パネルがソフトなら、律儀にパラメータ一個にツマミ一個つけなくてもいいんじゃね?減らしたりまとめたりできるよね?操作楽だよね?
  • いいかも
  • でもツマミをくりくり回せないアナログシンセなんてアナログシンセじゃないよ。作る意味ないじゃん?

そんなわけで、色々試行錯誤してゆくうちに、Analog3 はこんな風なシンセになってきました。

  • あくまでもアナログシンセサイザー
  • でもパネルを作らなくてもいい
  • でもパネルを作りたくなったら作ってもいい

冒頭の写真の試作では、LFO モジュールを PSoC で実装して、アナログシンセを揺らしています。LFO のパネルはなくて、そのかわりにパネル情報が PSoC のモジュールに入っています。これを Raspberry Pi を経由して Mac から読んで、Mac の画面に描いています。ただ描くだけじゃなくてちゃんと操作もできます。まだ実装中ですけれども。ツマミを回すぐらいのことはできるようになってきました。

組み込み向け exp() 関数の実装方法

楽器系の作り物をマイクロプロセッサでするときには、指数関数が必要になる場合が頻繁にあります。汎用の実装は遅くてでかいので、組み込みには向きません。正確さが必要な場合は少ないですが、スピードと小ささは重要です。

組み込み向けの実装をいくつか探したので忘れないようにここにリンクをはっておきます。

http://www.convict.lu/Jeunes/ultimate_stuff/exp_ln_2.htm

http://www.quinapalus.com/efunc.html

今の所、過去に試作したエンベロープジェネレータの指数関数計算部分を流用していて、まだでかくて遅いですがとりあえず今やっているプロジェクトで使っている PSoC 4200 に収まってちゃんと走っているので困るまでこのままにしておくのではあります。

Memo: Maven

Installation

How to install Maven on Windows

Maven is a Java application, so we are just fine with expanding product zip package and setting environment variables M2_HOME and JAVA_HOME and set PATH.

Creating a Maven Project

Maven in 5 Minutes

Maven in 5 seconds… dothis:

mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

Stub Synth Module for MOM Development

MOM (Master Of Modules) manages synthesizer modules to make them work as a single musical instrument.  The main responsibilities of MOM are

  • Control patching.
  • Control parameters.
  • Organize voices.
  • (possibly) Organize modules such as device ID management.

Designing and implementing MOM and synth module data model is yet another challenge out of building CAN network.  Basically, the inter-module communication depends on CAN physical layer, but it’s a pain to dragging such a dependency during the MOM development.  I’m sure the CAN network would be quite unstable at first and I don’t want to stop and troubleshoot CAN while I’m working on MOM.

So, in order to remove dependency on CAN network, I’ll build the initial version of MOM based on TCP/IP with dummy (stub) synth modules that are purely software oriented and talk TCP/IP.  Once the MOM design is fixed, I can replace the TCP/IP driver by CAN driver later.  It will not ruin the module data model.

MCP2515 CAN Controller

As I mentioned in the previous article, I’ll use MCP2515 CAN controller for inter-module communication (initially, at least) for the Analog3 Project.

Datasheet of this device is available at the product page.

MCP2515 consists of CAN protocol engine, data buffers,  controller, and SPI interface as illustrated in the picture below.

MCP2515_block_diagram

a3_networkYou need to attach a processor to make this device functional.  In early phase of the project, I’m thinking of using a Raspberry Pi as the Master Of Modules (mom) and Arduino’s for dummy synthesizer modules.  Arduino is not a realistic solution for Analog3 both in terms of cost and performance.  So, I’m thinking of implementing a common synthesizer module driver based on PSoC or CAN enabled AVR.  MCP2551 is CAN transceiver.

It may take a while to get used to MCP2515.  Here are several links that are useful for getting started:

MCP2515 Linux Device Driver (probably for Raspberry Pi)

Arduino Example Sketch

https://gist.github.com/rechargecar/4177820

AVR Example Code (C)