[Programowanie] SPI - szeregowy interfejs urządzeń peryferyjnych.

Elektryk0 · Sierpień 24, 2009

Interfejs SPI używany jest do komunikacji między mikrokontrolerami AVR lubi innymi urządzeniami jak zewnętrzne pamięci EEPROM, zewnętrzne przetworniki analogowo - cyfrowe, czujniki itp. Może więc nam się przydać przy budowie robota dlatego warto zapoznać się z nim bliżej by móc potem bez większych problemów wykorzystywać go w budowanych konstrukcjach.

Urządzenia komunikujące się za pomocą interfejsu SPI dzieli się na dwie podstawowe grupy. Pierwsze to urządzenia Master ( Wyższy ), które inicjują i kontrolują wysyłanie danych oraz urządzenia Slave ( Niewolnik ), które odbierają dane wysyłane przez Master'a ale mogą je do niego także w tym samym czasie wysyłać. Zazwyczaj w prostych rozwiązaniach mamy jeden układ typu Master, który wysyła i odbiera dane od jednego lub kilku układów typu Slave.

Najważniejszą część interfejsu SPI stanowi 8-bitowy rejestr przesuwny, który występuje zarówno w urządzeniu skonfigurowanym jako Master jak i Slave oraz sygnał zegarowy generowany przez urządzenie Master.

A oto jak przebiega transmisja. Powiedzmy, że Master chce wysłać do układu Slave jakiś bajt nazwijmy go M oraz odebrać od niego również pewien bajt danych nazwijmy go S. Zanim rozpocznie się komunikacja oba urządzenia umieszczają swoje bajty w swoich rejestrach przesuwnych. Zostało to przedstawione poglądowo na rysunku poniżej M0..M7 oznaczają kolejne bity bajtu M podobnie ma się sprawa z bajtem S.

Następnie Master generuje 8 pulsów zegara na linii SCK i zawartość rejestru przesuwnego Master'a ( bajt M ) jest wysyłany w takt pulsów zegarowych do Slave oraz w tym samym czasie nadchodzi do Master'a bajt wysyłany przez Slave ( bajt S ). Po pierwszym impulsie zegar sytuacja wygląda tak jak na obrazku niżej.

Po następnym impulsie zegarowym mamy taką sytuację.

Po 8 pulsach zegara Master ma bajt S a Slave bajt M.

To, że transmisja zachodzi w tym samym czasie w obu kierunkach nazywa się w pełni dwukierunkowym transferem danych ( full duplex data transfer ).

W mikrokontrolerach AVR cztery piny są używane przy komunikacji SPI :

- MISO ( Master in Slave out ) - Tą linią Slave przesyła dane do Master

- MOSI ( Master out Slave in ) - Tą drogą docierają dane od Master do Slave

- SCK ( Serial Colock ) - To jest linia na, której generowany jest sygnał zegarowy przez urządzenie Master i odbierany przez Slave, zegar jest niezbędny do poprawnego działania SPI gdyż synchronizuje komunikacje to właśnie w takt zegara przesuwane są poszczególne bity w rejestrach przesuwnych.

- SS' ( Slave Select ) - W zależności od tego jak skonfigurujemy nasze urządzenie jako Master lub Slave ta linia ma różne znaczenia w obu przypadkach :

• SS' dla Slave - Mając w układzie więcej urządzeń Slave niż jedno Master musi mieć możliwość wybrania do którego w danym momencie mają trafić dane a do których nie. Po to właśnie jest linia SS'. Jeżeli SS' jest w stanie wysokim to dany Slave jest niejako nieaktywny i nie odbiera nadchodzących danych natomiast gdy SS' jest w stanie niskim to jest aktywny i nadchodzące dane będą odbierane o ile SPI został poprawnie skonfigurowany. Program Master'a musi kontrolować SS' każdego Slave tak by wysyłać dane tylko do wybranych urządzeń w danym momencie.

