Jump to content

    

Алгоритм стирания Флеш. Алгоритм выравнивания износа при записи данных

Recommended Posts

mantech
4 часа назад, TViT сказал:

Что будет физически во флеш FF везде? Ну кроме например сбойного бита или байта не важно.

Ну так и будет, вот представьте себе, флеш организован в виде матрицы, на строку подают напряжение стирания, весь заряд сбрасывается на всей строке, не важно, были там сбойные ячейки или нет. Сбой - это просто заряд, 1, но по уровню, почти или чуть ниже значения 0, это если SLC ячейка. Поэтому все и сотрется одновременно.

Share this post


Link to post
Share on other sites

Eddy_Em
36 minutes ago, jcxz said:

В современных МК объём флеша таков, что хватит нескольких миллисекунд чтобы весь его прочитать

Ложь. Даже через st-link прошивка каждых 10кБ длится достаточно долго.

Share this post


Link to post
Share on other sites

makc
20 минут назад, Eddy_Em сказал:

Ложь. Даже через st-link прошивка каждых 10кБ длится достаточно долго.

Вы путаете запись, требующую стирания, и чтение. @jcxz написал именно о чтении и если считать рабочей частоту флеша 25 МГц, а ширину его шины не менее 4 байт, то время чтения посчитать совсем несложно. Сколько получается требуется на чтение 256 кБайт? ;-)

Share this post


Link to post
Share on other sites

TViT
22 минуты назад, mantech сказал:

Поэтому все и сотрется одновременно.

Как же одновременно если построчно стирается? (" на строку подают напряжение стирания, весь заряд сбрасывается на всей строке" ) Иначе почему процесс стирания такой долгий. Тогда бы вся страница параллельно стерлась бы? А если построчно, то что сделает контроллер когда определенная строка не стерлась? Идет дальше стирает остальные строки и уже потом на верхнем уровне функция стирания проверяет регистр состояния и выкидывает ошибку? Типа там где-то при стирании не дотерлось... И тогда при таком раскладе действительно можно предположить что FF везде кроме сбойных мест.

Share this post


Link to post
Share on other sites

mantech
27 минут назад, TViT сказал:

Как же одновременно если построчно стирается?

Это я привел для аналогии. Строка бывает по неск. килобайт. И еще их объединяют в блок.

Edited by mantech

Share this post


Link to post
Share on other sites

jcxz
4 часа назад, Eddy_Em сказал:

STM32F103CBT6. Прошивка на 10кБ, остальное - под эмуляцию EEPROM. Длина блока была то ли 16, то ли 20 байт. Если забить "до упора", то линейный поиск проходил почти 5 секунд: считали блок, проверили, потом считали следующий... В случае бинарного поиска хватало меньше 15 проверок!

Судя по даташиту, на линейное чтение всей флешь этого МК единой транзакцией нужно: 128*1024/(24e6*8) = ~683мкс. Если я правильно понял написанное в даташите. Конечно - в реале будет немного больше из-за накладных расходов на организацию цикла и на операции сравнения и на неоптимальность частоты тактирования и т.п.. Но всё равно - я даже примерно не могу представить как можно умудриться затормозить эту процедуру в 7324 раза!!!

Ну в 2, 3, ну в 10 раз - ещё куда ни шло. Но не в 7324 раза, Карл!!! Вы видимо очень старались.  :biggrin::biggrin::biggrin:

4 часа назад, jcxz сказал:

В современных МК объём флеша таков, что хватит нескольких миллисекунд чтобы весь его прочитать.

4 часа назад, Eddy_Em сказал:

Ложь. Даже через st-link прошивка каждых 10кБ длится достаточно долго.

Включите голову хоть на несколько секунд! Причём тут прошивка, когда речь о чтении???

Вы понимаете разницу между чтением и стиранием/записью? Нет?  :unknw:

3 часа назад, TViT сказал:

А если построчно, то что сделает контроллер когда определенная строка не стерлась? Идет дальше стирает остальные строки и уже потом на верхнем уровне функция стирания проверяет регистр состояния и выкидывает ошибку?

