logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

DS1820 nie odpowiada na reset z AT90S2313 – testowane różne czasy, assembler

prok 28 Mar 2005 20:02 1533 9
REKLAMA
  • #1 1356330
    prok
    Poziom 11  
    Posty: 11
    Zakupiony przeze mnie DS1820 po poprawnym podlaczeniu do AT90S2313 nie odpowiada. Po ustawieniu lini na LOW przez min 480 us DS czeka 15-60 us potem odpowiada stanem niskim. Probowalem roznych czasow resetow nawet 960 us w kazdym przypadku gdy zwalnialem linie czekajac na odpowiedz DS - a nie bylo zadnego odzewu - po podciagnieciu do 5V pozostawala w tym stanie. Bardzo prosze o sugestie co mozna z tym jeszcze zrobic.
    Czy ktos moze wypowiedziec na temat jak czesto pojawiaja sie nowe wadliwe czesci?

    Dodam jeszcze ze program pisalem w assemblerze, probowalem rowniez gotowych takze z tego forum.
  • REKLAMA
  • REKLAMA
  • #3 1356359
    elektryk
    Poziom 42  
    Posty: 11029
    Pomógł: 439
    Ocena: 241
    A pod który port podłączasz i jak jest on skonfigurowany?
  • REKLAMA
  • #4 1356452
    prok
    Poziom 11  
    Posty: 11
    DS1820 podpinam do 4 pinu portu B. W makrze BusHigh ustawiam mozliwosc "podciagania" lini, a w BusLow - pin 4 jest wyjsciowy.
    Czasy sie zgadzaja bo sprawdzalem w symulatorze avr studio.
    Dodam jeszcze ze DS1820 jest zasilany dodatkowa linia. Rezystor podciagajacy dalem zgodnie z zaleceniami 4,7 kOhm. Podciaganie dziala - sprawdzalem.

    Oto kod:

    .include "2313def.inc"
    
    .EQU DS1820 = 4
    
    .MACRO BusLow
    
     	sbi DDRB, DS1820
     	cbi PORTB, DS1820
    
    .ENDMACRO
    
    .MACRO BusHigh
     	sbi PORTB, DS1820
     	cbi DDRB, DS1820 
    .ENDMACRO 
    
    
    Start:
    	ldi r16,RAMEND         	
    	out spl,r16				;stos
    
    Loop:
    	BusLow					
    							
    	ldi r16,215
    	rcall Delay
    	ldi r16,215
    	rcall Delay
    	ldi r16,215					
    	rcall Delay				;czekaj 489 us
    
    	BusHigh					
    
    	ldi r16, 19				;czekaj 16 us
    	rcall Delay	
    							
    
    WaitForDS1820:			
    	in r16, PINB
    	sbrc r16, DS1820		;jesli odpowiedzial to idz dalej
    	rjmp WaitForDS1820	
    
    	rjmp Loop
    
    Delay:						;(r16 * 3 + 7)/4 = ilosc mikrosekund
    	subi r16, 1
    	brne Delay
    	ret
    
  • #5 1356488
    LordBlick
    VIP Zasłużony dla elektroda
    Posty: 5438
    Pomógł: 549
    Ocena: 69
    prok napisał:
    Czasy się zgadzaja bo sprawdzalem w symulatorze avr studio.

    Jak to sprawdzasz ? Mi nigdy się nie udało w symulatorze AVRSimulator (AVRStudio) zasymulować czasu rzeczywistego, a AT90S2313 nie ma DebugWire, ani JTAG. Do generowania opóźnień proponuję użyć przerwania Timer0 Overflow, tak skonfigurowanego, aby było zależne od stałej Xtal, która definujesz na początku dyrektywą
    #define Xtal 400000
    Daje to efekt uniwersalności, nie trzeba za dużo zmieniać w kodzie przy podmianie oscylatora kwarcowego na inny o innej wartości. Zakładam, że masz najnowsze AVRStudio...
    Po czym poznajesz, czy odpowiedział, czy też nie ? Nie dopatrzyłem się w kodzie żadnej szczególnej sygnalizacji.
    Light-I
  • REKLAMA
  • #6 1356550
    prok
    Poziom 11  
    Posty: 11
    Zapomnialem dodac ze to wszystko hula na 4 MHz

    Nie sprawdzam w czasie rzeczywistym ale ile mikrosekund trwalaby instrukcja lub ich ciag. Symulator przeciez mierzy ilosc taktow zegara oraz ile uplynalo czasu.

    Jezeli chodzi sprawdzanie to robilem to przez port szeregowy.

    Celowo wycialem te fragmenty kodu zeby nie zaciemniac kodu.

    Wewnatrz petli WaitForDS1820 wysylalem zawartosc portu PINB na terminal procedura serout. Wykazalo to petle nieskonczona czyli DS nie odpowiedzial stanem niskim. Dowodem na to bylo fakt ze "bardziej znaczacy" NIB byl caly czas liczba nieparzysta bo PIN 4 jest pierwszym z drugie NIB-a

    
    Serial:
    	sbi             ucr,txen                ;enable UART transmitter
    	sbi             ucr,rxen                ;enable UART receiver
    	ldi             r16,25 		          ;set baud rate
    	out             ubrr,r16
    	ret
    
    Serout:
    	out             udr,r16         	 ;load UART data register
    serout1:
    	sbis            usr,udre        	;if UART data register empty bit is clear
    	rjmp            serout1                ;loop back
    						      ;else return
    	ret
    
  • #7 1356575
    LordBlick
    VIP Zasłużony dla elektroda
    Posty: 5438
    Pomógł: 549
    Ocena: 69
    He, he, ciekawe jak ja to zrobiłem, że zgadłem, jakiego kwarcu używasz... ;)
    To na serialu 9600bps niczego nie dowodzi, bo twoja procedurki mają podstawową wadę : dużo jest miejsc, w których procek miele w kółko, nic nie robiąc, a być może akurat wtedy "oskarżony" DS1820 udziela odpowiedzi...
    Light-I
  • #8 1356681
    prok
    Poziom 11  
    Posty: 11
    Rzeczywiscie mogloby nastapic przeoczenie odpowiedzi DS-a bo przy 9600 jeden bajt przesylany jest w okolo 1 ms jesli dobrze licze.
    Jednak probowalem juz roznych metod m. in. takiej ze obserwowalem czy wyszedl z petli WaitForDS1820 wysylajac cokolwiek na terminal po wyjsciu z tej petli a wewnatrz niej tylko sprawdzalem stany na pinie 4. Zreszta po to ta petla jest zrobiona zeby sie dowiedziec czy DS wogole odopowiada.
  • Pomocny post
    #9 1356781
    LordBlick
    VIP Zasłużony dla elektroda
    Posty: 5438
    Pomógł: 549
    Ocena: 69
    No cóż, jak dla mnie to 2 sprawy do przerobienia :
    1. Pomiar czasu na Timer0 - jakaś parka bajtów w SRAM, służąca za licznik, który co przerwanie zmniejsza swoją wartość do zera, ale się nie przekręca. Jak chcemy zmierzyć czas, to cli, zapis licznika, sei i już tylko sprawdzamy czy licznik jest wyzerowany, a w międzyczasie program może wyskoczyc do pętli głównej, robić coś pożytecznego, zamiast "mielić" w miejscu.
    2. Analogicznie przy "sbis USR, UDRE" - niech robi swoje w petli głównej, do póki nie można będzie coś wysłać, dałbym nawet mały buforek danych do wysłania i odpowiednią procedurkę do kompletu.
    Może wycinek kodu z mojej procedurki (ATmega8515) coś podpowie:
    #ifdef RS232_DEBUG_TXD
    .dseg
    TxBuff:
    .byte 0x40
    cTxBuff:
    .byte 0x01
    lpSendTxBuff:
    .byte 0x02
    .cseg
    USARTTxInit:
    	sts cTxBuff, TempD
    	ldi TempA, LOW(TxBuff)
    	sts lpSendTxBuff, TempA
    	ldi TempA, HIGH(TxBuff)
    	sts lpSendTxBuff+1, TempA
    	ret
    USARTTx:
    	sbis UCSRA, UDRE
    	rjmp USARTTxEnd
    	lds TempA, cTxBuff
    	tst TempA
    	breq USARTTxEnd
    	lds XL, lpSendTxBuff
    	lds XH, lpSendTxBuff+1
    	ld DataByte, X+
    	out UDR, DataByte
    	sts lpSendTxBuff, XL
    	sts lpSendTxBuff+1, XH
    	dec TempA
    	sts cTxBuff, TempA
    USARTTxEnd:
    	ret
    #endif

    Wywołanie :
    W rejestrze TempD (r13 - tak sobie ponazywałem... ;) ) - długość tekstu wpisanego do TxBuff
    Działanie : podprocedurka pętli głównej, jak transmisja zajęta, to wraca i nic nie wysyła, można tu dorobić dodanie czegoś do bufora i zwiekszenie licznika ilości danych do wysłania cTxBuff
    --------------
    Abstrachując od UART-a, możesz chyba pod jakiś wolny pin podpiąć LED+rezystorek i niech ona się zaświeci, jeżeli DS odpowiada... ;)
    Light-I
  • #10 1356915
    prok
    Poziom 11  
    Posty: 11
    Bardzi dziekuje za pomoc - DS1820 juz odpowiada. Rzeczywiscie zrodlem problemu bylo przesloniece czasowe odpowiedzi DS-a przez transmisje szeregowa.