• SS' dla Master – W tym przypadku mamy jeszcze dwie możliwości w zależności od tego czy pin SS' skonfigurowano jako wejście czy jako wyjście. Jeżeli SS' jest skonfigurowane jako wyjście to czy jest w stanie niskim czy w stanie wysokim nie wpływa na interfejs SPI jest on w obu przypadkach aktywny. Natomiast gdy SS' jest wejściem to musi być trzymane w stanie wysokim by urządzenie pracowało jako Master. Gdy natomiast wystąpi sytuacja, że na SS' będącym wejściem pojawi się stan niski zostanie to zinterpretowane tak jakby inny Master wybrał naszego Master'a jako Slave i rozpoczął z nim komunikacje. Taka sytuacja ( więcej niż jeden Master w układzie ) jest niebyt ciekawa i o ile to nie potrzebne lepiej jej unikać. Jeżeli jest nam to niepotrzebne lepiej konfigurować SS' Master'a jako wyjście wtedy będziemy mieli pewność, że sytuacje tego typu nie wystąpią.

W przypadku gdy mamy w układzie tylko jedno urządzenie Slave nie musimy się martwić implementowaniem w programie dla Master'a możliwości przestawiania stanu SS' Slave gdyż i tak nie mamy, żadnego wyboru bo Slave jest tylko jeden. Można wówczas na stałe dołączyć linie SS' Slave do masy wówczas będzie on stale gotów do komunikacji z Master'em. Natomiast pin SS' urządzenia Master można pozostawić niepołączony należy jednak zadbać by był wyjściem gdyż wtedy to w jakim jest stanie ( wysokim czy niskim ) nie ma znaczenia i w obu przypadkach SPI jest aktywne o czym już wyżej wspomniałem. Gdyby był wejściem to nieprzewidziane zmiany stanu mogą skutecznie zablokować komunikacje wystarczy by w jakiś nieprzewidziany sposób stan zmienił się na SS' Master'a na niski i SPI nie będzie działać poprawnie. Pozostałe linie łączymy tak jak na rysunku niżej.

Gdy natomiast mamy 2 lub więcej Slave'ów musimy mieć możliwość wybrania jednego konkretnego Slave'a gdy będziemy chcieli wysłać dane tylko do niego. Jak już wiadomo linia SS' w stanie niskim powoduje, że Slave jest aktywny i może komunikować się z Master'em natomiast SS' w stanie wysokim powoduje, że Slave jest nieaktywny i nie odbiera ani nie wysyła, danych. Najprościej więc do wyboru Slave posłużyć się dodatkowymi pinami układu Master podłączonymi do SS' Slave'ów i zmieniając ich stan na wysoki blokować dane Slave'y a na niski uaktywniać je. Pomocny może okazać się poniższy rysunek.

Należy tutaj zauważyć, że nazwy MISO, MOSI, SCK, SS' są używane w mikrokontrolerach AVR ale inne urządzenia np. zewnętrzne EEPEROM'y mogą mieć te nazwy inne należy więc sprawdzić w dokumentacji danego urządzenia jak nazywają się odpowiedniki powyższych i z nimi je połączyć.

To czy piny używane podczas komunikacji SPI są wejściami czy wyjściami zależy od tego czy urządzenie skonfigurowano jako Master czy jako Slave. Są tutaj dwie możliwości albo mamy narzucone, ustawienie danego pinu jako wejście albo kierunek pinu musi być ustalony przez programistę zgodnie z tym jaką funkcje pełni. Pomocna może być poniższa tabela.

Przed przystąpieniem do analizy kodu przykładowych programów należy jeszcze podać minimum informacji na temat rejestrów sterujących SPI tak aby kody były dla wszystkich zrozumiałe.

Do sterowania interfejsem SPI w mikrokontrolerach AVR ATmega8 służą 3 rejestry SPCR, SPSR oraz SPDR. Nie będę na razie podawał znaczenia wszystkich bitów danych rejestrów podam tylko te niezbędne do zrozumienia kodów reszta zostanie uzupełniona później.

