MCP3204 response

[ee_hob]

Hi all,

I'm new to microcontrollers. I've been trying to interface MCP3204 with PIC16F877 by bit banging method. The reason why I don't use built-in functions is that I want to learn the basics.

Here is my code.

[PCM programmer]

Here you are issuing a positive clock pulse before you set Din to a high
level:

[ee_hob]

Hi PCM programmer,

Thanks for your quick reply.

I changed the code but nothing changed. I guess I didn't exactly understand the initialization part. I opened the driver file of MCP3204, initialization is done by adc_init which is mcp_init in my code. Could you please tell me where I'm wrong?

[PCM programmer]

[ckielstra]

Just another comment on this part of your code:

[ee_hob]

PCM programmer,

I understood my mistake about CS. Although I knew that was suppose to be like that but I didn't look carefully, sorry for that.

ckielstra,

I removed mcp_init(); outside the while loop as you said. I didn't remove lcd_init(); outside the while loop because when I do that, the screen becomes messy.

I didn't notice that the digit precision is limited, thanks for that. Because of being a newbie, I wanted to use fundamental things like value=5V/2^12.

By the way, I changed the code due to your instructions but it's still not working. I don't know if you had time to look at the datasheet but can there be a problem with timing?

[ee_hob]

I didn't want to open a new topic, if this is wrong, sorry for this.

PCM programmer,

I saw a driver written by you I guess. (http://www.ccsinfo.com/forum/viewtopic.php?t=41059) If you don't mind, I would like to ask a question about this.

[RF_Developer]

As you're wanting to learn, I think its useful to simplify the process. Its confusing to think of start and stop bits (that's something relevant to asynchronous comms such as RS232 but not to synchronous such as SPI). Also, as others have pointed out, chip selects (CS) are traditionally active low, so their inactive state is high, and active, i.e. the chip is selected, is low.

SPI simultaneously sends and receives data, one bit of each for each clock period. However, setting the data bit to send and reading the data from the slave device are done on different clock edges. Also there are four possible combinations, modes 0 to 3, of the polarity of the clock and which edges are used for read and write. The MCP3204 uses probably the commonest mode, mode 0, of SPI where both ends read their incoming data on rising edges of the clock. This means that they must put their outgoing data out BEFORE the rising edge, and that typically means at the previous falling edge, or for the first bit, in advance of the first positive going clock edge.

The process sounds complex, but can be broken down to this, for masters. I'll use the CLK for clock, DI for data in (sometimes called MISO or Master In, Slave Out) and DO for data out (MOSI), and I'll assume we're sending bytes as most hardware implementations do:

Initialisation:

Set CS high (i.e. inactive - the slave ignores us)
Set CLK low
Set DO low.
Set DI to input

To transmit and receive a message/command.sequence of bytes:

Set CS low (active - slave now listens and sends to us)

For each byte we want to send:
Send and receive a byte.

Set CS high (inactive - ends the message, slave now ignores us again)

Where Send and receive a byte is:

For each bit of the byte from LSB (Least Significant Bit) to MSB:
Set DO to the bit to be sent
Possibly wait a little depending on processor speed and code efficiency
Read DI bit and put it into right place in the received byte
Set clock high
Possibly wait a little
Set clock low

A problem with any software implementation of SPI is that the active edge of the clock cannot be where the data is read. In hardware the clock literally clocks in the data at that moment with a delay measured typically in nanoseconds. You simply cant do that in firmware, the two cannot be coincident, so we have to read the data an instruction or two, or in C a line, which may be several instructions before we change the clock. Also hardware would read in and read out using shift registers, maybe even just one single register that reads into the MSB while reading out from the LSB. After a byte's worth of clocks the byte read will be in the right place in the register. I've done an SPI in an FPGA and I used two registers instead of one for simplicity. The firmware version would typically also use shifts on the send and receive bytes rather than masking out each bit in turn, i.e:

Set DO to the LSB bit of the byte to be sent
Shift received byte right one bit (also acts as wait)
Read DI bit into the MSB of the received byte
Set clock high
Shift send byte right one bit (also acts as a wait)
Set clock low

These processes shows that we don't have to worry about start and stop bits - there are none - and it leads naturally to a division into logical and neat subroutines that give clean code. Its also simple to alter this for other SPI modes.

RF Developer

[ee_hob]

RF_Developer,

Thanks a million for your reply.

I guess I'm getting idea of SPI but I still don't understand why I need to get byte by byte. Forgive me because I'm really having hard times to understand.

As I wrote above, I guess my problem is about timing operations. If I'm wrong please correct me but when I use hardware SPI instead of software SPI these timing problems are almost solved, right?

[dyeatman]

ee_hob
Using bit bang you don't have to go "byte by byte". You can input or output
as many bits as you want at one time, based on how you write
your custom routines.. I have written 24 bit ADC routines like this.

If you use SPI hardware, however, you will have to read or write "byte by byte" due to
limitations of the SPI hardware in the chip.

Over time I have found it much easier (and cleaner) to use the SPI
hardware and read/write as many 8 bit bytes as required so I eventually
rewrote my 24 bit ADC routine to use 8 bit SPI hardware and it works
equally well.

From the ADCs perspective sending (or receiving) three 8 bit bytes in a
row (without changing any of the other signals) looks like 24 continuous
bits.

BTW, Section 6.1 and figures 6-1 and 6-2 in the datasheet explain and
show the byte mode really well.

Also, note the min clock speed and sample times in section 6.2.
_________________
Google and Forum Search are some of your best tools!!!!

[ee_hob]

Thanks dyeatman, I'll be working on it.

[PCM programmer]

[RF_Developer]