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
normalnie ustawia się go jako wyjście, a potem zmienia jego stan poprzez
modyfikowane wartości PORTx. Jeśli potrzebujemy dodatkowego sygnału CS,
wybieramy pierwszy wolny pin GPIO.
Jeśli w ten sposób będzie mi łatwiej poprowadzić ścieżkę, mogę
zignorować sugestię producenta i wybrać inny pin? A może ta sugestia nie
wzięła się znikąd i warto trzymać się domyślnego pinu CS?

2) Jaką funkcję pełni tutaj rezystor R2 270 om na linii MISO?
http://tuxgraphics.org/common/src2/article06061/eth-
remote-device.pdf
Na innych schematach ten element bardzo często nie występuje, bez
względu na to czy mówimy o podłączaniu ENC28J60, karty pamięci czy
innego elementu. To jakieś zabezpieczenie? Mogę go pominąć, jeśli w ten
sposób wygodniej będzie prowadzić ścieżkę?

BTW, istnieje może jakiś odpowiednik ENC28J60 na 5V?

do góry

On Sun, 2014-04-06 at 09:55 +0200, Atlantis wrote:
> 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
> normalnie ustawia się go jako wyjście, a potem zmienia jego stan poprzez
> modyfikowane wartości PORTx. Jeśli potrzebujemy dodatkowego sygnału CS,
> wybieramy pierwszy wolny pin GPIO.
> Jeśli w ten sposób będzie mi łatwiej poprowadzić ścieżkę, mogę
> zignorować sugestię producenta i wybrać inny pin? A może ta sugestia nie
> wzięła się znikąd i warto trzymać się domyślnego pinu CS?

Jeśli sterujesz pinem CS ręcznie, to nie ma znaczenia którego użyjesz

>
> 2) Jaką funkcję pełni tutaj rezystor R2 270 om na linii MISO?

Pozwala programować AVRa przez SPI. gdyby go nie było, ENC wymuszałby
stan na tej linii, gdyby PB2 było w stanie niskim, powodując błędy
programowania


> BTW, istnieje może jakiś odpowiednik ENC28J60 na 5V?

dokładnego nie ma, są inne kontrolery.
z datasheeta: "The ENC28J60 is a 3.3V part; however, it was
designed to be easily integrated into 5V systems. The SPI CS, SCK and SI
inputs, as well as the RESET pin, are all 5V tolerant." więc konwersję
poziomów trzeba zrobić w jedną stronę tylko, tragedii nie ma.

@

do góry

W dniu 2014-04-06 11:19, Artur Miller pisze:

> Jeśli sterujesz pinem CS ręcznie, to nie ma znaczenia którego użyjesz

A w ATmegach są jakieś inne opcje? ;)


> Pozwala programować AVRa przez SPI. gdyby go nie było, ENC wymuszałby
> stan na tej linii, gdyby PB2 było w stanie niskim, powodując błędy
> programowania

Hmm... A to nie jest przypadkiem tak, że gdy CS jest w stanie wysokim,
to ENC się nie wtrąca do tego, co dzieje się na magistrali?
Po resecie co prawda MCU przestawia piny na wejścia w stanie wysokiej
impedancji, ale zewnętrzny pull-up do VCC wciąż utrzymuje CS w stanie
wysokim. W takiej sytuacji ENC nie powinien mieć swojego MISO
ustawionego na High Z?


> designed to be easily integrated into 5V systems. The SPI CS, SCK and SI
> inputs, as well as the RESET pin, are all 5V tolerant." więc konwersję
> poziomów trzeba zrobić w jedną stronę tylko, tragedii nie ma.

Nie ma. Po prostu zastanawiałem się czy nie zrobili jakiejś wersji na 5V
- zawsze trochę mniej komplikacji. Swoją drogą kontrolery CAN od
Microchipa są nieco bardziej tolerancyjne jeśli chodzi o dopuszczalne
poziomy napięcia...

do góry

On Sun, 2014-04-06 at 11:41 +0200, Atlantis wrote:
> W dniu 2014-04-06 11:19, Artur Miller pisze:
>
> > Jeśli sterujesz pinem CS ręcznie, to nie ma znaczenia którego użyjesz
>
> A w ATmegach są jakieś inne opcje? ;)

nie pamiętam, dawno przestałem się nimi bawić :) sentyment pozostał,
więc obecnie na biurku leży AVR32, a tam jest opcja "auto CS".



> > Pozwala programować AVRa przez SPI. gdyby go nie było, ENC wymuszałby
> > stan na tej linii, gdyby PB2 było w stanie niskim, powodując błędy
> > programowania
>
> Hmm... A to nie jest przypadkiem tak, że gdy CS jest w stanie wysokim,
> to ENC się nie wtrąca do tego, co dzieje się na magistrali?
> Po resecie co prawda MCU przestawia piny na wejścia w stanie wysokiej
> impedancji, ale zewnętrzny pull-up do VCC wciąż utrzymuje CS w stanie
> wysokim. W takiej sytuacji ENC nie powinien mieć swojego MISO
> ustawionego na High Z?

powinien. ot, dodatkowe zabezpieczenie w razie wroga pewnie.

@

do góry

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.

--
Michał

do góry

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.


Pozdrawiam

Marek
--
"If you want something done...do yourself!"
Jean-Baptiste Emmanuel Zorg

do góry

W dniu 2014-04-06 20:08, Marek Wodzinski pisze:
> On 04/06/2014 06:40 PM, Michał Lankosz wrote:
>> 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.

Znów moja wpadka...

--
Michał

do góry

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

do góry