Atmega32 + EEprom 24c32 zapis i odczyt z pamieci zewnetrznej

Dane z eeprom odczytujesz tak samo jak z ram RTC. Zapis przebiega prawie tak samo. Różnica taka, że po zapisie eeprom nie daje ACK dopóki operacja nie zakończy się. Trwa to max 10ms. Jeśli więc masz sprawdzone procedury dla RTC to tak samo muszą działać dla eeprom. Przy zapisie, możesz po każdym bajcie dać delay_ms(10). Pamiętaj, że zapis rozpoczyna sie po warunku stop. Musi to więc odbyc sie tak:
start
adres
dana
stop
delay_10ms


Jeśli zrobisz
start
adres
dana
dana
dana
stop
delay_10ms
to będzie zapis stronami a tu trzeba pamiętać o adresie strony i jej wielkości.


Czy masz ACK po zaadresowaniu eeprom?
Kod, który pokazałeś powienien wyświetlić jedną literę. Nie widzę aby tekst był zakończony 0 ale po resecie bufor powinien byc wypełniony zerami.

Umbactor napisał:

Dzieki za odpowiedz czyli powinno byc jakos tak ?

Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka

twistart();
		twiwrite(0b10100000);
	
		twiwrite(a[0]);
		twistop();
		_delay_ms(10);

Dokładnie tak.

Umbactor napisał:

Co do ACK rozumiem ze jesto jakiego rodzaju sygnal ktory daje nam komunikacje jednak nie mam pojecia jak go uzywac ;C

Masz beznadziejnie napisane funkcje obsługi I2C. Zakładasz wszędzie optymistycznie, że wszystko jest ok i nie sprawdzasz rejestru statusu.
Generujesz start, nie sprawdzaszy czy operacja powiadła się i adresujesz układ. Po jego zaadresowaniu nie sprawdzasz czy potwierdził operację, wysyłasz daną. Sprawdzaj rejestr statusu, z którego dowiesz się między innymi czy układ wysłał ACK.

Jak już to zrobisz, to warto zabezpieczyc się przed słynnym 0xF8.

Umbactor napisał:

Funkcje napisane przez mojego profesora

Dużo nauki przed nim.

Umbactor napisał:

nie chce mieszac poprostu chce mu oddac zapis i odczyt z 24C32 i tyle

zrób wiec tak:

i już bedziesz wiedział, czy układ odpowiada na ACK.

Umbactor napisał:

Rozumiem a do odczytu wystarczy
j=twiread(adres);?

Też trzeba sprawdzić ACK, bo układu może nie być (np adres jest zły), kabelek się urwał, itp.

Po warunku staru też należy sprawdzic status bo może byc problem z rezystorami podciągającymi. Jest tez inny powód. Np komunikujesz się po IIC i w czasie wysyłania np drugiego impulsu SCK następuje reset procesora. Po wykonaniu resetu procesor ponownie próbujesz się skomunikować i niekoniecznie to sie uda. Niektóre slave moga czekać na brakujące SCK. Po kilku resetach czy wyłączeniu zasilania wszystko ruszy ale lepiej chyba wykryć problem z warunkiem startu i odpowiednio zareagować.

Większość programistów a właściwie pseudo-programistów, pomija te "drobiazgi" a później posty "czasem I2C nie działa, próbowałem wszystkiego i nic". A wystarczyło odczytać status, dać informację na np LCD. Wtedy wiadomo co powoduje problemy a przynajmniej łatwiej je znaleźć.

Umbactor napisał:

Osobiscie nie mam pojecia jakie moga wystapic bledy

Zwarcie magistrali, przerwa na magistrali, za duża pojemność magistrali no i przypadek, który juz opisałem, czyli reset mikrokontrolera w czasie transmisji.

Błąd tez może wystąpic w trybie multimaster.

Umbactor napisał:

Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka

start(); // czy tez musze dawac start() ??
if (status & 0xF0 != 8) return( BLAD_START );
j=read(adres);
stop(); 

Czy taki odczyt zadziala czy musze jeszcze cos zrobic nie mam oczywiscie Atmegi przy sobie ;C

W nocie katalogowej eeprom masz przyklad operacji odczytu. Porównaj to z tym co napisałeś.