AVR - Wykorzystanie układu DS1307 tylko jako pamieci RAM

Cześć.
Potrzebuję się poradzić.
Musze dość często pamiętać kilka zmiennych po wyłączeniu zasilania.
Pomyślałem o wykorzystaniu do tego pamięci RAM z układu np. DS1307.
Nie potrzebny mi jest w nim RTC tylko sama pamięć RAM podtrzymywana baterią.

I tu mam pytania.
1. Czy układ DS1307 może nie mieć podłączonego kwarcu tylko samą baterię?
2. Czy konieczne jest jakieś ustawianie rejestrów zegara skoro ich nie wykorzystuję?
3. A może znacie sam układ pamięci RAM. Potrzebuje zaledwie 20 bajtów.
4. Poczciwe '51 miały możliwość podtrzymania wewnętrznej RAM poprzez zasilanie wejścia reset, ale AVRy chyba takiej możliwości nie mają, bo nie znalazłem w nocie takiej informacji

AVRy i inne współczesne uC mają pamięć EEPROM, przeznaczoną właśnie do takich celów. Istnieją również pamięci EEPROM i FRAM z interfejsem I2C.
A jakieś 2..3 tygodnie temu był tu wątek z dokładnie takim samym pytaniem - czytaj.

Niestety nie mogę zaleźć i rozumiem, że t ta pomoc?

A jeszcze prościej i w każdym MCU można po prostu uśpić procesor. W tym trybie zawartość pamięci jest podtrzymywana, a pobór prądu jest często mniejszy niż 2 mikroampery zbliżając się do nanoamperów.

Skoro w karcie katalogowej nie ma nic na temat konieczności podłączania kwarcu ani na temat bitów w rejestrach, które umożliwiałyby dostęp do RAM, to należy z tego wnioskować, że nie ma konieczności użycia oscylatora ani nie trzeba nic zapisywać. Nie rozumiem jednak, dlaczego nie użyjesz dostępnej w mikrokontrolerze pamięci EEPROM do przechowywania danych, które mają przeżyć zanik zasilania.

Nie mogę zmienić uC bo mam już ATMega162, uśpic też ciężko bo całe napięcie przychodzące jest odcinane

1.No i jaki w związku z tym masz problem z pamięcią EEPROM mikrokontrolera ATmega162?

2. Rozumiem, że do projektu możesz dorzucić bez problemu nową kostkę za 10 zł, ale nie możesz zmienić procesora na taki z wbudowanym RAM podtrzmywanym bateryjnie, który kosztowałby np. 8 zł?

Nie mogę zmienić uC bo mam już płytkę i całą otoczkę tego wszystkiego. po prostu wcześniej nie miałem takiej konieczności, a doczepić 4 przewody mogę, pomimo Waszej krytyki że to głupio wygląda.
Dlaczego nie EEPOM, bo za często dane muszą być zapisywane i boję się że po roku padnie.

To je zapisuj tylko wtedy, gdy zanika zasilanie, a normalnie pracuj na ich kopii w SRAM. Detekcję zaniku zasilania można zrobić prościej niż dodanie kolejnego scalaka.

Jasne, ale to nie jest praca na zmiennych w EEPROM, tylko tak często układ jest włączany i wyłączany.

To lepiej przemyśl jak ten zapis do pamięci zewnętrznej zrobić? Jeśli ktoś wyłączy zasilanie w trakcie transmisji I2C to otrzymasz sieczkę. Czyli wracamy do problemu początkowego, czyli detekcji awarii zasilania i podtrzymania procesora. A skoro tak, to można go usypiać co likwiduje problem.

To może lepiej zainteresuj się pamięcią FRAM FM24CL16B-GTR za 6zł/szt netto masz 2kB pamięci którą możesz do woli zapisywać i nie wymaga zasilania. Należy włączyć w procku monitor zasilania a w pamięci poza danymi zapisywać ich CRC.

Jacek Rutkowski napisał:

To może lepiej zainteresuj się pamięcią FRAM FM24CL16B-GTR za 6zł/szt netto masz 2kB pamięci którą możesz do woli zapisywać i nie wymaga zasilania. Należy włączyć w procku monitor zasilania a w pamięci poza danymi zapisywać ich CRC.

