Jak skutecznie i bezpowrotnie skasować pamięć flash? Metody i ich efektywność

Mon Jan 22, 2007 3:22 pm   

Newsuser "Marek Lewandowski" <locust@poczta.onet.pl> wrote:

Zależy jakiej pamięci. Jeśli używamy tej pamięci jako Random Access to
owszem. Ale jeśli jako pamięci masowej, to IMHO pomysł wart jest rozważenia.


Czy ktoś postulował by inaczej podawać?


Zawierają informację z której można zrobić użytek.


.... który można, przy nieco bardziej abstrakcyjnym podejściu, potraktować
jako liczbę.


Ot, taki eksperyment myślowy.


Do czego się odnosisz? :-)


Nie było moją ambicją, by mój eksperyment myślowy miał poparcie w
konkretnych przykładach. Ot, pokazałem uproszczeony model sytuacji, którą
uznałem za możliwą.
Atakujesz rzeczy oczywiste.
Myślę, że dyskusja była by ciekawsza, gdybyś atakował moje założenia, nie
tylko za to, że są założeniami, ale bardziej merytoryczne np.
zaproponowałbyś swoje założenia, które uznajesz za bardziej zgodne z
rzeczywistością.


Nie było moją intencją uzyskać zgodność z zacytowanym hardwarem.
Jeśli chodzi o zacytowanego Winbonda, to i tu można się pokusić o szacunki,
o ile w nocie katalogowej podano odpowiednie dane (np. szumy).
W wolnej chwili, o ile najdzie mnie ochota, mogę przejrzeć ową notę
katalogową i policzyć co nieco. A może ktoś inny się skusi na obliczenia?

pzdr
mk

Mon Jan 22, 2007 3:52 pm   

mk wrote:


?!@?
Nagle samo to, że danych jest dużo, pozwala je przekłamać?
Jako pamięć analogowa się te rozwiązania świetnie sprawdzają. Ale
założenie, że można z nich wyciągnąć 8bit/celę jest z sufitu.


Wiesz co, na marketingowca się kształć, dobry będziesz.
Każda pamięć jest specyfikowana względem użytecznej pojemności.
Jak masz 64k flasha, to to jest 64k do twojego użytku, a nie 64k z
których musisz sobie wyliczyć te dobre.


ale nie tę zapisaną informację! Na litość....


całkowitą? Zależną od czego? Sprowadzając analizę do wartości
zapisanej zignorowałeś błędy wzmacniaczy zapisu, pojemności
pasożytniczych wokół bramki itp itd.


Równie dobrze możesz założyć, że odczytasz to samo. A tym czasem
wykręcasz kota ogonem, bo ja się odniosłem do konkretnej wypowiedzi,
na temat pojemności bit/celę współczesnych pamięci analogowych (a
nawet w szczególności Winbonda). Możesz równie dobrze założyć,
że za 10 lat wynaleziony zostanie materiał z silnie zdyskretyzowanym
i stabilnym zestawem stanów energetycznych i na 10 atomach da się
zapisać 10 bitów. Tyle, że nie ma to nic wspólnego z kwestią, że
wykorzystanie pamięci analogowej do przechowywania danych cyfrowych w
obecnej technologii ani nie ogranicza się do dodania ADC, ani nie daje
pojemności nawet w okolicy bajta na celę.


do danych technicznych pamięci Winbonda.


i to jest problem.


innymi słowy: jak przychodzi do konkretów, to nie wiadomo, gdzie
zacząć liczenie, ale hasłami porzucać zawsze można?

--
Marek Lewandowski
ICQ#/GG#: ask per mail. mail: locust[X]poczta/onet/pl
my gallery: http://www.pbase.com/mareklew
my kind-of-a-blog: http://lockaphoto.stufftoread.com

Mon Jan 22, 2007 5:30 pm   

Newsuser "Marek Lewandowski" <locust@poczta.onet.pl> wrote:


Łatwo dodać warstwę, która przekłamania (z akceptowalnym
prawdopodobieństwem) wyeliminuje.


Tak.
Jest wzięte z sufitu.
Tak samo jak to, że nie można z nich wyciągnąć 8bit/komórka
Tak samo jak to, że być może w przyszłości nie będzie można...
W każdym razie nie wykazałeś tego jeszcze w tej dyskusji.


Przepraszam, ale źle zrozumiałem pojęcie "surowych bitów". Miałem na myśli
"użyteczne bity".

Dajmy na to kupujesz pamięć flash 64kB. Dane odczytujesz blokowo.
Wewnątrz kostki jest np. 80k komórek pamięci, by zmieściły się dane
nadmiarowe. Wewnątrz układu scalonego znajduje się również moduł dokonujący
niezbędnych korekcji podczas odczytu pamięci. Na zewnątrz podawane są już
skorygowane dane.

