Segment

И правильно сделал, если так.

Объем настроек от нескольких байт до нескольких десятков килобайт. Каким образом - надежным и быстрым.

Кто какие использует файловые системы? От больших и толстых до маленьких систем сохранения настроек, любые платные или бесплатные. Или может быть какие-нибудь особенные плюшки есть крутые в используемых библиотеках. В общем ваше мнение интересно услышать. Не нашел более подходящего раздела.

Очень спорное утверждение. Компании релоцировали (и все еще продолжают это делать) сотрудников целыми командами. Фрилансеры знакомые тоже уехали.

И правда, им ведь не оплатить его в рублях))

Эм, достаточно зайти через VPN и посмотреть цепочки поставок. Как сказал какой-то чиновник "плохо не то, что мы в жопе, а то, что мы начинаем там обживаться, а не пытаемся из нее выбраться."

лол, в чём смысл данной инициативы?

Не откликался, но советую пересмотреть ценообразование. Если брать среднюю ставку 1200р/час, и неделю на Ваш первый этап (если плата действительно не слишком сложная), то выйдет около 30-40к только за схему. Хотя я думаю могут согласиться и на меньшую стоимость, кто еще обучается или не очень опытен, тогда я бы брал запас на две-три недели с учетом все проверок и перепроверок первого этапа. Но тут правильно упомянули, что здесь нет этапа формирования технических требований/задания. Разводку печатной платы я бы тоже оценил для простой схемы в календарную неделю работы. Написание прошивки скорее всего займет несколько недель, потому что отладка и проверка занимает больше всего времени. Итого общий ценник должен быть около 100-150к. Но повторюсь, описание читал по диагонали.

Вероятно. У кого ни спрашиваю везде получаю какие-то абстрактные ответы, что в rust отсекаются рядовые баги, ну как бы и всё. Если смотреть какие-то статьи, то примеры которые там приведены - тривиальны. Если смотреть код на github, то простейшие реализации каких-то алгоритмов кажутся (вероятно, нужно очень погрузиться в язык) невероятно замысловатыми для меня. То есть еще до бизнес-задачи дело не дошло, а код выглядит как enterprise edition. При этом я наблюдаю все те же счетчики ссылок, огромное количество синтаксических конструкций, которые конечно им нужны, но ИМХО на том же Си (не С++) код выглядит при правильном подходе лаконичнее и понятнее, ведь это тоже важно при разработке.

Кто-нибудь может объяснить в чем же такое преимущество переписывания кода с Си на Rust? Я понимаю, что это другой язык со всеми вытекающими, но тренд "давайте перепишем все на rust" мне не понятен. При этом мне пока не удается найти внятное сравнение "безопасной реализации" на rust кода, который был переведен из Си проекта. Чтобы можно были взглянуть на сравнение "было-стало" и как-то оценить во-первых синтаксическую нагрузку, а также затраченное время и конечный для понимания код.

@mmarc__ Если приемлемо работать в Altium, то можно работать на полной удаленке на почасовой оплате, так работаем уже давно. Если интересно, то пишите на [email protected]

Какие компоненты запретили и как это помешало развитию? Вы не путаете развитие и потребление? Если я Вам дам какое-то очень технологичное устройство для нефтегазового комплекса, Вы станете сразу более развитым?

Можете привести пример таких ограничений?

Зачем они вернулись?

Можно было просто ответить, что перспектив нет, это очевидно, зачем так долго это обсуждать.

Потому что вопрос поставлен некорректно, отвечаем просто по сути проблемы. Что за механизм? Как Вы себе это представляете? У многих, если не у всех, загрузка кода происходит с одного и того же адреса, то есть как минимум этот сектор будет подвержен максимальному перезатиранию. Механизм может быть реализован разве что с разнесением секций в разных секторах, но при малом объеме флеша вряд ли это как-то сильно улучшит ситуацию. Сейчас все больше микроконтроллеров имеют кеширование исполняемого флеша, оно линейно. Так что механизма такого никто не предусматривает. Могу лишь только предположить, что выходом из подобной ситуации может быть некий счетчик обновлений микроконтроллера, который можно будет проверить перед тем как отдавать плату в бой.

Если речь идет о прошивке, то предполагается, что она ставится один раз и далее работает без стираний. Плюс можно добавить пару десятков обновлений прошивок, и все-равно это будет довольно мало, чтобы сильно занизить data retention. Но если у Вас блоки стирались уже 1000 раз, в среднем data retention гарантируется уже только около 10 лет (а не 20). Но опять таки, все эти 20 и 10 лет очень условны, т.к. все зависит от условий, а также от производственного брака. А если говорить о внутреннем хранилище, как это например используют в nRF SDK, то там нужно выравнивание, и еще желательно периодически данные переносить, хотябы раз в год.

Ручной монтаж или автоматический? На пасту ставили?

Ну, например, SD-карту ставить не всегда удобно. Паять ее на плату? Не технологично. Ставить разъем? Дороже выходит и место нужно много. Иногда целесообразно задействовать NOR с небольшим объемом, для периодической записи, но почему-то многие думают, что в NOR не возникают ошибки записи. Для большего объема данных можно поставить NAND.

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

Зависит от файловой системы, в моем проекте допустимо иметь страницы только для чтения, это избавит от лишнего переноса. Да и в целом это вопрос скорее к пониманию работы flash памяти и ее особенностей, которые не везде детально описаны.

@aaarrr А вот если блок помечен как битый, например у его не смогла записаться последняя страница и мы пометили блок как Bad Block, и если остальные страницы читаются без ошибок (и без коррекций), то я могу оставить его как Read Only? И перенести страницы только тогда, когда уже при чтении будет проявляться коррекция ECC?

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

То есть это программная реализация, не относящаяся к особенностям NAND памяти как таковой? Если в моей файловой системе виртуальная адресация идет постранично, а не поблочно, то при обнаружении скорректированной ошибки в странице, мне необходимо и достаточно просто перенести саму эту страницу (не перенося остальные страницы в этом блоке), верно?

Тут понятно, если у нас восстанавливаемая разовая ошибка, то при последующем стирании блока с ним может быть все в порядке. Но мне непонятно зачем переносить весь блок? Подразумевается, что данные начнут деградировать и со временем там будет больше ошибок?