Tylko, że to nic nie da. Włączenie BOD spowoduje, że procesor wejdzie w reset poniżej określonego progu napięcia, czyli przerwie transmisję w losowym momencie. Z kolei dodanie CRC spowoduje tylko, że będziemy wiedzieć, że dane są uszkodzone, niemniej w żaden sposób prawidłowych nie odtworzymy. Jeśli istotne są ostatnio zapisywane dane, to jedyną możliwością jest podtrzymanie pracy procesora do momentu, kiedy aplikacja wszystko zapisze i się wyłączy.

Zgadza się, tylko autor wątku nie wspomina jak często dane chce przeliczać i zapisywać. Jeśli czas pracy ma być porównywalny lub krótszy od czasu zapisu do pamięci to jest to bez sensu rozwiązanie.
Sam autor musi wypowiedzieć się dokładnie o co mu chodzi i czy utrata ostatnich wyników jest dopuszczalna. Jeśli nie dyskusja nie ma sensu.

Podsumowując:
- Autor nie chce opisać, o co mu chodzi.
- Wszyscy jesteśmy zgodni co do tego, że użycie DS1307 nie ma tu sensu - wystarczy wewnętrzny EEPROM mikrokontrolera albo zewnętrzny FRAM na I2C.

Sens ma o tyle, że rozwiązanie jest niezwykle proste i zabezpiecza przed utratą danych. Czyli detekcja awarii, podtrzymanie MCU i zapis do EEPROM. W wątku wskazanym na początku rozwiązanie takie zostało omówione.

Autor chce opisać o co mu chodzi i zrobił to tylko szanowni forumowicze zeszli z tematu. Po co ja mam 30 razu dziennie zapisywać kilka bajtów do EEPROM, skoro bez żadnego ograniczenia mogę zapisać do SRAM. Jak ja bym chciał zapisać do EEPROM to bym o to zapytał. Może wy widzicie że jest to lepsze, ale ja nie mogę się przemóc aby non stop zapisywać tą pamięć EEPROM. Może ona ma wiele cykli zapisu, ale jednak jest to ilość ograniczona i to ograniczenie mnie martwi.
jak jest to jeszcze mało jasne to raz jeszcze napiszę

30 razy dziennie po 5 bajtów - racja, w takiej sytuacj EEPROM mógłby się uszkodzić już po jakichś 30 latach ciągłej pracy urządzenia.

Problem z uszkodzeniem danych przy zapisie do DS1307 po I2C w przypadku wyłączenia zasilania można łatwo rozwiązać. Wystarczy zapisywać w dwie komórki z CRC. Wtedy zawsze jeden wynik będzie prawidłowy.
Czytamy pierwszą komórkę, porównujemy ją z CRC, jeśli jest źle to sprawdzamy jej kopię.

slawek55 napisał:

Autor chce opisać o co mu chodzi i zrobił to tylko szanowni forumowicze zeszli z tematu. Po co ja mam 30 razu dziennie zapisywać kilka bajtów do EEPROM, skoro bez żadnego ograniczenia mogę zapisać do SRAM. Jak ja bym chciał zapisać do EEPROM to bym o to zapytał. Może wy widzicie że jest to lepsze, ale ja nie mogę się przemóc aby non stop zapisywać tą pamięć EEPROM. Może ona ma wiele cykli zapisu, ale jednak jest to ilość ograniczona i to ograniczenie mnie martwi.
jak jest to jeszcze mało jasne to raz jeszcze napiszę

Kolego, albo nas pytasz o pomoc i na poważnie traktujesz propozycje rozwiązań, albo masz z góry upatrzoną dziwną ideę i tylko potrzebujesz klakierów.
Kolega BlueDraco pokazał ci, że żywotność EEPROM można łatwo wyliczyć, zresztą decydując się na skrócenie okresu przechowywania danych przez EEPROM jego żywotność znacznie się wydłuża. Skoro to kilka bajtów to można przy pomocy prostego wear leveling tą żywotność wydłużyć z tych 30 lat, do 15 tysięcy lat w twoim przypadku, co wydaje się czasem życia urządzenia dosyć abstrakcyjnym. Nie musisz też ciągle czegoś w EEPROM zapisywać, jak tego uniknąć ci podałem, masz nawet dwa różne rozwiązania tego problemu.

