Witam.
Chciałem się pobawić eepromem i zaserwowałem sobie taką zabawę, że hej. Mam problem z odczytem. Najlepiej wkleję troszkę kodu.
Teraz procedury, które są używane w kodzie:
Sprawdzałem, czy coś się dzieje. Wychodzi na to, że już po starcie układ się wiesza. Prawdopodobnie na sprawdzaniu TWINT. Patryłem na to dłuższy czas i doszedłem do wniosku, że w manualu do Atmegi8 dziwnie piszą. Czytałem do czego jest TWINT i tam jest napisane, że bit jest ustawiany. Jak mam to rozumieć, tak jak oni później w przykładzie, że jest tam 1, czy jak oni napiszą dalej, żę The TWINT Flag must be cleared by software by writing a logic one to it., czyli musi być wyczyszczona przez zapisanie tam 1. Jak oni chole*** piszą te posrane datasheety. A w przykładzie jest na odwrót. Nie czaję tego. Normalnie już sobie włosy wyrywam.
Ale powracając do tematu. Już jak napisałem po wysłaniu komendy start. Wiesza mi się uC prawdopodobmnie na instrukcji twi_busy, czyli sprawdzaniu znacznika TWINT.
Pozdrawiam i proszę o pomoc.
Jeszce jedna ważna uwaga. Nie piszcie mi, że to było poruszane na forum. Może i było ale w c i w bascomie. A do asemblera się nie dokopałem. Swoją drogą bascom to język strasznie głupkowaty. C już mniej. Bo nie ma tej "genialnej" obsługi wszystkiego co bascom, że można by zmusić uC do zrobienia kanapki. Takie małe rączki wyjdą i ciach, kanapka .... To tak na poboczu
.
Chciałem się pobawić eepromem i zaserwowałem sobie taką zabawę, że hej. Mam problem z odczytem. Najlepiej wkleję troszkę kodu.
clr r16
ldi r16, (1 << TWPS0)
out TWSR, r16
ldi r16, 12
out TWBR, R16
sbi PORTC, PC5
sbi PORTC, PC4
rcall twi_start
rcall twi_set_write
ldi TWI_REGISTER, 0x50
rcall twi_send_device_address
ldi r17, 0x00
ldi TWI_REGISTER, 0x00
rcall twi_send_address
;restart
rcall twi_start
rcall twi_set_read
ldi TWI_REGISTER, 0x50
rcall twi_send_device_address
rcall twi_disable_acknowledgment
rcall twi_read_data
mov EEPROM_DATA, TWI_REGISTER
rcall twi_stop
Teraz procedury, które są używane w kodzie:
;wylaczanie flagi potwierdzen
twi_disable_acknowledgment:
in TWI_REGISTER, TWCR
cbr TWI_REGISTER, 1 << TWEA
out TWCR, TWI_REGISTER
ret
;wysylanie STARTU
twi_start:
ldi TWI_REGISTER, (1 << TWINT) | (1 << TWSTA) | (1 << TWEN) | (1 << TWEA)
out TWCR, TWI_REGISTER
rcall twi_busy
;wylaczamy start
in TWI_REGISTER, TWCR
cbr TWI_REGISTER, (1 << TWSTA)
out TWCR, TWI_REGISTER
;koniec, powracamy
ret
;ustawiamy sie na odczyt
twi_set_read:
ldi r16, 0x01
;zapisujemy to tymczasowo w rejestrze danych do wyslania przez twi
out TWDR, TWI_REGISTER
ret
;ustawiamy sie na zapis
twi_set_write:
;dla zapisu wartosc to 0
clr TWI_REGISTER
out TWDR, TWI_REGISTER
ret
;wysylamy adres uzadzenia
twi_send_device_address:
;adres uzadzenia
;przesowamy w lewo poniewaz musimy ustalic, czy jest to operacja odczytu, czy zapisu
lsl TWI_REGISTER
out TWAR, TWI_REGISTER
;pobieramy dazne z rejestru, jest tam jeden bit, odpowiedzialny za zapis/odczyt
;czy bedziemy odczytywac z, czy zapisywac do uzadzenia
push r17
in r17, TWDR
;suma logiczna, pozwala nam to na otrzymanie operacji zapisu, badz odczytu
or TWI_REGISTER, r17
;wysylanie adresu
pop r17
rcall twi_send_data
ret
;wysylamy dane
twi_send_data:
;zapis do rejestru danych
out TWDR, TWI_REGISTER
in TWI_REGISTER, TWCR
sbr TWI_REGISTER, 1 << TWINT
;wysylamy dane na zlacze
out TWCR, TWI_REGISTER
rcall twi_busy
;konczymy wysylanie danych
ret
;ustawianie adresu z, ktorego bedziemy czytac, lub, do ktorego bedziemy zapisywac
twi_send_address:
;wysylanie msb adresu
;tutaj przypisanie adresu do rejestru !!!
rcall twi_send_data
mov TWI_REGISTER, r17
rcall twi_send_data
ret
;operacja odcytywania bajtu
twi_read_data:
;dajemy sygnal do odczytu
in TWI_REGISTER, TWCR
sbr TWI_REGISTER, 1 << TWINT
out TWCR, TWI_REGISTER
rcall twi_busy
;odczytujemy dane
in TWI_REGISTER, TWDR
ret
twi_stop:
;odczytanie bierzadzej zawartosci rejestru kontrolnego twi
in TWI_REGISTER, TWCR
;ustawienie bitu stopu i przerwania
sbr TWI_REGISTER, (1 << TWSTO) | (1 << TWINT)
;wysylamy nasze ustawienia
out TWCR, TWI_REGISTER
;czekamy na zakonczenie operacji
rcall twi_busy
;wylacamy interfejs twi
cbr TWI_REGISTER, 1 << TWEN
out TWCR, TWI_REGISTER
;wyslano stop, powracamy do programy
ret
;sprawdznaie czy interfejs TWI jest zajety
twi_busy:
;wczytanie rejestru kontrolnego
in TWI_REGISTER, TWCR
;porownanie bitu przerwania TWINT, jesli czysty
sbrs TWI_REGISTER, TWINT
;to omijamy skok do ponownego sprawdzenia
rjmp twi_busy
;powrot
ret
Sprawdzałem, czy coś się dzieje. Wychodzi na to, że już po starcie układ się wiesza. Prawdopodobnie na sprawdzaniu TWINT. Patryłem na to dłuższy czas i doszedłem do wniosku, że w manualu do Atmegi8 dziwnie piszą. Czytałem do czego jest TWINT i tam jest napisane, że bit jest ustawiany. Jak mam to rozumieć, tak jak oni później w przykładzie, że jest tam 1, czy jak oni napiszą dalej, żę The TWINT Flag must be cleared by software by writing a logic one to it., czyli musi być wyczyszczona przez zapisanie tam 1. Jak oni chole*** piszą te posrane datasheety. A w przykładzie jest na odwrót. Nie czaję tego. Normalnie już sobie włosy wyrywam.
Ale powracając do tematu. Już jak napisałem po wysłaniu komendy start. Wiesza mi się uC prawdopodobmnie na instrukcji twi_busy, czyli sprawdzaniu znacznika TWINT.
Pozdrawiam i proszę o pomoc.
Jeszce jedna ważna uwaga. Nie piszcie mi, że to było poruszane na forum. Może i było ale w c i w bascomie. A do asemblera się nie dokopałem. Swoją drogą bascom to język strasznie głupkowaty. C już mniej. Bo nie ma tej "genialnej" obsługi wszystkiego co bascom, że można by zmusić uC do zrobienia kanapki. Takie małe rączki wyjdą i ciach, kanapka .... To tak na poboczu
.
. Mniemam, że tego datasheeta pisała kobieta. A wiadomo, że kobieta zmienną jest....
, a zasada działania pozostaje tylko w PDF'kach 
