[AlexandrY 3]

2 hours ago, iliusmaster said:

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

Какой-то нездоровый оптимизм.  Похоже невнимательно следите за публикациями на хабре.  
А почитайте-ка про Weird machine. Дело в том, что определенными воздействиями любую реальную программу можно заставить работать глючно.
Мне в этом плане понравилась вот эта статья- https://tcipg.org/sites/default/files/papers/2014_q3_tfs1.pdf
Мужики просто манипуляцией прерываниями заставляют контроллер выполнить нужный им код, которого изначально нет в прошивке.
И вычислить анализом кода этот баг невозможно.  

 

 

[Arlleex 131]

В голос орнул про "надо писать не глючное ПО". Явно троллинг.

По поводу алгоритмов записи. Вот есть интересная запись на хабре: https://habr.com/post/262163/

Мне понравилась идея с маркерами, то есть как отследить, что питание вырубилось в процессе записи данных.

[jcxz 184]

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

Мне понравилась идея с маркерами, то есть как отследить, что питание вырубилось в процессе записи данных.

А что сложного? Выделить один байт в заголовке записываемого блока. При записи блока выставить ему значение == значению стёртой ячейки флешь (предположим это 0xFF). После завершения записи блока выполнить запись поверх этого байта со значением != 0xFF (предположим это 0xFE). Теперь при старте ПО проверяем блок:

1) Если все байты блока имеют значение == 0xFF - блок чистый (не писался);

2) Если в блоке есть байты со значением != 0xFF и наш байт == 0xFE - блок записан полностью;

3) Если в блоке есть байты со значением != 0xFF и наш байт == 0xFF - был рестарт в процессе записи блока.

[Arlleex 131]

12 минут назад, jcxz сказал:

А что сложного?

В том и беда, что хотелось бы не читать все байты в блоке. А косвенными методами определить, было ли что-то записано в блоке или нет. Двухэтапное маркирование, приведенное в статье, ИМХО, довольно неплохой метод, при этом также очень похожий на Ваш.

[jcxz 184]

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

В том и беда, что хотелось бы не читать все байты в блоке. А косвенными методами определить, было ли что-то записано в блоке или нет. Двухэтапное маркирование, приведенное в статье, ИМХО, довольно неплохой метод, при этом также очень похожий на Ваш.

Ну можно изменить мой метод, добавив перед записью блока, запись в тот маркерный байт отдельного значения "старт записи" например == 0xFE, а после завершения записи блока - записывать в этот байт "завершение записи" == 0xFC. Тогда достаточно только этот байт прочитать. Но выигрыш от этого не велик, так как блоки всё равно лучше проверять на валидность при старте ПО (CRC, ...), а значит их нужно читать полностью по любому. А вот при записи 3 шага вместо 2-х - это уменьшение скорости записи. И чтение блока - операция очень быстрая, я в своих устройствах читал их с внешней флешь по dual-SPI на SCLK == 30МГц - время очень малое.

[iliusmaster 5]