Na pierwszy ogień weźmy rejestr SPCR ( SPI Control Register )

będą nas tu na razie interesować następujące bity :

- SPE ( SPI Enable ) - Bit ten musi być ustawiony kiedy chcemy używać interfejsu SPI gdyż ustawienie tego bitu powoduje po prostu włączenie interfejsu SPI.

- SPIE ( SPI Interrupt Enable ) – Bit ten ustawiamy kiedy chcemy aby przerywania pochodzące od interfejsu SPI były włączone jeżeli nie chcemy korzystać z przerywań bit powinien mieć wartość 0. Należy pamiętać, że aby korzystać z przerywań należy w rejestrze SREG ustawić wcześniej bit I co czyni w asemblerze instrukcja sei a w C funkcja sei().

- MSTR ( Master / Slave Select ) - Nadanie bitowi wartości 1 powoduje, że urządzenie pracuje jako Master natomiast nadanie mu wartości 0 powoduje pracą urządzenia jako Slave.

- SPR1 i SPR0 – Bity te służą do konfiguracji częstotliwości sygnału zegara SPI generowanego przez Master'a na linii SCK. Jeżeli urządzenie skonfigurowano jako Master to można zmieniając wartości tych bitów ustawiać dzielnik przez, który zostanie podzielona częstotliwość oscylatora mikrokontrolera i tak otrzymaną częstotliwość będzie miał sygnał zegarowy generowany przez Master. Z racji, że dane są przesyłane w takt zegara zmieniając wartości bitów a co za tym idzie częstotliwość zegara SPI można zmieniać szybkość przesyłanych danych. Należy zauważyć, że jeżeli urządzenie skonfigurowano jako Slave to ustawienie tych bitów nie ma znaczenia gdyż Slave tylko odbiera sygnał, który generuje Master. Nie można jednak zapomnieć o ograniczeniach narzucanych przez sam sprzęt, które powodują, że częstotliwość zegara SPI nie może być większa niż fosc / 4 gdyż wtedy dane nie będą poprawnie odbierane. Poniższa tabelka przedstawia możliwości ustawienia dzielnika za pomocą bitów SPR1 i SPR0.

Pora na rejestr SPSR ( SPI Status Register )

na razie będzie nas interesował tylko bit SPIF tego rejestru.

- SPIF ( SPI Interrupt Flag ) - Jest to bit, który można tylko odczytywać nie można więc go ustawiać lub kasować programowo gdyż to sprzęt nim steruje. Jest on ustawiany przez sprzęt kiedy transfer SPI dobiegnie końca . Jest on kasowany przez sprzęt kiedy zostanie zgłoszone przerywanie od SPI ( SPI_STC ) i zaczyna się procedura jego obsługi lub jest kasowany wtedy gdy nastąpi odczytanie bitu SPIF i zawartości rejestru SPDR.

Na koniec rejestr SPDR

- Do tego rejestru zapisujemy dane do wysłania przez Master lub Slave oraz z tego rejestru odczytujemy nadchodzące dane po stwierdzeniu końca komunikacji, do czego może posłużyć wyżej opisana flaga SPIF lub przerywanie SPI_STC. Po poprawnym zainicjowaniuinterfejsu SPI wystarczy tylko wpisać do tego rejestru wartość do wysłania aby transmisja została rozpoczęta.

Teraz przejdziemy do części praktycznej zostaną przedstawione dwa proste przykłady użycia interfejsu SPI. Pierwszy z nich prezentuje użycie interfejsu SPI w bardzo prosty sposób. Drugi na przykładzie urządzenia Slave pokazuje wykorzystanie przerywania SPI_STC ( Spi Transfer Complete ) do wykrycia końca transmisji danych. Żeby móc przetestować pokazane przykłady wystarczy złożyć następujący prosty układ :