Podobnie jest ze współczesnymi dyskami twardymi, na nośniku informacje są
zapisywane wielowartościowo, a przy odczycie jest sporo błędów. Dzięki danym
nadmiarowym nie ma problemu, a na zewnątrz jest już czysto. Ot, wewnętrzne
sprawy dysku twardego.


Tu dyskusja jest już czysto scholastyczna.


Zależną od zapisywanych danych wejściowych.


Potraktowałem proces zapisu-odczytu jako czarną skrzynkę.


Nie równie dobrze. W dyskusji padła kwestja, że jeśli nie odczytamy
dokładnie tego samego, co zapiszemy, to pamięć dla danych binarnych jest
bezużyteczna.


Owszem, odniosłeś się. Poproszę teraz, o małe co nieco, na poprcie swojej
tezy.


Czy ktoś w tej dyskusji podnosił kwestię, ze wykorzystanie pamięci analgowej
do przechowywania danych cyfrowych ogranicza się do dodania ADC???


Pokusisz się o dowód?


To fajnie, że uważasz. Mnie tam intuicja mówi, że z 5 bitów to się z tego
Winbonda wyciśnie, nie zdziwię się jeśli więcej...


Wybacz, ale nie o to tu chodzi, byśmy sobie zaczęli udowadniać, który z nas
ma dłuższego, takiego, czy innego, penisa.
Najzwyczajniej, ja w tym wątku toszkę obliczeń zrobiłem. Jako miłośnicy
odkrywania faktów, dzielmy się pracą w miarę po równo. Nie o "manie racji"
tu chodzi. Nie uśmiecha mi się też perspektywa bycia chłopcem do odrabiania
prac domowych.
Dla mnie, amatora, obliczenia te wydają się być w zasięgu, pod warunkiem, że
w nocie znajdę odpowiednie dane np. szum w sygnale po retencji (ojej! pewnie
trzeba będzie założyć, że jest gaussowski, bo kto by tam o takim detalu
wspomniał w dokumentacji - znowu będzie można zbić całe obliczenia).

pzdr
mk

Mon Jan 22, 2007 5:48 pm   

"Marek Lewandowski" <locust@poczta.onet.pl> wrote in message
news:1169472157.139496.295050@q2g2000cwa.googlegroups.com...
PAndy wrote:


bajt=8bit.

np a wiec nie twierdzil tylko na przyklad - rozumiem ze odrozniasz luzna
idee ktora trzeba zweryfikowac od czegos co absolutnie nie jest realne -
nie wiem tego ja, nie wiesz tego Ty.


ale ta pamięć nie składa się z ,,analogowego scalaka winbonda i
przetwornia adc'' bo, jak napisałem, tego typu pamięć odtwarza co
innego niż zapisała. Mam powtarzać ci post po poście całą
kwestię, czy jednak uzyjesz gugla? A jak jesteś mądry z hasłami
teorii informacji, to je zastosuj i zobacz, ile bitów na celę da się
zapisać w tym Winbondzie.

umowmy sie ze dopoki nie udowodnisz ze jest to niemozliwe to tak samo
jest to prawdopodobne - trzeba by zrobic sobie eksperyment - jesli
chcesz zrob go - wierze ze podejdziesz do neigo obiektywnie - o wynikach
z duza przyjemnoscia przeczytam :)

O ile rozmawiamy o ideii to jest ona jak najbardziej sluszna bo obaj
wiemy ze realizowana w praktyce...

Mon Jan 22, 2007 7:35 pm   

Newsuser "Marek Lewandowski" <locust@poczta.onet.pl> wrote:

Wystarczyło pogooglać:
(4b/cell)
http://www.imec.be/esscirc/ESSCIRC2002/presentations/Slides/C05.03.pdf

(6b/cell; niestety trzeba mieć dostęp do dokumentów IEEE)
http://www.google.com/search?q=+site:ieeexplore.ieee.org+analog+flash+memory+for+digital+storage&hl=en&lr=&start=0&sa=N

I jescze (niestety również tylko dla subskrybentów IEEE):
"256-Level Non-Volatile Analog Storage Device Using EEPROM Technology"
http://www.google.com/search?hl=en&lr=&q=+site%3Aieeexplore.ieee.org+analog+eeprom+256-level

pzdr
mk

Mon Jan 22, 2007 9:56 pm   

Marek Lewandowski napisał(a):


Jesteś pewien? I czy na każdej platformie?

--
Adam Dybkowski
http://www.amwaw.edu.pl/~adybkows/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

Mon Jan 22, 2007 10:22 pm   

Adam Dybkowski schrieb:

