-
Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
atman.pl!news.supermedia.pl!news.nask.pl!news.nask.org.pl!news.internetia.pl!no
t-for-mail
From: "Gejzero SQ3OGX" <g...@p...onet.pl>
Newsgroups: pl.misc.elektronika
Subject: Re: Organizacja danych w EEPROM
Date: Thu, 6 Jun 2013 15:01:50 +0200
Organization: Netia S.A.
Lines: 84
Message-ID: <koq1q9$nvs$1@mx1.internetia.pl>
References: <51b04d1f$0$1255$65785112@news.neostrada.pl>
NNTP-Posting-Host: 77-253-76-84.adsl.inetia.pl
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response
Content-Transfer-Encoding: 8bit
X-Trace: mx1.internetia.pl 1370524297 24572 77.253.76.84 (6 Jun 2013 13:11:37 GMT)
X-Complaints-To: a...@i...pl
NNTP-Posting-Date: Thu, 6 Jun 2013 13:11:37 +0000 (UTC)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-Tech-Contact: u...@i...pl
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-Priority: 3
X-Server-Info: http://www.internetia.pl/
X-MSMail-Priority: Normal
Xref: news-archive.icm.edu.pl pl.misc.elektronika:648098
[ ukryj nagłówki ]
Użytkownik "Bool" <n...@n...com> napisał w wiadomości
news:51b04d1f$0$1255$65785112@news.neostrada.pl...
>W pewnym urządzeniu muszę zapisywać do 512 zdarzeń do pamięci EEPROM. Z tym
>urządzeniem będzie się komunikować drugie, które kolejno będzie te dane
>odczytywać. Potrzebuję więc dodatkowo zapisywać dwa wskaźniki zapisu i
>odczytu danych. EEPROM ma 1mln cykli zapisu, więc przy standardowym zapisie
>(dane i wskaźniki zawsze pod tym samym adresem) zapiszę 1mln zdarzeń.
>Chciałbym zwiększyć tą liczbę. EEPROMy są bardzo tanie, więc wykombinowałem
>że dam np. taki 8kB = 256 stron * 32 bajty.
> Dane (zdarzenia) zapisywałbym powiedzmy na 254 stronach a wskaźniki na
> dwóch ostatnich stronach. No i pojawia się problem zapisu wskaźników.
> Najprostsze rozwiązanie jakie przychodzi mi do głowy to na początku
> wyzerować całą stronę przeznaczoną na wskaźnik, i w momencie
> zapisu/odczytu zapisywać wskaźnik po kolei w pamięci, a po dojściu do
> końca pamięci zerować całą stronę i zapisywać od początku. Żeby odczytać
> wskaźniki, trzeba by szukać "wartownika" w postaci 0x0000 (adres 16
> bitowy). Czas nie jest tu elementem krytycznych, ponieważ minimalny czas
> pomiędzy wystąpieniem zdarzeń to 400ms. Czy macie jakieś inne pomysły?
Nie wiele to da ale może tak - zastosować pośrednie wskaźniki i lepiej
wykorzystać pamięć.
Podzielić całą pamięć na umowne strony np. po 584 bajtów co daje 14 obszarów
"umownych stron" i zajmuje 8176 bajtów
Pozostaje 16 poza stronami i w nich umieszczasz główny wskaźnik do umownej
strony (Wskaźniki w przypadku rozjechania odczytu i zapisu między stronami)
Na początku każdej umownej strony masz 72 bajty na wskazniki w obszarze
strony i licznik przepełnienia strony
Ja bym wpakował w pierwszych 4 bajtach strony dwa wskażniki "pośrednie" do
miejsca zapisu i odczytu w obszarzes danej strony,
w następnych zależnie od przyjętej ilości zapisów jakie wytrzyma wskaznik
tyle bajtów bym przeznaczył na zapisanie licznika przepełnien strony strony.
Po określonej liczbie obiegów strony, zwiękaszamy wskaźnik główny
jednocześnie przesuwamy sie ze wskażnikami o 4 pozycje w "prawo".
Zostawiając po "lewej stronie zużyte komórki wskaźników pośrednich" i
wykorzystujemy na wskaźniki pośrednie komórki dotychczas wykorzystywane na
zapis licznika przepełnienia strony
Znów po określonej liczbie obiegów strony powatarzamy zabieg zmiany w
głównym wskaźniku i przesuwanie pośrednich wskażników w prawo i tak długo aż
uzamy że obszar strony nie nadaje się do użycia.
Po kolejnym zwiększeniu głównego wskaźnika przeskakujemy na następną stronę
i znów "uśmercamy" komórki w kolejnej umownej stronie.
Przyjmująć 1 mln cykli zapisu komórek jako górną granicę żywotności, żeby
każdą komórkę w obszarze strony zapisać 1 mln razy liczniki zapisały by się
512 mln razy.
A w tym wykonaniu, mając 72 bajty na liczniki, z czego 4 bajty na wskaźnik
w obszarze strony i 3 lub 4 bajty na licznik przepełnienia stron możemy
przesuwac się z licznikami 17 razy w prawą stronę, i zawsze mieć licznik
zapisywany w miare świeżej komórce.
Wychodzi że każdą stronę można zapisać 1mln / 512 * 17 czyli około 33 tyś
razy.
Można zmniejszyć ilość stron jednoćześnie zwiększajac obszar na liczniki i
uzyskac większą ilość zapisów.
Zostajew jeszcze drobny szczegół jeżeli zapis dochodzi do końca "żwywotu"
strony to należy zadbać żeby odczyt nastąpił z właściwej strony. Może trzeba
by zastosować osobne zestawy wskaźników do zapisu i odczytu.
Cała idea polega na tym żeby przesuwac się ze wskaźnikami do coraz to nowych
komórek a położenie tych wskaźników wyliczać na podstawie jednego lub 2
wskaźników głównych które będa na tyle rzadko zapisywane że nie powinny się
uszkodzić.
Z wyliczeń widać że ilość zapisów samych danych ni jak się ma do maksymalnej
wytrzymałości komórek. Wychodzi na to że należało by na wskaźniki
przesnaczyć praktycznie cały obszar pamięci :/ pozostawiając jedna stronę na
same dane.
Tutaj masz wszystko wyliczane na podstawie odczytu kilku komórek z czego 2
lub 4 pierwsze, któe musimy odzytać, znajdują się w stałym miejscu, a reszta
to dodawania i mnożenie.
Ale elaborat wysmarowałem ;) Myślę że nie walnąłem się w założeniach.
Pozdr. Gejzero
Następne wpisy z tego wątku
Najnowsze wątki z tej grupy
- Rapsberry Pi i synchronizacja plików
- RCD 300 mA
- rpi i moduł przekaźników
- Falownik do pompy CO
- Lampa ogrodowa rozłączała różnicówkę
- Inteligentne oświetlenie schodów
- Pytanie do Użytkownika
- Emanuel kiedyś szukał gotowca do chłodzenia leków
- Sprzęty z Lidl-a
- idzie nowe
- Wybuchające pagery
- Jak shakować windę
- Sterowanie bezprzewodowe do wbudowania
- NC vs NO
- Jak dzięki mojemu pomysłowi amerykańce z Google przyspieszyli TV
Najnowsze wątki
- 2024-09-30 Rozprawa zdalna brak komputera
- 2024-09-30 Zielona Góra => Spedytor międzynarodowy <=
- 2024-09-30 Hackowanie SS7
- 2024-09-30 Seba strikes back
- 2024-09-30 MĂźnchen => DevOps Engineeer (Azure) <=
- 2024-09-30 MĂźnchen => DevOps Engineer (Azure) <=
- 2024-09-30 Gdańsk => Frontend Developer (Angular area) <=
- 2024-09-30 Warszawa => Spedytor Międzynarodowy <=
- 2024-09-30 Marki => Senior PHP Symfony Developer <=
- 2024-09-30 Warszawa => Technical Leader (Java Background) <=
- 2024-09-30 Warszawa => Key Account Manager <=
- 2024-09-30 Warszawa => Key Account Manager <=
- 2024-09-30 Białystok => Full Stack .Net Engineer <=
- 2024-09-30 Kraków => Ruby Backend Developer <=
- 2024-09-30 dziki wschod