Witam

Otóż robię od 2 dni przykład z niebieskiej książki "Mikrokontrolery AVR Podstawy programowania"

No i napotkałem na taki problem którego nijak przeskoczyć nie umiem, więc postanowiłem opisać go tutaj
Chodzi dokładnie o podrozdział RTC- sprzętowa obsługa I2C

A więc, podłączyłem układ jak na schemacie w książce, jako RTC służy mi PCF8583P (od NXP), kondensator do rezonatora 32.768kHz to 33pF--Vcc. Reszta dokładnie jak na schemacie.

Problem polega na tym że gdy wgram wsad do uC, to na LCD pojawia mi się tylko string "start...", i to wszystko.
Gdy mierze napięcie na INT to mam cały czas stałą wartość napięcia czyli nie ma przerwania.

Nie za bardzo wiem co z tym fantem zrobić. Poniżej kod który wrzucam do procka. Zmieniłem tylko PCF8583_ADDR na 0xA0 ponieważ A0 jest podłączony do GND (sygnalizuje to, bo w książce była literówka i przy A0 do GND w kodzie był adres 0xA2)



Nie wiem w którym miejscu popełniam błąd, więc proszę zgromadzonych tu użytkowników o pomoc

Sprawny RTC powinien generować tam sygnał co 1sek.
Wygląda, że coś jest niesprawny (aż nie chce mi się wierzyć)
Na pewno jest wszystko dobrze podłączone?

Dokładnie jak kolega wyżej pisze. Przy prawidłowym podłączeniu i (sprawnym), PCF powinien dawać oznaki życia na nodze INT. Na szybko podłączyłem się do PCFki żeby sprawdzić (choć z niej nie korzystam) i pięknie miga LEDem co 1s.
Nawet nie trzeba żadnych programów pisać żeby hardware sprawdzić

_________________
Pozdrawiam
PP

Dokładnie - polecam zacząć sprawdzać wszystko naszym "debugerem" jedno-diodowym LED