w międzyczasie tak. Kiedyś było 1 bajt == reprezentacja jednego znaku.
Mogło być 6 lub 12 bitów (CDC6000 i inne CDC z NOS/BE), PDP8 też chyba
12. PDP11 miało 8 bitów, choć reprezentacja znaku tam to 4.5 bita ;-)

Waldek

Tue Jan 23, 2007 12:13 am   

On Mon, 22 Jan 2007 22:22:17 +0100, Waldemar wrote:

Wtedy to sie chyba nazywalo znakiem, nie byte.

W kazdym badz razie specyfikacje sieciowe uzywaja slowa octet,
zeby nie bylo watpliwosci.

J.

Tue Jan 23, 2007 2:12 am   

Waldemar napisał(a):


Dlatego wprowadzono nazwę oktet, aby nie było wątpliwości.
BTW: 16-bitowe bajty można spotkać np. w niektórych texasowych DSPkach
jak TMS320VC5416, tam sizeof(char) = sizeof(int) = 1. A to wszystko
liczone w bajtach 16-bitowych.

--
Adam Dybkowski
http://www.amwaw.edu.pl/~adybkows/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

Tue Jan 23, 2007 2:17 am   

Hello Adam,

Tuesday, January 23, 2007, 2:12:56 AM, you wrote:


Zaraz chyba zawału dostanę. Nie mieszaj słowa z bajtem, bardzo proszę.
Octet to francowaty wynalazek ale oni nawet z komputera ordynatora
zrobili.

--
Best regards,
RoMan mailto:roman@pik-net.pl

Tue Jan 23, 2007 10:03 am   

Adam Dybkowski wrote:


tak i na każdej.
Słowo nie jest takie samo, znak (char) nie jest taki sam, ale bajt
tak.

Słowo najczęściej jest wielokrotnością bajtu, wyjątki są rzadkie
(np. PIC-e mają 12-bit słowo programu).
Znak jest 7, 8 albo n*8 bit (znowu: najczęściej, znaczy: nie z
definicji a z zasiedzenia).

--
Marek Lewandowski
ICQ#/GG#: ask per mail. mail: locust[X]poczta/onet/pl
my gallery: http://www.pbase.com/mareklew
my kind-of-a-blog: http://lockaphoto.stufftoread.com

Tue Jan 23, 2007 10:30 am   

mk wrote:


no właśnie ja twierdzę, że nie tak łatwo, żeby po odjęciu
nadmiaru wymaganego przez tę warstwę zostało więcej niż powiedzmy
3-4 bity. Dla tych obecnych na rynku pamięci analogowych.


a nie. Weź tę kość i obejrzyj
1. SNR
2. sygnał przy 0oC
3. sygnał przy 100oC

z podzielenia 2 przez 3 i policzenia dewiacji już poleci parę bitów.


tego nie twierdziłem, powiedziałem tylko Leszkowi, że wątpię.


Nie ja postawiłem postulat 8 bitów z ADC podpietego do pamięci
analogowej.



Czyli po odjęciu korekcji błędów. Ile zostanie?


dokładnie, ale dlatego nie stoi, że dysk zapisuje 4 czy 8 bitów na
domenę magnetyczną, tylko że zapisuje np. 250GB na ,,dysk''. To jest
netto, po odjęciu korekcji.


nie jest. Informacja może być użyteczna, jest użyteczna - dźwięk
daje się rozpoznać, szum i zniekształcenia amplitudy są filtrowane
w naszym mózgu, ale dane muszą być odczytane wiernie, więc bez tej
psychoakustycznej korekcji.


zapomniałeś o zależności od wszystkich czynników analogowych
związanych z zapisem i z samym nośnikiem zapisu. Zastanów się,
załóżmy - eksperyment myślowy - że zamrażasz wartość napięcia
0..255mV ~ 0..255. Załóż, że wzmacniacz zapisu i wzmacniacz odczytu
dopasowane są względem wzmocnienia do +/-1%. Dla sygnału analogowego
pestka, jaki masz błąd przy odczycie ,,cyfrowym''?


i to jest właśnie Twój błąd, bo gdyby ten proces był tak
stabilny, jak zakładasz, to pakowalibyśmy po 7 bitów na celę. Nie
jest. Nie pakujemy.


dokładnie tak jest. Jeśli masz n bitów których nie możesz
odczytać dokładnie, to pamięć jest bezużyteczna. Możesz dodać
mechanizmy korekcji ale juz nie masz n bitów, więc nie możesz
twierdzić, że pamięć ma pojemność n bitów.


popatrz nieco wyżej w poście - już SNR powinien załatwić kwestię
bit na różowo, błąd wzmocnienia w funkcji temperatury jest
silniejszym czynnikiem, ale nie pamiętam, czy jest podawany w danych w
dataszicie.