Не знаю как в STM32, но в XMC4xxx процесс стирания 256K-сектора занимает до <=5.5сек. Но этот МК умеет формировать биты статуса результата стирания. Может именно поэтому там такой длительный процесс стирания. И проверка качества стирания там похоже состоит не в простом обратном чтении, а что-то более сложное делается.

Share this post


Link to post
Share on other sites

Eddy_Em
4 hours ago, makc said:

Сколько получается требуется на чтение 256 кБайт? ;-)

1) Считали 32 байта. 2) Проверили magick. 3) Не годится? Перешли к п. 1).

А если блоки еще более мелкие, то это затянется еще сильней!

И да, может, я запускаю процедуру чтения до инициализации тактирования? =D

Edited by Eddy_Em

Share this post


Link to post
Share on other sites

makc
52 минуты назад, Eddy_Em сказал:

1) Считали 32 байта. 2) Проверили magick. 3) Не годится? Перешли к п. 1).

А если блоки еще более мелкие, то это затянется еще сильней!

И да, может, я запускаю процедуру чтения до инициализации тактирования? =D

Вангую, что если вставить в цикл чтения вызов delay_ms(1000); то будет ещё медленнее, но мы говорили не об этом, а о возможной максимальной скорости чтения флеша. Так что смысл вашего примера я не понял, если только это не ещё один совет из известной книги Остера для начинающих эмбеддеров. ;-)

1 час назад, jcxz сказал:

Включите голову хоть на несколько секунд! Причём тут прошивка, когда речь о чтении???

И причем здесь st-link тоже непонятно.

Share this post


Link to post
Share on other sites

amaora

Не очень понимаю как использовать эти неизвестные аппаратные особенности стирания. Если возвращается статус cтирания, то могут быть какие-то стратегии его использования. Но для чего знать как именно контроллер "недотрет" битый сектор? В любом случае будет программный контроль целостности данных.

Edited by amaora

Share this post


Link to post
Share on other sites

Eddy_Em
18 minutes ago, makc said:

И при чем здесь st-link тоже непонятно.

При том, что он дает наибольшую скорость записи. Бутлоадер через USART1 немного помедленней. А уж ждать, пока прошьется по DFU — вообще ужас!

Share this post


Link to post
Share on other sites

makc
1 час назад, Eddy_Em сказал:

При том, что он дает наибольшую скорость записи. Бутлоадер через USART1 немного помедленней. А уж ждать, пока прошьется по DFU — вообще ужас!

По-моему вы не видите разницы между тормозами транспорта данных и собственно скоростью стирания/записи данных во флеш-память. А это две большие разницы, если судить по элементарным расчетам и ваши собственные слова лишь подтверждают этот тезис.

Share this post


Link to post
Share on other sites

mantech
04.05.2022 в 21:19, makc сказал:

По-моему вы не видите разницы

Там просто не вопрос о командных строках, вот и поплыл наш гуру)))))))

04.05.2022 в 19:50, amaora сказал:

Если возвращается статус cтирания, то могут быть какие-то стратегии его использования.

Статус стирания -это просто флаг завершения процесса стирания блока или всего флеша, и все, нужен просто для того, чтобы не ждать неск. секунд от балды, а только то время, которое необходимо внутренней логике.

Share this post


Link to post
Share on other sites

Arlleex
35 минут назад, mantech сказал:

...нужен просто для того, чтобы не ждать неск. секунд от балды, а только то время, которое необходимо внутренней логике.

А когда все такие флаги умеют формировать прерывания - вообще сказка для программиста.

Share this post


Link to post
Share on other sites

mantech
1 час назад, Arlleex сказал:

А когда все такие флаги умеют формировать прерывания

Я думаю умеет, но не использовал никогда, т.к. запись процесс сам по себе медленный, проще поллить в своем потоке не отвлекая других))

Share this post


Link to post
Share on other sites

Arlleex
5 минут назад, mantech сказал:

Я думаю умеет, но не использовал никогда, т.к. запись процесс сам по себе медленный, проще поллить в своем потоке не отвлекая других))

Может и так:smile: В своих крайних проектах (не сложных) у меня нет RTOS вытесняющей; там вместо нее самописный переключатель задач (считай суперцикл), и вот там нельзя тупить на время стирания/записи. Вот и очень удобно по прерываниям работать.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.