na początek podłączamy się do wyjścia INT układu RTC - katodą do pinu a anodę przez rezystor do VCC (MUSI migać co sekundę

potem łączymy ten pin do wejścia INT procka i znowu na tym pinie sprawdzamy diodą LED czy miga ..... jeśli nie to może kabelek nie łączy ?

a jeśli tak - to dalej już programowo korzystamy po kolei z debugera LED, czyli w przerwaniu zmieniamy stan diody LED podłączonej do jakiegoś pinu procesora na przeciwny aby sprawdzić czy przerwanie działa itd itd itd

no taka procedura jest już chyba z 5 razy opisana na tym forum, warto je troszkę też poprzeglądać pod tym kątem

.... więc czekamy na info - co wyniknie z tych testów ?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Witam ponownie.

Przyczyna okazała się tak kuriozalnie prosta, że aż mi wstyd.

Otóż, jak wszyscy wiecie, układy scalone numeruje się od lewej do prawej, potem do góry i od prawej do lewej. Nie mam bladego pojęcia dlaczego tak zrobiłem, ale "górną" część PCF-a numerowałem od lewej do prawej. Więc piny od 5 do 8 były zamienione miejscami. Nie wiem co to za pomroczność mnie dopadła bo nigdy takiego czegoś nie odwaliłem, a mając przed oczami datasheet PCF8583 gdzie jest rysunek układu, nie dostrzegłem tego.

Oczywiście gdy podłączyłem PCF-a jak należy, zegarek działa poprawnie.

No cóż... dziękuję wszystkim którzy próbowali pomóc

...ja dołączę się do tego postu, bo problem lekko pokrywa się z moim. Mianowicie kod poniższy się zatrzymuje na TWI_read_buf():



"Debuger LED" wskazuje poprawne przerwanie, napis "int0_flag ustawiona" pokazuje się w konsoli jednak kolejny - "po odczycie..." już nie.
Przeszukałem wszelakie możliwe miejsca występowania problemu, począwszy od warstwy fizycznej i nie widzę błędów. Program kompiluje się poprawnie, nie ma ostrzeżeń itp.

Mogę jakoś inaczej sprawdzić czy ta funkcja TWI_read_buf() się wykonała/wykonuje?

Dziękuję!


Kody w C zamieszczamy przy pomocy [syntax=c] - Zielony J.

jan mazur --> a może przy takiej okazji takim pytaniu zawsze warto napisać na czym ty to testujesz jeśli chodzi o sprzęt ??? to jest elektronika a nie programowanie na PC , gdzie każdy ma taką samą elektronikę pod maską

Pokaż schemat - opisz itp - bo równie dobrze mogłeś babola tu zrobić .... rozumiesz ?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

mirekk36 --> sprzęt to procesor ATMEGA8 z kwarcem 16MHz. Jeśli chodzi o połączenia fizyczne są w porządku. Tak więc tą warstwą bym się nie przejmował.

PCF8583 ************* ATMEGA8

P5 (SDA) ----------- PC4
P6 (SCA) ----------- PC5
P7 (/INT) ---------- PD2

Reszta zgodnie z aplikacją PDF.

Właśnie teraz się zastanawiam nad funkcją i2cSetBitrate(). Czy aby jej wywołanie w postaci i2cSetBitrate(100) dla mojej częstotliwości 16MHz jest poprawne...

P.S. proszę wybaczyć, że nie zaznaczyłem składni kodu w moim poście

Gdybyś miał taktowanie 8MHz to akurat zadziałałoby ci to nawet bez i2cSetBitrate(), tak całkiem przypadkowo. Ale dla większych częstotliwości taktowania już KONIECZNIE trzeba ustawiać prędkość na I2C.

100kHz to akurat standard i wszystkie scalaki I2C muszą go obsługiwać - a ty przy taktowaniu 16MHz wręcz jak mówię MUSISZ to ustawić inaczej będą klopsy.

A nie denerwuj się że pytam o sprzęt bo skąd ja mogę wiedzieć kto jest po drugiej stronie ??? no toż z opisu to nie wynika i nie wiem np czy znasz się na elektronice czy nie ? no skąd mogę wiedzieć .... Więc czemu się niektórzy zaraz urażają gdy pytam o podstawowe rzeczy albo zarzucają mi że ja im zarzucam niewiedzę jakąś ??? nie rozumiem

a przecież wystarczy że np nie dasz rezystorów podciągających linie SDA i SCL i już może ci się DOKŁADNIE w ten sposób transmisja wieszać - Nawet pewnie nie zdajesz sobie sprawy ile już setek razy to samo podpowiedziałem na dokładnie takie samo pytanie. Więc nieraz już lecę z automatu.

Reasumując - im mniej informacji w pytaniu tym bardziej proszę mi wybaczyć jeśli zadaję w drugą stronę może dla ciebie banalne pytania ok ?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

hey Mirek spokojnie, ja się w ogóle nie zdenerwowałem ...ale rozumiem, też tak czasem mam, że jak czytam coś co ktoś napisze (przeważnie moja druga połówla ) i od razu myślę, że się ta druga strona o coś się denerwuje. Jednak doszedłem do wniosku, że to wszystko zależy od tego jak się samemu odbiera to co napisane i ...w jakim się jest nastroju. Tak to jest ze słowem pisanym - raczej nie da się na 100% przekazać emocji.
Tak więc nie przejmuj się mną dziś ustawię ten Bit Rate i mam nadzieję, że to pomoże. Tak w ogóle to mi się śnił ten cały kod i jakieś poprawki w nim za dużo siedzę przed kodem chyba...

No no to już poważne objawy uzależnienia .... trudno - trzeba się z tym nauczyć jakoś żyć ... ja też tak mam i lekarze mówią że nie da się tego zoperować.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

...na szczęście potrafię czasem się oderwać i idę poćwiczyć no ale wracając do tematu widzę, że ustawienie TWBR i TWSR pomogło. Ogólnie z obliczeń wyszło mi, że musi być tam wartość 2(d) przy "Prescaler Value" = 64, tak więc:


pomogło.

Miłego Wieczoru

A możesz sobie zajrzeć do uaktualnienia lekcji 08_TWI ??? tutaj:

http://atnel.pl/uaktualnienia-programow-do-dvd.html

przecież masz piękną funkcję i2cBitrate - którą można pięknie z parametrem wywoływać

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

...piszesz o tym?



no właśnie to nie działa u mnie. Sprawdzałem na poczatku i program zatrzymuje się w miejscu, o którym pisałem na początku. Ogólnie zauważyłem, że układ RTC albo jest mega czuły na częstotliwość transmisji TWI albo "coś nie tak z konfiguracją". U mnie zadziałało dopiero czy ustawiłem na sztywno, jak w poprzednim poście, bity TWSR i TWBR. Zauważyłem, że mimo poprawnych obliczeń i ustawień nie zadziałało coś w stylu:


Jedynie to dało pozytywny rezultat:


Jakoś nie miałem chwili, aby się nad tym zastanawiać czas spędziłem na "zmaganiach" nad parsowaniem stringu na wejściu UART. Podobno jest to opsane w Twojej drugiej książce Mirek. Narazie zastanowię się nad własnym rozwiązanie, a jak wymięknę to zasięgnę do Twego Pewnie masz to napisane w jednej linijce

No ale widzisz - czasem jednak warto się pozastanawiać nad takimi rzeczami, że tak powiem. Dlatego że w ten sposób nie rozwiązałeś problemu a go obszedłeś "jakoś" bokiem. Nie traktuj mojej wypowiedzi jako czepiania się - bo sam się wręcz zastanawiam co się tam u ciebie dzieje i rzuć okiem sobie na wzór z noty PDF:



podstawiając do niego wartości z twoich ustawień wynikałoby, że w przypadku twojej pierwszej próby



chociaż zastanawiam się skąd to wziąłeś - częstotliwość I2C wyszłaby = 307,692 kHz - więc nie dziwne że standardowy układ pracujący na 100 kHz nie ruszy. No to weźmy twój drugi "ręczny" kod:



ile teraz na wyjdzie częstotliwość I2C - policzmy wg wzoru - będzie dokładnie = 58,823 kHz

toż to praktycznie połowa 100 kHz ! więc nie jest dziwne że działa - ale jak może nie działać ta funkcja?



Policzmy dokładnie wg niej, po kolei:

16000000 / 1000 / 100 = 160 i dalej ponieważ bitrate_div >= 16 mamy: (160-16)/2 = 72

więc sprawdźmy jeszcze raz wzór przedstawiony wyżej z wyliczoną wartością TWBR=72 i TWPS=0

16000000/ 16 + 2(72) * 1 = 100 kHz (jak w mordkę strzelił)

A nie spotkałem się z układami szczególnie obecnymi, które działałyby z częstotliwościami taktowania I2C mniejszymi niż 100 kHz. Powiem więcej one zwykle działają nawet i na 200 albo nawet na 250 kHz .... dopiero przy 300 - 400 kHz wymiekają. Więc jeśli już można byłoby mówić że mój układ jest czuły na częstotliwość I2C to w zakresach pomiędzy 150-250kHz czyli sporo większych niż dopuszczalny przez producenta.

Jeśli jednak nie działało ci z tą funkcją na 100kHz czyli:

i2cBitrate( 100 );

to co za problem było sprawdzić mniejszej prędkości pisząc tak:

i2cBitrate( 50 );

przecież uzyskałbyś ten sam efekt co ręcznego grzebania w bitach TWBR i TWPS .... hmmm to jest właśnie to o czym m.in będzie w najbliższym poradniku VIDEO który zamieszczę. Nie o I2C ale o tym, że warto RAZ poświęcić się i zrobić sobie porządne funkcje czy biblioteki, które będą działały zawsze a później już nie musieć do nich zaglądać i zawracać sobie głowy nawet jak działają w szczegółach, niż tak jak ty tu prezentujesz - za każdym podejściem w programie do I2C od nowa rozważać "na randoma" (jak mawia mój syn) .... czy lepiej użyć taką wartość TWPS i TWBR czy inną. Na prawdę warto tak podchodzić do programowania - a nie omijać problemy bokiem ok ? - to taka porada - a nie żadna kąśliwość żebyś mnie źle nie zrozumiał.

aha - a jeśli ci RTC działa źle na 100kHz to weź sprawdź albo powiedz jakie rezystory masz w podciąganiu linii SDA i SCL bo jakoś o nich w ogóle nie napisałeś - już bałem się zapytać - ale zapytam (wybacz) czy je w ogóle masz ? Bo bez nich to co opisujesz to typowy objaw - że spada drastycznie prędkość I2C bo na wewnętrznych (za dużych) rezystorach podciągających zbocza drastycznie się wygładzają.




Oj to byś się zdziwił - nie w jednej linijce - ale z użyciem przede wszystkim zdarzeń (EVENTS) .... wiesz jak się tego używa ? jeśli nie to również zapraszam do najbliższego poradnika VIDEO - bo zobaczysz akurat właśnie przykłady na temat korzystania z EVENT'sów i jaka miodność z tego płynie dla użytkownika

a o jednej linijce zapomnij - jest ich i to dość sporo - ale warto - na prawdę warto (znowu) RAZ A DOBRZE to rozwiązać

bo później można w swoim kodzie szaleć i może być wtedy właśnie tak że używa się po jednej linijce kodu

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Tak więc dla mnie też jest to zastanawiające, bo wiem że nie pasuje TWBR = 2, gdyż powinno być TWBR = 1. Jednak dla tej wartości układ nie wysyłał na UART żadnych danych od RTC. Po zmianie na '2' zadziałało.
Mój 'pseudo kod' z TWSR = 0 i TWBR = 18 był przykładem gdyż pisałem to z pamięci, jednak chciałem zaznaczyć, że mimo iż obliczyłem poprawne wartości i ustawiłem poprawnie rejestry układ nie wysyłał danych. Dopiero metodą "Macajewa" udało mi się uzyskać poprzwne przesłanie danych.
Jeśli chodzi o rezystory to są dwa 4,7k...

Rozumiem doskonale, że pisanie "na szybko" czegoś nie jest dobre, jednak w tym momencie chciałem zobaczyć czy ten układ w ogóle zadziała, oczywiście poprawię to, bo wiadomo że tak nie może zostać no i muszę sprawdzić dlaczego niby poprawne ustawienie rejestrów daje nieoczekiwane rezultaty, bo rzeczywiścię Twój kod na i2cSetBitrate() jest OK ale u mnie nieststey nie zadziałał i to było bardzo zastanawiające.

Jesli chodzi i EVENT'y to nie używałem ale już nie mogę się doczekać kiedy to poznam i będę stosował.

edit: kiedy będzie te VIDEO o EVENT?

właśnie się smaży i gotuje. Będzie na pewno na wigilię jako 14-ta potrawa

mam nadzieję że zdążę

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

...no to czekam (jak pewnie inni) i mam nadzieję, że nie będzie rozwlekły lecz konkretny

przykro mi tego nie mogę zapewnić ... część ludzi narzeka że tworzę rozwlekłe poradniki właśnie - dlatego skoro pytanie/wątpliwość podana dużo wcześniej - przed poradnikiem - to wolę uprzedzić, żeby potem nie dostawać maili, że albo niewyraźnie mówię, albo źle po angielsku mówię, albo że nie mówi się "se" tylko "sobie" albo że nie mówi się "włanczam" tylko "włączam" ..... sorki ale takie maile - już mnie troszkę irytują - bo piszą ludzie zwykle na początku z takim dopiskiem. Ja życzliwie chciałem zwrócić uwagę że nie mówi się tak tylko tak. A tymczasem z uwagi na to że niezbyt wyraźnie mówię to źle słyszą i koło się zamyka.

reasumując jeśli ktoś nie lubi poradników z takimi przypadłościami to ...

....zawsze jest na to rada - a w zasadzie trzy rady

1. taki czerwony klawisz z krzyżykiem na górze okienka z przeglądarką - można zamknąć okno i nie oglądać dalej

2. można w ogóle nie oglądać moich poradników jak już się z góry wie że są rozwlekłe - nawet nie włączać YT

3. można wreszcie samemu nakręcić poradnik - ale taki który:
a.) nie będzie rozwlekły
b.) osoba mówiąca będzie wspaniały lektorem z idealną dykcją i wymową
c.) prowadzący będzie wyśmienicie wypowiadał słowa angielskojęzyczne


