Only SPI modes 0 and 1 supported by Attiny84 USI?

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

Just now reading more fine print in the ATTiny84 spec.  I think I can only do SPI slave in modes 0 or 1 using the USI module.

 

Seems that way after reading AVR319 too.

 

It's not a show stopper, but the SPI master is also communicating with a device using mode 2.  So, I'll have to dynamically change the SPI on the master device (rpi), when I want it to communicate with my Attiny84.

 

Just looking for a confirmation of that--(or not).

 

Thanks!

Last Edited: Sat. Jan 12, 2019 - 09:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Changing SPI on the fly is not a big deal. I have a mico-SD card and an accelerometer on the same SPI bus and they are in different modes.

 

Fortunately, the master knows which mode to use just as it knows which chip select line to assert.

 

Jim

 

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

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

Yes, I know how to change SPI on the fly on the RPI.  But, simpler is always better, and it seems simpler to just have the slaves in the same mode.

 

Looking for confirmation of the fact (or not) that the ATTiny 24/44/84 only supports SPI modes 0 and 1.  If that's true, then I will change modes when I change the CS (using pigpio on the RPI).

 

Thanks,

 

 

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

ka7ehk,

 

Have you done the dynamic SPI mode change on an RPI?  Are the states of the MOSI, SCLK, and CS pins defined between the close of the current channel/spi and open of the new one?

 

Are they floating, or driven to a level?  

 

I'll probably have to dig into the source code for the spiClose and spiOpen functions I'm using.  Hopefully, the spiClose drives both chip selects high, but that would tie up both chip selects in applications where only one is needed.  

 

 

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

Have just barely started on  RPi. Have not yet learned how to deal with SPI, at all.

 

Jim

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

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

Ok, I posted the question on a pigpio forum.

 

An older post raised on that forum an issue where some SPI signals glitched when simply changing channels (chip selects).  It would be easy enough to control the chip selects via bit banging, but the code has been fixed anyway..

 

If the attiny84 CAN be configured in mode 2, I need only worry about changing the chip selects, which I see has been done many times. 

 

Not so sure about supporting slaves in different modes.   That's probably much less common.

 

Of course, I can do my own bit-banging, but it might be easier to get Attiny in spi mode 2 (if that's possible). 

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

You should have full mode choice if you bit-bang SPI on the Tiny. Just be aware of slower max SPI clock rate (than hardware).

 

Jim

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

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

Looked at the source at spiOpen and spiClose.

 

Could be that I don't do spiClose then spiOpen to change channels/modes, but rather do multiple spiOpens and use the associated handles that are returned for communicating with the different slaves.

 

I added a second spiOpen to my code which is spi communicating in spi mode 2 to another device.  I added the second open in mode 0 and the second channel (chip select) AFTER the existing spiOpen.  Communication with the first device still works fine.

 

So, I'm optimistic that it is indeed simple to support slaves in different spi modes from the rpi.  I'll update if I get it working with the attiny and/or things look good on the logic analyzer (or post my woes).

 

Thanks!

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

Everything looks good on the logic analyzer.  I can do two spiOpens, each with a different spi channel and mode.  So, a handle for reading and writing is available for each slave.  They don't have to be on the same spi mode, and, of course, different select lines are associated with each handle

 

The existing SPI slave still works fine.  Haven't done an actual SPI transaction with the Attiny yet (have to remove the logic analyzer probes before I can reprogram the Atmel), but the spi write looks good.  Clock idles low (mode 0) instead of high (mode 2) when I use the handle for the Attiny.

 

Thanks for your attention.

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

I have an ATTINY861 with USI hung on an ATMEGA1284's SPI buss with a bunch of other things. I am concerned that USI is NOT compatible with SPI in either mode 1 or 0.

Look at waveform diagram 13.3 for USI 3-wire mode in ATTINY861 spec and compare with the same thing for SPI in figre 16.4 of the ATMEGA1284 spec. 

In SPI mode 1 in figure 16.4, the clock starts low. The first rising edge is ignored and the output data is good on the first falling edge.

Compare with figure 13,3 for USI: In the mode starting with clock low, the data is sampled on the first rising edge. Exactly the opposite.

Now pretty much everything esle in the world actually uses the other clock polarity: Clock starts high, the firrt falling edge is ignored, and data is sampled

on the rising edges. In figure 16.4 fo the SPI spec, this called mode 3 ?

 

Is the USI diagram wrong or is this a big blunder ?

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

On re-checking it seems that, whatever mode it is called,: the mode that starts with clock low and samples data on the first rising edge is compatible with both SPI and USI and that is what other devices seem to use too.