FreeRTOS+FAT use with and without the RTOS

Kernel
1

sachingole wrote on Monday, June 12, 2017:

Hi All,

This link [http://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_FAT/index.html] says that

FreeRTOS+FAT is an open source, thread aware and scalable FAT12/FAT16/FAT32 DOS/Windows compatible embedded FAT file system which was recently acquired by Real Time Engineers ltd. for use with and without the RTOS.

On my Nucleo board, when I have tried to create RamDisk before calling vTaskStartScheduler(); then it doesnt create RamDisk.

But when I have tried to create inside thread after vTaskStartScheduler() starts then RamDisk created successfully…

1. Is there anything specific need to be done to create RamDisk without using vTaskStartScheduler inside thread ?
2. Is FreeRTOS+FAT soruce is tightly coupled with FreeRTOS source code, Can we make compatible with other os or non-os platform.
3. Can FreeRTOS+FAT used with other RTOS like ThreadX or VxWork?

Best regards,
Sachin

2

rtel wrote on Monday, June 12, 2017:

The FAT library has to be ported to storage media, so the port layer is
not really part of the FAT library itself, and I suspect the RAM disk
(which works on any device with enough RAM) has a dependency on the RTOS

  • although I’ve not checked to see if that is true. It may also be the
    case that the ‘without an RTOS’ claim is no longer valid.
3

heinbali01 wrote on Monday, June 12, 2017:

Hi Sachin, as far as I remember, the only dependency is ff_locking.c.

If you’re a single user, you should make an empty version of each function:

BaseType_t FF_HasSemaphore (void *pxSemaphore)
{
	return 0;
}

BaseType_t FF_TrySemaphore( void *pxSemaphore, uint32_t ulTime_ms )
{
	return 1;
}
/*-----------------------------------------------------------*/

void FF_PendSemaphore( void *pxSemaphore )
{
}
/*-----------------------------------------------------------*/

void FF_ReleaseSemaphore( void *pxSemaphore )
{
}
/*-----------------------------------------------------------*/

void FF_Sleep( uint32_t ulTime_ms )
{
}
/*-----------------------------------------------------------*/

BaseType_t FF_CreateEvents( FF_IOManager_t *pxIOManager )
{
	return pdTRUE;
}
/*-----------------------------------------------------------*/

void FF_LockDirectory( FF_IOManager_t *pxIOManager )
{
}
/*-----------------------------------------------------------*/

void FF_UnlockDirectory( FF_IOManager_t *pxIOManager )
{
}
/*-----------------------------------------------------------*/

int FF_Has_Lock( FF_IOManager_t *pxIOManager, uint32_t aBits )
{
	return pdTRUE;
}

void FF_Assert_Lock( FF_IOManager_t *pxIOManager, uint32_t aBits )
{
}

void FF_LockFAT( FF_IOManager_t *pxIOManager )
{
}
/*-----------------------------------------------------------*/

void FF_UnlockFAT( FF_IOManager_t *pxIOManager )
{
}
/*-----------------------------------------------------------*/

BaseType_t FF_BufferWait( FF_IOManager_t *pxIOManager, uint32_t xWaitMS )
{
	return pdTRUE;
}
/*-----------------------------------------------------------*/

void FF_BufferProceed( FF_IOManager_t *pxIOManager )
{
}
/*-----------------------------------------------------------*/

Regards.

4

sachingole wrote on Monday, June 12, 2017:

Hi Hein,

  1. You are suggesting that if its one user means only main thread then it will be possible to create RamDisk with above mentioned empty functions for semaphore.

  2. Is FreeRTOS+FAT soruce is tightly coupled with FreeRTOS source code, Can we make compatible with other os or non-os platform.
    But it is multi threaded system then it is coupled with FreeRTOS scheduler, right.

  3. Can FreeRTOS+FAT used with other RTOS like ThreadX or VxWork?
    ??

5

heinbali01 wrote on Tuesday, June 13, 2017:

Hi Sachin,

The +FAT locking mechanism, as it has been implemented in ff_locking.c, is using FreeRTOS kernel API’s, notably mutexes and Event Groups.
These functions have been put together in a single module, so that all other modules remain independent from the kernel.
At least, that was the intention. But, through time, through the years, the library has been ( new verb ) : freertos-ised.

Also, the project got a nice extension: a new layer called ff_stdio. That module makes use of an errno that is local to a task.
Each task can have 1 or more pointers for local storage.

I’m trying to compile a +FAT project that uses a RAM-disk with the FreeRTOS header files excluded, that is any of these files:

    //#include "FreeRTOS.h"
    //#include "task.h"
    //#include "semphr.h"
    //#include "portable.h"

Most modules do not miss a lot, mainly the following defines:

    /* Get the standard types like 'int32_t'. */
    #include <stdint.h>

    typedef long BaseType_t;
    typedef unsigned long UBaseType_t;

    #define pdFALSE          ( ( BaseType_t ) 0 )
    #define pdTRUE           ( ( BaseType_t ) 1 )

    #ifndef portINLINE
        #define portINLINE   __inline
    #endif

    #ifndef configNUM_THREAD_LOCAL_STORAGE_POINTERS
        #define configNUM_THREAD_LOCAL_STORAGE_POINTERS    3 /* FreeRTOS+FAT requires 2 pointers if a CWD is supported. */
    #endif

That is not too much.

Today I found a few more dependencies, two of them are locking mechanisms:

ff_ioman.c is using :

    taskENTER_CRITICAL
    taskEXIT_CRITICAL

ff_sys.c is using :

    vTaskSuspendAll
    xTaskResumeAll

ff_stdio.c is using :

    vTaskSetThreadLocalStoragePointer
    pvTaskGetThreadLocalStoragePointer

Coming back to your questions:

You are suggesting that if its one user means only main thread then it will
be possible to create RamDisk with above mentioned empty functions for semaphore.

Yes.
Beside the locking mechanism there are 6 more functions that must be simulated, listed here above.

If FreeRTOS+FAT source is tightly coupled with FreeRTOS source code, can we make
compatible with other os or non-os platform.

Yes you can.

But if it is multi threaded system then it is coupled with FreeRTOS scheduler, right.

It will equally work together with another scheduler.

Can FreeRTOS+FAT used with other RTOS like ThreadX or VxWork?

You can also use it with a different RTOS, provided that you implement the locking mechanisms with primitives from that RTOS.
In case there is only a single user, things are a lot simpler.

Regards.

6

sachingole wrote on Wednesday, June 14, 2017:

Thanks Hein for your valueable response which has research included in it.

In summary :-

  1. Intention was not to create +FAT which is independant than FreeRTOS, if taking as it is then it is not compatible with other OS but if someone want he can make it with single user.
7

heinbali01 wrote on Thursday, June 15, 2017:

Sounds like a good summary, except that it is also possible to port +FAT to a different multi-tasking OS.

The FreeRTOS version of ff_locking.c is using both mutexes and event groups. If a different platform only has semaphores that is enough to create a reliable locking.

Regards