Помочь могут только тулзы, работающие с mmc-шиной, а не через свисток. Другое дело, что mmc-utils вроде как и не умеет ставить permanent write protection. Стоит им же посмотреть protection status.
То есть ровным счетом ничего не изменится (в лучшем случае, ведь помимо данных сектора в журнал придется поместить и его номер, то есть писать придется минимум два).
Не для всей периферии - таймеры гвоздями прибиты.
Вообще, в мире так принято - частоту ядра снижать при необходимости. Другое дело, что STM32 не очень приспособлен для динамического управления частотой.
Это ваша искаженная интерпретация. Причем намеренно искаженная - такой вот традиционно изящный полемический прием.
Ну, или же укажите, к какому месту файловой системы подключается источник резервного питания.
Да нет, это вы ошибаетесь в части интерпретации понятия "потеря данных". Речь, разумеется, не о потере уже записанных данных при аварии, а о текущих, готовящихся или находящихся в процессе записи. В первом случае и абсолютно надежная™ ФС, основанная на абсолютно надежных™ самописных библиотеках, совершенно не спасет.
В том и прок - не обрушить ненароком метаданные ФС. Если система не имеет резервного источника питания, то она по определению может терять данные при аварии.
Ширина шины может быть 4 или 8 бит, но это 1 бит на точку, 120Hz кадровой и управление интенсивностью через FRC. То есть никоим образом не совместимо с современыми образцами.