Dodano po 2 [minuty]:

Marek_Gorecki napisał:

Problem z uszkodzeniem danych przy zapisie do DS1307 po I2C w przypadku wyłączenia zasilania można łatwo rozwiązać. Wystarczy zapisywać w dwie komórki z CRC. Wtedy zawsze jeden wynik będzie prawidłowy.
Czytamy pierwszą komórkę, porównujemy ją z CRC, jeśli jest źle to sprawdzamy jej kopię.

Ale to nic nie da. Zakładając, że muszę mieć ostatnią wartość, a nie jakąś wartość z przeszłości, muszę mieć gwarancję, że chociaż jedna kopia będzie ją zawierała. Jeśli zasilanie padnie w czasie zapisu pierwszej kopii to skończy się to uszkodzeniem pierwszej kopii i nieaktualnymi danymi w drugiej. Na szczęśliwy traf typu wyłączenie zawsze po zapisie pierwszej kopii liczyć nie można.

tmf napisał:

Marek_Gorecki napisał:

Problem z uszkodzeniem danych przy zapisie do DS1307 po I2C w przypadku wyłączenia zasilania można łatwo rozwiązać. Wystarczy zapisywać w dwie komórki z CRC. Wtedy zawsze jeden wynik będzie prawidłowy.
Czytamy pierwszą komórkę, porównujemy ją z CRC, jeśli jest źle to sprawdzamy jej kopię.

Ale to nic nie da. Zakładając, że muszę mieć ostatnią wartość, a nie jakąś wartość z przeszłości, muszę mieć gwarancję, że chociaż jedna kopia będzie ją zawierała. Jeśli zasilanie padnie w czasie zapisu pierwszej kopii to skończy się to uszkodzeniem pierwszej kopii i nieaktualnymi danymi w drugiej. Na szczęśliwy traf typu wyłączenie zawsze po zapisie pierwszej kopii liczyć nie można.

ale tak samo będzie w przypadku EEPROMA. Jeśli akurat w czasie (stosunkowo długim) zasilanie padnie to też dana będzie uszkodzona.
Tyle tylko że w przypadku Ramu, może zapisywać dane w sposób bardzo szybki np co 2 sek w to samo miejsce, więc zawsze będzie jakaś dana prawidłowa. Jak nie jedna to druga.

tmf chciałby Ci się coś więcej napisać o wear leveling. Z tym się nie spotkałem.

Chodzi o ograniczenie liczby operacji kasowania. W przypadku EEPROM robi się to tak, że zamiast zapisywać daną zawsze do tej samej komórki, kolejne jej wartości (wraz z np. numerem generacji) zapisuje się do kolejnych komórek. W ten sposób kasowanie zachodzi tyle razy rzadziej, ile rekordów mieści się w pamięci. W przypadku pamięci Flash używa się min. 2 bloków, tak, aby zawsze w pamięci była jakaś w miarę aktualna kopia, również w czasie, gdy jeden blok jest kasowany. W zwykłej EEPROM kasowalnej "bajtowo" jest to łatwiejsze.

slawek55 napisał:

tmf chciałby Ci się coś więcej napisać o wear leveling. Z tym się nie spotkałem.

Tak jak pisze kolega BlueDraco. Gotowe kody realizujące wear leveling masz w przykłądach do mojej pierwszej książki (link do pobrania przykładów w stopce).

Książkę mam i zapomniałem że tam było. Może i racją, że prędzej całe urządzenie się znudzi niż uC padnie od częstości zapisów.

Nie daj sobie wmówić, że istnieje "jedynie słuszna droga" - bo wszyscy z niej korzystają.
Moim zdaniem opcja z DS1307 jest równie dobra.

Dla producentów baterii opcja z DS1307 jest jedynie słuszna. Ja wolę nie pakować zbędnej baterii tam, gdzie mona się bez niej obyć - po to właśnie wymyślono pamięci nieulotne, w tym szybkie FRAM.