ATmege8 as SPI master - Receiving and transmitting

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

Hi all

This is my first post and my first project with an Atmel AVR, so be gentle with me :D

I am trying to interface a CC2500 radiocip that uses SPI. The CC2500 is in slave mode so the AVR has to be in master mode.

When I have to send data to the chip i first have to send an address and then the actual data. When the master sends the address or the data the CC2500 chip at the same time sends status bits i would like to read. Are these automaticly received by the ATmega8's SPI interface so that I only have to read the receive buffer?

Another senario is when i would like to read data from the CC2500 chip. In this case I have to write the address I would like to read from to the CC2500 (and again the CC2500 sends status bits while i am transmitting these). When the adress is transmitted the CC2500 sends the data from the register.

Have a look the the data sheet for the CC2500 at page 19, figure 6. It explains it much better than I can:

http://www.chipcon.com/files/CC2...

So to sum up, my questions are:
-How do I receive data while sending data?
-How do i receive data from the slave while the ATmega8 is in master mode?

There are code examples in the data sheet for the ATmega8, that shows how to send while in master mode and receive while in slave mode, but not receive while in master mode (and not while sending at the same time).

Hope you guys can help me out!! Thx

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

It is quite easy
When You are in master mode and You send a byte over SPI then in the same time slave sends a byte to You. So... if You want to receive some data just send some :) . After sending a byte read SPI data register - this value would be a byte from slave device

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

Well that makes sense. If only they would have said that in the data sheet for the AVR...

Thanks.

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

Well that makes sense. If only they would have said that in the data sheet for the AVR...

Thanks.

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

Quote:

If only they would have said that in the data sheet for the AVR...

Quote:
The system consists of two Shift Registers, and a Master clock generator. The SPI Master initiates the communication cycle when pulling low the Slave Select SS pin of the
desired Slave. Master and Slave prepare the data to be sent in their respective Shift Registers, and the Master generates the required clock pulses on the SCK line to interchange data. Data is always shifted from Master to Slave on the Master Out – Slave In, MOSI, line, and from Slave to Master on the Master In – Slave Out, MISO, line. After each data packet, the Master will synchronize the Slave by pulling high the Slave Select, SS, line.

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

I haven't read you device's datasheet, but be aware that some devices require you to send an "extra" dummy byte for it to send back the answer, because the device needs to get your entire the command to be able to give an answer, so it only answers in the byte after the command has been completely sent (look at any AVR serial programming datasheet section (Serial Programming Instruction Set table); the last byte of each command is dummy, it serves only the purpose of retrieving the device's answer). Check your device's datasheet.

Embedded Dreams
One day, knowledge will replace money.

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

Just read SPDR after SPIF was set or SPI interrup.And SCLK generates after SPDR was written.
I have some pictures about the SPI's timing that I pohotgraphied on oscillograph.If you want ,just send mail to me.

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

Quote:
I haven't read you device's datasheet, but be aware that some devices require you to send an "extra" dummy byte for it to send back the answer, because the device needs to get your entire the command to be able to give an answer, so it only answers in the byte after the command has been completely sent (look at any AVR serial programming datasheet section (Serial Programming Instruction Set table); the last byte of each command is dummy, it serves only the purpose of retrieving the device's answer). Check your device's datasheet.

Listen to this wise man. Some slave spi devices require clocks even before trying to communicate with them. Read the datasheets very carefully.
Kostas

It's better to keep your mouth shut and think you a fool, than open it and move out the doubts!

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

Treat those devices with cookies ! :-) :-)

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Thx for all your replies, I have now got the SPI communication up and running with the CC2500 chip. I works like a charm.

The idea is with this project that i am to be able to send data from a PC to the USART via the COM port on the computer. This is also working now and in essense what I have is a an RS232 to SPI converter.
Now what I would like to have is an in- and output FIFO buffer at the USART so that the data from the computer is stored in the in-FIFO and and the data from the CC2500 is stored in the out-FIFO. This way there is some buffering in place both ways.

Isn't there an application note describing how to implement this in C? I am pretty sure there are, but I haven't been able to find it. (yes I have googled for it)
Are there some place where all the application notes are collected?

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

Found it. Is it really that easy? Guess so

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

please give me the source code of what u have done .. i am working on the same "interfacing cc2500 with atmega8" .. send me at joy_shukla@yahoo.in

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

You post a request to somebody that made totally 5 posts (all in that thread) 5 years ago.
Don't set your hopes too high for an answer.

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

hmmm....

that cc2500 chip looks quite interesting..
Is there anyone with a 'working' code to play with .. ??

Thanks..

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

draxos wrote:
hmmm....

that cc2500 chip looks quite interesting..
Is there anyone with a 'working' code to play with .. ??

Thanks..

I' also looking for an RF-comms module/unit. At this moment the CC2500 looks like the best bet for me if you consider price and availability.

I would like to start playing with it in the next month or two, first have to work through some other tutorials etc before I can even consider taking on the wireless comms.

Keep in touch,