Author Archives: Gan

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 in the picture is a CAN transceiver BTW.

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)

Changing the Strategy for Analog3

I’ve been trying for a year to make my own serial interface protocol to exchange data among synth modules.  Though it showed some progress, I kind of giving up this approach.  The problem is complexity of serial interface controller.  A controller for multi-master serial interface is complex.  Implementing using a generic device is more costly in many sense than I expected.  I started with Arduino.  This was the easiest approach but channel was too slow.  I could only achieve 50kbps.  Then I tried implementing it into AVR using assembler language.  It went 100kbps but it was about the limit.  The most serious problem with MPU was that the processing is always on single thread.  Some data processing has to be done in parallel during data reception, but it was pretty inefficient to run such concurrent tasks on 8-bit simple processor.  Overhead for such multi-tasking killed the speed.  Then, I moved onto PSoC.  It achieves bit rate 400kbps easily and it might go higher if it’s tuned well.  However, the logic to handle collision is so complex that I eventually am suffered from lack of resources in PSoC.

So at this point, it seems more practical to use a ready-made implementation of an existing protocol, which is CAN.

The reason I didn’t go for CAN at first was speed.  I wanted to use the interface even for synching oscillators.  I was not sure if 44bit-at-shortest message from at 1 Mbps is short enough for that usage.  (I’m not sure yet.  It’s about 22kHz rate if you keep repeating shortest CAN message at the highest rate.  That’s pretty close to audio frequency.  If an oscillator keeps sending such messages, the communication channel would be pretty much occupied.)  So probably I need to give up some usage of the common data bus.  I will go with following approach:

  • Use cheap CAN controller and transceiver: MCP2515 and MCP2551.
  • MCP2515 is controlled by SPI.  Most processors can use it.
  • I’ll use Raspberry Pi for the master synth controller module.
  • Synth modules can be based on PSoC or AVR.  These two are ones I am familiar with.
  • I’ll give up some features such as oscillator sync network.

I’ve placed an order to get these parts.  This part is blocked until the parts arrive.

Raspberry Pi I2C clock-stretching problem

The I2C slave that I’m developing has been failing intermittently.  I finally noticed this was a known bug in Raspberry Pi that mishandles clock stretching.

I2C slave may delay response by holding SCL low.  However, when the slave does it, the I2C master in Raspberry Pi gives very short clock for the first bit of the next byte.  The symptom can be seen as following picture.

10678616_689709434441211_7585444260259589843_n

More detail explanation can be read in this link:

http://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html

In order to workaround this, I set data rate in I2C slave module higher.  The communication rate is 400 kbps, but I set the data rate 1000 kbps.  It worked for me.  Here is the setup of I2C slave module.

I2Cslave

 

Raspberry Pi Setup Memo

Search engine helps, but I’m so lazy that I don’t like to do the same search repeatedly.

Wireless LAN setup:

Use application “Wifi Configuration” from GUI menu.

Common WIFI dongle problem of falling of network:

Power management feature is enabled in default for device 8192cu.  Having following file resolves the issue:

pi@raspberrypi ~ $ cat /etc/modprobe.d/8192cu.conf
# prevent power down of wireless when idle
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

See https://github.com/xbianonpi/xbian/issues/217

CAP/CTRL swap:

See http://raspberrypi.stackexchange.com/questions/5333/how-to-map-caps-lock-key-to-something-useful

Set static address to wifi interface:

Edit /etc/network/interfaces.  If the setup for wlan looks like following,

allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

modify as follows:

allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet static
address your-address
netmask your-netmask
gateway your-gateway

 Install Inconsolata font:

http://www.raspberryconnect.com/raspbian-packages-list/item/64-raspbian-fonts

Set timezone:

% sudo dpkg-reconfigure tzdata

Raspberry Pi B+ Pinout

Picture in Pi4J Project:

Noise Source Transistor — Conclusion

DSC00098_2I have been working for a while to determine which transistor to use for noise source in noise generator.  I was using 2SC3311 which was obsoleted recently.

I did several tests, mainly by listening, and chose BC547.  The reasons are:

  • It has good taste as a noise source.  Easy to find sweet spots when using it with a filter and VCA.
  • Noise level was close to 2SC3311, so my previous design works with simple replacement.
  • Availability is good.
  • Unlikely to get obsoleted soon.

I started the test with listening “raw” noise without any modification and filtering.  However, it didn’t work well.  Many of the candidates sounds similarly.  However, I found characteristics of transistors are so different when I also used a VCF and a VCA driven by an envelope generator.

Also, it was hard to determine “which sounds better” when I conducted A/B comparison test.  So I changed the strategy and just played with synth using each candidates, and chose one I felt the most fun to play with.  Thus I gave up “measuring” eventually.

Demo using the chosen transistor.


Reading Keypress with Python

This works for windows.

http://stackoverflow.com/questions/12175964/python-method-for-reading-keypress

However, you cannot use this feature from cygwin.  You need to invoke python script directly from Windows.  Double-clicking the python script works, but you need to catch exceptions in the case (otherwise, you don’t know what happened when an exception was raised).

Here is the sample program to read arrow keys.

#!c:\Python32\python

from msvcrt import getch
import sys

print("press ESC to exit")

while True:
    try:
        key = ord(getch())
        if key == 27: #ESC
            break
        elif key == 224: # special keys (arros, f keys, ins, del, etc.)
            key = ord(getch())
            if key == 75:
                print("left")
            elif key == 77:
                print("right")
            elif key == 80:
                print("down")
            elif key == 72:
                print("up")
    except:
        print(sys.exc_info()[0])

SPI / RX collision test

spi_rx_collision_testDone collision test between SPI and RX in the comm driver.  The driver would receive RX signal any time, even while the host processor is accessing the driver via SPI to send or retrieve data.  Currently, the serial RX is handled in external input interrupt handler, so any bug in RX handler may break registers (i.e., states) for SPI communication.  I actually saw those bugs several times.  The bugs are fixed now and load test has passed.  In the test, the load generator keeps sending data via serial channel.  I’ve changed the timing of data retrieval in the host of the receiver so that SPI / RX collisions frequently happen.  Actually, they are happening every other packets in the test.  The test ran for 10 hours so far and there is zero communication error.  Session keeps going without freezing.

Dragon’s Tail

dragons_tailAs mentioned in my previous post, AVI Dragon’s SPI pins in debugWire interface have to be disconnected during debug run in order to properly run an application that uses SPI / USI.  I also noticed that the Dragon dominates RESET pin, too.  In my project, I’m resetting target chip from Arduino.  The Dragon is killing this functionality as well.  This makes me quite uncomfortable with my development work, so I’ve enhanced the switch I made on bread board previously, and made a helper device.  It’s nicely working.  I named it “Dragon’s Tail”.

Continue reading