My standard SD card module uses four pins: SDCS, MOSI, SCK, and MISO. However, I can only dedicate two pins of my ATtiny85 to operate it. Is there a way I can do this without using more ICs, such as for example a second, bigger microcontroller?

Keep in mind that:

  • I only need to write to it.
  • I can do as much testing as necessary at start, but then it has to work on its own with only two pins.
  • I can add one or two discrete electronic components, as long as they're few and small.
  • The other pins are taken by a GPS module, which uses serial (RX-TX), and a crystal.
  • 2
    \$\begingroup\$ GPS module probably only needs RX. \$\endgroup\$ – Turbo J Aug 14 '15 at 20:15
  • \$\begingroup\$ ATTiny85 has 6 GPIO. Two for GPS (and probably only need RX like TurboJ said). That leaves 4 or 5 pins. What are you leaving out? \$\endgroup\$ – Karl Bielefeldt Aug 14 '15 at 20:35
  • \$\begingroup\$ Sorry, I forgot. Another two pins are taken by a crystal. Could I get rid of it and use the GPS module's provided time to correct the inaccuracy of it's internal oscillator?. \$\endgroup\$ – AvidScifiReader Aug 14 '15 at 21:04

Scenario 1:

You still need to read the file allocation table from the SD card unless:

you use your own RAW SD card format

Then you don't need the MISO pin. So instead of four pins for the SD card, you need three. It is possible to set a fuse in ATtiny85 that will

turn the reset pin to a regular I/O pin.

Now you have three pins you can use to talk to the SD card. You won't be able to use an ICSP programmer after you do that.

Scenario 2:

Share SD card pins with GPS.

Connect the RX pin with SCK. When you talk to the SD card, the GPS will receive garbage and will ignore it. When you talk to the GPS, keep the CS pin high and the SD card will ignore it. Connect the TX pin via a 10k resistor to the MOSI pin. When you talk to the SD card, use the MOSI pin as output. Communication won't get disrupted by the GPS, because it's behind the resistor. When you need to listen to the GPS, keep the MOSI pin as input and CS high. The SD card will ignore stuff coming from te GPS on that pin.

Scenario 3:

A combination of the above

Scenario 4:

Just use ATtiny84; it's almost the same as ATtiny85 with more pins and the same footprint in a QFN package anyway, if you care about size.


This will likely not work using a reduced SPI interface. You might be able to use an I2C to SPI bridge chip, but the parts are not cheap and likely 'big' for your design.


Simple method:

This type of SPI bus can share pins with other SPI devices. MISO, MOSI, and SCK are shared, and each component will need its own CS line. Do you have other SPI devices in your design that can share the SD card's bus?

Other method:

On some SPI devices the CS line can be tied low so that the bus is always enabled. However, most require a down-edge on the CS line to mark the beginning of data transfer, and an up-edge to signal the end of a command.

  • If you can tie the CS low, then that omits one pin.

  • If you are only writing then you can omit the MISO line. But are you truly only writing? There are generally read operations as part of the overhead, if only to verify that the SD card is available/seated/etc.

  • The SCK and MOSI are always necessary.

It just might work :) But if your device needs the CS toggling, then I don't see a straightforward way to have what you want.

  • \$\begingroup\$ The other device on my system is a GPS module, and it uses serial (RX-TX) :( \$\endgroup\$ – AvidScifiReader Aug 14 '15 at 19:10
  • 1
    \$\begingroup\$ You cannot tie down CS for SD cards and expect them to work. They also need MISO. \$\endgroup\$ – Turbo J Aug 14 '15 at 20:10

Ditch the crystal. The internal oscillator is plenty accurate for sampling a 9600 baud serial signal from the GPS, and you're mastering the clock on the SPI interface, so timing isn't critical there either. If you're looking for an accurate wall clock timestamp for logging, it's hard to beat a GPS signal. Yes, you can use it to correct drift. However, even without that, internal oscillators are usually "good enough," unless you're doing a precision autopilot or something like that.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.