tylko tyle w tym w temacie mogę niestety poradzić. Więc jeśli kolega (wcale nie mówię tego złośliwie) nie cierpi rozwlekłych poradników - to chyba jednak pozostanie tylko druga książka. A jeśli nie trafiam ze swoim przekazem to pewnie inna książka - w końcu nie tylko ja się takimi rzeczami zajmuję na tym bożym świecie

Nadmienię - jakby ktoś jeszcze inny spodziewał się lektora z telewizji typu np sławny JAN SUZIN - to te moje poradniki są bezpłatne - a w przeciwnym przypadku - byłyby słono płatne - choć pewnie mniej rozwlekłe

przy okazji już życzę wesołych świąt

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Znalazłem czas na sprawdzenie dlaczego nie działa u mnie to, że ustawiając (nawet na sztywno) rejestry tak, aby częstotliwość I2C wynosiła 100kHz i doszedłem do spostrzeżenia...

Ustawiłem rejestry wyznaczające częstotliwość tak (wiem, że nieelegancko ale tylko do testów tak):


Tak więc z tymi wartościami mamy 100kHz. Teraz metodą LED_ON/LED_OFF (idealny debuger ) sprawdzałem jak idzie program, który zaczyna się tak:


dalej wchodząc do funkcji:


zauważyłem, że program nie wychodzi z tamtejszej pętli while():