Gdybym się pomylił lub o czymś zapomniał przy rysowaniu schematu to napisze jeszcze słowami, że w sumie nie chodzi o nic więcej jak tylko połączenie ze sobą pinów MISO, MOSI, SCK obu układów pin SS' Slave łączymy z masą a do jego PortuD dołączamy diody ledukłady oczywiście podłączamy do napięcia 5V i dodajemy kondensatory odsprzęgające o wartościach C4 i C3 100nF ceramiczne oraz C5 i C6 10uF elektrolity natomiast reset łączymy z vcc przez rezystor 10k i z minusem przez kondensator 100nF.

Układ jest dość prosty a dane, które będzie otrzymywał Slave od Master'a są wyświetlane na 8 diodach połączonych do pinów portu D. Możemy dzięki temu stwierdzić czy interfejs działa poprawnie i czy wszystko zostało dobrze złożone. Do przykładów wykorzystano 2 AVR'y Atmega8 i na takich właśnie mikrokontrolerach kody będą działać poprawnie przy stosowaniu innych należy zgodnie z dokumentacją zmienić część kodu. Układ testowy został złożony na płytce stykowej ale oczywiście można go także złożyć na płytce uniwersalnej lub na płytce drukowanej. Programy zostały napisane w 2 językach programowania w AVR Asemblerze i AVR – GCC.

Pierwszy program ( animacja ) działa tak, że na diodach led wyświetlane są kolejne bajty wysyłane przez Master te bajty to nic innego jak coraz większe ( o jeden ) liczby od 0 do 255 z racji, że master po wysłaniu bajtu odczekuje ok. 1 sekundy efektem jest prosta animacja. Najpierw kody dla urządzenia Master.

Wersja ASM

.include "m8def.inc" 
.cseg
.org 0x000 rjmp Start

Start: 
ldi r16, low( RAMEND ) 			
out SPL, r16
ldi r16, high( RAMEND ) 
out SPH, r16

Inicjajcja_spi: 
ldi r16, ( 1 << PB3 )|( 1 << PB5 ) | ( 1 << PB2 )   		         //MOSI, SCK, SS' jako wyjścia
out DDRB, r16							
ldi r16, ( 1<<SPE )|( 1<<MSTR )|( 1<<SPR0 ) | ( 1 << SPR1 )	//Włączamy SPI, układ Master 
out SPCR, r16					            //Najmniejsza częstotliwość SCK fosc / 128 
ldi r19, 0

main:							  //Pętla nieskończona
out SPDR, r19				                  //Wysyłamy zawartość r19 	
inc r19					                  //Zwiększamy wartość w r19 o 1	
Czekaj_na_wyslanie:	                                  //Oczekujemy na zakończenie transmisji ( do ustawienia SPIF ) 
sbis SPSR, SPIF				                  //Przez sprzęt
rjmp Czekaj_na_wyslanie 
ldi r16, 250					          //Czekamy ok. 1 sek
rcall Czekaj
ldi r16, 250
rcall Czekaj
ldi r16, 250
rcall Czekaj
ldi r16, 250
rcall Czekaj
rjmp main	 	

Czekaj:				                         //Procedura opóźniająca o 1 * r16 [ ms ] 
P2: 
ldi r17, 10
P1: 
ldi r18, 25
P0: 
nop
dec r18
brne P0
dec r17
brne P1
dec r16
brne P2
ret

Wersja C

#define F_CPU 1000000UL
#include<avr/io.h> 
#include<util/delay.h> 


void Inicjacja_spi() 
{ 
DDRB = ( 1 << PB5 ) | ( 1 << PB3 ) | ( 1 << PB2 );	          //MOSI, SCK, SS' jako wyjścia
SPCR = ( 1 << SPE ) | ( 1 << MSTR ) | ( 1 << SPR1 ) | ( 1 << SPR0 );   //Włączamy SPI, 	
}			                                                                   //układ Master, najmniejsza częstotliwość SCK fosc / 128


