Harici Flash Üzerine Dosyalama Sistemi

Başlatan volkanunal, 11 Eylül 2019, 10:21:37

volkanunal

Merhabalar ,

Harici flash üzerinde bir dosyalama sistemi kuracağım. Daha önce böyle bir çalışma yapan var ise şunları sormak istiyorum.

Bunun için hangi modülü kullandı ? Eğer FatFS kullandıysanız , dezavantajını gördüğünüz herhangi bir nokta oldu mu ?

Primum nil nocere

SpeedyX

Merhaba,

Hem FS hem kendi geliştirdiğim birçok yapıyı kullandım. Fat veya diğer FS lerin dezavantajı, hafızayı verimsiz kullanmalarıdır. Bir block 512 byte tanımlıysa ve sizin dosya 10 byte ise geçmiş olsun, o 512 byte yer ayrılıyor ve hep boş kalıyor. Bunu da daha verimli kullanmanın yolları var (struct gibi) fakat onlar da bu sefer aynı hücreye daha çok yazma gerektirip chipin ömrünü kısaltıyolar.
O yüzden bazen kendi yazdığım mekanizmaları kullandım ki FS lib ile çözeceğim diye gidip flash chipinin 2 boy büyüğünü aramayayım.

Amaca göre seçim geliştiricinin.

kantirici

Merhaba,
Dosya sistemi için öncelikle yüksek bir kapasite kullanmak gerekir. Daha sonra kullanılan hazıfa tipine göre dosya sistemi belirlenmelidir. Spi flashlar Fat dosya sistemi ile kullanılmaya uygun değiller. Fat table'a çok yazma yapıldığından Fat tablet sektörü hızlıca ömrünü dolduracaktır. Arm'ın open source olarak geliştirdiği littlefs spi flashlar için uygun bir çözüm.sayfasını incelerseniz size başka open source seçeneklerde sunuyor.ayrıca Spi flashın hücre tipide dosya sistemi seçiminde rol oynamaktadır.

volkanunal

Alıntı yapılan: SpeedyX - 11 Eylül 2019, 15:41:27Merhaba,

Hem FS hem kendi geliştirdiğim birçok yapıyı kullandım. Fat veya diğer FS lerin dezavantajı, hafızayı verimsiz kullanmalarıdır. Bir block 512 byte tanımlıysa ve sizin dosya 10 byte ise geçmiş olsun, o 512 byte yer ayrılıyor ve hep boş kalıyor. Bunu da daha verimli kullanmanın yolları var (struct gibi) fakat onlar da bu sefer aynı hücreye daha çok yazma gerektirip chipin ömrünü kısaltıyolar.
O yüzden bazen kendi yazdığım mekanizmaları kullandım ki FS lib ile çözeceğim diye gidip flash chipinin 2 boy büyüğünü aramayayım.

Amaca göre seçim geliştiricinin.

Kendi geliştirdiğiniz yapı içerisinde nasıl bir wear-leveling algoirtması koşturudunuz acaba?

Alıntı yapılan: kantirici - 11 Eylül 2019, 18:46:57Merhaba,
Dosya sistemi için öncelikle yüksek bir kapasite kullanmak gerekir. Daha sonra kullanılan hazıfa tipine göre dosya sistemi belirlenmelidir. Spi flashlar Fat dosya sistemi ile kullanılmaya uygun değiller. Fat table'a çok yazma yapıldığından Fat tablet sektörü hızlıca ömrünü dolduracaktır. Arm'ın open source olarak geliştirdiği littlefs spi flashlar için uygun bir çözüm.sayfasını incelerseniz size başka open source seçeneklerde sunuyor.ayrıca Spi flashın hücre tipide dosya sistemi seçiminde rol oynamaktadır.

Kullanacağım model bu  W25N01GV  ve 1G-bit hafızaya sahip. NAND yapısında. Geçtiğimiz günlerde littlefs'i oldukça inceledim. Fatfsden ziyade daha çok aklıma yatan bir dosyalama sistemi yapısına sahip. Aynı zamanda wear-leveling testlerinde yapılan karşılaştırmalarda fatfs'in kafasına vurmuş.
Primum nil nocere

SpeedyX

Alıntı yapılan: volkanunal - 16 Eylül 2019, 10:29:22Kendi geliştirdiğiniz yapı içerisinde nasıl bir wear-leveling algoirtması koşturudunuz acaba?
Sık yazma yapılmayanlarda hiç kullanmadım, diğerlerinde dinamik.
Bazen tüm alanı dosya adedi kadar bölüme ayırıp, bölüm boyutlarını da dosya boyutu ve yazma sıklıklarını düşünerek belirleyip, dosyalara birer yazma numarası atayarak circular olarak o bölümlerde döndürdüm. Okurken ise ilk seferinde arama yaptım ve son noktayı ram değişkenine kaydettim, cihaz aktifken bir daha arama yapmama gerek kalmadı.

volkanunal

