USB Communication...

The USB interface is heaven for the users... mostly plug and play... or simply install the driver and everything would be working from there on... After short journey into USB, I realized it was a far jump from the RS232 I'm used to.

My learning points:

1. USB devices must have some intelligence built in. When you connect a device to a serial port, windows does not do anything UNTIL you tell it do so. Remember the old days when you connect a serial modem? You have to tell windows you have connected a serial modem and then install the necessary driver and then you can start using it by telling windows the comm port, baud rate, etc.

2. With USB, the moment you plug it that device, windows knows that a USB device has been connected. It will automatically try to identify the device and 'configure' it for use. If it fails to find a suitable driver or if it fail to properly communicate with the device, then it will complain... asking you for the driver or simply state that the USB device fails to be recognized.

3. When windows detect a USB device connection (pull up resistor on the data line)... it will query the device for its' class (mass storage, HID, etc). If the driver for the class is already available to windows then it will just install the driver and the device is ready for use...

4. SO, if you want you PIC to talk to the PC via USB... several key things need to be understood and programmed for...
** Your PIC must comply to the USB-bus strict timing requirement... for full speed USB, the timing is based on 48MHz clock... the USB portion of your PIC must operate at that speed, the main controller can operate at lower speed...
** Your PIC must response to PC initial queries (also called USB enumeration) to exhange various information in order for windows to recognise the device and use it...
** Your PIC USB portion must have what's called VendorID and ProductID in order for windows to manage USB communication destined for your device...

I was ready to give up and revert back to my convenient RS-232 interface (via USB to serial converter) but decided to dwell into USB for learning sake. To avoid having to write my own device driver, I decided to use the HID (Human Interface Device) class. Windows (and MacOS) already have driver for HID class so windows will detect the device, install the driver and I'm ready to go. Sound simple eh... wait for the next installment of blog... :-)

If up to this stage, you still have braincells to waste... go on to these sites for more indepth info on USB...
USB at BeyondLogic.com
Or something from Atmel
Or something else here...

SPI Tutorial

It is intended for transmission of data from a master device to/from one or more slave devices over short distances at high speeds (MHz).

It is simply based on an 8 bit shift register shifting data out on a single pin and shifting data in on another pin.

Note: some devices use more than 8 bits!

Its main use is to replace parallel interfaces so you don't have to route parallel buses around a pcb. pic spi masterFor example you can buy an SPI 12bit ADC and instead of 12 parallel wires to read the data you only need 4 SPI connections. Actually you may only need three as you may not need to send data to the device!

With the SPI interface you can communicate with a device transmitting and receiving 8 bits of data at the same time and it is suited to high speed streaming data transfers.


Note: The trade off between usingpic spi slave a parallel interface and the SPI interface is speed e.g. if you read a parallel 12bit ADC at 200ksps then you could read the device at a 200kHz rate but if you want to get the same data rate using SPI then you need a serial speed of 200kHz x 12 = 2.4MHz. So the actual trade off is speed and the consequential noise introduced into the circuit.

Unlike I2C there is no concept of transferring ownership of the bus i.e. changing bus master and there are no slave device addresses. SPI is a much simpler protocol and because of this you can operate it at speeds greater than 10MHz (compared with the 3.4MHz maximum for I2C).

The best feature of SPI is that you can do full duplex data transfers (data in both directions at the same time) which you can not do with I2C and you can do it fast.

Note: The maximum rate for a PIC Micro using a 20MHz clock is 5MHz.
SPI Interface : Signals
SPI Interface Signals
PIC name Master Slave
SCK Serial clock output from master [SCK] Input to slave [SCK]
SDO Serial data output from master [MOSI] Input to slave [MOSI}
SDI Serial data input from slave [MISO] Output from slave [MISO]
SS Optional slave (chip) select [SS]
Slave select [SS]

[] denotes SPI naming convention

Here is the setup for a single SPI device connection:

SPI Interface - single device

Single SPI device
Note: The chip select signal SS is optional for a single device system as you could tie the SS input at the slave low if the other lines are dedicated to SPI use.

There are two ways to implement multiple slave operation:

