[ATmega32][C] - Komunikacja dwóch czujników na I2C o różnych parametrach

No nic, będę musiał przestudiować to i owo, zrobić programator na LPT, ale najpierw kupić wtyk itp. U mnie w mieście nawet elektronicznego nie ma. Mam do Ciebie pytanie, jeżeli procesor myka na oscylatorze RC i ma 1MHz, w takim razie powinno dać się połączyć z procesorem przecież, obawiam się że wina leży po stronie prędkości programatora w Atmel Studio 6 w wyniku braku mojej wiedzy. Ustawiałem maks czyli tam jest 1,8kHz chyba...a jest wyraźnie napisane - prędkość ISP musi być niższa niż 1/4 prędkości procesora, więc powinienem zmniejszyć prędkość...wtedy powinno się połączyć?

zmniejsz prędkość na maxa i sprawdź - czy to czymś grozi ? sprawdzenie odczytu ? - przecież nie chodzi o zapis. Uparłeś się na kocie AVR Studio to się pomęcz teraz żeby w nim dostać się do procka .... (zaraz pewnie odezwą się obrońcy zwierząt, kotów i AVR Studio)...

Ja się tylko trochę dziwię, że tak niechętnie chce ci się sprawdzić - chociaż na chwilę byle jaki inny program do komunikacji z użyciem nawet twojego stk500. A czy to zaraz będzie dla ciebie oznaczało zdradę AVR Studio o odcięcie się od niego ???? chyba nie .... toż gdybyś sprawdził że w innym programie działa - to wiedziałbyś już na pewno że wystarczy coś jeszcze innego zmienić w AVR Studio i ruszy ..... Tym bardziej że rozumiem iż w twojej miejscowości nie ma nikogo kto np może pożyczyć ci inny programator. To jednak net masz pod ręką - a programów masz bez LIKU do sprawdzenia. Aż mi się nie chce nazw wymieniać.

Uruchom to z AVRStudio4, ustaw parametry zegara i sprawdź.

Już jestem, robiłem nową płytkę - tamta miała wadę estetyczną z gniazdem ISP. W AVR Studio zmniejszyłem prędkość ISP na 115kHz - programator połączył się z procesorem. Teraz pozostaje mi tylko ustawić fuse bit odnośnie zegara, za bardzo nie wiem czym są oznaczenia z tej listy w AVR Studio. Widzę, że jest kilka ustawień dla kwarcu od 8MHz w górę. Ustawiłem inne fuse bity wg. informacji (tutoriali) znalezionych w internecie.

Mam takie pytanie natury fuse bitów i odpalania procesora - ustawiłem sobie w razie czego fuse bity domyślne które przedstawione są w dokumentacji procesora. Fuse high na 0x99 a fuse low 0x46. Mam takie pytanie odnośnie zachowania procesora - czy mam to rozumieć jako upalenie czegoś w jego strukturze przez przelutowywanie albo przypadkowe zwarcie jaki mi się zdarzyło (przez przypadek zwarły mi się kabelki 5V i GND w wyniku bałaganu jaki panuje na biurku). W celu sprawdzenia w ogóle pinów dałem sobie proste



Po wgraniu hexa port C szwankuje, tzn tylko 4 z 8 pinów mają stan niski - sygnalizuje diodą. Czy mam rozumieć to jako uszkodzenie ?

doles wrote:

Fuse high na 0x99 a fuse low 0x46.

Nie są to ustawienia domyślne:

Domyślnie to tak :

Zrzuty ekranowe pochodzą z programu avrmate.

Ale to są dla ATmega32, a ja mam ATmega644PA i tak swoją drogą ATmega644 domyślnie pracuje na kwarcu wewnętrznym 8MHz a nie 1MHz - jeden jest dla ATmega32. Czytam datasheet obydwu. Pewnie spojrzałeś na procesor w temacie, ale temat się tak rozwinął i zasyfił a mowa była o obydwu procesorach, także ... powstał mętlik. Co jeśli chodzi o zachowanie portów ? Są to dokładnie piny:
PC3(TCK), PC4(TMS), PC5(TDO), PC6(TDI)