void Wyslij_spi(char bajt) 
{ 
SPDR = bajt;					//Wysyłamy zawartość zmiennej bajt	
while( ! bit_is_set( SPSR, SPIF ) );		//Oczekujemy na zakończenie transmisji ( do ustawienia SPIF ) przez sprzęt
}							

int main() 
{ 
char bajt = 0; 
Inicjacja_spi(); 
while(1)				//Pętla nieskończona
{ 
	Wyslij_spi(bajt); 
	_delay_ms(250);		//Czekamy ok. 1 sek
	_delay_ms(250); 
	_delay_ms(250); 
	_delay_ms(250); 
	bajt++;				//Zwiększamy wartość w bajt o 1
} 
return 0; 
}

Teraz kod dla Slave

Wersja ASM

.include "m8def.inc" 
.cseg
.org 0x00

Inicjajcja_spi: 
ldi r16, ( 1 << PB4 ) 			//MISO jako wyjście		
out DDRB, r16			
ldi r16, ( 1 << SPE )			//Włączamy SPI
out SPCR, r16				

ldi r17, 0xff				//Cały PortD jako wyjście	
out DDRD, r17					
ldi r17, 0x00				//W stanie niskim	
out PORTD, r17

main:								
sbis SPSR,SPIF		//Czekamy na koniec transmisji danych ( do ustawienie flagi SPIF	 ) 
rjmp main				        
in r16, SPDR 			//Wpisujemy to co przyszło od Master do r16		
out PORTD, r16		//Wysyłamy to na PortD ( diody led )			
rjmp main			//I tak bez końca

Wersja C

#include<avr/io.h> 

void Inicjacja_spi() 
{ 
DDRB = ( 1 << PB4 );		//MISO jako wyjście	
SPCR = ( 1 << SPE );			//Włączamy SPI
} 

char Odbieraj_spi() 
{							//Czekamy na koniec transmisji danych
while ( ! bit_is_set( SPSR, SPIF ) );	 	// ( aż do ustawienie flagi SPIF	 ) 
return SPDR;					//Zwracamy to co dostaliśmy do SPDR
}							//Czyli to co wysłał Master

int main() 
{ 
DDRD = 255; 
PORTD = 0; 
Inicjacja_spi(); 
while(1) 
{ 
	char bajt = Odbieraj_spi(); 
	PORTD = bajt;			//Wysyłamy to co dostaliśmy od Master'a na 
}						//PortD ( diody led ) 
return 0; 
}

Programy nie są trudne ale warto przenieść je na język ludzki na listę czynności które wykonują tak by widzieć co po kolei należy zrobić by wysyłać dane przez SPI.

Master

1. Najpierw inicjujemy SPI ustawiając MOSI ( PB3 ) , SCK ( PB5 ), SS' ( PB2 ) jako wyjścia co jest zrozumiałe gdyż sygnał zegarowy generuje Master a Slave go odbiera więc jeśli u Slave jest on ustawiany jako wejście zgodnie z wcześniejszą tabelką to u Master pasuje by był wyjściem podobnie ma się rzecz z MOSI a co do SS' to już było pisane, że ustawienie jako wyjście pozwala nam unikać przykrych sytuacji. Ta część wymaga zmian przy innych mikrokontrolerach bo mogą one mieć MISO, MOSI, SCK, i SS' na innych pinach niż Atmega8.

2. W dalszej części inicjacja ustawiamy odpowiednie bity w rejestrze SPCR czyli SPE ( włączamy SPI ) MSTR ( układ to Master ) SPR0 i SPR1 ustawiają najmniejszą częstotliwość SPI fosc / 128 co pozwala zminimalizować ryzyko zakłóceń do minimum i być może oszczędzić niektórym niepotrzebnych nerwów.

3. Następnie program wysyła bajt do Master rozpoczęcie wysyłania jest równoznaczne z wpisaniem bajtu do rejestru SPDR.

4. Następnie odczekujemy na koniec transmisji danych chodź nie jest to w 100 procentach potrzebne gdyż program i tak czeka potem 1 sekundę ale co nam szkodzi

