0
\$\begingroup\$

I plan on using a barebones Atmega168 running an Arduino sketch to drive two stepper motors and a heater. To interface with the steppers and heater I want to use 4 PWM pins. I will also have an SPI connection to a host controller so that the host can request a certain amount of steps at a given speed or demand that the heater be heated to a given temperature. To drive the stepping action I will need an interrupt every 100 micro seconds or so.

Now to do this I will probably need and open timer channel (or am I wrong), I know my 4 PWM pins will be using 4 of the 6 available timer channels, but will the SPI be using any and possibly cause some issues?

\$\endgroup\$
  • \$\begingroup\$ It's hard to take a question seriously when the title reads like gibberish. \$\endgroup\$ – Olin Lathrop Nov 15 '13 at 21:10
3
\$\begingroup\$

The SPI module has its own baud rate generator so it does not consume any of the timers. And the baud rate generator is only used in SPI master mode. In slave mode, it is synchronized to the clock of the external master. The only issue you may have with SPI is dealing with the data byte in a timely fasion as it is not possible for a slave to delay SPI like it is with I2C.

\$\endgroup\$
  • \$\begingroup\$ Thanks, could you just elaborate on what you mean when you say that I will not be able to deal with it in a timely fashion? \$\endgroup\$ – Gerharddc Nov 15 '13 at 18:09
  • 1
    \$\begingroup\$ It really depends what you need to do with the data. Whatever task you need to do with the data bye, it must be complete before the transmission of the next byte is complete. \$\endgroup\$ – Matt Young Nov 15 '13 at 18:19
  • \$\begingroup\$ In the case of temperature reading I plan on having a value ready for immediate reading and in the case of stepper commands I plan on buffering up the received bytes and then executing the entire command upon slave deselect, could that work? \$\endgroup\$ – Gerharddc Nov 15 '13 at 18:24
3
\$\begingroup\$

It's not necessary to worry about the SPI module using up a timer. A bigger issue is that most controller's slave peripherals are not designed to make them behave in the ways that most non-processor slave devices work. On a bidirectional SPI connection using a typical slave peripheral, the time between when the master releases /CS and when it reasserts it, the time between when it asserts /CS and when starts clocking data, and the time between when the master finishes clocking one byte and when it starts to clock the next byte, must all be greater than the worst-case time for the slave's controller to respond to those events. There's no way for the master to find out when the slave is ready for something; instead, the master must blindly wait some length of time, and the must always handle each event within that time frame.

Because of these timing requirements, designing reliable SPI slave devices is often annoyingly difficult. If other interrupts have priority over SPI-related interrupts (including rising-edge and falling-edge detect on /CS), it may be difficult to ensure that SPI events are always handled fast enough to meet the worst-case timing constraint. If the SPI interrupts have priority, it may be difficult to avoid having SPI communications cause timing jitter in those other interrupts.

Personally, I don't think there's any particular reason chip vendors shouldn't be able to design SPI peripherals that would allow the master to ask at any time whether a slave was ready for more communications, without needing any blind delays, but I'm unaware of any which do.

\$\endgroup\$

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.