tak. To post, od odpowiedzi na który usiłujecie zrobić ze mnie
wielbłąda.
,,Możliwe. Firma Winbond robi dość powszechnie znane układy do
rejestracji
dżwięku, które zapamiętują analogowo wartość napięcia
poszczególnych
próbek, czyli działają jak rejestr układów
próbkująco-pamiętających
(S-H). Wystarczy dodać przetwornik C-A na wejście i A-C na wyjście i
już
mamy pamięć w której jedna komórka ma np. bajt.''


jak tylko autor, lub ktoś popierający zacytowaną tezę, podeprze ją
jakąś matematyką.



5 < 8.
różnica 20dB w SNR jeśli w łepie dobrze liczę.


o, fajnie.


ale nic odnoszącego się do konkretnego problemu.
..

Gorzej. Poza szumem masz dryft wzmocnienia w f-cj temperatury i wpływ
jej, oraz czasu na zachowany ładunek. TEGO brakuje w przjętym modelu
zakładającym wąski błąd na poziomie 1bit.
Masz też stały w czasie szum wynikając z różnych parametrów cel,
ale ten jest akurat łatwo modelowalny.

Na koniec: nie oczekuję od Ciebie zrobienia tego modelu. To jest temat
na publikację naukową, a nie na posta w newsgrupie. Szacunek
5bit/celę wydaje się możliwy do zrealizowania, 4bpc uważałbym za
realistyczny. Szacując tylko po realnym stosunku sygnał/szum w takich
kościach.

--
Marek Lewandowski
ICQ#/GG#: ask per mail. mail: locust[X]poczta/onet/pl
my gallery: http://www.pbase.com/mareklew
my kind-of-a-blog: http://lockaphoto.stufftoread.com

Tue Jan 23, 2007 10:36 am   

mk wrote:


4 bity i bajt to 2x...


jest w produkcji? Bo ostatnie, co widziałem (nie mam konta IEEE) to
był projekt struktury typu proof-of-concept, czytaj ze cztery cele na
krzyż...


masz konto?
Ale nieważne: już tytuł mówi o pamięci analogowej i nie używa
pojęcia bitu, tylko liczby poziomów, podejrzewam, że chodzi o
,,normalną'' pamięć analogową, czyt. 256 poziomów bez ścisłości
ile to jest 1 poziom. Do audio OK.

--
Marek Lewandowski
ICQ#/GG#: ask per mail. mail: locust[X]poczta/onet/pl
my gallery: http://www.pbase.com/mareklew
my kind-of-a-blog: http://lockaphoto.stufftoread.com

Tue Jan 23, 2007 11:39 pm   

RoMan Mandziejewicz napisał(a):

http://pl.wikipedia.org/wiki/Bajt_(informatyka)
http://pl.wikipedia.org/wiki/Oktet_(informatyka)

A zgodnie z definicją słowa kluczowego sizeof w języku C zwraca rozmiar
argumentu liczony w bajtach i nic na to nie poradzisz:
"The sizeof operator is a compile-time operator that returns the size,
in bytes, of the argument passed to it."
http://www.cppreference.com/keywords/sizeof.html
albo po polsku:
http://4programmers.net/C/Sizeof


Romanie, kto jak kto ale Ty powinieneś bardzo dobrze znać nomenklaturę
stosowaną w dokumentacji np. protokołów sieciowych. Poczytaj pierwszy z
brzegu dokument RFC (w języku angielskim a nie francuskim) - nie
znajdziesz tam prawie nigdzie słowa "byte", wszędzie występuje "octet"
właśnie po to, aby jednoznacznie identyfikować 8-bitową jednostkę
informacji. I nie mieszać w głowie programistom zajmującym się
procesorami, w których bajt natywnie nie ma 8 bitów.

--
Adam Dybkowski
http://www.amwaw.edu.pl/~adybkows/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

Wed Jan 24, 2007 12:58 am   

Hello Adam,

Tuesday, January 23, 2007, 11:39:16 PM, you wrote:

[...]


Wikipedia nie jest nieomylną wyrocznią.

[...]

Nie przyjmuję do wiadomosci bajtów o wielkości innej niż 8 bitów,
podobniem, jak nie przyjmuję do wiadomości nowomodnych KiB'li i
MiB'li. Bajt to 8 bitów, 1 KB to 1024 B (ale 1 kB to 1000 B) a 1 MB to
1024 KB.

Odwołanie do architektury procesorów jest błędne - od dość dawna nie
ma związku pomiędzy słowem maszynowym a szerokością szyny. A nawet jak
był, to szerokość szyny danych określano nazwą "słowo maszynowe".

--
Best regards,
RoMan mailto:roman@pik-net.pl