robimy to poprzez oczekiwanie na zmianę stanu SPIF na 1 co zrobi sprzęt gdy transmisja bajtu dobiegnie końca gdy to się stanie możemy już wysyłać kolejny bajt.

Slave

1. Najpierw inicjujemy SPI ustawiając MISO ( PB3 ) jako wyjście.

2. W dalszej części inicjacji włączamy SPI ustawiając bit SPE

3. Wpadamy w pętle w której oczekujemy na koniec transmisji ( odebranie danych od master ) o czym da znać bit SPIF mający wartość jeden.

4. Jeśli SPIF ma wartość jeden oznacza to, że dane dotarły i możemy je odczytać gdyż są teraz w rejestrze SPDR więc i to robimy.

Teraz druga wersja programu robi w sumie to samo co pierwsza tyle, że urządzenie Slave wykorzystuje przerywanie SPI_STC do wykrycia końca transmisji danych. Kody dla Master są w tym przypadku takie same zmienia się tylko kod dla Slave. Oto one :

Wersja ASM

.include "m8def.inc" 
.cseg 
.org 0x000 rjmp Start
.org 0x00A rjmp SPI_Int

SPI_Int:			//Ten kod zostanie wykonany po zgłoszeniu przerywania SPI_STC
in r16, SPDR			//Pobieramy wartość wysłaną przez Master
out PORTD, r16		//Wysyłamy na PortD ( wyświetlamy ją na diodach led ) 
reti

Start: 
ldi r16, low( RAMEND ) 
out SPL, r16
ldi r16, high( RAMEND ) 
out SPH, r16
sei					//Włączamy przerywania

ldi r16, ( 1 << PB3 )				//Inicjacja Slave jak poprzednio
out DDRB, r16
ldi r16, ( 1 << SPIE ) | ( 1 << SPE )		//Włączamy przerywania i interfejs SPI
out SPCR, r16

ldi r16, 0xff
out DDRD, r16
ldi r16, 0x00
out PORTD, r16

main: 
rjmp main

Wersja C

#include<avr/io.h> 
#include<avr/interrupt.h> 

ISR(SPI_STC_vect)			//Kod wykonywany po zgłoszeniu przerywania SPI_STC 
{ 
char bajt = SPDR;		//Pobieramy wartość wysłaną przez Master
PORTD = bajt;		//Wysyłamy na PortD ( wyświetlamy ją na diodach led ) 
} 

void Inicjacja_spi()		
{ 
DDRB = ( 1 << PB4 );		//Jak poprzednio
SPCR = ( 1 << SPIE ) | ( 1 << SPE );	//Włączamy przerywania i interfejs SPI
} 

int main() 
{ 
DDRD = 255; 
PORTD = 0; 
Inicjacja_spi(); 
sei();				//Włączamy przerywania
for (;;); 
return 0; 
}

W sumie nie ma tu wielkich różnic więc nie ma co się rozpisywać bo przecież tłumaczenie jak obsługiwać przerywania nie należy do tego tematu i wszyscy powinni już to wiedzieć chyba, że są tacy co zaczynają stawiać dom od dachu. Wiedzieć należy jednak to, że po zgłoszeniu przerywania od SPI program skacze do adresu 0x00A, natomiast w C powinniśmy do funkcji obsługującej przerywania podać nazwę SPI_STC_vect . W sumie jedyną nowością jest ustawienie w rejestrze SPCR bitu SPIE, który włącza przerywania od SPI.

Na razie tyle ciąg dalszy nastąpi wkrótce.

Deimos · Sierpień 24, 2009

Super w końcu ktoś to zgrabnie opisał 😃

Fajne rysunki pomagające załapać o co kaman nie to co surowy wygląd eagla 😃

kodjak · Sierpień 16, 2010

W attiny2313 nie ma nóżki SS. Czy wobec tego jest jakiś sposób aby użyć go jako SLAVE ?

