Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
Two part question:
In the datasheet on page 168, the best SCK frequency one get get on SPI is \$\dfrac{f_{osc}}{2}\$, why can't this be \$f_{osc}\$?
Also from the datasheet: "When the SPI is configured as Slave, the SPI is only guaranteed to work at \$\dfrac{f_{osc}}{4}\$ or lower". Why?
Assuming faster electronics costs more money (in design time, testing, manufacturing costs, chip area, etc.), then I would expect Atmel's designers to trade reduced cost for reduced performance? Especially if there is feedback from customers that they aren't willing to pay a price premium for highest speed SPI?
A technical result might be driven by balancing cost and profit.
Typically, a MCU runs from it's own clock source; it is asynchronous with respect to other clock sources. Internally, it's SPI peripheral is synchronous with its own clock.
An SPI slave must lock to the external clock of a different asynchronous device. One way to do this is to 'sample' the external clock synchronously with the ATmega328's internal clock, two or more times for each state. This ensures the falling and rising edge of the external clock signal can't be confused.
If the slave were running at \$\dfrac{f_{osc}}{2}\$ there would only be time to take two samples of the external clock (synchronised with its own clock).
So that would imply one high and one low; the master clock is in an unknown state between samples. If the two systems were drifting with respect to each other the external clock signal might appear to jitter with long and short durations for the slave, making synchronisation fragile (which no one would like to deal with), or more complex (extra cost). It may be harder (more expensive) to make a system which can sample at higher than the systems clock to avoid this.
However with two, or more highs and two or more lows, they will stay broadly in-synch; the state of the master clock is known definitively between two highs and two lows, so for those periods there is no clock error between the master and slave.
So a way to 'know' that your synched, for part of the time, is see the external clock in the same state two or more times, hence the 4x slower.