EDIT: wystarczyło doczytać, że te piny zarezerwowane są dla JTAGa, a że z niego nie korzystam po prostu je wyłączam. Dondu może warto by było abyś tę informację też umieścił w poradniku dla początkujących tak jak z ustawieniem prędkości ISP ?
Mam jeszcze tylko duże problem z ustawieniem fuse bitów aby ATmega pracowała na kwarcu 20MHz, ATmega644 ma nieco inne ustawienia od ATmega32... nie wiem za bardzo co wybrać, bo przy żadnym ustawieniu dla kwarcu zewnętrznego mi nie działa, tzn sprawdzam sobie na prostej migającej diodzie

dyrektywa F_CPU=20000000 i próbuję ustawić tak fuse bity SKCEL aby dioda "mrugała" - będę wtedy wiedział, że oscylator jest ustawiony... Narazie mam na:

doles wrote:

Ale to są dla ATmega32, a ja mam ATmega644PA

Nie podawałeś efuse i to mnie zmyliło. Mimo wszystko 0x46 nie jest wartością domyślną dla lfuse...
Patrząc na twoje ustawienia (przewidujesz bootloader i brak kasowania EEPROM podczas Chip Erase) i te 20MHz, proponuję tak:

Zmieniłem tak jak proponujesz oraz w while(1) dałem tylko PORTC = 0x00; efektem jest szybkie miganie diody ? hm

EDIT: zmieniłem na: high 0xD0 a low na 0xE7 i działa Dziękuję strasznie wszystkim za pomoc...teraz mogę dalej kombinować z czujnikiem światła - zabawa ze znalezieniem rezystorów na niższą częstotliwość I2C i napięcie 1,8V... w nocie katalogowej jest 560Ω dla tego czujnika SFH5712 ale to jest do prędkości 3,4Mbit.

Czytam dokumentacje magistrali I2C oraz różnych artykułów w internecie odnośnie I2C. Mam parę pytań - jeśli istnieje zależność, że im mniejsza rezystancja rezystorów podciągających do VDD tym większe prędkości transmisji (czasy narastania i opadania zboczy, mniejsze ? pojemności) w takim razie jeśli 560Ω przy 1,8V w czujniku przystosowane do transmisji 3,4Mbit/s, jeśli zwiększę rezystancję spowolnię prędkość magistrali. Ze specyfikacji I2C widzę, że dla niskich napięć i prędkości takim uniwersalnym rezystorem jest 4k7Ω, czy dobrze myślę?

Dochodzi też inna kwestia która mnie nurtuje, jeśli czujnik ten będzie na przewodach o długości 50-80cm jak będzie wyglądać sprawa z filtracją zakłóceń na magistrali ? Rozumiem, że przewody dobrze ekranowane, nie byle szajs, ale czy podciąganie lini SDA i SCL kondensatorem do masy o wartościach pF ? Znów jeśli tak, problem pojemności lini magistrali, a przekroczyć ich nie mogę z tego co pamiętam 400pF ? To wartość typowa. Czujnik polutuję chyba tak, że będzie on sam na płytce dajmy na to 1x1cm + pady na przewody zasilania i danych, przewód o długości jakiej wspominałem do sterownika gdzie będzie dopiero konwerter logiczny itp. Co myślicie o takim rozwiązaniu ?

doles wrote:

Czytam dokumentacje magistrali I2C oraz różnych artykułów w internecie odnośnie I2C. Mam parę pytań - jeśli istnieje zależność, że im mniejsza rezystancja rezystorów podciągających do VDD tym większe prędkości transmisji (czasy narastania i opadania zboczy, mniejsze ? pojemności) w takim razie jeśli 560Ω przy 1,8V w czujniku przystosowane do transmisji 3,4Mbit/s, jeśli zwiększę rezystancję spowolnię prędkość magistrali. Ze specyfikacji I2C widzę, że dla niskich napięć i prędkości takim uniwersalnym rezystorem jest 4k7Ω, czy dobrze myślę?