* Use a separate chip select for each slave device.
* Wire all the slaves together DataOut to DataIn (daisy chain).

SII Interface : Using chip selects

SPI Interface using separate chip selects



















With this scheme you control each slave device using its chip select line (usually active low- red arrows show control lines). When disabled the Data output from the slave goes into a high impedance state so it does not interfere with the currently selected slave and the data input is ignored (check datasheet).

The advantage of this scheme is that you can consider each device separately when you compare it with the daisy chain method.



SPI Interface : Daisy chaining

SPI interface with daisy chain



















With this scheme all data sent by the master is shifted into all devices and all data sent from each device is shifted out to the next (shown by red dotted arrow). For this scheme to work you have to make sure that each slave uses the clock in the same way (see clock and data) and you have to get the right number of bits - so there is more work to do in software.

Compared to I2C these are very inelegant slave selection mechanisms and look like kludges to get round the fact that SPI was designed really as a simple single master to single slave protocol. Having said that the above methods will work but for daisy chaining you will have to be careful of clock polarity and clock use as this is not defined in the SPI standard.
SPI Interface : Clock and Data
How a device reacts to clock input is undefined!!!

Data can be sampled at the rising or falling edge and data can be generated after the rising or falling edge!

This is why you can set the clock output from a master mode device in multiple ways just look at the diagram below - the first four signals are the four options you have to select the output clock.

SPI Interface PIC signals (extract from DS39582B)

PIC SPI interface signals



















You match the output clock to the clock that your device requires.

Note: This is why daisy chaining may not be a good idea (or you have to think very carefully about it!).

Note: For Master or Slave mode when using PICs you need to set the TRIS direction of the SCK pin appropriately.
Problems with the SPI interface

* The clock scheme may not be the same between devices.
* The data length can vary from device to device.

Advantages of the SPI interface

* Very fast > 10Mhz.
* Simple protocol (easy to program in software if you have no SPI hardware module).
* Simple interface (no bidirectional pins c.f. I2C).
* Supports full duplex data streaming.

>>>> extracted from http://www.best-microcontroller-projects.com/spi-interface.html<<<<

Wireless System Development

Over the next few weeks, we are going to develop a wireless system to capture and log data from remotes sensors. The system will have a master controller to manage the communication between all the devices (nodes) in the system.

Depicted above is the overall architecture and the communication mode.
The PC will be communicating with the master controller (mPIC) via the USB interface.
The master controller (mPIC) will be talking to the wireless module (RFM) via SPI interface.
The wireless module (RFM) will communicate wireless to another RFM using radio waves at 430MHz.
The slave (sPIC) will be talking to the RFM via SPI to receive commands and submit data.
The slave (sPIC) will be connected to various analog and digital sensors as required.

System general info.
The slave will be operating using batteries thus will be in sleep mode until communication/data capture is required.
The master controller will operate autonomously independent of the PC. The PC connection is required only for offloading of capture data for further storage or analysis as well as for initial setup and configuration of the system.

SPI Communication...

As per Wikipedia... (click link for extensive explanation)

"The Serial Peripheral Interface Bus or SPI (often pronounced "es-pē-ī" [IPA: ɛs pi: 'aɪ] or "spy" [IPA: spaɪ]) bus is a synchronous serial data link standard named by Motorola that operates in full duplex mode. Devices communicate in master/slave mode where the master device initiates the data frame. Multiple slave devices are allowed with individual slave select (chip select) lines. Sometimes SPI is called a "four wire" serial bus, contrasting with three, two, and one wire serial buses."

Another good introduction to SPI (PDF) by Microchip...

We are dwelling into USB, SPI and UART because we ourselves are learning on how to design and build a system comprising of various sensors reporting/logging data to a central host. We'll be using Hope RF Transceiver Modules for wireless communication and the central host will be communicating with a PC via USB interface... A good write up explaining the transceiver module is here.

After a long break...

Very soon, we'll start getting some activities back to this site... some of the areas to be covered will be...
... USB communications
... SPI communications
... UART communications

We'll look at the physical aspect as well as the logical/firmware aspects to the devices talking to each other... stay tune...