| |
|
  |
 FatFS под RTOS, Интересует опыт по "доработке" FatFS для работы в несколько по |
|
|
|
|
 Mar 31 2009, 07:20
|
Частый гость
Группа: Свой
Сообщений: 127
Регистрация: 31-05-06
Из: Belarus, Minsk
Пользователь №: 17 638
|
Есть необходимость использования FatFS под FreeRTOS в несколько потоков с картой памяти. Наиболее простым способом видиться "упаковка" используемого API FatFS в мютекс, аля: Код FRESULT RTOS_f_open(
FIL *fp, /* Pointer to the blank file object */
const char *path, /* Pointer to the file name */
BYTE mode, /* Access mode and file open mode flags */
xSemaphoreHandle mutex /* <-- Например так */
)
{
xSemaphoreGive( mutex );
FRESULT fr = f_open( &file, file_name, FA_OPEN_ALWAYS | FA_WRITE );
xSemaphoreTake( mutex, portMAX_DELAY );
return fr;
} Прошу уже прошедших по этому пути поделиться опытом 
--------------------
Завтра пойму, что нужно было сделать вчера...
|
|
|
|
|
|
|
|
Mar 31 2009, 07:52
|
Частый гость
Группа: Свой
Сообщений: 127
Регистрация: 31-05-06
Из: Belarus, Minsk
Пользователь №: 17 638
|
насчет мютексов на низкоуровневые ф-ции я подумал первым делом, но меня "смутил" факт изменения структуры файловой системы из нескольких потоков.
на счет доступа к одному файлу из нескольких потоков - тут я извиняюсь, не до конца описал ситуацию, исправляюсь:
В одном потоке открыт файл на запись и только в этом потоке он записывается.
В другом потоке(-ах) открывается(-ются) другие файлы на чтени/запись, поскольку RTOS я использую в вытесняющем "режиме" то возможны варианты перекресного использования одних и тех-же ресурсов файловой системы, насколько я понял - это структура FATFS. Вот собственно в этом контексте я и предположил использование приведенного выше варианта.
З.Ы. кстати логичным кажется именно "защита" структуры FATFS.
--------------------
Завтра пойму, что нужно было сделать вчера...
|
|
|
|
|
|
|
|
Mar 31 2009, 08:42
|
Знающий
Группа: Свой
Сообщений: 877
Регистрация: 26-01-05
Из: Екатеринбург
Пользователь №: 2 206
|
Я в uCOS обернул все API-шные функии FatFs в семафор.
Хотел сначала обернуть только функции драйвера, но просмотрел структуру FatFs и пришел к выводу, что этого недостаточно.
В исходниках есть функции, работающие в том числе с File system object типа FATFS, поэтому может возникать конфликт, если не разделить обращение из задач к функциям, работающих с этой структурой. Так что возможно нужно защищать не столько структуру FIL, сколько FATFS.
В любом случае, если добьетесь какого-либо результата по более оптимальному "обертыванию" критических мест FATFS с минимальным внесением изменений в исходные тексты, будет очень интересно узнать.
--------------------
Пасу котов...
|
|
|
|
|
|
|
|
Apr 9 2009, 15:09
|
Знающий
Группа: Свой
Сообщений: 877
Регистрация: 26-01-05
Из: Екатеринбург
Пользователь №: 2 206
|
Взял 0.07 Для uCOS получилось примерно так: CODE
#include "ucos_ii.h"
#define WAIT_OBJECT_0 TRUE
typedef OS_EVENT * HANDLE;
inline HANDLE CreateMutex(void *p1, BOOL b, void *p2)
{
HANDLE FatFS_Sem;
FatFS_Sem = OSSemCreate(1);
if (0 == FatFS_Sem)
{
while(1)
{
}
}
return (FatFS_Sem);
}
inline void CloseHandle(HANDLE pmutex)
{
INT8U err;
OSSemDel(pmutex, OS_DEL_ALWAYS, &err);
}
inline BOOL WaitForSingleObject(HANDLE pmutex, INT16U tout)
{
INT8U err;
OSSemPend(pmutex, tout / OS_TICKS_PER_SEC, &err);
if (OS_ERR_NONE == err)
{
return (TRUE);
}
return (FALSE);
}
inline void ReleaseMutex(HANDLE pmutex)
{
OSSemPost(pmutex);
}
Но, не знаю, насколько автор тестировал "re-entrancy for multitask operation", поскольку есть банальная синтаксическая ошибка в функции unlock_fs(). Но по коду бегло просмотрел, вроде как дополнительно низкоуровневые функции драйвера лочить не нужно, все должно разруливаться через введенные lock_fs() и unlock_fs(). Буду тестировать. Если у кого вдруг появятся результаты, в том числе найдутся баги (мало ли, любой код не без этого), то интересно будет узнать.
--------------------
Пасу котов...
|
|
|
|
|
|
|
|
Apr 9 2009, 22:24
|
Частый гость
Группа: Свой
Сообщений: 80
Регистрация: 21-03-05
Пользователь №: 3 559
|
Цитата(Andy Mozzhevilov @ Apr 9 2009, 18:09)  Но, не знаю, насколько автор тестировал "re-entrancy for multitask operation", поскольку есть банальная синтаксическая ошибка в функции unlock_fs() С кем не бывает  Цитата Но по коду бегло просмотрел, вроде как дополнительно низкоуровневые функции драйвера лочить не нужно, все должно разруливаться через введенные lock_fs() и unlock_fs(). Для одной карты и одной FS может и не надо. А если карт больше одной (у меня их 8) то, полагаю, мютексить драйвер MCI необходимо. Цитата Буду тестировать.
Если у кого вдруг появятся результаты, в том числе найдутся баги (мало ли, любой код не без этого), то интересно будет узнать. Я под FreeRTOS второй день тестирую. Вроде пока все нормально. LFN не пробовал, а в остальном - вполне.
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
