SPI confusion

[dougal]

Can somebody clarify the status of hardware SPI on the DigiSpark? The ATTiny85 specs mention it, the product description on the Digistump web site mention it, but I see posts all over the forums saying that it's not supported.


What's up with that?

[semicolo]

Not sure, the I2C works and it uses the same pins as SPI, so SPI should work, maybe it's just the core software that doesn't support it, I'll have a look in the sources.

[semicolo]

Tried to build an SPI example, looks like this library need some rewrite to work with the digispark, the tiny SPI registers must have different names than the Mega328

[semicolo]

Alright to use SPI you have to set up the USI (Universal Serial Interface) to work in 3 wire mode, so this is quite different from the Mega328 which have serial and SPI and I2C on the same device, the digispark only has one peripheral used as serial xor I2C xor SPI.
It shouldn't be too hard to make a compatible SPI library though.

[dougal]

Thanks for looking into it. I just hadn't had time to actually try to play with it myself, yet.


I had hoped to have some project time last weekend, but that was shot when some friends of ours had their house destroyed by a tornado.    (no people hurt, fortunately, but a 200 year old oak tree fell over onto their house)


If it's just a library issue (which was my guess), I'm sure the existing code won't be hard to adapt.

[defragster]

I'm interested in SPI working as well - the above suggests using SPI would preclude I2C it looks like as the dedicated pins are shared.  Either way interested if there is a solution.

[Bluebie]

Absolutely right - we just need a library for it. The ATtiny85 and most other tiny's don't have hardware spi, uart, i2c, or OneWire support. Instead they have a Universal Serial Interface device, which can be set to send out and read in data in various ways - clocked by a clock input, or by a timer, on one wire or two, or a bunch of other configurable possibilities. It is possible to configure the USI interface to fit the specification of uart, spi, or i2c, but the tiny85 has only one USI device, so it can do only one of these at a time.


I think there hasn't been so much effort to support SPI in hardware because SPI tends to take 3-4 pins for most sorts of devices - these devices tend to also be available in i2c form, which require only two pins, and two-wire SPI (data out + clock) devices like chainable LED drivers tend to require special clocking that has resulted in almost all the libraries for these devices being written as bitbang code which already works without hardware SPI support.


Really SPI is such a simple protocol, I wouldn't be surprised it bitbang SPI ended up being more compact in terms of sketch size than hardware assisted. The main benefit of hardware assisted SPI is increased speed.


Another neat thing you can do with the USI instead of all this stuff is connect it's 4-bit counter to another timer's overflow, creating a 12-bit counter.

[TimO]

I've been using SPI on Teensy's quite extensively, because I've got a spacecraft EGSE (Electronics Ground Support Equipment) that talks to our MAGIC magnetometer using SPI, since for simplicity the only digital electronics on our card is the ADC, and the spacecraft talks SPI directly to our card.

MAGIC on CINEMA-TRIO at Imperial College London

Looking at the ATTiny85 datasheet, it doesn't look that involved to get the USI SPI working, although as has been said, it'll have limited functionality with so few pins available on the device overall.  The datasheet has some example code, admittedly in assembler, but it's probably better turned into some C for a "proper" Arduino library, if only for clarity.  I doubt it would end up being significanly larger than hand written assembler, or not enough to worry about.

When we use SPI, we connect a PC to the Teensy using the USB, and amazingly that would still be possible here, since the USB interface uses PB3 and PB4, whereas the SPI would connect to PB0, PB1 and PB2 (MISO,MOSI, and SCLK respectively).  Of course, as others said, most people don't use SPI with something like a DigiSpark, because it's heavier on pin usage than I2C, but there are devices out there which are not available in I2C versions, so occasionally SPI is likely to be needed.  With a dedicated SPI link, the SS line isn't necessary, so you've still got three lines to do other stuff with, although more than one serial protocol is not an option, without resorting to bit banging.

The DigiSpark couldn't take our EGSE program however, since it only just fits on the Flash of a 32K Teensy 2 (I'm switching over to using Teensy 2+'s for that reason), partly because it includes Bitlash, so we can write scripts on it.  A very heavily cut down version would probably work though, and I'm tempted to try it, simply out of curiosity!  I may have to borrow one of the lab's small scopes to bring home, so I can watch the SPI lines and experiment next weekend.

Initially I think I'd probably only bother to get the Master code working, since I've only ever bothered to use Slave mode as an experiment, with two boards talking to each other.  Worth a fiddle I think (unless one of the other posters in this thread has already succeeded).

Has anyone tried to use USI as a serial interface? (or for that matter, does the soft serial library work on a DigiSpark?)

[digistump]

TinySoftSerial included with our IDE version works well.

There is a rough example of SPI using USI in our RFM12B example - also included with the IDE

[TimO]

I haven't got around to trying to get the SPI working yet, but since I'm considering using the Adafruit Digital RGB LED Weatherproof Strip 32 LED on a bicycle POV (the NeoPixels apparently don't work well for this, because of their refresh rate), I'll need to sort out a working SPI library, and going the USI route is likely to be better than using bit banging.  The LPD8806 doesn't look like it's quite standard SPI (as far as there is a standard for SPI!), but I think it's close enough that the USI talking SPI will work with it (the main discrepancy seems to be that it doesn't have a SS or CS line, which can just be ignored in this case).