Конечно это был троллинг:)))  Несмотря на него никто не отменял грамотного кодирования. При грамотной организации процесса написания кода, он - не глючит и выполняется так, как нужно. Siemens-ы и прочие Philips-ы в примеры приводить не нужно. Для многих их проектов код пишется в китайских и индусских компаниях, зачастую недостаточно качественно. Например, для томографов Philips, между прочим одних из лучших, весь софт управления и визуализации написан в Neosoft (https://www.neusoft.com/about/index.html), почитайте очень крупная компания, где многие гиганты индустрии заказывают.... Лично бывал там, реализуя совместный проект с их медицинским подразделением, и не сказал бы, что там звезды с неба хватают. Таких компаний много, особенно тех, что поменьше. . В России есть некоторые. Потому ссылаться на то, что какие-то ПЛК Siemens глючат - моветон. Программное обеспечение то написано неизвестно кем.

А потом  вы все смешали в кучу и ошибки в информации и описании новых компонентов и ошибки топологии кристалла и ошибки самой программы. Так вот баг прошивки - это ошибка прошивки. Баг топологии кристалла -это баг топологии кристалла. И не надо это все в одну кучу складывать. Алгоритмы работы - это алгоритмы работы и они к прошивке не имеют отношения  это ошибки разработчиков алгоритмов. 

А мои проекты все сверхсекретные, спрятаны на флешке, флешка в яйце, яйцо в утке.... ну и далее по тексту. 

[haker_fox 60]

5 hours ago, iliusmaster said:

И не надо это все в одну кучу складывать.

Ну, во-первых, не нужно троллить в ветке, отличной от "Общения". Тогда наш разговор уже давно бы стал конструктивным.

Во-вторых, вы сделали заявление, что

Quote

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

Я понимаю, что это не мне адресовано. Но! Ответить я на это был вправе. Хорошо, отбросим проблемы с ерратами микросхем. Но безбажную прошивку для более-менее сложного объекта написать всё равно проблематично. Хотя бы по причине, указанной iosifk. И вы просто не будете в курсе как правильно расставить эти базовые основные команды для неполностью изученного физического объекта.

[controller_m30 1]

Попалась как-то в руки книжка от разработчиков NTFS. И там детальное описание механизма отказоустойчивых дисковых операций (перезапись файла, копирование, удаление).

В общих чертах, на примере перезаписи уже существующего файла "File.dat".

1. В журнале делается запись о намерении перезаписать файл "File.dat".

2. В журнал заносится последовательность запланированных операций: записать тело файла на свободное место, изменить FAT1, изменить FAT2, добавить в каталог новую файловую запись "File.dat", пометить прежний файл "File.dat" как удалённый, удалить данные о нём из FAT1, удалить из FAT2. Готово.

3. Операции выполняются одна за другой по плану, при этом каждая отмечается в журнале как начатая, или как завершенная.

4. При успешном завершении всех операций делается отметка о завершении главной задачи - перезаписи файла.

5. Журнал очищается.

 

В случае перезапуска компьютера, анализируется журнал (не блоки данных!), и по его состоянию принимается решение либо о продолжении запланированных операций, либо об откате к предыдущему состоянию файлов на диске.

Журнал ведётся в двух экземплярах, с номерами 0 и 1 - чтобы всегда была копия, на случай отказа системы во время обновления самого журнала.

[haker_fox 60]

1 hour ago, controller_m30 said:

Попалась как-то в руки книжка от разработчиков NTFS

А не поделитесь?)))) Если в электронном виде доступна...

А за описание алгоритма - спасибо!!!! Интересный подход!

[jcxz 184]

15 минут назад, haker_fox сказал:

А за описание алгоритма - спасибо!!!! Интересный подход!

Когда я писал про то, как сделать FatFS устойчивой к сбоям, я имел в виду подобный метод. Вроде в нём нет никакого ноу хау - всё само собой очевидно. Не раз реализовывал системы хранения подобным образом. Главное правило тут: любая небезопасная операция модификации носителя, должна быть журналируемой (перед её началом должна быть сделана в журнале запись о её начале, содержимое и последовательность планируемых операций, в процессе операции в журнале должно бэкапиться всё содержимое перезаписываемых поверх областей, а после завершения - запись удалена). Небезопасные операции модификации - все операции, которые, будучи прерваны, приведут к нарушению логической структуры хранения на носителе. Примерно так.

[controller_m30 1]

1 hour ago, haker_fox said:

А не поделитесь?)))) Если в электронном виде доступна...

Увы, я читал её ещё в бумажном виде 

Книга называется "Хелен Кастер. Основы Windows NT и NTFS", 1996. 

Изменено 16 ноября, 2018 пользователем controller_m30

[psyhologic 0]

Я бы присмотрелся на вашем месте к SQLite WAL. https://www.sqlite.org/wal.html

Мы активно используем под embedded Linux для задач, с возможной потерей данных (aka. power off)

[AlexandrY 3]

22 minutes ago, psyhologic said:

Мы активно используем под embedded Linux для задач, с возможной потерей данных (aka. power off)

Да все эти потери из-за дешевых SD карт. На хорошей карте вы и FAT замучаетесь убивать. 
 

[Arlleex 131]

Только что, AlexandrY сказал:

Да все эти потери из-за дешевых SD карт. На хорошей карте вы и FAT замучаетесь убивать. 
 

Целостность данных в файловом представлении в момент выключения питания от качества карты не зависит ровно никак.

[AlexandrY 3]

5 minutes ago, Arlleex said:

Целостность данных в файловом представлении в момент выключения питания от качества карты не зависит ровно никак.

Эт в теории.
А на практике качество карты имеет самое большое значение.
У меня есть карты полность вышедшие из строя или с полностью поврежденной файловой системой. Просто сбоем при записи блока на SD карту вы это не объясните.  

Хотя еще можно подозревать контроллер SDIO, но сама файловая на последнем месте в списке подозреваемых.