Alıntı yapılan: SpeedyX - 16 Eylül 2019, 14:06:28Sık yazma yapılmayanlarda hiç kullanmadım, diğerlerinde dinamik.
Bazen tüm alanı dosya adedi kadar bölüme ayırıp, bölüm boyutlarını da dosya boyutu ve yazma sıklıklarını düşünerek belirleyip, dosyalara birer yazma numarası atayarak circular olarak o bölümlerde döndürdüm. Okurken ise ilk seferinde arama yaptım ve son noktayı ram değişkenine kaydettim, cihaz aktifken bir daha arama yapmama gerek kalmadı.

Bu çalışmalarınızı açık kaynak olarak paylaştığınız bir platform var mıdır ?  İncelemek istiyorum.
Primum nil nocere

SpeedyX

#6
Alıntı yapılan: volkanunal - 16 Eylül 2019, 15:09:29Bu çalışmalarınızı açık kaynak olarak paylaştığınız bir platform var mıdır ?  İncelemek istiyorum.
Malesef, fakat zaten daha iyi çözümler internette açık kaynak olarak mevcut. Sadece ihtiyacı doğru tespit edebilmek gerekiyor.

volkanunal

Kullandığınız part numarası nedir acaba ,  kullanmayı düşündüğümüz part numarası ile datasheet açısından karşılaştırma yapmak açısından soruyorum.

Kullanmayı düşündüğümüz (https://www.winbond.com/resource-files/w25n01gv%20revg%20032116.pdf)

Bir page'i sildiğinizde komple blok silindiğini farkettik. Datasheet içerisinde sadece "block erase" komutu var. O da 128kb , her pagede 2048byte var ve 64 page -> 1blok yapmakta. Yani 128kb. Bu durum bizi kuşkulandırdı açıkcası.

Sizin kullandığınızda , sector ya da farklı boyutlarda block silme özelliği var mıydı e.flashın , herhangi bir FS'in yukarda ki durumu handle edemeyeceğini düşünüyorum.
Primum nil nocere

RaMu

#8
Alıntı yapılan: SpeedyX - 16 Eylül 2019, 15:39:41...
Sadece ihtiyacı doğru tespit edebilmek gerekiyor.
Önemli nokta bu.
Ne için kullanacaksın,
ne sıklıkta ne boyutta okuma yazma işlemlerin olacak,
bunları değerlendirmek lazım.

Silme boyutu o kadar önemli değil,
dosya sistemlerinde gerçek silme işlemi yapılmaz,
ayırma birimi boyutu kadar olan FatFs de misal sd kart ta block diye geçen 512 byte minumum boyutlu hafıza kısımlarını düşünelim,
bu 512 byte lık bloğun ilk karakteri boş anlamında işaretleniyor
(0xED idi herhalde)
yani silme işlemi yapılmıyor
1 byte yazma yaparak silinmiş gibi gösteriliyor.
Örneğin dosya kurtarma programları bu durumu kullanarak silinen bilgileri
eğer o bölümlere tekrar yazma yapılmadıysa geri bulabiliyor.

Yani kullanacağın hafızanın minimum yazma boyutu ne bu daha önemli.

Şimdi datasheete baktım üstünkörü,
pek iç açıcı değil,
Alıntı yapılan: undefined8.2.11 Load Program Data (02h) / Random Load Program Data (84h)
The Program operation allows from one byte to 2,112 bytes (a page) of data to be programmed at previously
erased (FFh) memory locations. A Program operation involves two steps: 1. Load the program data into
the Data Buffer. 2. Issue "Program Execute" command to transfer the data from Data Buffer to the specified
memory page.

1 byte yazma yapılabiliyor ama
yazma yapmadan önce yazılacak yerin silinmiş olması yani önceden 0xFF olması gerekiyor.
Yinede daha detaylı bakmak lazım
belki bir çıkar yolu vardır diye ama zannetmem.

Biraz daha bakınca:
Alıntı YapThe W25N01GV 1G-bit memory array is organized into 65,536 programmable pages of 2,048-bytes each.
The entire page can be programmed at one time using the data from the 2,048-Byte internal buffer. Pages
can be erased in groups of 64 (128KB block erase). The W25N01GV has 1,024 erasable blocks.
128 megabayt hafızayı
128 kilobaytlık 1024 tane silinebilir parçaya ayırmışlar,
diğer taraftan bu hafıza
2048 byte lık 65536 tane yazılabilir parça olarak bölünmüş
ama yazmadan önce tabiki silinmiş olması gerekiyor.
Yazma silme sayısı 100000.

Yani 1024 tane 128 kilobaytlık herbiri 100000 defa yazılabilir hafızan var
işini görüyorsa.
Sorularınıza hızlı cevap alın: http://www.picproje.org/index.php/topic,57135.0.html

volkanunal

Evet @RaMu  hocam , minimum silme alanı bizim için iyi olmadı. Pad Konfigürasyonları aynı olan başka bir flash yapısına bakıyorum şu anda. Silme sadece block erase olarak karşımıza çıktı. Bahsettiğiniz gibi , 128kb block erase.
Primum nil nocere