W dniu 2014-04-06 20:08, Marek Wodzinski pisze:
> On 04/06/2014 06:40 PM, Michał Lankosz wrote:
>> W dniu 2014-04-06 09:55, Atlantis pisze:
>>> Niby ze SPI korzystam dosyć często, ale ciągle zastanawiam się nad
>>> kilkoma kwestiami:
>>>
>>> 1) Pin CS. Istnieje jakiś powód by za wszelką cenę starać się korzystać
>>> z tego sugerowanego przez producenta? W programie przecież i tak
>>
>> ATmega16:
>> When configured as a Master, the SPI interface has no automatic control
>> of the SS line. This must be handled by user software before
>> communication can start.
>> When configured as a Slave, the SPI interface will remain sleeping with
>> MISO tri-stated as long as the SS pin is driven high.
>>
>> Z opisu wynika wręcz, że pin /SS powinien być zarezerwowany dla pracy uC
>> w trybie podrzędnym. Ponieważ w przeważającej większości przypadków
>> pracuje jako nadrzędny wyprowadzenie SS nie jest sprzętowo
>> wykorzystywane. Nazwa trochę sugeruje, że może to być wyjście dla
>> jednego układu podrzędnego więc żeby nie robić bałaganu w nazwach linii
>> często jest ono wykorzystywane do wybierania takiegoż układu.
>
> To jest niestety pół prawdy.
> Cały problem jest w tym, że jeżeli ten pin sobie użyjemy jako wejście i
> będziemy chcieli cały czas być masterem, to niski stan na nim wymusza
> przejście całego spi w tryb slave. Można się niemiło ździwić.
> Opisane jest to kawałek dalej w '/SS Pin Functionality'.
>
> Dlatego dla świętego spokoju lepiej wykorzystywać go do spi, a jeżeli
> nie, to pamiętać, że musi być wyjściem.

Gorzej jak masz kilka układów podpiętych do spi. Wtedy i tak trzeba olać
SS i po prostu chamsko ustawiać konkretne porty do CS.


--
pozdrawiam
MD