Chm, nie bardzo.
Pojemności wpływają na maksymalną możliwą do uzyskania częstotliwość, a nie bezpośrednio na częstotliwość.
Czyli jeżeli układ pracuje na 3,4MHz, a Ty zwiększysz pojemności, to układ automatycznie nie przejdzie na niższą częstotliwość. Po prostu przestanie działać.
Częstotliwość musisz zmniejszyć ręcznie.

doles wrote:

Dochodzi też inna kwestia która mnie nurtuje, jeśli czujnik ten będzie na przewodach o długości 50-80cm jak będzie wyglądać sprawa z filtracją zakłóceń na magistrali ? Rozumiem, że przewody dobrze ekranowane, nie byle szajs, ale czy podciąganie lini SDA i SCL kondensatorem do masy o wartościach pF ? Znów jeśli tak, problem pojemności lini magistrali, a przekroczyć ich nie mogę z tego co pamiętam 400pF ? To wartość typowa. Czujnik polutuję chyba tak, że będzie on sam na płytce dajmy na to 1x1cm + pady na przewody zasilania i danych, przewód o długości jakiej wspominałem do sterownika gdzie będzie dopiero konwerter logiczny itp. Co myślicie o takim rozwiązaniu ?

Generalnie I2C nie jest przystosowane o pracy na większe odległości. Ale ludzie je do tego stosują i pare dobrych rozwiązań powstało. Ogólne wnioski są takie jak piszesz. Czyli kable ekranowane ale takie gdzie pojemności linii sygnałowych do masy są małe.

Tzn, rozumiem, że nie zgadasz się i poprawiłeś moje rozumowanie odnośnie pojemności w magistrali, a co odnośnie rezystancji ? Chodzi mi moje wstępne wnioski które wyciągnąłem po przeczytaniu paru rzeczy i przeanalizowaniu w skrócie wykresów z dokumentacji I2C. Co masz na myśli zmniejszyć częstotliwość ręcznie ?

No chodzi mi o to że zwiększenie rezystancji zmniejszy maksymalną częstotliwość pracy*.
Np. z 5MHz do 2MHz.
Ale jak układ pracował na 3,4MHz, to automatycznie nie przejdzie na 2MHz.
Musisz to zrobić ręcznie, czyli w programie w procesorze zmienić częstotliwość z 3,4MHz na 2MHz. Nie wiem jak to Ci dokładniej wyjaśnić

*tzn. zwiększenie rezystancji przy niezmiennej pojemności. Bo te rzeczy obydwie na raz decydują o maksymalnej częstotliwości. Np. jak zwiększysz rezystancję 2 razy i jednocześnie zmniejszysz pojemności 2 razy, to maksymalna częstotliwość się nie zmieni.

atom1477 wrote:

Musisz to zrobić ręcznie,

No może raczej chodzi o zmiany w kodzie i to możesz zrobić tym, czym preferujesz obsługiwać klawiaturę lub inne urządzenie do wprowadzania/zmiany kodu...

Dawno nie zajmowałem się czujnikiem ale znów wracam do niego...wlutowałem na kablach dwa potencjometry podciągające magistralę - zasilanie ATmegi 1,8V i tyle samo na magistrali, bez konwertera. Ustawiłem narazie na potencjometrach około 4,7k i nic, nie da się połączyć z czujnikiem. Zastanawiam się czy da się w ogóle na 1,8V uzyskać niskie transmisje I2C, bo skoro rezystor podciągający determinuje napięcie a rezystor pośrednio na pojemność i dalej częstotliwość no to chcąc nie chcąc wg. takiej teorii do 1,8V będzie około 500-600Ω czyli automatycznie uzyskamy wysoką częstotliwość...Ten czujnik mnie po prostu rozbraja już. Bez oscyloskopu to tutaj dużo nie zdziałam chyba. Kwarc ATmegi to 4MHz, więc wg. wzoru na częstotliwość I2C rejestr TWBR i bez preskalera ustawiłem na wartość 3 - teoretycznie 100kHz.

PS: mam już totalny mętlik w głowie, czytając o I2C wynika z tego, że tryb standard to główni(i tylko?) napięcia 5V i do 100kHz...czyli 1,8V to napięcie tylko dla HS mode. Nic już nie wiem oO. To w końcu jak, można zrobić 1,8V i 100kHz rozumiane jako standard ?