Nawyk · Sierpień 17, 2010

Z tego co mi wiadomo, to w Attiny2313 nie ma SPI, tylko USI.. (140 strona pełnej noty katalogowej)

The USI Three-wire mode is compliant to the Serial Peripheral Interface (SPI) mode 0
and 1, but does not have the slave select (SS) pin functionality. However, this feature
can be implemented in software if necessary.

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

wsowa · Sierpień 17, 2010

Ino te tabelki powykrzywiane niepotrzebnie.

kodjak · Sierpień 17, 2010

W takim razie czy ktoś wie jak programowo zrobić SS z dowolnej nóżki ?

Pytam o samą idee, nie o kod.

albercik506 · Lipiec 6, 2011

Witam, uruchomilem ten program na atmedze 8 (slave) i atmedze 32 jako master. Przesylanie jest, ale... To wyglada tak jakby liczby wyswietlane na porcie byly przypadkowe. Próbowałem ustawic tylko 1 bit na porcie slave'a zeby zapalic diode i znowu mruga caly port. program jest napewno poprawnie skonstruowany? jakies sugestie czemu sie tak dzieje?

[ Dodano: 06-07-2011, 19:53 ]

zastanawiam sie czy moze zasilanie z programatora ma jakis wplyw na to co sie pokazuje na porcie...

miszczo · Lipiec 7, 2011

W takim razie czy ktoś wie jak programowo zrobić SS z dowolnej nóżki ?
Pytam o samą idee, nie o kod.

Tak.

Jeżeli nie chcesz używać sprzętowego spi-jakiego nie ma attiny możesz zrobić programowe. Wtedy dowolnie wybierasz za co odpowiedzialne są poszczególne porty.

albercik506 · Lipiec 7, 2011

dochodze do wniosku ze to co pokazuja mi diody to sygnaly z programatora, a transmisji miedzy atmegami nie ma:/ ma ktos jakies pomysły czemu transmisja nie dziala?

Bobby · Lipiec 7, 2011

Sprawdzasz przy wypiętym programatorze?

Grzesieq94 · Lipiec 8, 2011

A jeśli mój SLAVE to zewnętrzna pamięć EEPROM to też muszę EEPROMA jakoś zaprogramować, czy on już jest niejako sam zaprogramowany?

miszczo · Lipiec 8, 2011

Jeżeli kupiłeś nowy - a zapewne tak zrobiłeś - to musisz go zaprogramować, żeby móc odczytać pożądane dane. Z czystego odczytasz same F.

Grzesieq94 · Lipiec 8, 2011

Oczywista oczywistość, ale mi chodzi o to czy musisz wsadzić do EEPROMU kawałki kodu przeznaczone do SLAVE tak jakbyś to zrobił dla uC będącego SLAVEM czy po prostu programujesz tam od razu dane bez żadnego inne kodu?

miszczo · Lipiec 8, 2011

Nie musisz nic "wsadzać". Programujesz od razu. Przecież eprom to nie uC - dla niego kod to zwykłe dane.

Grzesieq94 · Lipiec 8, 2011

No i oto mi właśnie chodziło 😉 Dzięki wielkie

[Programowanie] SPI - szeregowy interfejs urządzeń peryferyjnych.

Pomocna odpowiedź

Link do komentarza

Share on other sites

Link do komentarza

Share on other sites

Link do komentarza

Share on other sites

Link do komentarza

Share on other sites

Polecacz 101

Link do komentarza

Share on other sites

Link do komentarza

Share on other sites

Link do komentarza

Share on other sites

Link do komentarza

Share on other sites

Link do komentarza

Share on other sites

Link do komentarza

Share on other sites

Link do komentarza

Share on other sites

Link do komentarza

Share on other sites

Link do komentarza

Share on other sites

Link do komentarza

Share on other sites

Link do komentarza

Share on other sites

Dołącz do dyskusji, napisz odpowiedź!

Najnowsze posty w innych tematach