Podsumowanie tematu

LABEL_AI_GENERATED
Problem dotyczył braku odpowiedzi czujnika DS1820 na sygnał reset generowany przez mikrokontroler AT90S2313. Po prawidłowym podłączeniu i zastosowaniu zalecanego rezystora podciągającego 4,7 kΩ oraz odpowiednich czasów resetu (min. 480 µs), DS1820 nie sygnalizował stanu niskiego, co wskazywało na brak odpowiedzi. Kod sterujący był napisany w assemblerze, a testy czasów wykonywano w symulatorze AVR Studio, jednak pomiary w czasie rzeczywistym nie potwierdzały działania. Problemem okazało się zakłócenie sygnału odpowiedzi DS1820 przez transmisję szeregową UART 9600 bps, która powodowała opóźnienia i przeoczenie sygnału. Po zastosowaniu pomiaru czasu opartego na przerwaniu Timer0 oraz optymalizacji obsługi transmisji szeregowej (buforowanie i asynchroniczne wysyłanie danych) czujnik zaczął poprawnie odpowiadać na reset. Dyskusja podkreśliła znaczenie precyzyjnego pomiaru czasu i unikania blokujących pętli w kodzie mikrokontrolera podczas komunikacji z urządzeniami 1-wire.
Podsumowanie AI na podstawie dyskusji. Może zawierać błędy.
REKLAMA