Dziś w pracy zmierzyłem prąd płynący przez czujnik - wynosi on 1,2uA -> czyli jest OK, lutowanie dobre i czujnik działa bo w datasheecie jest notka o tym, że czujnik w stanie stand-by mode pobiera max 2,5uA. Mam chociaż pewność, że nie jest on uszkodzony albo źle przylutowany.

Witam, po długim czasie znów odgrzebuję ten temat... i problem z czujnikiem, który zostawiłem na rzecz ważniejszych rzeczy. Sprawa wygląda tak. Totalnie nie mam już pojęcia co jest nie tak, próbowało mi na uczelni pomóc 2 doktorów i żaden nie miał pojęcia co się dzieje. W końcu zalecono mi wywalić owy czujnik SFH5712 który miałem i kupić coś bardziej sensownego. Promotor polecił mi czujnik TSL2561...Więc zakupiłem go, w piecu rozpływowym na uczelni przylutowałem i próbuję go odpalić. Efekt ? Ten sam problem co z poprzednim czujnikiem. Wrzucę może prymitywny kod i powiem co dalej.



Problem jest taki. Procesor "żyje" dopóki zakomentowana jest linijka TWI_Write(0x8C);. Jest to adres rejestru poleceń, wybór konwersji światła - odczyt całego słowa lub tylko bajtów. Gdy odkomentuję tę linijkę to procesor idzie po prostu w las. Specjalnie dałem potem migające diody, aby widzieć czy idzie w las czy nie. Wszystko jest OK, do momentu gdy mam tylko polecenie START i adres urządzenia. A potem koniec. Biblioteki są te same co wcześniej.
Procesor ATmega644PA, zasilanie 3V ze stabilizatora MCP1825, chociaż tutaj też dziwactwa są -zamisat 3V na wyjściu mam 2,86V. W dodatku na lini SDA mam 2,86V a na lini SCL mam 0V. Totalnie nie mam już pojęcia ani pomysłów co jest nie tak. Wychodzę ze założenia, że jeśli dwie osoby z doktoratem nie potrafiły mi pomóc na uczelni to ja chyba nie mam większysz szans. Sama biblioteka do I2C jest wzięta z zestawu ewaluacyjnego pod ATmega32, ale te procesory chyba niczym się nie różnią prócz pamięci flash...Rejestry itp mają takie same. Nie wiem gdzie może być przyczyna oraz nie wiem czy jest sens próbować odpalić to dziadostwo z ATmega32 i konwerterem logicznym na dwóch tranzystorach BSS138. Rezystory podciągające na płytce mam 10k. Tak jak zalecane w datasheecie - 10k i zasilanie 3V. Pewną ciekawostkę powiedział mi promotor, że obudowy QFN6 czujników SFH5712 są bardzo słabe a urządzenia często wadliwe. Przytoczył mi przykład pewnej firmy która masowo zamawiała z OSRAMu te czujniki i masowo je wywalali bo okazywały się wadliwe i łatwo niszczące przy montażu - np spalenie podczas lutowania. Ten czujnik który mam też jest w tej obudowie... DFN to praktycznie to samo.

Dzisiaj sprawdziłem dokładnie magistralę I2C i biblioteki na 2 procesorach obsługując pamięć 24C64. Zarówno na ATmega32 jak i ATmega644PA wszystko działa poprawnie używając bibliotek które pokazywałem oraz dodatkowo wszystko działa z różnymi napięciami zasilania eepromu i procesora przy pomocy konwertera. Nie wiem gdzie teraz szukać przyczyny tego błędu.
1. Biblioteka jest OK
2. Konwerter jest OK
3. Procesory oba sprawne - moduły I2C

Uszkodzony czujnik przy lutowaniu ? Lutowany był w piecu i miał odpowiedni profil. Nie mam pojęcia dlaczego się tak zachowuje.

Witam, problem został rozwiązany. Powodem zawieszania się był zły adres urządzenia slave oraz niepoprawna procedura zapisu I2C. Temat do zamknięcia.