use spi inplace of that twi stuff

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

I have an example project that uses that twi code. I think its part of the Arduino wrapper. Its looks like this.

twi_init();
uartInit();// initialize UART (serial port)
uartSetBaudRate(115200);

then to write

data[0] = 0x40;
data[1] = 0x00;
result = twi_writeTo(0x52, data, 2, 1);

So I want to basically use the spi instead. Unfortunately I dont have much experience yet using it. My only use of it is a single byte.

spi_mSend(0x52);
static char spi_mSend ( char data)
{
/* Start transmission */
SPDR = data;
while(!(SPSR & (1<<SPIF)));
_delay_us(100);
return SPDR;
}
Can it be used like the twi?

these are the twi parameters

address: 7bit i2c device address
data: pointer to byte array
length: number of bytes in array
wait: boolean indicating to wait for write or not

Is spi limited to one byte? Or could one just stack the sends? I'm thinking timing is critical here.

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

You can send (or receive) as much SPI data as you want. Whether timing is critical or not depends on the particular players, but in general, one goal behind synchronous clocking such as SPI is to make timing -less- critical. Most SPI slaves don't care whether they get a clock every microsecond or every day.

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

In this case I'm emulating the host, so its entirely possible I need to send bytes with in a certain set of guide lines. I'm not sure if the twi has any way of setting this ( i.e byte 100 us byte100 us byte.. ). I may just try to send one after the other with a analyzer attached ans see what it takes to get a response.

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

Your only timing controls are the SPI clock rate (prescaler) and the delay between bytes. You DO need to be careful about what you do with the chip select between bytes; keep it in the select state until the end of the complete message.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

ah, so I could hold the select during 3 bytes then release. Isn't the SPDR only 8 bits wide?

guess this may be some help.
https://www.avrfreaks.net/index.p...

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

Yes, the SPDR is only 8 bits. To send, you would assert the select line, write to the SPDR (with prescaler, etc, initialized), wait for the transmit complete flag to be asserted, load the next byte into the SPDR, repeat as many times as needed, then, finally disable the select line.

Of course, I have left out a number of details. There are several control bits that set the idle level of the data output line, and the relative timing to the clock and the data. It is generally recommended to NOT use interrupts unless there is some strange reason that you have to set the clock rate very slow. Just wait in a loop for the transfer complete bit to go true.

The other important fact is that if you have to receive data from a slave, the master has to generate the clock and data, even if it is dummy data. When the SPDR (transmit) is done) the SPDR (receive) will have a byte from the slave to be read.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

TWI bus has the benefit of being open-collector, if a slave device needs time to process the received byte, it can just pull the clock line low for as long as it needs (hint: after receiving a byte the hardware generates the interrupt and software then reads the data and does something with it and says to the TWI hardware that it should start receiving the next byte). This is exactly what makes microcontrollers as TWI slaves different from ASIC chips, you can transfer data as fast as you can if there are no other limitations.

Same thing with SPI. Hardware devices could accept contiguous bytes at preposterous speeds, while the AVR being a slave must generate an interrupt, read the byte, store it somewhere, and be ready to accept the next, but there is no way to signal to the master it should hold back.

So you are in a good position of being the master with AVR, but you must keep the delays between bytes according to specs as well as delays between bits and delays between bytes and chip select events etc.

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

ah.. I see, ok thx Jepael,ka7ehk.