gdyż DEBUG_LED się nie zapala. Tak więc wszedłem do TWI_read() i wyszło, że tam program zatrzymuje się na tamtejszej pętli while(), która sprawdza ustawienie bitu TWINT.


Uprzednio zgaszona dioda się zapala ale już nie gaśnie, czyli LED_OFF; się nie wykonuje
Widać, że ten bit się nie ustawia czyli program stoi w tym miejscu i nie idzie dalej.

Jest to bardzo dziwne gdyż np. dla ustawień:


nie ma problemu, jednak zmierzona oscyloskopem częstotliwość SCL miała wartość około 55kHz, czyli mniej więcej tyle ile z obliczeń.

Z tego co wiem, niby mam poprawnie ustawione fuse bity w procesorze (ATmega8), kwarc 16MHz, rezystory SCL, SDA po 4,7kOhm... niby wszystko jest OK ale i tak chyba błąd jest sprzętowy, tylko teraz pytanie gdzie

---------------------------------------------------------
Już odkryłem co było nie tak!
Kolejnym narzędziem, które jest idealne do rozwiązywania problemów warstwy fizycznej jest... lupa.
Okazało się, że rezystory podciągające nie mają wartości 4k7 ale 470k. Przez omyłkę takie wlutowałem...
Zamiana na 4k7 pomogła, no ale debuger z diody led sporo mi pomógł

Właśnie widzę na oscyloskopie, że jest 90,3kHz. Brak tych 10kHz raczej nie jest problemem chyba. No ale widzę teraz zmianę, bo układ działa tak jak chcę i rejestry poprawnie konfigurują zegar. Także sygnał na SCL ma kształt prostokąta, a nie jak przedtem piły...
Czy sądzisz, że powinienem się martwić tymi 10kHz? Może to wpływ pojemności, gdyż układ jest na razie na płytce stykowej...

prawdopodobnie właśnie to wina stykówki .....
te i te 10 czasem więcej KHz umyka sobie gdzieś

_________________
[b]San Escobar! Patria mia! Tu eres como la salud.[/b]