Użyj struktury.

Do eepromu wyślesz element struktury (można i calą strukturę)

gdzie kolejne parametry to
0 - adres w eeprom I2C
eeprom+rekord*nrRekordu- adres danych w ram
sizeof(rekord) - liczba danych do zapisu

Strony pamięci nie przekraczasz (24C512 ma 128bajtów), więc zapis zajmie max 5ms. Aby program nie wisiał w czasie transferu danych użyj przerwań TWI.

Dlaczego zewnętrzny EEPROM a nie wbudowany w AVR? Mega16 ma 512bajtów eeprom. Potrzebujesz 40x4x2 bajty = 320. Warto aby dane były chronione przez CRC (np CRC8), więc 40x4x(2+2) = 480bajtów.

Z tym się nie zgodzę. Każdy dodatkowy element powoduje ryzyko zwiększenia awaryjności. Co się częściej psuje, rower czy samochód?


Ile zapisów potrzebujesz? Jaki czas "życia" urządzenia jest wymagany? Może lepszy będzie FRAM?


Jak masz dużo FLASH a potrzebujesz dużej liczby zapisów, to emuluj EEPROM w FLASH. W ten sposób może sobie zwiększyć liczbę zapisów do 10 czy słynnych wałęsowych 100 mln niskim kosztem. W praktyce, w mikrokontrolerach często nie ma pamięci EEPROM, jest ona emulowana w FLASH.

I myślisz, że osiągniesz to dodając zewnętrzne układy? Mylisz się, już pisałem, w ten sposób awaryjność zwiększa się.


Dobry pomysł ale połącz to z CRC o którym pisałem. Możesz dodatkowo trzymać pozą kopia w EEPROM kopię w FLASH.

Jeśli kostka ma możliwość zmiany adresu i piny masz na masie to do adresu w miejsca A0, A1 i A2 trafiają zera czyli adres to 0b10100000 (w heksie 0xA0) lub w stylu arduinowców 0b01010000 (w heksie 0x50).

Jeśli dany pin jest na masie to w miejsce numeru pinu w adresie wskakuje "0", jeśli pin jest do Vcc to wskakuje "1"

------------------------ [ Dodano po: 10 minutach ]

Kolega trochę demonizuje. Dużo producentów różnorakiego sprzętu umieszcza ustawienia w zewnętrznych pamięciach eeprom. Tylko może bardziej jest to podyktowane prostotą załadowania ustawień do takiej pamięci niż względami jej większej niezawodności. Łatwiej jest zaprogramować zewnętrzną kostkę niż dobierać się do uC który zazwyczaj jest zabezpieczony przed odczytem, a co za tym idzie i przed zapisem. Więc w takim przypadku trzeba by wykasować całą pomięć procka by ponownie wrzucić zawartość wsadów. A tak wystarczy zaprogramować eeprom i po sprawie.

trudno powiedzieć czy wszystko ok nie widząc ciała funkcji "TWI_write/read_bufor" ale pierwsze co rzuca sie w oczy to to:
kod BCD służy do zapisu pojedynczych cyfr dziesiętnych w jednym bajcie, ty prubujesz upchać np 19 w jednym bajcie co jest niemożliwe bo są to dwie cyfry dziesiętne więc muszą zajmować dwa bajty w BCD, oczywiście są implementacje umożliwiające zapis BCD dwóch cyfr dziesiętnych w jednym bajcie, ale nie wiem czy w tym przypadku to jest możliwe (obsługiwane przez funkcję dec2bcd).

Tak czy inaczej pierwsze dwie komórki tablicy bufora powinny zostać napełnione prawidłowo, a skoro nie są to problemu bym szukał w funkcjach zapisu/odczytu eeproma.
Te funkcje naskrobałeś sam czy masz z jakiegoś źródła? Bo widzisz z tymi pamięciami jest pewien problem, a mianowicie ich cała rodzina nie ma jednorodnego protokołu komunikacji ze względu na różną długość adresu potrzebnego do zaadresowania całej przestrzeni pamięci. I tak np kość 24c02 ma pojemność 2048 bitów, a komórki są 8 bitowe więc komórek jest 256, wiec adres ostatniej komórki to 255, czyli dokładnie jeden bajt. Pamięć której użyłeś ma pojemność 512*1024=524288, dzieląc przez 8 otrzymujemy 65536 komórek pamięci, a do zaadresowania ostatniej potrzeba dwóch bajtów. A to nie koniec niespodzianek. Pamięci których pojemność wymaga niepełnych dwóch bajtów są tak pokręcone że część adresu komórki która "wystaje" poza pierwszy bajt jest upychana w miejsce adresu sprzętowego (te kości mają albo ograniczoną możliwość zmiany adresu albo nie mają tej możliwości wcale).
Podsumowując, może być tak, że funkcje których używasz, były napisane pod inny rozmiar pamięci i twoją kostko nie chcą poprawnie gadać.

Funkcje TWI_write_buf i TWI_read_buf są niewłaściwe dla pamięci 24C512, tak jak pisałem wcześniej, w obecnej postaci nadają się do obsługi pamięci 24C01 i 24C02.
Z kolei funkcje EI2C_write_buf i EI2C_read_buf są już bliższe prawdy, ale jeszcze nie to, te nadają się do obsługi pamięci 24C04, 24C08 i 24C16.

Tu masz właściwą postać dla 24C512:

Masz bluebooka?

To ustaw sobie w stopce ikonę bb (można to zrobić w ustawieniach profilu). Dzięki temu jak ktoś będzie chciał Ci pomóc od razu widzi czym dysponujesz, i lepiej może dopasować odpowoedź.

Nie wiem czy dobrze rozumiem Twój problem bo trochę chaotycznie to opisujesz.
Rozumiem to tak, że masz rejestr który czymś steruje, i chcesz mieć możliwość odczytanie stanu pinów rejestru i zapisu ich w rozbiciu na zmienne, oraz w drugą stronę ze zmiennych chcesz mieć możliwość wysłać ich stan do rejestru
Takie coś możesz zrobić na zwykłych warunkach if:


dodatkowe ale:
nie wiem skąd Ci się to wzięło ale ten zapis ustawia 0 a nie jeden i na odwrót z drugim zapisem, chyba że potrzebujesz mieć wartość zanegowaną, bo np masz diody sterowane zerem...