Digi 0 23 октября, 2019 Опубликовано 23 октября, 2019 · Жалоба Пишу проект на STM32 с использованием FreeRTOS и для доступа к SD карте - FAT FS. У меня в проекте есть несколько задач, из которых я планирую записывать информацию в файлы на SD. Лог файлы, результаты. Таких файлов 3. Например логи будут писаться (дописываться) сразу из нескольких задач в один файл. Как правильно и красиво реализовать такое обращение ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 116 23 октября, 2019 Опубликовано 23 октября, 2019 · Жалоба Обрамить одним мутексом все функции доступа к SD-карте. Чтобы в любой момент времени работать с картой могла только одна задача, остальные становились в очередь в ожидании освобождения мутекса.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 23 октября, 2019 Опубликовано 23 октября, 2019 · Жалоба 17 minutes ago, Digi said: Пишу проект на STM32 с использованием FreeRTOS и для доступа к SD карте - FAT FS. У меня в проекте есть несколько задач, из которых я планирую записывать информацию в файлы на SD. Лог файлы, результаты. Таких файлов 3. Например логи будут писаться (дописываться) сразу из нескольких задач в один файл. Как правильно и красиво реализовать такое обращение ? Такое делают с использованием очередей. Все задачи пишут в одну очередь задачи пишущей на SD. Таким образом обезопаситесь как минимум от случаев когда в лог какая-то задача по ошибке начнет писать непрерывно. Тогда очереди позволяют отследить этот факт и запостить в лог сообщение о переполнении и факте нарушения реального времени. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Digi 0 24 октября, 2019 Опубликовано 24 октября, 2019 · Жалоба 15 hours ago, Сергей Борщ said: Обрамить одним мутексом все функции доступа к SD-карте. Чтобы в любой момент времени работать с картой могла только одна задача, остальные становились в очередь в ожидании освобождения мутекса.. Так пытался делать, но либо чего то упустил, либо что то ещё. Иногда при обращении к карте, функция (уже не помню какая) зависала внутри. А кто нибудь такое, в такой конфигурации, реализовывал ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 55 24 октября, 2019 Опубликовано 24 октября, 2019 · Жалоба 30 minutes ago, Digi said: Иногда при обращении к карте, функция (уже не помню какая) зависала внутри Ну с таким подходом это гадание на кофейной гуще. 30 minutes ago, Digi said: А кто нибудь такое, в такой конфигурации, реализовывал ? Ага. И не только карту, но и другие ресурсы. Но мне больше очереди нравятся. При этом к железу имеет доступ только один кусок кода, который может быть привилегированным (cortex-m3/m4). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 166 24 октября, 2019 Опубликовано 24 октября, 2019 · Жалоба 1 час назад, haker_fox сказал: Ага. И не только карту, но и другие ресурсы. Но мне больше очереди нравятся. При этом к железу имеет доступ только один кусок кода, который может быть привилегированным (cortex-m3/m4). Чисто очереди без блокирующего доступа (на мьютексах/семафорах и т.п.) возможны только при неограниченной памяти. Или если точно известно, что все пишущие задачи имеют строго регламентированную скорость записи в очереди и суммарная их скорость не превышает возможности по буферизации, предоставляемые очередью. Как только есть хотя-бы одна задача, которая может переполнить очередь если её не притормаживать своевременно, то появляется необходимость в блокирующем доступе. И решение с очередью превращается в решение "очередь + блокирующий доступ". А такие задачи где есть только запись несколькими потоками с фиксированной скоростью каждого потока - редкость, так как в большинстве случаев, при грамотном планировании алгоритма работы программы, они превращаются в задачи с одним только пишущим потоком, для которого не нужна никакая межпоточная синхронизация. Именно поэтому ответ данный Сергей Борщ - исчерпывающий и достаточный в общем случае. А очередь - лишь позволит улучшить это решение в некоторых частных случаях. А для начинающего тем более однозначный ответ - блокирующий доступ. Ибо если на блокирующем доступе он не может реализовать, то на одной очереди - тем более не сможет сделать нормальную синхронизацию. 2 часа назад, Digi сказал: Так пытался делать, но либо чего то упустил, либо что то ещё. Иногда при обращении к карте, функция (уже не помню какая) зависала внутри. Если у вас что-то виснет, то нужно отлаживать и искать ошибку. У себя. Или Вы думаете, что виснут мьютексы сами по себе, и все кто их использует - дураки? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 24 октября, 2019 Опубликовано 24 октября, 2019 · Жалоба 2 hours ago, Digi said: Так пытался делать, но либо чего то упустил, либо что то ещё. Иногда при обращении к карте, функция (уже не помню какая) зависала внутри. Мьютексы - довольно коварное средство, поскольку они вызывают наследование приоритета. Т.е. в голове надо держать всегда что приоритет вашей задачи меняется как только захватываете мьютекс. Следовательно после захвата мьютекса нельзя использовать другие разделяемые ресурсы кроме того что защищается мьютексом. Но беда в том что вы не знаете как и чем делит ресурсы сама файловая система да и архитектуру процедур вашего приложения мьютексы потребуют сильно пересмотреть. Еще помнить что кэш файловой системы любит последовательность в записи и не любит когда каждая следующая запись идет в новый файл, Тогда кэш просто перестает работать. Поэтому мьютексы только для очень простых и прозрачных API. Я мьютексы применяю очень редко. Так что очереди и только очереди. Помните что очереди можно проверять без задержки. Они не влияют на реальное время критических задач. А переполнение очереди - это очень полезная фича, которая вам необходима для контроля за вышедшими из под контроля задачами и за соответствием скоростей потоков задач источников и задач приемников. Скорости этих потоков без очередей вы не гармонизируете никак. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Digi 0 24 октября, 2019 Опубликовано 24 октября, 2019 · Жалоба 22 minutes ago, jcxz said: Если у вас что-то виснет, то нужно отлаживать и искать ошибку. У себя. Или Вы думаете, что виснут мьютексы сами по себе, и все кто их использует - дураки? Ясное дело, что ошибка у меня. Виснет не мьютекс, а функция работы с СД картой. Зависала в цикле ожидания какого-то состояния с карты (уже не помню какого именно) внутри низкоуровневой функции. Причём это происходило при работе с несколькими файлами. Сейчас работаю в один момент времени только с одним файлом. Но это временно )) Да, обращения к СД у меня блокировались мьютексами, но тем не менее проблема была. Поэтому и спросил, как это правильно реализовать. Планирую переосмыслить и переделать как положено ) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 166 24 октября, 2019 Опубликовано 24 октября, 2019 · Жалоба 26 минут назад, AlexandrY сказал: Еще помнить что кэш файловой системы любит последовательность в записи и не любит когда каждая следующая запись идет в новый файл, Тогда кэш просто перестает работать. Осталось только понять - причём тут кеш? Или хотелось написать про всюду рекламируемые облака и что "нужно их использовать вместо уже нынче немодного SD", но дёрнулась рука? 22 минуты назад, Digi сказал: Ясное дело, что ошибка у меня. Виснет не мьютекс, а функция работы с СД картой. Зависала в цикле ожидания какого-то состояния с карты (уже не помню какого именно) внутри низкоуровневой функции. Причём это происходило при работе с несколькими файлами. Давно не пользовался FatFS, но я бы посмотрел в сторону увеличения количества дескрипторов описателей открытых файлов (или как оно там правильно называется в FatFS?). Должно быть что-то типа такого в FatFS.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться