tgruzd

У меня версия другая, но поведение тоже непонятное. Выходит, программисты не бездействуют)

Хорош

У вас эта мысль прямо красной линией в каждом сообщении. Ок, я не до конца понимаю, если вы так настаиваете. Если вас задел мой первоначальный вопрос о влиянии вашего кэширования на ваши данные, прошу меня простить: уверен, вы всё делали правильно. Я просто описал (возможно невнятно и чрезмерно кратко, ещё раз извините) свой случай, где кэширование, будь оно только на уровне ФС, принесло бы не только пользу но и вред. Да, именно это мне и нужно было, при том, чтобы ещё и формат файла не ломался, так как при последующем включении после сбоя желательно было писать в тот же файл. Ещё раз повторю, на всякий случай: в моём случае f_sync почти не увеличивал частоту "реальной" записи. Хотя, уже сомневаюсь что вы это поймёте (имею в виду не вашу способность, а моё нежелание описывать в подробностях своё решение и соображения при его реализации). Спасибо, конечно. Но в нюансах я разобрался (не до конца, само-собой, но лишь в меру своих способностей) перед тем, как реализовал свой способ. А после того, как реализовал, ещё и хорошенько проверил, достиг ли я с его помощью конкретного, нужного мне поведения системы. Следует с осторожностью относиться к советам, которые дают люди не разобравшись в вопросе (я сейчас не имею в виду вопрос всех способов сохранять данные во всех абстрактных устройствах, в котором вы, очевидно, разобрались до конца), но с порога орущие: "вы всё делаете неправильно". А картинке из документации конкретной ФС (тоже не самой лучшей, как я теперь могу догадываться), поясняющую работу конкретной функции, я не вижу смысла не доверять. На этом предлагаю завершить нашу с Вами дискуссию.

Вы первый начали. Если бы внимательно прочитали про сценарий в котором я использовал f_sync, то поняли бы, что это почти не влияло на частоту записей. Да кто же спорит про разные способы? Вот, это видимо, писали люди, не разбирающиеся в ФС, раз советуют что-то из вне вашего списка: Я тут даже комментировать не стану.

Попробуйте потянуть границу вверх. Там странно (или криво) решили вопрос ресайза окна Filter. Иногда оно обрезается сверху, хотя во всех случаях логично - снизу. И странно , при таком перетягивании скроллбар таки может появиться). Всё-таки, какая-то кривизна с поведением этих окон есть, и она кочует из версии в версию.

Выглядит, как будто заказчику не рабочая схема нужна, а "импортозамещённая".

В моей ситуации, данные писались постоянно в несколько файлов. Так что "не заметить" всё таки трудновато было. Спасибо, как раз на износ мне было плевать. В приоритете была целостность файлов при минимизации влияния на скорость записи. Да уж, теперь-то понял. Наверное вы сейчас наспех прочитали про f_sync, толком не поняв, как и зачем я его использовал. Жаль, что вы увидели лишь повод подозревать и смеяться. Не туда подозреваете, похоже.

Вот это поворот) Спасибо, когда-нибудь попробуем научиться всему этому, раз это сулит возможность программировать "как для 8-ми битников , так и моделей покруче". Главные вопросы в такой ситуации: "на..я?" и "зачем?" если всё-таки проще с ОС.

Ровно это и означает: сломанную ФС трудно не заметить. И да, я не исключаю, что сбой ФС таки может произойти с некоторой вероятностью. Как и не утверждаю, что описанный мной вариант лучше всех других. Вот как раз на запись мелкими кусочками и влияет. Если вы пишете десяток байт в файл, то этот десяток именно в буфер структуры FILE и запишется и там будет висеть пока буфера достаточно или пока вы не закроете файл. Использование f_sync, напротив, принудительно сливает данные на диск не освобождая FILE, что позволяет не открывать (f_open) файл повторно. Не знаю, возможно вы этот механизм и имеете в виду под встроенным кэшированием, но тогда и выходит, что кэширование негативно влияет на целостность ФС и положительно на минимизацию износа.

Ну ок. Я использовал немного другой подход, когда нужно было много мелких записей писать на SD в разные файлы (не знаю, журналирование это или нет): Файлы открывались при старте системы и не закрывались, условно, никогда. Кэширование делал на уровне самих записей, то есть, накапливал их буфере для каждого файла (типичный размер самой записи был кратно меньше размера сектора, типичный размер буфера перед записью - как повезёт, зависит от интенсивности потока данных), после записи сразу f_sync. Да, конечно, данные за последние пару миллисекунд могли и потеряться. Но такого, чтобы файл терялся или ФС повреждалась не замечал.

Мне кажется, три ТТЛ элемента с подтяжкой выходов 270 ом тоже хорошо превращают электричество в тепло.

Как это отражается на вероятности повредить данные, при внезапном пропадании питания?

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

Я конкретно с этой серией не работал, точно не скажу. Но считаю, что jtag/swd-отладчик это очень нужная вещь.

По аналогии может и не получиться. Ищите различия (они есть) в даташитах: Чтобы прямо кирпич сделать - ещё постараться надо.

Про неведомый мне гуи гилдер ничего сказать не могу. А LVGL - как раз то, что нужно для написания гуя на C. Пойдет везде, где есть возможность вывода изображения. В составе уже есть драйверы, в том числе вроде и под линукс. Если что, вывод изображения (относительно) просто написать самостоятельно под нужный вам дисплей/периферию. Так не победим)

"Короче, нахер все заткнитесь и ответьте на вопрос"

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

Вы человека совсем в тупик загнать хотите? Тут скоро месяц будет, как толщину диэлектрика выбирают. Страшного нет ничего, конечно - все с чего-то начинали. Но это тот случай, когда надо начать с простого: выбрать стандартный стек, посчитать импеданс +-20% и начать уже читать про трассировку. Потому что трассировка будет иметь чуть большее значение чем импеданс дорожек. точняк)

Холивара не будет) Устраивает - хорошо.

Не знаю. По-моему, лучше LVGL изучить и писать код руками.

да. Это для тех, кто хочет быстро и мышкой и чтобы программистынинужны. Результат немного предсказуем). Вы ещё в выхлоп этой дичи не успели посмотреть, наверное.

Это как раз случай, когда слеплено из картинок. Но красиво, да. Пример с их сайта. И чтобы такую красоту делать, нужен дизайнер, который нарисует вам эти картинки. неа. Приглядывался, но предчувствовал, что будет "досадно" 🙂 Наверное, давно смотрели. Они за последние пару лет хорошо подросли.

Работать не работал, но собеседовался не так давно. И вот что я заметил: в компании не менее двух "говорящих кукол": одна, на неоднократные вопросы о требуемых навыках говорит "Главное уметь в технологию-X", а другая уже после собеседования, даст тестовое задание по технологии-Y, плюс, немного X. На предложение заменить технологию-Y на технологию-YY в тестовом задании, чтобы таки показать знание X отвечает: "мы не готовы продолжить с Вами диалог ... , т.к. Вы не готовы выполнить тестовое задание в том виде, в котором оно есть." Задание оценивалось в неделю работы. Ееееестееееественно, неоплачиваемое 🙃. Не знаю, может просто "повезло" на таких.

Как по мне, Edge/Square Line у них пока ещё сырой и не годится.