Category: Electronics

SPI (Serial Peripheral Interface) protocol is a synchronous serial data link which operates in full duplex mode. It’s got a higher throughput compared to I2C or SMBus  and it’s very useful for high speed short-range communications.

The SPI protocol specifies the following signals:

• SCLK — Serial Clock (output from master)
• MOSI/SIMO — Master Output, Slave Input (output from master)
• MISO/SOMI — Master Input, Slave Output (output from slave)
• SS — Slave Select (active low, output from master)

All lines can be shared for every slave device in the bus except the Slave Select signal which has to be different (out of band selection) for each slave.

This is the basic operation depending on the CPOL and CPHA values:

The SPI core I’ve implemented is fixed for Slave and CPOL=0/CPHA=0 modes. This means that the MOSI line will be sampled at every rising edge of the SPI Clock whilst the MISO signal will be set right before this rising edge (actually, on the falling edge) so that it can be properly sampled by the Master.

As the FPGA will have its own clock, we’ll be having two different clock domains since the SPI master signals will be generated externally and they won’t be necessarily synchronized to the FPGA internal clock. Thus, the approach will be sampling all the external signals to get them synchronized and using two shift registers for input and output data.

 Source code:

entity spi_slave is
  port (
    RESET_in    : in  std_logic;
    CLK_in      : in  std_logic;
    SPI_CLK     : in std_logic;
    SPI_SS      : in std_logic;
    SPI_MOSI    : in  std_logic;
    SPI_MISO    : out std_logic;
    SPI_DONE    : out std_logic;
    DataToTx    : in std_logic_vector(7 downto 0);
    DataToTxLoad: in std_logic;
    DataRxd     : out std_logic_vector(7 downto 0)
    );
end spi_slave;

architecture Behavioral of spi_slave is

    signal SCLK_latched, SCLK_old : std_logic;
    signal SS_latched, SS_old : std_logic;
    signal MOSI_latched: std_logic;
    signal TxData : std_logic_vector(7 downto 0);
    signal index: natural range 0 to 7;
    signal RxdData : std_logic_vector(7 downto 0);

begin

 --
 -- Sync process
 --

  process(CLK_in, RESET_in)

 begin
    if (RESET_in = '1') then
      RxdData  '0');
      index <= 7;
      TxData  '0');
      SCLK_old <= '0';
      SCLK_latched <= '0';
      SS_old <= '0';
      SS_latched <= '0';
      SPI_DONE <= '0';
      MOSI_latched <= '0';

    elsif( rising_edge(CLK_in) ) then

      SCLK_latched <= SPI_CLK;
      SCLK_old <= SCLK_latched;
      SS_latched <= SPI_SS;
      SS_old <= SS_latched;
      SPI_done <= '0';
      MOSI_latched <= SPI_MOSI;

      if(DataToTxLoad = '1') then
          TxData <= DataToTx;
      end if;

      if (SS_old = '1' and SS_latched = '0') then
          index <= 7;
      end if;

      if( SS_latched = '0' ) then
         if(SCLK_old = '0' and SCLK_latched = '1') then
            RxdData <= RxdData(6 downto 0) & MOSI_latched;
            if(index = 0) then -- cycle ended
               index <= 7;
            else
               index <= index-1;
            end if;
         elsif(SCLK_old = '1' and SCLK_latched = '0') then
            if( index = 7 ) then
               SPI_DONE <= '1';
            end if;
            TxData <= TxData(6 downto 0) & '1';
         end if;
      end if;
     end if;
   end if;
   end process;

   --
   -- Combinational assignments
   --

   SPI_MISO <= TxData(7);
   DataRxd <= RxdData;

end Behavioral;

In order to test this core I wrote a simple testbench wich basically waits for a command from the master and answers it. This will serve as a base for the microcontroller code which will send this same command (0xA0) and wait for the answer (0xA4). This is the simulation view:

As you can see, when the spi_done signal goes high, the datarxd register is loaded with the value 0xA0. Afterwards, the answer to this command (0xA4) is loaded into the datatoxload register and the MISO line is set to the right bit at every falling edge of the SPI clock signal.

As the simulation looks good, I decided to wire up the FPGA to an LPC2148 microcontroller and test the SPI core for real. The following code will run in the LPC:

void send_fpga_cmd(unsigned char cmd)
{
    unsigned char dummy;
    IO0PIN &= ~(1<<11);    // Select FPGA
    while ( !(SSPSR & 0x02) );
    SSPDR=(unsigned int) cmd;
    while((SSPSR & (1<<4)));
    IO0PIN |= (1<<11);    // deselect FPGA
    dummy = SSPDR;         //flush the RxFIFO

}

