PSoC 42xx provides SPI component that supports up to 4MHz clock speed. Communicating with MCP2515 via this component, however, is not straightforward when you try the highest clock speed.

The problem is concept of ‘operation’ of MCP2515. An operation consists of multiple SPI bytes bundled by ‘enable’ signal on the CS pin. Lowering the CS pin initiates an operation and it must stay low during the data transmission. See following timing chart quoted from the MCP2515 datasheet.

The PSoC SPI component lacks direct control on the CS pin signal. The component automatically lowers the CS level when the write API puts a byte to Tx FIFO and the component’s internal logic raises the CS level when all FIFO values are consumed. But auto-generated API functions are not fast enough due to overhead to make the functions generic. Then, the CS signal may split during an operation when Tx FIFO becomes empty due to the API failing to catch up with the desired speed.

I wrote a function that generates a valid READ operation frame and retrieves returned bytes. The strategy is:

• Use lower-level component interfaces to avoid overhead.
• The function pushes sending bytes to Tx FIFO as fast as possible to keep it non-empty during the operation.
• Concurrently read data from Rx FIFO as fast as possible to avoid FIFO overflow.

There are limitations to use this functions:

• Both Rx and Tx buffer sizes of the SPI component must be 4. PSoC Creator generates software buffer when the sizes are larger than 4. That makes source code management too complicated.
• The first two bytes in output array are dummy that do not mean anything. Actual retrieve data starts from the third element.
• The function may need to disable interrupts during the operation, though it is still missing in the implementation.

Here is the source code. In this example code, the SPI component name is ‘SPIM_CAN’ which is a master SPI component (non SCB).

#define CAN_CTL_READ 0x03

void mcp2515_read(uint8_t address, uint8_t data[], uint8_t length)
{
    /* initialization */
    uint8_t to_write = length;
    length += 2;

    /* flush rx buffer */
    while (SPIM_CAN_GetRxBufferSize())
        SPIM_CAN_ReadRxData();

    /* wait until Tx FIFO becomes empty */    
    while (0u == (SPIM_CAN_TX_STATUS_REG & SPIM_CAN_STS_TX_FIFO_EMPTY)) {}

    CY_SET_REG8(SPIM_CAN_TXDATA_PTR, CAN_CTL_READ); // push instruction
    CY_SET_REG8(SPIM_CAN_TXDATA_PTR, address);      // push address

    // loop until all bytes are retrieved
    while (length > 0) {
        // transmit 0 to receive a byte
        if (to_write > 0 && (SPIM_CAN_TX_STATUS_REG & SPIM_CAN_STS_TX_FIFO_NOT_FULL)) {
            CY_SET_REG8(SPIM_CAN_TXDATA_PTR, 0);
            --to_write;
        }
        // retrieve a byte if there is any in Rx FIFO
        if (SPIM_CAN_RX_STATUS_REG & SPIM_CAN_STS_RX_FIFO_NOT_EMPTY) {
            *data++ = CY_GET_REG8(SPIM_CAN_RXDATA_PTR);
            --length;
        }
    }
}

Tried reading 16 bytes from MCP2515 using this read function from a 4MHz-clock SPI of a PSoC Pionner Kit. The CS (Enable) signal stays low during the operation, as expected.

You frequently encounter a situation that exponential function is necessary when you work on a musical instrument project using micro processors.  Its generic implementation is slow and space consuming, so is not suitable for micro processors.  So I need to do some alternative implementations.  For those implementations, space and speed is important but accuracy may be sacrificed in many cases.

Follows are articles about fast and compact exp() implementations, for my future reference.

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

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

I’m currently using a table lookup approach that I implemented before for an envelope generator I prototyped before.指 This one is still a little slow and large, but it’s running in PSoC 4200 without major problem anyways.  So I’ll keep it for a while.

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

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.

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.

You 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)

• http://clientes.netvisao.pt/anbadeol/mcp2515.html
• https://github.com/msperl/mcp2515
• http://lnxpps.de/rpie/mcp2515_mod.c

Arduino Example Sketch

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

AVR Example Code (C)

• http://read.pudn.com/downloads127/sourcecode/embed/537693/AVR%2Bmcp2515%E6%BA%90%E7%A0%81/src/mcp2515.c__.htm
• https://code.google.com/p/avr-drv/source/browse/trunk/ExternalDevice/Microchip/MCP2515/?r=170

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.

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.

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.