How to tell SPI is working?

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you've seen my posts, you can tell I am new at this.

I am trying to the touchscreen on my graphic LCD screen.

The controller is MXB7843 from Maxim, and it uses SPI. My 4-wire screen is hooked up correctly to the controller, and I have all my SPI signals connected to the controller, too.

I have my code programmed to write values received from the SPDR to the LCD screen. So, far all my SPDR values are 0's.

I've tried to look at the CLK signal for the SPI, but I don't see anything on the OScope.

So, is there anyway that I can troubleshoot if my code is wrong or the controller isn't working?

Is there anyone that has working code for the Maxim touchscreen controllers?

Attached is my code in progress....

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am very confused at a first pass through that program.

You say that it is an SPI interface, yet "data_port" is PORTA and there is a bunch of bit-whacking with the WR etc.

I cannot find the definition for DDR_SPI but according to the comments it stands a good chance of not working--it makes the /SS pin an input which is >>not<< good for master SPI.

There is entirely too much messing about with SPDR. SPI is an inherently full-duplex protocol. When you sprinkle those SPDR=0x00; in there you are starting another full-duplex transaction.

Do yourself a favor--use CodeVision's spi() primitive.

SPCR=0xD1; neeeds to be correct for >>your<< target device.

There is rarely if ever a justifiable case to use interrupt-driven SPI on a master.

Below is a 25xxx SPI EEPROM read sequence. You will probably have similar sequences. 1) Select the slave; 2) Send command byte(s) ignoring the returned bits from the full-duplex SPI--discard the return value from spi() 'cause don't care; 3) Clock in one or more response bytes, sending a "don't care" value; 4) De-select the slave

// **************************************************************************
// *	E E P R O M _ R E A D
// **************************************************************************
//
unsigned char				eeprom_read			(unsigned int addr,
												unsigned char * data,
												unsigned char count)
{
unsigned char i;	// working variable

// Check for not busy.
	if (eeprom_rdsr() & 1)					// low bit: /RDY or BUSY
		{
		return (0);							// busy; this operation failed.
		}

	SELECT_EEP = 0;							// select serial EEPROM
	i = EEP_READ;

	// >= 25080 sequence
	spi(i);									// send op code

	i=(unsigned char)(addr >>8);
	spi(i);									// send high 8 bits of address

	i=(unsigned char)(addr & 0xff);
	spi(i);									// send low 8 bits of address

	for (i=0; i

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the reply!

Quote:
You say that it is an SPI interface, yet "data_port" is PORTA and there is a bunch of bit-whacking with the WR etc.

PORTA is data for my LCD module. Bit-whacking is because AVR Studio doesn't allow bit access like Code Vision does.

Quote:
I cannot find the definition for DDR_SPI but according to the comments it stands a good chance of not working--it makes the /SS pin an input which is >>not<< good for master SPI.

PORTB has the SPI signals. Yeah, I just changed it to DDRB = 0x06. This will make MISO and the busy signal from the touchscreen controller as inputs, and MOSI and the SPI clock as outputs. The commented code on the DDR_SPI came from the datasheet, and I decided not to change it around and use it. Since the MXB7843 chip is already enabled via GND, I decided not to use the /SS pin.

Quote:
SPCR=0xD1; neeeds to be correct for >>your<< target device
Yep it is... I got this from the Atmega1281 datasheet. I have the Atmega configured for SPI interrupt, SPI enable, MSB order, Master, CPOL & CPHA = 0, sysclk/16

Quote:
There is rarely if ever a justifiable case to use interrupt-driven SPI on a master

So, there's no need for an interrupt? So, for a touch screen controller, does it just send out data to my AVR as soon as I touch the screen? How do I know when that data arrives? Is that when I poll the SPSR register for a "1" on the SPIF? Does this SPIF reading become part of the WHILE loop in MAIN to run a menu system on the touchscreen?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Since the MXB7843 chip is already enabled via GND, I decided not to use the /SS pin.

Bad puppy, bad! You expect always to stay in sync, eh? And no heed my warning about making /SS and output? SEE THE DATASHEET ON THAT!

Quote:

So, there's no need for an interrupt?

Short answer, yes there is no need. If you are the master, >>you<< initiate the transaction. If you are the slave then it is a whole different ball game.

Quote:

Bit-whacking is because AVR Studio doesn't allow bit access like Code Vision does.

Converting to the Dark Side, eh? WAY bad puppy!

A quick glance at the datasheet indicates that yes you do indeed want to use CS and that AVR SPI should be suitable in 24-clock mode.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, the interrupt on a master SPI fires when the transmission is complete. The screen controller can't send out any data on its own, because it's a slave, the master has to issue clock pulses, and you need to initiate a transfer for that to happen.

It's possible the screen controller has a (not SPI related) dedicated interrupt line which you can monitor with either an external interrupt, pin change interrupt, or plain polling. But this is completely seperate from the SPI interrupt.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
You expect always to stay in sync, eh?

So, my controller might be out of sync with the AVR? I'm not following you.

Quote:
And no heed my warning about making /SS and output? SEE THE DATASHEET ON THAT!

What?!! I don't get it! Why do I need the /SS line? If the synchronization is controlled by the master's SCK and the touchscreen controller is the only slave, then why to I need the /SS?

I saw in the datasheet that the master can output a high on /SS to signal the end of a data packet to the slave, but I won't be sending anything to the slave. The slave should be sending me information only

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

/SS (or /CS) in SPI signals to the slave device that a new transmission is about to happen and that it should pay attention.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cannot belive how many people can't figure out how SPI works!!! It's it the easiest thing on avr ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

/SS should be set to an output, whether you use it or not. If it is left as an input then if it goes high (perhaps due to noise) the AVR switches to slave mode. (this is in the datasheet, but not highlighted).

Quote:
cannot belive how many people can't figure out how SPI works!!! It's it the easiest thing on avr ?

I'm in the dullard group here. SPI is easy in principle, but punctuated with pitfalls for the unwary in practice. The wide variety of peripherals might be a contributing factor -That's my excuse, and I'm sticking to it!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hehe, true there are some pitfalls when using spi, but fortunately most of them you only do once :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

If the synchronization is controlled by the master's SCK

It is not--see your device's datasheet.
Quote:

but I won't be sending anything to the slave.

Wrong--one could say that in SPI it is >>only<< the master that is sending because the master controls the clock; the slave replies with one bit for each clock.

I did not see anything in the datasheet of your device about a countinuous-conversion/report mode. Perhaps I missed it. The two options that I saw had CS handling as an integral part of the syncronization, and contrary to your assertion the master has to tell the device what to do.

HEED MY WARNING about the /SS pin on the AVR, and READ THAT SECTION--that is why you don't see clocks, because the AVR is turning into a slave.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.