unsigned char read_fpga_byte()
{
    unsigned char data;
    SSPDR= 0xFF;         // write dummy data out to gen clock
    while((SSPSR & (1<<4)));
    data = SSPDR;
    return data;
}

while(1)
{
    send_fpga_cmd(0xA0);
    data = read_fpga_byte();
}

I configured the SPI bus to run at 2MHz on the microcontroller. Here you can see the logic analyzer output which shows that the SPI core works as expected.

As you can see, the microcontroller sends a ping (0xA0 byte) and the FPGA answers with a response command (0xA4 byte). The SPI clock frequency is exactly 2.000MHz and the behavior is the expected one.

Silvestre FPGA – SPI Test

Daniel

I’m working on a project which involves an i2c communication between a master and some slaves. The master device is using an LPC2148 microcontroller running at 60 MHz and the slave ones have a low-cost PIC microcontroller. Each slave device runs a different task and some of them are more CPU-intensive than others.

The nature of this i2c communication is essentially some kind of Query-Response protocol in which the master requests some processing from the slaves and they send back the results to the master. The processing time varies from one slave to another and sometimes it will be higher than the master ‘clock’ time.

This leaded me to find a way to stop the master until the slave is done with its processing: clock stretching. The slave will pull the clock line down, causing the master to stop until it’s done with its task and then releases the SCL line (going high due to the required pull-ups of the i2c signals).

As I was writing the slave C code using PICC compiler, there was no way to implement this technique directly from the supplied i2c functions therefore I’d got to implement it by myself:


#byte PIC_SSPCON=0x14
#bit CKP = PIC_SSPCON.4 // 1 = Release Clock, 0 = Holds Clock Low (clock stretch)
#define SCL_STRECTHING_ON bit_clear(PIC_SSPCON, 4); // CLK STRETCHING
#define SCL_STRETCHING_OFF bit_set(PIC_SSPCON, 4); // release clock to master

…
ISR:

if(state >= 0x80) //Master is requesting data
{
SCL_STRECTHING_ON
delay_us(400); // Simulate processing delay
i2c_write(buffer[cnt++]);
SCL_STRETCHING_OFF
}

Please, note that the values defined for SSPCON register / bits are for PIC16F677 microcontroller and it might differ from the one you’re using.

Below you can see an screenshot of the Logic Analyzer output I used for testing purposes. You can see the 400 us delay between two consecutive readings from the master while the SCL line remains low.

All in all, it’s a well known technique described in the protocol specification but as far as I’m concerned by googling a little bit, its usage is not very extended and there are not so much source code out there addressing this issue.

Daniel

RL-AMC-50NP04 is an advanced Full H-Bridge board based on high performance MOSFETs capable of driving two high power DC motors. It has been designed to achieve a great efficiency and usage simplicity since just 3 pins are needed to control a motor. Based on the large experience working with Robotics we designed this board keeping in mind some important factors such as power dissipation, heating, simplicity and functionalities like braking, bi-directional control of the motors and a wide range of PWM frequencies from 3.3v or 5V microcontrollers.

Its small size makes this H-Bridge MOSFET board perfect to fit in your Robotics designs: 50 x 42 mm (1,97 x 1,65 inch) .

Main features:

• 2 high power DC Motors control.
• PWM frequencies up to 20 KHz for speed control.
• Bi-directional control.
• Braking function (coast and brake functions).
• 3.3v / 5V logic capable.
• Up to 8A continuous operation with very low internal resistance (0.038 ohms).
• Up to 35A pulsed current.
• Wide range of power supply voltage ranging from 3 to 40V.
• Current sense (just 6mV per amp to minimize the total voltage drop when high currents are demanded).
• Just 3 pins needed from your microcontroller to drive each motor.
• Two LEDs per leg indicating the rotating direction of each motor.
• Easy interface connections through an standard 10-pin male header.
• Three two-pin terminal blocks for connecting the motors and their power supply.
• Logic power supply ranging from 2V to 6V.

Here you can see the output of the board when driving one of its LEDs with a voltage supply of 8,4V. The voltage drop accross the LED is about 1 Volt and in this graphic you can appreciate that the rising and falling times are extremely small since it has been designed for operating in high-speed environments with the maximum efficiency. This minimizes the transition time of the MOSFETs (time when their internal Rds resistance is higher) and, thus, also minimizes the total power dissipation due to switching power losses.

If you are interested in this board or have any further questions / suggestions don’t hesitate  to contact me.

Documentation:

• RL-AMC-50NP04 Quick Reference Guide
• RL-AMC-50NP04 Reference Source Code (for interfacing it from the LPC2138-01 board)

More to come,

Daniel