Форум разработчиков электроники ELECTRONIX.ru

Помощь - Поиск - Пользователи - Календарь

Полная версия этой страницы: FatFS под RTOS

Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы

Faradey

Mar 31 2009, 07:20

Есть необходимость использования 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:36

Цитата(Faradey @ Mar 31 2009, 10:20)

Прошу уже прошедших по этому пути поделиться опытом

Я бы mutex вставил прямо в структуру FIL. Вам ведь надо разделять одновременный доступ к одному и тому же файлу. И параметр лишний пропадает, и семафор не перепутаете. Еще один mutex надо повесить на низкоуровневые функции.

Faradey

Mar 31 2009, 07:52

насчет мютексов на низкоуровневые ф-ции я подумал первым делом, но меня "смутил" факт изменения структуры файловой системы из нескольких потоков.
на счет доступа к одному файлу из нескольких потоков - тут я извиняюсь, не до конца описал ситуацию, исправляюсь:
В одном потоке открыт файл на запись и только в этом потоке он записывается.
В другом потоке(-ах) открывается(-ются) другие файлы на чтени/запись, поскольку RTOS я использую в вытесняющем "режиме" то возможны варианты перекресного использования одних и тех-же ресурсов файловой системы, насколько я понял - это структура FATFS. Вот собственно в этом контексте я и предположил использование приведенного выше варианта.

З.Ы. кстати логичным кажется именно "защита" структуры FATFS.

Andy Mozzhevilov

Mar 31 2009, 08:42

Я в uCOS обернул все API-шные функии FatFs в семафор.
Хотел сначала обернуть только функции драйвера, но просмотрел структуру FatFs и пришел к выводу, что этого недостаточно.
В исходниках есть функции, работающие в том числе с File system object типа FATFS, поэтому может возникать конфликт, если не разделить обращение из задач к функциям, работающих с этой структурой. Так что возможно нужно защищать не столько структуру FIL, сколько FATFS.
В любом случае, если добьетесь какого-либо результата по более оптимальному "обертыванию" критических мест FATFS с минимальным внесением изменений в исходные тексты, будет очень интересно узнать.

zhz

Apr 6 2009, 14:45

R0.07, Apr 01, 2009
Merged Tiny-FatFs as a buffer configuration option.
Added long file name support.
Added multiple code page support.
Added re-entrancy for multitask operation.
Added auto cluster size selection to f_mkfs().
Added rewind option to f_readdir().
Changed result code of critical errors.
Renamed string functions to avoid name collision.

Andy Mozzhevilov

Apr 9 2009, 15:09

Взял 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().
Буду тестировать.
Если у кого вдруг появятся результаты, в том числе найдутся баги (мало ли, любой код не без этого), то интересно будет узнать.

zhz

Apr 9 2009, 22:24

Цитата(Andy Mozzhevilov @ Apr 9 2009, 18:09)

Но, не знаю, насколько автор тестировал "re-entrancy for multitask operation", поскольку есть банальная синтаксическая ошибка в функции unlock_fs()

С кем не бывает

Цитата

Но по коду бегло просмотрел, вроде как дополнительно низкоуровневые функции драйвера лочить не нужно, все должно разруливаться через введенные lock_fs() и unlock_fs().

Для одной карты и одной FS может и не надо. А если карт больше одной (у меня их 8) то, полагаю, мютексить драйвер MCI необходимо.

Цитата

Буду тестировать.
Если у кого вдруг появятся результаты, в том числе найдутся баги (мало ли, любой код не без этого), то интересно будет узнать.

Я под FreeRTOS второй день тестирую. Вроде пока все нормально. LFN не пробовал, а в остальном - вполне.

zhz

Apr 13 2009, 16:08

R0.07a, Apr 14, 2009
Separated out OS dependent code on re-entrant configuration.
Added multiple sector size support.

Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.